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

[Ned Freed <[e-mail]>]

> > 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.

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