imapext: docs/rfc/rfc5092.txt comparison

comparison docs/rfc/rfc5092.txt @ 0:ada5e610ab86

imap-2007e

author	yuuji@gentei.org
date	Mon, 14 Sep 2009 15:17:45 +0900
parents
children

comparison

equal deleted inserted replaced

--1:000000000000
+:ada5e610ab86
+Network Working Group                                   A. Melnikov, Ed.
+Request for Comments: 5092                                    Isode Ltd.
+Obsoletes: 2192                                                C. Newman
+Updates: 4467                                           Sun Microsystems
+Category: Standards Track                                  November 2007
+IMAP URL Scheme
+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.
+Abstract
+IMAP (RFC 3501) is a rich protocol for accessing remote message
+stores.  It provides an ideal mechanism for accessing public mailing
+list archives as well as private and shared message stores.  This
+document defines a URL scheme for referencing objects on an IMAP
+server.
+This document obsoletes RFC 2192.  It also updates RFC 4467.
+Melnikov & Newman           Standards Track                     [Page 1]
+RFC 5092                    IMAP URL Scheme                November 2007
+Table of Contents
+1. Introduction ....................................................2
+2. Conventions Used in This Document ...............................3
+3. IMAP userinfo Component (iuserinfo) .............................4
+3.1. IMAP Mailbox Naming Scope ..................................4
+3.2. IMAP User Name and Authentication Mechanism ................4
+3.3. Limitations of enc-user ....................................6
+4. IMAP Server .....................................................7
+5. Lists of Messages ...............................................7
+6. A Specific Message or Message Part ..............................8
+6.1. URLAUTH Authorized URL .....................................9
+6.1.1. Concepts ............................................9
+6.1.1.1. URLAUTH ....................................9
+6.1.1.2. Mailbox Access Key .........................9
+6.1.1.3. Authorized Access Identifier ...............9
+6.1.1.4. Authorization Mechanism ...................10
+6.1.1.5. Authorization Token .......................10
+6.1.2. URLAUTH Extensions to IMAP URL .....................10
+7. Relative IMAP URLs .............................................11
+7.1. absolute-path References ..................................12
+7.2. relative-path References ..................................12
+8. Internationalization Considerations ............................13
+9. Examples .......................................................13
+9.1. Examples of Relative URLs .................................16
+10. Security Considerations .......................................16
+10.1. Security Considerations Specific to URLAUTH Authorized
+URL ......................................................17
+11. ABNF for IMAP URL Scheme ......................................17
+12. IANA Considerations ...........................................21
+12.1. IANA Registration of imap: URI Scheme ....................21
+13. References ....................................................22
+13.1. Normative References .....................................22
+13.2. Informative References ...................................23
+Appendix A. Sample Code............................................24
+Appendix B. List of Changes since RFC 2192.........................30
+Appendix C. List of Changes since RFC 4467.........................31
+Appendix D. Acknowledgments........................................31
+1.  Introduction
+The IMAP URL scheme is used to designate IMAP servers, mailboxes,
+messages, MIME bodies [MIME], and search programs on Internet hosts
+accessible using the IMAP protocol over TCP.
+The IMAP URL follows the common Internet scheme syntax as defined in
+[URI-GEN].  If :<port> is omitted, the port defaults to 143 (as
+defined in Section 2.1 of [IMAP4]).
+Melnikov & Newman           Standards Track                     [Page 2]
+RFC 5092                    IMAP URL Scheme                November 2007
+An absolute IMAP URL takes one of the following forms:
+imap://<iserver>[/]
+imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
+imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
+[<isection>][<ipartial>][<iurlauth>]
+The first form is used to refer to an IMAP server (see Section 4),
+the second form refers to the contents of a mailbox or a set of
+messages resulting from a search (see Section 5), and the final form
+refers to a specific message or message part, and possibly a byte
+range in that part (see Section 6).  If [URLAUTH] extension is
+supported, then the final form can have the <iurlauth> component (see
+Section 6.1 for more details).
+The <iserver> component common to all types of absolute IMAP URLs has
+the following syntax expressed in ABNF [ABNF]:
+[iuserinfo "@"] host [ ":" port ]
+The <iserver> component is the same as "authority" defined in
+[URI-GEN].  The syntax and uses of the <iuserinfo> ("IMAP userinfo
+component") are described in detail in Section 3.  The syntax of
+<host> and <port> is described in [URI-GEN].
+2.  Conventions Used in This Document
+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 [KEYWORDS].
+This document references many productions from [URI-GEN].  When the
+document needs to emphasize IMAP URI-specific differences from [URI-
+GEN] (i.e., for parts of IMAP URIs that have more restricted syntax
+than generic URIs), it uses a non-terminal i<foo> to define an IMAP-
+specific version of the non-terminal <foo> from [URI-GEN].
+Note that the ABNF syntax shown in Section 11 is normative.  Sections
+2-6 may use a less formal syntax that does not necessarily match the
+normative ABNF shown in Section 11.  If there are any differences
+between the syntax shown in Sections 2-6 and Section 11, then the
+syntax shown in Section 11 must be treated as authoritative.  Non-
+syntax requirements included in Sections 2-6 are, of course,
+normative.
+Melnikov & Newman           Standards Track                     [Page 3]
+RFC 5092                    IMAP URL Scheme                November 2007
+3.  IMAP userinfo Component (iuserinfo)
+The <iuserinfo> component conforms to the generic syntax of
+<userinfo> defined in [URI-GEN].  It has the following syntax
+expressed in ABNF [ABNF]:
+enc-user [iauth] / [enc-user] iauth
+The meaning of the different parts is described in subsections of
+this section.
+3.1.  IMAP Mailbox Naming Scope
+The "enc-user" part of the "iuserinfo" component, if present, denotes
+mailbox naming scope.  If it is absent, the IMAP URL can only
+reference mailboxes with globally unique names, i.e., mailboxes with
+names that don't change depending on the user the client
+authenticated as to the IMAP server.  Note that not all IMAP
+implementations support globally unique names.
+For example, a personal mailbox described by the following URL
+<imap://michael@example.org/INBOX> is most likely different from a
+personal mailbox described by <imap://bester@example.org/INBOX>, even
+though both URLs use the same mailbox name.
+3.2.  IMAP User Name and Authentication Mechanism
+The userinfo component (see [URI-GEN]) of an IMAP URI may contain an
+IMAP user name (a.k.a. authorization identity [SASL], "enc-user")
+and/or an authentication mechanism. (Note that the "enc-user" also
+defines a mailbox naming scope as described in Section 3.1).  The
+IMAP user name and the authentication mechanism are used in the
+"LOGIN" or "AUTHENTICATE" commands after making the connection to the
+IMAP server.
+If no user name and no authentication mechanism are supplied, the
+client MUST authenticate as anonymous to the server.  If the server
+advertises AUTH=ANONYMOUS IMAP capability, the client MUST use the
+AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism.  If
+SASL ANONYMOUS is not available, the (case-insensitive) user name
+"anonymous" is used with the "LOGIN" command and the Internet email
+address of the end user accessing the resource is supplied as the
+password.  The latter option is given in order to provide for
+interoperability with deployed servers.
+Note that, as described in RFC 3501, the "LOGIN" command MUST NOT be
+used when the IMAP server advertises the LOGINDISABLED capability.
+Melnikov & Newman           Standards Track                     [Page 4]
+RFC 5092                    IMAP URL Scheme                November 2007
+An authentication mechanism (as used by the IMAP AUTHENTICATE
+command) can be expressed by adding ";AUTH=<enc-auth-type>" to the
+end of the user name in an IMAP URL.  When such an <enc-auth-type> is
+indicated, the client SHOULD request appropriate credentials from
+that mechanism and use the "AUTHENTICATE" command instead of the
+"LOGIN" command.  If no user name is specified, one MUST be obtained
+from the mechanism or requested from the user/configuration as
+appropriate.
+The string ";AUTH=*" indicates that the client SHOULD select an
+appropriate authentication mechanism.  (Though the '*' character in
+this usage is not strictly a delimiter, it is being treated like a
+sub-delim [URI-GEN] in this instance.  It MUST NOT be percent-encoded
+in this usage, as ";AUTH=%2A" will not match this production.)  It
+MAY use any mechanism listed in the response to the CAPABILITY
+command (or CAPABILITY response code) or use an out-of-band security
+service resulting in a PREAUTH connection.  If no user name is
+specified and no appropriate authentication mechanisms are available,
+the client SHOULD fall back to anonymous login as described above.
+The behavior prescribed in this section allows a URL that grants
+read-write access to authorized users and read-only anonymous access
+to other users.
+If a user name is included with no authentication mechanism, then
+";AUTH=*" is assumed.
+Clients must take care when resolving a URL that requires or requests
+any sort of authentication, since URLs can easily come from untrusted
+sources.  Supplying authentication credentials to the wrong server
+may compromise the security of the user's account; therefore, the
+program resolving the URL should meet at least one of the following
+criteria in this case:
+1) The URL comes from a trusted source, such as a referral server
+that the client has validated and trusts according to site policy.
+Note that user entry of the URL may or may not count as a trusted
+source, depending on the experience level of the user and site
+policy.
+2) Explicit local site policy permits the client to connect to the
+server in the URL.  For example, a company example.com may have a
+site policy to trust all IMAP server names ending in example.com,
+whereas such a policy would be unwise for example.edu where random
+students can set up IMAP servers.
+3) The user confirms that connecting to that domain name with the
+specified credentials and/or mechanism is permitted.  For example,
+when using "LOGIN" or SASL PLAIN with Transport Layer Security
+Melnikov & Newman           Standards Track                     [Page 5]
+RFC 5092                    IMAP URL Scheme                November 2007
+(TLS), the IMAP URL client presents a dialog box "Is it OK to send
+your password to server "example.com"?  Please be aware the owners
+of example.com will be able to reuse your password to connect to
+other servers on your behalf".
+4) A mechanism is used that validates the server before passing
+potentially compromising client credentials.  For example, a site
+has a designated TLS certificate used to certify site-trusted IMAP
+server certificates, and this has been configured explicitly into
+the IMAP URL client.  Another example is use of a Simple
+Authentication and Security Layer (SASL) mechanism such as
+DIGEST-MD5 [DIGEST-MD5], which supports mutual authentication.
+5) An authentication mechanism is used that will not reveal any
+information to the server that could be used to compromise future
+connections.  Examples are SASL ANONYMOUS [ANONYMOUS] or GSSAPI
+[GSSAPI].
+URLs that do not include a user name but include an authentication
+mechanism (";AUTH=<mech>") must be treated with extra care, since for
+some <mech>s they are more likely to compromise the user's primary
+account.  A URL containing ";AUTH=*" must also be treated with extra
+care since it might fall back on a weaker security mechanism.
+Finally, clients are discouraged from using a plaintext password as a
+fallback with ";AUTH=*" unless the connection has strong encryption.
+A program interpreting IMAP URLs MAY cache open connections to an
+IMAP server for later reuse.  If a URL contains a user name, only
+connections authenticated as that user may be reused.  If a URL does
+not contain a user name or authentication mechanism, then only an
+anonymous connection may be reused.
+Note that if unsafe or reserved characters such as " " (space) or ";"
+are present in the user name or authentication mechanism, they MUST
+be percent-encoded as described in [URI-GEN].
+3.3.  Limitations of enc-user
+As per Sections 3.1 and 3.2 of this document, the IMAP URI enc-user
+has two purposes:
+1) It provides context for user-specific mailbox paths such as
+"INBOX" (Section 3.1).
+2) It specifies that resolution of the URL requires logging in as
+that user and limits use of that URL to only that user (Section
+3.2).
+Melnikov & Newman           Standards Track                     [Page 6]
+RFC 5092                    IMAP URL Scheme                November 2007
+An obvious limitation of using the same field for both purposes is
+that the URL can be resolved only by the mailbox owner.  In order to
+avoid this restriction, implementations should use globally unique
+mailbox names (see Section 3.1) whenever possible.
+Note: There is currently no general way in IMAP of learning a
+globally unique name for a mailbox.  However, by looking at the
+NAMESPACE [NAMESPACE] command result, it is possible to determine
+whether or not a mailbox name is globally unique.
+The URLAUTH component overrides the second purpose of the enc-user in
+the IMAP URI and by default permits the URI to be resolved by any
+user permitted by the <access> identifier.  URLAUTH and <access>
+identifier are described in Section 6.1.
+4.  IMAP Server
+An IMAP URL referring to an IMAP server has the following form:
+imap://<iserver>[/]
+This URL type is frequently used to describe a location of an IMAP
+server, both in referrals and in configuration.  It may optionally
+contain the <iuserinfo> component (see Sections 3 and 11).  A program
+interpreting this URL would issue the standard set of commands it
+uses to present a view of the content of the IMAP server, as visible
+to the user described by the "enc-user" part of the <iuserinfo>
+component, if the "enc-user" part is specified.
+5.  Lists of Messages
+An IMAP URL referring to a list of messages has the following form:
+imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
+The <enc-mailbox> field is used as the argument to the IMAP4 "SELECT"
+or "EXAMINE" command.  Note that if unsafe or reserved characters
+such as " " (space), ";", or "?" are present in <enc-mailbox>, they
+MUST be percent-encoded as described in [URI-GEN].
+The <uidvalidity> field is optional.  If it is present, it MUST be
+the same as the value of IMAP4 UIDVALIDITY response code at the time
+the URL was created.  This MUST be used by the program interpreting
+the IMAP URL to determine if the URL is stale.  If the IMAP URL is
+stale, then the program should behave as if the corresponding mailbox
+doesn't exist.
+Melnikov & Newman           Standards Track                     [Page 7]
+RFC 5092                    IMAP URL Scheme                November 2007
+Note that the <uidvalidity> field is a modifier to the <enc-mailbox>,
+i.e., it is considered a part of the last "component" (as used in
+[URI-GEN]) of the <enc-mailbox>.  This is significant during relative
+URI resolution.
+The "?<enc-search>" field is optional.  If it is not present, the
+program interpreting the URL will present the entire content of the
+mailbox.
+If the "?<enc-search>" field is present, the program interpreting the
+URL should use the contents of this field as arguments following an
+IMAP4 SEARCH command.  These arguments are likely to contain unsafe
+characters such as " " (space) (which are likely to be present in the
+<enc-search>).  If unsafe characters are present, they MUST be
+percent-encoded as described in [URI-GEN].
+Note that quoted strings and non-synchronizing literals [LITERAL+]
+are allowed in the <enc-search> content; however, synchronizing
+literals are not allowed, as their presence would effectively mean
+that the agent interpreting IMAP URLs needs to parse an <enc-search>
+content, find all synchronizing literals, and perform proper command
+continuation request handling (see Sections 4.3 and 7 of [IMAP4]).
+6.  A Specific Message or Message Part
+An IMAP URL referring to a specific message or message part has the
+following form:
+imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
+[<isection>][<ipartial>][<iurlauth>]
+The <enc-mailbox> and [uidvalidity] are as defined in Section 5
+above.
+If <uidvalidity> is present in this form, it SHOULD be used by the
+program interpreting the URL to determine if the URL is stale.
+The <iuid> refers to an IMAP4 message Unique Identifier (UID), and it
+SHOULD be used as the <set> argument to the IMAP4 "UID FETCH"
+command.
+The <isection> field is optional.  If not present, the URL refers to
+the entire Internet message as returned by the IMAP command "UID
+FETCH <uid> BODY.PEEK[]".  If present, the URL refers to the object
+returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command.  The
+type of the object may be determined by using a "UID FETCH <uid>
+BODYSTRUCTURE" command and locating the appropriate part in the
+Melnikov & Newman           Standards Track                     [Page 8]
+RFC 5092                    IMAP URL Scheme                November 2007
+resulting BODYSTRUCTURE.  Note that unsafe characters in [isection]
+MUST be percent-encoded as described in [URI-GEN].
+The <ipartial> field is optional.  If present, it effectively appends
+"<<partial-range>>" to the end of the UID FETCH BODY.PEEK[<section>]
+command constructed as described in the previous paragraph.  In other
+words, it allows the client to request a byte range of the
+message/message part.
+The <iurlauth> field is described in detail in Section 6.1.
+6.1.  URLAUTH Authorized URL
+URLAUTH authorized URLs are only supported by an IMAP server
+advertising the URLAUTH IMAP capability [URLAUTH].
+6.1.1.  Concepts
+6.1.1.1.  URLAUTH
+URLAUTH is a component, appended at the end of a URL, that conveys
+authorization to access the data addressed by that URL.  It contains
+an authorized access identifier, an authorization mechanism name, and
+an authorization token.  The authorization token is generated from
+the URL, the authorized access identifier, authorization mechanism
+name, and a mailbox access key.
+Note: This specification only allows for the URLAUTH component in
+IMAP URLs describing a message or its part.
+6.1.1.2.  Mailbox Access Key
+The mailbox access key is an unpredictable, random string.  To ensure
+unpredictability, the random string with at least 128 bits of entropy
+is generated by software or hardware (not by the human user).
+Each user has a table of mailboxes and an associated mailbox access
+key for each mailbox.  Consequently, the mailbox access key is per-
+user and per-mailbox.  In other words, two users sharing the same
+mailbox each have a different mailbox access key for that mailbox,
+and each mailbox accessed by a single user also has a different
+mailbox access key.
+6.1.1.3.  Authorized Access Identifier
+The authorized <access> identifier restricts use of the URLAUTH
+authorized URL to certain users authorized on the server, as
+described in Section 6.1.2.
+Melnikov & Newman           Standards Track                     [Page 9]
+RFC 5092                    IMAP URL Scheme                November 2007
+6.1.1.4.  Authorization Mechanism
+The authorization mechanism is the algorithm by which the URLAUTH is
+generated and subsequently verified, using the mailbox access key.
+6.1.1.5.  Authorization Token
+The authorization token is a deterministic string of at least 128
+bits that an entity with knowledge of the secret mailbox access key
+and URL authorization mechanism can use to verify the URL.
+6.1.2.  URLAUTH Extensions to IMAP URL
+A specific message or message part IMAP URL can optionally contain
+";EXPIRE=<datetime>" and/or ";URLAUTH=<access>:<mech>:<token>".
+When ";EXPIRE=<datetime>" is used, this indicates the latest date and
+time that the URL is valid.  After that date and time, the URL has
+expired and server implementations MUST reject the URL.  If
+";EXPIRE=<datetime>" is not used, the URL has no expiration, but can
+still be revoked using the RESETKEY command [URLAUTH].
+The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>", and it
+MUST be at the end of the URL.  It is composed of three parts.  The
+<access> portion provides the authorized access identifiers that may
+constrain the operations and users that are permitted to use this
+URL.  The <mech> portion provides the authorization mechanism used by
+the IMAP server to generate the authorization token that follows.
+The <token> portion provides the authorization token, which can be
+generated using the GENURLAUTH command [URLAUTH].
+The "submit+" <access> identifier prefix, followed by a userid,
+indicates that only a userid authorized as a message submission
+entity on behalf of the specified userid is permitted to use this
+URL.  The IMAP server does not validate the specified userid but does
+validate that the IMAP session has an authorization identity that is
+authorized as a message submission entity.  The authorized message
+submission entity MUST validate the userid prior to contacting the
+IMAP server.
+The "user+" <access> identifier prefix, followed by a userid,
+indicates that use of this URL is limited to IMAP sessions that are
+logged in as the specified userid (that is, have authorization
+identity as that userid).
+Note: If a SASL mechanism that provides both authorization and
+authentication identifiers is used to authenticate to the IMAP
+server, the "user+" <access> identifier MUST match the
+Melnikov & Newman           Standards Track                    [Page 10]
+RFC 5092                    IMAP URL Scheme                November 2007
+authorization identifier.  If the SASL mechanism can't transport
+the authorization identifier, the "user+" <access> identifier MUST
+match the authorization identifier derived from the authentication
+identifier (see [SASL]).
+The "authuser" <access> identifier indicates that use of this URL is
+limited to authenticated IMAP sessions that are logged in as any
+non-anonymous user (that is, have authorization identity as a non-
+anonymous user) of that IMAP server.  To restate this: use of this
+type of URL is prohibited to anonymous IMAP sessions, i.e., any
+URLFETCH command containing this type of URL issued in an anonymous
+session MUST return NIL in the URLFETCH response.
+The "anonymous" <access> identifier indicates that use of this URL is
+not restricted by session authorization identity; that is, any IMAP
+session in authenticated or selected state (as defined in [IMAP4]),
+including anonymous sessions, may issue a URLFETCH [URLAUTH] using
+this URL.
+The authorization token is represented as an ASCII-encoded
+hexadecimal string, which is used to authorize the URL.  The length
+and the calculation of the authorization token depend upon the
+mechanism used, but in all cases, the authorization token is at least
+128 bits (and therefore at least 32 hexadecimal digits).
+Example:
+<imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=
+submit+fred:internal:91354a473744909de610943775f92038>
+7.  Relative IMAP URLs
+Relative IMAP URLs are permitted and are resolved according to the
+rules defined in [URI-GEN].  In particular, in IMAP URLs parameters
+(such as ";uid=" or ";section=") are treated as part of the normal
+path with respect to relative URL resolution.
+[URI-GEN] defines four forms of relative URLs: <inetwork-path>,
+<iabsolute-path>, <irelative-path>, and <ipath-empty>.  Their syntax
+is defined in Section 11.
+A relative reference that begins with two slash characters is termed
+a network-path reference (<inetwork-path>); such references are
+rarely used, because in most cases they can be replaced with an
+equivalent absolute URL.  A relative reference that begins with a
+single slash character is termed an absolute-path reference
+(<iabsolute-path>; see also Section 7.1).  A relative reference that
+does not begin with a slash character is termed a relative-path
+Melnikov & Newman           Standards Track                    [Page 11]
+RFC 5092                    IMAP URL Scheme                November 2007
+reference (<irelative-path>; see also Section 7.2).  The final form
+is <ipath-empty>, which is "same-document reference" (see Section 4.4
+of [URI-GEN]).
+The following observations about relative URLs are important:
+The <iauth> grammar element (which is a part of <iuserinfo>, which
+is, in turn, a part of <iserver>; see Section 3) is considered part
+of the user name for purposes of resolving relative IMAP URLs.  This
+means that unless a new user name/server specification is included in
+the relative URL, the authentication mechanism is inherited from the
+base IMAP URL.
+URLs always use "/" as the hierarchy delimiter for the purpose of
+resolving paths in relative URLs.  IMAP4 permits the use of any
+hierarchy delimiter in mailbox names.  For this reason, relative
+mailbox paths will only work if the mailbox uses "/" as the hierarchy
+delimiter.  Relative URLs may be used on mailboxes that use other
+delimiters, but in that case, the entire mailbox name MUST be
+specified in the relative URL or inherited as a whole from the base
+URL.
+If an IMAP server allows for mailbox names starting with "./" or
+"../", ending with "/." or "/..", or containing sequences "/../" or
+"/./", then such mailbox names MUST be percent-encoded as described
+in [URI-GEN].  Otherwise, they would be misinterpreted as dot-
+segments (see Section 3.3 of [URI-GEN]), which are processed
+specially during the relative path resolution process.
+7.1.  absolute-path References
+A relative reference that begins with a single slash character is
+termed an absolute-path reference (see Section 4.2 of [URI-GEN]).  If
+an IMAP server permits mailbox names with a leading "/", then the
+leading "/" MUST be percent-encoded as described in [URI-GEN].
+Otherwise, the produced absolute-path reference URI will be
+misinterpreted as a network-path reference [URI-GEN] described by the
+<inetwork-path> non-terminal.
+7.2.  relative-path References
+A relative reference that does not begin with a slash character is
+termed a relative-path reference [URI-GEN].  Implementations MUST NOT
+generate or accept relative-path IMAP references.
+See also Section 4.2 of [URI-GEN] for restrictions on relative-path
+references.
+Melnikov & Newman           Standards Track                    [Page 12]
+RFC 5092                    IMAP URL Scheme                November 2007
+8.  Internationalization Considerations
+IMAP4, Section 5.1.3 [IMAP4] includes a convention for encoding non-
+US-ASCII characters in IMAP mailbox names.  Because this convention
+is private to IMAP, it is necessary to convert IMAP's encoding to one
+that can be more easily interpreted by a URL display program.  For
+this reason, IMAP's modified UTF-7 encoding for mailboxes MUST be
+converted to UTF-8 [UTF-8].  Since 8-bit octets are not permitted in
+URLs, the UTF-8 octets are percent-encoded as required by the URL
+specification [URI-GEN], Section 2.1.  Sample code is included in
+Appendix A to demonstrate this conversion.
+IMAP user names are UTF-8 strings and MUST be percent-encoded as
+required by the URL specification [URI-GEN], Section 2.1.
+Also note that IMAP SEARCH criteria can contain non-US-ASCII
+characters.  8-bit octets in those strings MUST be percent-encoded as
+required by the URL specification [URI-GEN], Section 2.1.
+9.  Examples
+The following examples demonstrate how an IMAP4 client program might
+translate various IMAP4 URLs into a series of IMAP4 commands.
+Commands sent from the client to the server are prefixed with "C:",
+and responses sent from the server to the client are prefixed with
+"S:".
+The URL:
+<imap://minbari.example.org/gray-council;UIDVALIDITY=385759045/;
+UID=20/;PARTIAL=0.1024>
+may result in the following client commands and server responses:
+<connect to minbari.example.org, port 143>
+S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=ANONYMOUS] Welcome
+C: A001 AUTHENTICATE ANONYMOUS
+S: +
+C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmc=
+S: A001 OK Welcome sheridan@babylon5.example.org
+C: A002 SELECT gray-council
+<client verifies the UIDVALIDITY matches>
+C: A003 UID FETCH 20 BODY.PEEK[]<0.1024>
+The URL:
+<imap://psicorp.example.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
+%E5%8F%B0%E5%8C%97>
+Melnikov & Newman           Standards Track                    [Page 13]
+RFC 5092                    IMAP URL Scheme                November 2007
+may result in the following client commands:
+<connect to psicorp.example.org, port 143>
+S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5] Welcome
+C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org
+C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
+<commands the client uses for viewing the contents of
+the mailbox>
+The URL:
+<imap://;AUTH=GSSAPI@minbari.example.org/gray-council/;uid=20/
+;section=1.2>
+may result in the following client commands:
+<connect to minbari.example.org, port 143>
+S: * OK Greetings
+C: A000 CAPABILITY
+S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
+S: A000 OK
+C: A001 AUTHENTICATE GSSAPI
+<authentication exchange>
+C: A002 SELECT gray-council
+C: A003 UID FETCH 20 BODY.PEEK[1.2]
+If the following relative URL is located in that body part:
+<;section=1.4>
+this could result in the following client commands:
+C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
+BODY.PEEK[1.MIME]
+BODY.PEEK[HEADER.FIELDS (Content-Location)])
+<Client looks for Content-Location headers in
+result.  If no such headers, then it does the following>
+C: A005 UID FETCH 20 BODY.PEEK[1.4]
+The URL:
+<imap://;AUTH=*@minbari.example.org/gray%20council?
+SUBJECT%20shadows>
+Melnikov & Newman           Standards Track                    [Page 14]
+RFC 5092                    IMAP URL Scheme                November 2007
+could result in the following:
+<connect to minbari.example.org, port 143>
+S: * OK Welcome
+C: A001 CAPABILITY
+S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5
+S: A001 OK
+C: A002 AUTHENTICATE DIGEST-MD5
+<authentication exchange>
+S: A002 OK user lennier authenticated
+C: A003 SELECT "gray council"
+...
+C: A004 SEARCH SUBJECT shadows
+S: * SEARCH 8 10 13 14 15 16
+S: A004 OK SEARCH completed
+C: A005 FETCH 8,10,13:16 ALL
+...
+In the example above, the client has implementation-dependent
+choices.  The authentication mechanism could be anything, including
+PREAUTH.  The final FETCH command could fetch more or less
+information about the messages, depending on what it wishes to
+display to the user.
+The URL:
+<imap://john;AUTH=*@minbari.example.org/babylon5/personel?
+charset%20UTF-8%20SUBJECT%20%7B14+%7D%0D%0A%D0%98%D0%B2%
+D0%B0%D0%BD%D0%BE%D0%B2%D0%B0>
+shows that 8-bit data can be sent using non-synchronizing literals
+[LITERAL+].  This could result in the following:
+<connect to minbari.example.org, port 143>
+S: * OK Hi there
+C: A001 CAPABILITY
+S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5
+S: A001 OK
+C: A002 AUTHENTICATE DIGEST-MD5
+<authentication exchange>
+S: A002 OK user john authenticated
+C: A003 SELECT babylon5/personel
+...
+C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+}
+C: XXXXXXXXXXXXXX
+S: * SEARCH 7 10 12
+S: A004 OK SEARCH completed
+C: A005 FETCH 7,10,12 ALL
+Melnikov & Newman           Standards Track                    [Page 15]
+RFC 5092                    IMAP URL Scheme                November 2007
+...
+where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified
+in the URL above.
+9.1.  Examples of Relative URLs
+The following absolute-path reference
+</foo/;UID=20/..>
+is the same as
+</foo>
+That is, both of them reference the mailbox "foo" located on the IMAP
+server described by the corresponding Base URI.
+The following relative-path reference
+<;UID=20>
+references a message with UID in the mailbox specified by the Base
+URI.
+The following edge case example demonstrates that the ;UIDVALIDITY=
+modifier is a part of the mailbox name as far as relative URI
+resolution is concerned:
+<..;UIDVALIDITY=385759045/;UID=20>
+In this example, ".." is not a dot-segment [URI-GEN].
+10.  Security Considerations
+Security considerations discussed in the IMAP specification [IMAP4]
+and the URI specification [URI-GEN] are relevant.  Security
+considerations related to authenticated URLs are discussed in Section
+3.2 of this document.
+Many email clients store the plaintext password for later use after
+logging into an IMAP server.  Such clients MUST NOT use a stored
+password in response to an IMAP URL without explicit permission from
+the user to supply that password to the specified host name.
+Clients resolving IMAP URLs that wish to achieve data confidentiality
+and/or integrity SHOULD use the STARTTLS command (if supported by the
+Melnikov & Newman           Standards Track                    [Page 16]
+RFC 5092                    IMAP URL Scheme                November 2007
+server) before starting authentication, or use a SASL mechanism, such
+as GSSAPI, that provides a confidentiality security layer.
+10.1.  Security Consideration Specific to URLAUTH Authorized URL
+The "user+<userid>" <access> identifier limits resolution of that URL
+to a particular userid, whereas the "submit+<userid>" <access>
+identifier is more general and simply requires that the session be
+authorized by a user that has been granted a "submit" role within the
+authentication system.  Use of either of these mechanisms limits the
+scope of the URL.  An attacker who cannot authenticate using the
+appropriate credentials cannot make use of the URL.
+The "authuser" and "anonymous" <access> identifiers do not have this
+level of protection.  These access identifiers are primarily useful
+for public export of data from an IMAP server, without requiring that
+it be copied to a web or anonymous FTP server.
+The decision to use the "authuser" <access> identifier should be made
+with caution.  An "authuser" <access> identifier can be used by any
+authorized user of the IMAP server; therefore, use of this access
+identifier should be limited to content that may be disclosed to any
+authorized user of the IMAP server.
+The decision to use the "anonymous" <access> identifier should be
+made with extreme caution.  An "anonymous" <access> identifier can be
+used by anyone; therefore, use of this access identifier should be
+limited to content that may be disclosed to anyone.
+11.  ABNF for IMAP URL Scheme
+Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
+in Section 9 of [IMAP4].  Elements not defined here can be found in
+[ABNF], [IMAP4], [IMAPABNF], or [URI-GEN].  Strings are not case
+sensitive, and free insertion of linear white space is not permitted.
+sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
+"*" / "+" / ","
+;; Same as [URI-GEN] sub-delims,
+;; but without ";", "&" and "=".
+uchar            = unreserved / sub-delims-sh / pct-encoded
+achar            = uchar / "&" / "="
+;; Same as [URI-GEN] 'unreserved / sub-delims /
+;; pct-encoded', but ";" is disallowed.
+bchar            = achar / ":" / "@" / "/"
+Melnikov & Newman           Standards Track                    [Page 17]
+RFC 5092                    IMAP URL Scheme                November 2007
+enc-auth-type    = 1*achar
+; %-encoded version of [IMAP4] "auth-type"
+enc-mailbox      = 1*bchar
+; %-encoded version of [IMAP4] "mailbox"
+enc-search       = 1*bchar
+; %-encoded version of [IMAPABNF]
+; "search-program".  Note that IMAP4
+; literals may not be used in
+; a "search-program", i.e., only
+; quoted or non-synchronizing
+; literals (if the server supports
+; LITERAL+ [LITERAL+]) are allowed.
+enc-section      = 1*bchar
+; %-encoded version of [IMAP4] "section-spec"
+enc-user         = 1*achar
+; %-encoded version of [IMAP4] authorization
+; identity or "userid".
+imapurl          = "imap://" iserver ipath-query
+; Defines an absolute IMAP URL
+ipath-query      = ["/" [ icommand ]]
+; Corresponds to "path-abempty [ "?" query ]"
+; in [URI-GEN]
+Generic syntax for relative URLs is defined in Section 4.2 of
+[URI-GEN].  For ease of implementation, the relative IMAP URL syntax
+is defined below:
+imapurl-rel     = inetwork-path
+/ iabsolute-path
+/ irelative-path
+/ ipath-empty
+inetwork-path   = "//" iserver ipath-query
+; Corresponds to '"//" authority path-abempty
+; [ "?" query ]' in [URI-GEN]
+iabsolute-path  = "/" [ icommand ]
+; icommand, if present, MUST NOT start with '/'.
+;
+; Corresponds to 'path-absolute [ "?" query ]'
+; in [URI-GEN]
+Melnikov & Newman           Standards Track                    [Page 18]
+RFC 5092                    IMAP URL Scheme                November 2007
+irelative-path  = imessagelist /
+imsg-or-part
+; Corresponds to 'path-noscheme [ "?" query ]'
+; in [URI-GEN]
+imsg-or-part    = ( imailbox-ref "/" iuid-only ["/" isection-only]
+["/" ipartial-only] ) /
+( iuid-only ["/" isection-only]
+["/" ipartial-only] ) /
+( isection-only ["/" ipartial-only] ) /
+ipartial-only
+ipath-empty     = 0<pchar>
+; Zero characters.
+; The same-document reference.
+The following three rules are only used in the presence of the IMAP
+[URLAUTH] extension:
+authimapurl     = "imap://" iserver "/" imessagepart
+; Same as "imapurl" when "[icommand]" is
+; "imessagepart"
+authimapurlfull = authimapurl iurlauth
+; Same as "imapurl" when "[icommand]" is
+; "imessagepart iurlauth"
+authimapurlrump = authimapurl iurlauth-rump
+enc-urlauth     = 32*HEXDIG
+iurlauth        = iurlauth-rump iua-verifier
+iua-verifier    = ":" uauth-mechanism ":" enc-urlauth
+iurlauth-rump   = [expire] ";URLAUTH=" access
+access          = ("submit+" enc-user) / ("user+" enc-user) /
+"authuser" / "anonymous"
+expire          = ";EXPIRE=" date-time
+; date-time is defined in [DATETIME]
+uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
+; Case-insensitive.
+; New mechanisms MUST be registered with IANA.
+Melnikov & Newman           Standards Track                    [Page 19]
+RFC 5092                    IMAP URL Scheme                November 2007
+iauth            = ";AUTH=" ( "*" / enc-auth-type )
+icommand         = imessagelist /
+imessagepart [iurlauth]
+imailbox-ref     = enc-mailbox [uidvalidity]
+imessagelist     = imailbox-ref [ "?" enc-search ]
+; "enc-search" is [URI-GEN] "query".
+imessagepart     = imailbox-ref iuid [isection] [ipartial]
+ipartial         = "/" ipartial-only
+ipartial-only    = ";PARTIAL=" partial-range
+isection         = "/" isection-only
+isection-only    = ";SECTION=" enc-section
+iserver          = [iuserinfo "@"] host [ ":" port ]
+; This is the same as "authority" defined
+; in [URI-GEN].  See [URI-GEN] for "host"
+; and "port" definitions.
+iuid             = "/" iuid-only
+iuid-only        = ";UID=" nz-number
+; See [IMAP4] for "nz-number" definition
+iuserinfo        = enc-user [iauth] / [enc-user] iauth
+; conforms to the generic syntax of
+; "userinfo" as defined in [URI-GEN].
+partial-range    = number ["." nz-number]
+; partial FETCH.  The first number is
+; the offset of the first byte,
+; the second number is the length of
+; the fragment.
+uidvalidity      = ";UIDVALIDITY=" nz-number
+; See [IMAP4] for "nz-number" definition
+Melnikov & Newman           Standards Track                    [Page 20]
+RFC 5092                    IMAP URL Scheme                November 2007
+12.  IANA Considerations
+IANA has updated the "imap" definition in the "Uniform Resource
+Identifier scheme registry" to point to this document.
+The registration template (as per [URI-REG]) is specified in Section
+12.1 of this document.
+12.1.  IANA Registration of imap: URI Scheme
+This section provides the information required to register the imap:
+URI scheme.
+URI scheme name: imap
+Status: permanent
+URI scheme syntax:
+See Section 11 of [RFC5092].
+URI scheme semantics:
+The imap: URI scheme is used to designate IMAP servers, mailboxes,
+messages, MIME bodies [MIME] and their parts, and search programs
+on Internet hosts accessible using the IMAP protocol.
+There is no MIME type associated with this URI.
+Encoding considerations:
+See Section 8 of [RFC5092].
+Applications/protocols that use this URI scheme name:
+The imap: URI is intended to be used by applications that might
+need access to an IMAP mailstore.  Such applications may include
+(but are not limited to) IMAP-capable web browsers; IMAP clients
+that wish to access a mailbox, message, or edit a message on the
+server using [CATENATE]; [SUBMIT] clients and servers that are
+requested to assemble a complete message on submission using
+[BURL].
+Interoperability considerations:
+A widely deployed IMAP client Netscape Mail (and possibly
+Mozilla/Thunderbird/Seamonkey) uses a different imap: scheme
+internally.
+Melnikov & Newman           Standards Track                    [Page 21]
+RFC 5092                    IMAP URL Scheme                November 2007
+Security considerations:
+See Security Considerations (Section 10) of [RFC5092].
+Contact:
+Alexey Melnikov <alexey.melnikov@isode.com>
+Author/Change controller:
+IESG
+References:
+[RFC5092] and [IMAP4].
+13. References
+13.1.  Normative References
+[KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+Requirement Levels", BCP 14, RFC 2119, March 1997.
+[IMAP4]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+4rev1", RFC 3501, March 2003.
+[IMAPABNF]   Melnikov, A. and C. Daboo, "Collected Extensions to
+IMAP4 ABNF", RFC 4466, April 2006.
+[ABNF]       Crocker, D., Ed., and P. Overell, "Augmented BNF for
+Syntax Specifications: ABNF", RFC 4234, October 2005.
+[MIME]       Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+Extensions (MIME) Part One: Format of Internet Message
+Bodies", RFC 2045, November 1996.
+[URI-GEN]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+Resource Identifier (URI): Generic Syntax", STD 66, RFC
+3986, January 2005.
+[UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+10646", STD 63, RFC 3629, November 2003.
+[NAMESPACE]  Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
+May 1998.
+[LITERAL+]   Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
+January 1997.
+Melnikov & Newman           Standards Track                    [Page 22]
+RFC 5092                    IMAP URL Scheme                November 2007
+[ANONYMOUS]  Zeilenga, K., "Anonymous Simple Authentication and
+Security Layer (SASL) Mechanism", RFC 4505, June 2006.
+[DATETIME]   Klyne, G. and C. Newman, "Date and Time on the Internet:
+Timestamps", RFC 3339, July 2002.
+[URLAUTH]    Crispin, M., "Internet Message Access Protocol (IMAP) -
+URLAUTH Extension", RFC 4467, May 2006.
+13.2.  Informative References
+[SUBMIT]     Gellens, R. and J. Klensin, "Message Submission for
+Mail", RFC 4409, April 2006.
+[BURL]       Newman, C., "Message Submission BURL Extension", RFC
+4468, May 2006.
+[CATENATE]   Resnick, P., "Internet Message Access Protocol (IMAP)
+CATENATE Extension", RFC 4469, April 2006.
+[SASL]       Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
+Authentication and Security Layer (SASL)", RFC 4422,
+June 2006.
+[GSSAPI]     Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
+Authentication and Security Layer (SASL) Mechanism", RFC
+4752, November 2006.
+[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as
+a SASL Mechanism", RFC 2831, May 2000.
+[URI-REG]    Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
+Registration Procedures for New URI Schemes", BCP 115,
+RFC 4395, February 2006.
+Melnikov & Newman           Standards Track                    [Page 23]
+RFC 5092                    IMAP URL Scheme                November 2007
+Appendix A.  Sample Code
+Here is sample C source code to convert between URL paths and IMAP
+mailbox names, taking into account mapping between IMAP's modified
+UTF-7 [IMAP4] and hex-encoded UTF-8, which is more appropriate for
+URLs.  This code has not been rigorously tested nor does it
+necessarily behave reasonably with invalid input, but it should serve
+as a useful example.  This code just converts the mailbox portion of
+the URL and does not deal with parameters, query, or server
+components of the URL.
+/* Copyright (C) The IETF Trust (2007).  This version of
+sample C code is part of RFC XXXX; see the RFC itself
+for full legal notices.
+Regarding this sample C code (or any portion of it), the authors
+make no guarantees and are not responsible for any damage
+resulting from its use.  The authors grant irrevocable permission
+to anyone to use, modify, and distribute it in any way that does
+not diminish the rights of anyone else to use, modify, and
+distribute it, provided that redistributed derivative works do
+not contain misleading author or version information.
+Derivative works need not be licensed under similar terms.
+*/
+#include <stdio.h>
+#include <string.h>
+/* hexadecimal lookup table */
+static const char hex[] = "0123456789ABCDEF";
+#define XX 127
+/*
+* Table for decoding hexadecimal in %encoding
+*/
+static const char index_hex[256] = {
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+0, 1, 2, 3,  4, 5, 6, 7,  8, 9,XX,XX, XX,XX,XX,XX,
+XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+Melnikov & Newman           Standards Track                    [Page 24]
+RFC 5092                    IMAP URL Scheme                November 2007
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
+};
+#define HEXCHAR(c)  (index_hex[(unsigned char)(c)])
+/* "gen-delims" excluding "/" but including "%" */
+#define GENERAL_DELIMS_NO_SLASH     ":?#[]@" "%"
+/* "gen-delims" (excluding "/", but including "%")
+plus subset of "sub-delims" */
+#define GENERAL_UNSAFE_NO_SLASH     GENERAL_DELIMS_NO_SLASH ";&=+"
+#define OTHER_UNSAFE                " \"<>\\^`{|}"
+/* URL unsafe printable characters */
+static const char mailbox_url_unsafe[] = GENERAL_UNSAFE_NO_SLASH
+OTHER_UNSAFE;
+/* UTF7 modified base64 alphabet */
+static const char base64chars[] =
+"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
+#define UNDEFINED 64
+/* UTF16 definitions */
+#define UTF16MASK   0x03FFUL
+#define UTF16SHIFT  10
+#define UTF16BASE   0x10000UL
+#define UTF16HIGHSTART   0xD800UL
+#define UTF16HIGHEND     0xDBFFUL
+#define UTF16LOSTART     0xDC00UL
+#define UTF16LOEND  0xDFFFUL
+/* Convert an IMAP mailbox to a URL path
+*  dst needs to have roughly 4 times the storage space of src
+*    Hex encoding can triple the size of the input
+*    UTF-7 can be slightly denser than UTF-8
+*     (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
+*/
+void MailboxToURL(char *dst, char *src)
+{
+unsigned char c, i, bitcount;
+unsigned long ucs4, utf16, bitbuf;
+unsigned char base64[256], utf8[6];
+/* initialize modified base64 decoding table */
+Melnikov & Newman           Standards Track                    [Page 25]
+RFC 5092                    IMAP URL Scheme                November 2007
+memset(base64, UNDEFINED, sizeof (base64));
+for (i = 0; i < sizeof (base64chars); ++i) {
+base64[(int) base64chars[i]] = i;
+}
+/* loop until end of string */
+while (*src != '\0') {
+c = *src++;
+/* deal with literal characters and &- */
+if (c != '&' || *src == '-') {
+/* NB: There are no "URL safe" characters after the '~' */
+if (c < ' ' || c > '~' ||
+strchr(mailbox_url_unsafe, c) != NULL) {
+/* hex encode if necessary */
+dst[0] = '%';
+dst[1] = hex[c >> 4];
+dst[2] = hex[c & 0x0f];
+dst += 3;
+} else {
+/* encode literally */
+*dst++ = c;
+}
+/* skip over the '-' if this is an &- sequence */
+if (c == '&') ++src;
+} else {
+/* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
+bitbuf = 0;
+bitcount = 0;
+ucs4 = 0;
+while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
+++src;
+bitbuf = (bitbuf << 6) | c;
+bitcount += 6;
+/* enough bits for a UTF-16 character? */
+if (bitcount >= 16) {
+bitcount -= 16;
+utf16 = (bitcount ? bitbuf >> bitcount
+: bitbuf) & 0xffff;
+/* convert UTF16 to UCS4 */
+if
+(utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
+ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
+continue;
+} else if
+(utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
+ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
+} else {
+Melnikov & Newman           Standards Track                    [Page 26]
+RFC 5092                    IMAP URL Scheme                November 2007
+ucs4 = utf16;
+}
+/* convert UTF-16 range of UCS4 to UTF-8 */
+if (ucs4 <= 0x7fUL) {
+utf8[0] = (unsigned char) ucs4;
+i = 1;
+} else if (ucs4 <= 0x7ffUL) {
+utf8[0] = 0xc0 | (unsigned char) (ucs4 >> 6);
+utf8[1] = 0x80 | (unsigned char) (ucs4 & 0x3f);
+i = 2;
+} else if (ucs4 <= 0xffffUL) {
+utf8[0] = 0xe0 | (unsigned char) (ucs4 >> 12);
+utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
+utf8[2] = 0x80 | (unsigned char) (ucs4 & 0x3f);
+i = 3;
+} else {
+utf8[0] = 0xf0 | (unsigned char) (ucs4 >> 18);
+utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 12) & 0x3f);
+utf8[2] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
+utf8[3] = 0x80 | (unsigned char) (ucs4 & 0x3f);
+i = 4;
+}
+/* convert utf8 to hex */
+for (c = 0; c < i; ++c) {
+dst[0] = '%';
+dst[1] = hex[utf8[c] >> 4];
+dst[2] = hex[utf8[c] & 0x0f];
+dst += 3;
+}
+}
+}
+/* skip over trailing '-' in modified UTF-7 encoding */
+if (*src == '-') ++src;
+}
+}
+/* terminate destination string */
+*dst = '\0';
+}
+/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
+*  dst should be about twice the length of src to deal with non-hex
+*  coded URLs
+*/
+int URLtoMailbox(char *dst, char *src)
+{
+unsigned int utf8pos = 0;
+unsigned int utf8total, i, c, utf7mode, bitstogo, utf16flag;
+unsigned long ucs4 = 0, bitbuf = 0;
+Melnikov & Newman           Standards Track                    [Page 27]
+RFC 5092                    IMAP URL Scheme                November 2007
+utf7mode = 0; /* is the output UTF7 currently in base64 mode? */
+utf8total = 0; /* how many octets is the current input UTF-8 char;
+0 == between characters */
+bitstogo = 0; /* bits that need to be encoded into base64; if
+bitstogo != 0 then utf7mode == 1 */
+while ((c = (unsigned char)*src) != '\0') {
+++src;
+/* undo hex-encoding */
+if (c == '%' && src[0] != '\0' && src[1] != '\0') {
+c = HEXCHAR(src[0]);
+i = HEXCHAR(src[1]);
+if (c == XX || i == XX) {
+return 0;
+} else {
+c = (char)((c << 4) | i);
+}
+src += 2;
+}
+/* normal character? */
+if (c >= ' ' && c <= '~') {
+/* switch out of UTF-7 mode */
+if (utf7mode) {
+if (bitstogo) {
+*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
+}
+*dst++ = '-';
+utf7mode = 0;
+bitstogo = bitbuf = 0;
+}
+*dst++ = c;
+/* encode '&' as '&-' */
+if (c == '&') {
+*dst++ = '-';
+}
+continue;
+}
+/* switch to UTF-7 mode */
+if (!utf7mode) {
+*dst++ = '&';
+utf7mode = 1;
+}
+/* Encode US-ASCII characters as themselves */
+if (c < 0x80) {
+ucs4 = c;
+utf8total = 1;
+} else if (utf8total) {
+/* this is a subsequent octet of a multi-octet character */
+/* save UTF8 bits into UCS4 */
+Melnikov & Newman           Standards Track                    [Page 28]
+RFC 5092                    IMAP URL Scheme                November 2007
+ucs4 = (ucs4 << 6) | (c & 0x3FUL);
+if (++utf8pos < utf8total) {
+continue;
+}
+} else {
+/* this is the first octet of a multi-octet character */
+utf8pos = 1;
+if (c < 0xE0) {
+utf8total = 2;
+ucs4 = c & 0x1F;
+} else if (c < 0xF0) {
+utf8total = 3;
+ucs4 = c & 0x0F;
+} else {
+/* NOTE: can't convert UTF8 sequences longer than 4 */
+utf8total = 4;
+ucs4 = c & 0x03;
+}
+continue;
+}
+/* Finished with UTF-8 character.  Make sure it isn't an
+overlong sequence.  If it is, return failure. */
+if ((ucs4 < 0x80 && utf8total > 1) ||
+(ucs4 < 0x0800 && utf8total > 2) ||
+(ucs4 < 0x00010000 && utf8total > 3) ||
+(ucs4 < 0x00200000 && utf8total > 4) ||
+(ucs4 < 0x04000000 && utf8total > 5) ||
+(ucs4 < 0x80000000 && utf8total > 6)) {
+return 0;
+}
+/* loop to split ucs4 into two utf16 chars if necessary */
+utf8total = 0;
+do {
+if (ucs4 >= UTF16BASE) {
+ucs4 -= UTF16BASE;
+bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
++ UTF16HIGHSTART);
+ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
+utf16flag = 1;
+} else {
+bitbuf = (bitbuf << 16) | ucs4;
+utf16flag = 0;
+}
+bitstogo += 16;
+/* spew out base64 */
+while (bitstogo >= 6) {
+bitstogo -= 6;
+*dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
+Melnikov & Newman           Standards Track                    [Page 29]
+RFC 5092                    IMAP URL Scheme                November 2007
+: bitbuf)
+& 0x3F];
+}
+} while (utf16flag);
+}
+/* if in UTF-7 mode, finish in ASCII */
+if (utf7mode) {
+if (bitstogo) {
+*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
+}
+*dst++ = '-';
+}
+/* tie off string */
+*dst = '\0';
+return 1;
+}
+Appendix B.  List of Changes since RFC 2192
+Updated boilerplate, list of editor's, etc.
+Updated references.
+Updated ABNF not to use _, to use SP instead of SPACE, etc.
+Updated example domains to use example.org.
+Fixed ABNF error in "imessagelist" non-terminal.
+Updated ABNF, due to changes in RFC 3501, RFC 4466, and RFC 3986.
+Renamed "iuserauth" non-terminal to <iuserinfo>.
+Clarified that the userinfo component describes both authorization
+identity and mailbox naming scope.
+Allow for non-synchronizing literals in "enc-search".
+Added "ipartial" specifier that denotes a partial FETCH.
+Moved URLAUTH text from RFC 4467 to this document.
+Updated ABNF for the whole server to allow missing trailing "/"
+(e.g., "imap://imap.example.com" is now valid and is the same as
+"imap://imap.example.com/").
+Clarified how relative-path references are constructed.
+Added more examples demonstrating relative-path references.
+Added rules for relative URLs and restructured ABNF as the result.
+Removed text on use of relative URLs in MHTML.
+Added examples demonstrating security considerations when resolving
+URLs.
+Recommend usage of STARTTLS/SASL security layer to protect
+confidential data.
+Removed some advices about connection reuse that were incorrect.
+Removed URLs referencing a list of mailboxes, as this feature
+hasn't seen any deployments.
+Clarified that user name "anonymous" is case-insensitive.
+Melnikov & Newman           Standards Track                    [Page 30]
+RFC 5092                    IMAP URL Scheme                November 2007
+Appendix C.  List of Changes since RFC 4467
+Renamed <mechanism> to <uauth-mechanism>.  Restructured ABNF.
+Appendix D.  Acknowledgments
+Text describing URLAUTH was lifted from [URLAUTH] by Mark Crispin.
+Stephane H. Maes contributed some ideas to this document; he also
+co-edited early versions of this document.
+The editors would like to thank Mark Crispin, Ken Murchison, Ted
+Hardie, Zoltan Ordogh, Dave Cridland, Kjetil Torgrim Homme, Lisa
+Dusseault, Spencer Dawkins, Filip Navara, Shawn M. Emery, Sam
+Hartman, Russ Housley, and Lars Eggert for the time they devoted to
+reviewing this document and/or for the comments received.
+Authors' Addresses
+Chris Newman (Author/Editor)
+Sun Microsystems
+3401 Centrelake Dr., Suite 410
+Ontario, CA 91761
+EMail: chris.newman@sun.com
+Alexey Melnikov (Editor)
+Isode Limited
+5 Castle Business Village
+36 Station Road
+Hampton, Middlesex
+TW12 2BX, UK
+EMail: Alexey.Melnikov@isode.com
+URI:   http://www.melnikov.ca/
+Melnikov & Newman           Standards Track                    [Page 31]
+RFC 5092                    IMAP URL Scheme                November 2007
+Full Copyright Statement
+Copyright (C) The IETF Trust (2007).
+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, THE IETF TRUST 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
+Intellectual Property Rights or other rights that might be claimed to
+pertain to the implementation or use of the technology described in
+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
+made any independent effort to identify any such rights.  Information
+on the procedures with respect to rights in RFC documents can be
+found in BCP 78 and BCP 79.
+Copies of IPR disclosures made to the IETF Secretariat and any
+assurances of licenses to be made available, or the result of an
+attempt made to obtain a general license or permission for the use of
+such proprietary rights by implementers or users of this
+specification can be obtained from the IETF on-line IPR repository at
+http://www.ietf.org/ipr.
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary
+rights that may cover technology that may be required to implement
+this standard.  Please address the information to the IETF at
+ietf-ipr@ietf.org.
+Melnikov & Newman           Standards Track                    [Page 32]

Mercurial > hgrepos > hgweb.cgi > imapext

comparison docs/rfc/rfc5092.txt @ 0:ada5e610ab86