]" command. The 335 type of the object may be determined with a "UID FETCH BODYS- 336 TRUCTURE" command and locating the appropriate part in the result- 337 ing BODYSTRUCTURE. Note that unsafe characters in [isection] MUST 338 be encoded as described in [URI-GEN]. 340 The [ipartial] field is optional. If present, it effectively 341 appends "<>" to the end of the UID FETCH 342 BODY.PEEK[

] command constructed as described in the previ- 343 ous paragraph. In other words it allows the client to request a 344 byte range of the message/message part. 346 7.1 URLAUTH authorized URL 348 <> 351 7.1.1. Concepts 353 7.1.1.1. URLAUTH 355 The URLAUTH is a component, appended at the end of a URL, which 356 conveys authorization to access the data addressed by that URL. It 357 contains an authorized access identifier, an authorization mecha- 358 nism name, and an authorization token. The authorization token is 359 generated from the URL, the authorized access identifer, authoriza- 360 tion mechanism name, and a mailbox access key. 362 7.1.1.2. Mailbox Access Key 363 The mailbox access key is a random string with at least 128 bits of 364 entropy. It is generated by software (not by the human user), and 365 MUST be unpredictable. 367 Each user has a table of mailboxes and an associated mailbox access 368 key for each mailbox. Consequently, the mailbox access key is per- 369 user and per-mailbox. In other words, two users sharing the same 370 mailbox each have a different mailbox access key for that mailbox, 371 and each mailbox accessed by a single user also has a different 372 mailbox access key. 374 7.1.1.3. Authorized Access Identifier 376 The authorized access identifier restricts use of the URLAUTH 377 authorized URL to certain users authorized on the server, as 378 described in section 7.1.2. 380 7.1.1.4. Authorization Mechanism 382 The authorization mechanism is the algorithm by which the URLAUTH 383 is generated and subsequently verified, using the mailbox access 384 key. 386 7.1.1.5. Authorization Token 388 The authorization token is a deterministic string of at least 128 389 bits which an entity with knowledge of the secret mailbox access 390 key and URL authorization mechanism can use to verify the URL. 392 7.1.2. URLAUTH extensions to IMAP URL 394 A specific message or message part IMAP URL can optionally contain 395 ";EXPIRE=" and ";URLAUTH=::". 397 The URLAUTH is comprised of ";URLAUTH=::", and 398 MUST be at the end of the URL. 400 When ";EXPIRE=" is used, this indicates the latest date 401 and time that the URL is valid. After that date and time, the URL 402 has expired and server implementations MUST reject the URL. If 403 ";EXPIRE=" is not used, the URL has no expiration, <>. 406 The URLAUTH takes the form ";URLAUTH=::". It 407 is composed of three parts. The portion provides the 408 authorized access identifiers which may constrain the operations 409 and users that are permitted to use this URL. The portion 410 provides the authorization mechanism used by the IMAP server to 411 generate the authorization token that follows. The portion 412 provides authorization token. <> 414 The "submit+" access identifier prefix, followed by a userid, indi- 415 cates that only a userid authorized as a message submission entity 416 on behalf of the specified userid is permitted to use this URL. 417 The IMAP server does not validate the specified userid but does 418 validate that the IMAP session has an authorization identity that 419 is authorized as a message submission entity. The authorized mes- 420 sage submission entity MUST validate the userid prior to contacting 421 the IMAP server. 423 The "user+" access identifier prefix, followed by a userid, indi- 424 cates that use of this URL is limited to IMAP sessions which are 425 logged in as the specified userid (that is, have authorization 426 identity as that userid). 428 Note: if a SASL mechanism which provides both authorization and 429 authentication identifiers is used to authenticate to the IMAP 430 server, the "user+" access identifier MUST match the authoriza- 431 tion identifier. If the SASL mechanism can't transport the 432 authorization identifier, the "user+" access identifier MUST 433 match the authorization identifier derived from the authentica- 434 tion identifier (see [SASL]). 436 The "authuser" access identifier indicates that use of this URL is 437 limited to IMAP sessions which are logged in as an authorized user 438 (that is, have authorization identity as an authorized user) of 439 that IMAP server. Use of this URL is prohibited to anonymous IMAP 440 sessions. 442 The "anonymous" access identifier indicates that use of this URL is 443 not restricted by session authorization identity; that is, any IMAP 444 session in authenticated or selected state (as defined in [IMAP4]), 445 including anonymous sessions, may issue a URLFETCH [URLAUTH] using 446 this URL. 448 The authorization token is represented as an ASCII-encoded hexadec- 449 imal string, which is used to authorize the URL. The length and 450 the calculation of the authorization token depends upon the 451 mechanism used; but, in all cases, the authorization token is at 452 least 128 bits (and therefore at least 32 hexadecimal digits). 454 8. Relative IMAP URLs 456 Relative IMAP URLs are permitted and are resolved according to the 457 rules defined in [URI-GEN] <>. In IMAP URLs, 458 parameters are treated as part of the normal path with respect to 459 relative URL resolution. 461 The following observations are also important: 463 The grammar element is considered part of the user name for 464 purposes of resolving relative IMAP URLs. This means that unless a 465 new login/server specification is included in the relative URL, the 466 authentication mechanism is inherited from a base IMAP URL. 468 URLs always use "/" as the hierarchy delimiter for the purpose of 469 resolving paths in relative URLs. IMAP4 permits the use of any 470 hierarchy delimiter in mailbox names. For this reason, relative 471 mailbox paths will only work if the mailbox uses "/" as the hierar- 472 chy delimiter. Relative URLs may be used on mailboxes which use 473 other delimiters, but in that case, the entire mailbox name MUST be 474 specified in the relative URL or inherited as a whole from the base 475 URL. 477 <> 490 If an IMAP server uses "/" as the IMAP mailbox hierarchy delimiter 491 and allows for mailbox named "." or ".." at any level of mailbox 492 hierarchy, then such mailbox names MUST be encoded as described in 493 [URI-GEN]. Otherwise they would be misinterpreted as dot-segments 494 (see Section 3.3 of [URI-GEN]), which are processed specially dur- 495 ing relative path resolution process. <> 500 8.1. absolute-path References 502 A relative reference that begins with a single slash character is 503 termed an absolute-path reference [URI-GEN]. Note that if an IMAP 504 server is allowing for leading "/" in mailbox names, the first 505 leading "/" MUST be encoded as described in [URI-GEN]. Otherwise 506 the produced absolute-path reference URI will be misinterpreted as 507 a network-path reference [URI-GEN]. 509 8.2. relative-path References 511 A relative reference that does not begin with a slash character is 512 termed a relative-path reference [URI-GEN]. Implementations SHOULD 513 NOT generate or accept relative-path IMAP references. 515 See also section 4.2 of [URI-GEN] for restrictions on relative-path 516 references. 518 9. Multinational Considerations 520 IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding non- 521 US-ASCII characters in IMAP mailbox names. Because this convention 522 is private to IMAP, it is necessary to convert IMAP's encoding to 523 one that can be more easily interpreted by a URL display program. 524 For this reason, IMAP's modified UTF-7 encoding for mailboxes MUST 525 be converted to UTF-8 [UTF-8]. Since 8-bit characters are not per- 526 mitted in URLs, the UTF-8 characters are encoded as required by the 527 URL specification [URI-GEN], section 2.1. Sample code is included 528 in Appendix A to demonstrate this conversion. 530 IMAP usernames are UTF-8 strings and MUST be encoded as required by 531 the URL specification [URI-GEN], section 2.1. 533 Also note that IMAP SEARCH criteria can contain non US-ASCII char- 534 acters. 8-bit octets in those strings MUST be encoded as required 535 by the URL specification [URI-GEN], section 2.1. 537 10. Examples 539 The following examples demonstrate how an IMAP4 client program 540 might translate various IMAP4 URLs into a series of IMAP4 commands. 542 Commands sent from the client to the server are prefixed with "C:", 543 and responses sent from the server to the client are prefixed with 544 "S:". 546 The URL: 548 551 Results in the following client commands: 553 554 C: A001 LOGIN ANONYMOUS sheridan@babylon5.example.org 555 C: A002 SELECT gray-council 556 557 C: A003 UID FETCH 20 BODY.PEEK[]<0.1024> 559 The URL: 561 563 Results in the following client commands: 565 566 568 C: A001 LOGIN MICHAEL zipper 569 C: A002 LIST "" users.* 571 The URL: 573 576 Results in the following client commands: 578 579 C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org 580 C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw- 581 583 The URL: 585 588 Results in the following client commands: 590 591 C: A001 AUTHENTICATE GSSAPI 592 593 C: A002 SELECT gray-council 594 C: A003 UID FETCH 20 BODY.PEEK[1.2] 596 If the following relative URL is located in that body part: 598 <;section=1.4> 600 This could result in the following client commands: 602 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] 603 BODY.PEEK[1.MIME] 604 BODY.PEEK[HEADER.FIELDS (Content-Location)]) 605 607 C: A005 UID FETCH 20 BODY.PEEK[1.4] 609 The URL: 611 614 Could result in the following: 616 617 C: A001 CAPABILITY 618 S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5 619 S: A001 OK 620 C: A002 AUTHENTICATE DIGEST-MD5 621 622 S: A002 OK user lennier authenticated 623 C: A003 SELECT "gray council" 624 ... 625 C: A004 SEARCH SUBJECT shadows 626 S: * SEARCH 8 10 13 14 15 16 627 S: A004 OK SEARCH completed 628 C: A005 FETCH 8,10,13:16 ALL 629 ... 631 NOTE: In this final example, the client has implementation depen- 632 dent choices. The authentication mechanism could be anything, 633 including PREAUTH. And the final FETCH command could fetch more or 634 less information about the messages, depending on what it wishes to 635 display to the user. 637 The URL: 639 643 shows that 8-bit data can be sent using non-synchronizing literals 644 [LITERAL+]. This could result in the following: 646 647 C: A001 CAPABILITY 648 S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5 649 S: A001 OK 650 C: A002 AUTHENTICATE DIGEST-MD5 651 652 S: A002 OK user john authenticated 653 C: A003 SELECT babylon5/personel 654 ... 655 C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+} 656 C: XXXXXXXXXXXXXX 657 S: * SEARCH 7 10 12 658 S: A004 OK SEARCH completed 659 C: A005 FETCH 7,10,12 ALL 660 ... 662 Where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified 663 in the URL above. 665 10.1. Examples of relative URLs 667 The following absolute-path reference 669 671 is the same as 673 675 I.e. both of them reference the mailbox "foo". 677 The following relative-path reference 678 <;UID=20> 680 references a message with UID in the mailbox specified by the Base 681 URI. 683 <..;UIDVALIDITY=385759045/;UID=20> <> 686 11. Security Considerations 688 Security considerations discussed in the IMAP specification [IMAP4] 689 and the URI specification [URI-GEN] are relevant. Security consid- 690 erations related to authenticated URLs are discussed in section 3 691 of this document. 693 Many email clients store the plain text password for later use 694 after logging into an IMAP server. Such clients MUST NOT use a 695 stored password in response to an IMAP URL without explicit permis- 696 sion from the user to supply that password to the specified host 697 name. 699 12. ABNF for IMAP URL scheme 701 Formal syntax is defined using ABNF [ABNF], extending the ABNF 702 rules in section 9 of [IMAP4]. Elements not defined here can be 703 found in the [ABNF], [IMAP4], [IMAPABNF] or [URI-GEN]. Strings are 704 not case sensitive and free insertion of linear-white-space is not 705 permitted. 707 sub-delims-sh = "!" / "$" / "'" / "(" / ")" / 708 "*" / "+" / "," 709 ;; <> 718 bchar = achar / ":" / "@" / "/" 720 enc-auth-type = 1*achar 721 ; encoded version of [IMAP4] "auth-type" 723 enc-list-mailbox = 1*bchar 724 ; encoded version of [IMAP4] "list-mailbox" 726 enc-mailbox = 1*bchar 727 ; encoded version of [IMAP4] "mailbox" 729 enc-search = 1*bchar 730 ; encoded version of [IMAPABNF] 731 ; "search-program". Note that IMAP4 732 ; literals may not be used in 733 ; a "search-program", i.e. only 734 ; quoted or non-synchronizing 735 ; literals (if the server supports 736 ; LITERAL+ [LITERAL+]) are allowed. 738 enc-section = 1*bchar 739 ; encoded version of [IMAP4] "section-spec" 741 enc-user = 1*achar 742 ; encoded version of [IMAP4] authorization identity 743 ; or "userid". 745 imapurl = "imap://" iserver ipath-query 746 ; Defines an absolute IMAP URL 748 ipath-query = ["/" [ icommand ]] 749 ; <> 750 ; Corresponds to "path-abempty [ "?" query ]" 751 ; in [URI-GEN] 753 Generic syntax for relative URLs is defined in Section 4.2 754 of [URI-GEN]. For ease of implementation, the relative 755 IMAP URL syntax is defined below: 757 imapurl-rel = inetwork-path 758 / iabsolute-path 759 / irelative-path 760 / ipath-empty 762 inetwork-path = "//" iserver ipath-query 763 ; Corresponds to '"//" authority path-abempty 764 ; [ "?" query ]' in [URI-GEN] 766 iabsolute-path = "/" [ icommand ] 767 ; icommand, if present, MUST NOT start with '/'. 768 ; 769 ; Corresponds to 'path-absolute [ "?" query ]' 770 ; in [URI-GEN] 772 <> 774 irelative-path = imailboxlist / 775 imessagelist / 776 ( imsg-or-part [iurlauth] ) 777 ; Corresponds to 'path-noscheme [ "?" query ]' 778 ; in [URI-GEN] 780 <> 782 imsg-or-part = ( imailbox-ref "/" iuid-only ["/" isection-only] 783 ["/" ipartial-only] ) / 784 ( iuid-only ["/" isection-only] 785 ["/" ipartial-only] ) / 786 ( isection-only ["/" ipartial-only] ) / 787 ipartial-only 789 ipath-empty = 0 790 ; Zero characters. 791 ; Corresponds to the relative form of "an IMAP server" 792 ; URL 794 The following 3 rules are only used in the presence of IMAP 795 URLAUTH extension: 797 authimapurl = "imap://" iserver "/" imessagepart 798 ; Same as "imapurl" when "[icommand]" is 799 ; "imessagepart" 801 authimapurlfull = authimapurl iurlauth 802 ; Same as "imapurl" when "[icommand]" is 803 ; "imessagepart iurlauth" 805 authimapurlrump = authimapurl iurlauth-rump 807 <> 811 enc-urlauth = 32*HEXDIG 813 iurlauth = iurlauth-rump iua-verifier 815 iua-verifier = ":" uauth-mechanism ":" enc-urlauth 816 iurlauth-rump = [expire] ";URLAUTH=" access 818 access = ("submit+" enc-user) / ("user+" enc-user) / 819 "authuser" / "anonymous" 821 expire = ";EXPIRE=" date-time 822 ; date-time defined in [DATETIME] 824 uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".") 825 ; Case-insensitive. 826 ; New mechanisms MUST be registered with IANA. 827 ; <> 829 iauth = ";AUTH=" ( "*" / enc-auth-type ) 831 icommand = imailboxlist / 832 imessagelist / 833 imessagepart [iurlauth] 835 imailboxlist = [enc-list-mailbox] ";TYPE=" list-type 837 imailbox-ref = enc-mailbox [uidvalidity] 838 ; <> 840 imessagelist = imailbox-ref [ "?" enc-search ] 841 ; "enc-search" is [URI-GEN] "query". 843 imessagepart = imailbox-ref iuid [isection] [ipartial] 845 ipartial = "/" ipartial-only 847 ipartial-only = ";PARTIAL=" partial-range 848 ; <> 850 isection = "/" isection-only 852 isection-only = ";SECTION=" enc-section 853 ; <> 855 iserver = [iuserinfo "@"] host [ ":" port ] 856 ; This is the same as "authority" defined 857 ; in [URI-GEN]. See [URI-GEN] for "host" 858 ; and "port" definitions. 860 iuid = "/" iuid-only 862 iuid-only = ";UID=" nz-number 863 ; <> 864 ; See [IMAP4] for "nz-number" definition 866 iuserinfo = enc-user [iauth] / [enc-user] iauth 867 ; conforms to the generic syntax of 868 ; "userinfo" as defined in [URI-GEN]. 870 list-type = "LIST" / "LSUB" 872 partial-range = number ["." nz-number] 873 ; partial fetch 875 uidvalidity = ";UIDVALIDITY=" nz-number 876 ; See [IMAP4] for "nz-number" definition 878 13. IANA Considerations 880 IANA is requested to update "imap" definition in the "Uniform 881 Resource Identifier scheme registry" to point to this document. 883 The registration template (as per <>) is specified in section 13.1 of this docu- 885 ment. 887 13.1. IANA Registration of imap: URI Scheme 889 This section provides the information required to register the 890 imap: URI scheme. 892 URI scheme name: imap 894 Status: permanent 896 URI scheme syntax: 897 See section 12 of this RFC. 899 URI scheme semantics: 901 The imap: URI scheme is used to designate IMAP servers, mail- 902 boxes, messages, MIME bodies [MIME], and search programs on Inter- 903 net hosts accessible using the IMAP protocol. <> 906 There is no MIME type associated with this URI. 908 Encoding considerations: 910 See Section 9 of <<[this RFC]>>. 912 Applications/protocols that use this URI scheme name: 914 The imap: URI is intended to be used by applications that might 915 need access to IMAP mailstore. Such applications may include (but 916 not limited to) IMAP-capable web browsers; IMAP clients that wish 917 to access a mailbox, message, or edit a message on the server using 918 [CATENATE]; [SUBMIT] clients and servers that are requested to 919 assemble a complete message on submission using [BURL]. 921 Interoperability considerations: 923 A widely deployed IMAP client Mozilla/Thubderbird use a differ- 924 ent imap: scheme internally. <> 926 Security considerations: 928 See Security Considerations (Section 11) of <<[this RFC]>>. 930 Contact: 932 Alexey Melnikov 934 Author/Change controller: 936 IESG 938 References: 940 [This RFC] and [IMAP4]. 942 14. References 944 14.1. Normative References 946 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Require- 947 ment Levels", BCP 14, RFC 2119, Harvard University, March 1997. 949 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 950 4rev1", RFC 3501, University of Washington, March 2003. 952 [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to 953 IMAP4 ABNF", RFC 4466, April 2006. 955 [MHTML] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation 956 of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 957 1999. 959 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 960 ABNF", RFC 4234, October 2005. 962 [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail 963 Extensions", RFC 2045, November 1996. 965 [URI-GEN] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 966 Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. 968 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 969 10646", STD 63, RFC 3629, November 2003. 971 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 972 May 1998. 974 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 975 January 1997. 977 [ANONYMOUS] K. Zeilenga (Ed.), "The Anonymous SASL Mechanism", work 978 in progress, draft-ietf-sasl-anon-XX.txt (Obsoletes RFC 2245). 979 <> 981 [DATETIME] Klyne, G., and Newman, C., "Date and Time on the Inter- 982 net: Timestamps", RFC 3339, July 2002. 984 14.2. Informative References 986 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 987 RFC 4409, April 2006. 989 [BURL] Newman, C. "Message Submission BURL Extension", RFC 4468, 990 May 2006. 992 [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) 993 CATENATE Extension", RFC 4469, April 2006. 995 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 996 Security Layer (SASL)", RFC 4422, June 2006. 998 15. Author's Address 1000 Chris Newman 1001 Sun Microsystems 1002 3401 Centrelake Dr., Suite 410 1003 Ontario, CA 91761 1004 EMail: chris.newman@sun.com 1006 Alexey Melnikov (Editor) 1007 Isode Limited 1008 5 Castle Business Village 1009 36 Station Road 1010 Hampton, Middlesex 1011 TW12 2BX, UK 1012 Email: Alexey.Melnikov@isode.com 1013 URI: http://www.melnikov.ca/ 1015 Stephane H. Maes (Editor) 1016 Oracle Corporation 1017 500 Oracle Parkway 1018 M/S 4op634 1019 Redwood Shores, CA 94065 1020 USA 1021 Phone: +1-650-607-6296 1022 Email: stephane.maes@oracle.com 1024 Appendix A. Sample code 1026 Here is sample C source code to convert between URL paths and IMAP mail- 1027 box names, taking into account mapping between IMAP's modified UTF-7 1028 [IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This 1029 code has not been rigorously tested nor does it necessarily behave rea- 1030 sonably with invalid input, but it should serve as a useful example. 1031 This code just converts the mailbox portion of the URL and does not deal 1032 with parameters, query or server components of the URL. 1034 <> 1036 #include 1037 #include 1039 /* hexadecimal lookup table */ 1040 static char hex[] = "0123456789ABCDEF"; 1042 /* URL unsafe printable characters */ 1043 static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}"; 1045 /* UTF7 modified base64 alphabet */ 1046 static char base64chars[] = 1047 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,"; 1048 #define UNDEFINED 64 1050 /* UTF16 definitions */ 1051 #define UTF16MASK 0x03FFUL 1052 #define UTF16SHIFT 10 1053 #define UTF16BASE 0x10000UL 1054 #define UTF16HIGHSTART 0xD800UL 1055 #define UTF16HIGHEND 0xDBFFUL 1056 #define UTF16LOSTART 0xDC00UL 1057 #define UTF16LOEND 0xDFFFUL 1059 /* Convert an IMAP mailbox to a URL path 1060 * dst needs to have roughly 4 times the storage space of src 1061 * Hex encoding can triple the size of the input 1062 * UTF-7 can be slightly denser than UTF-8 1063 * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) 1064 */ 1065 void MailboxToURL(char *dst, char *src) 1066 { 1067 unsigned char c, i, bitcount; 1068 unsigned long ucs4, utf16, bitbuf; 1069 unsigned char base64[256], utf8[6]; 1071 /* initialize modified base64 decoding table */ 1072 memset(base64, UNDEFINED, sizeof (base64)); 1073 for (i = 0; i < sizeof (base64chars); ++i) { 1074 base64[base64chars[i]] = i; 1075 } 1077 /* loop until end of string */ 1078 while (*src != '\0') { 1079 c = *src++; 1080 /* deal with literal characters and &- */ 1081 if (c != '&' || *src == '-') { 1082 if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) { 1083 /* hex encode if necessary */ 1084 dst[0] = '%'; 1085 dst[1] = hex[c >> 4]; 1086 dst[2] = hex[c & 0x0f]; 1087 dst += 3; 1088 } else { 1089 /* encode literally */ 1090 *dst++ = c; 1091 } 1092 /* skip over the '-' if this is an &- sequence */ 1093 if (c == '&') ++src; 1094 } else { 1095 /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ 1096 bitbuf = 0; 1097 bitcount = 0; 1098 ucs4 = 0; 1099 while ((c = base64[(unsigned char) *src]) != UNDEFINED) { 1100 ++src; 1101 bitbuf = (bitbuf << 6) | c; 1102 bitcount += 6; 1103 /* enough bits for a UTF-16 character? */ 1104 if (bitcount >= 16) { 1105 bitcount -= 16; 1106 utf16 = (bitcount ? bitbuf >> bitcount 1107 : bitbuf) & 0xffff; 1108 /* convert UTF16 to UCS4 */ 1109 if 1110 (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { 1111 ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; 1112 continue; 1113 } else if 1114 (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { 1115 ucs4 += utf16 - UTF16LOSTART + UTF16BASE; 1116 } else { 1117 ucs4 = utf16; 1118 } 1119 /* convert UTF-16 range of UCS4 to UTF-8 */ 1120 if (ucs4 <= 0x7fUL) { 1121 utf8[0] = ucs4; 1122 i = 1; 1123 } else if (ucs4 <= 0x7ffUL) { 1124 utf8[0] = 0xc0 | (ucs4 >> 6); 1125 utf8[1] = 0x80 | (ucs4 & 0x3f); 1126 i = 2; 1127 } else if (ucs4 <= 0xffffUL) { 1128 utf8[0] = 0xe0 | (ucs4 >> 12); 1129 utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f); 1130 utf8[2] = 0x80 | (ucs4 & 0x3f); 1131 i = 3; 1132 } else { 1133 utf8[0] = 0xf0 | (ucs4 >> 18); 1134 utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f); 1135 utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f); 1136 utf8[3] = 0x80 | (ucs4 & 0x3f); 1137 i = 4; 1138 } 1139 /* convert utf8 to hex */ 1140 for (c = 0; c < i; ++c) { 1141 dst[0] = '%'; 1142 dst[1] = hex[utf8[c] >> 4]; 1143 dst[2] = hex[utf8[c] & 0x0f]; 1144 dst += 3; 1145 } 1146 } 1147 } 1148 /* skip over trailing '-' in modified UTF-7 encoding */ 1149 if (*src == '-') ++src; 1150 } 1151 } 1152 /* terminate destination string */ 1153 *dst = '\0'; 1154 } 1156 /* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox 1157 * dst should be about twice the length of src to deal with non-hex 1158 * coded URLs 1159 */ 1160 void URLtoMailbox(char *dst, char *src) 1161 { 1162 unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag; 1163 unsigned long ucs4, bitbuf; 1164 unsigned char hextab[256]; 1166 /* initialize hex lookup table */ 1167 memset(hextab, 0, sizeof (hextab)); 1168 for (i = 0; i < sizeof (hex); ++i) { 1169 hextab[hex[i]] = i; 1170 if (isupper(hex[i])) hextab[tolower(hex[i])] = i; 1171 } 1173 utf7mode = 0; 1174 utf8total = 0; 1175 bitstogo = 0; 1176 while ((c = *src) != '\0') { 1177 ++src; 1178 /* undo hex-encoding */ 1179 if (c == '%' && src[0] != '\0' && src[1] != '\0') { 1180 c = (hextab[src[0]] << 4) | hextab[src[1]]; 1181 src += 2; 1182 } 1183 /* normal character? */ 1184 if (c >= ' ' && c <= '~') { 1185 /* switch out of UTF-7 mode */ 1186 if (utf7mode) { 1187 if (bitstogo) { 1188 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; 1189 } 1190 *dst++ = '-'; 1191 utf7mode = 0; 1192 } 1193 *dst++ = c; 1194 /* encode '&' as '&-' */ 1195 if (c == '&') { 1196 *dst++ = '-'; 1197 } 1198 continue; 1199 } 1200 /* switch to UTF-7 mode */ 1201 if (!utf7mode) { 1202 *dst++ = '&'; 1203 utf7mode = 1; 1204 } 1205 /* Encode US-ASCII characters as themselves */ 1206 if (c < 0x80) { 1207 ucs4 = c; 1208 utf8total = 1; 1209 } else if (utf8total) { 1210 /* save UTF8 bits into UCS4 */ 1211 ucs4 = (ucs4 << 6) | (c & 0x3FUL); 1212 if (++utf8pos < utf8total) { 1213 continue; 1214 } 1215 } else { 1216 utf8pos = 1; 1217 if (c < 0xE0) { 1218 utf8total = 2; 1219 ucs4 = c & 0x1F; 1220 } else if (c < 0xF0) { 1221 utf8total = 3; 1222 ucs4 = c & 0x0F; 1223 } else { 1224 /* NOTE: can't convert UTF8 sequences longer than 4 */ 1225 utf8total = 4; 1226 ucs4 = c & 0x03; 1227 } 1228 continue; 1229 } 1230 /* loop to split ucs4 into two utf16 chars if necessary */ 1231 utf8total = 0; 1232 do { 1233 if (ucs4 >= UTF16BASE) { 1234 ucs4 -= UTF16BASE; 1235 bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) 1236 + UTF16HIGHSTART); 1237 ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; 1238 utf16flag = 1; 1239 } else { 1240 bitbuf = (bitbuf << 16) | ucs4; 1241 utf16flag = 0; 1242 } 1243 bitstogo += 16; 1244 /* spew out base64 */ 1245 while (bitstogo >= 6) { 1246 bitstogo -= 6; 1247 *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo) 1248 : bitbuf) 1249 & 0x3F]; 1250 } 1251 } while (utf16flag); 1252 } 1253 /* if in UTF-7 mode, finish in ASCII */ 1254 if (utf7mode) { 1255 if (bitstogo) { 1256 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; 1257 } 1258 *dst++ = '-'; 1259 } 1260 /* tie off string */ 1261 *dst = '\0'; 1262 } 1264 Appendix B. List of changes since RFC 2192 1266 <> 1267 Updated boilerplate, list of editor's, etc. 1268 Updated references. 1269 Updated ABNF not to use _, to use SP instead of SPACE, etc. 1270 Updated example domains to use example.org. 1271 Fixed ABNF error in "imessagelist" non-terminal. 1272 Updated ABNF, due to changes in RFC 3501, RFC 4466 and RFC 3986. 1274 Renamed "iuserauth" non-terminal to "iuserinfo". 1275 Clarified that the userinfo component describes both authorization 1276 identity and mailbox naming scope. 1277 Allow for non-synchronizing literals in "enc-search". 1278 Added "ipartial" specifier that denotes a partial fetch. 1279 Moved URLAUTH text from RFC 4467 to this document. 1280 Added more examples demonstrating relative-path references. 1281 Updated ABNF for the whole server to allow missing trailing "/" 1282 (e.g. "imap://imap.example.com" is now valid and is the same as 1283 "imap://imap.example.com/") 1284 Added rules for relative URLs and restructured ABNF as the result. 1286 Intellectual Property 1288 The IETF takes no position regarding the validity or scope of any 1289 Intellectual Property Rights or other rights that might be claimed 1290 to pertain to the implementation or use of the technology 1291 described in this document or the extent to which any license 1292 under such rights might or might not be available; nor does it 1293 represent that it has made any independent effort to identify any 1294 such rights. Information on the procedures with respect to rights 1295 in RFC documents can be found in BCP 78 and BCP 79. 1297 Copies of IPR disclosures made to the IETF Secretariat and any 1298 assurances of licenses to be made available, or the result of an 1299 attempt made to obtain a general license or permission for the use 1300 of such proprietary rights by implementers or users of this 1301 specification can be obtained from the IETF on-line IPR repository 1302 at http://www.ietf.org/ipr. 1304 The IETF invites any interested party to bring to its attention 1305 any copyrights, patents or patent applications, or other 1306 proprietary rights that may cover technology that may be required 1307 to implement this standard. Please address the information to the 1308 IETF at ietf-ipr@ietf.org. 1310 Full Copyright Statement 1312 Copyright (C) The Internet Society (2006). 1314 This document is subject to the rights, licenses and restrictions 1315 contained in BCP 78, and except as set forth therein, the authors 1316 retain all their rights. 1318 This document and the information contained herein are provided on an 1319 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1320 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1321 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1322 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1323 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1324 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1326 Acknowledgement 1328 Funding for the RFC Editor function is currently provided by the 1329 Internet Society.