New revision of CONDSTORE draft (conditional store)

[Alexey Melnikov <[e-mail]>]

In July I've submitted two revisions of conditional store extension
(CONDSTORE).
Current draft is named draft-melnikov-imap-condstore-02.txt.

Here is the list of changes:
Changes from -01 to -02:
     1.  Added MODTIME data item to STATUS command.
     2.  Added OK untagged response to SELECT/EXAMINE.
     3.  Clarified that MODIFIED response code contains list of UIDs for
          conditional UID STORE and message set for STORE.
     4.  Added per-message modtime.
     5.  Added PERFLAGMODTIME capability.
     6.  Fixed several bugs in examples.
     7.  Added more comments to ABNF.

    Changes from -00 to -01:
     1.  Refreshed the list of Open Issues.
     2.  Changed "attr-name" to "entry-name", because modtime applies to
entry,
           not attribute.
     3.  Added MODTIME untagged response.
     4.  Cleaned up ABNF.
     5.  Added "Acknowledgments" section.
     6.  Fixed some spelling mistakes.

List of open issues:

    1). How specify different UNCHANGESINCE for different flags in the
          same STORE?  Do we want such granularity anyway?

    2). The document assumes that each flag has a corresponding
          ANNOTATE entry. This has to be synchronized with ANNOTATE draft.

    3). "If the "modtime" of any metadata item specified in STORE
         operation for any message in the message set is greater
         than the unchangedsince value, then the store fails with a
         MODIFIED response code that includes message set of all
         messages that failed UNCHANGESINCE test."

        This basically means that server must continue conditional store
          operation to find all messages for which test fails. Is it
          reasonable, or should the text be changed from "all messages" to
          "at least one message".

    4). MODTIME Untagged Response specifies a message set modtime applies
to.
          Can anybody think of a reason why it is a bad idea? Message set
          is not really required, because MODTIME untagged response must
          follow corresponding untagged FETCH responses.
        Should we use UID set instead?

    5). Should SEARCH MODTIME require MODTIME untagged response?

          SEARCH doesn't cause updates, unless they are the result of some
          other operation. However SEARCH MODTIME forces server to read
          modtime, so server can report this information anyway.

    6). Add support for SORT extension?

I've also implemented revision 2 of the draft in our server, so I can share
my experience.

Comments?
__________________________________________
Alexey Melnikov
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone [phone] x357

I speak for myself only, not for my employer.
__________________________________________