idnits 2.17.1 draft-saintandre-xmpp-6122bis-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 date (August 19, 2011) is 4633 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR36' -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA2003') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP P. Saint-Andre 3 Internet-Draft Cisco 4 Obsoletes: 6122 (if approved) August 19, 2011 5 Intended status: Standards Track 6 Expires: February 20, 2012 8 Extensible Messaging and Presence Protocol (XMPP): Address Format 9 draft-saintandre-xmpp-6122bis-02 11 Abstract 13 This document defines the address format for the Extensible Messaging 14 and Presence Protocol (XMPP), including support for code points 15 outside the US-ASCII range. This document obsoletes RFC 6122. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 20, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Internationalization Considerations . . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 4.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 8 62 4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 9 63 4.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9 64 4.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 9 65 4.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 10 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 5.1. Use of NameClass . . . . . . . . . . . . . . . . . . . . . 11 68 5.2. Use of FreeClass . . . . . . . . . . . . . . . . . . . . . 11 69 6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 12 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Differences from RFC 6122 . . . . . . . . . . . . . . 16 74 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 1.1. Overview 81 The Extensible Messaging and Presence Protocol [XMPP] is an 82 application profile of the Extensible Markup Language [XML] for 83 streaming XML data in close to real time between any two or more 84 network-aware entities. The address format for XMPP entities was 85 originally developed in the Jabber open-source community in 1999, 86 first described by [XEP-0029] in 2002, and then defined canonically 87 by [RFC3920] in 2004 and [RFC6122] in 2011. 89 As specified in RFC 3920 and RFC 6122, the XMPP address format used 90 the "stringprep" technology for preparation of non-ASCII characters 91 [STRINGPREP]. This document defines the XMPP address format in a way 92 that no longer depends on stringprep. Instead, this document depends 93 on the internationalization framework defined by the IETF's PRECIS 94 Working Group [FRAMEWORK]. 96 This document obsoletes RFC 6122. 98 1.2. Terminology 100 Many important terms used in this document are defined in 101 [FRAMEWORK], [I18N-TERMS], [IDNA-DEFS], [UNICODE], and [XMPP]. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in RFC 106 2119 [KEYWORDS]. 108 2. Addresses 110 2.1. Fundamentals 112 An XMPP entity is anything that is network-addressable and that can 113 communicate using XMPP. For historical reasons, the native address 114 of an XMPP entity is called a Jabber Identifier ("JID"). A valid JID 115 is a string of [UNICODE] code points, encoded using [UTF-8], and 116 structured as an ordered sequence of localpart, domainpart, and 117 resourcepart (where the first two parts are demarcated by the '@' 118 character used as a separator, and the last two parts are similarly 119 demarcated by the '/' character). 121 The syntax for a JID is defined as follows using the Augmented 122 Backus-Naur Form as specified in [ABNF]. 124 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 125 localpart = 1*(localpoint) 126 ; 127 ; a "localpoint" is a UTF-8 encoded Unicode 128 ; code point that conforms to the localpart 129 ; subclass of the "NameClass" string class 130 ; defined in draft-blanchet-precis-framework 131 ; 132 domainpart = IP-literal / IPv4address / ifqdn 133 ; 134 ; the "IPv4address" and "IP-literal" rules are 135 ; defined in RFC 3986, and the first-match-wins 136 ; (a.k.a. "greedy") algorithm described in RFC 137 ; 3986 applies to the matching process 138 ; 139 ; note well that reuse of the IP-literal rule 140 ; from RFC 3986 implies that IPv6 addresses are 141 ; enclosed in square brackets (i.e., beginning 142 ; with '[' and ending with ']') 143 ; 144 ifqdn = 1*(domainpoint) 145 ; 146 ; a "domainpoint" is a UTF-8 encoded Unicode 147 ; code point that conforms to the "domain name" 148 ; string class effectively defined in RFC 5890 149 ; 150 resourcepart = 1*(resourcepoint) 151 ; 152 ; a "resourcepoint" is a UTF-8 encoded Unicode 153 ; code point that conforms to the localpart 154 ; subclass of the "FreeClass" string class 155 ; defined in draft-blanchet-precis-framework 156 ; 158 All JIDs are based on the foregoing structure. 160 Each allowable portion of a JID (localpart, domainpart, and 161 resourcepart) MUST NOT be zero bytes in length and MUST NOT be more 162 than 1023 bytes in length, resulting in a maximum total size 163 (including the '@' and '/' separators) of 3071 bytes. 165 For the purposes of communication over an XMPP network (e.g., in the 166 'to' or 'from' address of an XMPP stanza), an entity's address MUST 167 be represented as a JID, not as a Uniform Resource Identifier [URI] 168 or Internationalized Resource Identifier [IRI]. An XMPP URI or IRI 169 [XMPP-URI] is in essence a JID prepended with 'xmpp:'; however, the 170 native addressing format used in XMPP is that of a mere JID without a 171 URI scheme. [XMPP-URI] is provided only for identification and 172 interaction outside the context of XMPP itself, for example when 173 linking to a JID from a web page. See [XMPP-URI] for information 174 about securely extracting a JID from an XMPP URI or IRI. 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 to 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 [XEP-0045], a publish-subscribe service 194 [XEP-0060], or a user directory). 196 The domainpart for every XMPP service MUST be a fully qualified 197 domain name (FQDN; see [DNS]), IPv4 address, IPv6 address, or 198 unqualified hostname (i.e., a text label that is resolvable on a 199 local network). 201 Interoperability Note: Domainparts that are IP addresses might not 202 be accepted by other services for the sake of server-to-server 203 communication, and domainparts that are unqualified hostnames 204 cannot be used on public networks because they are resolvable only 205 on a local network. 207 If the domainpart includes a final character considered to be a label 208 separator (dot) by [DNS], this character MUST be stripped from the 209 domainpart before the JID of which it is a part is used for the 210 purpose of routing an XML stanza, comparing against another JID, or 211 constructing an [XMPP-URI]. In particular, the character MUST be 212 stripped before any other canonicalization steps are taken. 214 A domainpart MUST NOT be zero bytes in length and MUST NOT be more 215 than 1023 bytes in length. This rule is to be enforced after any 216 mapping or normalization of code points. Naturally, the length 217 limits of [DNS] apply, and nothing in this document is to be 218 interpreted as overriding those more fundamental limits. 220 In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a 221 "domain name slot". 223 A domainpart consisting of a fully qualified domain name MUST be an 224 "internationalized domain name" as defined in [IDNA-DEFS] and MUST 225 consist only of Unicode code points that conform to the rules 226 specified in [IDNA-CODE]. 228 For the purposes of communication over XMPP, the domainpart of a JID 229 MUST be treated as follows, where the operations specified MUST be 230 completed in the order shown: 232 1. Uppercase and titlecase characters MUST be mapped to their 233 lowercase equivalents. 235 2. All characters MUST be mapped using Unicode Normalization Form C 236 (NFC). [[OPEN ISSUE: Use NFD instead?]] 238 3. Each A-label SHOULD be converted to a U-label (however, if it is 239 not converted then the application MUST apply the Punycode 240 algorithm [PUNYCODE] to each A-label and prepend the ACE prefix 241 ("xn--") to the resulting DNS domain name). 243 With regard to directionality, the "Bidi Rule" provided in 244 [IDNA-BIDI] applies. 246 2.3. Localpart 248 The localpart of a JID is an optional identifier placed before the 249 domainpart and separated from the latter by the '@' character. 250 Typically a localpart uniquely identifies the entity requesting and 251 using network access provided by a server (i.e., a local account), 252 although it can also represent other kinds of entities (e.g., a chat 253 room associated with a multi-user chat service [XEP-0045]). The 254 entity represented by an XMPP localpart is addressed within the 255 context of a specific domain (i.e., ). 257 A localpart MUST NOT be zero bytes in length and MUST NOT be more 258 than 1023 bytes in length. This rule is to be enforced after any 259 mapping or normalization of code points. 261 A localpart MUST consist only of Unicode code points that conform to 262 the "NameClass" base string class defined in [FRAMEWORK], with the 263 exception of the following characters that are explicitly disallowed 264 in XMPP localparts: 266 U+0022 (QUOTATION MARK), i.e., " 267 U+0026 (AMPERSAND), i.e., & 268 U+0027 (APOSTROPHE), i.e., ' 269 U+002F (SOLIDUS), i.e., / 270 U+003A (COLON), i.e., : 271 U+003C (LESS-THAN SIGN), i.e., < 272 U+003E (GREATER-THAN SIGN), i.e., > 273 U+0040 (COMMERCIAL AT), i.e., @ 275 For the purposes of communication over XMPP, the localpart of a JID 276 MUST be treated as follows, where the operations specified MUST be 277 completed in the order shown: 279 1. Uppercase and titlecase characters MUST be mapped to their 280 lowercase equivalents. 282 2. All characters MUST be mapped using Unicode Normalization Form C 283 (NFC). [[OPEN ISSUE: Use NFD instead?]] 285 With regard to directionality, the "Bidi Rule" provided in 286 [IDNA-BIDI] applies. 288 2.4. Resourcepart 290 The resourcepart of a JID is an optional identifier placed after the 291 domainpart and separated from the latter by the '/' character. A 292 resourcepart can modify either a address or a 293 mere address. Typically a resourcepart uniquely 294 identifies a specific connection (e.g., a device or location) or 295 object (e.g., an occupant in a multi-user chat room [XEP-0045]) 296 belonging to the entity associated with an XMPP localpart at a domain 297 (i.e., ). 299 A resourcepart MUST NOT be zero bytes in length and MUST NOT be more 300 than 1023 bytes in length. This rule is to be enforced after any 301 mapping or normalization of code points. 303 A resourcepart MUST consist only of Unicode code points that conform 304 to the "FreeClass" base string class defined in [FRAMEWORK]. 306 For the purposes of communication over XMPP, the localpart of a JID 307 MUST be treated as follows, where the operations specified MUST be 308 completed in the order shown: 310 1. Uppercase and titlecase characters MAY be mapped to their 311 lowercase equivalents. 313 2. All characters MUST be mapped using Unicode Normalization Form C 314 (NFC). [[OPEN ISSUE: Use NFD instead?]] 316 With regard to directionality, the "Bidi Rule" provided in 317 [IDNA-BIDI] applies. 319 XMPP entities SHOULD consider resourceparts to be opaque strings and 320 SHOULD NOT impute meaning to any given resourcepart. In particular: 322 o Use of the '/' character as a separator between the domainpart and 323 the resourcepart does not imply that XMPP addresses are 324 hierarchical in the way that, say, HTTP addresses are 325 hierarchical; thus for example an XMPP address of the form 326 does not identify a resource "bar" 327 that exists below a resource "foo" in a hierarchy of resources 328 associated with the entity "localpart@domainpart". 330 o The '@' character is allowed in the resourcepart and is often used 331 in the "nick" shown in XMPP chatrooms [XEP-0045]. For example, 332 the JID describes an entity who 333 is an occupant of the room with an 334 (asserted) nick of . However, chatroom services do not 335 necessarily check such an asserted nick against the occupant's 336 real JID. 338 3. Internationalization Considerations 340 XMPP applications MUST support IDNA2008 for domainparts, the 341 "NameClass" string class from [FRAMEWORK] for localparts (with the 342 exception of certain ASCII characters specified under Section 2.3), 343 and the "FreeClass" string class from [FRAMEWORK] for resourceparts. 344 This enables XMPP addresses to include a wide variety of characters 345 outside the US-ASCII range. Rules for enforcement of the XMPP 346 address format are provided in [XMPP] and specifications for various 347 XMPP extensions. 349 For backward compatibility, many XMPP applications support [IDNA2003] 350 for domainparts, and the [STRINGPREP] profiles Nodeprep and 351 Resourceprep [RFC3920] for localparts and resourceparts. 353 4. Security Considerations 355 4.1. Reuse of PRECIS 357 The security considerations described in [FRAMEWORK] apply to the 358 "NameClass" and "FreeClass" base string classes used in this document 359 for XMPP localparts and resourceparts. The security considerations 360 described in [IDNA-DEFS] apply to internationalized domain names, 361 which are used here for XMPP domainparts. 363 4.2. Reuse of Unicode 365 The security considerations described in [UTR39] apply to the use of 366 Unicode characters in XMPP addresses. 368 4.3. Address Spoofing 370 There are two forms of address spoofing: forging and mimicking. 372 4.3.1. Address Forging 374 In the context of XMPP technologies, address forging occurs when an 375 entity is able to generate an XML stanza whose 'from' address does 376 not correspond to the account credentials with which the entity 377 authenticated onto the network (or an authorization identity provided 378 during negotiation of SASL authentication [SASL] as described in 379 [XMPP]). For example, address forging occurs if an entity that 380 authenticated as "juliet@im.example.com" is able to send XML stanzas 381 from "nurse@im.example.com" or "romeo@example.net". 383 Address forging is difficult in XMPP systems, given the requirement 384 for sending servers to stamp 'from' addresses and for receiving 385 servers to verify sending domains via server-to-server authentication 386 (see [XMPP]). However, address forging is possible if: 388 o A poorly implemented server ignores the requirement for stamping 389 the 'from' address. This would enable any entity that 390 authenticated with the server to send stanzas from any 391 localpart@domainpart as long as the domainpart matches the sending 392 domain of the server. 394 o An actively malicious server generates stanzas on behalf of any 395 registered account at the domain or domains hosted at that server. 397 Therefore, an entity outside the security perimeter of a particular 398 server cannot reliably distinguish between JIDs of the form 399 at that server and thus can authenticate only 400 the domainpart of such JIDs with any level of assurance. This 401 specification does not define methods for discovering or 402 counteracting the kind of poorly implemented or rogue servers just 403 described. However, the end-to-end authentication or signing of XMPP 404 stanzas could help to mitigate this risk, since it would require the 405 rogue server to generate false credentials for signing or encryption 406 of each stanza, in addition to modifying 'from' addresses. 408 Furthermore, it is possible for an attacker to forge JIDs at other 409 domains by means of a DNS poisoning attack if DNS security extensions 410 [DNSSEC] are not used. 412 4.3.2. Address Mimicking 414 Address mimicking occurs when an entity provides legitimate 415 authentication credentials for and sends XML stanzas from an account 416 whose JID appears to a human user to be the same as another JID. 417 Because many characters are visually similar, it is relatively easy 418 to mimic JIDs in XMPP systems. As one simple example, the localpart 419 "ju1iet" (using the Arabic numeral one as the third character) might 420 appear the same as the localpart "juliet" (using lowercase "L" as the 421 third character). 423 As explained in [IDNA-DEFS], [FRAMEWORK], [UTR36], and [UTR39], there 424 is no straightforward solution to the problem of visually similar 425 characters. Furthermore, IDNA and PRECIS technologies do not attempt 426 to define such a solution. As a result, XMPP domainparts, 427 localparts, and resourceparts could contain such characters, leading 428 to security vulnerabilities such as the following: 430 o A domainpart is always employed as one part of an entity's address 431 in XMPP. One common usage is as the address of a server or 432 server-side service, such as a multi-user chat service [XEP-0045]. 433 The security of such services could be compromised based on 434 different interpretations of the internationalized domainpart; for 435 example, a user might authorize a malicious entity at a fake 436 server to view the user's presence information, or a user could 437 join chatrooms at a fake multi-user chat service. 439 o A localpart can be employed as one part of an entity's address in 440 XMPP. One common usage is as the username of an instant messaging 441 user; another is as the name of a multi-user chat room; and many 442 other kinds of entities could use localparts as part of their 443 addresses. The security of such services could be compromised 444 based on different interpretations of the internationalized 445 localpart; for example, a user entering a single internationalized 446 localpart could access another user's account information, or a 447 user could gain access to a hidden or otherwise restricted chat 448 room or service. 450 o A resourcepart can be employed as one part of an entity's address 451 in XMPP. One common usage is as the name for an instant messaging 452 user's connected resource; another is as the nickname of a user in 453 a multi-user chat room; and many other kinds of entities could use 454 resourceparts as part of their addresses. The security of such 455 services could be compromised based on different interpretations 456 of the internationalized resourcepart; for example, two or more 457 confusable resources could be bound at the same time to the same 458 account (resulting in inconsistent authorization decisions in an 459 XMPP application that uses full JIDs), or a user could send a 460 message to someone other than the intended recipient in a multi- 461 user chat room. 463 XMPP services and clients are strongly encouraged to define and 464 implement consistent policies regarding the registration, storage, 465 and presentation of visually similar characters in XMPP systems. In 466 particular, service providers and software implementers are strongly 467 encouraged to use the policies recommended in [FRAMEWORK]. 469 5. IANA Considerations 471 5.1. Use of NameClass 473 The IANA shall add an entry to the PRECIS Usage Registry for reuse of 474 the PRECIS NameClass in XMPP, as follows: 476 Application Protocol: XMPP. 477 Base Class: NameClass. 478 Subclassing: Yes. See Section 2.3 of RFC XXXX. 479 Directionality: If the string contains at least one right-to-left 480 code point, the entire string is considered to be right-to-left. 481 Casemapping: Uppercase and titlecase code points are mapped to their 482 lowercase equivalents. 483 Normalization: NFC. 484 Specification: RFC XXXX. 486 5.2. Use of FreeClass 488 The IANA shall add an entry to the PRECIS Usage Registry for reuse of 489 the PRECIS FreeClass in XMPP, as follows: 491 Application Protocol: XMPP. 492 Base Class: FreeClass 493 Subclassing: No. 494 Directionality: If the string contains at least one right-to-left 495 code point, the entire string is considered to be right-to-left. 496 Casemapping: None. 497 Normalization: NFC. 498 Specification: RFC XXXX. 500 6. Conformance Requirements 502 This section describes a protocol feature set that summarizes the 503 conformance requirements of this specification. This feature set is 504 appropriate for use in software certification, interoperability 505 testing, and implementation reports. For each feature, this section 506 provides the following information: 508 o A human-readable name 509 o An informational description 510 o A reference to the particular section of this document that 511 normatively defines the feature 512 o Whether the feature applies to the Client role, the Server role, 513 or both (where "N/A" signifies that the feature is not applicable 514 to the specified role) 515 o Whether the feature MUST or SHOULD be implemented, where the 516 capitalized terms are to be understood as described in [KEYWORDS] 518 The feature set specified here attempts to adhere to the concepts and 519 formats proposed by Larry Masinter within the IETF's NEWTRK Working 520 Group in 2005, as captured in [INTEROP]. Although this feature set 521 is more detailed than called for by [REPORTS], it provides a suitable 522 basis for the generation of implementation reports to be submitted in 523 support of advancing this specification from Proposed Standard to 524 Draft Standard in accordance with [PROCESS]. 526 Feature: address-domain-length 527 Description: Ensure that the domainpart of an XMPP address is at 528 least one byte in length and at most 1023 bytes in length, and 529 conforms to the underlying length limits of the DNS. 530 Section: Section 2.2 531 Roles: Both MUST. 533 Feature: address-domain-prep 534 Description: Ensure that the domainpart of an XMPP address conforms 535 to IDNA2008, mapped to lowercase and normalized using NFC. 536 Section: Section 2.2 537 Roles: Both MUST. 539 Feature: address-localpart-length 540 Description: Ensure that the localpart of an XMPP address is at 541 least one byte in length and at most 1023 bytes in length. 542 Section: Section 2.3 543 Roles: Both MUST. 545 Feature: address-localpart-prep 546 Description: Ensure that the localpart of an XMPP address conforms 547 to the "NameClass" base string class from the PRECIS framework, 548 excluding the eight XMPP prohibited code points (U+0022, U+0026, 549 U+0027, U+002F, U+003A, U+003C, U+003E, and U+0040), with all code 550 points mapped to lowercase and normalized using NFC. 551 Section: Section 2.3 552 Roles: Both MUST. 554 Feature: address-resource-length 555 Description: Ensure that the resourcepart of an XMPP address is at 556 least one byte in length and at most 1023 bytes in length. 557 Section: Section 2.4 558 Roles: Both MUST. 560 Feature: address-resource-prep 561 Description: Ensure that the resourcepart of an XMPP address 562 conforms to the "FreeClass" base string class from the PRECIS 563 framework, with all code points normalized using NFC. 564 Section: Section 2.4 565 Roles: Both MUST. 567 7. References 569 7.1. Normative References 571 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 572 Specifications: ABNF", STD 68, RFC 5234, January 2008. 574 [DNS] Mockapetris, P., "Domain names - implementation and 575 specification", STD 13, RFC 1035, November 1987. 577 [FRAMEWORK] 578 Blanchet, M. and P. Saint-Andre, "Precis Framework: 579 Handling Internationalized Strings in Protocols", 580 draft-blanchet-precis-framework-03 (work in progress), 581 August 2011. 583 [IDNA-BIDI] 584 Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 585 Internationalized Domain Names for Applications (IDNA)", 586 RFC 5893, August 2010. 588 [IDNA-CODE] 589 Faltstrom, P., "The Unicode Code Points and 590 Internationalized Domain Names for Applications (IDNA)", 591 RFC 5892, August 2010. 593 [IDNA-DEFS] 594 Klensin, J., "Internationalized Domain Names for 595 Applications (IDNA): Definitions and Document Framework", 596 RFC 5890, August 2010. 598 [IDNA-PROTO] 599 Klensin, J., "Internationalized Domain Names in 600 Applications (IDNA): Protocol", RFC 5891, August 2010. 602 [KEYWORDS] 603 Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 607 3.2.0", 2000. 609 The Unicode Standard, Version 3.2.0 is defined by The 610 Unicode Standard, Version 3.0 (Reading, MA, Addison- 611 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 612 Unicode Standard Annex #27: Unicode 3.1 613 (http://www.unicode.org/reports/tr27/) and by the Unicode 614 Standard Annex #28: Unicode 3.2 615 (http://www.unicode.org/reports/tr28/). 617 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 618 10646", STD 63, RFC 3629, November 2003. 620 [UTR36] The Unicode Consortium, "Unicode Technical Report #36: 621 Unicode Security Considerations", 2008, 622 . 624 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 625 Protocol (XMPP): Core", RFC 6120, March 2011. 627 7.2. Informative References 629 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 630 Rose, "DNS Security Introduction and Requirements", 631 RFC 4033, March 2005. 633 [I18N-TERMS] 634 Hoffman, P. and J. Klensin, "Terminology Used in 635 Internationalization in the IETF", 636 draft-hoffman-rfc3536bis-02 (work in progress), 637 April 2011. 639 [IDNA2003] 640 Faltstrom, P., Hoffman, P., and A. Costello, 641 "Internationalizing Domain Names in Applications (IDNA)", 642 RFC 3490, March 2003. 644 See Section 1 for an explanation of why the normative 645 reference to an obsoleted specification is needed. 647 [IDNA-RATIONALE] 648 Klensin, J., "Internationalized Domain Names for 649 Applications (IDNA): Background, Explanation, and 650 Rationale", RFC 5894, August 2010. 652 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 653 Reporting", Work in Progress, October 2005. 655 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 656 Identifiers (IRIs)", RFC 3987, January 2005. 658 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 659 3", BCP 9, RFC 2026, October 1996. 661 [PUNYCODE] 662 Costello, A., "Punycode: A Bootstring encoding of Unicode 663 for Internationalized Domain Names in Applications 664 (IDNA)", RFC 3492, March 2003. 666 [REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation 667 and Implementation Reports for Advancement to Draft 668 Standard", BCP 9, RFC 5657, September 2009. 670 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 671 Protocol (XMPP): Core", RFC 3920, October 2004. 673 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 674 Protocol (XMPP): Address Format", RFC 6122, March 2011. 676 [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 677 Authentication and Security Layer (SASL)", RFC 4422, 678 June 2006. 680 [STRINGPREP] 681 Hoffman, P. and M. Blanchet, "Preparation of 682 Internationalized Strings ("stringprep")", RFC 3454, 683 December 2002. 685 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 686 Resource Identifier (URI): Generic Syntax", STD 66, 687 RFC 3986, January 2005. 689 [UTR39] The Unicode Consortium, "Unicode Technical Report #39: 690 Unicode Security Mechanisms", August 2010, 691 . 693 [XEP-0029] 694 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 695 XEP 0029, October 2003. 697 [XEP-0045] 698 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 699 July 2008. 701 [XEP-0060] 702 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 703 Subscribe", XSF XEP 0060, July 2010. 705 [XEP-0165] 706 Saint-Andre, P., "Best Practices to Discourage JID 707 Mimicking", XSF XEP 0165, December 2007. 709 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 710 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 711 Edition)", World Wide Web Consortium Recommendation REC- 712 xml-20060816, August 2006, 713 . 715 [XMPP-URI] 716 Saint-Andre, P., "Internationalized Resource Identifiers 717 (IRIs) and Uniform Resource Identifiers (URIs) for the 718 Extensible Messaging and Presence Protocol (XMPP)", 719 RFC 5122, February 2008. 721 Appendix A. Differences from RFC 6122 723 Based on consensus derived from implementation and deployment 724 experience as well as formal interoperability testing, the following 725 substantive modifications were made from RFC 3920. 727 o Changed domainpart preparation to use IDNA2008 instead of 728 IDNA2003. 729 o Changed localpart preparation to use PRECIS instead of the 730 Nodeprep profile of Stringprep. 731 o Changed resourcepart preparation to use PRECIS instead of the 732 Resourceprep profile of Stringprep. 734 Appendix B. Acknowledgements 736 Some text in this document was borrowed or adapted from [IDNA-DEFS], 737 [IDNA-PROTO], [IDNA-RATIONALE], and [XEP-0165]. 739 Author's Address 741 Peter Saint-Andre 742 Cisco 743 1899 Wyknoop Street, Suite 600 744 Denver, CO 80202 745 USA 747 Phone: +1-303-308-3282 748 Email: psaintan@cisco.com