[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Updated draft-ietf-imapext-condstore document
From:       Alexey Melnikov <mel () messagingdirect ! com>
Date:       2003-04-20 5:49:27
[Download RAW message or body]

I've updated the document as per comments from Mark and Cyrus.
New version (draft-ietf-imapext-condstore-01) should appear shortly. In
the meantime, I've attached the diff for the changes.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

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


["00-01.diff.txt" (text/plain)]

--- draft-ietf-imapext-condstore-00.txt	Thu Mar 27 00:27:06 2003
+++ draft-ietf-imapext-condstore-01.txt	Fri Apr 11 23:29:42 2003
@@ -1,7 +1,7 @@
 Internet Draft: IMAP Extension for Conditional STORE          A. Melnikov
-Document: draft-ietf-imapext-condstore-00.txt                     S. Hole
-Expires: September 2003                     ACI WorldWide/MessagingDirect
-                                                               March 2003
+Document: draft-ietf-imapext-condstore-01.txt                     S. Hole
+Expires: October 2003                       ACI WorldWide/MessagingDirect
+                                                               April 2003
 
                IMAP Extension for Conditional STORE operation
 
@@ -43,6 +43,13 @@
 
 0.2. Change History
 
+     Changes from draft-ietf-imapext-condstore-00
+      1.  Dropped "/message" prefix in entry names as per decision in San Francisco.
+      2.  Fixed ABNF for SEARCH and SORT untagged responses.
+      3.  Changed "private" to "priv" to be consistent with ANNOTATE.
+      4.  MODIFIED response code is now returned in OK response, not NO.
+      5.  Added NOMODSEQ response code.
+
      Changes from draft-melnikov-imap-condstore-09:
       1.  Some text clarifications based on suggestions by Harrie Hazewinkel
       2.  Added paragraph about mailbox locking and DOS when conditional STORE
@@ -139,6 +146,7 @@
    4  IMAP Protocol Changes ..................................... X
    4.1 New OK untagged responses for SELECT and EXAMINE ......... X
    4.1.1 HIGHESTMODSEQ response code ............................ X
+   4.1.2 NOMODSEQ response code ................................. X
    4.2 STORE and UID STORE Commands ............................. X
    4.3 MODSEQ message data item in FETCH Command ................ X
    4.4 MODSEQ search criterion in SEARCH ........................ X
@@ -240,13 +248,18 @@
     different metadata items. If the server does so, per message mod-sequence is
     the highest mod-sequence of all metadata items for the specified message.
 
+    The server that supports this extention is not required to be able to store
+    mod-sequences for every available mailbox. Section 4.1.2 describes how
+    the server may act if a particular mailbox doesn't support the persistent
+    storage of mod-sequences.
+
     This extension makes the following changes to the IMAP4 protocol:
 
         a) extends the syntax of the STORE command to allow STORE
            modifiers
 
         b) adds the MODIFIED response code which should be used with
-           a NO response to the STORE command
+           an OK response to the STORE command
 
         c) adds a new MODSEQ message data item for use with the FETCH command
 
@@ -269,13 +282,26 @@
 
 4.1. New OK untagged responses for SELECT and EXAMINE
 
+    This document adds two new response codes HIGHESTMODSEQ and NOMODSEQ.
+    One of those response codes MUST be returned in the OK untagged
+    response for a successful SELECT and EXAMINE commands.
+
+    When opening a mailbox the server must check if the mailbox supports
+    the persistent storage of mod-sequences. If the mailbox supports
+    the persistent storage of mod-sequences and mailbox open operation succeeds,
+    the server MUST send the OK untagged response including HIGHESTMODSEQ
+    response code. If the persistent storage for the mailbox is not supported,
+    the server MUST send the OK untagged response including NOMODSEQ response
+    code instead.
+
+
 4.1.1. HIGHESTMODSEQ response code
 
     This document adds a new response code that is returned in the OK
     untagged response for the SELECT and EXAMINE commands. A server
