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

[Ned Freed <[e-mail]>]

I have a few observations and comments on this draft.

The sieve language is designed not to be specific to IMAP. However, this
extension seems to specifically tied to IMAP in general and to RFC 6154
in particular. This means there's really no reason not to tighten the
association - in particular, would it not make sense to provide sample
IMAP command sequences to implement the various things in this specification?

This would be quite helpful to implementors, who might otherwise overlook an
important step.

Special use is, in effect, a many-to-many mapping of special use attributes to
mailboxes. That is, mailboxes can have multiple special use attributes and a
given attribute can be associated with multiple mailboxes.

As far as choosing the right mailbox when more than one has the specified
special-use attribute, the draft says "implementations MUST ensure that this
choice is made consistently, so that the same mailbox is used every time."

I don't know how to implement this short of keeping a per-user list of what
mailbox was used for a given special use attribute. And even a list doesn't
guarantee that no least astonishment violations will occur.

Consider: Suppose there's only mailbox for a given special use and I deliver to
it. Then the user adds an additional special use mailbox. No simple selection
criteria, e.g., first alphabetically will work in general in this case, because
I can alway construct an example where the new mailbox beats the old one.

Creation date doesn't work either, because you can add a special use attribute
to an existing, old maibox. Mailboxes can also be deleted and recreated.

You can solve these problems by keeping a list of mailboxes you've used for a
given special use attribute. But this is a royal PITA, and it still doesn't
address sequences like
createa-delivera-createb-deletea-deliverb-deleteb-createa-deliver? 

The bottom line is I think this needs to be relaxed to a SHOULD. It probably
should also be made clear that if a previously used mailbox no longer exists
then the mailbox default from the command is used rather than recreating the
old mailbox. That is, the mailbox explicitly listed in the command wins over
consistency with the past.

The other aspect of the many-many mapping is the fact that a single mailbox can
have multiple special use attributes. The draft supports this in the context of
specialuse_exists but not in the context of fileinto. I think this is fine, but
I want to make sure everyone is happy with this limitation, including the fact
that because of this you won't be able to create mailbox with fileinto with
multiple special use attributes.

Section 3 says:

   If the "mailbox" string argument is omitted, the "specialuse_exists"
   test yields true if all of the following statements are true for each
   of the special-use flags listed in the "special-use-flags" argument:

   a.  at least one mailbox exists in the mail store that has that
       particular special-use flag assigned, and

   b.  that mailbox allows the user in whose context the Sieve script
       runs to "deliver" messages into it.

I'm concerned about a. - the phrase "the mail store" conjures up an image
of searching through folders belonging to millions of users looking for
one that has an ACL allowing the sieve owner to write to it.

I'm pretty sure you don't intend this to cover shared folders, so I suggest
changing the text to say something like:

   a.  at least one mailbox exists in the user's personal namespace
       [NAMESPACE]  that has that particular special-use flag assigned, and

And add the [NAMESPACE] reference pointing at RFC 2342.

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.

The specialuse_exists makes use of an optional positional parameter. I'm
fine with this, but I want to make sure everyone else is, and that we don't
need to switch to something like:

   specialuse_exists [:mailbox <mailbox: string>]
                     <special-use-flags: string-list>

The same point about special use mailboxes being in the user's personal
namespace needs to be reiterated in the fileinto discussion in section 4.

The text and examples showing the interaction of :specialuse with :create seem
to assume that mailboxes won't be created without :create. This assumption is
incorrect; the sieve base specification is quite clear that an implementation
MAY create the specified mailbox if it doesn't exist even if :create isn't
specified. (Our implementation is one that always creates missing mailboxes
specified in fileinto; :create is therefore a no-op.)

I think an implementation that creates by default SHOULD also assign the
special use attribute by default if it able to do so. This should be covered in
the text. A reference to the text about fileinto in RFC 5228 is probably in
order here.

The first example should probably be changed to note that what happens in the
event there's no mailbox with the \Junk attribute and a mailbox named "Spam"
doesn't exist is implementation-dependent.

The second example should be tweaked a bit to make it clear that the effect of 
:create is to make the creation of the mailbox unconditional.

That's it for now.

				Ned