idnits 2.17.1 draft-ietf-xmpp-6122bis-14.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 (October 10, 2014) is 3479 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) == Outdated reference: A later version (-23) exists of draft-ietf-precis-framework-18 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR36' == Outdated reference: A later version (-12) exists of draft-ietf-precis-mappings-08 == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-10 -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (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 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP P. Saint-Andre 3 Internet-Draft &yet 4 Obsoletes: 6122 (if approved) October 10, 2014 5 Intended status: Standards Track 6 Expires: April 13, 2015 8 Extensible Messaging and Presence Protocol (XMPP): Address Format 9 draft-ietf-xmpp-6122bis-14 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 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 April 13, 2015. 34 Copyright Notice 36 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Preparation, Comparison, and Enforcement . . . . . . . . . . 3 54 4. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 7 58 4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 7 59 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.3.1. Preparation . . . . . . . . . . . . . . . . . . . . . 8 62 4.3.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 8 63 4.3.3. Comparison . . . . . . . . . . . . . . . . . . . . . 9 64 4.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . 10 65 4.4.1. Preparation . . . . . . . . . . . . . . . . . . . . . 11 66 4.4.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 11 67 4.4.3. Comparison . . . . . . . . . . . . . . . . . . . . . 12 68 4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5. Enforcement in JIDs and JID Parts . . . . . . . . . . . . . . 15 70 6. Internationalization Considerations . . . . . . . . . . . . . 17 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 7.1. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 18 73 7.1.1. JIDlocalIdentifierClass . . . . . . . . . . . . . . . 18 74 7.1.2. JIDresourceFreeformClass . . . . . . . . . . . . . . 19 75 7.2. Stringprep Profiles Registry . . . . . . . . . . . . . . 19 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 8.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 20 78 8.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 20 79 8.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . 20 80 8.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 20 81 8.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 21 82 9. Conformance Requirements . . . . . . . . . . . . . . . . . . 22 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 10.2. Informative References . . . . . . . . . . . . . . . . . 25 86 Appendix A. Differences from RFC 6122 . . . . . . . . . . . . . 28 87 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 29 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 90 1. Introduction 92 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is an 93 application profile of the Extensible Markup Language [XML] for 94 streaming XML data in close to real time between any two or more 95 network-aware entities. The address format for XMPP entities was 96 originally developed in the Jabber open-source community in 1999, 97 first described by [XEP-0029] in 2002, and then defined canonically 98 by [RFC3920] in 2004 and [RFC6122] in 2011. 100 As specified in RFC 3920 and RFC 6122, the XMPP address format used 101 the "stringprep" technology for preparation and comparison of non- 102 ASCII characters [RFC3454]. Following the migration of 103 internationalized domain names away from stringprep, this document 104 defines the XMPP address format in a way that no longer depends on 105 stringprep (see the PRECIS problem statement [RFC6885]). Instead, 106 this document builds upon the internationalization framework defined 107 by the IETF's PRECIS Working Group [I-D.ietf-precis-framework]. 109 Although every attempt has been made to ensure that the characters 110 allowed in Jabber Identifiers (JIDs) under Stringprep are still 111 allowed and handled in the same way under PRECIS, there is no 112 guarantee of strict backward compatibility because of changes in 113 Unicode and the fact that PRECIS handling is based on Unicode 114 properties, not a hardcoded table of characters. Because it is 115 possible that previously-valid JIDs might no longer be valid (or 116 previously-invalid JIDs might now be valid), operators of XMPP 117 services are advised to perform careful testing before migrating 118 accounts and other data. 120 This document obsoletes RFC 6122. 122 2. Terminology 124 Many important terms used in this document are defined in 125 [I-D.ietf-precis-framework], [RFC5890], [RFC6120], [RFC6365], and 126 [UNICODE]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 [RFC2119]. 133 3. Preparation, Comparison, and Enforcement 135 This document distinguishes between three different actions that an 136 XMPP entity can take: 138 o Enforcement entails applying all of the rules specified for a 139 particular profile (JIDlocalIdentifierClass or 140 JIDresourceFreeformClass) to an individual string. 142 o Comparison entails applying all of the rules specified for a 143 particular profile to two separate strings, for the purpose of 144 determining if the two strings are equivalent. 146 o Preparation entails only ensuring that the characters in an 147 individual string are allowed by the underlying PRECIS base class 148 (IdentifierClass or FreeformClass). 150 In most cases, XMPP servers are responsible for enforcement and XMPP 151 clients are responsible only for preparation. See Section 5 for a 152 detailed discussion). 154 4. Addresses 156 4.1. Fundamentals 158 An XMPP entity is anything that can communicate using XMPP. For 159 historical reasons, the network address of an XMPP entity is called a 160 Jabber Identifier ("JID"). A valid JID is a string of Unicode code 161 points [UNICODE], encoded using UTF-8 [RFC3629], and structured as an 162 ordered sequence of localpart, domainpart, and resourcepart, where 163 the first two parts are demarcated by the '@' character used as a 164 separator and the last two parts are similarly demarcated by the '/' 165 character (e.g., ). 167 The syntax for a JID is defined as follows using the Augmented 168 Backus-Naur Form (ABNF) as specified in [RFC5234]. 170 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 171 localpart = 1*1023(localbyte) 172 ; 173 ; a "localbyte" is a byte used to represent a 174 ; UTF-8 encoded Unicode code point that can be 175 ; contained in a string that conforms to the 176 ; "JIDlocalIdentifierClass" profile of the 177 ; PRECIS IdentifierClass 178 ; 179 domainpart = IP-literal / IPv4address / ifqdn 180 ; 181 ; the "IPv4address" and "IP-literal" rules are 182 ; defined in RFC 3986, and the first-match-wins 183 ; (a.k.a. "greedy") algorithm described therein 184 ; applies to the matching process 185 ; 186 ; note well that reuse of the IP-literal rule from 187 ; RFC 3986 implies that IPv6 addresses are enclosed 188 ; in square brackets (i.e., beginning with '[' and 189 ; ending with ']') 190 ; 191 ifqdn = 1*1023(domainbyte) 192 ; 193 ; a "domainbyte" is a byte used to represent a 194 ; UTF-8 encoded Unicode code point that can be 195 ; contained in a string that conforms to RFC 5890 196 ; 197 resourcepart = 1*1023(resourcebyte) 198 ; 199 ; a "resourcebyte" is a byte used to represent a 200 ; UTF-8 encoded Unicode code point that can be 201 ; contained in a string that conforms to the 202 ; "JIDresourceFreeformClass" profile of the 203 ; PRECIS FreeformClass 204 ; 206 All JIDs are based on the foregoing structure. However, note that 207 the formal syntax provided above does not capture all of the rules 208 and restrictions that apply to JIDs, which are described below. 210 Each allowable portion of a JID (localpart, domainpart, and 211 resourcepart) MUST NOT be zero octets in length and MUST NOT be more 212 than 1023 octets in length, resulting in a maximum total size 213 (including the '@' and '/' separators) of 3071 octets. 215 Implementation Note: The length limits on JIDs and parts of JIDs 216 are based on octets (bytes), not characters. UTF-8 encoding can 217 result in more than one octet per character. 219 Implementation Note: When dividing a JID into its component parts, 220 an implementation needs to match the separator characters '@' and 221 '/' before applying any transformation algorithms, which might 222 decompose certain Unicode code points to the separator characters 223 (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL 224 AT decomposes to U+0040 COMMERCIAL AT, although note that this 225 decomposition does not occur under Unicode Normalization C, which 226 is used in this specification). 228 This document defines the native format for JIDs; see [RFC5122] for 229 information about the representation of a JID as a Uniform Resource 230 Identifier (URI) [RFC3986] or Internationalized Resource Identifier 231 (IRI) [RFC3987] and the extraction of a JID from an XMPP URI or IRI. 233 4.2. Domainpart 235 The domainpart of a JID is that portion after the first '@' character 236 (if any) and before the first '/' character (if any); it is the 237 primary identifier and is the only REQUIRED element of a JID (a mere 238 domainpart is a valid JID). Typically a domainpart identifies the 239 "home" server to which clients connect for XML routing and data 240 management functionality. However, it is not necessary for an XMPP 241 domainpart to identify an entity that provides core XMPP server 242 functionality (e.g., a domainpart can identify an entity such as a 243 multi-user chat service [XEP-0045], a publish-subscribe service 244 [XEP-0060], or a user directory). 246 The domainpart for every XMPP service MUST be a fully-qualified 247 domain name (FQDN), an IPv4 address, an IPv6 address, or an 248 unqualified hostname (i.e., a text label that is resolvable on a 249 local network). 251 Informational Note: The term "fully-qualified domain name" is not 252 well defined. In [RFC1034] it is also called an absolute domain 253 name, and the two terms are associated in [RFC1535]. The earliest 254 use of the term can be found in [RFC1123]. References to those 255 older specifications ought not to be construed as limiting the 256 characters of a fully-qualified domain name to the ASCII range; 257 for example, [RFC5890] mentions that a fully-qualified domain name 258 can contain one or more U-labels. 260 Interoperability Note: Domainparts that are IP addresses might not 261 be accepted by other services for the purpose of server-to-server 262 communication, and domainparts that are unqualified hostnames 263 cannot be used on public networks because they are resolvable only 264 on a local network. 266 If the domainpart includes a final character considered to be a label 267 separator (dot) by [RFC1034], this character MUST be stripped from 268 the domainpart before the JID of which it is a part is used for the 269 purpose of routing an XML stanza, comparing against another JID, or 270 constructing an XMPP URI or IRI [RFC5122]. In particular, such a 271 character MUST be stripped before any other canonicalization steps 272 are taken. 274 In general, the content of a domainpart is an Internationalized 275 Domain Name ("IDN") as described in the specifications for 276 Internationalized Domain Names in Applications (commonly called 277 "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as 278 defined in [RFC5890]. 280 After any and all normalization, conversion, and mapping of code 281 points as well as encoding of the string as UTF-8, a domainpart MUST 282 NOT be zero octets in length and MUST NOT be more than 1023 octets in 283 length. (Naturally, the length limits of [RFC1034] apply, and 284 nothing in this document is to be interpreted as overriding those 285 more fundamental limits.) 287 Detailed rules and considerations for preparation, enforcement, and 288 comparison are provided in the following sections. 290 4.2.1. Preparation 292 An XMPP entity that prepares a string for inclusion in a domainpart 293 slot MUST ensure that the string consists only of Unicode code points 294 that are allowed in NR-LDH labels or U-labels as defined in 295 [RFC5890]. This implies that the string MUST NOT include A-labels as 296 defined in [RFC5890]; each A-label MUST be converted to a U-label 297 during preparation of a string for inclusion in a domainpart slot. 298 In addition, the string MUST be encoded as UTF-8 [RFC3629]. 300 4.2.2. Enforcement 302 An XMPP entity that performs enforcement in domainpart slots MUST 303 prepare a string as described in the previous section and MUST also 304 apply the normalization, case-mapping, and width-mapping rules 305 defined in [RFC5892]. 307 The order in which the rules are applied for IDNA2008 (see 308 [RFC5892] and [RFC5895]) is different from the order for 309 localparts and resourceparts as described under Section 4.3 and 310 Section 4.4. 312 4.2.3. Comparison 314 An XMPP entity that performs comparison of two strings before or 315 after their inclusion in domainpart slots MUST prepare each string 316 and enforce the normalization, case-mapping, and width-mapping rules 317 specified in the previous two sections. The two strings are to be 318 considered equivalent if they are an exact octet-for-octet match 319 (sometimes called "bit-string identity"). 321 4.3. Localpart 323 The localpart of a JID is an optional identifier placed before the 324 domainpart and separated from the latter by the '@' character. 325 Typically a localpart uniquely identifies the entity requesting and 326 using network access provided by a server (i.e., a local account), 327 although it can also represent other kinds of entities (e.g., a chat 328 room associated with a multi-user chat service [XEP-0045]). The 329 entity represented by an XMPP localpart is addressed within the 330 context of a specific domain (i.e., ). 332 A localpart MUST NOT be zero octets in length and MUST NOT be more 333 than 1023 octets in length. This rule is to be enforced after any 334 normalization and mapping of code points as well as encoding of the 335 string as UTF-8. 337 Detailed rules and considerations for preparation, enforcement, and 338 comparison are provided in the following sections. 340 4.3.1. Preparation 342 An XMPP entity that prepares a string for inclusion in a localpart 343 slot MUST ensure that the string consists only of Unicode code points 344 that conform to the "IdentifierClass" base string class defined in 345 [I-D.ietf-precis-framework]. In addition, the string MUST be encoded 346 as UTF-8 [RFC3629]. 348 4.3.2. Enforcement 350 An XMPP entity that performs enforcement in localpart slots MUST 351 prepare a string as described in the previous section and MUST also 352 apply the width-mapping rules, case-mapping, normalization, and 353 exclusion rules for the JIDlocalIdentifierClass profile described 354 below (these rules MUST be applied in the order shown). 356 1. Fullwidth and halfwidth characters MUST be mapped to their 357 decomposition mappings. 359 2. Uppercase and titlecase characters MUST be mapped to their 360 lowercase equivalents, preferably using Unicode Default Case 361 Folding as defined in Chapter 3 of the Unicode Standard 362 [UNICODE]. 364 3. All characters MUST be normalized using Unicode Normalization 365 Form C (NFC). 367 The exclusion rule for the The JIDlocalIdentifierClass profile is as 368 follows, i.e., the characters listed below are explicitly disallowed 369 in XMPP localparts even though they are allowed by the 370 IdentifierClass base class: 372 U+0022 (QUOTATION MARK), i.e., " 374 U+0026 (AMPERSAND), i.e., & 376 U+0027 (APOSTROPHE), i.e., ' 378 U+002F (SOLIDUS), i.e., / 380 U+003A (COLON), i.e., : 382 U+003C (LESS-THAN SIGN), i.e., < 384 U+003E (GREATER-THAN SIGN), i.e., > 386 U+0040 (COMMERCIAL AT), i.e., @ 388 Implementation Note: An XMPP-specific method for escaping the 389 above-listed characters (along with U+0020, i.e., ASCII SPACE) has 390 been defined in the JID Escaping specification [XEP-0106]. 392 With regard to directionality, applications MUST apply the "Bidi 393 Rule" defined in [RFC5893] (i.e., each of the six conditions of the 394 Bidi Rule must be satisfied). 396 4.3.3. Comparison 398 An XMPP entity that performs comparison of two strings before or 399 after their inclusion in localpart slots MUST prepare each string and 400 enforce the normalization, case-mapping, and width-mapping rules 401 specified in the previous two sections. The two strings are to be 402 considered equivalent if they are an exact octet-for-octet match 403 (sometimes called "bit-string identity"). 405 4.4. Resourcepart 407 The resourcepart of a JID is an optional identifier placed after the 408 domainpart and separated from the latter by the '/' character. A 409 resourcepart can modify either a address or a 410 mere address. Typically a resourcepart uniquely 411 identifies a specific connection (e.g., a device or location) or 412 object (e.g., an occupant in a multi-user chat room [XEP-0045]) 413 belonging to the entity associated with an XMPP localpart at a domain 414 (i.e., ). 416 XMPP entities SHOULD consider resourceparts to be opaque strings and 417 SHOULD NOT impute meaning to any given resourcepart. In particular: 419 o Use of the '/' character as a separator between the domainpart and 420 the resourcepart does not imply that XMPP addresses are 421 hierarchical in the way that, say, HTTP URIs are hierarchical (see 422 [RFC3986] for general discussion); thus for example an XMPP 423 address of the form does not 424 identify a resource "bar" that exists below a resource "foo" in a 425 hierarchy of resources associated with the entity 426 "localpart@domainpart". 428 o The '@' character is allowed in the resourcepart and is often used 429 in the "handle" shown in XMPP chatrooms [XEP-0045]. For example, 430 the JID describes an entity who 431 is an occupant of the room with a handle 432 of . However, chatroom services do not necessarily 433 check such an asserted handle against the occupant's real JID. 435 A resourcepart MUST NOT be zero octets in length and MUST NOT be more 436 than 1023 octets in length. This rule is to be enforced after any 437 normalization and mapping of code points as well as encoding of the 438 string as UTF-8. 440 Detailed rules and considerations for preparation, enforcement, and 441 comparison are provided in the following sections. 443 In some contexts, it might be appropriate to apply more restrictive 444 rules to the preparation, enforcement, and comparison of XMPP 445 resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it 446 might be appropriate to apply the rules specified in 447 [I-D.ietf-precis-nickname]. However, the application of more 448 restrictive rules is out of scope for resourceparts in general and is 449 properly defined in specifications for the relevant XMPP extensions. 451 4.4.1. Preparation 453 An XMPP entity that prepares a string for inclusion in a resourcepart 454 slot MUST ensure that the string consists only of Unicode code points 455 that conform to the "FreeformClass" base string class defined in 456 [I-D.ietf-precis-framework]. In addition, the string MUST be encoded 457 as UTF-8 [RFC3629]. 459 4.4.2. Enforcement 461 An XMPP entity that performs enforcement in resourcepart slots MUST 462 prepare a string as described in the previous section and MUST also 463 apply the rules for the JIDresourceFreeformClass profile described 464 below (these rules MUST be applied in the order shown). 466 1. There is no width-mapping rule. 468 2. Any instances of non-ASCII space MUST be mapped to ASCII space 469 (U+0020); such an instance is any Unicode code point that has a 470 compatibility mapping of any kind (including but not limited to 471 as for U+0384 GREEK TONOS, as for U+2007 472 FIGURE SPACE, and as for U+3000 IDEOGRAPHIC SPACE) to 473 U+0020 SPACE. 475 3. So-called additional mappings MAY be applied, such as mapping of 476 characters that are similar to common delimiters (such as '@', 477 ':', '/', '+', '-', and '.', e.g., mapping of IDEOGRAPHIC FULL 478 STOP (U+3002) to FULL STOP (U+002E)) and special handling of 479 certain characters or classes of characters (e.g., mapping of 480 non-ASCII spaces to ASCII space); the PRECIS mappings document 481 [I-D.ietf-precis-mappings] describes such mappings in more 482 detail. 484 4. There is no case-mapping rule. 486 5. All characters MUST be normalized using Unicode Normalization 487 Form C (NFC). 489 6. There is no exclusion rule. 491 Finally, leading and trailing whitespace (i.e., one or more instances 492 of the ASCII space character at the beginning or end of a 493 resourcepart) MUST be removed (e.g., "stpeter " is mapped to 494 "stpeter"). 496 With regard to directionality, applications MUST apply the "Bidi 497 Rule" defined in [RFC5893] (i.e., each of the six conditions of the 498 Bidi Rule must be satisfied). 500 Note: XMPP extensions, or implementations thereof, MAY apply 501 supplemental procedures for the handling of resourpart slots; for 502 example, a user's nickname in XMPP groupchat [XEP-0045] might be 503 handled in accordance with [I-D.ietf-precis-nickname] (which 504 specifies a case mapping rule and uses Normalization Form KC). 506 4.4.3. Comparison 508 An XMPP entity that performs comparison of two strings before or 509 after their inclusion in resourcepart slots MUST prepare each string 510 and enforce the normalization, case-mapping, and width-mapping rules 511 specified in the previous two sections. The two strings are to be 512 considered equivalent if they are an exact octet-for-octet match 513 (sometimes called "bit-string identity"). 515 4.5. Examples 517 The following examples illustrate a small number of JIDs that are 518 consistent with the format defined above. 520 Table 1: A sample of legal JIDs 522 +---------------------------------+---------------------------------+ 523 | # | JID | Notes | 524 +---------------------------------+---------------------------------+ 525 | 1 | juliet@example.com | A "bare JID" | 526 +---------------------------------+---------------------------------+ 527 | 2 | juliet@example.com/foo | A "full JID" | 528 +---------------------------------+---------------------------------+ 529 | 3 | juliet@example.com/foo bar | Single space in resourcepart | 530 +---------------------------------+---------------------------------+ 531 | 4 | foo\20bar@example.com | Single space in localpart, as | 532 | | | optionally escaped using the | 533 | | | XMPP "JID Escaping" extension | 534 +---------------------------------+---------------------------------+ 535 | 5 | fussball@example.com | Another bare JID | 536 +---------------------------------+---------------------------------+ 537 | 6 | fußball@example.com | The third character is LATIN | 538 | | | SMALL LETTER SHARP S (U+00DF) | 539 +---------------------------------+---------------------------------+ 540 | 7 | π@example.com | A localpart of GREEK SMALL | 541 | | | LETTER PI (U+03C0) | 542 +---------------------------------+---------------------------------+ 543 | 8 | π@example.com/Σ | A resourcepart of GREEK CAPITAL | 544 | | | LETTER SIGMA (U+03A3) | 545 +---------------------------------+---------------------------------+ 546 | 9 | π@example.com/σ | A resourcepart of GREEK SMALL | 547 | | | LETTER SIGMA (U+03C3) | 548 +---------------------------------+---------------------------------+ 549 | 10| π@example.com/ς | A resourcepart of GREEK SMALL | 550 | | | LETTER FINAL SIGMA (U+03C2) | 551 +---------------------------------+---------------------------------+ 552 | 11| henryiv@example.com/♚| A resourcepart of the Unicode | 553 | | | character BLACK CHESS KING | 554 | | | (U+265A) | 555 +---------------------------------+---------------------------------+ 556 | 12| example.com | A domainpart | 557 +---------------------------------+---------------------------------+ 558 | 13| example.com/foobar | A domainpart plus resourcepart | 559 +---------------------------------+---------------------------------+ 561 Several points are worth noting. Regarding examples 5 and 6: 562 although in German the character esszett (LATIN SMALL LETTER SHARP S, 563 U+00DF) can mostly be used interchangeably with the two characters 564 "ss", the localparts in these examples are different and (if desired) 565 a server would need to enforce a registration policy that disallows 566 one of them if the other is registered. Regarding examples 8, 9, and 567 10: case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to lowercase 568 (i.e., to GREEK SMALL LETTER SIGMA, U+03C3) during comparison would 569 result in matching the JIDs in examples 8 and 9; however, because the 570 PRECIS mapping rules do not account for the special status of GREEK 571 SMALL LETTER FINAL SIGMA (U+03C2), the JIDs in examples 8 and 10 or 572 examples 9 and 10 would not be matched. Regarding example 11: symbol 573 characters such as BLACK CHESS KING (U+265A) are allowed by the 574 PRECIS FreeformClass and thus can be used in resourceparts. 575 Regarding example 13: JIDs consisting of a domainpart and 576 resourcepart are rarely seen in the wild, but are allowed according 577 to the XMPP address format. 579 The following examples illustrate strings that are not JIDs because 580 they violate the format defined above. 582 Table 2: A sample of strings that violate the JID rules 584 +---------------------------------+---------------------------------+ 585 | # | Non-JID string | Notes | 586 +---------------------------------+---------------------------------+ 587 | 13| "juliet"@example.com | Quotation marks (U+0022) in | 588 | | | localpart | 589 +---------------------------------+---------------------------------+ 590 | 14| foo bar@example.com | Space (U+0020) in localpart | 591 +---------------------------------+---------------------------------+ 592 | 15| juliet@example.com/ foo | Leading space in resourcepart | 593 +---------------------------------+---------------------------------+ 594 | 16| <@example.com/> | Zero-length localpart and | 595 | | | resourcepart ('<' and '>' are | 596 | | | used here to show the start and | 597 | | | end of the JID in question) | 598 +---------------------------------+---------------------------------+ 599 | 17| henryⅣ@example.com | The sixth character is ROMAN | 600 | | | NUMERAL FOUR (U+2163) | 601 +---------------------------------+---------------------------------+ 602 | 18| ♚@example.com | A localpart of BLACK CHESS KING | 603 | | | (U+265A) | 604 +---------------------------------+---------------------------------+ 605 | 19| juliet@ | A localpart without domainpart | 606 +---------------------------------+---------------------------------+ 607 | 20| /foobar | A resourcepart without | 608 | | domainpart | 609 +---------------------------------+---------------------------------+ 611 Here again, several points are worth noting. Regarding example 15, 612 even though ASCII SPACE (U+0020) is disallowed in the PRECIS 613 IdentifierClass, it can be escaped to "\27" in XMPP localparts by 614 using the JID Escaping rules defined in [XEP-0106], as illustrated by 615 example 4 in Table 1. Regarding example 17, the Unicode character 616 ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the 617 string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL 618 LETTER V (U+0056), but characters with compatibility equivalents are 619 not allowed in the PRECIS IdentiferClass. Regarding example 18: 620 symbol characters such as BLACK CHESS KING (U+265A) are not allowed 621 in the PRECIS IdentifierClass; however, both of the non-ASCII 622 characters in examples 17 and 18 are allowed in the PRECIS Freeform 623 class and therefore in the XMPP resourcepart (as illustrated for 624 U+265A by example 11 in Table 1). Regarding examples 19 and 20: the 625 domainpart is required in a JID. 627 5. Enforcement in JIDs and JID Parts 629 Enforcement entails applying all of the rules specified in this 630 document. Enforcement of the XMPP address format rules is the 631 responsibility of XMPP servers. Although XMPP clients SHOULD prepare 632 complete JIDs and parts of JIDs in accordance with this document 633 before including them in protocol slots within XML streams (such that 634 JIDs and parts of JIDs are in conformance), XMPP servers MUST enforce 635 the rules wherever possible and reject stanzas and other XML elements 636 that violate the rules (for stanzas, by returning a 637 error to the sender as described in Section 8.3.3.8 of [RFC6120]). 639 Entities that enforce the rules specified in this document are 640 encouraged to be liberal in what they accept by following this 641 procedure: 643 1. Where possible, map characters (e.g, through width mapping, 644 additional mapping, special mapping, case mapping, or 645 normalization) and accept the mapped string. 647 2. If mapping is not possible (e.g., because a character is 648 disallowed in the FreeformClass), reject the string and return a 649 error. 651 Enforcement applies to complete JIDs and to parts of JIDs. To 652 facilitate implementation, this document defines the concepts of "JID 653 slot", "localpart slot", and "resourcepart slot" (similar to the 654 concept of a "domain name slot" for IDNA2008 defined in 655 Section 2.3.2.6 of [RFC5890]): 657 JID Slot: An XML element or attribute explicitly designated in XMPP 658 or in XMPP extensions for carrying a complete JID. 660 Localpart Slot: An XML element or attribute explicitly designated in 661 XMPP or in XMPP extensions for carrying the localpart of a JID. 663 Resourcepart Slot: An XML element or attribute explicitly designated 664 in XMPP or in XMPP extensions for carrying the resourcepart of a 665 JID. 667 A server is responsible for enforcing the address format rules when 668 receiving protocol elements from clients where the server is expected 669 to handle such elements directly or to use them for purposes of 670 routing a stanza to another domain or delivering a stanza to a local 671 entity; two examples from [RFC6120] are the 'to' attribute on XML 672 stanzas (which is a JID slot used by XMPP servers for routing of 673 outbound stanzas) and the child of the element 674 (which is a resourcepart slot used by XMPP servers for binding of a 675 resource to an account for routing of stanzas between the server and 676 a particular client). An example from [RFC6121] is the 'jid' 677 attribute of the roster element. 679 A server is not responsible for enforcing the rules when the protocol 680 elements are intended for communication among other entities, 681 typically within the payload of a stanza that the server is merely 682 routing to another domain or delivering to a local entity. Two 683 examples are the 'initiator' attribute in the Jingle extension 684 [XEP-0166] (which is a JID slot used for client-to-client 685 coordination of multimedia sessions) and the 'nick' attribute in the 686 Multi-User Chat extension [XEP-0045] (which is a resourcepart slot 687 used for administrative purposes in the context of XMPP chatrooms). 688 In such cases, clients SHOULD enforce the rules themselves and not 689 depend on the server to do so, and client implementers need to 690 understand that not enforcing the rules can lead to a degraded user 691 experience or to security vulnerabilities. However, when an add-on 692 service (e.g., a multi-user chat service) handles a stanza directly, 693 it ought to enforce the rules as well, as defined in the relevant 694 specification for that type of service. 696 This document does not provide an exhaustive list of JID slots, 697 localpart slots, or resourcepart slots. However, implementers of 698 core XMPP servers are advised to consider as JID slots at least the 699 following elements and attributes when they are handled directly or 700 used for purposes of routing to another domain or delivering to a 701 local entity: 703 o The 'from' and 'to' stream attributes and the 'from' and 'to' 704 stanza attributes [RFC6120]. 706 o The 'jid' attribute of the roster element for contact list 707 management [RFC6121]. 709 o The 'value' attribute of the element for Privacy Lists 710 [RFC3921] [XEP-0016] when the value of the 'type' attribute is 711 "jid". 713 o The 'jid' attribute of the element for Service Discovery 714 defined in [XEP-0030]. 716 o The element for Data Forms [XEP-0004], when the 'type' 717 attribute is "jid-single" or "jid-multi". 719 o The 'jid' attribute of the element for Bookmark 720 Storage [XEP-0048]. 722 o The of the element for vCard 3.0 [XEP-0054] 723 and the child of the element for vCard 4.0 724 [XEP-0292] when the XML character data identifies an XMPP URI 725 [RFC5122]. 727 o The 'from' attribute of the element for Delayed Delivery 728 [XEP-0203]. 730 o The 'jid' attribute of the element for the Blocking 731 Command [XEP-0191]. 733 o The 'from' and 'to' attributes of the and 734 elements for Server Dialback [RFC3921], [XEP-0220]. 736 o The 'from' and 'to' attributes of the , , and 737 elements for the Jabber Component Protocol [XEP-0114]. 739 Developers of XMPP clients and specialized XMPP add-on services are 740 advised to check the appropriate specifications for JID slots, 741 localpart slots, and resourcepart slots in XMPP protocol extensions 742 such as Service Discovery [XEP-0030], Multi-User Chat [XEP-0045], 743 Publish-Subscribe [XEP-0060], SOCKS5 Bytestreams [XEP-0065], In-Band 744 Registration [XEP-0077], Roster Item Exchange [XEP-0144], and Jingle 745 [XEP-0166]. 747 6. Internationalization Considerations 749 XMPP applications MUST support IDNA2008 for domainparts as described 750 under Section 4.2, the "JIDlocalIdentifierClass" profile for 751 localparts as described under Section 4.3, and the 752 "JIDresourceFreeformClass" profile for resourceparts as described 753 under Section 4.4. This enables XMPP addresses to include a wide 754 variety of characters outside the ASCII range. Rules for enforcement 755 of the XMPP address format are provided in [RFC6120] and 756 specifications for various XMPP extensions. 758 Interoperability Note: For backward compatibility, many existing 759 XMPP implementations and deployments support IDNA2003 [RFC3490] 760 for domainparts, and the stringprep [RFC3454] profiles Nodeprep 761 and Resourceprep [RFC3920] for localparts and resourceparts. 763 7. IANA Considerations 765 7.1. PRECIS Profiles Registry 767 7.1.1. JIDlocalIdentifierClass 769 The following completed template provides the information necessary 770 for the IANA to add 'JIDlocalIdentifierClass' to the PRECIS Profiles 771 Registry. 773 Name: JIDlocalIdentifierClass. 775 Applicability: Localparts of XMPP addresses. 777 Base Class: IdentifierClass. 779 Replaces: Nodeprep. 781 Width Mapping: Map fullwidth and halfwidth characters to their 782 decomposition mappings. 784 Additional Mappings: None required or recommended. 786 Case Mapping: Map uppercase and titlecase characters to lowercase. 788 Normalization: NFC. 790 Directionality: The "Bidi Rule" defined in RFC 5893 applies. 792 Exclusions: Eight legacy characters in the ASCII range: U+0022, 793 U+0026, U+0027, U+002F, U+003A, U+003C, U+003E, U+0040. 795 Enforcement: In general, XMPP servers are responsible for enforcing 796 the rules (although XMPP clients and components can also be 797 responsible for doing so, depending on the JID slots, localpart 798 slots, and resourcepart slots where JIDs or parts of JIDs are 799 used). 801 Specification: this document. [Note to RFC Editor: please change 802 "this document" to the number issued for this specification.] 804 7.1.2. JIDresourceFreeformClass 806 The following completed template provides the information necessary 807 for the IANA to add 'JIDresourceFreeformClass' to the PRECIS Profiles 808 Registry. 810 Profile: JIDresourceFreeformClass. 812 Applicability: Resourceparts of XMPP addresses. 814 Base Class: FreeformClass 816 Replaces: The Resourceprep profile of Stringprep. 818 Width Mapping: Optional. 820 Additional Mappings: Map non-ASCII space to ASCII space. 822 Case Mapping: Optional. 824 Normalization: NFC. 826 Directionality: The "Bidi Rule" defined in RFC 5893 applies. 828 Exclusions: None. 830 Enforcement: In general, XMPP servers are responsible for enforcing 831 the rules (although XMPP clients and components can also be 832 resonsible for doing so, depending on the protocol slots where 833 JIDs or parts of JIDs are used). 835 Specification: this document. [Note to RFC Editor: please change 836 "this document" to the number issued for this specification.] 838 7.2. Stringprep Profiles Registry 840 The Stringprep specification [RFC3454] did not provide for entries in 841 the Stringprep Profiles registry to be marked as anything except 842 current or not current. Because this document obsoletes RFC 6122, 843 which registered the "Nodeprep" and "Resourceprep" profiles, IANA is 844 requested at the least to mark those profiles as not current, and if 845 possible to mark them as a deprecated (with a pointer to this 846 document). 848 8. Security Considerations 850 8.1. Reuse of PRECIS 852 The security considerations described in [I-D.ietf-precis-framework] 853 apply to the "IdentifierClass" and "FreeformClass" base string 854 classes used in this document for XMPP localparts and resourceparts, 855 respectively. The security considerations described in [RFC5890] 856 apply to internationalized domain names, which are used here for XMPP 857 domainparts. 859 8.2. Reuse of Unicode 861 The security considerations described in [UTS39] apply to the use of 862 Unicode characters in XMPP addresses. 864 8.3. Address Spoofing 866 There are two forms of address spoofing: forging and mimicking. 868 8.3.1. Address Forging 870 In the context of XMPP technologies, address forging occurs when an 871 entity is able to generate an XML stanza whose 'from' address does 872 not correspond to the account credentials with which the entity 873 authenticated onto the network (or an authorization identity provided 874 during negotiation of SASL authentication [RFC4422] as described in 875 [RFC6120]). For example, address forging occurs if an entity that 876 authenticated as "juliet@im.example.com" is able to send XML stanzas 877 from "nurse@im.example.com" or "romeo@example.net". 879 Address forging is difficult in XMPP systems, given the requirement 880 for sending servers to stamp 'from' addresses and for receiving 881 servers to verify sending domains via server-to-server authentication 882 (see [RFC6120]). However, address forging is possible if: 884 o A poorly implemented server ignores the requirement for stamping 885 the 'from' address. This would enable any entity that 886 authenticated with the server to send stanzas from any 887 localpart@domainpart as long as the domainpart matches the sending 888 domain of the server. 890 o An actively malicious server generates stanzas on behalf of any 891 registered account at the domain or domains hosted at that server. 893 Therefore, an entity outside the security perimeter of a particular 894 server cannot reliably distinguish between JIDs of the form 895 at that server and thus can authenticate only 896 the domainpart of such JIDs with any level of assurance. This 897 specification does not define methods for discovering or 898 counteracting the kind of poorly implemented or rogue servers just 899 described. However, the end-to-end authentication or signing of XMPP 900 stanzas could help to mitigate this risk, since it would require the 901 rogue server to generate false credentials for signing or encryption 902 of each stanza, in addition to modifying 'from' addresses. 904 8.3.2. Address Mimicking 906 Address mimicking occurs when an entity provides legitimate 907 authentication credentials for and sends XML stanzas from an account 908 whose JID appears to a human user to be the same as another JID. 909 Because many characters are visually similar, it is relatively easy 910 to mimic JIDs in XMPP systems. As one simple example, the localpart 911 "ju1iet" (using the Arabic numeral one as the third character) might 912 appear the same as the localpart "juliet" (using lowercase "L" as the 913 third character). 915 As explained in [RFC5890], [I-D.ietf-precis-framework], [UTR36], and 916 [UTS39], there is no straightforward solution to the problem of 917 visually similar characters. Furthermore, IDNA and PRECIS 918 technologies do not attempt to define such a solution. As a result, 919 XMPP domainparts, localparts, and resourceparts could contain such 920 characters, leading to security vulnerabilities such as the 921 following: 923 o A domainpart is always employed as one part of an entity's address 924 in XMPP. One common usage is as the address of a server or 925 server-side service, such as a multi-user chat service [XEP-0045]. 926 The security of such services could be compromised based on 927 different interpretations of the internationalized domainpart; for 928 example, a user might authorize a malicious entity at a fake 929 server to view the user's presence information, or a user could 930 join chatrooms at a fake multi-user chat service. 932 o A localpart can be employed as one part of an entity's address in 933 XMPP. One common usage is as the username of an instant messaging 934 user; another is as the name of a multi-user chat room; and many 935 other kinds of entities could use localparts as part of their 936 addresses. The security of such services could be compromised 937 based on different interpretations of the internationalized 938 localpart; for example, a user entering a single internationalized 939 localpart could access another user's account information, or a 940 user could gain access to a hidden or otherwise restricted chat 941 room or service. 943 o A resourcepart can be employed as one part of an entity's address 944 in XMPP. One common usage is as the name for an instant messaging 945 user's connected resource; another is as the nickname of a user in 946 a multi-user chat room; and many other kinds of entities could use 947 resourceparts as part of their addresses. The security of such 948 services could be compromised based on different interpretations 949 of the internationalized resourcepart; for example, two or more 950 confusable resources could be bound at the same time to the same 951 account (resulting in inconsistent authorization decisions in an 952 XMPP application that uses full JIDs), or a user could send a 953 private message to someone other than the intended recipient in a 954 multi-user chat room. 956 XMPP services and clients are strongly encouraged to define and 957 implement consistent policies regarding the registration, storage, 958 and presentation of visually similar characters in XMPP systems. In 959 particular, service providers and software implementers are strongly 960 encouraged to apply the policies recommended in 961 [I-D.ietf-precis-framework]. 963 9. Conformance Requirements 965 This section describes a protocol feature set that summarizes the 966 conformance requirements of this specification (similar feature sets 967 are provided for XMPP in [RFC6120] and [RFC6121]). This feature set 968 is appropriate for use in software certification, interoperability 969 testing, and implementation reports. For each feature, this section 970 provides the following information: 972 o A human-readable name 974 o An informational description 976 o A reference to the particular section of this document that 977 normatively defines the feature 979 o Whether the feature applies to the Client role, the Server role, 980 or both (where "N/A" signifies that the feature is not applicable 981 to the specified role) 983 o Whether the feature MUST or SHOULD be implemented, where the 984 capitalized terms are to be understood as described in [RFC2119] 986 The feature set specified here provides a basis for interoperability 987 testing and follows the spirit of a proposal made by Larry Masinter 988 within the IETF's NEWTRK Working Group in 2005 [INTEROP]. 990 Feature: address-domain-length 991 Description: Ensure that the domainpart of an XMPP address is at 992 least one octet in length and at most 1023 octets in length, and 993 that it conforms to the underlying length limits of the DNS. 995 Section: Section 4.2 997 Roles: Server MUST, client SHOULD. 999 Feature: address-domain-prep 1001 Description: Ensure that the domainpart of an XMPP address conforms 1002 to IDNA2008, that it contains only NR-LDH labels and U-labels (not 1003 A-labels), and that all uppercase and titlecase code points are 1004 mapped to their lowercase equivalents. 1006 Section: Section 4.2 1008 Roles: Server MUST, client SHOULD. 1010 Feature: address-localpart-length 1012 Description: Ensure that the localpart of an XMPP address is at 1013 least one octet in length and at most 1023 octets in length. 1015 Section: Section 4.3 1017 Roles: Server MUST, client SHOULD. 1019 Feature: address-localpart-prep 1021 Description: Ensure that the localpart of an XMPP address conforms 1022 to the "JIDlocalIdentifierClass" profile. 1024 Section: Section 4.3 1026 Roles: Server MUST, client SHOULD. 1028 Feature: address-resource-length 1030 Description: Ensure that the resourcepart of an XMPP address is at 1031 least one octet in length and at most 1023 octets in length. 1033 Section: Section 4.4 1035 Roles: Server MUST, client SHOULD. 1037 Feature: address-resource-prep 1038 Description: Ensure that the resourcepart of an XMPP address 1039 conforms to the "JIDresourceFreeformClass" profile. 1041 Section: Section 4.4 1043 Roles: Server MUST, client SHOULD. 1045 10. References 1047 10.1. Normative References 1049 [I-D.ietf-precis-framework] 1050 Saint-Andre, P. and M. Blanchet, "Precis Framework: 1051 Handling Internationalized Strings in Protocols", draft- 1052 ietf-precis-framework-18 (work in progress), September 1053 2014. 1055 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1056 STD 13, RFC 1034, November 1987. 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, March 1997. 1061 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1062 10646", STD 63, RFC 3629, November 2003. 1064 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1065 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1067 [RFC5890] Klensin, J., "Internationalized Domain Names for 1068 Applications (IDNA): Definitions and Document Framework", 1069 RFC 5890, August 2010. 1071 [RFC5891] Klensin, J., "Internationalized Domain Names in 1072 Applications (IDNA): Protocol", RFC 5891, August 2010. 1074 [RFC5892] Faltstrom, P., "The Unicode Code Points and 1075 Internationalized Domain Names for Applications (IDNA)", 1076 RFC 5892, August 2010. 1078 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 1079 Internationalized Domain Names for Applications (IDNA)", 1080 RFC 5893, August 2010. 1082 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1083 Protocol (XMPP): Core", RFC 6120, March 2011. 1085 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 1086 6.3", 2013, 1087 . 1089 [UTR36] The Unicode Consortium, "Unicode Technical Report #36: 1090 Unicode Security Considerations", November 2013, 1091 . 1093 10.2. Informative References 1095 [I-D.ietf-precis-mappings] 1096 Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS 1097 classes", draft-ietf-precis-mappings-08 (work in 1098 progress), June 2014. 1100 [I-D.ietf-precis-nickname] 1101 Saint-Andre, P., "Preparation and Comparison of 1102 Nicknames", draft-ietf-precis-nickname-10 (work in 1103 progress), January 2014. 1105 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 1106 Reporting", Work in Progress, October 2005. 1108 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1109 and Support", STD 3, RFC 1123, October 1989. 1111 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 1112 With Widely Deployed DNS Software", RFC 1535, October 1113 1993. 1115 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1116 Internationalized Strings ("stringprep")", RFC 3454, 1117 December 2002. 1119 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1120 "Internationalizing Domain Names in Applications (IDNA)", 1121 RFC 3490, March 2003. 1123 See Section 1 for an explanation of why the normative 1124 reference to an obsoleted specification is needed. 1126 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1127 Protocol (XMPP): Core", RFC 3920, October 2004. 1129 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1130 Protocol (XMPP): Instant Messaging and Presence", RFC 1131 3921, October 2004. 1133 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1134 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1135 3986, January 2005. 1137 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1138 Identifiers (IRIs)", RFC 3987, January 2005. 1140 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1141 Security Layer (SASL)", RFC 4422, June 2006. 1143 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1144 (IRIs) and Uniform Resource Identifiers (URIs) for the 1145 Extensible Messaging and Presence Protocol (XMPP)", RFC 1146 5122, February 2008. 1148 [RFC5894] Klensin, J., "Internationalized Domain Names for 1149 Applications (IDNA): Background, Explanation, and 1150 Rationale", RFC 5894, August 2010. 1152 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1153 Internationalized Domain Names in Applications (IDNA) 1154 2008", RFC 5895, September 2010. 1156 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1157 Protocol (XMPP): Instant Messaging and Presence", RFC 1158 6121, March 2011. 1160 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 1161 Protocol (XMPP): Address Format", RFC 6122, March 2011. 1163 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1164 Internationalization in the IETF", BCP 166, RFC 6365, 1165 September 2011. 1167 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 1168 Problem Statement for the Preparation and Comparison of 1169 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 1171 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 1172 Unicode Security Mechanisms", July 2012, 1173 . 1175 [XEP-0004] 1176 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 1177 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 1179 [XEP-0016] 1180 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 1181 0016, February 2007. 1183 [XEP-0029] 1184 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 1185 XEP 0029, October 2003. 1187 [XEP-0030] 1188 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1189 Andre, "Service Discovery", XSF XEP 0030, June 2008. 1191 [XEP-0045] 1192 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 1193 2012. 1195 [XEP-0048] 1196 Blackman, R., Millard, P., and P. Saint-Andre, 1197 "Bookmarks", XSF XEP 0048, November 2007. 1199 [XEP-0054] 1200 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 1202 [XEP-0060] 1203 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1204 Subscribe", XSF XEP 0060, July 2010. 1206 [XEP-0065] 1207 Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, 1208 "SOCKS5 Bytestreams", XSF XEP 0065, April 2011. 1210 [XEP-0077] 1211 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 1212 January 2012. 1214 [XEP-0106] 1215 Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 1216 0106, June 2007. 1218 [XEP-0114] 1219 Saint-Andre, P., "Jabber Component Protocol", XSF XEP 1220 0114, March 2005. 1222 [XEP-0144] 1223 Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, 1224 August 2005. 1226 [XEP-0165] 1227 Saint-Andre, P., "Best Practices to Discourage JID 1228 Mimicking", XSF XEP 0165, December 2007. 1230 [XEP-0166] 1231 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 1232 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 1233 2009. 1235 [XEP-0191] 1236 Saint-Andre, P., "Blocking Command", XSF XEP 0191, July 1237 2012. 1239 [XEP-0203] 1240 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 1241 September 2009. 1243 [XEP-0220] 1244 Miller, J., Saint-Andre, P., and P. Hancke, "Server 1245 Dialback", XSF XEP 0220, August 2012. 1247 [XEP-0292] 1248 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 1249 0292, October 2011. 1251 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 1252 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 1253 Edition)", World Wide Web Consortium Recommendation REC- 1254 xml-20081126, November 2008, 1255 . 1257 Appendix A. Differences from RFC 6122 1259 Based on consensus derived from working group discussion, 1260 implementation and deployment experience, and formal interoperability 1261 testing, the following substantive modifications were made from RFC 1262 6122. 1264 o Changed domainpart preparation to use IDNA2008 (instead of 1265 IDNA2003). 1267 o Changed localpart preparation to use the JIDlocalIdentifierClass 1268 profile of the PRECIS IdentifierClass (instead of the Nodeprep 1269 profile of Stringprep). 1271 o Changed resourcepart preparation to use the 1272 JIDresourceFreeformClass profile of the PRECIS FreeformClass 1273 (instead of the Resourceprep profile of Stringprep). 1275 o Specified that internationalized labels within domainparts must be 1276 U-labels (instead of "should be" U-labels). 1278 o Specified that fullwidth and halfwidth characters must be mapped 1279 to their decomposition mappings (previously handled through the 1280 use of NFKC). 1282 o Specified the use of Unicode Normalization Form C (instead of 1283 Unicode Normalization Form KC as specified in the Nodeprep and 1284 Resourceprep profiles of Stringprep). 1286 o Specified that servers must enforce the address formatting rules. 1288 Appendix B. Acknowledgements 1290 Thanks to Miguel Garcia, Joe Hildebrand, Jonathan Lennox, Matt 1291 Miller, and Florian Zeitz for their feedback. 1293 Some text in this document was borrowed or adapted from [RFC5890], 1294 [RFC5891], [RFC5894], and [XEP-0165]. 1296 Author's Address 1298 Peter Saint-Andre 1299 &yet 1301 Email: peter@andyet.com 1302 URI: https://andyet.com/