-    supporting the CONDSTORE extension MUST send the OK untagged
-    response including HIGHESTMODSEQ response code with every successful
-    SELECT or EXAMINE command:
+    supporting the persistent storage of mod-sequences for the mailbox MUST
+    send the OK untagged response including HIGHESTMODSEQ response code with
+    every successful SELECT or EXAMINE command:
 
       OK [HIGHESTMODSEQ <mod-sequence-value>]
 
@@ -307,6 +333,24 @@
                 S: A142 OK [READ-WRITE] SELECT completed
 
 
+4.1.2 NOMODSEQ response code
+
+    A server that doesn't support the persistent storage of mod-sequences for
+    the mailbox MUST send the OK untagged response including NOMODSEQ response
+    code with every successful SELECT or EXAMINE command.
+
+    Example:    C: A142 SELECT INBOX
+                S: * 172 EXISTS
+                S: * 1 RECENT
+                S: * OK [UNSEEN 12] Message 12 is first unseen
+                S: * OK [UIDVALIDITY 3857529045] UIDs valid
+                S: * OK [UIDNEXT 4392] Predicted next UID
+                S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+                S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+                S: * OK [NOMODSEQ] Sorry, this mailbox format doesn't support modsequences
+                S: A142 OK [READ-WRITE] SELECT completed
+
+
 4.2. STORE and UID STORE Commands
 
     Arguments:  message set
@@ -328,8 +372,9 @@
          UNCHANGEDSINCE
             If the mod-sequence of any metadata item specified in the STORE
             operation for any message in the message set is greater than the
-            specified unchangedsince value, then the command fails.
-            On failure, a MODIFIED response code is returned which includes
+            specified unchangedsince value, then the command MUST NOT change
+            any flags. Instead, the server replies with the OK tagged response that
+            includes a MODIFIED response code. The MODIFIED response code includes
             the message set (for STORE) or set of UIDs (for UID STORE)
             of all messages that failed the UNCHANGESINCE test.
 
@@ -337,7 +382,7 @@
 
               C: a101 STORE 7,5,9 (UNCHANGEDSINCE 20000320162338)
                   +FLAGS.SILENT (\Deleted)
-              S: a101 NO [MODIFIED 7,9] Conditional STORE failed
+              S: a101 OK [MODIFIED 7,9] Conditional STORE failed
 
 		   In spite of the failure of the conditional STORE operation
                for message 7, the server continues to process the conditional
@@ -351,7 +396,7 @@
 
               C: a102 STORE 12 (UNCHANGEDSINCE 0)
                   +FLAGS.SILENT ($MDNSent)
-              S: a102 NO [MODIFIED 12] Conditional STORE failed
+              S: a102 OK [MODIFIED 12] Conditional STORE failed
 
             Note: A client trying to atomically change the state of a particular
              flag (or a set of flags) should be prepared to deal with the case
@@ -370,7 +415,7 @@
             Example:
               C: a106 STORE 100:150 (UNCHANGEDSINCE 200212030000000)
                   +FLAGS.SILENT ($Processed)
-              S: a106 NO [MODIFIED 101] Conditional STORE failed
+              S: a106 OK [MODIFIED 101] Conditional STORE failed
              
              the flag $Processed was set on the message 101 ...
               C: a107 NOOP
@@ -560,15 +605,15 @@
              cache. The client may also specify <entry-name> (name of metadata
              item) and <entry-type-req> (type of metadata item) before
              <mod-sequence-valzer>. <entry-type-req> can be one of "shared",
-             "private" or "all". The latter means that the server should use
-             the biggest value among "private" and "shared" modseqs for the
+             "priv" (private) or "all". The latter means that the server should use
+             the biggest value among "priv" and "shared" mod-sequences for the
              metadata item. If the server doesn't store internally separate
              mod-sequences for different flags and annotations, it MUST ignore
              <entry-name> and <entry-type-req>. Otherwise the server should
              use them to narrow down the search.
 
              For a flag <flagname> the corresponding <entry-name> has a form
