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

>>> 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?

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.

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.  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