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