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

] command constructed as described in the previ- 342 ous paragraph. In other words it allows the client to request a 343 byte range of the message/message part. 345 7.1 URLAUTH authorized URL 347 <> 350 7.1.1. Concepts 352 7.1.1.1. URLAUTH 354 The URLAUTH is a component, appended at the end of a URL, which 355 conveys authorization to access the data addressed by that URL. It 356 contains an authorized access identifier, an authorization mecha- 357 nism name, and an authorization token. The authorization token is 358 generated from the URL, the authorized access identifer, authoriza- 359 tion mechanism name, and a mailbox access key. 361 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 mecha- 451 nism used; but, in all cases, the authorization token is at least 452 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] with one exception. In IMAP URLs, 458 parameters are treated as part of the normal path with respect to 459 relative URL resolution. This is believed to be the behavior of 460 the installed base and is likely to be documented in a future revi- 461 sion of the relative URL specification. 463 The following observations are also important: 465 The grammar element is considered part of the user name for 466 purposes of resolving relative IMAP URLs. This means that unless a 467 new login/server specification is included in the relative URL, the 468 authentication mechanism is inherited from a base IMAP URL. 470 URLs always use "/" as the hierarchy delimiter for the purpose of 471 resolving paths in relative URLs. IMAP4 permits the use of any 472 hierarchy delimiter in mailbox names. For this reason, relative 473 mailbox paths will only work if the mailbox uses "/" as the hierar- 474 chy delimiter. Relative URLs may be used on mailboxes which use 475 other delimiters, but in that case, the entire mailbox name MUST be 476 specified in the relative URL or inherited as a whole from the base 477 URL. 479 The base URL for a list of mailboxes or messages which was referred 480 to by an IMAP URL is always the referring IMAP URL itself. The 481 base URL for a message or message part which was referred to by an 482 IMAP URL may be more complicated to determine. The program inter- 483 preting the relative URL will have to check the headers of the MIME 484 entity and any enclosing MIME entities in order to locate the "Con- 485 tent-Location" header. This header is used to determine the base 486 URL as defined in section 5 of [MHTML]. For example, if the refer- 487 ring IMAP URL contains a "/;SECTION=1.2" parameter, then the MIME 488 headers for section 1.2, for section 1, and for the enclosing mes- 489 sage itself SHOULD be checked in that order for "Content-Location" 490 headers. 492 9. Multinational Considerations 494 IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding non- 495 US-ASCII characters in IMAP mailbox names. Because this convention 496 is private to IMAP, it is necessary to convert IMAP's encoding to 497 one that can be more easily interpreted by a URL display program. 499 For this reason, IMAP's modified UTF-7 encoding for mailboxes MUST 500 be converted to UTF-8 [UTF-8]. Since 8-bit characters are not per- 501 mitted in URLs, the UTF-8 characters are encoded as required by the 502 URL specification [URI-GEN], section 2.1. Sample code is included 503 in Appendix A to demonstrate this conversion. 505 IMAP usernames are UTF-8 strings and MUST be encoded as required by 506 the URL specification [URI-GEN], section 2.1. 508 Also note that IMAP SEARCH criteria can contain non US-ASCII char- 509 acters. 8-bit octets in those strings MUST be encoded as required 510 by the URL specification [URI-GEN], section 2.1. 512 10. Examples 514 The following examples demonstrate how an IMAP4 client program 515 might translate various IMAP4 URLs into a series of IMAP4 commands. 516 Commands sent from the client to the server are prefixed with "C:", 517 and responses sent from the server to the client are prefixed with 518 "S:". 520 The URL: 522 525 Results in the following client commands: 527 528 C: A001 LOGIN ANONYMOUS sheridan@babylon5.example.org 529 C: A002 SELECT gray-council 530 531 C: A003 UID FETCH 20 BODY.PEEK[]<0.1024> 533 The URL: 535 537 Results in the following client commands: 539 540 542 C: A001 LOGIN MICHAEL zipper 543 C: A002 LIST "" users.* 545 The URL: 547 550 Results in the following client commands: 552 553 C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org 554 C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw- 555 557 The URL: 559 562 Results in the following client commands: 564 565 C: A001 AUTHENTICATE GSSAPI 566 567 C: A002 SELECT gray-council 568 C: A003 UID FETCH 20 BODY.PEEK[1.2] 570 If the following relative URL is located in that body part: 572 <;section=1.4> 574 This could result in the following client commands: 576 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] 577 BODY.PEEK[1.MIME] 578 BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) 579 581 C: A005 UID FETCH 20 BODY.PEEK[1.4] 583 The URL: 585 588 Could result in the following: 590 591 C: A001 CAPABILITY 592 S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5 593 S: A001 OK 594 C: A002 AUTHENTICATE DIGEST-MD5 595 596 S: A002 OK user lennier authenticated 597 C: A003 SELECT "gray council" 598 ... 599 C: A004 SEARCH SUBJECT shadows 600 S: * SEARCH 8 10 13 14 15 16 601 S: A004 OK SEARCH completed 602 C: A005 FETCH 8,10,13:16 ALL 603 ... 604 NOTE: In this final example, the client has implementation depen- 605 dent choices. The authentication mechanism could be anything, 606 including PREAUTH. And the final FETCH command could fetch more or 607 less information about the messages, depending on what it wishes to 608 display to the user. 610 The URL: 612 616 shows that 8-bit data can be sent using non-synchronizing literals 617 [LITERAL+]. This could result in the following: 619 620 C: A001 CAPABILITY 621 S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5 622 S: A001 OK 623 C: A002 AUTHENTICATE DIGEST-MD5 624 625 S: A002 OK user john authenticated 626 C: A003 SELECT babylon5/personel 627 ... 628 C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+} 629 C: XXXXXXXXXXXXXX 630 S: * SEARCH 7 10 12 631 S: A004 OK SEARCH completed 632 C: A005 FETCH 7,10,12 ALL 633 ... 635 Where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified 636 in the URL above. 638 11. Security Considerations 640 Security considerations discussed in the IMAP specification [IMAP4] 641 and the URI specification [URI-GEN] are relevant. Security consid- 642 erations related to authenticated URLs are discussed in section 3 643 of this document. 645 Many email clients store the plain text password for later use 646 after logging into an IMAP server. Such clients MUST NOT use a 647 stored password in response to an IMAP URL without explicit permis- 648 sion from the user to supply that password to the specified host 649 name. 651 12. ABNF for IMAP URL scheme 653 Formal syntax is defined using ABNF [ABNF], extending the ABNF 654 rules in section 9 of [IMAP4]. Elements not defined here can be 655 found in the [ABNF], [IMAP4], [IMAPABNF] or [URI-GEN]. Strings are 656 not case sensitive and free insertion of linear-white-space is not 657 permitted. 659 sub-delims-sh = "!" / "$" / "'" / "(" / ")" / 660 "*" / "+" / "," 661 ;; <> 670 bchar = achar / ":" / "@" / "/" 672 enc-auth-type = 1*achar 673 ; encoded version of [IMAP4] "auth-type" 675 enc-list-mailbox = 1*bchar 676 ; encoded version of [IMAP4] "list-mailbox" 678 enc-mailbox = 1*bchar 679 ; encoded version of [IMAP4] "mailbox" 681 enc-search = 1*bchar 682 ; encoded version of [IMAPABNF] 683 ; "search-program". Note that IMAP4 684 ; literals may not be used in 685 ; a "search-program", i.e. only 686 ; quoted or non-synchronizing 687 ; literals (if the server supports 688 ; LITERAL+ [LITERAL+]) are allowed. 690 enc-section = 1*bchar 691 ; encoded version of [IMAP4] "section-spec" 693 enc-user = 1*achar 694 ; encoded version of [IMAP4] authorization identity 695 ; or "userid". 697 imapurl = "imap://" iserver "/" [ icommand ] 699 <> 702 authimapurl = "imap://" iserver "/" imessagepart 703 ; <<"imapurl" with "[icommand] == imessagepart">> 705 authimapurlfull = authimapurl iurlauth 706 ; <<"imapurl" with "[icommand] == 707 ; imessagepart iurlauth">> 709 authimapurlrump = authimapurl iurlauth-rump 711 <> 715 enc-urlauth = 32*HEXDIG 716 iurlauth = iurlauth-rump iua-verifier 718 iua-verifier = ":" uauth-mechanism ":" enc-urlauth 720 iurlauth-rump = [expire] ";URLAUTH=" access 722 access = ("submit+" enc-user) / ("user+" enc-user) / 723 "authuser" / "anonymous" 725 expire = ";EXPIRE=" date-time 726 ; date-time defined in [DATETIME] 728 uauth-mechanism = "INTERNAL" / 1*(alpha / digit / "-" / ".") 729 ; case-insensitive 730 ; new mechanisms MUST be registered with IANA 732 <> 734 <> 736 iauth = ";AUTH=" ( "*" / enc-auth-type ) 738 icommand = imailboxlist / 739 imessagelist / 740 imessagepart [iurlauth] 742 imailboxlist = [enc-list-mailbox] ";TYPE=" list-type 744 imailbox-ref = enc-mailbox [uidvalidity] 745 ; <> 747 imessagelist = imailbox-ref [ "?" enc-search ] 748 ; "enc-search" is [URI-GEN] "query". 750 imessagepart = imailbox-ref iuid [isection] [ipartial] 752 ipartial = "/;PARTIAL=" partial-range 754 isection = "/;SECTION=" enc-section 756 iserver = [iuserinfo "@"] host [ ":" port ] 757 ; This is the same as "authority" defined 758 ; in [URI-GEN]. See [URI-GEN] for "host" 759 ; and "port" definitions. 761 iuid = "/;UID=" nz-number 762 ; See [IMAP4] for "nz-number" definition 764 iuserinfo = enc-user [iauth] / [enc-user] iauth 765 ; conforms to the generic syntax of 766 ; "userinfo" as defined in [URI-GEN]. 768 list-type = "LIST" / "LSUB" 770 partial-range = number ["." nz-number] 771 ; partial fetch 773 uidvalidity = ";UIDVALIDITY=" nz-number 774 ; See [IMAP4] for "nz-number" definition 776 13. IANA Considerations 778 IANA is requested to update "imap" definition in the "Uniform 779 Resource Identifier scheme registry" to point to this document. 781 The registration template (as per <>) is specified in section 13.1 of this docu- 783 ment. 785 13.1. IANA Registration of imap: URI Scheme 787 This section provides the information required to register the 788 imap: URI scheme. 790 URI scheme name: imap 792 Status: permanent 794 URI scheme syntax: 795 See section 12 of this RFC. 797 URI scheme semantics: 799 The imap: URI scheme is used to designate IMAP servers, mail- 800 boxes, messages, MIME bodies [MIME], and search programs on Inter- 801 net hosts accessible using the IMAP protocol. <> 804 There is no MIME type associated with this URI. 806 Encoding considerations: 808 See Section 9 of <<[this RFC]>>. 810 Applications/protocols that use this URI scheme name: 812 The imap: URI is intended to be used by applications that might 813 need access to IMAP mailstore. Such applications may include (but 814 not limited to) IMAP-capable web browsers; IMAP clients that wish 815 to access a mailbox, message, or edit a message on the server using 816 [CATENATE]; [SUBMIT] clients and servers that are requested to 817 assemble a complete message on submission using [BURL]. 819 Interoperability considerations: 821 A widely deployed IMAP client Mozilla/Thubderbird use a differ- 822 ent imap: scheme internally. <> 824 Security considerations: 826 See Security Considerations (Section 11) of <<[this RFC]>>. 828 Contact: 830 Alexey Melnikov 832 Author/Change controller: 834 IESG 836 References: 838 [This RFC] and [IMAP4]. 840 14. References 842 14.1. Normative References 844 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Require- 845 ment Levels", RFC 2119, Harvard University, March 1997. 847 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 848 4rev1", RFC 3501, University of Washington, March 2003. 850 [IMAPABNF] Melnikov, A., and C. Daboo, "Collected extensions to 851 IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 853 [MHTML] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation 854 of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 855 1999. 857 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 858 ABNF", RFC 4234, October 2005. 860 [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail 861 Extensions", RFC 2045, Innosoft, First Virtual, November 1996. 863 [URI-GEN] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 864 Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. 866 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 867 10646", STD 63, RFC 3629, November 2003. 869 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 870 May 1998. 872 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 873 January 1997. 875 [ANONYMOUS] K. Zeilenga (Ed.), "The Anonymous SASL Mechanism", work 876 in progress, draft-ietf-sasl-anon-XX.txt (Obsoletes RFC 2245). 878 [DATETIME] Klyne, G., and Newman, C., "Date and Time on the Inter- 879 net: Timestamps", RFC 3339, July 2002. 881 14.2. Informative References 883 [SUBMIT] Gellens, R. and Klensin, J., "Message Submission for 884 Mail", draft-gellens-submit-bis-02.txt. 886 [BURL] Newman, C. "Message Composition", work in progress, draft- 887 ietf-lemonade-burl-XX.txt. 889 [CATENATE] Resnick, P. "Internet Message Access Protocol (IMAP) 890 CATENATE Extension", work in progress, draft-ietf-lemonade-cate- 891 nate-XX.txt. 893 [SASL] <>. 896 15. Author's Address 898 Chris Newman 899 Sun Microsystems 900 3401 Centrelake Dr., Suite 410 901 Ontario, CA 91761 902 EMail: chris.newman@sun.com 904 Alexey Melnikov (Editor) 905 Isode Limited 906 5 Castle Business Village 907 36 Station Road 908 Hampton, Middlesex 909 TW12 2BX, UK 910 Email: Alexey.Melnikov@isode.com 911 URI: http://www.melnikov.ca/ 913 Stephane H. Maes (Editor) 914 Oracle Corporation 915 500 Oracle Parkway 916 M/S 4op634 917 Redwood Shores, CA 94065 918 USA 919 Phone: +1-650-607-6296 920 Email: stephane.maes@oracle.com 922 Appendix A. Sample code 924 Here is sample C source code to convert between URL paths and IMAP mail- 925 box names, taking into account mapping between IMAP's modified UTF-7 926 [IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This 927 code has not been rigorously tested nor does it necessarily behave rea- 928 sonably with invalid input, but it should serve as a useful example. 929 This code just converts the mailbox portion of the URL and does not deal 930 with parameters, query or server components of the URL. 932 <> 934 #include 935 #include 937 /* hexadecimal lookup table */ 938 static char hex[] = "0123456789ABCDEF"; 940 /* URL unsafe printable characters */ 941 static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}"; 943 /* UTF7 modified base64 alphabet */ 944 static char base64chars[] = 945 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,"; 946 #define UNDEFINED 64 948 /* UTF16 definitions */ 949 #define UTF16MASK 0x03FFUL 950 #define UTF16SHIFT 10 951 #define UTF16BASE 0x10000UL 952 #define UTF16HIGHSTART 0xD800UL 953 #define UTF16HIGHEND 0xDBFFUL 954 #define UTF16LOSTART 0xDC00UL 955 #define UTF16LOEND 0xDFFFUL 957 /* Convert an IMAP mailbox to a URL path 958 * dst needs to have roughly 4 times the storage space of src 959 * Hex encoding can triple the size of the input 960 * UTF-7 can be slightly denser than UTF-8 961 * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) 962 */ 963 void MailboxToURL(char *dst, char *src) 964 { 965 unsigned char c, i, bitcount; 966 unsigned long ucs4, utf16, bitbuf; 967 unsigned char base64[256], utf8[6]; 969 /* initialize modified base64 decoding table */ 970 memset(base64, UNDEFINED, sizeof (base64)); 971 for (i = 0; i < sizeof (base64chars); ++i) { 972 base64[base64chars[i]] = i; 973 } 975 /* loop until end of string */ 976 while (*src != '\0') { 977 c = *src++; 978 /* deal with literal characters and &- */ 979 if (c != '&' || *src == '-') { 980 if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) { 981 /* hex encode if necessary */ 982 dst[0] = '%'; 983 dst[1] = hex[c >> 4]; 984 dst[2] = hex[c & 0x0f]; 985 dst += 3; 987 } else { 988 /* encode literally */ 989 *dst++ = c; 990 } 991 /* skip over the '-' if this is an &- sequence */ 992 if (c == '&') ++src; 993 } else { 994 /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ 995 bitbuf = 0; 996 bitcount = 0; 997 ucs4 = 0; 998 while ((c = base64[(unsigned char) *src]) != UNDEFINED) { 999 ++src; 1000 bitbuf = (bitbuf << 6) | c; 1001 bitcount += 6; 1002 /* enough bits for a UTF-16 character? */ 1003 if (bitcount >= 16) { 1004 bitcount -= 16; 1005 utf16 = (bitcount ? bitbuf >> bitcount 1006 : bitbuf) & 0xffff; 1007 /* convert UTF16 to UCS4 */ 1008 if 1009 (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { 1010 ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; 1011 continue; 1012 } else if 1013 (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { 1014 ucs4 += utf16 - UTF16LOSTART + UTF16BASE; 1015 } else { 1016 ucs4 = utf16; 1017 } 1018 /* convert UTF-16 range of UCS4 to UTF-8 */ 1019 if (ucs4 <= 0x7fUL) { 1020 utf8[0] = ucs4; 1021 i = 1; 1022 } else if (ucs4 <= 0x7ffUL) { 1023 utf8[0] = 0xc0 | (ucs4 >> 6); 1024 utf8[1] = 0x80 | (ucs4 & 0x3f); 1025 i = 2; 1026 } else if (ucs4 <= 0xffffUL) { 1027 utf8[0] = 0xe0 | (ucs4 >> 12); 1028 utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f); 1029 utf8[2] = 0x80 | (ucs4 & 0x3f); 1030 i = 3; 1031 } else { 1032 utf8[0] = 0xf0 | (ucs4 >> 18); 1033 utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f); 1034 utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f); 1035 utf8[3] = 0x80 | (ucs4 & 0x3f); 1036 i = 4; 1037 } 1038 /* convert utf8 to hex */ 1039 for (c = 0; c < i; ++c) { 1040 dst[0] = '%'; 1041 dst[1] = hex[utf8[c] >> 4]; 1042 dst[2] = hex[utf8[c] & 0x0f]; 1043 dst += 3; 1044 } 1045 } 1046 } 1047 /* skip over trailing '-' in modified UTF-7 encoding */ 1048 if (*src == '-') ++src; 1049 } 1050 } 1051 /* terminate destination string */ 1052 *dst = '\0'; 1053 } 1055 /* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox 1056 * dst should be about twice the length of src to deal with non-hex 1057 * coded URLs 1058 */ 1059 void URLtoMailbox(char *dst, char *src) 1060 { 1061 unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag; 1062 unsigned long ucs4, bitbuf; 1063 unsigned char hextab[256]; 1065 /* initialize hex lookup table */ 1066 memset(hextab, 0, sizeof (hextab)); 1067 for (i = 0; i < sizeof (hex); ++i) { 1068 hextab[hex[i]] = i; 1069 if (isupper(hex[i])) hextab[tolower(hex[i])] = i; 1070 } 1072 utf7mode = 0; 1073 utf8total = 0; 1074 bitstogo = 0; 1075 while ((c = *src) != '\0') { 1076 ++src; 1077 /* undo hex-encoding */ 1078 if (c == '%' && src[0] != '\0' && src[1] != '\0') { 1079 c = (hextab[src[0]] << 4) | hextab[src[1]]; 1080 src += 2; 1081 } 1082 /* normal character? */ 1083 if (c >= ' ' && c <= '~') { 1084 /* switch out of UTF-7 mode */ 1085 if (utf7mode) { 1086 if (bitstogo) { 1087 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; 1088 } 1089 *dst++ = '-'; 1090 utf7mode = 0; 1091 } 1092 *dst++ = c; 1093 /* encode '&' as '&-' */ 1094 if (c == '&') { 1095 *dst++ = '-'; 1096 } 1097 continue; 1098 } 1099 /* switch to UTF-7 mode */ 1100 if (!utf7mode) { 1101 *dst++ = '&'; 1102 utf7mode = 1; 1103 } 1104 /* Encode US-ASCII characters as themselves */ 1105 if (c < 0x80) { 1106 ucs4 = c; 1107 utf8total = 1; 1108 } else if (utf8total) { 1109 /* save UTF8 bits into UCS4 */ 1110 ucs4 = (ucs4 << 6) | (c & 0x3FUL); 1111 if (++utf8pos < utf8total) { 1112 continue; 1113 } 1114 } else { 1115 utf8pos = 1; 1116 if (c < 0xE0) { 1117 utf8total = 2; 1118 ucs4 = c & 0x1F; 1119 } else if (c < 0xF0) { 1120 utf8total = 3; 1121 ucs4 = c & 0x0F; 1122 } else { 1123 /* NOTE: can't convert UTF8 sequences longer than 4 */ 1124 utf8total = 4; 1125 ucs4 = c & 0x03; 1126 } 1127 continue; 1128 } 1129 /* loop to split ucs4 into two utf16 chars if necessary */ 1130 utf8total = 0; 1131 do { 1132 if (ucs4 >= UTF16BASE) { 1133 ucs4 -= UTF16BASE; 1134 bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) 1135 + UTF16HIGHSTART); 1136 ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; 1137 utf16flag = 1; 1138 } else { 1139 bitbuf = (bitbuf << 16) | ucs4; 1140 utf16flag = 0; 1141 } 1142 bitstogo += 16; 1143 /* spew out base64 */ 1144 while (bitstogo >= 6) { 1145 bitstogo -= 6; 1146 *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo) 1147 : bitbuf) 1148 & 0x3F]; 1149 } 1150 } while (utf16flag); 1151 } 1152 /* if in UTF-7 mode, finish in ASCII */ 1153 if (utf7mode) { 1154 if (bitstogo) { 1155 *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; 1156 } 1157 *dst++ = '-'; 1158 } 1159 /* tie off string */ 1160 *dst = '\0'; 1161 } 1163 Appendix B. List of changes since RFC 2192 1165 <> 1166 Updated boilerplate, list of editor's, etc. 1167 Updated references. 1168 Updated ABNF not to use _, to use SP instead of SPACE. 1169 Updated example domains to use example.org. 1170 Fixed ABNF error in "imessagelist" non-terminal. 1171 Updated ABNF, due to changes in RFC 3501, IMAPABNF and RFC 3986. 1172 Renamed "iuserauth" non-terminal to "iuserinfo". 1173 Clarified that the userinfo component describes both authorization 1174 identity and mailbox naming scope. 1175 Allow for non-synchronizing literals in "enc-search". 1176 Added "ipartial" specifier that denotes a partial fetch. 1177 Moved URLAUTH text from RFC <> to this document. 1179 Intellectual Property 1181 The IETF takes no position regarding the validity or scope of any 1182 Intellectual Property Rights or other rights that might be claimed 1183 to pertain to the implementation or use of the technology 1184 described in this document or the extent to which any license 1185 under such rights might or might not be available; nor does it 1186 represent that it has made any independent effort to identify any 1187 such rights. Information on the procedures with respect to rights 1188 in RFC documents can be found in BCP 78 and BCP 79. 1190 Copies of IPR disclosures made to the IETF Secretariat and any 1191 assurances of licenses to be made available, or the result of an 1192 attempt made to obtain a general license or permission for the use 1193 of such proprietary rights by implementers or users of this 1194 specification can be obtained from the IETF on-line IPR repository 1195 at http://www.ietf.org/ipr. 1197 The IETF invites any interested party to bring to its attention 1198 any copyrights, patents or patent applications, or other 1199 proprietary rights that may cover technology that may be required 1200 to implement this standard. Please address the information to the 1201 IETF at ietf-ipr@ietf.org. 1203 Full Copyright Statement 1205 Copyright (C) The Internet Society (2006). 1207 This document is subject to the rights, licenses and restrictions 1208 contained in BCP 78, and except as set forth therein, the authors 1209 retain all their rights. 1211 This document and the information contained herein are provided on an 1212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1214 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1215 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1216 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1219 Acknowledgement 1221 Funding for the RFC Editor function is currently provided by the 1222 Internet Society.