Re: [Extra] SPECIAL-USE MAY appear in LIST responses (was: Re: I-D Action: draft-ietf-extra-sieve-special-use-01.txt)

[Bron Gondwana <[e-mail]>]

On Fri, Jul 20, 2018, at 02:00, Ned Freed wrote:
>>> Yes, according to RFC 6154 section 2 special use attributes MAY
>>> appear in> non-extended LIST responses. There's an example of
>>> this in>>> section 5.1.>
> 
>>> However, the fact that this is a MAY makes it effectively useless
>>> since you> can't tell the difference between a case where there
>>> are no>>> special use> attributes assigned and one where the server has simply
>>> elected not>>> to include> these attributes in its responses. And it's expected
>>> that the>>> overwhelming> majority of mailboxes won't have any special use
>>> overwhelming> assigned.> 
>> MAY fricking shmay.
> 
> :)
> 
>> There are clients out there which flat out expect
>> that you return the SPECIAL-USE for an unadorned LIST, and customers>> report your server as buggy if it doesn't do what their client
>> expects.> 
> Well, if that's the case, we have a problem independent of this Sieve> extension. Do we need to at least file an errata on this?

Errata submitted, suggesting s/MAY/SHOULD/ in section 2.

>>> In fact I'd go so far to say that this is a design error. It's
>>> one thing> to want to support existing implementations of
>>> special use>>> attributes, it's> another to be so permissive that a compliant
>>> implementation - one that> supports SPECIAL-USE but not LIST-
>>> EXTENDED - can have no way to>>> determine> what the special use mailboxes are actually present.
> 
>> I'm sure that RFC3501bis (IMAP4rev2) will fix this.
> 
> Which creates a dependency on yet another IMAP extension. Not sure if> this is sufficient.

IMAP4rev2 is already planning to remove all the non-extended responses
to things.  Adding special-use and requiring that it be present in all
responses is totally reasonable within the scope of the other changes.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]