idnits 2.17.1 draft-ietf-lemonade-rfc2192bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 977. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages -- Found 22 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6616 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UTF8' is mentioned on line 370, but not defined == Missing Reference: 'This RFC' is mentioned on line 639, but not defined -- Looks like a reference, but probably isn't: '256' on line 841 -- Looks like a reference, but probably isn't: '6' on line 746 == Unused Reference: 'UTF-8' is defined on line 665, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- No information found for draft-melnikov-imap-ext-abnf-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IMAPABNF' ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- No information found for draft-ietf-sasl-anon-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ANONYMOUS' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Document: draft-ietf-lemonade-rfc2192bis-01.txt Sun Microsystems 4 Expires: August 2006 A. Melnikov 5 Intended category: Standards Track Isode Ltd. 6 S. H. Maes 7 Oracle Corporation 8 February 2006 10 IMAP URL Scheme 12 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the RFC 34 editor as a Proposed Standard for the Internet Community. Discussion 35 and suggestions for improvement are requested, and should be sent to 36 the IMAPEXT Mailing list . Distribution of this 37 draft is unlimited. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 44 IMAP [IMAP4] is a rich protocol for accessing remote message 45 stores. It provides an ideal mechanism for accessing public mail- 46 ing list archives as well as private and shared message stores. 47 This document defines a URL scheme for referencing objects on an 48 IMAP server. 50 1. Conventions used in this document 52 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 53 in this document are to be interpreted as defined in "Key words for 54 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 56 2. IMAP scheme 58 The IMAP URL scheme is used to designate IMAP servers, mailboxes, 59 messages, MIME bodies [MIME], and search programs on Internet hosts 60 accessible using the IMAP protocol. 62 The IMAP URL follows the common Internet scheme syntax as defined 63 in [URI-GEN] <>. If : is omitted, the port defaults to 143. 66 An IMAP URL takes one of the following forms: 68 imap:/// 70 imap:///;TYPE= 72 imap:///[uidvalidity][?] 74 imap:///[uidvalidity] 75 [isection][ipartial] 77 The first form is used to refer to an IMAP server, the second form 78 refers to a list of mailboxes, the third form refers to the con- 79 tents of a mailbox or a set of messages resulting from a search, 80 and the final form refers to a specific message or message part, 81 and possibly a byte range in that part. Note that the syntax here 82 is informal. The authoritative formal syntax for IMAP URLs is 83 defined in section 11. The partial specifier semantics conforms to 84 [IMAP4] partial specifiers. 86 3. IMAP userinfo component 87 3.1. IMAP mailbox naming scope 89 The "enc-user" part of the "iuserinfo" component, if present, 90 denotes mailbox naming scope. If it is absent, the IMAP URL can 91 only reference mailboxes with globally unique names, i.e. mailboxes 92 with names that don't change depending on the user the client 93 authenticated as to the IMAP server. <> 96 For example, a personal mailbox described by the following URL 97 is most likely be different 98 from a personal mailbox described by 99 , even though both URLs use the 100 same mailbox name. 102 <> 108 3.2. IMAP User Name and Authentication Mechanism 110 The userinfo component [URI-GEN] of an IMAP URI may contains an 111 IMAP user Name (authorization identity, "enc-user") and/or an 112 authentication mechanism. (Note that the "enc-user" also defines a 113 mailbox naming scope as described in section 3.1). They are used 114 in the "LOGIN" or "AUTHENTICATE" commands after making the connec- 115 tion to the IMAP server. 117 If no user name or authentication mechanism is supplied, the client 118 must authenticate as anonymous to the server. If the server adver- 119 tises AUTH=ANONYMOUS IMAP capability, the client MUST use the 120 AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism. If 121 SASL ANONYMOUS is not available, the user name "anonymous" is used 122 with the "LOGIN" command and the password is supplied as the Inter- 123 net e-mail address of the end user accessing the resource. <> 126 If the URL doesn't supply a user name, the program interpreting the 127 IMAP URL SHOULD request one from the user (if it is an interactive 128 program) or configuration. 130 Note that as described in RFC 3501, the LOGIN command MUST NOT be 131 used when the IMAP server advertises the LOGINDISABLED capability. 133 An authentication mechanism can be expressed by adding ";AUTH=" to the end of the user name. When such an is indicated, the client SHOULD request appropriate creden- 136 tials from that mechanism and use the "AUTHENTICATE" command 137 instead of the "LOGIN" command. If no user name is specified, one 138 SHOULD be obtained from the mechanism or requested from the user as 139 appropriate. 141 The string ";AUTH=*" indicates that the client SHOULD select an 142 appropriate authentication mechanism. It MAY use any mechanism 143 listed in the CAPABILITY command or use an out of band security 144 service resulting in a PREAUTH connection. If no user name is 145 specified and no appropriate authentication mechanisms are avail- 146 able, the client SHOULD fall back to anonymous login as described 147 above. This allows a URL which grants read-write access to autho- 148 rized users, and read-only anonymous access to other users. 150 If a user name is included with no authentication mechanism, then 151 ";AUTH=*" is assumed. 153 Since URLs can easily come from untrusted sources, care must be 154 taken when resolving a URL which requires or requests any sort of 155 authentication. If authentication credentials are supplied to the 156 wrong server, it may compromise the security of the user's account. 157 The program resolving the URL should make sure it meets at least 158 one of the following criteria in this case: 160 (1) The URL comes from a trusted source, such as a referral server 161 which the client has validated and trusts according to site policy. 162 Note that user entry of the URL may or may not count as a trusted 163 source, depending on the experience level of the user and site pol- 164 icy. 165 (2) Explicit local site policy permits the client to connect to the 166 server in the URL. For example, if the client knows the site 167 domain name, site policy may dictate that any hostname ending in 168 that domain is trusted. 169 (3) The user confirms that connecting to that domain name with the 170 specified credentials and/or mechanism is permitted. 171 (4) A mechanism is used which validates the server before passing 172 potentially compromising client credentials. 173 (5) An authentication mechanism is used which will not reveal 174 information to the server which could be used to compromise future 175 connections. 177 URLs which do not include a user name must be treated with extra 178 care, since they are more likely to compromise the user's primary 179 account. A URL containing ";AUTH=*" must also be treated with 180 extra care since it might fall back on a weaker security mechanism. 181 Finally, clients are discouraged from using a plain text password 182 as a fallback with ";AUTH=*" unless the connection has strong 183 encryption. 185 A program interpreting IMAP URLs MAY cache open connections to an 186 IMAP server for later re-use. If a URL contains a user name, only 187 connections authenticated as that user may be re-used. If a URL 188 does not contain a user name or authentication mechanism, then only 189 an anonymous connection may be re-used. If a URL contains an 190 authentication mechanism without a user name, then any non-anony- 191 mous connection may be re-used. 193 Note that if unsafe or reserved characters such as " " or ";" are 194 present in the user name or authentication mechanism, they MUST be 195 encoded as described in [URI-GEN]. 197 <> 199 <> 201 4. IMAP server 203 An IMAP URL referring to an IMAP server has the following form: 205 imap:/// 207 A program interpreting this URL would issue the standard set of 208 commands it uses to present a view of the contents of an IMAP 209 server. This is likely to be semanticly equivalent to one of the 210 following URLs: 212 imap:///;TYPE=LIST 213 imap:///;TYPE=LSUB 215 See section 5 for details on how such URLs should be processed. 217 The program interpreting this URL SHOULD use the LSUB form if it 218 supports mailbox subscriptions. 220 5. Lists of mailboxes 222 An IMAP URL referring to a list of mailboxes has the following 223 form: 225 imap:///;TYPE= 227 The may be either "LIST" or "LSUB", and is case insen- 228 sitive. The field ";TYPE=" MUST be included. 230 The is any argument suitable for the list-mail- 231 box field of the IMAP [IMAP4] LIST or LSUB commands. The field 232 may be omitted, in which case the program inter- 233 preting the IMAP URL may use "*" or "%" as the . 234 The program SHOULD use "%" if it supports a hierarchical view, oth- 235 erwise it SHOULD use "*". 237 Note that if unsafe or reserved characters such as " " or "%" are 238 present in they MUST be encoded as described in 239 [URI-GEN]. If the character "/" is present in enc-list-mailbox, it 240 SHOULD NOT be encoded. 242 If the field is omitted or is defined to be "*" 243 or "%" the following procedure for listing mailboxes is RECOM- 244 MENDED: 246 The program SHOULD first use the NAMESPACE [NAMESPACE] command (if 247 supported by the server) to discover available namespaces, for 248 example: 250 C: A001 NAMESPACE 251 S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/")) 252 S: A001 OK NAMESPACE command completed 254 After that it should issue a LIST/LSUB command (as described by 255 ) for each namespace, suppressing redundant list com- 256 mands if the server lists mailboxes for multiple namespaces as a 257 result of a single list command. For example (continuing the exam- 258 ple above), the client first issues . If the server 259 returns information for mailboxes under the shared namespace prefix 260 "Public Folders/" the client should omit the subsequent command. 263 If the NAMESPACE command is not supported by the IMAP server, the 264 client SHOULD issue "" >. 266 <> 269 6. Lists of messages 271 An IMAP URL referring to a list of messages has the following form: 273 imap:///[uidvalidity][?] 275 The field is used as the argument to the IMAP4 276 "SELECT" command. Note that if unsafe or reserved characters such 277 as " ", ";", or "?" are present in they MUST be 278 encoded as described in [URI-GEN]. If the character "/" is present 279 in enc-mailbox, it SHOULD NOT be encoded. 281 The [uidvalidity] field is optional. If it is present, it MUST be 282 the argument to the IMAP4 UIDVALIDITY status response at the time 283 the URL was created. This SHOULD be used by the program interpret- 284 ing the IMAP URL to determine if the URL is stale. 286 The [?] field is optional. If it is not present, the 287 contents of the mailbox SHOULD be presented by the program inter- 288 preting the URL. If it is present, it SHOULD be used as the argu- 289 ments following an IMAP4 SEARCH command with unsafe characters such 290 as " " (which are likely to be present in the ) encoded 291 as described in [URI-GEN]. 293 7. A specific message or message part 295 An IMAP URL referring to a specific message or message part has the 296 following form: 298 imap:///[uidvalidity] 299 [isection][ipartial] 301 The and [uidvalidity] are as defined above. 303 If [uidvalidity] is present in this form, it SHOULD be used by the 304 program interpreting the URL to determine if the URL is stale. 306 The refers to an IMAP4 message UID, and SHOULD be used as 307 the argument to the IMAP4 "UID FETCH" command. 309 The [isection] field is optional. If not present, the URL refers 310 to the entire Internet message as returned by the IMAP command "UID 311 FETCH BODY.PEEK[]". If present, the URL refers to the object 312 returned by a "UID FETCH BODY.PEEK[
]" command. The 313 type of the object may be determined with a "UID FETCH BODYS- 314 TRUCTURE" command and locating the appropriate part in the result- 315 ing BODYSTRUCTURE. Note that unsafe characters in [isection] MUST 316 be encoded as described in [URI-GEN]. 318 The [ipartial] field is optional. If present, it effectively 319 appends "<>" to the end of the UID FETCH 320 BODY.PEEK[
] command constructed as described in the previ- 321 ous paragraph. In other words it allows the client to request a 322 byte range of the message/message part. 324 8. Relative IMAP URLs 326 Relative IMAP URLs are permitted and are resolved according to the 327 rules defined in [URI-GEN] with one exception. In IMAP URLs, 328 parameters are treated as part of the normal path with respect to 329 relative URL resolution. This is believed to be the behavior of 330 the installed base and is likely to be documented in a future revi- 331 sion of the relative URL specification. 333 The following observations are also important: 335 The grammar element is considered part of the user name for 336 purposes of resolving relative IMAP URLs. This means that unless a 337 new login/server specification is included in the relative URL, the 338 authentication mechanism is inherited from a base IMAP URL. 340 URLs always use "/" as the hierarchy delimiter for the purpose of 341 resolving paths in relative URLs. IMAP4 permits the use of any 342 hierarchy delimiter in mailbox names. For this reason, relative 343 mailbox paths will only work if the mailbox uses "/" as the hierar- 344 chy delimiter. Relative URLs may be used on mailboxes which use 345 other delimiters, but in that case, the entire mailbox name MUST be 346 specified in the relative URL or inherited as a whole from the base 347 URL. 349 The base URL for a list of mailboxes or messages which was referred 350 to by an IMAP URL is always the referring IMAP URL itself. The 351 base URL for a message or message part which was referred to by an 352 IMAP URL may be more complicated to determine. The program inter- 353 preting the relative URL will have to check the headers of the MIME 354 entity and any enclosing MIME entities in order to locate the "Con- 355 tent-Location" header. This header is used to determine the base 356 URL as defined in section 5 of [MHTML]. For example, if the refer- 357 ring IMAP URL contains a "/;SECTION=1.2" parameter, then the MIME 358 headers for section 1.2, for section 1, and for the enclosing mes- 359 sage itself SHOULD be checked in that order for "Content-Location" 360 headers. 362 9. Multinational Considerations 364 IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding non- 365 US-ASCII characters in IMAP mailbox names. Because this convention 366 is private to IMAP, it is necessary to convert IMAP's encoding to 367 one that can be more easily interpreted by a URL display program. 369 For this reason, IMAP's modified UTF-7 encoding for mailboxes MUST 370 be converted to UTF-8 [UTF8]. Since 8-bit characters are not per- 371 mitted in URLs, the UTF-8 characters are encoded as required by the 372 URL specification [URI-GEN], section 2.1. Sample code is included 373 in Appendix A to demonstrate this conversion. 375 IMAP usernames are UTF-8 strings and MUST be encoded as required by 376 the URL specification [URI-GEN], section 2.1. 378 Also note that IMAP SEARCH criteria can contain non US-ASCII char- 379 acters. 8-bit octets in those strings MUST be encoded as required 380 by the URL specification [URI-GEN], section 2.1. 382 10. Examples 384 The following examples demonstrate how an IMAP4 client program 385 might translate various IMAP4 URLs into a series of IMAP4 commands. 386 Commands sent from the client to the server are prefixed with "C:", 387 and responses sent from the server to the client are prefixed with 388 "S:". 390 The URL: 392 395 Results in the following client commands: 397 398 C: A001 LOGIN ANONYMOUS sheridan@babylon5.example.org 399 C: A002 SELECT gray-council 400 401 C: A003 UID FETCH 20 BODY.PEEK[]<0.1024> 403 The URL: 405 407 Results in the following client commands: 409 410 412 C: A001 LOGIN MICHAEL zipper 413 C: A002 LIST "" users.* 415 The URL: 417 420 Results in the following client commands: 422 423 C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org 424 C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw- 425 427 The URL: 429 432 Results in the following client commands: 434 435 C: A001 AUTHENTICATE GSSAPI 436 437 C: A002 SELECT gray-council 438 C: A003 UID FETCH 20 BODY.PEEK[1.2] 440 If the following relative URL is located in that body part: 442 <;section=1.4> 444 This could result in the following client commands: 446 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] 447 BODY.PEEK[1.MIME] 448 BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) 449 451 C: A005 UID FETCH 20 BODY.PEEK[1.4] 453 The URL: 455 458 Could result in the following: 460 461 C: A001 CAPABILITY 462 S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5 463 S: A001 OK 464 C: A002 AUTHENTICATE DIGEST-MD5 465 466 S: A002 OK user lennier authenticated 467 C: A003 SELECT "gray council" 468 ... 469 C: A004 SEARCH SUBJECT shadows 470 S: * SEARCH 8 10 13 14 15 16 471 S: A004 OK SEARCH completed 472 C: A005 FETCH 8,10,13:16 ALL 473 ... 475 NOTE: In this final example, the client has implementation depen- 476 dent choices. The authentication mechanism could be anything, 477 including PREAUTH. And the final FETCH command could fetch more or 478 less information about the messages, depending on what it wishes to 479 display to the user. 481 11. Security Considerations 483 Security considerations discussed in the IMAP specification [IMAP4] 484 and the URI specification [URI-GEN] are relevant. Security consid- 485 erations related to authenticated URLs are discussed in section 3 486 of this document. 488 Many email clients store the plain text password for later use 489 after logging into an IMAP server. Such clients MUST NOT use a 490 stored password in response to an IMAP URL without explicit permis- 491 sion from the user to supply that password to the specified host 492 name. 494 12. ABNF for IMAP URL scheme 496 Formal syntax is defined using ABNF [ABNF], extending the ABNF 497 rules in section 9 of [IMAP4]. Elements not defined here can be 498 found in the [ABNF], [IMAP4], [IMAPABNF] or [URI-GEN]. Strings are 499 not case sensitive and free insertion of linear-white-space is not 500 permitted. 502 uchar = unreserved | pct-encoded 504 achar = uchar / "&" / "=" 505 ;; <> 507 bchar = achar / ":" / "@" / "/" 508 ;; <> 510 enc-auth-type = 1*achar 511 ; encoded version of [IMAP4] "auth-type" 513 enc-list-mailbox = 1*bchar 514 ; encoded version of [IMAP4] "list-mailbox" 516 enc-mailbox = 1*bchar 517 ; encoded version of [IMAP4] "mailbox" 519 enc-search = 1*bchar 520 ; encoded version of [IMAPABNF] 521 ; "search-program". Note that IMAP4 522 ; literals may not be used in 523 ; a "search-program", i.e. only 524 ; quoted or non-synchronizing 525 ; literals (if the server supports 526 ; LITERAL+) are allowed. 527 <> 529 <> 531 enc-section = 1*bchar 532 ; encoded version of [IMAP4] "section-spec" 534 enc-user = 1*achar 535 ; encoded version of [IMAP4] authorization identiry 536 ; or "userid". 538 imapurl = "imap://" iserver "/" [ icommand ] 540 iauth = ";AUTH=" ( "*" / enc-auth-type ) 541 icommand = imailboxlist / imessagelist / imessagepart 543 imailboxlist = [enc-list-mailbox] ";TYPE=" list-type 545 imailbox-ref = enc-mailbox [uidvalidity] 546 ; <> 548 imessagelist = imailbox-ref [ "?" enc-search ] 549 ; "enc-search" is [URI-GEN] "query". 551 imessagepart = imailbox-ref iuid [isection] [ipartial] 553 ipartial = "/;PARTIAL=" partial-range 555 isection = "/;SECTION=" enc-section 557 iserver = [iuserinfo "@"] host [ ":" port ] 558 ; This is the same as "authority" defined 559 ; in [URI-GEN]. See [URI-GEN] for "host" 560 ; and "port" definitions. 562 iuid = "/;UID=" nz-number 563 ; See [IMAP4] for "nz-number" definition 565 iuserinfo = enc-user [iauth] / [enc-user] iauth 566 ; conforms to the generic syntax of 567 ; "userinfo" as defined in [URI-GEN]. 569 list-type = "LIST" / "LSUB" 571 partial-range = number ["." nz-number] 572 ; partial fetch 574 uidvalidity = ";UIDVALIDITY=" nz-number 575 ; See [IMAP4] for "nz-number" definition 577 13. IANA Considerations 579 IANA is requested to update "imap" definition in the "Uniform 580 Resource Identifier scheme registry" to point to this document. 582 The registration teplate (as per <>) is specified in section 13.1 of this docu- 584 ment. 586 13.1. IANA Registration of imap: URI Scheme 588 This section provides the information required to register the 589 imap: URI scheme. 591 URI scheme name: imap 593 Status: permanent 595 URI scheme syntax: 596 See section 12 of this RFC. 598 URI scheme semantics: 600 The imap: URI scheme is used to designate IMAP servers, mail- 601 boxes, messages, MIME bodies [MIME], and search programs on Inter- 602 net hosts accessible using the IMAP protocol. <> 605 There is no MIME type associated with this URI. 607 Encoding considerations: 609 See Section 9 of <<[this RFC]>>. 611 Applications/protocols that use this URI scheme name: 613 The imap: URI is intended to be used by applications that might 614 need access to IMAP mailstore. Such applications may include (but 615 not limited to) IMAP-capable web browsers; IMAP clients that wish 616 to access a mailbox, message, or edit a message on the server using 617 <<[CATENATE]>>; <<[SUBMIT]>> clients and servers that are requested 618 to assemble a complete message on submission using <<[BURL]>>. 620 Interoperability considerations: 622 Mozilla/Thubderbird use a different imap: scheme internally. 623 <> 625 Security considerations: 627 See Security Considerations (Section 11) of <<[this RFC]>>. 629 Contact: 631 Alexey Melnikov 633 Author/Change controller: 635 IESG 637 References: 639 [This RFC] and [IMAP4]. 641 14. Normative References 643 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Require- 644 ment Levels", RFC 2119, Harvard University, March 1997. 646 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 647 4rev1", RFC 3501, University of Washington, March 2003. 649 [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to 650 IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 652 [MHTML] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation 653 of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 654 1999. 656 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 657 ABNF", RFC 4234, October 2005. 659 [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail 660 Extensions", RFC 2045, Innosoft, First Virtual, November 1996. 662 [URI-GEN] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 663 Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. 665 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 666 10646", STD 63, RFC 3629, November 2003. 668 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 669 May 1998. 671 [ANONYMOUS] K. Zeilenga (Ed.), "The Anonymous SASL Mechanism", work 672 in progress, draft-ietf-sasl-anon-XX.txt (Obsoletes RFC 2245). 674 15. Author's Address 676 Chris Newman 677 Sun Microsystems 678 1050 Lakes Drive 679 West Covina, CA 91790 USA 680 EMail: chris.newman@sun.com 682 Alexey Melnikov (Editor) 683 Isode Limited 684 5 Castle Business Village 685 36 Station Road 686 Hampton, Middlesex 687 TW12 2BX, UK 688 Email: Alexey.Melnikov@isode.com 689 URI: http://www.melnikov.ca/ 691 Stephane H. Maes (Editor) 692 Oracle Corporation 693 500 Oracle Parkway 694 M/S 4op634 695 Redwood Shores, CA 94065 696 USA 697 Phone: +1-650-607-6296 698 Email: stephane.maes@oracle.com 700 Appendix A. Sample code 702 Here is sample C source code to convert between URL paths and IMAP mail- 703 box names, taking into account mapping between IMAP's modified UTF-7 704 [IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This 705 code has not been rigorously tested nor does it necessarily behave rea- 706 sonably with invalid input, but it should serve as a useful example. 707 This code just converts the mailbox portion of the URL and does not deal 708 with parameters, query or server components of the URL. 710 <> 712 #include 713 #include 715 /* hexadecimal lookup table */ 716 static char hex[] = "0123456789ABCDEF"; 718 /* URL unsafe printable characters */ 719 static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}"; 721 /* UTF7 modified base64 alphabet */ 722 static char base64chars[] = 723 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,"; 725 #define UNDEFINED 64 727 /* UTF16 definitions */ 728 #define UTF16MASK 0x03FFUL 729 #define UTF16SHIFT 10 730 #define UTF16BASE 0x10000UL 731 #define UTF16HIGHSTART 0xD800UL 732 #define UTF16HIGHEND 0xDBFFUL 733 #define UTF16LOSTART 0xDC00UL 734 #define UTF16LOEND 0xDFFFUL 736 /* Convert an IMAP mailbox to a URL path 737 * dst needs to have roughly 4 times the storage space of src 738 * Hex encoding can triple the size of the input 739 * UTF-7 can be slightly denser than UTF-8 740 * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) 741 */ 742 void MailboxToURL(char *dst, char *src) 743 { 744 unsigned char c, i, bitcount; 745 unsigned long ucs4, utf16, bitbuf; 746 unsigned char base64[256], utf8[6]; 748 /* initialize modified base64 decoding table */ 749 memset(base64, UNDEFINED, sizeof (base64)); 750 for (i = 0; i < sizeof (base64chars); ++i) { 751 base64[base64chars[i]] = i; 752 } 754 /* loop until end of string */ 755 while (*src != '\0') { 756 c = *src++; 757 /* deal with literal characters and &- */ 758 if (c != '&' || *src == '-') { 759 if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) { 760 /* hex encode if necessary */ 761 dst[0] = '%'; 762 dst[1] = hex[c >> 4]; 763 dst[2] = hex[c & 0x0f]; 764 dst += 3; 765 } else { 766 /* encode literally */ 767 *dst++ = c; 768 } 769 /* skip over the '-' if this is an &- sequence */ 770 if (c == '&') ++src; 771 } else { 772 /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ 773 bitbuf = 0; 774 bitcount = 0; 775 ucs4 = 0; 776 while ((c = base64[(unsigned char) *src]) != UNDEFINED) { 777 ++src; 778 bitbuf = (bitbuf << 6) | c; 779 bitcount += 6; 780 /* enough bits for a UTF-16 character? */ 781 if (bitcount >= 16) { 782 bitcount -= 16; 783 utf16 = (bitcount ? bitbuf >> bitcount 784 : bitbuf) & 0xffff; 785 /* convert UTF16 to UCS4 */ 786 if 787 (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { 788 ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; 789 continue; 790 } else if 791 (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { 792 ucs4 += utf16 - UTF16LOSTART + UTF16BASE; 793 } else { 794 ucs4 = utf16; 795 } 796 /* convert UTF-16 range of UCS4 to UTF-8 */ 797 if (ucs4 <= 0x7fUL) { 798 utf8[0] = ucs4; 799 i = 1; 800 } else if (ucs4 <= 0x7ffUL) { 801 utf8[0] = 0xc0 | (ucs4 >> 6); 802 utf8[1] = 0x80 | (ucs4 & 0x3f); 803 i = 2; 804 } else if (ucs4 <= 0xffffUL) { 805 utf8[0] = 0xe0 | (ucs4 >> 12); 806 utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f); 807 utf8[2] = 0x80 | (ucs4 & 0x3f); 808 i = 3; 809 } else { 810 utf8[0] = 0xf0 | (ucs4 >> 18); 811 utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f); 812 utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f); 813 utf8[3] = 0x80 | (ucs4 & 0x3f); 814 i = 4; 815 } 816 /* convert utf8 to hex */ 817 for (c = 0; c < i; ++c) { 818 dst[0] = '%'; 819 dst[1] = hex[utf8[c] >> 4]; 820 dst[2] = hex[utf8[c] & 0x0f]; 821 dst += 3; 822 } 823 } 824 } 825 /* skip over trailing '-' in modified UTF-7 encoding */ 826 if (*src == '-') ++src; 827 } 828 } 829 /* terminate destination string */ 830 *dst = '\0'; 831 } 833 /* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox 834 * dst should be about twice the length of src to deal with non-hex 835 * coded URLs 836 */ 837 void URLtoMailbox(char *dst, char *src) 838 { 839 unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag; 840 unsigned long ucs4, bitbuf; 841 unsigned char hextab[256]; 843 /* initialize hex lookup table */ 844 memset(hextab, 0, sizeof (hextab)); 845 for (i = 0; i < sizeof (hex); ++i) { 846 hextab[hex[i]] = i; 847 if (isupper(hex[i])) hextab[tolower(hex[i])] = i; 848 } 850 utf7mode = 0; 851 utf8total = 0; 852 bitstogo = 0; 853 while ((c = *src) != '\0') { 854 ++src; 855 /* undo hex-encoding */ 856 if (c == '%' && src[0] != '\0' && src[1] != '\0') { 857 c = (hextab[src[0]] << 4) | hextab[src[1]]; 858 src += 2; 859 } 860 /* normal character? */ 861 if (c >= ' ' && c <= '~') { 862 /* switch out of UTF-7 mode */ 863 if (utf7mode) { 864 if (bitstogo) { 865 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; 866 } 867 *dst++ = '-'; 868 utf7mode = 0; 870 } 871 *dst++ = c; 872 /* encode '&' as '&-' */ 873 if (c == '&') { 874 *dst++ = '-'; 875 } 876 continue; 877 } 878 /* switch to UTF-7 mode */ 879 if (!utf7mode) { 880 *dst++ = '&'; 881 utf7mode = 1; 882 } 883 /* Encode US-ASCII characters as themselves */ 884 if (c < 0x80) { 885 ucs4 = c; 886 utf8total = 1; 887 } else if (utf8total) { 888 /* save UTF8 bits into UCS4 */ 889 ucs4 = (ucs4 << 6) | (c & 0x3FUL); 890 if (++utf8pos < utf8total) { 891 continue; 892 } 893 } else { 894 utf8pos = 1; 895 if (c < 0xE0) { 896 utf8total = 2; 897 ucs4 = c & 0x1F; 898 } else if (c < 0xF0) { 899 utf8total = 3; 900 ucs4 = c & 0x0F; 901 } else { 902 /* NOTE: can't convert UTF8 sequences longer than 4 */ 903 utf8total = 4; 904 ucs4 = c & 0x03; 905 } 906 continue; 907 } 908 /* loop to split ucs4 into two utf16 chars if necessary */ 909 utf8total = 0; 910 do { 911 if (ucs4 >= UTF16BASE) { 912 ucs4 -= UTF16BASE; 913 bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) 914 + UTF16HIGHSTART); 915 ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; 916 utf16flag = 1; 917 } else { 918 bitbuf = (bitbuf << 16) | ucs4; 919 utf16flag = 0; 920 } 921 bitstogo += 16; 922 /* spew out base64 */ 923 while (bitstogo >= 6) { 924 bitstogo -= 6; 925 *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo) 926 : bitbuf) 927 & 0x3F]; 928 } 929 } while (utf16flag); 930 } 931 /* if in UTF-7 mode, finish in ASCII */ 932 if (utf7mode) { 933 if (bitstogo) { 934 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; 935 } 936 *dst++ = '-'; 937 } 938 /* tie off string */ 939 *dst = '\0'; 940 } 942 Appendix B. List of changes since RFC 2192 944 Updated boilerplate, list of editor's, etc. 945 Updated references. 946 Updated ABNF not to use _, to use SP instead of SPACE. 947 Updated example domains to use example.org. 948 Fixed ABNF error in "imessagelist" non-terminal. 949 Updated ABNF, due to changes in RFC 3501, IMAPABNF and RFC 3986. 950 Renamed "iuserauth" non-terminal to "iuserinfo". 951 Clarified that the userinfo component describes both authorization 952 identity and mailbox naming scope. 953 Added "ipartial" specifier that denotes a partial fetch. 955 Intellectual Property 957 The IETF takes no position regarding the validity or scope of any 958 Intellectual Property Rights or other rights that might be claimed 959 to pertain to the implementation or use of the technology 960 described in this document or the extent to which any license 961 under such rights might or might not be available; nor does it 962 represent that it has made any independent effort to identify any 963 such rights. Information on the procedures with respect to rights 964 in RFC documents can be found in BCP 78 and BCP 79. 966 Copies of IPR disclosures made to the IETF Secretariat and any 967 assurances of licenses to be made available, or the result of an 968 attempt made to obtain a general license or permission for the use 969 of such proprietary rights by implementers or users of this 970 specification can be obtained from the IETF on-line IPR repository 971 at http://www.ietf.org/ipr. 973 The IETF invites any interested party to bring to its attention 974 any copyrights, patents or patent applications, or other 975 proprietary rights that may cover technology that may be required 976 to implement this standard. Please address the information to the 977 IETF at ietf-ipr@ietf.org. 979 Full Copyright Statement 981 Copyright (C) The Internet Society (2006). 983 This document is subject to the rights, licenses and restrictions 984 contained in BCP 78, and except as set forth therein, the authors 985 retain all their rights. 987 This document and the information contained herein are provided on an 988 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 989 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 990 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 991 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 992 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 993 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 995 Acknowledgement 997 Funding for the RFC Editor function is currently provided by the 998 Internet Society.