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

[Ned Freed <[e-mail]>]

> > This, incidentially, is one of those places where providing the actual IMAP
> > commands will be especially valuable: Pointing out that you should use the
> > NAMESPACE extension and if it isn't present, fallback to LIST "" would be very
> > helpful.

> Here's my initial attempt at addressing this point (separate branch in
> Github):

> https://github.com/ietfextra/draft-ietf-extra-sieve-special-use/commit/035a1af6137a383089c8d54cd733238dc2dfebda

> This adds an IMAP example for specialuse_exists.

> What do you think?

The first step seems fine:

   C: A01 NAMESPACE
   S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
   S: A01 OK NAMESPACE command completed

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.

The final step is:

    C: A03 SELECT Archive/Default
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS (\Answered \Deleted \Seen \Draft \*)] Flags permitted.
    S: * 11211 EXISTS
    S: * 3 RECENT
    S: * OK [UIDVALIDITY 1526903163] UIDs valid
    S: * OK [UIDNEXT 11278] Predicted next UID
    S: A03 OK [READ-WRITE] SELECT command completed

There are several issues here.

First, if you're going to use SELECT it's probably worth noting that since
inclusion of [READ-WRITE] for writable mailboxes is a SHOULD in RFC 3501 while
inclusion of [READ-ONLY] for non-writable is a MUST, a writability check really
needs to based on the absence of [READ-ONLY]. (RFC 5490 3.1.a appears incorrect
to me in this regard - should I file an errata?)

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?

And as a bonus, if it's available you could use the just-standardized
LIST-MYRIGHTS extension to piggyback getting the rights while getting the list
of special-use mailboxes.

More generally, this is why documenting the things necessary to implement the
necessary semantics of an extension is helpful - there may be optimizations and
concerns that should be called out lest implementors miss them.

It also helps clarify overall implementation difficulty. And while this
extension may be easy to implement in the Sieve-in-IMAP case, from the
perspective of an MTA/MDA implementation, even if all of the steps can be done
efficiently, there's still the question of IMAP server availability and the
handling of temporary errors.

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.

I also reviewed the rest of the revised draft, and it's looking good. My one
remaining concern is with the handling of multiple mailboxes having the
same special-use flag assigned. The draft currently says:

   More than one mailbox in the user's personal namespace can have a
   particular special-use flag assigned.  In case of such ambiguity, the
   mailbox that is chosen for delivery is implementation-defined.
   However, while the set of mailboxes to which the involved special-use
   flags are assigned remains unchanged, implementations MUST ensure
   that the mailbox choice is made consistently, so that the same
   mailbox is used every time.  Conversely, the chosen mailbox MAY
   change once the special-use flag assignments that are relevant for
   the mailbox choice are changed (usually by user interaction).

I don't see a way I can reasonably implement this MUST via IMAP unless the 
IMAP server always returns the list of special-use mailboxes in the same order.
Sure, I can cache the user/special-use-attribute/actual-mailbox-list tuple
somewhere, but caches can always be lost. And mailbox metadata is (a)
Potentially much too expensive and (b) Subject to the vagarities of user
actions.

I'm not happy about it, but I think this needs to become a SHOULD.

Another possibility is to use the default mailbox name as a means of
disambiguating multiple mailboxes with the same special-use attribute:
If the default mailbox is one of these deliver to it preferentially,
otherwise the behavior is implementation-defined. Not perfect, but it
provides a bit more consistent behavior that's easily achievable.

Aside from these issues, this draft looks good to go to me.

				Ned