Subject: [lemonade] [Technical Errata Reported] RFC5162 (3323)

From: RFC Errata System <[email-masked]>
Date: Thu, 16 Aug 2012 07:47:07 -0700 (PDT)

The following errata report has been submitted for RFC5162,
"IMAP4 Extensions for Quick Mailbox Resynchronization".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5162&eid=3323

--------------------------------------
Type: Technical
Reported by: Jan Kundrát <[email-masked]>

Section: GLOBAL

Original Text
-------------
The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command
also tells the server that it SHOULD start sending VANISHED responses
(see Section 3.6) instead of EXPUNGE responses.

Corrected Text
--------------
The "ENABLE QRESYNC"/"ENABLE QRESYNC CONDSTORE" command
also tells the server that it MUST start sending VANISHED responses
(see Section 3.6) instead of EXPUNGE responses.

Notes
-----
The explicit allowance for EXPUNGE being sent instead of VANISHED means that clients still have to maintain a full sequence-to-UID mapping, otherwise there is a risk of losing synchronization. Given that QRESYNC itself is an optional extension, I find it hard to imagine a case where the server cannot send a proper VANISHED response.

If this errata gets accepted, it will require rather heavy editing of the document; the notion of EXPUNGE responses being allowed is followed throughout the whole RFC, including the examples.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5162 (draft-ietf-lemonade-reconnect-client-06)
--------------------------------------
Title               : IMAP4 Extensions for Quick Mailbox Resynchronization
Publication Date    : March 2008
Author(s)           : A. Melnikov, D. Cridland, C. Wilson
Category            : PROPOSED STANDARD
Source              : Enhancements to Internet email to support diverse service environments
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Aug 2012 07:56:43 -0700 (PDT)

Leaving aside the issue of whether or not this change is a good idea, this
errata proposes changing a SHOULD to a MUST. It isn't possible to change
compliance language in a specification with an errata - and it should be
obvious why this is so.

The most that can be done here is note this as a possible future revision. As
to whether or not it is appropriate to use the errata system for such, I'll
defer to Barry on that.

				Ned

---

From: Eric Burger <[email-masked]>
Date: Fri, 17 Aug 2012 11:07:51 -0400

The submitter says it themselves:
> If this errata gets accepted, it will require rather heavy editing of the document

That sounds like a revision of the document, not just an editorial errata.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Aug 2012 16:12:38 +0100

> to whether or not it is appropriate to use the errata system for such, I'll
I think the use of SHOULD is correct, because we wanted this behaviour 
to be per mailbox (and not necessarily server wide). So I think a 
different change is needed and I will try to suggest some alternative 
change later on.

I am also open to suggestions on whether people would like me to work on 
a -bis version of this document.

In the meantime I would like to suggest that the erratum remains open 
(and not rejected).

---

From: Jan Kundrát <[email-masked]>
Date: Fri, 17 Aug 2012 17:19:28 +0200

> That sounds like a revision of the document, not just an editorial errata.

Before filing the errata, I wrote a draft proposal [1] (not submitted at 
the time due to the submission form being closed) fixing both of the 
erratas I submitted yesterday. In the subsequent discussion, I was 
pointed to the errata form as the best way to proceed.

I'm obviously very unfamiliar with the process, but I'm just trying to 
fix a real problem with the QRESYNC extension. Going either the way of 
erratas or proceeding though a new revision of the extension are both 
fine by me, and I'll be happy to contribute to the eventual -bis RFC as 
well.

With kind regards,
Jan

[1] http://trojita.flaska.net/draft-imap-qresync-arrived-01.html

-- 
Trojita, a fast e-mail client -- http://trojita.flaska.net/

---

From: Jan Kundrát <[email-masked]>
Date: Fri, 17 Aug 2012 17:26:30 +0200

> different change is needed and I will try to suggest some alternative

(Going just to lemonade for the technical discussion.)

 From how I understand the wording, the "ENABLE QRESYNC" is enough to 
tell the server that it SHOULD send VANISHED instead of EXPUNGE, and 
also the sole reason for why is ENABLE QRESYNC needed at all (because if 
the mailbox was selected previously, one could easily use SELECT ... 
QRESYNC ... to activate this extension and hence indicate that VANISHED 
is expected).

Or is it due to the possibility of having mail stores for which the 
server cannot report UIDs which are expunged *while* the mailbox is 
selected, but can report their sequence numbers just fine? Is that a 
likely scenario?

With kind regards,
Jan

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Aug 2012 16:37:03 +0100

On 17/08/2012 16:19, Jan Kundrát wrote:
> Before filing the errata, I wrote a draft proposal [1] (not submitted 
> at the time due to the submission form being closed) fixing both of 
> the erratas I submitted yesterday. In the subsequent discussion, I was 

Indeed, I encouraged Jan to submit the errata.

> fine by me, and I'll be happy to contribute to the eventual -bis RFC 
> as well.
>
> With kind regards,
> Jan
>

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 17 Aug 2012 19:11:20 +0300

On 17.8.2012, at 18.26, Jan Kundrát wrote:

> From how I understand the wording, the "ENABLE QRESYNC" is enough to tell the server that it SHOULD send VANISHED instead of EXPUNGE, and also the sole reason for why is ENABLE QRESYNC needed at all (because if the mailbox was selected previously, one could easily use SELECT ... QRESYNC ... to activate this extension and hence indicate that VANISHED is expected).
> 
> Or is it due to the possibility of having mail stores for which the server cannot report UIDs which are expunged *while* the mailbox is selected, but can report their sequence numbers just fine? Is that a likely scenario?

I'm guessing the idea was to allow QRESYNC for some mailboxes, but not for others that don't support modseqs. That's reasonable, but I don't really see how a server couldn't be able to send proper VANISHED replies. Or I guess if the server does dummy proxying for some selected mailboxes, but that would also have problems with other extensions.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 17 Aug 2012 12:37:42 -0400

> Before filing the errata, I wrote a draft proposal [1] (not submitted at the
> time due to the submission form being closed) fixing both of the erratas I
> submitted yesterday. In the subsequent discussion, I was pointed to the
> errata form as the best way to proceed.

Ooh, bad advice.  I'm sorry you're caught in the middle of that; you
shouldn't be.  But, yes, the errata system is meant to be used *only*
for things that were truly *errors* in the publishing of the original
spec -- that is, things that would have been considered errors at the
time, but didn't get caught.

This is an issue where you think something should have been done
differently.  You might be right, but it's not for "errata".

What I *should* do is reject this erratum, though I do have the option
of marking it "held for document update", by way of recording the
issue.  We (the IESG) are strongly trying to avoid doing that, because
the errata system isn't mean to be an issue tracker.  So I really
prefer to reject it.

Alexey has asked that I not reject it just yet, so I'll leave it open
for now.  For now.

> I'm obviously very unfamiliar with the process,

I understand, and, as I say, I'm sorry to get you caught up in a silly
"process" thing.  Let's try to move it in the right direction.

> but I'm just trying to fix a
> real problem with the QRESYNC extension. Going either the way of erratas or
> proceeding though a new revision of the extension are both fine by me, and
> I'll be happy to contribute to the eventual -bis RFC as well.

I would like to see Alexey and Jan work on a revision of the RFC,
which we can handle through the appsawg.

Barry, Applications AD

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Aug 2012 09:30:16 -0700 (PDT)

> > If this errata gets accepted, it will require rather heavy editing of the document

Um, that was precisely what I was responding to. "Accepted" has a specific
meaning in the context of errata. And the errata has to be dealt with no matter
what is subsequently done to the document.

That said, I find myself in agreement with Alexey as to how this should be
handled. So I now believe this errata should be rejected on both process and
technical grounds, and an alternate solution to the problem should be
implemented in a document revision.

				Ned

---

From: Jan Kundrát <[email-masked]>
Date: Sat, 18 Aug 2012 15:16:06 +0200

> which we can handle through the appsawg.

I've therefore submitted my earlier draft, it lives on [1].

Please feel free to do anything you deem appropriate with the original 
errata.

With kind regards
Jan

[1] http://datatracker.ietf.org/doc/draft-kundrat-qresync-arrived/