Re: [Extra] I-D Action: draft-ietf-extra-sieve-special-use-01.txt

[Ned Freed <[e-mail]>]

> > In the next step:
> >
> >    Subsequently, when no particular mailbox is of interest (i.e., the
> >    "specialuse_exists" test has no mailbox argument), the client lists
> >    all mailboxes with special-use flags in the two returned personal
> >    namespaces:
> >
> >    C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") RETURN
> > (SPECIAL-USE)
> >    S: * LIST (\Drafts) "/" INBOX/Drafts
> >    S: * LIST (\Trash) "/" INBOX/Trash
> >    S: * LIST (\Sent) "/" INBOX/Sent
> >    S: * LIST (\Archive) "/" Archive/Default
> >
> > It should be noted that this depends on extended list being available.

> True. I thought LIST-EXTENDED is pretty much required for SPECIAL-USE,
> but the specification doesn't actually mention anything like that. Is
> there another way to obtain information on which mailboxes have a
> particular special-use flag assigned?

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

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.

All that said, all I was asking for here was a note saying this depended on
LIST-EXTENDED. Nothing more. (Personally, I don't intend to even bother to
check if it's supported.)

> > However, I think use of SELECT for this purpose is problematic: It's
> > potentially expensive and worse, may cause undesireable state changes.
> > Why
> > not use the MYRIGHTS command to obtain the access rights (and check
> > for "p" or
> > "i") without having to select the mailbox?

> Sure, if the ACL capability is available. I can mention that. If it is
> not available, there is really no alternative to using SELECT, right?

Not as far as I know. But again, the problem is that SELECTing a mailbox
on behalf of a user can change its state, with all that implies. I'd rather
have my implementation fail if ACL isn't present than have a sieve operation
cause a state change.
> > All of which is roundabout way of saying I now think that we may want a
> > capability for specialuse_exists that's separate from
> > "special-use"/:specialuse. Or better still, since we already have the
> > "mailbox"
> > capability for "mailbox access stuff", I think we should require the
> > presence
> > of both "mailbox" and "special-use" capabilities in order to use
> > specialuse_exists.

> Can you clarify this point? I don't see how this leads to requiring the
> mailbox extension.

It doesn't unless we want it to, and I think we want it to. We have this
collection of stuff collected under the mailbox extension that lets sieve peek
at the state of the mailbox. And here we have an extension that consists of two
parts: One extending fileinto and the other adding to things you can peek at.

>From an MTA implementation perspective, these are very distinct things, and
the latter shares a ton of code with the mailbox extension. It therefore
makes sense to me to separate the two and link it to the mailbox extension.

It's really no different than the way SPECIAL-USE and LIST-EXTENDED
interact on the IMAP side of things: Both have to be present for the
RETURN (SPECIAL-USE) stuff to work.

				Ned