Subject: [MORG] [Editorial Errata Reported] RFC6154 (5431)

From: RFC Errata System <[email-masked]>
Date: Thu, 19 Jul 2018 14:43:12 -0700 (PDT)

The following errata report has been submitted for RFC6154,
"IMAP LIST Extension for Special-Use Mailboxes".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5431

--------------------------------------
Type: Editorial
Reported by: Bron Gondwana <[email-masked]>

Section: 2

Original Text
-------------
An IMAP server that supports this extension MAY include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

Corrected Text
--------------
An IMAP server that supports this extension SHOULD include any or all of
the following attributes in responses to the non-extended IMAP LIST
command.

Notes
-----
There exist clients which send a non-extended LIST command and will correctly display and interact with mailboxes usefully if their special-uses are given in the response.

Because of this, many servers are already replying with the special-use attributes, and there are no known reports of clients being broken by that behaviour.  Because of this, the MAY should be raised to a SHOULD, and server implementations should default to turning this on.

Instructions:
-------------
This erratum 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  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6154 (draft-ietf-morg-list-specialuse-06)
--------------------------------------
Title               : IMAP LIST Extension for Special-Use Mailboxes
Publication Date    : March 2011
Author(s)           : B. Leiba, J. Nicolson
Category            : PROPOSED STANDARD
Source              : Message Organization
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Jul 2018 18:26:03 -0400

> There exist clients which send a non-extended LIST command and will

> correctly display and interact with mailboxes usefully if their

> special-uses are given in the response.

> Because of this, many servers are already replying with the special-use

> attributes, and there are no known reports of clients being broken by

> that behaviour.  Because of this, the MAY should be raised to a SHOULD,

> and server implementations should default to turning this on.

That may (ahem) be true now, but the document says exactly what we intended
it to say when it was written.

Alexey, please mark this report REJECTED.

Barry

On Thu, Jul 19, 2018 at 5:51 PM RFC Errata System <[email-masked]>
wrote:

> There exist clients which send a non-extended LIST command and will
> correctly display and interact with mailboxes usefully if their
> special-uses are given in the response.
>
> Because of this, many servers are already replying with the special-use
> attributes, and there are no known reports of clients being broken by that
> behaviour.  Because of this, the MAY should be raised to a SHOULD, and
> server implementations should default to turning this on.
>
> Instructions:
> -------------
-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 20 Jul 2018 08:33:29 +1000

Fair enough! Is there a better way to say "if you're implementing now,
please do this to get best interop"?

On Fri, Jul 20, 2018, at 08:26, Barry Leiba wrote:
> > There exist clients which send a non-extended LIST command and will> > correctly display and interact with mailboxes usefully if their

> > Because of this, many servers are already replying with the
> > special-use> > attributes, and there are no known reports of clients being
> > broken by> > that behaviour.  Because of this, the MAY should be raised to a
> > SHOULD,> > and server implementations should default to turning this on.

> That may (ahem) be true now, but the document says exactly what we
> intended it to say when it was written.> 

> On Thu, Jul 19, 2018 at 5:51 PM RFC Errata System <rfc-editor@rfc-
> editor.org> wrote:>> The following errata report has been submitted for RFC6154,
>>  An IMAP server that supports this extension MAY include any or
>>  all of>>  the following attributes in responses to the non-extended IMAP LIST>>  command.
>> 
>>  Corrected Text
>>  --------------
>>  An IMAP server that supports this extension SHOULD include any or
>>  all of>>  the following attributes in responses to the non-extended IMAP LIST>>  command.
>> 
>>  Notes
>>  -----
>>  correctly display and interact with mailboxes usefully if their special-
>>  uses are given in the response.>> 
>>  Because of this, many servers are already replying with the special-
>>  use attributes, and there are no known reports of clients being
>>  broken by that behaviour.  Because of this, the MAY should be raised
>>  to a SHOULD, and server implementations should default to turning
>>  this on.>> 
>>  Instructions:
>>  -------------
>>  This erratum is currently posted as "Reported". If necessary, please>>  use "Reply All" to discuss whether it should be verified or
>>  can log in to change the status and edit the report, if necessary.>> 
>>  Title               : IMAP LIST Extension for Special-Use Mailboxes>>  Publication Date    : March 2011

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Jul 2018 18:40:17 -0400

Write an update RFC.  Or we’ll put it into rev4.2

On Thu, Jul 19, 2018 at 6:33 PM Bron Gondwana <[email-masked]>
wrote:

> intended it to say when it was written.
>
>
> On Thu, Jul 19, 2018 at 5:51 PM RFC Errata System <
> [email-masked]> wrote:
>
Barry

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Jul 2018 15:36:31 -0700 (PDT)

> Alexey, please mark this report REJECTED.

The existence of such clients is not really the issue, although it's what makes
the issue a pressing matter. Rather, the issue is that the semantics provided by
the specification provide no reliable way to obtain special use information,
and thus cannot be said to provide a minimum level of interoperability. In
particular:

(1) SPECIAL-USE does not require LIST-EXTENDED be implemented.

(2) The MAY on returning special use attributes as part of unextended LIST
    means that there's no way to distinguish between the (common) case of
    no special use attributes being set and LIST not supporting returning
    such attributes.

(3) The METADATA approach of deteching special use attributes is also
    optional.

Now, I'm all for supporting existing implementations, but IMO this goes
too far. And the simplest way to fix it is to change the MAY.

It's also easy to see why clients are simply assuming unextended LIST returns
this information regardless of what the standard says. As a client implementer
myself in this case (since I'm implementing the Sieve specialuse extension
using IMAP) I'm going to assume LIST-EXTENDED is available and fail if it
isn't, but I can't say what I'm doing is really any better.

				Ned