-             "/message/flags/<flagname>" as defined in [ANNOTATE]. Note, that
+             "/flags/<flagname>" as defined in [ANNOTATE]. Note, that
              the leading "\" character that denotes a system flag has to be
              escaped as per Section 4.3 of [IMAP4], as the <entry-name> uses
              syntax for quoted strings.
@@ -580,14 +625,14 @@
     See also section 4.6.
 
     Example:
-         C: a SEARCH MODSEQ "/message/flags/draft" all 20010320162338
-                     ANNOTATION "/message/comment" "value" "IMAP4"
+         C: a SEARCH MODSEQ "/flags/draft" all 20010320162338
+                     ANNOTATION "/comment" "value" "IMAP4"
          S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 20010917162500)
          S: a OK Search complete
 
             In the above example, the message numbers of any messages
             containing the string "IMAP4" in the "value" attribute of the
-            "/message/comment" entry and having a mod-sequence equal to or
+            "/comment" entry and having a mod-sequence equal to or
             greater than 20010320162338 for the "\Draft" flag are returned in
             the search results.
 
@@ -684,9 +729,6 @@
 
     status-att-req      = status-att / "HIGHESTMODSEQ"
 
-    mailbox-data        =/ "STATUS" SP mailbox SP "("
-                           [status-rsp-info *(SP status-rsp-info)] ")"
-
     status-rsp-info     = status-att SP number /
                           "HIGHESTMODSEQ" SP mod-sequence-value
 
@@ -713,21 +755,22 @@
     search-modseq-ext   = SP entry-name SP entry-type-req
 
     resp-text-code      =/ "HIGHESTMODSEQ" SP mod-sequence-value /
+                           "NOMODSEQ" /
                            "MODIFIED" SP set
 
-    entry-name          = '"' "/message/flags/" attr-flag '"'
+    entry-name          = '"' "/flags/" attr-flag '"'
                           ;; each system or user defined flag <flag>
-                          ;; is mapped to "/message/flags/<flag>".
+                          ;; is mapped to "/flags/<flag>".
                           ;;
                           ;; <entry-name> follows the escape rules used
                           ;; by "quoted" string as described in Section
                           ;; 4.3 of [IMAP4], e.g. for the flag \Seen
                           ;; the corresponding <entry-name> is
-                          ;; "/message/flags/\\seen", and for the flag
+                          ;; "/flags/\\seen", and for the flag
                           ;; $MDNSent, the corresponding <entry-name>
-                          ;; is "/message/flags/$mdnsent".
+                          ;; is "/flags/$mdnsent".
 
-    entry-type-resp     = "private" | "shared"
+    entry-type-resp     = "priv" | "shared"
                           ;; metadata item type
 
     entry-type-req      = entry-type-resp | "all"
@@ -749,8 +792,10 @@
 
 ;;Borrowed from IMAP4rev1 and modified accordingly:
 
-    mailbox-data        =/ "SEARCH" [SP nz-number *(SP nz-number) search_sort_mod_seq] /
-                           "SORT" [SP nz-number *(SP nz-number) search_sort_mod_seq]
+    mailbox-data        =/ "STATUS" SP mailbox SP "("
+                           [status-rsp-info *(SP status-rsp-info)] ")" /
+                           "SEARCH" [1*(SP nz-number) SP search_sort_mod_seq] /
+                           "SORT" [1*(SP nz-number) SP search_sort_mod_seq]
 
     attr-flag           = "\\Answered" / "\\Flagged" / "\\Deleted" /
                           "\\Seen" / "\\Draft" / attr-flag-keyword /
@@ -828,8 +873,8 @@
     interact with ANNOTATE extension and for thorough review of the document.
 
     Authors also acknowledge the feedback provided by Cyrus Daboo, Larry
-    Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen and Timo
-    Sirainen.
+    Greenfield, Chris Newman, Harrie Hazewinkel, Arnt Gulbrandsen Timo
+    Sirainen and Mark Crispin.
 
 
 9. Author's Addresses


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic