rfc2342.txt

RFC 的详细文档！


RFC 2342                    IMAP4 Namespace                     May 1998


      C: A004 CREATE "#mh/Deleted Items"
      S: A004 OK CREATE command completed

   The next level of hierarchy following the Other Users' Namespace
   prefix SHOULD consist of <username>, where <username> is a user name
   as per the IMAP4 LOGIN or AUTHENTICATE command.

   A client can construct a LIST command by appending a "%" to the Other
   Users' Namespace prefix to discover the Personal Namespaces of other
   users that are available to the currently authenticated user.

   In response to such a LIST command, a server SHOULD NOT return user
   names that have not granted access to their personal mailboxes to the
   user in question.

   A server MAY return a LIST response containing only the names of
   users that have explicitly granted access to the user in question.

   Alternatively, a server MAY return NO to such a LIST command,
   requiring that a user name be included with the Other Users'
   Namespace prefix before listing any other user's mailboxes.

   Example 5.7:
   ===========

      < A server that supports providing a list of other user's
      mailboxes that are accessible to the currently logged on user. >

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
      S: A001 OK NAMESPACE command completed

      C: A002 LIST "" "Other Users/%"
      S: * LIST () "/" "Other Users/Mike"
      S: * LIST () "/" "Other Users/Karen"
      S: * LIST () "/" "Other Users/Matthew"
      S: * LIST () "/" "Other Users/Tesa"
      S: A002 OK LIST command completed

   Example 5.8:
   ===========

      < A server that does not support providing a list of other user's
      mailboxes that are accessible to the currently logged on user.
      The mailboxes are listable if the client includes the name of the
      other user with the Other Users' Namespace prefix. >





Gahrns & Newman             Standards Track                     [Page 6]

RFC 2342                    IMAP4 Namespace                     May 1998


      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
      S: A001 OK NAMESPACE command completed

      < In this example, the currently logged on user has access to the
      Personal Namespace of user Mike, but the server chose to suppress
      this information in the LIST response.  However, by appending the
      user name Mike (received through user input) to the Other Users'
      Namespace prefix, the client is able to get a listing of the
      personal mailboxes of user Mike. >

      C: A002 LIST "" "#Users/%"
      S: A002 NO The requested item could not be found.

      C: A003 LIST "" "#Users/Mike/%"
      S: * LIST () "/" "#Users/Mike/INBOX"
      S: * LIST () "/" "#Users/Mike/Foo"
      S: A003 OK LIST command completed.

      A prefix string might not contain a hierarchy delimiter, because
      in some cases it is not needed as part of the prefix.

      Example 5.9:
      ===========

      < A server that allows access to the Other Users' Namespace by
      prefixing the others' mailboxes with a '~' followed by <username>,
      where <username> is a user name as per the IMAP4 LOGIN or
      AUTHENTICATE command.>

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("~" "/")) NIL
      S: A001 OK NAMESPACE command completed

      < List the mailboxes for user mark >

      C: A002 LIST "" "~mark/%"
      S: * LIST () "/" "~mark/INBOX"
      S: * LIST () "/" "~mark/foo"
      S: A002 OK LIST command completed

   Historical convention has been to start all namespaces with the "#"
   character.  Namespaces that include the "#" character are not IMAP
   URL [IMAP-URL] friendly requiring the "#" character to be represented
   as %23 when within URLs.  As such, server implementers MAY instead
   consider using namespace prefixes that do not contain the "#"
   character.




Gahrns & Newman             Standards Track                     [Page 7]

RFC 2342                    IMAP4 Namespace                     May 1998


6. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].

   atom = <atom>
      ; <atom> as defined in [RFC-2060]

   Namespace = nil / "(" 1*( "(" string SP  (<"> QUOTED_CHAR <"> /
      nil) *(Namespace_Response_Extension) ")" ) ")"

   Namespace_Command = "NAMESPACE"

   Namespace_Response_Extension = SP string SP "(" string *(SP string)
      ")"

   Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
      Namespace

      ; The first Namespace is the Personal Namespace(s)
      ; The second Namespace is the Other Users' Namespace(s)
      ; The third Namespace is the Shared Namespace(s)

      nil = <nil>
         ; <nil> as defined in [RFC-2060]

      QUOTED_CHAR = <QUOTED_CHAR>
         ; <QUOTED_CHAR> as defined in [RFC-2060]

      string = <string>
         ; <string> as defined in [RFC-2060]
         ; Note that  the namespace prefix is to a mailbox and following
         ; IMAP4 convention, any international string in the NAMESPACE
         ; response MUST be of modified UTF-7 format as described in
         ;  [RFC-2060].

7. Security Considerations

   In response to a LIST command containing an argument of the Other
   Users' Namespace prefix, a server SHOULD NOT list users that have not
   granted list access to their personal mailboxes to the currently
   authenticated user.  Providing such a list, could compromise security
   by potentially disclosing confidential information of who is located
   on the server, or providing a starting point of a list of user
   accounts to attack.






Gahrns & Newman             Standards Track                     [Page 8]

RFC 2342                    IMAP4 Namespace                     May 1998


8. References

   [RFC-2060], Crispin, M., "Internet Message Access Protocol Version
   4rev1", RFC 2060, December 1996.

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.

   [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.

9.  Acknowledgments

   Many people have participated in the discussion of IMAP namespaces on
   the IMAP mailing list.  In particular, the authors would like to
   thank Mark Crispin for many of the concepts relating to the Personal
   Namespace and accessing the Personal Namespace of other users, Steve
   Hole for summarizing the two namespace models, John Myers and Jack De
   Winter for their work in a preceding effort trying to define a
   standardized personal namespace, and Larry Osterman for his review
   and collaboration on this document.

11. Authors' Addresses

   Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98072, USA

   Phone: [phone]
   EMail: [e-mail]


   Chris Newman
   Innosoft International, Inc.
   1050 East Garvey Ave. South
   West Covina, CA, 91790, USA

   EMail: [e-mail]










Gahrns & Newman             Standards Track                     [Page 9]

RFC 2342                    IMAP4 Namespace                     May 1998


12.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Gahrns & Newman             Standards Track                    [Page 10]