[MORG] Updating morg-special-use with the latest comments

[Barry Leiba <[e-mail]>]

I have a new version of morg-special-use ready to submit.  There's just one
issue that I want to check the resolution on, one posted by Dan Keen here:  
  http://www.ietf.org/mail-archive/web/morg/current/msg00366.html

> This doesn't seem to cover the request in the room:
>
> Proposal: leave CREATE option, don't add any non-metadata way to add 
> special-use tag, define metadata way (registry) to add or change 
> special use tags (if you support METADATA, we will give a reserved 
> item for this function).  No objection in room; adopted.
>
> We've left CREATE (good), but there's no way to alter an existent 
> mailbox to become special use.

As I read Dan's note, he's not happy with the decision to leave this to
METADATA, and NOT to provide a way to change the special-use status of an
existing mailbox, other than through METADATA.  Still, that was the
consensus.

Is that correct?

Assuming that it is, I have the following proposed text to add to
morg-special-use, related to using METADATA here:

4.  IMAP METADATA entry for special-use flags

   If a server supports this extension and the METADATA extension
   [RFC5464], it SHOULD tie the special-use flags for a mailbox to its
   metadata entry "/shared/specialuse".  The value of /shared/specialuse
   is either NIL (if there are no special-use flags for that mailbox) or
   a space-separated list of special-use flags, presented the same way
   they would be presented in the LIST command response.

   Such a server MAY allow the setting of special-use flags through the
   METADATA mechanisms, thereby allowing clients to change the special
   uses of existing mailboxes.  These changes might have side effects,
   as the server automatically adjusts the special uses accordingly,
   just as it might do with CREATE USE, above.  See Section 5.4 for an
   example.

   A server that supports this MUST check the validity of changes to the
   special-use flags that are done through the metadata.  It MUST NOT
   allow a client to set invalid or unsupported flags, nor to create
   conflicting or otherwise invalid situations.


And the example here:

5.4.  Example of using IMAP METADATA to manipulate special-use flags

   This example shows how IMAP METADATA can be used to manipulate
   special-use flags, if the operation is supported on the server.

     ==> Starting point:
     C: t1 LIST "" "%" RETURN (SPECIAL-USE)
     S: * LIST (\Sent) "/" SentMail
     S: * LIST (\Drafts) "/" MyDrafts
     S: * LIST () "/" SavedDrafts
     S: * LIST (\Trash) "/" Trash
     S: t1 OK done

     ==> Demonstrate the connection:
     C: t2 GETMETADATA "MyDrafts" /shared/specialuse
     S: * METADATA "MyDrafts" (/shared/specialuse "\Drafts")
     S: t2 OK done

     ==> Set new use for SavedDrafts; MyDrafts changes automatically:
     C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts")
     S: * METADATA "MyDrafts" (/shared/specialuse NIL)
     S: t3 OK SETMETADATA complete

     ==> Remove special use for SentMail:
     C: t4 SETMETADATA "SentMail" (/shared/specialuse NIL)
     S: t4 OK SETMETADATA complete

     ==> Check the results:
     C: t5 LIST "" "%" RETURN (SPECIAL-USE)
     S: * LIST () "/" SentMail
     S: * LIST () "/" MyDrafts
     S: * LIST (\Drafts) "/" SavedDrafts
     S: * LIST (\Trash) "/" Trash
     S: t5 OK done


Sanity check: does all that look OK?  (I have also added a reference to the
METADATA RFC, and a registration for the metadata entry to the IANA
Considerations section.)

Shall I post a final draft with this, along with the other changes?

Barry