I don't quite see the details in RFC 3501. I think what's going on is that:
A server implementation that uses a shorter command line length limit than this recommendation could clip a longer client command line at the server's line length limit. This SHOULD result in a syntax error (e.g., due to the server not finding a CRLF at the end of the clipped command line) that causes the server to return a BAD response, as specified in RFC 3501. Thanks, --David From: Dave Cridland [mailto:[email protected]] Sent: Monday, January 27, 2014 4:26 PM To: Eliot Lear Cc: Barry Leiba; Alexey Melnikov; General Area Review Team ([email protected]); Black, David; [email protected]; [email protected]; [email protected] Subject: Re: [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09 I assume you mean it should include a pointer to that SHOULD, not restate it as such? On Mon, Jan 27, 2014 at 9:23 PM, Eliot Lear <[email protected]<mailto:[email protected]>> wrote: Hi Barry, Dave, and Alexey, On 1/27/14, 8:59 PM, Barry Leiba wrote: >> Actually, I think I convinced Barry that it is updating RFC 2683. > Yes: because the new line-length-limit recommendation is meant to > apply whether or not condstore or qresync are in play, this "updates" > remains (it's the others that used to be there that we scrubbed). > > I think David's right that some version of what Eliot said: > >> there >> is a requirement for strict syntax parsing. If the client blows it in >> any way, the server SHOULD return an error with a BAD response. > ...should be added to the section about the line-length limit. A > sentence or two should do nicely. > > I don't see a problem, but for context I was really just borrowing from RFC 3501, which already states that SHOULD (Section 2.2 if memory serves). Stating it again won't hurt. Eliot
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
