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:dave(_at_)cridland(_dot_)net]
Sent: Monday, January 27, 2014 4:26 PM
To: Eliot Lear
Cc: Barry Leiba; Alexey Melnikov; General Area Review Team
(gen-art(_at_)ietf(_dot_)org); Black, David; dcridland(_at_)arcode(_dot_)com;
imapext(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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
<lear(_at_)cisco(_dot_)com<mailto:lear(_at_)cisco(_dot_)com>> 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