idnits 2.17.1 draft-ietf-xmpp-address-02.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 12, 2010) is 5035 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 Systems, Inc. 4 Intended status: Standards Track July 12, 2010 5 Expires: January 13, 2011 7 Extensible Messaging and Presence Protocol (XMPP): Address Format 8 draft-ietf-xmpp-address-02 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 13, 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 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 MAY be either an Internet Protocol 199 (IPv4 or IPv6) address or a text label that is resolvable on a local 200 network (commonly called an "unqualified hostname"), it is possible 201 that domainparts that are IP addresses will not be acceptable to 202 other services for the sake of interdomain communication. 203 Furthermore, domainparts that are unqualified hostnames MUST NOT be 204 used on public networks but MAY be used on private networks. 206 Note: If the domainpart includes a final character considered to 207 be a label separator (dot) by [IDNA2003] or [DNS], this character 208 MUST be stripped from the domainpart before the JID of which it is 209 a part is used for the purpose of routing an XML stanza, comparing 210 against another JID, or constructing an [XMPP-URI]; in particular, 211 the character MUST be stripped before any other canonicalization 212 steps are taken, such as application of the [NAMEPREP] profile of 213 [STRINGPREP] or completion of the ToASCII operation as described 214 in [IDNA2003]. 216 A domainpart consisting of a fully qualified domain name MUST be an 217 "internationalized domain name" as defined in [IDNA2003], that is, "a 218 domain name in which every label is an internationalized label". 219 When preparing a text label (consisting of a sequence of properly- 220 encoded Unicode code points) for representation as an 221 internationalized label in the process of constructing an XMPP 222 domainpart or comparing two XMPP domainparts, an application MUST 223 ensure that for each text label it is possible to apply without 224 failing the ToASCII operation specified in [IDNA2003] with the 225 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other 226 than letters, digits, and hyphens). If the ToASCII operation can be 227 applied without failing, then the label is an internationalized 228 label. An internationalized domain name (and therefore an XMPP 229 domainpart) is constructed from its constituent internationalized 230 labels by following the rules specified in [IDNA2003]. 232 Note: The ToASCII operation includes application of the [NAMEPREP] 233 profile of [STRINGPREP] and encoding using the algorithm specified 234 in [PUNYCODE]; for details, see [IDNA2003]. Although the output 235 of the ToASCII operation is not used in XMPP, it MUST be possible 236 to apply that operation without failing. 238 In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a 239 "domain name slot". 241 2.3. Localpart 243 The LOCALPART of a JID is an optional identifier placed before the 244 domainpart and separated from the latter by the '@' character. 245 Typically a localpart uniquely identifies the entity requesting and 246 using network access provided by a server (i.e., a local account), 247 although it can also represent other kinds of entities (e.g., a chat 248 room associated with a multi-user chat service). The entity 249 represented by an XMPP localpart is addressed within the context of a 250 specific domain. 252 A localpart MUST NOT be zero bytes in length and MUST NOT be more 253 than 1023 bytes in length. 255 A localpart MUST be formatted such that the Nodeprep profile of 256 [STRINGPREP] can be applied without failing (see Appendix A). Before 257 comparing two localparts, an application MUST first ensure that the 258 Nodeprep profile has been applied to each identifier (the profile 259 need not be applied each time a comparison is made, as long as it has 260 been applied before comparison). 262 2.4. Resourcepart 264 The resourcepart of a JID is an optional identifier placed after the 265 domainpart and separated from the latter by the '/' character. A 266 resourcepart can modify either a address or a 267 mere address. Typically a resourcepart uniquely 268 identifies a specific connection (e.g., a device or location) or 269 object (e.g., an occupant in a multi-user chat room) belonging to the 270 entity associated with an XMPP localpart at a local domain. 272 When an XMPP address does not include a resourcepart (i.e., when it 273 is of the form or ), it is 274 referred to as a BARE JID. When an XMPP address includes a 275 resourcepart (i.e., when it is of the form or 276 ), is referred to as a FULL JID. 278 A resourcepart MUST NOT be zero bytes in length and MUST NOT be more 279 than 1023 bytes in length. 281 A resourcepart MUST be formatted such that the Resourceprep profile 282 of [STRINGPREP] can be applied without failing (see Appendix B). 283 Before comparing two resourceparts, an application MUST first ensure 284 that the Resourceprep profile has been applied to each identifier 285 (the profile need not be applied each time a comparison is made, as 286 long as it has been applied before comparison). 288 Note: For historical reasons, the term "resource identifier" is 289 often used in XMPP to refer to the optional portion of an XMPP 290 address that follows the domainpart and the "/" separator 291 character; to help prevent confusion between an XMPP "resource 292 identifier" and the meanings of "resource" and "identifier" 293 provided in Section 1.1 of [URI], this specification uses the term 294 "resourcepart" instead of "resource identifier" (as in RFC 3920). 296 XMPP entities SHOULD consider resourceparts to be opaque strings and 297 SHOULD NOT impute meaning to any given resourcepart. In particular: 299 o Use of the '/' character as a separator between the domainpart and 300 the resourcepart does not imply that XMPP addresses are 301 hierarchical in the way that, say, HTTP addresses are 302 hierarchical; thus for example an XMPP address of the form 303 does not identify a resource "bar" that 304 exists below a resource "foo" in a hierarchy of resources 305 associated with the entity "localpart@domain". 307 o The '@' character is allowed in the resourcepart, and is often 308 used in the "nick" shown in XMPP chatrooms. For example, the JID 309 describes an entity who is an 310 occupant of the room with an (asserted) 311 nick of . However, chatroom services do not 312 necessarily check such an asserted nick against the occupant's 313 real JID. 315 3. Internationalization Considerations 317 XMPP servers MUST, and XMPP clients SHOULD, support [IDNA2003] for 318 domainparts (including the [NAMEPREP] profile of [STRINGPREP]), the 319 Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and the 320 Resourceprep (Appendix B) profile of [STRINGPREP] for resourceparts; 321 this enables XMPP addresses to include a wide variety of characters 322 outside the US-ASCII range. Rules for enforcement of the XMPP 323 address format are provided in [XMPP]. 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 4.4. Address Spoofing 376 There are two forms of address spoofing: forging and mimicking. 378 4.4.1. Address Forging 380 In the context of XMPP technologies, address forging occurs when an 381 entity is able to generate an XML stanza whose 'from' address does 382 not correspond to the account credentials with which the entity 383 authenticated onto the network (or an authorization identity provided 384 during SASL negotiation). For example, address forging occurs if an 385 entity that authenticated as "juliet@im.example.com" is able to send 386 XML stanzas from "nurse@im.example.com" or "romeo@example.net". 388 Address forging is difficult in XMPP systems, given the requirement 389 for sending servers to stamp 'from' addresses and for receiving 390 servers to verify sending domains via server-to-server authentication 391 (see [XMPP]). However, address forging is not impossible, since a 392 rogue server could forge JIDs at the sending domain by ignoring the 393 stamping requirement. Therefore, an entity outside the security 394 perimeter of a particular server cannot reliably distinguish between 395 bare JIDs of the form at that server and thus 396 can authenticate only the domainpart of such JIDs with any level of 397 assurance. This specification does not define methods for 398 discovering or counteracting such rogue servers. 400 Furthermore, it is possible for an attacker to forge JIDs at other 401 domains by means of a DNS poisoning attack if DNS security extensions 402 [DNSSEC] are not used. 404 4.4.2. Address Mimicking 406 Address mimicking occurs when an entity provides legitimate 407 authentication credentials for and sends XML stanzas from an account 408 whose JID appears to a human user to be the same as another JID. For 409 example, in some XMPP clients the address "paypa1@example.org" 410 (spelled with the number one as the final character of the localpart) 411 might appear to be the same as "paypal@example.org (spelled with the 412 lower-case version of the letter "L"), especially on casual visual 413 inspection; this phenomenon is sometimes called "typejacking". A 414 more sophisticated example of address mimicking might involve the use 415 of characters from outside the US-ASCII range, such as the Cherokee 416 characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead 417 of the US-ASCII characters "STPETER". 419 In some examples of address mimicking, it is unlikely that the 420 average user could tell the difference between the real JID and the 421 fake JID. (Indeed, there is no way to distinguish with full 422 certainty which is the fake JID and which is the real JID; in some 423 communication contexts, the JID with Cherokee characters might be the 424 real JID and the JID with US-ASCII characters might thus appear to be 425 the fake JID.) Because JIDs can contain almost any Unicode 426 character, it can be relatively easy to mimic some JIDs in XMPP 427 systems. The possibility of address mimicking introduces security 428 vulnerabilities of the kind that have also plagued the World Wide 429 Web, specifically the phenomenon known as phishing. 431 As noted in [IDNA-DEFS], "there are no comprehensive technical 432 solutions to the problems of confusable characters". Mimicked JIDs 433 that involve characters from only one character set or from the 434 character set typically employed by a particular user are not easy to 435 combat (e.g., the simple typejacking attack previously described, 436 which relies on a surface similarity between the characters "1" and 437 "l" in some presentations). However, mimicked addresses that involve 438 characters from more than one character set, or from a character set 439 not typically employed by a particular user, can be mitigated 440 somewhat through intelligent presentation. In particular, every 441 human user of an XMPP technology presumably has a preferred language 442 (or, in some cases, a small set of preferred languages), which an 443 XMPP application SHOULD gather either explicitly from the user or 444 implicitly via the operating system of the user's device. 445 Furthermore, every language has a range (or a small set of ranges) of 446 characters normally used to represent that language in textual form. 447 Therefore, an XMPP application SHOULD warn the user when presenting a 448 JID that uses characters outside the normal range of the user's 449 preferred language(s). This recommendation is not intended to 450 discourage communication across language communities; instead, it 451 recognizes the existence of such language communities and encourages 452 due caution when presenting unfamiliar character sets to human users. 454 5. IANA Considerations 456 The following sections update the registrations provided in 457 [RFC3920]. 459 5.1. Nodeprep Profile of Stringprep 461 The Nodeprep profile of stringprep is defined under Nodeprep 462 (Appendix A). The IANA has registered Nodeprep in the stringprep 463 profile registry. 465 Name of this profile: 467 Nodeprep 469 RFC in which the profile is defined: 471 XXXX 473 Indicator whether or not this is the newest version of the profile: 475 This is the first version of Nodeprep 477 5.2. Resourceprep Profile of Stringprep 479 The Resourceprep profile of stringprep is defined under Resourceprep 480 (Appendix B). The IANA has registered Resourceprep in the stringprep 481 profile registry. 483 Name of this profile: 485 Resourceprep 487 RFC in which the profile is defined: 489 XXXX 491 Indicator whether or not this is the newest version of the profile: 493 This is the first version of Resourceprep 495 6. Conformance Requirements 497 This section describes a protocol feature set that summarizes the 498 conformance requirements of this specification. This feature set is 499 appropriate for use in software certification, interoperability 500 testing, and implementation reports. For each feature, this section 501 provides the following information: 503 o A human-readable name 505 o An informational description 507 o A reference to the particular section of this document that 508 normatively defines the feature 510 o Whether the feature applies to the Client role, the Server role, 511 or both (where "N/A" signifies that the feature is not applicable 512 to the specified role) 514 o Whether the feature MUST or SHOULD be implemented, where the 515 capitalized terms are to be understood as described in [KEYWORDS] 517 The feature set specified here attempts to adhere to the concepts and 518 formats proposed by Larry Masinter within the IETF's NEWTRK Working 519 Group in 2005, as captured in [INTEROP]. Although this feature set 520 is more detailed than called for by [REPORTS], it provides a suitable 521 basis for the generation of implementation reports to be submitted in 522 support of advancing this specification from Proposed Standard to 523 Draft Standard in accordance with [PROCESS]. 525 Feature: address-domain-length 526 Description: Ensure that the domainpart of an XMPP address is at 527 least one byte in length and at most 1023 bytes in length. 528 Section: Section 2.2 529 Roles: Both MUST. 531 Feature: address-domain-prep 532 Description: Ensure that the domainpart of an XMPP address conforms 533 to the Nameprep profile of Stringprep. 534 Section: Section 2.2 535 Roles: Client SHOULD, Server MUST. 537 Feature: address-localpart-length 538 Description: Ensure that the localpart of an XMPP address is at 539 least one byte in length and at most 1023 bytes in length. 540 Section: Section 2.3 541 Roles: Both MUST. 543 Feature: address-localpart-prep 544 Description: Ensure that the localpart of an XMPP address conforms 545 to the Nodeprep profile of Stringprep. 546 Section: Section 2.3 547 Roles: Client SHOULD, Server MUST. 549 Feature: address-resource-length 550 Description: Ensure that the resourcepart of an XMPP address is at 551 least one byte in length and at most 1023 bytes in length. 552 Section: Section 2.4 553 Roles: Both MUST. 555 Feature: address-resource-prep 556 Description: Ensure that the resourcepart of an XMPP address 557 conforms to the Resourceprep profile of Stringprep. 559 Section: Section 2.2 560 Roles: Client SHOULD, Server MUST. 562 7. References 564 7.1. Normative References 566 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 567 Specifications: ABNF", STD 68, RFC 5234, January 2008. 569 [IDNA2003] 570 Faltstrom, P., Hoffman, P., and A. Costello, 571 "Internationalizing Domain Names in Applications (IDNA)", 572 RFC 3490, March 2003. 574 [KEYWORDS] 575 Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [NAMEPREP] 579 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 580 Profile for Internationalized Domain Names (IDN)", 581 RFC 3491, March 2003. 583 [STRINGPREP] 584 Hoffman, P. and M. Blanchet, "Preparation of 585 Internationalized Strings ("stringprep")", RFC 3454, 586 December 2002. 588 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 589 3.2.0", 2000. 591 The Unicode Standard, Version 3.2.0 is defined by The 592 Unicode Standard, Version 3.0 (Reading, MA, Addison- 593 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 594 Unicode Standard Annex #27: Unicode 3.1 595 (http://www.unicode.org/reports/tr27/) and by the Unicode 596 Standard Annex #28: Unicode 3.2 597 (http://www.unicode.org/reports/tr28/). 599 [UNICODE-SEC] 600 The Unicode Consortium, "Unicode Technical Report #36: 601 Unicode Security Considerations", 2008. 603 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 604 10646", STD 63, RFC 3629, November 2003. 606 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 607 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-10 (work 608 in progress), July 2010. 610 7.2. Informative References 612 [DNS] Mockapetris, P., "Domain names - implementation and 613 specification", STD 13, RFC 1035, November 1987. 615 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 616 Rose, "DNS Security Introduction and Requirements", 617 RFC 4033, March 2005. 619 [IDNA-DEFS] 620 Klensin, J., "Internationalized Domain Names for 621 Applications (IDNA): Definitions and Document Framework", 622 draft-ietf-idnabis-defs-13 (work in progress), 623 January 2010. 625 [IDNA-PROTO] 626 Klensin, J., "Internationalized Domain Names in 627 Applications (IDNA): Protocol", 628 draft-ietf-idnabis-protocol-18 (work in progress), 629 January 2010. 631 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 632 Reporting", draft-ietf-newtrk-interop-reports-00 (work in 633 progress), October 2005. 635 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 636 Identifiers (IRIs)", RFC 3987, January 2005. 638 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 639 3", BCP 9, RFC 2026, October 1996. 641 [PUNYCODE] 642 Costello, A., "Punycode: A Bootstring encoding of Unicode 643 for Internationalized Domain Names in Applications 644 (IDNA)", RFC 3492, March 2003. 646 [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation 647 and Implementation Reports for Advancement to Draft 648 Standard", BCP 9, RFC 5657, September 2009. 650 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 651 Protocol (XMPP): Core", RFC 3920, October 2004. 653 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 654 Resource Identifier (URI): Generic Syntax", STD 66, 655 RFC 3986, January 2005. 657 [XEP-0029] 658 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 659 XEP 0029, October 2003. 661 [XEP-0030] 662 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 663 Andre, "Service Discovery", XSF XEP 0030, June 2008. 665 [XEP-0045] 666 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 667 January in progress, last updated 2010. 669 [XEP-0060] 670 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 671 Subscribe", XSF XEP 0060, September 2008. 673 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 674 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 675 Edition)", World Wide Web Consortium Recommendation REC- 676 xml-20060816, August 2006, 677 . 679 [XMPP-URI] 680 Saint-Andre, P., "Internationalized Resource Identifiers 681 (IRIs) and Uniform Resource Identifiers (URIs) for the 682 Extensible Messaging and Presence Protocol (XMPP)", 683 RFC 5122, February 2008. 685 Appendix A. Nodeprep 687 A.1. Introduction 689 This appendix defines the "Nodeprep" profile of stringprep. As such, 690 it specifies processing rules that will enable users to enter 691 internationalized localparts in the Extensible Messaging and Presence 692 Protocol (XMPP) and have the highest chance of getting the content of 693 the strings correct. (An XMPP localpart is the optional portion of 694 an XMPP address that precedes an XMPP domainpart and the '@' 695 separator; it is often but not exclusively associated with an instant 696 messaging username.) These processing rules are intended only for 697 XMPP localparts and are not intended for arbitrary text or any other 698 aspect of an XMPP address. 700 This profile defines the following, as required by [STRINGPREP]: 702 o The intended applicability of the profile: internationalized 703 localparts within XMPP 704 o The character repertoire that is the input and output to 705 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 706 o The mappings used: specified in Section 3 707 o The Unicode normalization used: specified in Section 4 708 o The characters that are prohibited as output: specified in Section 709 5 710 o Bidirectional character handling: specified in Section 6 712 A.2. Character Repertoire 714 This profile uses Unicode 3.2 with the list of unassigned code points 715 being Table A.1, both defined in Appendix A of [STRINGPREP]. 717 A.3. Mapping 719 This profile specifies mapping using the following tables from 720 [STRINGPREP]: 722 Table B.1 723 Table B.2 725 A.4. Normalization 727 This profile specifies the use of Unicode normalization form KC, as 728 described in [STRINGPREP]. 730 A.5. Prohibited Output 732 This profile specifies the prohibition of using the following tables 733 from [STRINGPREP]. 735 Table C.1.1 736 Table C.1.2 737 Table C.2.1 738 Table C.2.2 739 Table C.3 740 Table C.4 741 Table C.5 742 Table C.6 743 Table C.7 744 Table C.8 745 Table C.9 747 In addition, the following additional Unicode characters are also 748 prohibited: 750 U+0022 (QUOTATION MARK), i.e., " 751 U+0026 (AMPERSAND), i.e., & 752 U+0027 (APOSTROPHE), i.e., ' 753 U+002F (SOLIDUS), i.e., / 754 U+003A (COLON), i.e., : 755 U+003C (LESS-THAN SIGN), i.e., < 756 U+003E (GREATER-THAN SIGN), i.e., > 757 U+0040 (COMMERCIAL AT), i.e., @ 759 A.6. Bidirectional Characters 761 This profile specifies checking bidirectional strings, as described 762 in Section 6 of [STRINGPREP]. 764 A.7. Notes 766 Because the additional characters prohibited by Nodeprep are 767 prohibited after normalization, an implementation MUST NOT enable a 768 human user to input any Unicode code point whose decomposition 769 includes those characters; such code points include but are not 770 necessarily limited to the following (refer to [UNICODE] for complete 771 information). 773 o U+2100 (ACCOUNT OF) 774 o U+2101 (ADDRESSED TO THE SUBJECT) 775 o U+2105 (CARE OF) 776 o U+2106 (CADA UNA) 777 o U+226E (NOT LESS-THAN) 778 o U+226F (NOT GREATER-THAN) 779 o U+2A74 (DOUBLE COLON EQUAL) 780 o U+FE13 (SMALL COLON) 781 o U+FE60 (SMALL AMPERSAND) 782 o U+FE64 (SMALL LESS-THAN SIGN) 783 o U+FE65 (SMALL GREATER-THAN SIGN) 784 o U+FE6B (SMALL COMMERCIAL AT) 785 o U+FF02 (FULLWIDTH QUOTATION MARK) 786 o U+FF06 (FULLWIDTH AMPERSAND) 787 o U+FF07 (FULLWIDTH APOSTROPHE) 788 o U+FF0F (FULLWIDTH SOLIDUS) 789 o U+FF1A (FULLWIDTH COLON) 790 o U+FF1C (FULLWIDTH LESS-THAN SIGN) 791 o U+FF1E (FULLWIDTH GREATER-THAN SIGN) 792 o U+FF20 (FULLWIDTH COMMERCIAL AT) 794 Appendix B. Resourceprep 795 B.1. Introduction 797 This appendix defines the "Resourceprep" profile of stringprep. As 798 such, it specifies processing rules that will enable users to enter 799 internationalized resourceparts in the Extensible Messaging and 800 Presence Protocol (XMPP) and have the highest chance of getting the 801 content of the strings correct. (An XMPP resourcepart is the 802 optional portion of an XMPP address that follows an XMPP domainpart 803 and the '/' separator.) These processing rules are intended only for 804 XMPP resourceparts and are not intended for arbitrary text or any 805 other aspect of an XMPP address. 807 This profile defines the following, as required by [STRINGPREP]: 809 o The intended applicability of the profile: internationalized 810 resourceparts within XMPP 811 o The character repertoire that is the input and output to 812 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 813 o The mappings used: specified in Section 3 814 o The Unicode normalization used: specified in Section 4 815 o The characters that are prohibited as output: specified in Section 816 5 817 o Bidirectional character handling: specified in Section 6 819 B.2. Character Repertoire 821 This profile uses Unicode 3.2 with the list of unassigned code points 822 being Table A.1, both defined in Appendix A of [STRINGPREP]. 824 B.3. Mapping 826 This profile specifies mapping using the following tables from 827 [STRINGPREP]: 829 Table B.1 831 B.4. Normalization 833 This profile specifies the use of Unicode normalization form KC, as 834 described in [STRINGPREP]. 836 B.5. Prohibited Output 838 This profile specifies the prohibition of using the following tables 839 from [STRINGPREP]. 841 Table C.1.2 842 Table C.2.1 843 Table C.2.2 844 Table C.3 845 Table C.4 846 Table C.5 847 Table C.6 848 Table C.7 849 Table C.8 850 Table C.9 852 B.6. Bidirectional Characters 854 This profile specifies checking bidirectional strings, as described 855 in Section 6 of [STRINGPREP]. 857 Appendix C. Differences From RFC 3920 859 Based on consensus derived from implementation and deployment 860 experience as well as formal interoperability testing, the following 861 substantive modifications were made from RFC 3920. 863 o Corrected the ABNF syntax to (1) ensure consistency with [URI] and 864 [IRI], and (2) prevent zero-length localparts, domainparts, and 865 resourceparts. 866 o To avoid confusion with the term "node" as used in [XEP-0030] and 867 [XEP-0060], changed the term "node identifier" to "localpart" (but 868 retained the name "Nodeprep" for backward compatibility). 869 o To avoid confusion with the terms "resource" and "identifier" as 870 used in [URI], changed the term "resource identifier" to 871 "resourcepart". 872 o Corrected the nameprep processing rules to require use of the 873 UseSTD3ASCIIRules flag. 875 Appendix D. Copying Conditions 877 Regarding this entire document or any portion of it, the author makes 878 no guarantees and is not responsible for any damage resulting from 879 its use. The author grants irrevocable permission to anyone to use, 880 modify, and distribute it in any way that does not diminish the 881 rights of anyone else to use, modify, and distribute it, provided 882 that redistributed derivative works do not contain misleading author 883 or version information. Derivative works need not be licensed under 884 similar terms. 886 Author's Address 888 Peter Saint-Andre 889 Cisco Systems, Inc. 890 1899 Wyknoop Street, Suite 600 891 Denver, CO 80202 892 USA 894 Phone: +1-303-308-3282 895 Email: psaintan@cisco.com