As per Relevance of the word complete, we have this rfc below:
Network Working Group M.
Request for Comments: 2342
Category: Standards Track C.
May 1998
IMAP4
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
1.
IMAP4 [RFC-2060] does not define a default server namespace. As
result, two common namespace models have evolved
The "Personal Mailbox" model, in which the default namespace that
presented consists of only the user's personal mailboxes. To
shared mailboxes, the user must use an escape mechanism to
another namespace
The "Complete Hierarchy" model, in which the default namespace
is presented includes the user's personal mailboxes along with
other mailboxes they have access to
These two models, create difficulties for certain client operations
This document defines a NAMESPACE command that allows a client
discover the prefixes of namespaces used by a server for
mailboxes, other users' mailboxes, and shared mailboxes. This
a client to avoid much of the manual user configuration that is
necessary when mixing and matching IMAP4 clients and servers
2. Conventions used in this
In examples, "C:" and "S:" indicate lines sent by the client
server respectively. If such lines are wrapped without a new "C:"
"S:" label, then the wrapping is for editorial clarity and is
part of the command
Gahrns & Newman Standards Track [Page 1]
RFC 2342 IMAP4 Namespace May 1998
Personal Namespace: A namespace that the server considers within
personal scope of the authenticated user on a particular connection
Typically, only the authenticated user has access to mailboxes
their Personal Namespace. It is the part of the namespace
belongs to the user that is allocated for mailboxes. If an
exists for a user, it MUST appear within the user's
namespace. In the typical case, there SHOULD be only one
Namespace on a server
Other Users' Namespace: A namespace that consists of mailboxes
the Personal Namespaces of other users. To access mailboxes in
Other Users' Namespace, the currently authenticated user MUST
explicitly granted access rights. For example, it is common for
manager to grant to their secretary access rights to their mailbox
In the typical case, there SHOULD be only one Other Users'
on a server
Shared Namespace: A namespace that consists of mailboxes that
intended to be shared amongst users and do not exist within a user'
Personal Namespace
The namespaces a server uses MAY differ on a per-user basis
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC-2119].
3. Introduction and
Clients often attempt to create mailboxes for such purposes
maintaining a record of sent messages (e.g. "Sent Mail")
temporarily saving messages being composed (e.g. "Drafts").
these clients to inter-operate correctly with the variety of IMAP
servers available, the user must enter the prefix of the
Namespace used by the server. Using the NAMESPACE command, a
is able to automatically discover this prefix without manual
configuration
In addition, users are often required to manually enter the
of various namespaces in order to view the mailboxes located there
For example, they might be required to enter the prefix of #shared
view the shared mailboxes namespace. The NAMESPACE command allows
client to automatically discover the namespaces that are available
a server. This allows a client to present the available namespaces
the user in what ever manner it deems appropriate. For example,
Gahrns & Newman Standards Track [Page 2]
RFC 2342 IMAP4 Namespace May 1998
client could choose to initially display only personal mailboxes,
it may choose to display the complete list of mailboxes available
and initially position the user at the root of their
Namespace
A server MAY choose to make available to the NAMESPACE command only
subset of the complete set of namespaces the server supports.
provide the ability to access these namespaces, a client SHOULD
the user the ability to manually enter a namespace prefix
4.
IMAP4 servers that support this extension MUST list the
NAMESPACE in their CAPABILITY response
The NAMESPACE command is valid in the Authenticated and
state
5. NAMESPACE
Arguments:
Response: an untagged NAMESPACE response that contains the
and hierarchy delimiter to the server's
Namespace(s), Other Users' Namespace(s), and
Namespace(s) that the server wishes to expose.
response will contain a NIL for any namespace
that is not available. Namespace_Response_
MAY be included in the response
Namespace_Response_Extensions which are not on the
standards track, MUST be prefixed with an "X-".
Result: OK - Command
NO - Error: Can't complete
BAD - argument
Example 5.1:
===========
< A server that supports a single personal namespace. No
prefix is used on personal mailboxes and "/" is the
delimiter.>
C: A001
S: * NAMESPACE (("" "/")) NIL
S: A001 OK NAMESPACE command
Gahrns & Newman Standards Track [Page 3]
RFC 2342 IMAP4 Namespace May 1998
Example 5.2:
===========
< A user logged on anonymously to a server. No personal
are associated with the anonymous user and the user does not
access to the Other Users' Namespace. No prefix is required
access shared mailboxes and the hierarchy delimiter is "." >
C: A001
S: * NAMESPACE NIL NIL (("" "."))
S: A001 OK NAMESPACE command
Example 5.3:
===========
< A server that contains a Personal Namespace and a single
Namespace. >
C: A001
S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
S: A001 OK NAMESPACE command
Example 5.4:
===========
< A server that contains a Personal Namespace, Other Users
Namespace and multiple Shared Namespaces. Note that the
delimiter used within each namespace can be different. >
C: A001
S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
("#public/" "/")("#ftp/" "/")("#news." "."))
S: A001 OK NAMESPACE command
The prefix string allows a client to do things such as
creating personal mailboxes or LISTing all available mailboxes
a namespace
Example 5.5:
===========
< A server that supports only the Personal Namespace, with
leading prefix of INBOX to personal mailboxes and a
delimiter of ".">
C: A001
S: * NAMESPACE (("INBOX." ".")) NIL
S: A001 OK NAMESPACE command
Gahrns & Newman Standards Track [Page 4]
RFC 2342 IMAP4 Namespace May 1998
< Automatically create a mailbox to store sent items.>
C: A002 CREATE "INBOX.Sent Mail
S: A002 OK CREATE command
Although typically a server will support only a single
Namespace, and a single Other User's Namespace, circumstances
where there MAY be multiples of these, and a client MUST be
for them. If a client is configured such that it is required
create a certain mailbox, there can be circumstances where it
unclear which Personal Namespaces it should create the mailbox in
In these situations a client SHOULD let the user select
namespaces to create the mailbox in
Example 5.6:
===========
< In this example, a server supports 2 Personal Namespaces.
addition to the regular Personal Namespace, the user has
additional personal namespace to allow access to mailboxes in
MH format mailstore. >
< The client is configured to save a copy of all mail sent by
user into a mailbox called 'Sent Mail'. Furthermore, after
message is deleted from a mailbox, the client is configured
move that message to a mailbox called 'Deleted Items'.>
< Note that this example demonstrates how some extension flags
be passed to further describe the #mh namespace. >
C: A001
S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
NIL
S: A001 OK NAMESPACE command
< It is desired to keep only one copy of sent mail. It is
which Personal Namespace the client should use to create the '
Mail' mailbox. The user is prompted to select a namespace
only one 'Sent Mail' mailbox is created. >
C: A002 CREATE "Sent Mail
S: A002 OK CREATE command
< The client is designed so that it keeps two 'Deleted Items
mailboxes, one for each namespace. >
C: A003 CREATE "Delete Items
S: A003 OK CREATE command
Gahrns & Newman Standards Track [Page 5]
RFC 2342 IMAP4 Namespace May 1998
C: A004 CREATE "#mh/Deleted Items
S: A004 OK CREATE command
The next level of hierarchy following the Other Users'
prefix SHOULD consist of <username>, where <username> is a user
as per the IMAP4 LOGIN or AUTHENTICATE command
A client can construct a LIST command by appending a "%" to the
Users' Namespace prefix to discover the Personal Namespaces of
users that are available to the currently authenticated user
In response to such a LIST command, a server SHOULD NOT return
names that have not granted access to their personal mailboxes to
user in question
A server MAY return a LIST response containing only the names
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'
mailboxes that are accessible to the currently logged on user. >
C: A001
S: * NAMESPACE (("" "/")) (("Other Users/" "/"))
S: A001 OK NAMESPACE command
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
Example 5.8:
===========
< A server that does not support providing a list of other user'
mailboxes that are accessible to the currently logged on user
The mailboxes are listable if the client includes the name of
other user with the Other Users' Namespace prefix. >
Gahrns & Newman Standards Track [Page 6]
RFC 2342 IMAP4 Namespace May 1998
C: A001
S: * NAMESPACE (("" "/")) (("#Users/" "/"))
S: A001 OK NAMESPACE command
< In this example, the currently logged on user has access to
Personal Namespace of user Mike, but the server chose to
this information in the LIST response. However, by appending
user name Mike (received through user input) to the Other Users
Namespace prefix, the client is able to get a listing of
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,
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
prefixing the others' mailboxes with a '~' followed by <username>,
where <username> is a user name as per the IMAP4 LOGIN
AUTHENTICATE command.>
C: A001
S: * NAMESPACE (("" "/")) (("~" "/"))
S: A001 OK NAMESPACE command
< List the mailboxes for user mark >
C: A002 LIST "" "~mark/%"
S: * LIST () "/" "~mark/INBOX
S: * LIST () "/" "~mark/foo
S: A002 OK LIST command
Historical convention has been to start all namespaces with the "#"
character. Namespaces that include the "#" character are not
URL [IMAP-URL] friendly requiring the "#" character to be
as %23 when within URLs. As such, server implementers MAY
consider using namespace prefixes that do not contain the "#"
character
Gahrns & Newman Standards Track [Page 7]
RFC 2342 IMAP4 Namespace May 1998
6. Formal
The following syntax specification uses the augmented Backus-
Form (BNF) as described in [ABNF].
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
; 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 =
; as defined in [RFC-2060]
QUOTED_CHAR =
; as defined in [RFC-2060]
string =
; as defined in [RFC-2060]
; Note that the namespace prefix is to a mailbox and
; IMAP4 convention, any international string in the
; response MUST be of modified UTF-7 format as described
; [RFC-2060].
7. Security
In response to a LIST command containing an argument of the
Users' Namespace prefix, a server SHOULD NOT list users that have
granted list access to their personal mailboxes to the
authenticated user. Providing such a list, could compromise
by potentially disclosing confidential information of who is
on the server, or providing a starting point of a list of
accounts to attack
Gahrns & Newman Standards Track [Page 8]
RFC 2342 IMAP4 Namespace May 1998
8.
[RFC-2060], Crispin, M., "Internet Message Access Protocol
4rev1", RFC 2060, December 1996.
[RFC-2119], Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
9.
Many people have participated in the discussion of IMAP namespaces
the IMAP mailing list. In particular, the authors would like
thank Mark Crispin for many of the concepts relating to the
Namespace and accessing the Personal Namespace of other users,
Hole for summarizing the two namespace models, John Myers and Jack
Winter for their work in a preceding effort trying to define
standardized personal namespace, and Larry Osterman for his
and collaboration on this document
11. Authors'
Mike
One Microsoft
Redmond, WA, 98072,
Phone: (425) 936-9833
EMail: mikega@microsoft.
Chris
Innosoft International, Inc
1050 East Garvey Ave.
West Covina, CA, 91790,
EMail: chris.newman@innosoft.
Gahrns & Newman Standards Track [Page 9]
RFC 2342 IMAP4 Namespace May 1998
12. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Gahrns & Newman Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
