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. From: Dave Cridland [mailto:dave@xxxxxxxxxxxx]
Sent: Monday, January 27, 2014 4:26 PM
To: Eliot Lear
Cc: Barry Leiba; Alexey Melnikov; General Area Review Team (gen-art@xxxxxxxx); Black, David; dcridland@xxxxxxxxxx; imapext@xxxxxxxx; ietf@xxxxxxxx
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@xxxxxxxxx> 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 |