You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ba...@apache.org on 2006/07/29 15:16:01 UTC
svn commit: r426798 [11/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2060.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2086.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2086.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2086.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2086.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,452 @@
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 2086 Carnegie Mellon
+Category: Standards Track January 1997
+
+
+ IMAP4 ACL extension
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ The ACL extension of the Internet Message Access Protocol [IMAP4]
+ permits access control lists to be manipulated through the IMAP
+ protocol.
+
+Table of Contents
+
+ 1. Abstract............................................... 1
+ 2. Conventions Used in this Document...................... 1
+ 3. Introduction and Overview.............................. 2
+ 4. Commands............................................... 3
+ 4.1. SETACL................................................. 3
+ 4.2. DELETEACL.............................................. 4
+ 4.3. GETACL................................................. 4
+ 4.4. LISTRIGHTS............................................. 4
+ 4.5. MYRIGHTS............................................... 5
+ 5. Responses.............................................. 5
+ 5.1. ACL.................................................... 5
+ 5.2. LISTRIGHTS............................................. 6
+ 5.3. MYRIGHTS............................................... 6
+ 6. Formal Syntax.......................................... 6
+ 7. References............................................. 7
+ 8. Security Considerations................................ 7
+ 9. Author's Address....................................... 8
+
+2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+
+
+
+
+
+Myers Standards Track [Page 1]
+
+RFC 2086 ACL extension January 1997
+
+
+3. Introduction and Overview
+
+ The ACL extension is present in any IMAP4 implementation which
+ returns "ACL" as one of the supported capabilities to the CAPABILITY
+ command.
+
+ An access control list is a set of <identifier,rights> pairs.
+
+ Identifier is a US-ASCII string. The identifier anyone is reserved
+ to refer to the universal identity (all authentications, including
+ anonymous). All user name strings accepted by the LOGIN or
+ AUTHENTICATE commands to authenticate to the IMAP server are reserved
+ as identifiers for the corresponding user. Identifiers starting with
+ a dash ("-") are reserved for "negative rights", described below.
+ All other identifier strings are interpreted in an implementation-
+ defined manner.
+
+ Rights is a string listing a (possibly empty) set of alphanumeric
+ characters, each character listing a set of operations which is being
+ controlled. Letters are reserved for ``standard'' rights, listed
+ below. The set of standard rights may only be extended by a
+ standards-track document. Digits are reserved for implementation or
+ site defined rights. The currently defined standard rights are:
+
+ l - lookup (mailbox is visible to LIST/LSUB commands)
+ r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL,
+ SEARCH, COPY from mailbox)
+ s - keep seen/unseen information across sessions (STORE SEEN flag)
+ w - write (STORE flags other than SEEN and DELETED)
+ i - insert (perform APPEND, COPY into mailbox)
+ p - post (send mail to submission address for mailbox,
+ not enforced by IMAP4 itself)
+ c - create (CREATE new sub-mailboxes in any implementation-defined
+ hierarchy)
+ d - delete (STORE DELETED flag, perform EXPUNGE)
+ a - administer (perform SETACL)
+
+ An implementation may tie rights together or may force rights to
+ always or never be granted to particular identifiers. For example,
+ in an implementation that uses unix mode bits, the rights "wisd" are
+ tied, the "a" right is always granted to the owner of a mailbox and
+ is never granted to another user. If rights are tied in an
+ implementation, the implementation must be conservative in granting
+ rights in response to SETACL commands--unless all rights in a tied
+ set are specified, none of that set should be included in the ACL
+ entry for that identifier. A client may discover the set of rights
+ which may be granted to a given identifier in the ACL for a given
+ mailbox by using the LISTRIGHTS command.
+
+
+
+Myers Standards Track [Page 2]
+
+RFC 2086 ACL extension January 1997
+
+
+ It is possible for multiple identifiers in an access control list to
+ apply to a given user (or other authentication identity). For
+ example, an ACL may include rights to be granted to the identifier
+ matching the user, one or more implementation-defined identifiers
+ matching groups which include the user, and/or the identifier
+ "anyone". How these rights are combined to determine the user's
+ access is implementation-defined. An implementation may choose, for
+ example, to use the union of the rights granted to the applicable
+ identifiers. An implementation may instead choose, for example, to
+ only use those rights granted to the most specific identifier present
+ in the ACL. A client may determine the set of rights granted to the
+ logged-in user for a given mailbox by using the MYRIGHTS command.
+
+ When an identifier in an ACL starts with a dash ("-"), that indicates
+ that associated rights are to be removed from the identifier that is
+ prefixed by the dash. For example, if the identifier "-fred" is
+ granted the "w" right, that indicates that the "w" right is to be
+ removed from users matching the identifier "fred". Implementations
+ need not support having identifiers which start with a dash in ACLs.
+
+4. Commands
+
+4.1. SETACL
+
+ Arguments: mailbox name
+ authentication identifier
+ access right modification
+
+ Data: no specific data for this command
+
+ Result: OK - setacl completed
+ NO - setacl failure: can't set acl
+ BAD - command unknown or arguments invalid
+
+ The SETACL command changes the access control list on the
+ specified mailbox so that the specified identifier is granted
+ permissions as specified in the third argument.
+
+ The third argument is a string containing an optional plus ("+")
+ or minus ("-") prefix, followed by zero or more rights characters.
+ If the string starts with a plus, the following rights are added
+ to any existing rights for the identifier. If the string starts
+ with a minus, the following rights are removed from any existing
+ rights for the identifier. If the string does not start with a
+ plus or minus, the rights replace any existing rights for the
+ identifier.
+
+
+
+
+
+Myers Standards Track [Page 3]
+
+RFC 2086 ACL extension January 1997
+
+
+4.2. DELETEACL
+
+ Arguments: mailbox name
+ authentication identifier
+
+ Data: no specific data for this command
+
+ Result: OK - deleteacl completed
+ NO - deleteacl failure: can't delete acl
+ BAD - command unknown or arguments invalid
+
+ The DELETEACL command removes any <identifier,rights> pair for the
+ specified identifier from the access control list for the specified
+ mailbox.
+
+4.3. GETACL
+
+ Arguments: mailbox name
+
+ Data: untagged responses: ACL
+
+ Result: OK - getacl completed
+ NO - getacl failure: can't get acl
+ BAD - command unknown or arguments invalid
+
+ The GETACL command returns the access control list for mailbox in
+ an untagged ACL reply.
+
+ Example: C: A002 GETACL INBOX
+ S: * ACL INBOX Fred rwipslda
+ S: A002 OK Getacl complete
+
+4.4. LISTRIGHTS
+
+ Arguments: mailbox name
+ authentication identifier
+
+ Data: untagged responses: LISTRIGHTS
+
+ Result: OK - listrights completed
+ NO - listrights failure: can't get rights list
+ BAD - command unknown or arguments invalid
+
+ The LISTRIGHTS command takes a mailbox name and an identifier and
+ returns information about what rights may be granted to the identifier
+ in the ACL for the mailbox.
+
+
+
+
+
+Myers Standards Track [Page 4]
+
+RFC 2086 ACL extension January 1997
+
+
+ Example: C: a001 LISTRIGHTS ~/Mail/saved smith
+ S: * LISTRIGHTS ~/Mail/saved smith la r swicd
+ S: a001 OK Listrights completed
+
+
+ C: a005 LISTRIGHTS archive.imap anyone
+ S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a
+ 0 1 2 3 4 5 6 7 8 9
+
+4.5. MYRIGHTS
+
+ Arguments: mailbox name
+
+ Data: untagged responses: MYRIGHTS
+
+ Result: OK - myrights completed
+ NO - myrights failure: can't get rights
+ BAD - command unknown or arguments invalid
+
+ The MYRIGHTS command returns the set of rights that the user has
+ to mailbox in an untagged MYRIGHTS reply.
+
+ Example: C: A003 MYRIGHTS INBOX
+ S: * MYRIGHTS INBOX rwipslda
+ S: A003 OK Myrights complete
+
+5. Responses
+
+5.1. ACL
+
+ Data: mailbox name
+ zero or more identifier rights pairs
+
+ The ACL response occurs as a result of a GETACL command. The first
+ string is the mailbox name for which this ACL applies. This is
+ followed by zero or more pairs of strings, each pair contains the
+ identifier for which the entry applies followed by the set of
+ rights that the identifier has.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 5]
+
+RFC 2086 ACL extension January 1997
+
+
+5.2. LISTRIGHTS
+
+ Data: mailbox name
+ identifier
+ required rights
+ list of optional rights
+
+ The LISTRIGHTS response occurs as a result of a LISTRIGHTS
+ command. The first two strings are the mailbox name and identifier
+ for which this rights list applies. Following the identifier is a
+ string containing the (possibly empty) set of rights the
+ identifier will always be granted in the mailbox.
+
+ Following this are zero or more strings each containing a set of
+ rights the identifier may be granted in the mailbox. Rights
+ mentioned in the same string are tied together--either all must be
+ granted to the identifier in the mailbox or none may be granted.
+
+ The same right may not be listed more than once in the LISTRIGHTS
+ command.
+
+5.3. MYRIGHTS
+
+ Data: mailbox name
+ rights
+
+ The MYRIGHTS response occurs as a result of a MYRIGHTS command.
+ The first string is the mailbox name for which these rights apply.
+ The second string is the set of rights that the client has.
+
+6. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+ Non-terminals referenced but not defined below are as defined by
+ [IMAP4].
+
+ Except as noted otherwise, all alphabetic characters are case-
+ insensitive. The use of upper or lower case characters to define
+ token strings is for editorial clarity only. Implementations MUST
+ accept these strings in a case-insensitive fashion.
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 6]
+
+RFC 2086 ACL extension January 1997
+
+
+ acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE
+ rights)
+
+ deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier
+
+ getacl ::= "GETACL" SPACE mailbox
+
+ identifier ::= astring
+
+ listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
+
+ listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
+ SPACE rights *(SPACE rights)
+
+ mod_rights ::= astring
+ ;; +rights to add, -rights to remove
+ ;; rights to replace
+
+ myrights ::= "MYRIGHTS" SPACE mailbox
+
+ myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights
+
+ rights ::= astring
+
+ setacl ::= "SETACL" SPACE mailbox SPACE identifier
+ SPACE mod_rights
+
+7. References
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+ RFC 1730, University of Washington, December 1994.
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822.
+
+8. Security Considerations
+
+ An implementation must make sure the ACL commands themselves do not
+ give information about mailboxes with appropriately restricted ACL's.
+ For example, a GETACL command on a mailbox for which the user has
+ insufficient rights should not admit the mailbox exists, much less
+ return the mailbox's ACL.
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 7]
+
+RFC 2086 ACL extension January 1997
+
+
+9. Author's Address
+
+ John G. Myers
+ Carnegie-Mellon University
+ 5000 Forbes Ave.
+ Pittsburgh PA, 15213-3890
+
+ Email: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 8]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2086.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2087.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2087.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2087.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2087.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,284 @@
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 2087 Carnegie Mellon
+Category: Standards Track January 1997
+
+
+ IMAP4 QUOTA extension
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ The QUOTA extension of the Internet Message Access Protocol [IMAP4]
+ permits administrative limits on resource usage (quotas) to be
+ manipulated through the IMAP protocol.
+
+Table of Contents
+
+ 1. Abstract........................................... 1
+ 2. Conventions Used in this Document.................. 1
+ 3. Introduction and Overview.......................... 2
+ 4. Commands........................................... 2
+ 4.1. SETQUOTA Command................................... 2
+ 4.2. GETQUOTA Command................................... 2
+ 4.3. GETQUOTAROOT Command............................... 3
+ 5. Responses.......................................... 3
+ 5.1. QUOTA Response..................................... 3
+ 5.2. QUOTAROOT Response................................. 4
+ 6. Formal syntax...................................... 4
+ 7. References......................................... 5
+ 8. Security Considerations............................ 5
+ 9. Author's Address................................... 5
+
+
+2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 1]
+
+RFC 2087 QUOTA January 1997
+
+
+3. Introduction and Overview
+
+ The QUOTA extension is present in any IMAP4 implementation which
+ returns "QUOTA" as one of the supported capabilities to the
+ CAPABILITY command.
+
+ An IMAP4 server which supports the QUOTA capability may support
+ limits on any number of resources. Each resource has an atom name
+ and an implementation-defined interpretation which evaluates to an
+ integer. Examples of such resources are:
+
+ Name Interpretation
+
+ STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets
+ MESSAGE Number of messages
+
+
+ Each mailbox has zero or more implementation-defined named "quota
+ roots". Each quota root has zero or more resource limits. All
+ mailboxes that share the same named quota root share the resource
+ limits of the quota root.
+
+ Quota root names do not necessarily have to match the names of
+ existing mailboxes.
+
+4. Commands
+
+4.1. SETQUOTA Command
+
+ Arguments: quota root
+ list of resource limits
+
+ Data: untagged responses: QUOTA
+
+ Result: OK - setquota completed
+ NO - setquota error: can't set that data
+ BAD - command unknown or arguments invalid
+
+ The SETQUOTA command takes the name of a mailbox quota root and a
+ list of resource limits. The resource limits for the named quota root
+ are changed to be the specified limits. Any previous resource limits
+ for the named quota root are discarded.
+
+ If the named quota root did not previously exist, an implementation
+ may optionally create it and change the quota roots for any number of
+ existing mailboxes in an implementation-defined manner.
+
+
+
+
+
+Myers Standards Track [Page 2]
+
+RFC 2087 QUOTA January 1997
+
+
+ Example: C: A001 SETQUOTA "" (STORAGE 512)
+ S: * QUOTA "" (STORAGE 10 512)
+ S: A001 OK Setquota completed
+
+4.2. GETQUOTA Command
+
+ Arguments: quota root
+
+ Data: untagged responses: QUOTA
+
+ Result: OK - getquota completed
+ NO - getquota error: no such quota root, permission
+ denied
+ BAD - command unknown or arguments invalid
+
+ The GETQUOTA command takes the name of a quota root and returns the
+ quota root's resource usage and limits in an untagged QUOTA response.
+
+ Example: C: A003 GETQUOTA ""
+ S: * QUOTA "" (STORAGE 10 512)
+ S: A003 OK Getquota completed
+
+4.3. GETQUOTAROOT Command
+
+ Arguments: mailbox name
+
+ Data: untagged responses: QUOTAROOT, QUOTA
+
+ Result: OK - getquota completed
+ NO - getquota error: no such mailbox, permission denied
+ BAD - command unknown or arguments invalid
+
+ The GETQUOTAROOT command takes the name of a mailbox and returns the
+ list of quota roots for the mailbox in an untagged QUOTAROOT
+ response. For each listed quota root, it also returns the quota
+ root's resource usage and limits in an untagged QUOTA response.
+
+ Example: C: A003 GETQUOTAROOT INBOX
+ S: * QUOTAROOT INBOX ""
+ S: * QUOTA "" (STORAGE 10 512)
+ S: A003 OK Getquota completed
+
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 3]
+
+RFC 2087 QUOTA January 1997
+
+
+5. Responses
+
+5.1. QUOTA Response
+
+ Data: quota root name
+ list of resource names, usages, and limits
+
+ This response occurs as a result of a GETQUOTA or GETQUOTAROOT
+ command. The first string is the name of the quota root for which
+ this quota applies.
+
+ The name is followed by a S-expression format list of the resource
+ usage and limits of the quota root. The list contains zero or
+ more triplets. Each triplet conatins a resource name, the current
+ usage of the resource, and the resource limit.
+
+ Resources not named in the list are not limited in the quota root.
+ Thus, an empty list means there are no administrative resource
+ limits in the quota root.
+
+ Example: S: * QUOTA "" (STORAGE 10 512)
+
+5.2. QUOTAROOT Response
+
+ Data: mailbox name
+ zero or more quota root names
+
+ This response occurs as a result of a GETQUOTAROOT command. The
+ first string is the mailbox and the remaining strings are the
+ names of the quota roots for the mailbox.
+
+ Example: S: * QUOTAROOT INBOX ""
+ S: * QUOTAROOT comp.mail.mime
+
+6. Formal syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in RFC 822 with one exception; the
+ delimiter used with the "#" construct is a single space (SP) and not
+ one or more commas.
+
+ Except as noted otherwise, all alphabetic characters are case-
+ insensitive. The use of upper or lower case characters to define
+ token strings is for editorial clarity only. Implementations MUST
+ accept these strings in a case-insensitive fashion.
+
+
+
+
+
+
+Myers Standards Track [Page 4]
+
+RFC 2087 QUOTA January 1997
+
+
+ getquota ::= "GETQUOTA" SP astring
+
+ getquotaroot ::= "GETQUOTAROOT" SP astring
+
+ quota_list ::= "(" #quota_resource ")"
+
+ quota_resource ::= atom SP number SP number
+
+ quota_response ::= "QUOTA" SP astring SP quota_list
+
+ quotaroot_response
+ ::= "QUOTAROOT" SP astring *(SP astring)
+
+ setquota ::= "SETQUOTA" SP astring SP setquota_list
+
+ setquota_list ::= "(" 0#setquota_resource ")"
+
+ setquota_resource ::= atom SP number
+
+7. References
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+ RFC 1730, University of Washington, December 1994.
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822.
+
+8. Security Considerations
+
+ Implementors should be careful to make sure the implementation of
+ these commands does not violate the site's security policy. The
+ resource usage of other users is likely to be considered confidential
+ information and should not be divulged to unauthorized persons.
+
+9. Author's Address
+
+ John G. Myers
+ Carnegie-Mellon University
+ 5000 Forbes Ave.
+ Pittsburgh PA, 15213-3890
+
+ EMail: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+Myers Standards Track [Page 5]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2087.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2088.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2088.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2088.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2088.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,116 @@
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 2088 Carnegie Mellon
+Cateogry: Standards Track January 1997
+
+
+ IMAP4 non-synchronizing literals
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ The Internet Message Access Protocol [IMAP4] contains the "literal"
+ syntactic construct for communicating strings. When sending a
+ literal from client to server, IMAP4 requires the client to wait for
+ the server to send a command continuation request between sending the
+ octet count and the string data. This document specifies an
+ alternate form of literal which does not require this network round
+ trip.
+
+2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+3. Specification
+
+ The non-synchronizing literal is added an alternate form of literal,
+ and may appear in communication from client to server instead of the
+ IMAP4 form of literal. The IMAP4 form of literal, used in
+ communication from client to server, is referred to as a
+ synchronizing literal.
+
+ Non-synchronizing literals may be used with any IMAP4 server
+ implementation which returns "LITERAL+" as one of the supported
+ capabilities to the CAPABILITY command. If the server does not
+ advertise the LITERAL+ capability, the client must use synchronizing
+ literals instead.
+
+ The non-synchronizing literal is distinguished from the original
+ synchronizing literal by having a plus ('+') between the octet count
+ and the closing brace ('}'). The server does not generate a command
+ continuation request in response to a non-synchronizing literal, and
+
+
+
+Myers Standards Track [Page 1]
+
+RFC 2088 LITERAL January 1997
+
+
+ clients are not required to wait before sending the octets of a non-
+ synchronizing literal.
+
+ The protocol receiver of an IMAP4 server must check the end of every
+ received line for an open brace ('{') followed by an octet count, a
+ plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
+ If it finds this sequence, it is the octet count of a non-
+ synchronizing literal and the server MUST treat the specified number
+ of following octets and the following line as part of the same
+ command. A server MAY still process commands and reject errors on a
+ line-by-line basis, as long as it checks for non-synchronizing
+ literals at the end of each line.
+
+ Example: C: A001 LOGIN {11+}
+ C: FRED FOOBAR {7+}
+ C: fat man
+ S: A001 OK LOGIN completed
+
+4. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+ Non-terminals referenced but not defined below are as defined by
+ [IMAP4].
+
+ literal ::= "{" number ["+"] "}" CRLF *CHAR8
+ ;; Number represents the number of CHAR8 octets
+
+6. References
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+ draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822.
+
+7. Security Considerations
+
+ There are no known security issues with this extension.
+
+8. Author's Address
+
+ John G. Myers
+ Carnegie-Mellon University
+ 5000 Forbes Ave.
+ Pittsburgh PA, 15213-3890
+
+ Email: jgm+@cmu.edu
+
+
+
+Myers Standards Track [Page 2]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2088.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2177.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2177.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2177.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2177.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,228 @@
+
+
+
+
+
+Network Working Group B. Leiba
+Request for Comments: 2177 IBM T.J. Watson Research Center
+Category: Standards Track June 1997
+
+
+ IMAP4 IDLE command
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+1. Abstract
+
+ The Internet Message Access Protocol [IMAP4] requires a client to
+ poll the server for changes to the selected mailbox (new mail,
+ deletions). It's often more desirable to have the server transmit
+ updates to the client in real time. This allows a user to see new
+ mail immediately. It also helps some real-time applications based on
+ IMAP, which might otherwise need to poll extremely often (such as
+ every few seconds). (While the spec actually does allow a server to
+ push EXISTS responses aysynchronously, a client can't expect this
+ behaviour and must poll.)
+
+ This document specifies the syntax of an IDLE command, which will
+ allow a client to tell the server that it's ready to accept such
+ real-time updates.
+
+2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ in this document are to be interpreted as described in RFC 2060
+ [IMAP4].
+
+3. Specification
+
+ IDLE Command
+
+ Arguments: none
+
+ Responses: continuation data will be requested; the client sends
+ the continuation data "DONE" to end the command
+
+
+
+Leiba Standards Track [Page 1]
+
+RFC 2177 IMAP4 IDLE command June 1997
+
+
+
+ Result: OK - IDLE completed after client sent "DONE"
+ NO - failure: the server will not allow the IDLE
+ command at this time
+ BAD - command unknown or arguments invalid
+
+ The IDLE command may be used with any IMAP4 server implementation
+ that returns "IDLE" as one of the supported capabilities to the
+ CAPABILITY command. If the server does not advertise the IDLE
+ capability, the client MUST NOT use the IDLE command and must poll
+ for mailbox updates. In particular, the client MUST continue to be
+ able to accept unsolicited untagged responses to ANY command, as
+ specified in the base IMAP specification.
+
+ The IDLE command is sent from the client to the server when the
+ client is ready to accept unsolicited mailbox update messages. The
+ server requests a response to the IDLE command using the continuation
+ ("+") response. The IDLE command remains active until the client
+ responds to the continuation, and as long as an IDLE command is
+ active, the server is now free to send untagged EXISTS, EXPUNGE, and
+ other messages at any time.
+
+ The IDLE command is terminated by the receipt of a "DONE"
+ continuation from the client; such response satisfies the server's
+ continuation request. At that point, the server MAY send any
+ remaining queued untagged responses and then MUST immediately send
+ the tagged response to the IDLE command and prepare to process other
+ commands. As in the base specification, the processing of any new
+ command may cause the sending of unsolicited untagged responses,
+ subject to the ambiguity limitations. The client MUST NOT send a
+ command while the server is waiting for the DONE, since the server
+ will not be able to distinguish a command from a continuation.
+
+ The server MAY consider a client inactive if it has an IDLE command
+ running, and if such a server has an inactivity timeout it MAY log
+ the client off implicitly at the end of its timeout period. Because
+ of that, clients using IDLE are advised to terminate the IDLE and
+ re-issue it at least every 29 minutes to avoid being logged off.
+ This still allows a client to receive immediate mailbox updates even
+ though it need only "poll" at half hour intervals.
+
+
+
+
+
+
+
+
+
+
+
+Leiba Standards Track [Page 2]
+
+RFC 2177 IMAP4 IDLE command June 1997
+
+
+ Example: C: A001 SELECT INBOX
+ S: * FLAGS (Deleted Seen)
+ S: * 3 EXISTS
+ S: * 0 RECENT
+ S: * OK [UIDVALIDITY 1]
+ S: A001 OK SELECT completed
+ C: A002 IDLE
+ S: + idling
+ ...time passes; new mail arrives...
+ S: * 4 EXISTS
+ C: DONE
+ S: A002 OK IDLE terminated
+ ...another client expunges message 2 now...
+ C: A003 FETCH 4 ALL
+ S: * 4 FETCH (...)
+ S: A003 OK FETCH completed
+ C: A004 IDLE
+ S: * 2 EXPUNGE
+ S: * 3 EXISTS
+ S: + idling
+ ...time passes; another client expunges message 3...
+ S: * 3 EXPUNGE
+ S: * 2 EXISTS
+ ...time passes; new mail arrives...
+ S: * 3 EXISTS
+ C: DONE
+ S: A004 OK IDLE terminated
+ C: A005 FETCH 3 ALL
+ S: * 3 FETCH (...)
+ S: A005 OK FETCH completed
+ C: A006 IDLE
+
+4. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
+ Non-terminals referenced but not defined below are as defined by
+ [IMAP4].
+
+ command_auth ::= append / create / delete / examine / list / lsub /
+ rename / select / status / subscribe / unsubscribe
+ / idle
+ ;; Valid only in Authenticated or Selected state
+
+ idle ::= "IDLE" CRLF "DONE"
+
+
+
+
+
+
+Leiba Standards Track [Page 3]
+
+RFC 2177 IMAP4 IDLE command June 1997
+
+
+5. References
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 2060, December 1996.
+
+6. Security Considerations
+
+ There are no known security issues with this extension.
+
+7. Author's Address
+
+ Barry Leiba
+ IBM T.J. Watson Research Center
+ 30 Saw Mill River Road
+ Hawthorne, NY 10532
+
+ Email: leiba@watson.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leiba Standards Track [Page 4]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2177.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2180.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2180.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2180.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2180.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group M. Gahrns
+Request for Comments: 2180 Microsoft
+Category: Informational July 1997
+
+
+ IMAP4 Multi-Accessed Mailbox Practice
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+1. Abstract
+
+ IMAP4[RFC-2060] is rich client/server protocol that allows a client
+ to access and manipulate electronic mail messages on a server.
+ Within the protocol framework, it is possible to have differing
+ results for particular client/server interactions. If a protocol does
+ not allow for this, it is often unduly restrictive.
+
+ For example, when multiple clients are accessing a mailbox and one
+ attempts to delete the mailbox, an IMAP4 server may choose to
+ implement a solution based upon server architectural constraints or
+ individual preference.
+
+ With this flexibility comes greater client responsibility. It is not
+ sufficient for a client to be written based upon the behavior of a
+ particular IMAP server. Rather the client must be based upon the
+ behavior allowed by the protocol.
+
+ By documenting common IMAP4 server practice for the case of
+ simultaneous client access to a mailbox, we hope to ensure the widest
+ amount of inter-operation between IMAP4 clients and servers.
+
+ The behavior described in this document reflects the practice of some
+ existing servers or behavior that the consensus of the IMAP mailing
+ list has deemed to be reasonable. The behavior described within this
+ document is believed to be [RFC-2060] compliant. However, this
+ document is not meant to define IMAP4 compliance, nor is it an
+ exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be
+ consulted to determine IMAP4 compliance, especially for server
+ behavior not described within this document.
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 1]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+2. Conventions used in this document
+
+ In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different
+ clients (client #1, client #2 and client #3) that are connected to a
+ server. "S1:", "S2:" and "S3:" indicated lines sent by the server to
+ client #1, client #2 and client #3 respectively.
+
+ A shared mailbox, is a mailbox that can be used by multiple users.
+
+ A multi-accessed mailbox, is a mailbox that has multiple clients
+ simultaneously accessing it.
+
+ A client is said to have accessed a mailbox after a successful SELECT
+ or EXAMINE command.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC-2119].
+
+
+3. Deletion/Renaming of a multi-accessed mailbox
+
+ If an external agent or multiple clients are accessing a mailbox,
+ care must be taken when handling the deletion or renaming of the
+ mailbox. Following are some strategies an IMAP server may choose to
+ use when dealing with this situation.
+
+
+3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed
+ mailbox
+
+ In some cases, this behavior may not be practical. For example, if a
+ large number of clients are accessing a shared mailbox, the window in
+ which no clients have the mailbox accessed may be small or non-
+ existent, effectively rendering the mailbox undeletable or
+ unrenamable.
+
+ Example:
+
+ <Client #1 and Client #2 have mailbox FOO accessed. Client #1 tries
+ to DELETE the mailbox and is refused>
+
+ C1: A001 DELETE FOO
+ S1: A001 NO Mailbox FOO is in use by another user.
+
+
+
+
+
+
+
+Gahrns Informational [Page 2]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+3.2. The server MAY allow the DELETE command of a multi-accessed
+ mailbox, but keep the information in the mailbox available for
+ those clients that currently have access to the mailbox.
+
+ When all clients have finished accessing the mailbox, it is
+ permanently removed. For clients that do not already have access to
+ the mailbox, the 'ghosted' mailbox would not be available. For
+ example, it would not be returned to these clients in a subsequent
+ LIST or LSUB command and would not be a valid mailbox argument to any
+ other IMAP command until the reference count of clients accessing the
+ mailbox reached 0.
+
+ In some cases, this behavior may not be desirable. For example if
+ someone created a mailbox with offensive or sensitive information,
+ one might prefer to have the mailbox deleted and all access to the
+ information contained within removed immediately, rather than
+ continuing to allow access until the client closes the mailbox.
+
+ Furthermore, this behavior, may prevent 'recycling' of the same
+ mailbox name until all clients have finished accessing the original
+ mailbox.
+
+ Example:
+
+ <Client #1 and Client #2 have mailbox FOO selected. Client #1 DELETEs
+ mailbox FOO>
+
+ C1: A001 DELETE FOO
+ S1: A001 OK Mailbox FOO is deleted.
+
+ <Client #2 is still able to operate on the deleted mailbox>
+
+ C2: B001 STORE 1 +FLAGS (\Seen)
+ S2: * 1 FETCH FLAGS (\Seen)
+ S2: B001 OK STORE completed
+
+ <Client #3 which did not have access to the mailbox prior to the
+ deletion by client #1 does not have access to the mailbox>
+
+ C3: C001 STATUS FOO (MESSAGES)
+ S3: C001 NO Mailbox does not exist
+
+ <Nor is client #3 able to create a mailbox with the name FOO, while
+ the reference count is non zero>
+
+ C3: C002 CREATE FOO
+ S3: C002 NO Mailbox FOO is still in use. Try again later.
+
+
+
+
+Gahrns Informational [Page 3]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+ <Client #2 closes its access to the mailbox, no other clients have
+ access to the mailbox FOO and reference count becomes 0>
+
+ C2: B002 CLOSE
+ S2: B002 OK CLOSE Completed
+
+ <Now that the reference count on FOO has reached 0, the mailbox name
+ can be recycled>
+
+ C3: C003 CREATE FOO
+ S3: C003 OK CREATE Completed
+
+
+3.3. The server MAY allow the DELETE/RENAME of a multi-accessed
+ mailbox, but disconnect all other clients who have the mailbox
+ accessed by sending a untagged BYE response.
+
+ A server may often choose to disconnect clients in the DELETE case,
+ but may choose to implement a "friendlier" method for the RENAME
+ case.
+
+ Example:
+
+ <Client #1 and Client #2 have mailbox FOO accessed. Client #1 DELETEs
+ the mailbox FOO>
+
+ C1: A002 DELETE FOO
+ S1: A002 OK DELETE completed.
+
+ <Server disconnects all other users of the mailbox>
+ S2: * BYE Mailbox FOO has been deleted.
+
+
+3.4. The server MAY allow the RENAME of a multi-accessed mailbox by
+ simply changing the name attribute on the mailbox.
+
+ Other clients that have access to the mailbox can continue issuing
+ commands such as FETCH that do not reference the mailbox name.
+ Clients would discover the renaming the next time they referred to
+ the old mailbox name. Some servers MAY choose to include the
+ [NEWNAME] response code in their tagged NO response to a command that
+ contained the old mailbox name, as a hint to the client that the
+ operation can succeed if the command is issued with the new mailbox
+ name.
+
+
+
+
+
+
+
+Gahrns Informational [Page 4]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+ Example:
+
+ <Client #1 and Client #2 have mailbox FOO accessed. Client #1 RENAMEs
+ the mailbox.>
+
+ C1: A001 RENAME FOO BAR
+ S1: A001 OK RENAME completed.
+
+ <Client #2 is still able to do operations that do not reference the
+ mailbox name>
+
+ C2: B001 FETCH 2:4 (FLAGS)
+ S2: * 2 FETCH . . .
+ S2: * 3 FETCH . . .
+ S2: * 4 FETCH . . .
+ S2: B001 OK FETCH completed
+
+ <Client #2 is not able to do operations that reference the mailbox
+ name>
+
+ C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994
+ 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO
+ BAR] Mailbox has been renamed
+
+
+4. Expunging of messages on a multi-accessed mailbox
+
+ If an external agent or multiple clients are accessing a mailbox,
+ care must be taken when handling the EXPUNGE of messages. Other
+ clients accessing the mailbox may be in the midst of issuing a
+ command that depends upon message sequence numbers. Because an
+ EXPUNGE response can not be sent while responding to a FETCH, STORE
+ or SEARCH command, it is not possible to immediately notify the
+ client of the EXPUNGE. This can result in ambiguity if the client
+ issues a FETCH, STORE or SEARCH operation on a message that has been
+ EXPUNGED.
+
+
+4.1. Fetching of expunged messages
+
+ Following are some strategies an IMAP server may choose to use when
+ dealing with a FETCH command on expunged messages.
+
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 5]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+ Consider the following scenario:
+
+ - Client #1 and Client #2 have mailbox FOO selected.
+ - There are 7 messages in the mailbox.
+ - Messages 4:7 are marked for deletion.
+ - Client #1 issues an EXPUNGE, to expunge messages 4:7
+
+
+4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but
+ keep the messages available to satisfy subsequent FETCH commands
+ until it is able to send an EXPUNGE response to each client.
+
+ In some cases, the behavior of keeping "ghosted" messages may not be
+ desirable. For example if a message contained offensive or sensitive
+ information, one might prefer to instantaneously remove all access to
+ the information, regardless of whether another client is in the midst
+ of accessing it.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 is still able to access the expunged messages because the
+ server has kept a 'ghosted' copy of the messages until it is able to
+ notify client #2 of the EXPUNGE>
+
+ C2: B001 FETCH 4:7 RFC822
+ S2: * 4 FETCH RFC822 . . . (RFC822 info returned)
+ S2: * 5 FETCH RFC822 . . . (RFC822 info returned)
+ S2: * 6 FETCH RFC822 . . . (RFC822 info returned)
+ S2: * 7 FETCH RFC822 . . . (RFC822 info returned)
+ S2: B001 OK FETCH Completed
+
+ <Client #2 issues a command where it can get notified of the EXPUNGE>
+
+ C2: B002 NOOP
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 3 EXISTS
+ S2: B002 OK NOOP Complete
+
+ <Client #2 no longer has access to the expunged messages>
+
+ C2: B003 FETCH 4:7 RFC822
+ S2: B003 NO Messages 4:7 are no longer available.
+
+
+
+
+
+
+Gahrns Informational [Page 6]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox,
+ and on subsequent FETCH commands return FETCH responses only for
+ non-expunged messages and a tagged NO.
+
+ After receiving a tagged NO FETCH response, the client SHOULD issue a
+ NOOP command so that it will be informed of any pending EXPUNGE
+ responses. The client may then either reissue the failed FETCH
+ command, or by examining the EXPUNGE response from the NOOP and the
+ FETCH response from the FETCH, determine that the FETCH failed
+ because of pending expunges.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 attempts to FETCH a mix of expunged and non-expunged
+ messages. A FETCH response is returned only for then non-expunged
+ messages along with a tagged NO>
+
+ C2: B001 FETCH 3:5 ENVELOPE
+ S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
+ S2: B001 NO Some of the requested messages no longer exist
+
+ <Upon receiving a tagged NO FETCH response, Client #2 issues a NOOP
+ to be informed of any pending EXPUNGE responses>
+
+ C2: B002 NOOP
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 3 EXISTS
+ S2: B002 OK NOOP Completed.
+
+ <By receiving a FETCH response for message 3, and an EXPUNGE response
+ that indicates messages 4:7 have been expunged, the client does not
+ need to re-issue the FETCH>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 7]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and
+ on subsequent FETCH commands return the usual FETCH responses for
+ non-expunged messages, "NIL FETCH Responses" for expunged
+ messages, and a tagged OK response.
+
+ If all of the messages in the subsequent FETCH command have been
+ expunged, the server SHOULD return only a tagged NO. In this case,
+ the client SHOULD issue a NOOP command so that it will be informed of
+ any pending EXPUNGE responses. The client may then either reissue
+ the failed FETCH command, or by examining the EXPUNGE response from
+ the NOOP, determine that the FETCH failed because of pending
+ expunges.
+
+ "NIL FETCH responses" are a representation of empty data as
+ appropriate for the FETCH argument specified.
+
+ Example:
+
+ * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL))
+ * 1 FETCH (FLAGS ())
+ * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000")
+ * 1 FETCH (RFC822 "")
+ * 1 FETCH (RFC822.HEADER "")
+ * 1 FETCH (RFC822.TEXT "")
+ * 1 FETCH (RFC822.SIZE 0)
+ * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
+ * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0)
+ * 1 FETCH (BODY[<section>] "")
+ * 1 FETCH (BODY[<section>]<partial> "")
+
+ In some cases, a client may not be able to distinguish between "NIL
+ FETCH responses" received because a message was expunged and those
+ received because the data actually was NIL. For example, a * 5
+ FETCH (FLAGS ()) response could be received if no flags were set on
+ message 5, or because message 5 was expunged. In a case of potential
+ ambiguity, the client SHOULD issue a command such as NOOP to force
+ the sending of the EXPUNGE responses to resolve any ambiguity.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 attempts to access a mix of expunged and non-expunged
+ messages. Normal data is returned for non-expunged message, "NIL
+ FETCH responses" are returned for expunged messages>
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 8]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+ C2: B002 FETCH 3:5 ENVELOPE
+ S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned)
+ S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
+ NIL NIL)
+ S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL
+ NIL NIL)
+ S2: B002 OK FETCH Completed
+
+ <Client #2 attempts to FETCH only expunged messages and receives a
+ tagged NO response>
+
+ C2: B002 FETCH 4:7 ENVELOPE
+ S2: B002 NO Messages 4:7 have been expunged.
+
+
+4.1.4 To avoid the situation altogether, the server MAY fail the
+ EXPUNGE of a multi-accessed mailbox
+
+ In some cases, this behavior may not be practical. For example, if a
+ large number of clients are accessing a shared mailbox, the window in
+ which no clients have the mailbox accessed may be small or non-
+ existent, effectively rendering the message unexpungeable.
+
+
+4.2. Storing of expunged messages
+
+ Following are some strategies an IMAP server may choose to use when
+ dealing with a STORE command on expunged messages.
+
+
+4.2.1 If the ".SILENT" suffix is used, and the STORE completed
+ successfully for all the non-expunged messages, the server SHOULD
+ return a tagged OK.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 tries to silently STORE flags on expunged and non-
+ expunged messages. The server sets the flags on the non-expunged
+ messages and returns OK>
+
+ C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN)
+ S2: B001 OK
+
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 9]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+4.2.2. If the ".SILENT" suffix is not used, and only expunged messages
+ are referenced, the server SHOULD return only a tagged NO.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 tries to STORE flags only on expunged messages>
+
+ C2: B001 STORE 5:7 +FLAGS (\SEEN)
+ S2: B001 NO Messages have been expunged
+
+
+4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged
+ and non-expunged messages are referenced, the server MAY set the
+ flags and return a FETCH response for the non-expunged messages
+ along with a tagged NO.
+
+ After receiving a tagged NO STORE response, the client SHOULD issue a
+ NOOP command so that it will be informed of any pending EXPUNGE
+ responses. The client may then either reissue the failed STORE
+ command, or by examining the EXPUNGE responses from the NOOP and
+ FETCH responses from the STORE, determine that the STORE failed
+ because of pending expunges.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 tries to STORE flags on a mixture of expunged and non-
+ expunged messages>
+
+ C2: B001 STORE 1:7 +FLAGS (\SEEN)
+ S2: * FETCH 1 FLAGS (\SEEN)
+ S2: * FETCH 2 FLAGS (\SEEN)
+ S2: * FETCH 3 FLAGS (\SEEN)
+ S2: B001 NO Some of the messages no longer exist.
+
+ C2: B002 NOOP
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 3 EXISTS
+ S2: B002 OK NOOP Completed.
+
+ <By receiving FETCH responses for messages 1:3, and an EXPUNGE
+ response that indicates messages 4:7 have been expunged, the client
+ does not need to re-issue the STORE>
+
+
+
+
+
+
+Gahrns Informational [Page 10]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged
+ and non-expunged messages are referenced, the server MAY return
+ an untagged NO and not set any flags.
+
+ After receiving a tagged NO STORE response, the client SHOULD issue a
+ NOOP command so that it will be informed of any pending EXPUNGE
+ responses. The client would then re-issue the STORE command after
+ updating its message list per any EXPUNGE response.
+
+ If a large number of clients are accessing a shared mailbox, the
+ window in which there are no pending expunges may be small or non-
+ existent, effectively disallowing a client from setting the flags on
+ all messages at once.
+
+ Example: (Building upon the scenario outlined in 4.1.)
+
+ <Client #2 tries to STORE flags on a mixture of expunged and non-
+ expunged messages>
+
+ C2: B001 STORE 1:7 +FLAGS (\SEEN)
+ S2: B001 NO Some of the messages no longer exist.
+
+ <Client #2 issues a NOOP to be informed of the EXPUNGED messages>
+
+ C2: B002 NOOP
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 4 EXPUNGE
+ S2: * 3 EXISTS
+ S2: B002 OK NOOP Completed.
+
+ <Client #2 updates its message list and re-issues the STORE on only
+ those messages that have not been expunged>
+
+ C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS
+ (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS
+ (\SEEN) S2: B003 OK STORE Completed
+
+
+4.3. Searching of expunged messages
+
+ A server MAY simply not return a search response for messages that
+ have been expunged and it has not been able to inform the client
+ about. If a client was expecting a particular message to be returned
+ in a search result, and it was not, the client SHOULD issue a NOOP
+ command to see if the message was expunged by another client.
+
+
+
+
+Gahrns Informational [Page 11]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+4.4 Copying of expunged messages
+
+ COPY is the only IMAP4 sequence number command that is safe to allow
+ an EXPUNGE response on. This is because a client is not permitted to
+ cascade several COPY commands together. A client is required to wait
+ and confirm that the copy worked before issuing another one.
+
+4.4.1 The server MAY disallow the COPY of messages in a multi-access
+ mailbox that contains expunged messages.
+
+ Pending EXPUNGE response(s) MUST be returned to the COPY command.
+
+ Example:
+
+ C: A001 COPY 2,4,6,8 FRED
+ S: * 4 EXPUNGE
+ S: A001 NO COPY rejected, because some of the requested
+ messages were expunged
+
+ Note: Non of the above messages are copied because if a COPY command
+ is unsuccessful, the server MUST restore the destination mailbox to
+ its state before the COPY attempt.
+
+
+4.4.2 The server MAY allow the COPY of messages in a multi-access
+ mailbox that contains expunged messages.
+
+ Pending EXPUNGE response(s) MUST be returned to the COPY command.
+ Messages that are copied are messages corresponding to sequence
+ numbers before any EXPUNGE response.
+
+ Example:
+
+ C: A001 COPY 2,4,6,8 FRED
+ S: * 3 EXPUNGE
+ S: A001 OK COPY completed
+
+ In the above example, the messages that are copied to FRED are
+ messages 2,4,6,8 at the start of the COPY command. These are
+ equivalent to messages 2,3,5,7 at the end of the COPY command. The
+ EXPUNGE response can't take place until after the messages from the
+ COPY command are identified (because of the "no expunge while no
+ commands in progress" rule).
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 12]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+ Example:
+
+ C: A001 COPY 2,4,6,8 FRED
+ S: * 4 EXPUNGE
+ S: A001 OK COPY completed
+
+ In the above example, message 4 was copied before it was expunged,
+ and MUST appear in the destination mailbox FRED.
+
+
+5. Security Considerations
+
+ This document describes behavior of servers that use the IMAP4
+ protocol, and as such, has the same security considerations as
+ described in [RFC-2060].
+
+ In particular, some described server behavior does not allow for the
+ immediate deletion of information when a mailbox is accessed by
+ multiple clients. This may be a consideration when dealing with
+ sensitive information where immediate deletion would be preferred.
+
+
+6. References
+
+ [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 2060, University of Washington, December 1996.
+
+ [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+
+7. Acknowledgments
+
+ This document is the result of discussions on the IMAP4 mailing list
+ and is meant to reflect consensus of this group. In particular,
+ Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole,
+ Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry
+ Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De
+ Winter were active participants in this discussion or made
+ suggestions to this document.
+
+
+
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 13]
+
+RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997
+
+
+8. Author's Address
+
+ Mike Gahrns
+ Microsoft
+ One Microsoft Way
+ Redmond, WA, 98072
+
+ Phone: (206) 936-9833
+ EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns Informational [Page 14]
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2180.txt
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org