Re: AD review of draft-ietf-imapapnd-rfc2088bis-03

Hi Barry,

On 05/03/2016 18:36, Barry Leiba wrote:
>>>> Hm, but then I think the sentence is meaningless.  The server still
>>>> has to read and discard the literal, so whether it sends the BAD
>>>> before or after it does that hardly matters.  What are you really
>>>> trying to say with that parenthetical that's useful?
>>>
>>> This is a valuable implementation advice.
>>
>> This also potentially affects how client implementations are coded.
> 
> I don't agree that it's valuable as written, as I don't think it says
> enough to be useful.  Consider a non-expert implementor, who codes
> like this:
> 
> - Read up to CRLF
> - See "{666666+}" at the end
> - Send BAD
> - Now what?  Read the next command?  That won't work, because the
> client already sent the literal.  Close the socket?  With or without
> sending untagged BYE first?  And why would you want to close the
> socket when you've already said BAD to the command itself?  Are we
> advising servers to kick off clients that have protocol errors?  And
> then what if the client just reconnects?  Kick it off again?

But you know that this particular problem is not really solvable.

> Rather than having a cryptic parenthetical, if you want to give useful
> implementation advice it'd be better to give real advice about the
> options that are reasonable, and what the pros and cons are.  And I
> personally (just opinion here) don't think that sending BAD before
> discarding the literal is something implementors should be advised to
> do, even if some implementations happen to do it... unless one can
> articulate what advantages it gives to the server or to the client.

Oh, I think you misinterpreted what the text is trying to say: it
doesn't recommend discarding the literal. Implementations that return
BAD must still eat the data. But this sentence is saying that it is OK
to say BAD immediately after observing a large literal, without waiting
till the full command is received.

> If your argument is that sending BAD and then immediately closing the
> socket (or sending BAD, then BYE, then closing the socket), without
> bothering the read the literal... saves the server work and resources,
> then maybe it's reasonable advice.

This is not better than just sending BYE.

> But then the advice isn't just to
> send BAD -- it's the whole sequence, together.
> 
> Get what I'm trying to say?
> 
> b
> 
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext
> 

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext