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

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Jan 2014 14:00:40 +0100

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Jan 2014 17:41:40 +0000

Hi Eliot,
Mostly agreeing with you, but some corrections below:

On 27/01/2014 13:00, Eliot Lear wrote:
> first, RFC 2683 is not normative (informational).
I don't think this actually matters, but the rest of your argument is 
still valid.
> I am unaware of any
That is very true. This is what happens now.
> the interests of interoperability.
Agreed.
> that document is superceded by a specific option.  As such, this error
Actually, I think I convinced Barry that it is updating RFC 2683.

Best Regards,
Alexey

---

From: "Black, David" <[email-masked]>
Date: Sun, 26 Jan 2014 21:06:53 -0500

Summary:

Minor Issues:

Nits/editorial comments:

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Mon, 27 Jan 2014 09:20:10 -0500

Hi Eliot,

> 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'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:[email-masked]]
> Sent: Monday, January 27, 2014 8:01 AM
> To: Black, David; Alexey Melnikov ([email-masked]);
> [email-masked]; General Area Review Team ([email-masked])
> Cc: Barry Leiba ([email-masked]); [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-qresync-rfc5162bis-09
> 
> Hi Dave,
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 27 Jan 2014 15:59:48 -0500

> 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

...should be added to the section about the line-length limit.  A
sentence or two should do nicely.

Barry

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Jan 2014 21:23:32 +0000

Hi Barry, Dave, and Alexey,

> 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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 27 Jan 2014 21:26:03 +0000

I assume you mean it should include a pointer to that SHOULD, not restate
it as such?

---

From: "Black, David" <[email-masked]>
Date: Mon, 27 Jan 2014 16:42:27 -0500

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-masked]]
Sent: Monday, January 27, 2014 4:26 PM
To: Eliot Lear
Cc: Barry Leiba; Alexey Melnikov; General Area Review Team ([email-masked]); Black, David; [email-masked]; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Hi Barry, Dave, and Alexey,

Eliot

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jan 2014 08:37:07 +0000

> sentence or two should do nicely.

Yes, I agree.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Jan 2014 17:21:40 +0100

Alexey,

>> sentence or two should do nicely.
Then my suggestion is to push out a new version with  some text along
these lines before the teleconference, please (tomorrow would be
ideal).  I will note that I believe this advice to be general in nature
and not limited to this capability, but we certainly can reinforce the
point here, and restate it if/when someone does an update to 3501
(probably when I have grandchildren, I would think).

Eliot

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Jan 2014 18:19:17 +0000

Hi David,

> that servers that implement this extension need to be prepared to cope
I added some text on this issue. It will appear in -10 which I will post 
shortly.
>> Cc: Barry Leiba ([email-masked]);[email-masked];[email-masked]