idnits 2.17.1 draft-saintandre-xmpp-address-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 31, 2010) is 5140 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' -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 March 31, 2010 5 Expires: October 2, 2010 7 Extensible Messaging and Presence Protocol (XMPP): Address Format 8 draft-saintandre-xmpp-address-00 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 to IETF 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), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 2, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Internationalization Considerations . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 4.1. Stringprep Profiles . . . . . . . . . . . . . . . . . . . 7 65 4.2. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.1. Address Forging . . . . . . . . . . . . . . . . . . . 8 67 4.2.2. Address Mimicking . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 10 70 5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 10 71 6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 15 76 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15 77 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 15 78 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 15 80 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 16 81 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 16 82 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 17 84 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 85 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 18 86 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 18 88 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 18 89 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 18 90 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 18 91 Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19 92 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 The Extensible Messaging and Presence Protocol (XMPP) is an 98 application profile of the Extensible Markup Language [XML] for 99 streaming XML data in close to real time between any two or more 100 network-aware entities. The address format for such entities was 101 originally developed in the Jabber open-source community in 1999 102 (thus for historical reasons the native address of an XMPP entity is 103 called a Jabber Identifier or JID). In essence, a JID contains up to 104 three parts, in the arrangement 105 (where the localpart and resourcepart are both discretionary and each 106 part can contain nearly any Unicode code point, encoded according to 107 [UTF-8]). The JID format was first described by [XEP-0029] in 2002- 108 2003, then defined canonically by [RFC3920] in 2004. As defined in 109 RFC 3920, the XMPP address format re-uses the "stringprep" technology 110 for preparation of non-ASCII characters [STRINGPREP], including the 111 Nameprep profile for internationalized domain names as specified in 112 [NAMEPREP] and [IDNA2003] as well as two XMPP-specific profiles for 113 the localpart and resourcepart. Since the publication of RFC 3920, 114 IDNA2003 has been superseded by IDNA2008, and other protocols that 115 use stringprep (including XMPP) have begun to migrate away from that 116 technology. Because work on improved handling of internationalized 117 addresses is currently in progress, specifying the XMPP address 118 format in the revisions to RFC 3920 would unacceptably delay the 119 revision process. Therefore, this specification provides 120 documentation of the XMPP address format from RFC 3920, with the 121 intent that it can be superseded once work on a new approach to 122 internationalization is complete. 124 2. Addresses 126 2.1. Overview 128 An ENTITY is anything that is network-addressable and that can 129 communicate using XMPP. For historical reasons, the native address 130 of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID 131 contains a set of ordered elements formed of an XMPP localpart, 132 domainpart, and resourcepart. 134 The syntax for a JID is defined as follows using the Augmented 135 Backus-Naur Form as specified in [ABNF]. 137 jid = [ localpart "@" ] domain [ "/" resource ] 138 localpart = 1*(nodepoint) 139 ; a "nodepoint" is a UTF-8 encoded Unicode code 140 ; point that satisfies the Nodeprep profile of 141 ; stringprep 142 domain = fqdn / address-literal 143 fqdn = *(ldhlabel ".") toplabel 144 ldhlabel = letdig [*61(ldh) letdig] 145 toplabel = ALPHA *61(ldh) letdig 146 letdig = ALPHA / DIGIT 147 ldh = ALPHA / DIGIT / "-" 148 address-literal = IPv4address / IPv6address 149 ; the "IPv4address" and "IPv6address" rules are 150 ; defined in RFC 3986 151 resource = 1*(resourcepoint) 152 ; a "resourcepoint" is a UTF-8 encoded Unicode 153 ; code point that satisfies the Resourceprep 154 ; profile of stringprep 156 All JIDs are based on the foregoing structure. One common use of 157 this structure is to identify a messaging and presence account, the 158 server that hosts the account, and a connected resource (e.g., a 159 specific device) in the form of . 160 However, localparts other than clients are possible; for example, a 161 specific chat room offered by a multi-user conference service (see 162 [XEP-0045]) could be addressed as (where "room" is the 163 name of the chat room and "service" is the hostname of the multi-user 164 conference service) and a specific occupant of such a room could be 165 addressed as (where "nick" is the occupant's room 166 nickname). Many other JID types are possible (e.g., could be a server-side script or service). 169 Each allowable portion of a JID (localpart, domainpart, and 170 resourcepart) MUST NOT be more than 1023 bytes in length, resulting 171 in a maximum total size (including the '@' and '/' separators) of 172 3071 bytes. 174 Note: While the format of a JID is consistent with [URI], an 175 entity's address on an XMPP network MUST be represented as a JID 176 (without a URI scheme) and not a [URI] or [IRI] as specified in 177 [XMPP-URI]; the latter specification is provided only for 178 identification and interaction outside the context of the XMPP 179 wire protocol itself. 181 2.2. Domainpart 183 The DOMAINPART of a JID is that portion after the '@' character (if 184 any) and before the '/' character (if any); it is the primary 185 identifier and is the only REQUIRED element of a JID (a mere 186 domainpart is a valid JID). Typically a domainpart identifies the 187 "home" server to which clients connect for XML routing and data 188 management functionality. However, it is not necessary for an XMPP 189 domainpart to identify an entity that provides core XMPP server 190 functionality (e.g., a domainpart can identity an entity such as a 191 multi-user conference service, a publish-subscribe service, or a user 192 directory). 194 Note: A single server can service multiple domainparts, i.e., 195 multiple local domains; this is typically referred to as virtual 196 hosting. 198 The domainpart for every server or service that will communicate over 199 a network SHOULD be a fully qualified domain name (see [DNS]); while 200 the domainpart MAY be either an Internet Protocol (IPv4 or IPv6) 201 address or a text label that is resolvable on a local network 202 (commonly called an "unqualified hostname"), it is possible that 203 domainparts that are IP addresses will not be acceptable to other 204 services for the sake of interdomain communication. Furthermore, 205 domainparts that are unqualified hostnames MUST NOT be used on public 206 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 MUST be an "internationalized domain name" as defined in 219 [IDNA2003], that is, "a domain name in which every label is an 220 internationalized label". When preparing a text label (consisting of 221 a sequence of Unicode code points) for representation as an 222 internationalized label in the process of constructing an XMPP 223 domainpart or comparing two XMPP domainparts, an application MUST 224 ensure that for each text label it is possible to apply without 225 failing the ToASCII operation specified in [IDNA2003] with the 226 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other 227 than letters, digits, and hyphens). If the ToASCII operation can be 228 applied without failing, then the label is an internationalized 229 label. An internationalized domain name (and therefore an XMPP 230 domainpart) is constructed from its constituent internationalized 231 labels by following the rules specified in [IDNA2003]. 233 Note: The ToASCII operation includes application of the [NAMEPREP] 234 profile of [STRINGPREP] and encoding using the algorithm specified 235 in [PUNYCODE]; for details, see [IDNA2003]. Although the output 236 of the ToASCII operation is not used in XMPP, it MUST be possible 237 to apply that operation without failing. 239 In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a 240 "domain name slot". 242 2.3. Localpart 244 The LOCALPART of a JID is an optional identifier placed before the 245 domainpart and separated from the latter by the '@' character. 246 Typically a localpart uniquely identifies the entity requesting and 247 using network access provided by a server (i.e., a local account), 248 although it can also represent other kinds of entities (e.g., a chat 249 room associated with a multi-user conference service). The entity 250 represented by an XMPP localpart is addressed within the context of a 251 specific domain. 253 A localpart MUST NOT be zero bytes in length and, as for all portions 254 of a JID, MUST NOT be more than 1023 bytes in length. 256 A localpart MUST be formatted such that the Nodeprep profile of 257 [STRINGPREP] can be applied without failing (see Appendix A). Before 258 comparing two localparts, an application MUST first ensure that the 259 Nodeprep profile has been applied to each identifier (the profile 260 need not be applied each time a comparison is made, as long as it has 261 been applied before comparison). 263 2.4. Resourcepart 265 The resourcepart of a JID is an optional identifier placed after the 266 domainpart and separated from the latter by the '/' character. A 267 resourcepart can modify either a address or a mere 268 address. Typically a resourcepart uniquely identifies a 269 specific connection (e.g., a device or location) or object (e.g., a 270 participant in a multi-user conference room) belonging to the entity 271 associated with an XMPP localpart at a local domain. 273 When an XMPP address does not include a resourcepart (i.e., when it 274 is of the form or ), it is referred to as 275 a BARE JID. When an XMPP address includes a resourcepart (i.e., when 276 it is of the form or ), 277 is referred to as a FULL JID. 279 A resourcepart MUST NOT be zero bytes in length and, as for all 280 portions of a JID, MUST NOT be more than 1023 bytes in length. 282 A resourcepart MUST be formatted such that the Resourceprep profile 283 of [STRINGPREP] can be applied without failing (see Appendix B). 284 Before comparing two resourceparts, an application MUST first ensure 285 that the Resourceprep profile has been applied to each identifier 286 (the profile need not be applied each time a comparison is made, as 287 long as it has been applied before comparison). 289 Note: For historical reasons, the term "resource identifier" is 290 often used in XMPP to refer to the optional portion of an XMPP 291 address that follows the domainpart and the "/" separator 292 character; to help prevent confusion between an XMPP "resource 293 identifier" and the meanings of "resource" and "identifier" 294 provided in Section 1.1 of [URI], this specification typically 295 uses the term "resourcepart" instead of "resource identifier" (as 296 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, 300 the use of the '/' character as a separator between the domainpart 301 and the resourcepart does not imply that XMPP addresses are 302 hierarchical in the way that, say, HTTP addresses are hierarchical; 303 thus for example an XMPP address of the form 304 does not identify a resource "bar" that 305 exists below a resource "foo" in a hierarchy of resources associated 306 with the entity "localpart@domain". 308 3. Internationalization Considerations 310 An XMPP server MUST support and enforce [IDNA2003] for domainparts, 311 the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and 312 the Resourceprep (Appendix B) profile of [STRINGPREP] for 313 resourceparts; this enables XMPP addresses to include a wide variety 314 of Unicode characters outside the US-ASCII range. 316 4. Security Considerations 318 4.1. Stringprep Profiles 320 XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for 321 processing of domainparts; for security considerations related to 322 Nameprep, refer to the appropriate section of [NAMEPREP]. 324 In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep 325 (Appendix A) for localparts and Resourceprep (Appendix B) for 326 resourceparts. 328 The Unicode and ISO/IEC 10646 repertoires have many characters that 329 look similar. In many cases, users of security protocols might 330 perform visual matching, such as when comparing the names of trusted 331 third parties. Because it is impossible to map similar-looking 332 characters without a great deal of context (such as knowing the fonts 333 used), stringprep does nothing to map similar-looking characters 334 together, nor to prohibit some characters because they look like 335 others. 337 A localpart can be employed as one part of an entity's address in 338 XMPP. One common usage is as the username of an instant messaging 339 user; another is as the name of a multi-user conference room; and 340 many other kinds of entities could use localparts as part of their 341 addresses. The security of such services could be compromised based 342 on different interpretations of the internationalized localpart; for 343 example, a user entering a single internationalized localpart could 344 access another user's account information, or a user could gain 345 access to a hidden or otherwise restricted chat room or service. 347 A resourcepart can be employed as one part of an entity's address in 348 XMPP. One common usage is as the name for an instant messaging 349 user's connected resource; another is as the nickname of a user in a 350 multi-user conference room; and many other kinds of entities could 351 use resourceparts as part of their addresses. The security of such 352 services could be compromised based on different interpretations of 353 the internationalized resourcepart; for example, a user could attempt 354 to initiate multiple connections with the same name, or a user could 355 send a message to someone other than the intended recipient in a 356 multi-user conference room. 358 4.2. Address Spoofing 360 As discussed in [XEP-0165], there are two forms of address spoofing: 361 forging and mimicking. 363 4.2.1. Address Forging 365 In the context of XMPP technologies, address forging occurs when an 366 entity is able to generate an XML stanza whose 'from' address does 367 not correspond to the account credentials with which the entity 368 authenticated onto the network (or an authorization identity provided 369 during SASL negotiation). For example, address forging occurs if an 370 entity that authenticated as "juliet@im.example.com" is able to send 371 XML stanzas from "nurse@im.example.com" or "romeo@example.net". 373 Address forging is difficult in XMPP systems, given the requirement 374 for sending servers to stamp 'from' addresses and for receiving 375 servers to verify sending domains via server-to-server 376 authentication. However, address forging is not impossible, since a 377 rogue server could forge JIDs at the sending domain by ignoring the 378 stamping requirement. A rogue server could even forge JIDs at other 379 domains by means of a DNS poisoning attack if [DNSSEC] is not used. 380 This specification does not define methods for discovering or 381 counteracting such rogue servers. 383 Note: An entity outside the security perimeter of a particular server 384 cannot reliably distinguish between bare JIDs of the form 385 at that server, since the server could forge any 386 such JID; therefore only the domainpart can be authenticated or 387 authorized with any level of assurance. 389 4.2.2. Address Mimicking 391 Address mimicking occus when an entity provides legitimate 392 authentication credentials for and sends XML stanzas from an account 393 whose JID appears to a human user to be the same as another JID. For 394 example, in some XMPP clients the address "paypa1@example.org" 395 (spelled with the number one as the final character of the localpart) 396 might appear to be the same as "paypal@example.org (spelled with the 397 lower-case version of the letter "L"), especially on casual visual 398 inspection; this phenomenon is sometimes called "typejacking". A 399 more sophisticated example of address mimicking might involve the use 400 of characters from outside the US-ASCII range, such as the Cherokee 401 characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead 402 of the US-ASCII characters "STPETER". 404 In some examples of address mimicking, it is unlikely that the 405 average user could tell the difference between the real JID and the 406 fake JID. (Naturally, there is no way to distinguish with full 407 certainty which is the fake JID and which is the real JID; in some 408 communication contexts, the JID with Cherokee characters might be the 409 real JID and the JID with US-ASCII characters might thus appear to be 410 the fake JID.) Because JIDs can contain almost any Unicode 411 character, it can be relatively easy to mimic some JIDs in XMPP 412 systems. The possibility of address mimicking introduces security 413 vulnerabilities of the kind that have also plagued the World Wide 414 Web, specifically the phenomenon known as phishing. 416 Mimicked addresses that involve characters from only one character 417 set or from the character set typically employed by a particular user 418 are not easy to combat (e.g., the simple typejacking attack 419 previously described, which relies on a surface similarity between 420 the characters "1" and "l" in some presentations). However, mimicked 421 addresses that involve characters from more than one character set, 422 or from a character set not typically employed by a particular user, 423 can be mitigated somewhat through intelligent presentation. In 424 particular, every human user of an XMPP technology presumably has a 425 preferred language (or, in some cases, a small set of preferred 426 languages), which an XMPP application SHOULD gather either explicitly 427 from the user or implicitly via the operating system of the user's 428 device. Furthermore, every language has a range (or a small set of 429 ranges) of characters normally used to represent that language in 430 textual form. Therefore, an XMPP application SHOULD warn the user 431 when presenting a JID that uses characters outside the normal range 432 of the user's preferred language(s). This recommendation is not 433 intended to discourage communication across language communities; 434 instead, it recognizes the existence of such language communities and 435 encourages due caution when presenting unfamiliar character sets to 436 human users. 438 For more detailed recommendations regarding prevention of address 439 mimicking in XMPP systems, refer to [XEP-0165]. 441 5. IANA Considerations 443 The following sections update the registrations provided in 444 [RFC3920]. 446 5.1. Nodeprep Profile of Stringprep 448 The Nodeprep profile of stringprep is defined under Nodeprep 449 (Appendix A). The IANA has registered Nodeprep in the stringprep 450 profile registry. 452 Name of this profile: 454 Nodeprep 456 RFC in which the profile is defined: 458 XXXX 460 Indicator whether or not this is the newest version of the profile: 462 This is the first version of Nodeprep 464 5.2. Resourceprep Profile of Stringprep 466 The Resourceprep profile of stringprep is defined under Resourceprep 467 (Appendix B). The IANA has registered Resourceprep in the stringprep 468 profile registry. 470 Name of this profile: 472 Resourceprep 474 RFC in which the profile is defined: 476 XXXX 478 Indicator whether or not this is the newest version of the profile: 480 This is the first version of Resourceprep 482 6. Conformance Requirements 484 This section describes a protocol feature set that summarizes the 485 conformance requirements of this specification. This feature set is 486 appropriate for use in software certification, interoperability 487 testing, and implementation reports. For each feature, this section 488 provides the following information: 490 o A human-readable name 491 o An informational description 492 o A reference to the particular section of this document that 493 normatively defines the feature 494 o Whether the feature applies to the Client role, the Server role, 495 or both (where "N/A" signifies that the feature is not applicable 496 to the specified role) 497 o Whether the feature MUST or SHOULD be implemented, where the 498 capitalized terms are to be understood as described in [TERMS] 500 Note: The feature set specified here attempts to adhere to the 501 concepts and formats proposed by Larry Masinter within the IETF's 502 NEWTRK Working Group in 2005, as captured in [INTEROP]. Although 503 this feature set is more detailed than called for by [REPORTS], it 504 provides a suitable basis for the generation of implementation 505 reports to be submitted in support of advancing this specification 506 from Proposed Standard to Draft Standard in accordance with 507 [PROCESS]. 509 Feature: address-domain-length 510 Description: Ensure that the domainpart of an XMPP address is 511 limited to 1023 bytes in length. 512 Section: Section 2.2 513 Roles: Both MUST. 515 Feature: address-domain-prep 516 Description: Ensure that the domainpart of an XMPP address conforms 517 to the Nameprep profile of Stringprep. 518 Section: Section 2.2 519 Roles: Client SHOULD, Server MUST. 521 Feature: address-localpart-length 522 Description: Ensure that the localpart of an XMPP address is limited 523 to 1023 bytes in length. 524 Section: Section 2.3 525 Roles: Both MUST. 527 Feature: address-localpart-prep 528 Description: Ensure that the localpart of an XMPP address conforms 529 to the Nodeprep profile of Stringprep. 530 Section: Section 2.3 531 Roles: Client SHOULD, Server MUST. 533 Feature: address-resource-length 534 Description: Ensure that the resourcepart of an XMPP address is 535 limited to 1023 bytes in length. 536 Section: Section 2.4 537 Roles: Both MUST. 539 Feature: address-resource-prep 540 Description: Ensure that the resourcepart of an XMPP address 541 conforms to the Resourceprep profile of Stringprep. 542 Section: Section 2.2 543 Roles: Client SHOULD, Server MUST. 545 7. References 547 7.1. Normative References 549 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 550 Specifications: ABNF", STD 68, RFC 5234, January 2008. 552 [IDNA2003] 553 Faltstrom, P., Hoffman, P., and A. Costello, 554 "Internationalizing Domain Names in Applications (IDNA)", 555 RFC 3490, March 2003. 557 [NAMEPREP] 558 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 559 Profile for Internationalized Domain Names (IDN)", 560 RFC 3491, March 2003. 562 [STRINGPREP] 563 Hoffman, P. and M. Blanchet, "Preparation of 564 Internationalized Strings ("stringprep")", RFC 3454, 565 December 2002. 567 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, March 1997. 570 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 571 3.2.0", 2000. 573 The Unicode Standard, Version 3.2.0 is defined by The 574 Unicode Standard, Version 3.0 (Reading, MA, Addison- 575 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 576 Unicode Standard Annex #27: Unicode 3.1 577 (http://www.unicode.org/reports/tr27/) and by the Unicode 578 Standard Annex #28: Unicode 3.2 579 (http://www.unicode.org/reports/tr28/). 581 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 582 10646", STD 63, RFC 3629, November 2003. 584 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 585 Resource Identifier (URI): Generic Syntax", STD 66, 586 RFC 3986, January 2005. 588 7.2. Informative References 590 [DNS] Mockapetris, P., "Domain names - implementation and 591 specification", STD 13, RFC 1035, November 1987. 593 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 594 Rose, "DNS Security Introduction and Requirements", 595 RFC 4033, March 2005. 597 [IDNA-DEFS] 598 Klensin, J., "Internationalized Domain Names for 599 Applications (IDNA): Definitions and Document Framework", 600 draft-ietf-idnabis-defs-13 (work in progress), 601 January 2010. 603 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 604 Reporting", draft-ietf-newtrk-interop-reports-00 (work in 605 progress), October 2005. 607 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 608 Identifiers (IRIs)", RFC 3987, January 2005. 610 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 611 3", BCP 9, RFC 2026, October 1996. 613 [PUNYCODE] 614 Costello, A., "Punycode: A Bootstring encoding of Unicode 615 for Internationalized Domain Names in Applications 616 (IDNA)", RFC 3492, March 2003. 618 [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation 619 and Implementation Reports for Advancement to Draft 620 Standard", BCP 9, RFC 5657, September 2009. 622 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 623 Protocol (XMPP): Core", RFC 3920, October 2004. 625 [XEP-0029] 626 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 627 XEP 0029, October 2003. 629 [XEP-0030] 630 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 631 Andre, "Service Discovery", XSF XEP 0030, June 2008. 633 [XEP-0045] 634 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 635 January in progress, last updated 2010. 637 [XEP-0060] 638 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 639 Subscribe", XSF XEP 0060, September 2008. 641 [XEP-0165] 642 Saint-Andre, P., "Best Practices to Prevent JID 643 Mimicking", XSF XEP 0165, December 2007. 645 [XEP-0271] 646 Saint-Andre, P. and R. Meijer, "XMPP Nodes", XSF XEP 0271, 647 June 2009. 649 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 650 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 651 Edition)", World Wide Web Consortium Recommendation REC- 652 xml-20060816, August 2006, 653 . 655 [XMPP-URI] 656 Saint-Andre, P., "Internationalized Resource Identifiers 657 (IRIs) and Uniform Resource Identifiers (URIs) for the 658 Extensible Messaging and Presence Protocol (XMPP)", 659 RFC 5122, February 2008. 661 Appendix A. Nodeprep 663 A.1. Introduction 665 This appendix defines the "Nodeprep" profile of stringprep. As such, 666 it specifies processing rules that will enable users to enter 667 internationalized localparts in the Extensible Messaging and Presence 668 Protocol (XMPP) and have the highest chance of getting the content of 669 the strings correct. (An XMPP localpart is the optional portion of 670 an XMPP address that precedes an XMPP domainpart and the '@' 671 separator; it is often but not exclusively associated with an instant 672 messaging username.) These processing rules are intended only for 673 XMPP localparts and are not intended for arbitrary text or any other 674 aspect of an XMPP address. 676 This profile defines the following, as required by [STRINGPREP]: 678 o The intended applicability of the profile: internationalized 679 localparts within XMPP 680 o The character repertoire that is the input and output to 681 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 682 o The mappings used: specified in Section 3 683 o The Unicode normalization used: specified in Section 4 684 o The characters that are prohibited as output: specified in Section 685 5 686 o Bidirectional character handling: specified in Section 6 688 A.2. Character Repertoire 690 This profile uses Unicode 3.2 with the list of unassigned code points 691 being Table A.1, both defined in Appendix A of [STRINGPREP]. 693 A.3. Mapping 695 This profile specifies mapping using the following tables from 696 [STRINGPREP]: 698 Table B.1 699 Table B.2 701 A.4. Normalization 703 This profile specifies the use of Unicode normalization form KC, as 704 described in [STRINGPREP]. 706 A.5. Prohibited Output 708 This profile specifies the prohibition of using the following tables 709 from [STRINGPREP]. 711 Table C.1.1 712 Table C.1.2 713 Table C.2.1 714 Table C.2.2 715 Table C.3 716 Table C.4 717 Table C.5 718 Table C.6 719 Table C.7 720 Table C.8 721 Table C.9 723 In addition, the following additional Unicode characters are also 724 prohibited: 726 U+0022 (QUOTATION MARK), i.e., " 727 U+0026 (AMPERSAND), i.e., & 728 U+0027 (APOSTROPHE), i.e., ' 729 U+002F (SOLIDUS), i.e., / 730 U+003A (COLON), i.e., : 731 U+003C (LESS-THAN SIGN), i.e., < 732 U+003E (GREATER-THAN SIGN), i.e., > 733 U+0040 (COMMERCIAL AT), i.e., @ 735 A.6. Bidirectional Characters 737 This profile specifies checking bidirectional strings, as described 738 in Section 6 of [STRINGPREP]. 740 A.7. Notes 742 Because the additional characters prohibited by Nodeprep are 743 prohibited after normalization, an implementation MUST NOT enable a 744 human user to input any Unicode code point whose decomposition 745 includes those characters; such code points include but are not 746 necessarily limited to the following (refer to [UNICODE] for complete 747 information). 749 o U+2100 (ACCOUNT OF) 750 o U+2101 (ADDRESSED TO THE SUBJECT) 751 o U+2105 (CARE OF) 752 o U+2106 (CADA UNA) 753 o U+226E (NOT LESS-THAN) 754 o U+226F (NOT GREATER-THAN) 755 o U+2A74 (DOUBLE COLON EQUAL) 756 o U+FE13 (SMALL COLON) 757 o U+FE60 (SMALL AMPERSAND) 758 o U+FE64 (SMALL LESS-THAN SIGN) 759 o U+FE65 (SMALL GREATER-THAN SIGN) 760 o U+FE6B (SMALL COMMERCIAL AT) 761 o U+FF02 (FULLWIDTH QUOTATION MARK) 762 o U+FF06 (FULLWIDTH AMPERSAND) 763 o U+FF07 (FULLWIDTH APOSTROPHE) 764 o U+FF0F (FULLWIDTH SOLIDUS) 765 o U+FF1A (FULLWIDTH COLON) 766 o U+FF1C (FULLWIDTH LESS-THAN SIGN) 767 o U+FF1E (FULLWIDTH GREATER-THAN SIGN) 768 o U+FF20 (FULLWIDTH COMMERCIAL AT) 770 Appendix B. Resourceprep 772 B.1. Introduction 774 This appendix defines the "Resourceprep" profile of stringprep. As 775 such, it specifies processing rules that will enable users to enter 776 internationalized resourceparts in the Extensible Messaging and 777 Presence Protocol (XMPP) and have the highest chance of getting the 778 content of the strings correct. (An XMPP resourcepart is the 779 optional portion of an XMPP address that follows an XMPP domainpart 780 and the '/' separator.) These processing rules are intended only for 781 XMPP resourceparts and are not intended for arbitrary text or any 782 other aspect of an XMPP address. 784 This profile defines the following, as required by [STRINGPREP]: 786 o The intended applicability of the profile: internationalized 787 resourceparts within XMPP 788 o The character repertoire that is the input and output to 789 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 790 o The mappings used: specified in Section 3 791 o The Unicode normalization used: specified in Section 4 792 o The characters that are prohibited as output: specified in Section 793 5 794 o Bidirectional character handling: specified in Section 6 796 B.2. Character Repertoire 798 This profile uses Unicode 3.2 with the list of unassigned code points 799 being Table A.1, both defined in Appendix A of [STRINGPREP]. 801 B.3. Mapping 803 This profile specifies mapping using the following tables from 804 [STRINGPREP]: 806 Table B.1 808 B.4. Normalization 810 This profile specifies the use of Unicode normalization form KC, as 811 described in [STRINGPREP]. 813 B.5. Prohibited Output 815 This profile specifies the prohibition of using the following tables 816 from [STRINGPREP]. 818 Table C.1.2 819 Table C.2.1 820 Table C.2.2 821 Table C.3 822 Table C.4 823 Table C.5 824 Table C.6 825 Table C.7 826 Table C.8 827 Table C.9 829 B.6. Bidirectional Characters 831 This profile specifies checking bidirectional strings, as described 832 in Section 6 of [STRINGPREP]. 834 Appendix C. Differences From RFC 3920 836 Based on consensus derived from implementation and deployment 837 experience as well as formal interoperability testing, the following 838 substantive modifications were made from RFC 3920. 840 o Corrected the ABNF syntax for JIDs to prevent zero-length 841 localparts, domainparts, and resourceparts. 843 o To avoid confusion with the term "node" as used in [XEP-0030] and 844 [XEP-0060] (see also [XEP-0271]), changed the term "node 845 identifier" to "localpart" (but retained the name "Nodeprep" for 846 backward compatibility). 847 o To avoid confusion with the terms "resource" and "identifier" as 848 used in [URI], changed the term "resource identifier" to 849 "resourcepart". 850 o Corrected the nameprep processing rules to require use of the 851 UseSTD3ASCIIRules flag. 853 Appendix D. Copying Conditions 855 Regarding this entire document or any portion of it, the author makes 856 no guarantees and is not responsible for any damage resulting from 857 its use. The author grants irrevocable permission to anyone to use, 858 modify, and distribute it in any way that does not diminish the 859 rights of anyone else to use, modify, and distribute it, provided 860 that redistributed derivative works do not contain misleading author 861 or version information. Derivative works need not be licensed under 862 similar terms. 864 Index 866 B 867 Bare JID 6 869 D 870 Domainpart 4 872 E 873 Entity 3 875 F 876 Full JID 6 878 J 879 Jabber Identifier 3 881 L 882 Localpart 6 884 R 885 Resourcepart 6 887 Author's Address 889 Peter Saint-Andre 890 Cisco 892 Email: psaintan@cisco.com