Re: [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09

[Alexey Melnikov <[e-mail]>]

Hi David,

On 27/01/2014 14:20, Black, David wrote:
> Hi Eliot,
>
> Regarding line length:
>
>> As the draft indicates, this is problematic for the two extensions in
>> question. We have discussed this limitation in the working group, and
>> nobody seems to be concerned.  That's due to two factors, I think:
>> first, RFC 2683 is not normative (informational).  I am unaware of any
>> strict line length limitation in RFC 3501, for instance.  Instead, 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.
> The latter two sentences would be good to add to the draft in some form.
>
> My primary concern is what happens if the client sends a rather long
> line to a server that isn't prepared to cope, and the latter sentence
> would address it.  That could be accompanied by some sort of statement
> that servers that implement this extension need to be prepared to cope
> with longer lines.
I added some text on this issue. It will appear in -10 which I will post 
shortly.
> I'll leave the downref as a process concern for you (WG chair) and Barry (AD)
> to work out.
>
> Thanks,
> --David
>
>> -----Original Message-----
>> From: Eliot Lear [mailto:[e-mail]]
>> Sent: Monday, January 27, 2014 8:01 AM
>> To: Black, David; Alexey Melnikov ([e-mail]);
>> [e-mail]; General Area Review Team ([e-mail])
>> Cc: Barry Leiba ([e-mail]);[e-mail];[e-mail]
>> Subject: Re: Gen-ART review of draft-ietf-qresync-rfc5162bis-09
>>
>> Hi Dave,
>>
>> First, thank you for your review.  I personally appreciate to the time
>> you put in to all of your reviews.
>>
>> On 1/27/14, 3:06 AM, Black, David wrote:
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>>
>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>>
>>> Document: draft-ietf-qresync-rfc5162bis-09
>>> Reviewer: David L. Black
>>> Review Date: January 26, 2014
>>> IETF LC End Date: January 27, 2014
>>>
>>> Summary:
>>> This draft is basically ready for publication, but has minor issues that
>>> should be fixed before publication.
>>>
>>> This draft consolidates RFC 4551 (IMAP Conditional STORE) and RFC 5162
>>> (IMAP Quick Mailbox Resynchronization) into a single document and makes
>>> a few minor updates.  It also updates the command line length
>>> recommendation in RFC 2683 to support the longer command lines that
>>> can occur with these extensions.
>>>
>>> As this is an update, I checked the diffs against RFC 4551 and RFC 5162;
>>> they look reasonable.  I found one minor issue that should be relatively
>>> easy to address.
>>>
>>> Minor Issues:
>>>
>>> The command line length change in Section 4 applies to all IMAP commands,
>>> and hence affects old servers, including those that don't implement either
>>> of the extensions in this draft. That raises a backwards compatibility
>>> concern - what happens when a new client sends a > 1000 character command
>>> line to an old server that isn't expecting more than 1000 characters?
>> As the draft indicates, this is problematic for the two extensions in
>> question. We have discussed this limitation in the working group, and
>> nobody seems to be concerned.  That's due to two factors, I think:
>> first, RFC 2683 is not normative (informational).  I am unaware of any
>> strict line length limitation in RFC 3501, for instance.  Instead, 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.
>>
>> This having been said, while the working group has discussed this
>> matter, it would be good to hear any additional voices of concern, in
>> the interests of interoperability.
>>
>> This takes us to your next point:
>>
>>> One possibility would be to apply the larger length recommendation only
>>> after the client determines that the server supports at least one of
>>> these extensions.
>>>
>>> Nits/editorial comments:
>>>
>>> The update to RFC 2683 would be easier to find from the table of contents
>>> if the title of Section 4 were changed to "Long Command Lines (Update to
>>> RFC 2683)".
>>>
>>> idnits 2.13.01 got confused by the command line examples, and flagged a
>>> downref:
>>>
>>>    ** Downref: Normative reference to an Informational RFC: RFC 2683
>>>
>>> That downref appears to be ok and intended, as noted in the shepherd's
>>> writeup.
>> This will be addressed in a forthcoming update.  Barry has "educated" us
>> that really this is NOT an update to RFC2683, where the advice given in
>> that document is superceded by a specific option.  As such, this error
>> will evaporate.
>>
>>