idnits 2.17.1 draft-ietf-xmpp-address-01.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 7, 2010) is 5042 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-09 -- 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 Systems, Inc. 4 Intended status: Standards Track July 7, 2010 5 Expires: January 8, 2011 7 Extensible Messaging and Presence Protocol (XMPP): Address Format 8 draft-ietf-xmpp-address-01 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 8, 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 . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . 17 80 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 81 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 18 82 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 18 84 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 18 85 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19 86 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19 87 Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19 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 such entities was 96 originally developed in the Jabber open-source community in 1999 97 (thus for historical reasons the native address of an XMPP entity is 98 called a Jabber Identifier or JID). In essence, a JID contains up to 99 three parts, in the arrangement 100 (where the localpart and resourcepart are both discretionary and each 101 part can contain nearly any Unicode code point [UNICODE], encoded 102 according to [UTF-8]). The JID format was first described by 103 [XEP-0029] in 2002, then defined canonically by [RFC3920] in 2004. 104 As defined in RFC 3920, the XMPP address format re-uses the 105 "stringprep" technology for preparation of non-ASCII characters 106 [STRINGPREP], including the Nameprep profile for internationalized 107 domain names as specified in [NAMEPREP] and [IDNA2003] along with two 108 XMPP-specific profiles for the localpart and resourcepart. Since the 109 publication of RFC 3920, IDNA2003 has been superseded by IDNA2008 110 (see [IDNA-PROTO] and related documents). As a result, other 111 protocols that use stringprep (including XMPP) have begun to migrate 112 from stringprep toward more "modern" approaches. Because work on 113 improved handling of internationalized addresses is currently in 114 progress, specifying the XMPP address format in the specification 115 that obsoletes RFC 3920 would unacceptably delay the revision 116 process. Therefore, this specification provides updated 117 documentation of the XMPP address format (essentially copied from RFC 118 3920), with the intent that it can be superseded once work on a new 119 approach to internationalization is complete. 121 2. Addresses 123 2.1. Overview 125 An ENTITY is anything that is network-addressable and that can 126 communicate using XMPP. For historical reasons, the native address 127 of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID 128 contains a set of ordered elements formed of an XMPP localpart, 129 domainpart, and resourcepart. 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 Although the format of a JID is roughly consistent with [URI], an 172 entity's address on an XMPP network MUST be represented as a JID 173 (without a URI scheme) and not a [URI] or [IRI] as specified in 174 [XMPP-URI]; the latter specification is provided only for 175 identification and interaction outside the context of the XMPP wire 176 protocol itself. 178 Implementation Note: When dividing a JID into its component parts, 179 an implementation needs to match the separator characters '@' and 180 '/' before applying any transformation algorithms, which might 181 decompose certain Unicode code points to the separator characters 182 (e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040 183 COMMERCIAL AT). 185 2.2. Domainpart 187 The DOMAINPART of a JID is that portion after the '@' character (if 188 any) and before the '/' character (if any); it is the primary 189 identifier and is the only REQUIRED element of a JID (a mere 190 domainpart is a valid JID). Typically a domainpart identifies the 191 "home" server to which clients connect for XML routing and data 192 management functionality. However, it is not necessary for an XMPP 193 domainpart to identify an entity that provides core XMPP server 194 functionality (e.g., a domainpart can identify an entity such as a 195 multi-user chat service, a publish-subscribe service, or a user 196 directory). 198 The domainpart for every server or service that will communicate over 199 a network SHOULD be a fully qualified domain name or "FQDN" (see 200 [DNS]); although the domainpart MAY be either an Internet Protocol 201 (IPv4 or IPv6) address or a text label that is resolvable on a local 202 network (commonly called an "unqualified hostname"), it is possible 203 that domainparts that are IP addresses will not be acceptable to 204 other services for the sake of interdomain communication. 205 Furthermore, domainparts that are unqualified hostnames MUST NOT be 206 used on public networks but MAY be used on private networks. 208 Note: If the domainpart includes a final character considered to 209 be a label separator (dot) by [IDNA2003] or [DNS], this character 210 MUST be stripped from the domainpart before the JID of which it is 211 a part is used for the purpose of routing an XML stanza, comparing 212 against another JID, or constructing an [XMPP-URI]; in particular, 213 the character MUST be stripped before any other canonicalization 214 steps are taken, such as application of the [NAMEPREP] profile of 215 [STRINGPREP] or completion of the ToASCII operation as described 216 in [IDNA2003]. 218 A domainpart consisting of a fully qualified domain name MUST be an 219 "internationalized domain name" as defined in [IDNA2003], that is, "a 220 domain name in which every label is an internationalized label". 221 When preparing a text label (consisting of a sequence of properly- 222 encoded Unicode code points) for representation as an 223 internationalized label in the process of constructing an XMPP 224 domainpart or comparing two XMPP domainparts, an application MUST 225 ensure that for each text label it is possible to apply without 226 failing the ToASCII operation specified in [IDNA2003] with the 227 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other 228 than letters, digits, and hyphens). If the ToASCII operation can be 229 applied without failing, then the label is an internationalized 230 label. An internationalized domain name (and therefore an XMPP 231 domainpart) is constructed from its constituent internationalized 232 labels by following the rules specified in [IDNA2003]. 234 Note: The ToASCII operation includes application of the [NAMEPREP] 235 profile of [STRINGPREP] and encoding using the algorithm specified 236 in [PUNYCODE]; for details, see [IDNA2003]. Although the output 237 of the ToASCII operation is not used in XMPP, it MUST be possible 238 to apply that operation without failing. 240 In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a 241 "domain name slot". 243 2.3. Localpart 245 The LOCALPART of a JID is an optional identifier placed before the 246 domainpart and separated from the latter by the '@' character. 247 Typically a localpart uniquely identifies the entity requesting and 248 using network access provided by a server (i.e., a local account), 249 although it can also represent other kinds of entities (e.g., a chat 250 room associated with a multi-user chat service). The entity 251 represented by an XMPP localpart is addressed within the context of a 252 specific domain. 254 A localpart MUST NOT be zero bytes in length and MUST NOT be more 255 than 1023 bytes in length. 257 A localpart MUST be formatted such that the Nodeprep profile of 258 [STRINGPREP] can be applied without failing (see Appendix A). Before 259 comparing two localparts, an application MUST first ensure that the 260 Nodeprep profile has been applied to each identifier (the profile 261 need not be applied each time a comparison is made, as long as it has 262 been applied before comparison). 264 2.4. Resourcepart 266 The resourcepart of a JID is an optional identifier placed after the 267 domainpart and separated from the latter by the '/' character. A 268 resourcepart can modify either a address or a 269 mere address. Typically a resourcepart uniquely 270 identifies a specific connection (e.g., a device or location) or 271 object (e.g., an occupant in a multi-user chat room) belonging to the 272 entity associated with an XMPP localpart at a local domain. 274 When an XMPP address does not include a resourcepart (i.e., when it 275 is of the form or ), it is 276 referred to as a BARE JID. When an XMPP address includes a 277 resourcepart (i.e., when it is of the form or 278 ), is referred to as a FULL JID. 280 A resourcepart MUST NOT be zero bytes in length and MUST NOT be more 281 than 1023 bytes in length. 283 A resourcepart MUST be formatted such that the Resourceprep profile 284 of [STRINGPREP] can be applied without failing (see Appendix B). 285 Before comparing two resourceparts, an application MUST first ensure 286 that the Resourceprep profile has been applied to each identifier 287 (the profile need not be applied each time a comparison is made, as 288 long as it has been applied before comparison). 290 Note: For historical reasons, the term "resource identifier" is 291 often used in XMPP to refer to the optional portion of an XMPP 292 address that follows the domainpart and the "/" separator 293 character; to help prevent confusion between an XMPP "resource 294 identifier" and the meanings of "resource" and "identifier" 295 provided in Section 1.1 of [URI], this specification uses the term 296 "resourcepart" instead of "resource identifier" (as in RFC 3920). 298 XMPP entities SHOULD consider resourceparts to be opaque strings and 299 SHOULD NOT impute meaning to any given resourcepart. In particular: 301 o Use of the '/' character as a separator between the domainpart and 302 the resourcepart does not imply that XMPP addresses are 303 hierarchical in the way that, say, HTTP addresses are 304 hierarchical; thus for example an XMPP address of the form 305 does not identify a resource "bar" that 306 exists below a resource "foo" in a hierarchy of resources 307 associated with the entity "localpart@domain". 309 o The '@' character is allowed in the resourcepart, and is often 310 used in the "nick" shown in XMPP chatrooms. For example, the JID 311 describes an entity who is an 312 occupant of the room with an (asserted) 313 nick of . However, chatroom services do not 314 necessarily check such an asserted nick against the occupant's 315 real JID. 317 3. Internationalization Considerations 319 An XMPP server MUST support and enforce [IDNA2003] for domainparts, 320 the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and 321 the Resourceprep (Appendix B) profile of [STRINGPREP] for 322 resourceparts; this enables XMPP addresses to include a wide variety 323 of characters outside the US-ASCII range. 325 4. Security Considerations 327 4.1. Reuse of Stringprep 329 The security considerations described in [STRINGPREP] apply to the 330 Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined 331 in this document for XMPP localparts and resourceparts. The security 332 considerations described in [STRINGPREP] and [NAMEPREP] apply to the 333 Nameprep profile that is re-used here for XMPP domainparts. 335 4.2. Reuse of Unicode 337 The security considerations described in [UNICODE-SEC] apply to the 338 use of Unicode characters in XMPP addresses. 340 4.3. Confusable Characters 342 The Unicode and ISO/IEC 10646 repertoires have many characters that 343 look similar (so-called "confusable characters"). In many cases, 344 users of security protocols might perform visual matching, such as 345 when comparing the names of trusted third parties. Because it is 346 impossible to map similar-looking characters without a great deal of 347 context (such as knowing the fonts used), stringprep does nothing to 348 map similar-looking characters together, nor to prohibit some 349 characters because they look like others. Some specific suggestions 350 about identification and handling of confusable characters appear in 351 the Unicode Security Considerations [UNICODE-SEC]. 353 A localpart can be employed as one part of an entity's address in 354 XMPP. One common usage is as the username of an instant messaging 355 user; another is as the name of a multi-user chat room; and many 356 other kinds of entities could use localparts as part of their 357 addresses. The security of such services could be compromised based 358 on different interpretations of the internationalized localpart; for 359 example, a user entering a single internationalized localpart could 360 access another user's account information, or a user could gain 361 access to a hidden or otherwise restricted chat room or service. 363 A resourcepart can be employed as one part of an entity's address in 364 XMPP. One common usage is as the name for an instant messaging 365 user's connected resource; another is as the nickname of a user in a 366 multi-user chat room; and many other kinds of entities could use 367 resourceparts as part of their addresses. The security of such 368 services could be compromised based on different interpretations of 369 the internationalized resourcepart; for example, a user could attempt 370 to initiate multiple connections with the same name, or a user could 371 send a message to someone other than the intended recipient in a 372 multi-user chat room. 374 Further discussion is provided under Section 4.4.2. 376 4.4. Address Spoofing 378 There are two forms of address spoofing: forging and mimicking. 380 4.4.1. Address Forging 382 In the context of XMPP technologies, address forging occurs when an 383 entity is able to generate an XML stanza whose 'from' address does 384 not correspond to the account credentials with which the entity 385 authenticated onto the network (or an authorization identity provided 386 during SASL negotiation). For example, address forging occurs if an 387 entity that authenticated as "juliet@im.example.com" is able to send 388 XML stanzas from "nurse@im.example.com" or "romeo@example.net". 390 Address forging is difficult in XMPP systems, given the requirement 391 for sending servers to stamp 'from' addresses and for receiving 392 servers to verify sending domains via server-to-server authentication 393 (see [XMPP]). However, address forging is not impossible, since a 394 rogue server could forge JIDs at the sending domain by ignoring the 395 stamping requirement. Therefore, an entity outside the security 396 perimeter of a particular server cannot reliably distinguish between 397 bare JIDs of the form at that server and thus 398 can authenticate only the domainpart of such JIDs with any level of 399 assurance. This specification does not define methods for 400 discovering or counteracting such rogue servers. 402 Furthermore, it is possible for an attacker to forge JIDs at other 403 domains by means of a DNS poisoning attack if DNS security extensions 404 [DNSSEC] are not used. 406 4.4.2. Address Mimicking 408 Address mimicking occus when an entity provides legitimate 409 authentication credentials for and sends XML stanzas from an account 410 whose JID appears to a human user to be the same as another JID. For 411 example, in some XMPP clients the address "paypa1@example.org" 412 (spelled with the number one as the final character of the localpart) 413 might appear to be the same as "paypal@example.org (spelled with the 414 lower-case version of the letter "L"), especially on casual visual 415 inspection; this phenomenon is sometimes called "typejacking". A 416 more sophisticated example of address mimicking might involve the use 417 of characters from outside the US-ASCII range, such as the Cherokee 418 characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead 419 of the US-ASCII characters "STPETER". 421 In some examples of address mimicking, it is unlikely that the 422 average user could tell the difference between the real JID and the 423 fake JID. (Indeed, there is no way to distinguish with full 424 certainty which is the fake JID and which is the real JID; in some 425 communication contexts, the JID with Cherokee characters might be the 426 real JID and the JID with US-ASCII characters might thus appear to be 427 the fake JID.) Because JIDs can contain almost any Unicode 428 character, it can be relatively easy to mimic some JIDs in XMPP 429 systems. The possibility of address mimicking introduces security 430 vulnerabilities of the kind that have also plagued the World Wide 431 Web, specifically the phenomenon known as phishing. 433 As noted in [IDNA-DEFS], "there are no comprehensive technical 434 solutions to the problems of confusable characters". Mimicked JIDs 435 that involve characters from only one character set or from the 436 character set typically employed by a particular user are not easy to 437 combat (e.g., the simple typejacking attack previously described, 438 which relies on a surface similarity between the characters "1" and 439 "l" in some presentations). However, mimicked addresses that involve 440 characters from more than one character set, or from a character set 441 not typically employed by a particular user, can be mitigated 442 somewhat through intelligent presentation. In particular, every 443 human user of an XMPP technology presumably has a preferred language 444 (or, in some cases, a small set of preferred languages), which an 445 XMPP application SHOULD gather either explicitly from the user or 446 implicitly via the operating system of the user's device. 447 Furthermore, every language has a range (or a small set of ranges) of 448 characters normally used to represent that language in textual form. 449 Therefore, an XMPP application SHOULD warn the user when presenting a 450 JID that uses characters outside the normal range of the user's 451 preferred language(s). This recommendation is not intended to 452 discourage communication across language communities; instead, it 453 recognizes the existence of such language communities and encourages 454 due caution when presenting unfamiliar character sets to human users. 456 5. IANA Considerations 458 The following sections update the registrations provided in 459 [RFC3920]. 461 5.1. Nodeprep Profile of Stringprep 463 The Nodeprep profile of stringprep is defined under Nodeprep 464 (Appendix A). The IANA has registered Nodeprep in the stringprep 465 profile registry. 467 Name of this profile: 469 Nodeprep 471 RFC in which the profile is defined: 473 XXXX 475 Indicator whether or not this is the newest version of the profile: 477 This is the first version of Nodeprep 479 5.2. Resourceprep Profile of Stringprep 481 The Resourceprep profile of stringprep is defined under Resourceprep 482 (Appendix B). The IANA has registered Resourceprep in the stringprep 483 profile registry. 485 Name of this profile: 487 Resourceprep 489 RFC in which the profile is defined: 491 XXXX 493 Indicator whether or not this is the newest version of the profile: 495 This is the first version of Resourceprep 497 6. Conformance Requirements 499 This section describes a protocol feature set that summarizes the 500 conformance requirements of this specification. This feature set is 501 appropriate for use in software certification, interoperability 502 testing, and implementation reports. For each feature, this section 503 provides the following information: 505 o A human-readable name 507 o An informational description 509 o A reference to the particular section of this document that 510 normatively defines the feature 512 o Whether the feature applies to the Client role, the Server role, 513 or both (where "N/A" signifies that the feature is not applicable 514 to the specified role) 516 o Whether the feature MUST or SHOULD be implemented, where the 517 capitalized terms are to be understood as described in [KEYWORDS] 519 The feature set specified here attempts to adhere to the concepts and 520 formats proposed by Larry Masinter within the IETF's NEWTRK Working 521 Group in 2005, as captured in [INTEROP]. Although this feature set 522 is more detailed than called for by [REPORTS], it provides a suitable 523 basis for the generation of implementation reports to be submitted in 524 support of advancing this specification from Proposed Standard to 525 Draft Standard in accordance with [PROCESS]. 527 Feature: address-domain-length 528 Description: Ensure that the domainpart of an XMPP address is at 529 least one byte in length and at most 1023 bytes in length. 530 Section: Section 2.2 531 Roles: Both MUST. 533 Feature: address-domain-prep 534 Description: Ensure that the domainpart of an XMPP address conforms 535 to the Nameprep profile of Stringprep. 536 Section: Section 2.2 537 Roles: Client SHOULD, Server MUST. 539 Feature: address-localpart-length 540 Description: Ensure that the localpart of an XMPP address is at 541 least one byte in length and at most 1023 bytes in length. 542 Section: Section 2.3 543 Roles: Both MUST. 545 Feature: address-localpart-prep 546 Description: Ensure that the localpart of an XMPP address conforms 547 to the Nodeprep profile of Stringprep. 548 Section: Section 2.3 549 Roles: Client SHOULD, Server MUST. 551 Feature: address-resource-length 552 Description: Ensure that the resourcepart of an XMPP address is at 553 least one byte in length and at most 1023 bytes in length. 554 Section: Section 2.4 555 Roles: Both MUST. 557 Feature: address-resource-prep 558 Description: Ensure that the resourcepart of an XMPP address 559 conforms to the Resourceprep profile of Stringprep. 561 Section: Section 2.2 562 Roles: Client SHOULD, Server MUST. 564 7. References 566 7.1. Normative References 568 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 569 Specifications: ABNF", STD 68, RFC 5234, January 2008. 571 [IDNA2003] 572 Faltstrom, P., Hoffman, P., and A. Costello, 573 "Internationalizing Domain Names in Applications (IDNA)", 574 RFC 3490, March 2003. 576 [KEYWORDS] 577 Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 [NAMEPREP] 581 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 582 Profile for Internationalized Domain Names (IDN)", 583 RFC 3491, March 2003. 585 [STRINGPREP] 586 Hoffman, P. and M. Blanchet, "Preparation of 587 Internationalized Strings ("stringprep")", RFC 3454, 588 December 2002. 590 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 591 3.2.0", 2000. 593 The Unicode Standard, Version 3.2.0 is defined by The 594 Unicode Standard, Version 3.0 (Reading, MA, Addison- 595 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 596 Unicode Standard Annex #27: Unicode 3.1 597 (http://www.unicode.org/reports/tr27/) and by the Unicode 598 Standard Annex #28: Unicode 3.2 599 (http://www.unicode.org/reports/tr28/). 601 [UNICODE-SEC] 602 The Unicode Consortium, "Unicode Technical Report #36: 603 Unicode Security Considerations", 2008. 605 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 606 10646", STD 63, RFC 3629, November 2003. 608 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 609 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-09 (work 610 in progress), June 2010. 612 7.2. Informative References 614 [DNS] Mockapetris, P., "Domain names - implementation and 615 specification", STD 13, RFC 1035, November 1987. 617 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 618 Rose, "DNS Security Introduction and Requirements", 619 RFC 4033, March 2005. 621 [IDNA-DEFS] 622 Klensin, J., "Internationalized Domain Names for 623 Applications (IDNA): Definitions and Document Framework", 624 draft-ietf-idnabis-defs-13 (work in progress), 625 January 2010. 627 [IDNA-PROTO] 628 Klensin, J., "Internationalized Domain Names in 629 Applications (IDNA): Protocol", 630 draft-ietf-idnabis-protocol-18 (work in progress), 631 January 2010. 633 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 634 Reporting", draft-ietf-newtrk-interop-reports-00 (work in 635 progress), October 2005. 637 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 638 Identifiers (IRIs)", RFC 3987, January 2005. 640 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 641 3", BCP 9, RFC 2026, October 1996. 643 [PUNYCODE] 644 Costello, A., "Punycode: A Bootstring encoding of Unicode 645 for Internationalized Domain Names in Applications 646 (IDNA)", RFC 3492, March 2003. 648 [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation 649 and Implementation Reports for Advancement to Draft 650 Standard", BCP 9, RFC 5657, September 2009. 652 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 653 Protocol (XMPP): Core", RFC 3920, October 2004. 655 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 656 Resource Identifier (URI): Generic Syntax", STD 66, 657 RFC 3986, January 2005. 659 [XEP-0029] 660 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 661 XEP 0029, October 2003. 663 [XEP-0030] 664 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 665 Andre, "Service Discovery", XSF XEP 0030, June 2008. 667 [XEP-0045] 668 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 669 January in progress, last updated 2010. 671 [XEP-0060] 672 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 673 Subscribe", XSF XEP 0060, September 2008. 675 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 676 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 677 Edition)", World Wide Web Consortium Recommendation REC- 678 xml-20060816, August 2006, 679 . 681 [XMPP-URI] 682 Saint-Andre, P., "Internationalized Resource Identifiers 683 (IRIs) and Uniform Resource Identifiers (URIs) for the 684 Extensible Messaging and Presence Protocol (XMPP)", 685 RFC 5122, February 2008. 687 Appendix A. Nodeprep 689 A.1. Introduction 691 This appendix defines the "Nodeprep" profile of stringprep. As such, 692 it specifies processing rules that will enable users to enter 693 internationalized localparts in the Extensible Messaging and Presence 694 Protocol (XMPP) and have the highest chance of getting the content of 695 the strings correct. (An XMPP localpart is the optional portion of 696 an XMPP address that precedes an XMPP domainpart and the '@' 697 separator; it is often but not exclusively associated with an instant 698 messaging username.) These processing rules are intended only for 699 XMPP localparts and are not intended for arbitrary text or any other 700 aspect of an XMPP address. 702 This profile defines the following, as required by [STRINGPREP]: 704 o The intended applicability of the profile: internationalized 705 localparts within XMPP 706 o The character repertoire that is the input and output to 707 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 708 o The mappings used: specified in Section 3 709 o The Unicode normalization used: specified in Section 4 710 o The characters that are prohibited as output: specified in Section 711 5 712 o Bidirectional character handling: specified in Section 6 714 A.2. Character Repertoire 716 This profile uses Unicode 3.2 with the list of unassigned code points 717 being Table A.1, both defined in Appendix A of [STRINGPREP]. 719 A.3. Mapping 721 This profile specifies mapping using the following tables from 722 [STRINGPREP]: 724 Table B.1 725 Table B.2 727 A.4. Normalization 729 This profile specifies the use of Unicode normalization form KC, as 730 described in [STRINGPREP]. 732 A.5. Prohibited Output 734 This profile specifies the prohibition of using the following tables 735 from [STRINGPREP]. 737 Table C.1.1 738 Table C.1.2 739 Table C.2.1 740 Table C.2.2 741 Table C.3 742 Table C.4 743 Table C.5 744 Table C.6 745 Table C.7 746 Table C.8 747 Table C.9 749 In addition, the following additional Unicode characters are also 750 prohibited: 752 U+0022 (QUOTATION MARK), i.e., " 753 U+0026 (AMPERSAND), i.e., & 754 U+0027 (APOSTROPHE), i.e., ' 755 U+002F (SOLIDUS), i.e., / 756 U+003A (COLON), i.e., : 757 U+003C (LESS-THAN SIGN), i.e., < 758 U+003E (GREATER-THAN SIGN), i.e., > 759 U+0040 (COMMERCIAL AT), i.e., @ 761 A.6. Bidirectional Characters 763 This profile specifies checking bidirectional strings, as described 764 in Section 6 of [STRINGPREP]. 766 A.7. Notes 768 Because the additional characters prohibited by Nodeprep are 769 prohibited after normalization, an implementation MUST NOT enable a 770 human user to input any Unicode code point whose decomposition 771 includes those characters; such code points include but are not 772 necessarily limited to the following (refer to [UNICODE] for complete 773 information). 775 o U+2100 (ACCOUNT OF) 776 o U+2101 (ADDRESSED TO THE SUBJECT) 777 o U+2105 (CARE OF) 778 o U+2106 (CADA UNA) 779 o U+226E (NOT LESS-THAN) 780 o U+226F (NOT GREATER-THAN) 781 o U+2A74 (DOUBLE COLON EQUAL) 782 o U+FE13 (SMALL COLON) 783 o U+FE60 (SMALL AMPERSAND) 784 o U+FE64 (SMALL LESS-THAN SIGN) 785 o U+FE65 (SMALL GREATER-THAN SIGN) 786 o U+FE6B (SMALL COMMERCIAL AT) 787 o U+FF02 (FULLWIDTH QUOTATION MARK) 788 o U+FF06 (FULLWIDTH AMPERSAND) 789 o U+FF07 (FULLWIDTH APOSTROPHE) 790 o U+FF0F (FULLWIDTH SOLIDUS) 791 o U+FF1A (FULLWIDTH COLON) 792 o U+FF1C (FULLWIDTH LESS-THAN SIGN) 793 o U+FF1E (FULLWIDTH GREATER-THAN SIGN) 794 o U+FF20 (FULLWIDTH COMMERCIAL AT) 796 Appendix B. Resourceprep 797 B.1. Introduction 799 This appendix defines the "Resourceprep" profile of stringprep. As 800 such, it specifies processing rules that will enable users to enter 801 internationalized resourceparts in the Extensible Messaging and 802 Presence Protocol (XMPP) and have the highest chance of getting the 803 content of the strings correct. (An XMPP resourcepart is the 804 optional portion of an XMPP address that follows an XMPP domainpart 805 and the '/' separator.) These processing rules are intended only for 806 XMPP resourceparts and are not intended for arbitrary text or any 807 other aspect of an XMPP address. 809 This profile defines the following, as required by [STRINGPREP]: 811 o The intended applicability of the profile: internationalized 812 resourceparts within XMPP 813 o The character repertoire that is the input and output to 814 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 815 o The mappings used: specified in Section 3 816 o The Unicode normalization used: specified in Section 4 817 o The characters that are prohibited as output: specified in Section 818 5 819 o Bidirectional character handling: specified in Section 6 821 B.2. Character Repertoire 823 This profile uses Unicode 3.2 with the list of unassigned code points 824 being Table A.1, both defined in Appendix A of [STRINGPREP]. 826 B.3. Mapping 828 This profile specifies mapping using the following tables from 829 [STRINGPREP]: 831 Table B.1 833 B.4. Normalization 835 This profile specifies the use of Unicode normalization form KC, as 836 described in [STRINGPREP]. 838 B.5. Prohibited Output 840 This profile specifies the prohibition of using the following tables 841 from [STRINGPREP]. 843 Table C.1.2 844 Table C.2.1 845 Table C.2.2 846 Table C.3 847 Table C.4 848 Table C.5 849 Table C.6 850 Table C.7 851 Table C.8 852 Table C.9 854 B.6. Bidirectional Characters 856 This profile specifies checking bidirectional strings, as described 857 in Section 6 of [STRINGPREP]. 859 Appendix C. Differences From RFC 3920 861 Based on consensus derived from implementation and deployment 862 experience as well as formal interoperability testing, the following 863 substantive modifications were made from RFC 3920. 865 o Corrected the ABNF syntax to (1) ensure consistency with [URI] and 866 [IRI], and (2) prevent zero-length localparts, domainparts, and 867 resourceparts. 868 o To avoid confusion with the term "node" as used in [XEP-0030] and 869 [XEP-0060], changed the term "node identifier" to "localpart" (but 870 retained the name "Nodeprep" for backward compatibility). 871 o To avoid confusion with the terms "resource" and "identifier" as 872 used in [URI], changed the term "resource identifier" to 873 "resourcepart". 874 o Corrected the nameprep processing rules to require use of the 875 UseSTD3ASCIIRules flag. 877 Appendix D. Copying Conditions 879 Regarding this entire document or any portion of it, the author makes 880 no guarantees and is not responsible for any damage resulting from 881 its use. The author grants irrevocable permission to anyone to use, 882 modify, and distribute it in any way that does not diminish the 883 rights of anyone else to use, modify, and distribute it, provided 884 that redistributed derivative works do not contain misleading author 885 or version information. Derivative works need not be licensed under 886 similar terms. 888 Author's Address 890 Peter Saint-Andre 891 Cisco Systems, Inc. 892 1899 Wyknoop Street, Suite 600 893 Denver, CO 80202 894 USA 896 Phone: +1-303-308-3282 897 Email: psaintan@cisco.com