idnits 2.17.1 draft-ietf-xmpp-address-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 26, 2010) is 5016 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3490 (ref. 'IDNA2003') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (ref. 'NAMEPREP') (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE-SEC' == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-3920bis-10 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: Standards Track July 26, 2010 5 Expires: January 27, 2011 7 Extensible Messaging and Presence Protocol (XMPP): Address Format 8 draft-ietf-xmpp-address-03 10 Abstract 12 This document defines the format for addresses used in the Extensible 13 Messaging and Presence Protocol (XMPP), including support for non- 14 ASCII characters. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 27, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Internationalization Considerations . . . . . . . . . . . . . 8 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 8 59 4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Confusable Characters . . . . . . . . . . . . . . . . . . 8 61 4.4. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9 62 4.4.1. Address Forging . . . . . . . . . . . . . . . . . . . 9 63 4.4.2. Address Mimicking . . . . . . . . . . . . . . . . . . 9 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 11 66 5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 11 67 6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 15 72 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 16 73 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 16 74 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 16 76 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 16 77 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 17 78 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 18 80 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 81 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 18 82 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 19 84 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 19 85 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19 86 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19 87 Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 20 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 The Extensible Messaging and Presence Protocol [XMPP] is an 93 application profile of the Extensible Markup Language [XML] for 94 streaming XML data in close to real time between any two or more 95 network-aware entities. The address format for XMPP entities was 96 originally developed in the Jabber open-source community in 1999, 97 first described by [XEP-0029] in 2002, and defined canonically by 98 [RFC3920] in 2004. 100 As specified in RFC 3920, the XMPP address format re-uses the 101 "stringprep" technology for preparation of non-ASCII characters 102 [STRINGPREP], including the Nameprep profile for internationalized 103 domain names as specified in [NAMEPREP] and [IDNA2003] along with two 104 XMPP-specific profiles for the localpart and resourcepart. However, 105 since the publication of RFC 3920, IDNA2003 has been superseded by 106 IDNA2008 (see [IDNA-PROTO] and related documents). As a result, 107 other protocols that use stringprep (including XMPP) have begun to 108 migrate from stringprep toward more "modern" approaches. 110 Because work on improved handling of internationalized addresses is 111 currently in progress, specifying the XMPP address format in the 112 specification that obsoletes RFC 3920 would unacceptably delay the 113 revision process. Therefore, this specification provides updated 114 documentation of the XMPP address format (essentially copied from RFC 115 3920), with the intent that it can be superseded once work on a new 116 approach to internationalization is complete. 118 2. Addresses 120 2.1. Overview 122 An XMPP entity is anything that is network-addressable and that can 123 communicate using XMPP. For historical reasons, the native address 124 of an XMPP entity is called a Jabber Identifier or JID. A valid JID 125 is a string of [UNICODE] code points, encoded using [UTF-8], and 126 structured as an ordered sequence of localpart, domainpart, and 127 resourcepart (where the first two parts are demarcated by the '@' 128 character used as a separator, and the last two parts are similarly 129 demarcated by the '/' character). 131 The syntax for a JID is defined as follows using the Augmented 132 Backus-Naur Form as specified in [ABNF]. 134 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 135 localpart = 1*(nodepoint) 136 ; a "nodepoint" is a UTF-8 encoded Unicode code 137 ; point that satisfies the Nodeprep profile of 138 ; stringprep 139 domainpart = IP-literal / IPv4address / ifqdn 140 ; the "IPv4address" and "IP-literal" rules are 141 ; defined in RFC 3986, and the first-match-wins 142 ; (a.k.a. "greedy") algorithm described in RFC 143 ; 3986 applies to the matching process 144 ifqdn = 1*(namepoint) 145 ; a "namepoint" is a UTF-8 encoded Unicode 146 ; code point that satisfies the Nameprep 147 ; profile of stringprep 148 resourcepart = 1*(resourcepoint) 149 ; a "resourcepoint" is a UTF-8 encoded Unicode 150 ; code point that satisfies the Resourceprep 151 ; profile of stringprep 153 All JIDs are based on the foregoing structure. One common use of 154 this structure is to identify a messaging and presence account, the 155 server that hosts the account, and a connected resource (e.g., a 156 specific device) in the form of . 157 However, localparts other than clients are possible; for example, a 158 specific chat room offered by a multi-user chat service (see 159 [XEP-0045]) is addressed as (where "room" is the name 160 of the chat room and "service" is the hostname of the multi-user chat 161 service) and a specific occupant of such a room could be addressed as 162 (where "nick" is the occupant's room nickname). 163 Many other JID types are possible (e.g., could be a 164 server-side script or service). 166 Each allowable portion of a JID (localpart, domainpart, and 167 resourcepart) MUST NOT be zero bytes in length and MUST NOT be more 168 than 1023 bytes in length, resulting in a maximum total size 169 (including the '@' and '/' separators) of 3071 bytes. 171 An entity's address on an XMPP network MUST be represented as a JID 172 (without a URI scheme) and not a [URI] or [IRI] as specified in 173 [XMPP-URI]; the latter specification is provided only for 174 identification and interaction outside the context of XMPP itself. 176 Implementation Note: When dividing a JID into its component parts, 177 an implementation needs to match the separator characters '@' and 178 '/' before applying any transformation algorithms, which might 179 decompose certain Unicode code points to the separator characters 180 (e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040 181 COMMERCIAL AT). 183 2.2. Domainpart 185 The DOMAINPART of a JID is that portion after the '@' character (if 186 any) and before the '/' character (if any); it is the primary 187 identifier and is the only REQUIRED element of a JID (a mere 188 domainpart is a valid JID). Typically a domainpart identifies the 189 "home" server to which clients connect for XML routing and data 190 management functionality. However, it is not necessary for an XMPP 191 domainpart to identify an entity that provides core XMPP server 192 functionality (e.g., a domainpart can identify an entity such as a 193 multi-user chat service, a publish-subscribe service, or a user 194 directory). 196 The domainpart for every server or service that will communicate over 197 a network SHOULD be a fully qualified domain name or "FQDN" (see 198 [DNS]); although the domainpart is allowed to be either an Internet 199 Protocol (IPv4 or IPv6) address or a text label that is resolvable on 200 a local network (commonly called an "unqualified hostname"), it is 201 possible that domainparts that are IP addresses will not be 202 acceptable to other services for the sake of interdomain 203 communication. Furthermore, domainparts that are unqualified 204 hostnames MUST NOT be used on public networks but MAY be used on 205 private networks. 207 Note: If the domainpart includes a final character considered to 208 be a label separator (dot) by [IDNA2003] or [DNS], this character 209 MUST be stripped from the domainpart before the JID of which it is 210 a part is used for the purpose of routing an XML stanza, comparing 211 against another JID, or constructing an [XMPP-URI]; in particular, 212 the character MUST be stripped before any other canonicalization 213 steps are taken, such as application of the [NAMEPREP] profile of 214 [STRINGPREP] or completion of the ToASCII operation as described 215 in [IDNA2003]. 217 A domainpart MUST NOT be zero bytes in length and MUST NOT be more 218 than 1023 bytes in length. 220 A domainpart consisting of a fully qualified domain name MUST be an 221 "internationalized domain name" as defined in [IDNA2003], that is, it 222 MUST be "a domain name in which every label is an internationalized 223 label" and MUST follow the rules for construction of 224 internationalized domain names specified in [IDNA2003]. When 225 preparing a text label (consisting of a sequence of UTF-8 encoded 226 Unicode code points) for representation as an internationalized label 227 in the process of constructing an XMPP domainpart or comparing two 228 XMPP domainparts, an application MUST ensure that for each text label 229 it is possible to apply without failing the ToASCII operation 230 specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus 231 forbidding ASCII code points other than letters, digits, and 232 hyphens). If the ToASCII operation can be applied without failing, 233 then the label is an internationalized label. (Note: The ToASCII 234 operation includes application of the [NAMEPREP] profile of 235 [STRINGPREP] and encoding using the algorithm specified in 236 [PUNYCODE]; for details, see [IDNA2003].) Although XMPP applications 237 do not communicate the output of the ToASCII operation (called an 238 "ACE label") over the wire, it MUST be possible to apply that 239 operation without failing to each internationalized label. If an 240 XMPP application receives as input an ACE label, it SHOULD convert 241 that ACE label to an internationalized label using the ToUnicode 242 operation (see [IDNA2003]) before including the label in an XMPP 243 domainpart that will be communicated over the wire on an XMPP network 244 (however, instead of converting the label, there are legitimate 245 reasons why an application might instead refuse the input altogether 246 and return an error to the entity that provided the offending data). 248 In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a 249 "domain name slot". 251 2.3. Localpart 253 The LOCALPART of a JID is an optional identifier placed before the 254 domainpart and separated from the latter by the '@' character. 255 Typically a localpart uniquely identifies the entity requesting and 256 using network access provided by a server (i.e., a local account), 257 although it can also represent other kinds of entities (e.g., a chat 258 room associated with a multi-user chat service). The entity 259 represented by an XMPP localpart is addressed within the context of a 260 specific domain. 262 A localpart MUST NOT be zero bytes in length and MUST NOT be more 263 than 1023 bytes in length. 265 A localpart MUST be formatted such that the Nodeprep profile of 266 [STRINGPREP] can be applied without failing (see Appendix A). Before 267 comparing two localparts, an application MUST first ensure that the 268 Nodeprep profile has been applied to each identifier (the profile 269 need not be applied each time a comparison is made, as long as it has 270 been applied before comparison). 272 2.4. Resourcepart 274 The resourcepart of a JID is an optional identifier placed after the 275 domainpart and separated from the latter by the '/' character. A 276 resourcepart can modify either a address or a 277 mere address. Typically a resourcepart uniquely 278 identifies a specific connection (e.g., a device or location) or 279 object (e.g., an occupant in a multi-user chat room) belonging to the 280 entity associated with an XMPP localpart at a local domain. 282 When an XMPP address does not include a resourcepart (i.e., when it 283 is of the form or ), it is 284 referred to as a BARE JID. When an XMPP address includes a 285 resourcepart (i.e., when it is of the form or 286 ), is referred to as a FULL JID. 288 A resourcepart MUST NOT be zero bytes in length and MUST NOT be more 289 than 1023 bytes in length. 291 A resourcepart MUST be formatted such that the Resourceprep profile 292 of [STRINGPREP] can be applied without failing (see Appendix B). 293 Before comparing two resourceparts, an application MUST first ensure 294 that the Resourceprep profile has been applied to each identifier 295 (the profile need not be applied each time a comparison is made, as 296 long as it has been applied before comparison). 298 Note: For historical reasons, the term "resource identifier" is 299 often used in XMPP to refer to the optional portion of an XMPP 300 address that follows the domainpart and the "/" separator 301 character; to help prevent confusion between an XMPP "resource 302 identifier" and the meanings of "resource" and "identifier" 303 provided in Section 1.1 of [URI], this specification uses the term 304 "resourcepart" instead of "resource identifier" (as in RFC 3920). 306 XMPP entities SHOULD consider resourceparts to be opaque strings and 307 SHOULD NOT impute meaning to any given resourcepart. In particular: 309 o Use of the '/' character as a separator between the domainpart and 310 the resourcepart does not imply that XMPP addresses are 311 hierarchical in the way that, say, HTTP addresses are 312 hierarchical; thus for example an XMPP address of the form 313 does not identify a resource "bar" that 314 exists below a resource "foo" in a hierarchy of resources 315 associated with the entity "localpart@domain". 317 o The '@' character is allowed in the resourcepart, and is often 318 used in the "nick" shown in XMPP chatrooms. For example, the JID 319 describes an entity who is an 320 occupant of the room with an (asserted) 321 nick of . However, chatroom services do not 322 necessarily check such an asserted nick against the occupant's 323 real JID. 325 3. Internationalization Considerations 327 XMPP servers MUST, and XMPP clients SHOULD, support [IDNA2003] for 328 domainparts (including the [NAMEPREP] profile of [STRINGPREP]), the 329 Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and the 330 Resourceprep (Appendix B) profile of [STRINGPREP] for resourceparts; 331 this enables XMPP addresses to include a wide variety of characters 332 outside the US-ASCII range. Rules for enforcement of the XMPP 333 address format are provided in [XMPP]. 335 4. Security Considerations 337 4.1. Reuse of Stringprep 339 The security considerations described in [STRINGPREP] apply to the 340 Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined 341 in this document for XMPP localparts and resourceparts. The security 342 considerations described in [STRINGPREP] and [NAMEPREP] apply to the 343 Nameprep profile that is re-used here for XMPP domainparts. 345 4.2. Reuse of Unicode 347 The security considerations described in [UNICODE-SEC] apply to the 348 use of Unicode characters in XMPP addresses. 350 4.3. Confusable Characters 352 The Unicode and ISO/IEC 10646 repertoires have many characters that 353 look similar (so-called "confusable characters"). In many cases, 354 users of security protocols might perform visual matching, such as 355 when comparing the names of trusted third parties. Because it is 356 impossible to map similar-looking characters without a great deal of 357 context (such as knowing the fonts used), stringprep does nothing to 358 map similar-looking characters together, nor to prohibit some 359 characters because they look like others. Some specific suggestions 360 about identification and handling of confusable characters appear in 361 the Unicode Security Considerations [UNICODE-SEC]. 363 A localpart can be employed as one part of an entity's address in 364 XMPP. One common usage is as the username of an instant messaging 365 user; another is as the name of a multi-user chat room; and many 366 other kinds of entities could use localparts as part of their 367 addresses. The security of such services could be compromised based 368 on different interpretations of the internationalized localpart; for 369 example, a user entering a single internationalized localpart could 370 access another user's account information, or a user could gain 371 access to a hidden or otherwise restricted chat room or service. 373 A resourcepart can be employed as one part of an entity's address in 374 XMPP. One common usage is as the name for an instant messaging 375 user's connected resource; another is as the nickname of a user in a 376 multi-user chat room; and many other kinds of entities could use 377 resourceparts as part of their addresses. The security of such 378 services could be compromised based on different interpretations of 379 the internationalized resourcepart; for example, a user could attempt 380 to initiate multiple connections with the same name, or a user could 381 send a message to someone other than the intended recipient in a 382 multi-user chat room. 384 4.4. Address Spoofing 386 There are two forms of address spoofing: forging and mimicking. 388 4.4.1. Address Forging 390 In the context of XMPP technologies, address forging occurs when an 391 entity is able to generate an XML stanza whose 'from' address does 392 not correspond to the account credentials with which the entity 393 authenticated onto the network (or an authorization identity provided 394 during SASL negotiation). For example, address forging occurs if an 395 entity that authenticated as "juliet@im.example.com" is able to send 396 XML stanzas from "nurse@im.example.com" or "romeo@example.net". 398 Address forging is difficult in XMPP systems, given the requirement 399 for sending servers to stamp 'from' addresses and for receiving 400 servers to verify sending domains via server-to-server authentication 401 (see [XMPP]). However, address forging is not impossible, since a 402 rogue server could forge JIDs at the sending domain by ignoring the 403 stamping requirement. Therefore, an entity outside the security 404 perimeter of a particular server cannot reliably distinguish between 405 bare JIDs of the form at that server and thus 406 can authenticate only the domainpart of such JIDs with any level of 407 assurance. This specification does not define methods for 408 discovering or counteracting such rogue servers. 410 Furthermore, it is possible for an attacker to forge JIDs at other 411 domains by means of a DNS poisoning attack if DNS security extensions 412 [DNSSEC] are not used. 414 4.4.2. Address Mimicking 416 Address mimicking occurs when an entity provides legitimate 417 authentication credentials for and sends XML stanzas from an account 418 whose JID appears to a human user to be the same as another JID. For 419 example, in some XMPP clients the address "paypa1@example.org" 420 (spelled with the number one as the final character of the localpart) 421 might appear to be the same as "paypal@example.org (spelled with the 422 lower-case version of the letter "L"), especially on casual visual 423 inspection; this phenomenon is sometimes called "typejacking". A 424 more sophisticated example of address mimicking might involve the use 425 of characters from outside the US-ASCII range, such as the Cherokee 426 characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead 427 of the US-ASCII characters "STPETER". 429 In some examples of address mimicking, it is unlikely that the 430 average user could tell the difference between the real JID and the 431 fake JID. (Indeed, there is no way to distinguish with full 432 certainty which is the fake JID and which is the real JID; in some 433 communication contexts, the JID with Cherokee characters might be the 434 real JID and the JID with US-ASCII characters might thus appear to be 435 the fake JID.) Because JIDs can contain almost any Unicode 436 character, it can be relatively easy to mimic some JIDs in XMPP 437 systems. The possibility of address mimicking introduces security 438 vulnerabilities of the kind that have also plagued the World Wide 439 Web, specifically the phenomenon known as phishing. 441 As noted in [IDNA-DEFS], "there are no comprehensive technical 442 solutions to the problems of confusable characters". Mimicked JIDs 443 that involve characters from only one character set or from the 444 character set typically employed by a particular user are not easy to 445 combat (e.g., the simple typejacking attack previously described, 446 which relies on a surface similarity between the characters "1" and 447 "l" in some presentations). However, mimicked addresses that involve 448 characters from more than one character set, or from a character set 449 not typically employed by a particular user, can be mitigated 450 somewhat through intelligent presentation. In particular, every 451 human user of an XMPP technology presumably has a preferred language 452 (or, in some cases, a small set of preferred languages), which an 453 XMPP application SHOULD gather either explicitly from the user or 454 implicitly via the operating system of the user's device. 455 Furthermore, every language has a range (or a small set of ranges) of 456 characters normally used to represent that language in textual form. 457 Therefore, an XMPP application SHOULD warn the user when presenting a 458 JID that mixes characters from more than one character set or that 459 uses characters outside the normal range of the user's preferred 460 language(s). This recommendation is not intended to discourage 461 communication across language communities; instead, it recognizes the 462 existence of such language communities and encourages due caution 463 when presenting unfamiliar character sets to human users. 465 5. IANA Considerations 467 The following sections update the registrations provided in 469 [RFC3920]. 471 5.1. Nodeprep Profile of Stringprep 473 The Nodeprep profile of stringprep is defined under Nodeprep 474 (Appendix A). The IANA has registered Nodeprep in the stringprep 475 profile registry. 477 Name of this profile: 479 Nodeprep 481 RFC in which the profile is defined: 483 XXXX 485 Indicator whether or not this is the newest version of the profile: 487 This is the first version of Nodeprep 489 5.2. Resourceprep Profile of Stringprep 491 The Resourceprep profile of stringprep is defined under Resourceprep 492 (Appendix B). The IANA has registered Resourceprep in the stringprep 493 profile registry. 495 Name of this profile: 497 Resourceprep 499 RFC in which the profile is defined: 501 XXXX 503 Indicator whether or not this is the newest version of the profile: 505 This is the first version of Resourceprep 507 6. Conformance Requirements 509 This section describes a protocol feature set that summarizes the 510 conformance requirements of this specification. This feature set is 511 appropriate for use in software certification, interoperability 512 testing, and implementation reports. For each feature, this section 513 provides the following information: 515 o A human-readable name 517 o An informational description 519 o A reference to the particular section of this document that 520 normatively defines the feature 522 o Whether the feature applies to the Client role, the Server role, 523 or both (where "N/A" signifies that the feature is not applicable 524 to the specified role) 526 o Whether the feature MUST or SHOULD be implemented, where the 527 capitalized terms are to be understood as described in [KEYWORDS] 529 The feature set specified here attempts to adhere to the concepts and 530 formats proposed by Larry Masinter within the IETF's NEWTRK Working 531 Group in 2005, as captured in [INTEROP]. Although this feature set 532 is more detailed than called for by [REPORTS], it provides a suitable 533 basis for the generation of implementation reports to be submitted in 534 support of advancing this specification from Proposed Standard to 535 Draft Standard in accordance with [PROCESS]. 537 Feature: address-domain-length 538 Description: Ensure that the domainpart of an XMPP address is at 539 least one byte in length and at most 1023 bytes in length. 540 Section: Section 2.2 541 Roles: Both MUST. 543 Feature: address-domain-prep 544 Description: Ensure that the domainpart of an XMPP address conforms 545 to the Nameprep profile of Stringprep. 546 Section: Section 2.2 547 Roles: Client SHOULD, Server MUST. 549 Feature: address-localpart-length 550 Description: Ensure that the localpart of an XMPP address is at 551 least one byte in length and at most 1023 bytes in length. 552 Section: Section 2.3 553 Roles: Both MUST. 555 Feature: address-localpart-prep 556 Description: Ensure that the localpart of an XMPP address conforms 557 to the Nodeprep profile of Stringprep. 558 Section: Section 2.3 559 Roles: Client SHOULD, Server MUST. 561 Feature: address-resource-length 562 Description: Ensure that the resourcepart of an XMPP address is at 563 least one byte in length and at most 1023 bytes in length. 564 Section: Section 2.4 565 Roles: Both MUST. 567 Feature: address-resource-prep 568 Description: Ensure that the resourcepart of an XMPP address 569 conforms to the Resourceprep profile of Stringprep. 570 Section: Section 2.2 571 Roles: Client SHOULD, Server MUST. 573 7. References 575 7.1. Normative References 577 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 578 Specifications: ABNF", STD 68, RFC 5234, January 2008. 580 [IDNA2003] 581 Faltstrom, P., Hoffman, P., and A. Costello, 582 "Internationalizing Domain Names in Applications (IDNA)", 583 RFC 3490, March 2003. 585 [KEYWORDS] 586 Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, March 1997. 589 [NAMEPREP] 590 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 591 Profile for Internationalized Domain Names (IDN)", 592 RFC 3491, March 2003. 594 [STRINGPREP] 595 Hoffman, P. and M. Blanchet, "Preparation of 596 Internationalized Strings ("stringprep")", RFC 3454, 597 December 2002. 599 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 600 3.2.0", 2000. 602 The Unicode Standard, Version 3.2.0 is defined by The 603 Unicode Standard, Version 3.0 (Reading, MA, Addison- 604 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 605 Unicode Standard Annex #27: Unicode 3.1 606 (http://www.unicode.org/reports/tr27/) and by the Unicode 607 Standard Annex #28: Unicode 3.2 608 (http://www.unicode.org/reports/tr28/). 610 [UNICODE-SEC] 611 The Unicode Consortium, "Unicode Technical Report #36: 612 Unicode Security Considerations", 2008. 614 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 615 10646", STD 63, RFC 3629, November 2003. 617 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 618 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-10 (work 619 in progress), July 2010. 621 7.2. Informative References 623 [DNS] Mockapetris, P., "Domain names - implementation and 624 specification", STD 13, RFC 1035, November 1987. 626 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 627 Rose, "DNS Security Introduction and Requirements", 628 RFC 4033, March 2005. 630 [IDNA-DEFS] 631 Klensin, J., "Internationalized Domain Names for 632 Applications (IDNA): Definitions and Document Framework", 633 draft-ietf-idnabis-defs-13 (work in progress), 634 January 2010. 636 [IDNA-PROTO] 637 Klensin, J., "Internationalized Domain Names in 638 Applications (IDNA): Protocol", 639 draft-ietf-idnabis-protocol-18 (work in progress), 640 January 2010. 642 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 643 Reporting", draft-ietf-newtrk-interop-reports-00 (work in 644 progress), October 2005. 646 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 647 Identifiers (IRIs)", RFC 3987, January 2005. 649 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 650 3", BCP 9, RFC 2026, October 1996. 652 [PUNYCODE] 653 Costello, A., "Punycode: A Bootstring encoding of Unicode 654 for Internationalized Domain Names in Applications 655 (IDNA)", RFC 3492, March 2003. 657 [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation 658 and Implementation Reports for Advancement to Draft 659 Standard", BCP 9, RFC 5657, September 2009. 661 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 662 Protocol (XMPP): Core", RFC 3920, October 2004. 664 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 665 Resource Identifier (URI): Generic Syntax", STD 66, 666 RFC 3986, January 2005. 668 [XEP-0029] 669 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 670 XEP 0029, October 2003. 672 [XEP-0030] 673 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 674 Andre, "Service Discovery", XSF XEP 0030, June 2008. 676 [XEP-0045] 677 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 678 January in progress, last updated 2010. 680 [XEP-0060] 681 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 682 Subscribe", XSF XEP 0060, September 2008. 684 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 685 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 686 Edition)", World Wide Web Consortium Recommendation REC- 687 xml-20060816, August 2006, 688 . 690 [XMPP-URI] 691 Saint-Andre, P., "Internationalized Resource Identifiers 692 (IRIs) and Uniform Resource Identifiers (URIs) for the 693 Extensible Messaging and Presence Protocol (XMPP)", 694 RFC 5122, February 2008. 696 Appendix A. Nodeprep 697 A.1. Introduction 699 This appendix defines the "Nodeprep" profile of stringprep. As such, 700 it specifies processing rules that will enable users to enter 701 internationalized localparts in the Extensible Messaging and Presence 702 Protocol (XMPP) and have the highest chance of getting the content of 703 the strings correct. (An XMPP localpart is the optional portion of 704 an XMPP address that precedes an XMPP domainpart and the '@' 705 separator; it is often but not exclusively associated with an instant 706 messaging username.) These processing rules are intended only for 707 XMPP localparts and are not intended for arbitrary text or any other 708 aspect of an XMPP address. 710 This profile defines the following, as required by [STRINGPREP]: 712 o The intended applicability of the profile: internationalized 713 localparts within XMPP 714 o The character repertoire that is the input and output to 715 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 716 o The mappings used: specified in Section 3 717 o The Unicode normalization used: specified in Section 4 718 o The characters that are prohibited as output: specified in Section 719 5 720 o Bidirectional character handling: specified in Section 6 722 A.2. Character Repertoire 724 This profile uses Unicode 3.2 with the list of unassigned code points 725 being Table A.1, both defined in Appendix A of [STRINGPREP]. 727 A.3. Mapping 729 This profile specifies mapping using the following tables from 730 [STRINGPREP]: 732 Table B.1 733 Table B.2 735 A.4. Normalization 737 This profile specifies the use of Unicode normalization form KC, as 738 described in [STRINGPREP]. 740 A.5. Prohibited Output 742 This profile specifies the prohibition of using the following tables 743 from [STRINGPREP]. 745 Table C.1.1 746 Table C.1.2 747 Table C.2.1 748 Table C.2.2 749 Table C.3 750 Table C.4 751 Table C.5 752 Table C.6 753 Table C.7 754 Table C.8 755 Table C.9 757 In addition, the following additional Unicode characters are also 758 prohibited: 760 U+0022 (QUOTATION MARK), i.e., " 761 U+0026 (AMPERSAND), i.e., & 762 U+0027 (APOSTROPHE), i.e., ' 763 U+002F (SOLIDUS), i.e., / 764 U+003A (COLON), i.e., : 765 U+003C (LESS-THAN SIGN), i.e., < 766 U+003E (GREATER-THAN SIGN), i.e., > 767 U+0040 (COMMERCIAL AT), i.e., @ 769 A.6. Bidirectional Characters 771 This profile specifies checking bidirectional strings, as described 772 in Section 6 of [STRINGPREP]. 774 A.7. Notes 776 Because the additional characters prohibited by Nodeprep are 777 prohibited after normalization, an implementation MUST NOT enable a 778 human user to input any Unicode code point whose decomposition 779 includes those characters; such code points include but are not 780 necessarily limited to the following (refer to [UNICODE] for complete 781 information). 783 o U+2100 (ACCOUNT OF) 784 o U+2101 (ADDRESSED TO THE SUBJECT) 785 o U+2105 (CARE OF) 786 o U+2106 (CADA UNA) 787 o U+226E (NOT LESS-THAN) 788 o U+226F (NOT GREATER-THAN) 789 o U+2A74 (DOUBLE COLON EQUAL) 790 o U+FE13 (SMALL COLON) 791 o U+FE60 (SMALL AMPERSAND) 792 o U+FE64 (SMALL LESS-THAN SIGN) 793 o U+FE65 (SMALL GREATER-THAN SIGN) 794 o U+FE6B (SMALL COMMERCIAL AT) 795 o U+FF02 (FULLWIDTH QUOTATION MARK) 796 o U+FF06 (FULLWIDTH AMPERSAND) 797 o U+FF07 (FULLWIDTH APOSTROPHE) 798 o U+FF0F (FULLWIDTH SOLIDUS) 799 o U+FF1A (FULLWIDTH COLON) 800 o U+FF1C (FULLWIDTH LESS-THAN SIGN) 801 o U+FF1E (FULLWIDTH GREATER-THAN SIGN) 802 o U+FF20 (FULLWIDTH COMMERCIAL AT) 804 Appendix B. Resourceprep 806 B.1. Introduction 808 This appendix defines the "Resourceprep" profile of stringprep. As 809 such, it specifies processing rules that will enable users to enter 810 internationalized resourceparts in the Extensible Messaging and 811 Presence Protocol (XMPP) and have the highest chance of getting the 812 content of the strings correct. (An XMPP resourcepart is the 813 optional portion of an XMPP address that follows an XMPP domainpart 814 and the '/' separator.) These processing rules are intended only for 815 XMPP resourceparts and are not intended for arbitrary text or any 816 other aspect of an XMPP address. 818 This profile defines the following, as required by [STRINGPREP]: 820 o The intended applicability of the profile: internationalized 821 resourceparts within XMPP 822 o The character repertoire that is the input and output to 823 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 824 o The mappings used: specified in Section 3 825 o The Unicode normalization used: specified in Section 4 826 o The characters that are prohibited as output: specified in Section 827 5 828 o Bidirectional character handling: specified in Section 6 830 B.2. Character Repertoire 832 This profile uses Unicode 3.2 with the list of unassigned code points 833 being Table A.1, both defined in Appendix A of [STRINGPREP]. 835 B.3. Mapping 837 This profile specifies mapping using the following tables from 838 [STRINGPREP]: 840 Table B.1 842 B.4. Normalization 844 This profile specifies the use of Unicode normalization form KC, as 845 described in [STRINGPREP]. 847 B.5. Prohibited Output 849 This profile specifies the prohibition of using the following tables 850 from [STRINGPREP]. 852 Table C.1.2 853 Table C.2.1 854 Table C.2.2 855 Table C.3 856 Table C.4 857 Table C.5 858 Table C.6 859 Table C.7 860 Table C.8 861 Table C.9 863 B.6. Bidirectional Characters 865 This profile specifies checking bidirectional strings, as described 866 in Section 6 of [STRINGPREP]. 868 Appendix C. Differences From RFC 3920 870 Based on consensus derived from implementation and deployment 871 experience as well as formal interoperability testing, the following 872 substantive modifications were made from RFC 3920. 874 o Corrected the ABNF syntax to (1) ensure consistency with [URI] and 875 [IRI], and (2) prevent zero-length localparts, domainparts, and 876 resourceparts. 877 o To avoid confusion with the term "node" as used in [XEP-0030] and 878 [XEP-0060], changed the term "node identifier" to "localpart" (but 879 retained the name "Nodeprep" for backward compatibility). 881 o To avoid confusion with the terms "resource" and "identifier" as 882 used in [URI], changed the term "resource identifier" to 883 "resourcepart". 884 o Corrected the nameprep processing rules to require use of the 885 UseSTD3ASCIIRules flag. 887 Appendix D. Copying Conditions 889 Regarding this entire document or any portion of it, the author makes 890 no guarantees and is not responsible for any damage resulting from 891 its use. The author grants irrevocable permission to anyone to use, 892 modify, and distribute it in any way that does not diminish the 893 rights of anyone else to use, modify, and distribute it, provided 894 that redistributed derivative works do not contain misleading author 895 or version information. Derivative works need not be licensed under 896 similar terms. 898 Author's Address 900 Peter Saint-Andre 901 Cisco 902 1899 Wyknoop Street, Suite 600 903 Denver, CO 80202 904 USA 906 Phone: +1-303-308-3282 907 Email: psaintan@cisco.com