| < draft-ietf-imapext-annotate-15.txt | draft-ietf-imapext-annotate-16.txt > | |||
|---|---|---|---|---|
| IMAP Extensions Working Group C. Daboo | IMAP Extensions Working Group C. Daboo | |||
| Internet-Draft | Internet-Draft Apple Computer | |||
| Expires: September 29, 2006 R. Gellens | Intended status: Informational R. Gellens | |||
| QUALCOMM Incorporated | Expires: February 2, 2007 QUALCOMM Incorporated | |||
| March 28, 2006 | August 2006 | |||
| IMAP ANNOTATE Extension | IMAP ANNOTATE Extension | |||
| draft-ietf-imapext-annotate-15 | draft-ietf-imapext-annotate-16 | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on September 29, 2006. | This Internet-Draft will expire on February 2, 2007. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| The ANNOTATE extension to the Internet Message Access Protocol | The ANNOTATE extension to the Internet Message Access Protocol | |||
| permits clients and servers to maintain "meta data" for messages, or | permits clients and servers to maintain "meta data" for messages, or | |||
| individual message parts, stored in a mailbox on the server. For | individual message parts, stored in a mailbox on the server. For | |||
| example, this can be used to attach comments and other useful | example, this can be used to attach comments and other useful | |||
| information to a message. It is also possible to attach annotations | information to a message. It is also possible to attach annotations | |||
| to specific parts of a message, so that, for example, they could be | to specific parts of a message, so that, for example, they could be | |||
| marked as seen or important, or a comment added. | marked as seen or important, or a comment added. | |||
| Change History (to be removed prior to publication as an RFC) | Change History (to be removed prior to publication as an RFC) | |||
| Changes from -15 to -16: | ||||
| 1. Updated to rfc 4551 reference. | ||||
| 2. Updated to rfc 4466 reference. | ||||
| 3. Reworded first sentence of 4.2. | ||||
| 4. Added proper description of body part flag meaning. | ||||
| 5. Added text about 0 for size and NIL for value of non-existent | ||||
| entries. | ||||
| 6. Added note about CONDSTORE behavior in 5.5. | ||||
| 7. Reworded first sentence of 5.1 for consistency with base spec | ||||
| elements. | ||||
| 8. Various spelling fixes. | ||||
| Changes from -14 to -15: | Changes from -14 to -15: | |||
| 1. Updated to rfc 4314 reference. | 1. Updated to rfc 4314 reference. | |||
| 2. Removed Content-Language value and reference. | 2. Removed Content-Language value and reference. | |||
| 3. Added statement about experimental status. | 3. Added statement about experimental status. | |||
| 4. Changed to experimental capability name. | 4. Changed to experimental capability name. | |||
| 5. Removed ability to sort on size attribute. | 5. Removed ability to sort on size attribute. | |||
| 6. Expanded abstract. | 6. Expanded abstract. | |||
| Changes from -13 to -14: | Changes from -13 to -14: | |||
| 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' | 1. Changed 'string' formal syntax to 'list-mailbox' and 'astring' | |||
| skipping to change at page 2, line 39 ¶ | skipping to change at page 3, line 4 ¶ | |||
| 10. Prevent use of * and % wildcards in attributes. | 10. Prevent use of * and % wildcards in attributes. | |||
| 11. Only allow "value" attributes in SEARCH. | 11. Only allow "value" attributes in SEARCH. | |||
| 12. Only allow "value" or "size" attributes in SORT. | 12. Only allow "value" or "size" attributes in SORT. | |||
| 13. Removed vendor attributes. | 13. Removed vendor attributes. | |||
| 14. Removed IMAP flags, though the /flags entry path is reserved. | 14. Removed IMAP flags, though the /flags entry path is reserved. | |||
| 15. Added internationalization considerations. | 15. Added internationalization considerations. | |||
| Changes from -12 to -13: | Changes from -12 to -13: | |||
| 1. Sync with change from DC meeting wrt 'r' right for both read and | 1. Sync with change from DC meeting wrt 'r' right for both read and | |||
| write of .priv. | write of .priv. | |||
| 2. Add text about 'n' right being a 'shared flag right' as defined | 2. Add text about 'n' right being a 'shared flag right' as defined | |||
| in 2086upd. | in 2086upd. | |||
| 3. Allow NIL in /<section-part>/flags entries. | 3. Allow NIL in /<section-part>/flags entries. | |||
| 4. Expand abstract to also indicate that annotations can apply on a | 4. Expand abstract to also indicate that annotations can apply on a | |||
| per-body part basis as well as per message. | per-body part basis as well as per message. | |||
| 5. Fix resp-text-code to use nil instead of "NIL". | 5. Fix resp-text-code to use nil instead of "NIL". | |||
| 6. Use double-quotes consistently around ANNOTATESIZE etc. | 6. Use double-quotes consistently around ANNOTATESIZE etc. | |||
| 7. Fix typos. | 7. Fix typos. | |||
| 8. Remove redundant second para of Introduction. | 8. Remove redundant second para of Introduction. | |||
| 9. Added 'Conventions' section with RFC2119 reference.. | 9. Added 'Conventions' section with RFC2119 reference.. | |||
| 10. Describe S:, C: example behaviour in conventions section.. | 10. Describe S:, C: example behavior in conventions section.. | |||
| 11. Clarify that new rights must also be present if only old ACL is | 11. Clarify that new rights must also be present if only old ACL is | |||
| present. | present. | |||
| 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or | 12. Entry/attributes MUST NOT contain consecutive or trailing '/' or | |||
| '.'. | '.'. | |||
| 13. Clarify default charset for content-type text/plain. | 13. Clarify default charset for content-type text/plain. | |||
| 14. Recommend use of utf-8 for all non-ascii text. | 14. Recommend use of utf-8 for all non-ascii text. | |||
| 15. Clarify terminology of ANNOTATESIZE response code. | 15. Clarify terminology of ANNOTATESIZE response code. | |||
| 16. Require servers to return ANNOTATESIZE on SELECT. | 16. Require servers to return ANNOTATESIZE on SELECT. | |||
| 17. Change an example to use UID FETCH for variety. | 17. Change an example to use UID FETCH for variety. | |||
| 18. Clarify what to do about annotations exceeding allowed | 18. Clarify what to do about annotations exceeding allowed | |||
| ANNOTATESIZE when doing copy. | ANNOTATESIZE when doing copy. | |||
| 19. Use ABNFext document for extended SELECT etc. | 19. Use ABNFext document for extended SELECT etc. | |||
| skipping to change at page 4, line 4 ¶ | skipping to change at page 4, line 19 ¶ | |||
| Changes from -09 to -10: | Changes from -09 to -10: | |||
| 1. Added Content-Language value. | 1. Added Content-Language value. | |||
| 2. Added IANA registrations for entries/attributes in this document. | 2. Added IANA registrations for entries/attributes in this document. | |||
| Changes from -08 to -09: | Changes from -08 to -09: | |||
| 1. Fix formatting, ID nits etc. | 1. Fix formatting, ID nits etc. | |||
| 2. Fix subject -> altsubject in examples. | 2. Fix subject -> altsubject in examples. | |||
| 3. Added text to SELECT/EXAMINE optional parameter definition to | 3. Added text to SELECT/EXAMINE optional parameter definition to | |||
| indicate that the option could trigger a global state change or a | indicate that the option could trigger a global state change or a | |||
| mailbox specific change. | mailbox specific change. | |||
| 4. Changed entry/attribute names to be case-sensitive to avoid case | 4. Changed entry/attribute names to be case-sensitive to avoid case | |||
| mapping issues with utf8 text. | mapping issues with utf8 text. | |||
| 5. Clarify COPY interaction to indicate that only the current user's | 5. Clarify COPY interaction to indicate that only the current user's | |||
| '.priv's are copied, not the '.priv's of other users. | '.priv's are copied, not the '.priv's of other users. | |||
| Changes from -07 to -08: | Changes from -07 to -08: | |||
| 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that | 1. ANNOTATESIZE response changed to use "NIL" for a mailbox that | |||
| does not support any type of annotations, and "0" for a mailbox | does not support any type of annotations, and "0" for a mailbox | |||
| that only supports read-only annotations. | that only supports read-only annotations. | |||
| Changes from -06 to -07: | Changes from -06 to -07: | |||
| 1. Added text to state entry and attribute names are always case- | 1. Added text to state entry and attribute names are always case- | |||
| insensitive. | insensitive. | |||
| 2. Removed top-level entry namespace. | 2. Removed top-level entry namespace. | |||
| 3. Added server accept minima for annotation size and count. | 3. Added server accept minima for annotation size and count. | |||
| 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. | 4. Added [ANNOTATE TOOBIG] & [ANNOTATE TOOMANY] response codes. | |||
| 5. Added [ANNOTATESIZE <<n>>] response code. | 5. Added [ANNOTATESIZE <<n>>] response code. | |||
| 6. Added comment on suggested CONDSTORE support. | 6. Added comment on suggested CONDSTORE support. | |||
| 7. Modified append behaviour to account for MULTIAPPEND. | 7. Modified append behavior to account for MULTIAPPEND. | |||
| 8. Tweaked ABNF. | 8. Tweaked ABNF. | |||
| Changes from -05 to -06: | Changes from -05 to -06: | |||
| 1. Split references into Normative and Informative. | 1. Split references into Normative and Informative. | |||
| 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation | 2. Reworked flags to allow IMAP4 flag prefix to appear in annotation | |||
| name. | name. | |||
| 3. Removed smtp-envelope annotation - a future extension can add | 3. Removed smtp-envelope annotation - a future extension can add | |||
| this. | this. | |||
| 4. Changed subject to altsubject. | 4. Changed subject to altsubject. | |||
| 5. Added $MDNSent flag and reference to document. | 5. Added $MDNSent flag and reference to document. | |||
| skipping to change at page 7, line 50 ¶ | skipping to change at page 7, line 50 ¶ | |||
| 7.2.8. /<section-part>/flags/forwarded . . . . . . . . . . . 31 | 7.2.8. /<section-part>/flags/forwarded . . . . . . . . . . . 31 | |||
| 7.3. Attribute Registrations . . . . . . . . . . . . . . . . . 31 | 7.3. Attribute Registrations . . . . . . . . . . . . . . . . . 31 | |||
| 7.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7.3.1. value . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 7.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7.3.2. size . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 8. Internationalization Considerations . . . . . . . . . . . . . 32 | 8. Internationalization Considerations . . . . . . . . . . . . . 32 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 36 | Intellectual Property and Copyright Statements . . . . . . . . . . 35 | |||
| 1. Introduction and Overview | 1. Introduction and Overview | |||
| The ANNOTATE extension is present in any IMAP [RFC3501] | The ANNOTATE extension is present in any IMAP [RFC3501] | |||
| implementation which returns "ANNOTATE-EXPERIMENT-1" as one of the | implementation which returns "ANNOTATE-EXPERIMENT-1" as one of the | |||
| supported capabilities in the CAPABILITY response. | supported capabilities in the CAPABILITY response. | |||
| This extension makes the following changes to the IMAP protocol: | This extension makes the following changes to the IMAP protocol: | |||
| a. adds a new ANNOTATION message data item for use in FETCH | a. adds a new ANNOTATION message data item for use in FETCH | |||
| skipping to change at page 8, line 34 ¶ | skipping to change at page 8, line 34 ¶ | |||
| commands to indicate the maximum size. | commands to indicate the maximum size. | |||
| j. adds a new ACL "bit" for use with the ACL extensions [RFC2086] | j. adds a new ACL "bit" for use with the ACL extensions [RFC2086] | |||
| and [RFC4314] . | and [RFC4314] . | |||
| The data model used for the storage of annotations is based on that | The data model used for the storage of annotations is based on that | |||
| of the Application Configuration Access Protocol [RFC2244]. Note | of the Application Configuration Access Protocol [RFC2244]. Note | |||
| that there is no inheritance in annotations. | that there is no inheritance in annotations. | |||
| If a server supports annotations, then it MUST store all annotation | If a server supports annotations, then it MUST store all annotation | |||
| data permanently, i.e. there is no concept of "session only" | data permanently, i.e. there is no concept of "session only" | |||
| annotations that would correspond to the behaviour of "session" flags | annotations that would correspond to the behavior of "session" flags | |||
| as defined in the IMAP base specification. | as defined in the IMAP base specification. | |||
| In order to provide optimum support for a disconnected client (one | In order to provide optimum support for a disconnected client (one | |||
| that needs to synchronise annotations for use when offline), servers | that needs to synchronize annotations for use when offline), servers | |||
| SHOULD also support the Conditional STORE [I-D.ietf-imapext- | SHOULD also support the Conditional STORE [RFC4551] extension. | |||
| condstore] extension. | ||||
| The rest of this document describes the data model and protocol | The rest of this document describes the data model and protocol | |||
| changes more rigorously. | changes more rigorously. | |||
| 2. Working Group Note on Status | 2. Working Group Note on Status | |||
| The IMAP Extensions Working Group, which produced this specification, | The IMAP Extensions Working Group, which produced this specification, | |||
| has felt it important to first gain implementation experience with | has felt it important to first gain implementation experience with | |||
| this specification before submitting it as a 'proposed standard' for | this specification before submitting it as a 'proposed standard' for | |||
| more general deployment, and therefore suggests that it be published | more general deployment, and therefore suggests that it be published | |||
| skipping to change at page 9, line 44 ¶ | skipping to change at page 9, line 43 ¶ | |||
| such as "value", "size", etc. which contain the properties and data | such as "value", "size", etc. which contain the properties and data | |||
| of the entry. | of the entry. | |||
| The protocol changes to IMAP described below allow a client to access | The protocol changes to IMAP described below allow a client to access | |||
| or change the values of any attributes in any entries in a message | or change the values of any attributes in any entries in a message | |||
| annotation, assuming it has sufficient access rights to do so (see | annotation, assuming it has sufficient access rights to do so (see | |||
| Section 4.4 for specifics). | Section 4.4 for specifics). | |||
| 4.2. Namespace of entries and attributes | 4.2. Namespace of entries and attributes | |||
| Each message annotation is made up of a set of entries. Each entry | A message may contain zero or more annotations, each of which is a | |||
| has a hierarchical name, with each component of the name separated by | single uniquely named entry. Each entry has a hierarchical name, | |||
| a slash ("/"). An entry name MUST NOT contain two consecutive "/" | with each component of the name separated by a slash ("/"). An entry | |||
| characters and MUST NOT end with a "/" character. | name MUST NOT contain two consecutive "/" characters and MUST NOT end | |||
| with a "/" character. | ||||
| Each entry is made up of a set of attributes. Each attribute has a | Each entry is made up of a set of attributes. Each attribute has a | |||
| hierarchical name, with each component of the name separated by a | hierarchical name, with each component of the name separated by a | |||
| period ("."). An attribute name MUST NOT contain two consecutive "." | period ("."). An attribute name MUST NOT contain two consecutive "." | |||
| characters and MUST NOT end with a "." character. | characters and MUST NOT end with a "." character. | |||
| The value of an attribute is "NIL" (has no value), or is a string of | The value of an attribute is "NIL" (has no value), or is a string of | |||
| zero or more octets. | zero or more octets. | |||
| Entry and attribute names MUST NOT contain asterisk ("*") or percent | Entry and attribute names MUST NOT contain asterisk ("*") or percent | |||
| skipping to change at page 11, line 17 ¶ | skipping to change at page 11, line 17 ¶ | |||
| /vendor/<vendor-token> | /vendor/<vendor-token> | |||
| Defines the top-level of entries associated with an entire message | Defines the top-level of entries associated with an entire message | |||
| as created by a particular product of some vendor. These sub- | as created by a particular product of some vendor. These sub- | |||
| entries can be used by vendors to provide client-specific | entries can be used by vendors to provide client-specific | |||
| annotations. The vendor-token MUST be registered with IANA, using | annotations. The vendor-token MUST be registered with IANA, using | |||
| the [RFC2244] vendor subtree registry. | the [RFC2244] vendor subtree registry. | |||
| /<section-part> | /<section-part> | |||
| Defines the top-level of entries associated with a specific body | Defines the top-level of entries associated with a specific body | |||
| part of a message. This entry itself does not contain any | part of a message. This entry itself does not contain any | |||
| attributes. The section-part uses the same numeric part specifier | attributes. The section-part is a numeric part specifier. Its | |||
| syntax as the BODY message data item in the FETCH command | syntax is the same as the section-part ABNF element defined in | |||
| [RFC3501]. The server MUST return a BAD response if the client | [RFC3501]. The server MUST return a BAD response if the client | |||
| uses an incorrect part specifier (either incorrect syntax or a | uses an incorrect part specifier (either incorrect syntax or a | |||
| specifier referring to a non-existent part). The server MUST | specifier referring to a non-existent part). The server MUST | |||
| return a BAD response if the client uses an empty part specifier | return a BAD response if the client uses an empty part specifier | |||
| (which is used in IMAP to represent the entire message). | (which is used in IMAP to represent the entire message). | |||
| /<section-part>/comment | /<section-part>/comment | |||
| Defines a comment or note associated with a specific body part of | Defines a comment or note associated with a specific body part of | |||
| a message. | a message. | |||
| /<section-part>/flags | /<section-part>/flags | |||
| Defines the top-level of entries associated with flag state for a | Defines the top-level of entries associated with flag state for a | |||
| specific body part of a message. All sub-entries are maintained | specific body part of a message. All sub-entries are maintained | |||
| entirely by the client. There is no implicit change to any flag | entirely by the client. There is no implicit change to any flag | |||
| by the server. | by the server. | |||
| /<section-part>/flags/seen | /<section-part>/flags/seen | |||
| This is similar to the IMAP \Seen flag except it applies to | ||||
| only the body part referenced by the entry. | ||||
| /<section-part>/flags/answered | /<section-part>/flags/answered | |||
| This is similar to the IMAP \Answered flag except it applies | ||||
| to only the body part referenced by the entry. | ||||
| /<section-part>/flags/flagged | /<section-part>/flags/flagged | |||
| This is similar to the IMAP \Flagged flag except it applies | ||||
| to only the body part referenced by the entry. | ||||
| /<section-part>/flags/forwarded | /<section-part>/flags/forwarded | |||
| This is similar to the IMAP $Forwarded keyword except it | ||||
| applies to only the body part referenced by the entry. | ||||
| Defines flags for a specific body part of a message. The "value" | Defines flags for a specific body part of a message. The "value" | |||
| attribute of each of the entries described above must be either | attribute of each of the entries described above must be either | |||
| "1", "0" or "NIL". "1" corresponds to the flag being set. | "1", "0" or "NIL". "1" corresponds to the flag being set. | |||
| /<section-part>/vendor/<vendor-token> | /<section-part>/vendor/<vendor-token> | |||
| Defines the top-level of entries associated with a specific body | Defines the top-level of entries associated with a specific body | |||
| part of a message as created by a particular product of some | part of a message as created by a particular product of some | |||
| vendor. This entry can be used by vendors to provide client | vendor. This entry can be used by vendors to provide client | |||
| specific annotations. The vendor-token MUST be registered with | specific annotations. The vendor-token MUST be registered with | |||
| skipping to change at page 12, line 20 ¶ | skipping to change at page 12, line 27 ¶ | |||
| All attribute names implicitly have a ".priv" and a ".shared" suffix | All attribute names implicitly have a ".priv" and a ".shared" suffix | |||
| which maps to private and shared versions of the entry. Searching or | which maps to private and shared versions of the entry. Searching or | |||
| fetching without using either suffix includes both. The client MUST | fetching without using either suffix includes both. The client MUST | |||
| specify either a ".priv" or ".shared" suffix when storing an | specify either a ".priv" or ".shared" suffix when storing an | |||
| annotation or sorting on annotations. | annotation or sorting on annotations. | |||
| value | value | |||
| A string or binary data representing the value of the annotation. | A string or binary data representing the value of the annotation. | |||
| To delete an annotation, the client can store "NIL" into the | To delete an annotation, the client can store "NIL" into the | |||
| value. The content represented by the string is determined by the | value. If the client requests the value attribute for a non- | |||
| existent entry, then the server MUST return "NIL" for the value. | ||||
| The content represented by the string is determined by the | ||||
| content-type used to register the entry (see Section 7.1 for entry | content-type used to register the entry (see Section 7.1 for entry | |||
| registration templates). Where applicable, the registered | registration templates). Where applicable, the registered | |||
| content-type MUST include a charset parameter. Text values SHOULD | content-type MUST include a charset parameter. Text values SHOULD | |||
| use the utf-8 [RFC3629] character set. | use the utf-8 [RFC3629] character set. | |||
| Note that binary data (data which may contain the NULL octet) is | Note that binary data (data which may contain the NULL octet) is | |||
| allowed (e.g. for storing images etc), and this extension uses the | allowed (e.g. for storing images etc), and this extension uses the | |||
| "literal8" syntax element [I-D.melnikov-imap-ext-abnf] to allow | "literal8" syntax element [RFC4466] to allow such data to be | |||
| such data to be written to or read from the server. | written to or read from the server. | |||
| size | size | |||
| The size of the value, in octets. Set automatically by the | The size of the value, in octets. Set automatically by the | |||
| server, read-only to clients. | server, read-only to clients. If the client requests the size | |||
| attribute for a non-existent entry, then the server MUST return | ||||
| "0" (zero) for the size. | ||||
| 4.3. Private versus Shared | 4.3. Private versus Shared | |||
| Some IMAP mailboxes are private, accessible only to the owning user. | Some IMAP mailboxes are private, accessible only to the owning user. | |||
| Other mailboxes are not, either because the owner has set an ACL | Other mailboxes are not, either because the owner has set an ACL | |||
| [RFC4314] which permits access by other users, or because it is a | [RFC4314] which permits access by other users, or because it is a | |||
| shared mailbox. | shared mailbox. | |||
| This raises the issue of shared versus private annotations. | This raises the issue of shared versus private annotations. | |||
| skipping to change at page 13, line 25 ¶ | skipping to change at page 13, line 36 ¶ | |||
| danger in allowing a client to store an annotation without knowing if | danger in allowing a client to store an annotation without knowing if | |||
| it is shared or private. | it is shared or private. | |||
| This document proposes two standard suffixes for all attributes: | This document proposes two standard suffixes for all attributes: | |||
| ".shared" and ".priv". A SEARCH or FETCH command which specifies | ".shared" and ".priv". A SEARCH or FETCH command which specifies | |||
| neither uses both. STORE, APPEND and SORT commands MUST explicitly | neither uses both. STORE, APPEND and SORT commands MUST explicitly | |||
| use ".priv" or ".shared" suffixes. | use ".priv" or ".shared" suffixes. | |||
| If the ANNOTATE extension is present, support for shared annotations | If the ANNOTATE extension is present, support for shared annotations | |||
| in servers is REQUIRED, whilst support for private annotations in | in servers is REQUIRED, whilst support for private annotations in | |||
| servers is OPTIONAL. This recognises the fact that support for | servers is OPTIONAL. This recognizes the fact that support for | |||
| private annotations may introduce significantly more complexity to a | private annotations may introduce significantly more complexity to a | |||
| server in terms of tracking ownership of the annotations, how quota | server in terms of tracking ownership of the annotations, how quota | |||
| is determined for users based on their own annotations etc. Clients | is determined for users based on their own annotations etc. Clients | |||
| that support the ANNOTATE extension MUST handle both shared and | that support the ANNOTATE extension MUST handle both shared and | |||
| private annotations. | private annotations. | |||
| 4.4. Access Control | 4.4. Access Control | |||
| A user needs to have appropriate rights in order to read or write | A user needs to have appropriate rights in order to read or write | |||
| ".priv" or ".shared" annotation values. How those rights are | ".priv" or ".shared" annotation values. How those rights are | |||
| calculated depends on whether the ACL [RFC2086] extension or its | calculated depends on whether the ACL [RFC2086] extension or its | |||
| update [RFC4314] is present or not. If a client attempts to store or | update [RFC4314] is present or not. If a client attempts to store or | |||
| fetch an annotation to which they do not have the appropriate rights, | fetch an annotation to which they do not have the appropriate rights, | |||
| the server MUST respond with a NO response. | the server MUST respond with a NO response. | |||
| When the ACL extension is not present, access to annotation values is | When the ACL extension is not present, access to annotation values is | |||
| governed by the nature of the selected state. In particular whether | governed by the nature of the selected state. In particular whether | |||
| the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE | the mailbox was SELECT'ed or EXAMINE'd in READ-ONLY or READ-WRITE | |||
| mode. | mode. | |||
| When the ACL extension is present, the server MUST recognise the new | When the ACL extension is present, the server MUST recognize the new | |||
| ACL right "n", in addition to the ones defined by the ACL extension | ACL right "n", in addition to the ones defined by the ACL extension | |||
| itself. | itself. | |||
| The "r" right controls both read and write access to ".priv" | The "r" right controls both read and write access to ".priv" | |||
| annotation values. When it is on, access to ".priv" annotations is | annotation values. When it is on, access to ".priv" annotations is | |||
| allowed, when it is off, access to ".priv" annotations is disallowed. | allowed, when it is off, access to ".priv" annotations is disallowed. | |||
| The "r" right controls only the read access for ".shared" annotation | The "r" right controls only the read access for ".shared" annotation | |||
| values. When it is on, ".shared" annotations can be read, when it is | values. When it is on, ".shared" annotations can be read, when it is | |||
| off, ".shared" annotations cannot be read. | off, ".shared" annotations cannot be read. | |||
| skipping to change at page 16, line 15 ¶ | skipping to change at page 16, line 15 ¶ | |||
| 4.5. Access to Standard IMAP Flags and Keywords | 4.5. Access to Standard IMAP Flags and Keywords | |||
| Due to ambiguity of how private and shared values would map to the | Due to ambiguity of how private and shared values would map to the | |||
| base IMAP flag and keyword values, the ANNOTATE extension does not | base IMAP flag and keyword values, the ANNOTATE extension does not | |||
| expose IMAP flags or keywords as entries. However, the /flags | expose IMAP flags or keywords as entries. However, the /flags | |||
| annotation entry is reserved for future use and MUST NOT be used by | annotation entry is reserved for future use and MUST NOT be used by | |||
| clients or servers supporting this extension. | clients or servers supporting this extension. | |||
| Clients that need to implement shared and private "flags" can create | Clients that need to implement shared and private "flags" can create | |||
| their own annotation entries for those, completely bypassing the base | their own annotation entries for those, completely bypassing the base | |||
| IMAP flag/keyword behaviour. | IMAP flag/keyword behavior. | |||
| 5. IMAP Protocol Changes | 5. IMAP Protocol Changes | |||
| 5.1. General Considerations | 5.1. General Considerations | |||
| Servers may be able to offer only a limited level of support for | Servers may be able to offer only a limited level of support for | |||
| annotations in mailboxes, and it is useful for clients to be able to | annotations in mailboxes, and it is useful for clients to be able to | |||
| know what level of support is available. Servers MUST return an | know what level of support is available. Servers MUST return an | |||
| ANNOTATIONS response during the SELECT or EXAMINE command for a | ANNOTATIONS response code during the SELECT or EXAMINE command for a | |||
| mailbox to indicate the level of support. Possible response codes | mailbox to indicate the level of support. Possible data items used | |||
| used with the ANNOTATIONS response are: | with the ANNOTATIONS response code are: | |||
| "NONE" - this indicates that the mailbox being selected does not | "NONE" - this indicates that the mailbox being selected does not | |||
| support annotations at all. Clients MUST NOT attempt to use | support annotations at all. Clients MUST NOT attempt to use | |||
| annotation extensions in commands. | annotation extensions in commands. | |||
| "READ-ONLY" - this indicates that the annotations supported by the | "READ-ONLY" - this indicates that the annotations supported by the | |||
| mailbox cannot be changed by the client. Clients MUST NOT attempt | mailbox cannot be changed by the client. Clients MUST NOT attempt | |||
| to store annotations on any messages in a mailbox with this | to store annotations on any messages in a mailbox with this | |||
| response code. | response code. | |||
| "NOPRIVATE" - this indicates that the server does not support | "NOPRIVATE" - this indicates that the server does not support | |||
| private annotations on the mailbox. Only shared annotations are | private annotations on the mailbox. Only shared annotations are | |||
| supported. Clients SHOULD only attempt to read or store | supported. Clients SHOULD only attempt to read or store | |||
| annotations attributes with the ".shared" suffix. If a client | annotations attributes with the ".shared" suffix. If a client | |||
| uses an attribute with the ".priv" suffix in a FETCH command, then | uses an attribute with the ".priv" suffix in a FETCH command, then | |||
| servers should return the attribute value in the FETCH response as | servers should return the attribute value in the FETCH response as | |||
| "NIL". If a client uses an attribute with the ".priv" suffix in a | "NIL". If a client uses an attribute with the ".priv" suffix in a | |||
| STORE command (or an APPEND command targetted at the mailbox) then | STORE command (or an APPEND command targeted at the mailbox) then | |||
| the server MUST return a NO response. | the server MUST return a NO response. | |||
| numeric values - if servers support writable annotations, then the | numeric values - if servers support writable annotations, then the | |||
| server MUST indicate the maximum size for an annotation value by | server MUST indicate the maximum size for an annotation value by | |||
| providing the maximum size value in the response code. Clients | providing the maximum size value in the response code. Clients | |||
| MUST NOT store annotation values of a size greater than the amount | MUST NOT store annotation values of a size greater than the amount | |||
| indicated by the server. Servers MUST accept a minimum annotation | indicated by the server. Servers MUST accept a minimum annotation | |||
| data size of at least 1024 bytes if annotations can be written. | data size of at least 1024 bytes if annotations can be written. | |||
| In addition the server MAY limit the total number of annotations for | In addition the server MAY limit the total number of annotations for | |||
| a single message. However, the server MUST provide a minimum | a single message. However, the server MUST provide a minimum | |||
| annotation count per message of at least 10. | annotation count per message of at least 10. | |||
| 5.2. ANNOTATE parameter with the SELECT/EXAMINE commands | 5.2. ANNOTATE parameter with the SELECT/EXAMINE commands | |||
| The ANNOTATE extension defines a single optional SELECT parameter | The ANNOTATE extension defines a single optional SELECT parameter | |||
| [I-D.melnikov-imap-ext-abnf] "ANNOTATE", which is used to turn on | [RFC4466] "ANNOTATE", which is used to turn on unsolicited responses | |||
| unsolicited responses for annotations as described in Section 5.4. | for annotations as described in Section 5.4. This optional parameter | |||
| This optional parameter results in a per-mailbox state change, i.e. | results in a per-mailbox state change, i.e. it must be used in each | |||
| it must be used in each SELECT/EXAMINE command in order to be | SELECT/EXAMINE command in order to be effective, irrespective of | |||
| effective, irrespective of whether it was used in a previous SELECT/ | whether it was used in a previous SELECT/EXAMINE during the same | |||
| EXAMINE during the same session. | session. | |||
| Example: | Example: | |||
| C: a SELECT INBOX (ANNOTATE) | C: a SELECT INBOX (ANNOTATE) | |||
| S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) | S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) | |||
| S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft | S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft | |||
| \Deleted \Seen \*)] | \Deleted \Seen \*)] | |||
| S: * 10268 EXISTS | S: * 10268 EXISTS | |||
| S: * 1 RECENT | S: * 1 RECENT | |||
| S: * OK [UNSEEN 10268] | S: * OK [UNSEEN 10268] | |||
| skipping to change at page 19, line 31 ¶ | skipping to change at page 19, line 31 ¶ | |||
| In the above example, the contents of the private "value" | In the above example, the contents of the private "value" | |||
| attributes for the two entries "/comment" and "/altsubject" are | attributes for the two entries "/comment" and "/altsubject" are | |||
| requested by the client and returned by the server. | requested by the client and returned by the server. | |||
| 5.4. ANNOTATION Message Data Item in FETCH Response | 5.4. ANNOTATION Message Data Item in FETCH Response | |||
| The ANNOTATION message data item in the FETCH response displays | The ANNOTATION message data item in the FETCH response displays | |||
| information about annotations in a message. | information about annotations in a message. | |||
| ANNOTATION parenthesised list | ANNOTATION parenthesized list | |||
| The response consists of a list of entries, each of which has a | The response consists of a list of entries, each of which has a | |||
| list of attribute-value pairs. | list of attribute-value pairs. | |||
| Example: | Example: | |||
| C: a FETCH 1 (ANNOTATION (/comment value)) | C: a FETCH 1 (ANNOTATION (/comment value)) | |||
| S: * 1 FETCH (ANNOTATION (/comment | S: * 1 FETCH (ANNOTATION (/comment | |||
| (value.priv "My comment" | (value.priv "My comment" | |||
| value.shared NIL))) | value.shared NIL))) | |||
| skipping to change at page 21, line 12 ¶ | skipping to change at page 21, line 12 ¶ | |||
| ANNOTATION (/comment)) | ANNOTATION (/comment)) | |||
| S: a OK STORE complete | S: a OK STORE complete | |||
| In the above example, an unsolicited ANNOTATION response is | In the above example, an unsolicited ANNOTATION response is | |||
| returned during a STORE command. The unsolicited response | returned during a STORE command. The unsolicited response | |||
| contains only the entry name of the annotation that changed, and | contains only the entry name of the annotation that changed, and | |||
| not its value. | not its value. | |||
| 5.5. ANNOTATION Message Data Item in STORE | 5.5. ANNOTATION Message Data Item in STORE | |||
| ANNOTATION <parenthesised entry-attribute-value list> | ANNOTATION <parenthesized entry-attribute-value list> | |||
| Sets the specified list of entries by adding or replacing the | Sets the specified list of entries by adding or replacing the | |||
| specified attributes with the values provided. Clients can use | specified attributes with the values provided. Clients can use | |||
| "NIL" for values of attributes it wants to remove from entries. | "NIL" for values of attributes it wants to remove from entries. | |||
| The ANNOTATION message data item used with the STORE command has an | The ANNOTATION message data item used with the STORE command has an | |||
| implicit ".SILENT" behaviour. This means the server does not | implicit ".SILENT" behavior. This means the server does not generate | |||
| generate an untagged FETCH in response to the STORE command and | an untagged FETCH in response to the STORE command and assumes that | |||
| assumes that the client updates its own cache if the command | the client updates its own cache if the command succeeds. Though | |||
| succeeds. | note, that if the Conditional STORE extension [RFC4551] is present, | |||
| then an untagged FETCH response with a MODSEQ data item will be | ||||
| returned by the server as required by [RFC4551]. | ||||
| If the server is unable to store an annotation because the size of | If the server is unable to store an annotation because the size of | |||
| its value is too large, the server MUST return a tagged NO response | its value is too large, the server MUST return a tagged NO response | |||
| with a "[ANNOTATE TOOBIG]" response code. | with a "[ANNOTATE TOOBIG]" response code. | |||
| If the server is unable to store a new annotation because the maximum | If the server is unable to store a new annotation because the maximum | |||
| number of allowed annotations has already been reached, the server | number of allowed annotations has already been reached, the server | |||
| MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response | MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response | |||
| code. | code. | |||
| skipping to change at page 23, line 7 ¶ | skipping to change at page 23, line 8 ¶ | |||
| allowed, or if the destination mailbox is of a type that does not | allowed, or if the destination mailbox is of a type that does not | |||
| support annotations or does not support storing of annotations (a | support annotations or does not support storing of annotations (a | |||
| mailbox that returns a "NONE" or "READ-ONLY" response code in its | mailbox that returns a "NONE" or "READ-ONLY" response code in its | |||
| ANNOTATIONS response), or if the destination mailbox cannot support | ANNOTATIONS response), or if the destination mailbox cannot support | |||
| the size of a annotation because it exceeds the ANNOTATIONS value. | the size of a annotation because it exceeds the ANNOTATIONS value. | |||
| Servers MUST NOT copy ".priv" annotation data for users other than | Servers MUST NOT copy ".priv" annotation data for users other than | |||
| the current user. | the current user. | |||
| 5.7. ANNOTATION Message Data Item in APPEND | 5.7. ANNOTATION Message Data Item in APPEND | |||
| ANNOTATION <parenthesised entry-attribute-value list> | ANNOTATION <parenthesized entry-attribute-value list> | |||
| Sets the specified list of entries and attributes in the resulting | Sets the specified list of entries and attributes in the resulting | |||
| message. | message. | |||
| The APPEND command can include annotations for the message being | The APPEND command can include annotations for the message being | |||
| appended via the addition of a new append data item [I-D.melnikov- | appended via the addition of a new append data item [RFC4466]. The | |||
| imap-ext-abnf]. The new data item can also be used with the multi- | new data item can also be used with the multi-append [RFC3502] | |||
| append [RFC3502] extension that allows multiple messages to be | extension that allows multiple messages to be appended via a single | |||
| appended via a single APPEND command. | APPEND command. | |||
| Example: | Example: | |||
| C: a APPEND drafts ANNOTATION (/comment | C: a APPEND drafts ANNOTATION (/comment | |||
| (value.priv "Don't send until I say so")) {310} | (value.priv "Don't send until I say so")) {310} | |||
| S: + Ready for literal data | S: + Ready for literal data | |||
| C: MIME-Version: 1.0 | C: MIME-Version: 1.0 | |||
| ... | ... | |||
| C: | C: | |||
| S: a OK APPEND completed | S: a OK APPEND completed | |||
| skipping to change at page 24, line 45 ¶ | skipping to change at page 24, line 47 ¶ | |||
| Messages are sorted using the values of the <attribute-name> | Messages are sorted using the values of the <attribute-name> | |||
| attributes in the <entry-name> entries. | attributes in the <entry-name> entries. | |||
| Clients MUST provide either the ".priv" or ".shared" suffix to the | Clients MUST provide either the ".priv" or ".shared" suffix to the | |||
| attribute name to ensure that the server knows which specific value | attribute name to ensure that the server knows which specific value | |||
| to sort on. | to sort on. | |||
| Only the "value.priv" and "value.shared" attributes can be used for | Only the "value.priv" and "value.shared" attributes can be used for | |||
| sorting. Clients MUST NOT specify an attribute other than either | sorting. Clients MUST NOT specify an attribute other than either | |||
| "value.priv" or "value.shared". Servers MUST return a BAD response | "value.priv" or "value.shared". Servers MUST return a BAD response | |||
| if the client tries to search any other attribute. | if the client tries to sort on any other attribute. | |||
| When either "value.priv" or "value.shared" is being sorted, the | When either "value.priv" or "value.shared" is being sorted, the | |||
| server MUST use the character set value specified in the SORT command | server MUST use the character set value specified in the SORT command | |||
| to determine the appropriate sort order. | to determine the appropriate sort order. | |||
| Example: | Example: | |||
| C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL | C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL | |||
| S: * SORT 2 3 4 5 1 11 10 6 7 9 8 | S: * SORT 2 3 4 5 1 11 10 6 7 9 8 | |||
| S: a OK Sort complete | S: a OK Sort complete | |||
| skipping to change at page 25, line 28 ¶ | skipping to change at page 25, line 30 ¶ | |||
| As discussed in Section 4.4 this extension adds a new "n" right to | As discussed in Section 4.4 this extension adds a new "n" right to | |||
| the list of rights provided by the ACL extensions [RFC2086] and | the list of rights provided by the ACL extensions [RFC2086] and | |||
| [RFC4314]. | [RFC4314]. | |||
| 6. Formal Syntax | 6. Formal Syntax | |||
| The following syntax specification uses the Augmented Backus-Naur | The following syntax specification uses the Augmented Backus-Naur | |||
| Form (ABNF) notation as specified in [RFC2234]. | Form (ABNF) notation as specified in [RFC2234]. | |||
| Non-terminals referenced but not defined below are as defined by | Non-terminals referenced but not defined below are as defined by | |||
| [RFC3501] with the new definitions in [I-D.melnikov-imap-ext-abnf] | [RFC3501] with the new definitions in [RFC4466] superseding those in | |||
| superseding those in [RFC3501]. | [RFC3501]. | |||
| Except as noted otherwise, all alphabetic characters are case- | Except as noted otherwise, all alphabetic characters are case- | |||
| insensitive. The use of upper or lower case characters to define | insensitive. The use of upper or lower case characters to define | |||
| token strings is for editorial clarity only. Implementations MUST | token strings is for editorial clarity only. Implementations MUST | |||
| accept these strings in a case-insensitive fashion. | accept these strings in a case-insensitive fashion. | |||
| ann-size = "NONE" / | ann-size = "NONE" / | |||
| (("READ-ONLY" / nz-size) | (("READ-ONLY" / nz-size) | |||
| [SP "NOPRIVATE"]) | [SP "NOPRIVATE"]) | |||
| ; response codes indicating the level of | ; response codes indicating the level of | |||
| skipping to change at page 32, line 44 ¶ | skipping to change at page 32, line 44 ¶ | |||
| Contact person: Cyrus Daboo | Contact person: Cyrus Daboo | |||
| email: cyrus@daboo.name | email: cyrus@daboo.name | |||
| 8. Internationalization Considerations | 8. Internationalization Considerations | |||
| Annotations may contain values that include text strings, and both | Annotations may contain values that include text strings, and both | |||
| searching and sorting are possible with annotations. Servers MUST | searching and sorting are possible with annotations. Servers MUST | |||
| follow standard IMAP text normalization, character set conversion and | follow standard IMAP text normalization, character set conversion and | |||
| collation rules when such operations are acarried out, as they would | collation rules when such operations are carried out, as they would | |||
| for other textual fields being searched or sorted on. | for other textual fields being searched or sorted on. | |||
| 9. Security Considerations | 9. Security Considerations | |||
| Annotations whose values are intended to remain private MUST be | Annotations whose values are intended to remain private MUST be | |||
| stored in ".priv" values, and not ".shared" values which may be | stored in ".priv" values, and not ".shared" values which may be | |||
| accessible to other users. | accessible to other users. | |||
| Excluding the above issues the ANNOTATE extension does not raise any | Excluding the above issues the ANNOTATE extension does not raise any | |||
| security considerations that are not present in the base IMAP | security considerations that are not present in the base IMAP | |||
| skipping to change at page 33, line 19 ¶ | skipping to change at page 33, line 19 ¶ | |||
| 10. References | 10. References | |||
| 10.1. Normative References | 10.1. Normative References | |||
| [I-D.ietf-imapext-sort] | [I-D.ietf-imapext-sort] | |||
| Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS | Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS | |||
| PROTOCOL - SORT AND THREAD EXTENSION", | PROTOCOL - SORT AND THREAD EXTENSION", | |||
| draft-ietf-imapext-sort-17 (work in progress), May 2004. | draft-ietf-imapext-sort-17 (work in progress), May 2004. | |||
| [I-D.melnikov-imap-ext-abnf] | ||||
| Daboo, C. and A. Melnikov, "Collected extensions to IMAP4 | ||||
| ABNF", draft-melnikov-imap-ext-abnf-08 (work in progress), | ||||
| January 2006. | ||||
| [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. | [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
| Specifications: ABNF", RFC 2234, November 1997. | Specifications: ABNF", RFC 2234, November 1997. | |||
| [RFC2244] Newman, C. and J. Myers, "ACAP -- Application | [RFC2244] Newman, C. and J. Myers, "ACAP -- Application | |||
| Configuration Access Protocol", RFC 2244, November 1997. | Configuration Access Protocol", RFC 2244, November 1997. | |||
| skipping to change at page 33, line 47 ¶ | skipping to change at page 33, line 42 ¶ | |||
| [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - | [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - | |||
| MULTIAPPEND Extension", RFC 3502, March 2003. | MULTIAPPEND Extension", RFC 3502, March 2003. | |||
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||
| 10646", STD 63, RFC 3629, November 2003. | 10646", STD 63, RFC 3629, November 2003. | |||
| [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", | [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", | |||
| RFC 4314, December 2005. | RFC 4314, December 2005. | |||
| [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 | ||||
| ABNF", RFC 4466, April 2006. | ||||
| 10.2. Informative References | 10.2. Informative References | |||
| [I-D.ietf-imapext-condstore] | [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional | |||
| Melnikov, A. and S. Hole, "IMAP Extension for Conditional | STORE Operation or Quick Flag Changes Resynchronization", | |||
| STORE operation", draft-ietf-imapext-condstore-09 (work in | RFC 4551, June 2006. | |||
| progress), February 2006. | ||||
| Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
| Many thanks to Chris Newman for his detailed comments on the first | Many thanks to Chris Newman for his detailed comments on the first | |||
| draft of this document, and to the participants at the ACAP working | draft of this document, and to the participants at the ACAP working | |||
| dinner in Pittsburgh. The participants of the IMAPext working group | dinner in Pittsburgh. The participants of the IMAPext working group | |||
| made significant contributions to this work. | made significant contributions to this work. | |||
| Authors' Addresses | Authors' Addresses | |||
| Cyrus Daboo | Cyrus Daboo | |||
| Apple Computer, Inc. | ||||
| 1 Infinite Loop | ||||
| Cupertino, CA 95014 | ||||
| USA | ||||
| Email: cyrus@daboo.name | Email: cyrus@daboo.name | |||
| URI: http://www.apple.com/ | ||||
| Randall Gellens | Randall Gellens | |||
| QUALCOMM Incorporated | QUALCOMM Incorporated | |||
| 5775 Morehouse Dr. | 5775 Morehouse Dr. | |||
| San Diego, CA 92121-2779 | San Diego, CA 92121-2779 | |||
| US | US | |||
| Email: randy@qualcomm.com | Email: randy@qualcomm.com | |||
| Intellectual Property Statement | Full Copyright Statement | |||
| Copyright (C) The Internet Society (2006). | ||||
| This document is subject to the rights, licenses and restrictions | ||||
| contained in BCP 78, and except as set forth therein, the authors | ||||
| retain all their rights. | ||||
| This document and the information contained herein are provided on an | ||||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| Intellectual Property | ||||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
| skipping to change at page 36, line 29 ¶ | skipping to change at page 35, line 45 ¶ | |||
| such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
| specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
| http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
| ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
| Disclaimer of Validity | ||||
| This document and the information contained herein are provided on an | ||||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| Copyright Statement | ||||
| Copyright (C) The Internet Society (2006). This document is subject | ||||
| to the rights, licenses and restrictions contained in BCP 78, and | ||||
| except as set forth therein, the authors retain all their rights. | ||||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
| Internet Society. | Administrative Support Activity (IASA). | |||
| End of changes. 43 change blocks. | ||||
| 80 lines changed or deleted | 107 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||