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

From: Pete Resnick <[email-masked]>
Date: Mon, 10 Dec 2012 11:21:54 -0600

(Housekeeping)

Should we be marking this as "Hold for Document Update" at this point, 
or reject it outright?

pr

On 8/17/12 10:12 AM, Alexey Melnikov wrote:
> On 17/08/2012 15:56, Ned Freed wrote:
>> 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.
> 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).
>>> 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: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Dec 2012 15:19:40 +0000

> Should we be marking this as "Hold for Document Update" at this point, 
Sorry for the delay, finally got in touch with Jan to discuss what to do 
here.
Either reject explaining in the rejection note that the issue is valid, 
but the fix is not (and pointing to the new draft). Or "Hold for 
Document Update".
>>> Leaving aside the issue of whether or not this change is a good 
>>> idea, this
>> 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.
>>