idnits 2.17.1 draft-ietf-xmpp-6122bis-17.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 (November 26, 2014) is 3437 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-20 == Outdated reference: A later version (-18) exists of draft-ietf-precis-saslprepbis-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR36' == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-12 -- 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 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 9 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) November 26, 2014 5 Intended status: Standards Track 6 Expires: May 30, 2015 8 Extensible Messaging and Presence Protocol (XMPP): Address Format 9 draft-ietf-xmpp-6122bis-17 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 May 30, 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. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6 58 3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3.1. Further Excluded Characters . . . . . . . . . . . . . 7 61 3.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4.1. Resourcepart Profile . . . . . . . . . . . . . . . . 9 63 3.4.1.1. Preparation . . . . . . . . . . . . . . . . . . . 9 64 3.4.1.2. Enforcement . . . . . . . . . . . . . . . . . . . 9 65 3.4.1.3. Comparison . . . . . . . . . . . . . . . . . . . 10 66 3.4.2. Applicability to XMPP . . . . . . . . . . . . . . . . 10 67 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4. Enforcement in JIDs and JID Parts . . . . . . . . . . . . . . 13 69 5. Internationalization Considerations . . . . . . . . . . . . . 15 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 6.1. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 16 72 6.1.1. Resourcepart Profile . . . . . . . . . . . . . . . . 16 73 6.2. Stringprep Profiles Registry . . . . . . . . . . . . . . 16 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 7.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 17 76 7.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 17 77 7.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . 17 78 7.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 17 79 7.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 18 80 8. Conformance Requirements . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 83 9.2. Informative References . . . . . . . . . . . . . . . . . 22 84 Appendix A. Differences from RFC 6122 . . . . . . . . . . . . . 25 85 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 26 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is an 91 application profile of the Extensible Markup Language [XML] for 92 streaming XML data in close to real time between any two or more 93 network-aware entities. The address format for XMPP entities was 94 originally developed in the Jabber open-source community in 1999, 95 first described by [XEP-0029] in 2002, and then defined canonically 96 by [RFC3920] in 2004 and [RFC6122] in 2011. 98 As specified in RFC 3920 and RFC 6122, the XMPP address format used 99 the "stringprep" technology for preparation and comparison of non- 100 ASCII characters [RFC3454]. Following the migration of 101 internationalized domain names away from stringprep, this document 102 defines the XMPP address format in a way that no longer depends on 103 stringprep (see the PRECIS problem statement [RFC6885]). Instead, 104 this document builds upon the internationalization framework defined 105 by the IETF's PRECIS Working Group [I-D.ietf-precis-framework]. 107 Although every attempt has been made to ensure that the characters 108 allowed in Jabber Identifiers (JIDs) under Stringprep are still 109 allowed and handled in the same way under PRECIS, there is no 110 guarantee of strict backward compatibility because of changes in 111 Unicode and the fact that PRECIS handling is based on Unicode 112 properties, not a hardcoded table of characters. Because it is 113 possible that previously-valid JIDs might no longer be valid (or 114 previously-invalid JIDs might now be valid), operators of XMPP 115 services are advised to perform careful testing before migrating 116 accounts and other data. 118 This document obsoletes RFC 6122. 120 2. Terminology 122 Many important terms used in this document are defined in 123 [I-D.ietf-precis-framework], [RFC5890], [RFC6120], [RFC6365], and 124 [UNICODE]. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 3. Addresses 133 3.1. Fundamentals 135 An XMPP entity is anything that can communicate using XMPP. For 136 historical reasons, the network address of an XMPP entity is called a 137 Jabber Identifier ("JID"). A valid JID is a string of Unicode code 138 points [UNICODE], encoded using UTF-8 [RFC3629], and structured as an 139 ordered sequence of localpart, domainpart, and resourcepart, where 140 the first two parts are demarcated by the '@' character used as a 141 separator and the last two parts are similarly demarcated by the '/' 142 character (e.g., ). 144 The syntax for a JID is defined as follows using the Augmented 145 Backus-Naur Form (ABNF) as specified in [RFC5234]. 147 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 148 localpart = 1*1023(userbyte) 149 ; 150 ; a "userbyte" is a byte used to represent a 151 ; UTF-8 encoded Unicode code point that can be 152 ; contained in a string that conforms to the 153 ; "UsernameCaseMapped" profile of the PRECIS 154 ; IdentifierClass 155 ; 156 domainpart = IP-literal / IPv4address / ifqdn 157 ; 158 ; the "IPv4address" and "IP-literal" rules are 159 ; defined in RFC 3986, and the first-match-wins 160 ; (a.k.a. "greedy") algorithm described therein 161 ; applies to the matching process 162 ; 163 ; note well that reuse of the IP-literal rule from 164 ; RFC 3986 implies that IPv6 addresses are enclosed 165 ; in square brackets (i.e., beginning with '[' and 166 ; ending with ']') 167 ; 168 ifqdn = 1*1023(domainbyte) 169 ; 170 ; a "domainbyte" is a byte used to represent a 171 ; UTF-8 encoded Unicode code point that can be 172 ; contained in a string that conforms to RFC 5890 173 ; 174 resourcepart = 1*1023(resourcebyte) 175 ; 176 ; a "resourcebyte" is a byte used to represent a 177 ; UTF-8 encoded Unicode code point that can be 178 ; contained in a string that conforms to the 179 ; "Resourcepart" profile of the PRECIS 180 ; FreeformClass 181 ; 183 All JIDs are based on the foregoing structure. However, note that 184 the formal syntax provided above does not capture all of the rules 185 and restrictions that apply to JIDs, which are described below. 187 Each allowable portion of a JID (localpart, domainpart, and 188 resourcepart) MUST NOT be zero octets in length and MUST NOT be more 189 than 1023 octets in length, resulting in a maximum total size 190 (including the '@' and '/' separators) of 3071 octets. 192 Implementation Note: The length limits on JIDs and parts of JIDs 193 are based on octets (bytes), not characters. UTF-8 encoding can 194 result in more than one octet per character. 196 Implementation Note: When dividing a JID into its component parts, 197 an implementation needs to match the separator characters '@' and 198 '/' before applying any transformation algorithms, which might 199 decompose certain Unicode code points to the separator characters 200 (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL 201 AT decomposes to U+0040 COMMERCIAL AT, although note that this 202 decomposition does not occur under Unicode Normalization Form C, 203 which is used in this specification). 205 This document defines the native format for JIDs; see [RFC5122] for 206 information about the representation of a JID as a Uniform Resource 207 Identifier (URI) [RFC3986] or Internationalized Resource Identifier 208 (IRI) [RFC3987] and the extraction of a JID from an XMPP URI or IRI. 210 3.2. Domainpart 212 The domainpart of a JID is that portion after the first '@' character 213 (if any) and before the first '/' character (if any); it is the 214 primary identifier and is the only REQUIRED element of a JID (a mere 215 domainpart is a valid JID). Typically a domainpart identifies the 216 "home" server to which clients connect for XML routing and data 217 management functionality. However, it is not necessary for an XMPP 218 domainpart to identify an entity that provides core XMPP server 219 functionality (e.g., a domainpart can identify an entity such as a 220 multi-user chat service [XEP-0045], a publish-subscribe service 221 [XEP-0060], or a user directory). 223 The domainpart for every XMPP service MUST be a fully-qualified 224 domain name (FQDN), an IPv4 address, an IPv6 address, or an 225 unqualified hostname (i.e., a text label that is resolvable on a 226 local network). 228 Informational Note: The term "fully-qualified domain name" is not 229 well defined. In [RFC1034] it is also called an absolute domain 230 name, and the two terms are associated in [RFC1535]. The earliest 231 use of the term can be found in [RFC1123]. References to those 232 older specifications ought not to be construed as limiting the 233 characters of a fully-qualified domain name to the ASCII range; 234 for example, [RFC5890] mentions that a fully-qualified domain name 235 can contain one or more U-labels. 237 Interoperability Note: Domainparts that are IP addresses might not 238 be accepted by other services for the purpose of server-to-server 239 communication, and domainparts that are unqualified hostnames 240 cannot be used on public networks because they are resolvable only 241 on a local network. 243 If the domainpart includes a final character considered to be a label 244 separator (dot) by [RFC1034], this character MUST be stripped from 245 the domainpart before the JID of which it is a part is used for the 246 purpose of routing an XML stanza, comparing against another JID, or 247 constructing an XMPP URI or IRI [RFC5122]. In particular, such a 248 character MUST be stripped before any other canonicalization steps 249 are taken. 251 In general, the content of a domainpart is an Internationalized 252 Domain Name ("IDN") as described in the specifications for 253 Internationalized Domain Names in Applications (commonly called 254 "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as 255 defined in [RFC5890]. 257 After any and all normalization, conversion, and mapping of code 258 points as well as encoding of the string as UTF-8, a domainpart MUST 259 NOT be zero octets in length and MUST NOT be more than 1023 octets in 260 length. (Naturally, the length limits of [RFC1034] apply, and 261 nothing in this document is to be interpreted as overriding those 262 more fundamental limits.) 264 Detailed rules and considerations for preparation, enforcement, and 265 comparison are provided in the following sections. 267 3.2.1. Preparation 269 An entity that prepares a string for inclusion in an XMPP domainpart 270 slot MUST ensure that the string consists only of Unicode code points 271 that are allowed in NR-LDH labels or U-labels as defined in 272 [RFC5890]. This implies that the string MUST NOT include A-labels as 273 defined in [RFC5890]; each A-label MUST be converted to a U-label 274 during preparation of a string for inclusion in a domainpart slot. 275 In addition, the string MUST be encoded as UTF-8 [RFC3629]. 277 3.2.2. Enforcement 279 An entity that performs enforcement in XMPP domainpart slots MUST 280 prepare a string as described in the previous section and MUST also 281 apply the normalization, case-mapping, and width-mapping rules 282 defined in [RFC5892]. 284 The order in which the rules are applied for IDNA2008 (see 285 [RFC5892] and [RFC5895]) is different from the order for 286 localparts and resourceparts as described under Section 3.3 and 287 Section 3.4. 289 3.2.3. Comparison 291 An entity that performs comparison of two strings before or after 292 their inclusion in XMPP domainpart slots MUST prepare each string and 293 enforce the normalization, case-mapping, and width-mapping rules 294 specified in the previous two sections. The two strings are to be 295 considered equivalent if they are an exact octet-for-octet match 296 (sometimes called "bit-string identity"). 298 3.3. Localpart 300 The localpart of a JID is an optional identifier placed before the 301 domainpart and separated from the latter by the '@' character. 302 Typically a localpart uniquely identifies the entity requesting and 303 using network access provided by a server (i.e., a local account), 304 although it can also represent other kinds of entities (e.g., a chat 305 room associated with a multi-user chat service [XEP-0045]). The 306 entity represented by an XMPP localpart is addressed within the 307 context of a specific domain (i.e., ). 309 The localpart of a JID MUST NOT be zero octets in length and MUST NOT 310 be more than 1023 octets in length. This rule is to be enforced 311 after any normalization and mapping of code points as well as 312 encoding of the string as UTF-8. 314 The localpart of a JID is an instance of the UsernameCaseMapped 315 profile of the PRECIS IdentifierClass, which is specified in 316 [I-D.ietf-precis-saslprepbis]. The rules and considerations provided 317 in that specification MUST be applied to XMPP localparts. 319 Implementation Note: XMPP uses the Simple Authentication and 320 Security Layer (SASL) [RFC4422] for authentication. At the time 321 of this writing, some SASL mechanisms use SASLprep [RFC4013] for 322 handling of usernames and passwords; in the future these SASL 323 mechanisms will likely transition to the use of PRECIS-based 324 handling rules as specified in [I-D.ietf-precis-saslprepbis]. 326 3.3.1. Further Excluded Characters 328 In XMPP, the following characters are explicitly disallowed in XMPP 329 localparts even though they are allowed by the IdentifierClass base 330 class and the UsernameCaseMapped profile: 332 U+0022 (QUOTATION MARK), i.e., " 334 U+0026 (AMPERSAND), i.e., & 336 U+0027 (APOSTROPHE), i.e., ' 337 U+002F (SOLIDUS), i.e., / 339 U+003A (COLON), i.e., : 341 U+003C (LESS-THAN SIGN), i.e., < 343 U+003E (GREATER-THAN SIGN), i.e., > 345 U+0040 (COMMERCIAL AT), i.e., @ 347 Implementation Note: An XMPP-specific method for escaping the 348 foregoing characters (along with U+0020, i.e., ASCII SPACE) has 349 been defined in the JID Escaping specification [XEP-0106]. 351 3.4. Resourcepart 353 The resourcepart of a JID is an optional identifier placed after the 354 domainpart and separated from the latter by the '/' character. A 355 resourcepart can modify either a address or a 356 mere address. Typically a resourcepart uniquely 357 identifies a specific connection (e.g., a device or location) or 358 object (e.g., an occupant in a multi-user chat room [XEP-0045]) 359 belonging to the entity associated with an XMPP localpart at a domain 360 (i.e., ). 362 XMPP entities SHOULD consider resourceparts to be opaque strings and 363 SHOULD NOT impute meaning to any given resourcepart. In particular: 365 o Use of the '/' character as a separator between the domainpart and 366 the resourcepart does not imply that XMPP addresses are 367 hierarchical in the way that, say, HTTP URIs are hierarchical (see 368 [RFC3986] for general discussion); thus for example an XMPP 369 address of the form does not 370 identify a resource "bar" that exists below a resource "foo" in a 371 hierarchy of resources associated with the entity 372 "localpart@domainpart". 374 o The '@' character is allowed in the resourcepart and is often used 375 in the "handle" shown in XMPP chatrooms [XEP-0045]. For example, 376 the JID describes an entity who 377 is an occupant of the room with a handle 378 of . However, chatroom services do not necessarily 379 check such an asserted handle against the occupant's real JID. 381 The resourcepart of a JID MUST NOT be zero octets in length and MUST 382 NOT be more than 1023 octets in length. This rule is to be enforced 383 after any normalization and mapping of code points as well as 384 encoding of the string as UTF-8. 386 3.4.1. Resourcepart Profile 388 The definition of the Resourcepart profile is provided in the 389 following sections, including detailed information about preparation, 390 enforcement, and comparison (on the distinction between these 391 actions, refer to [I-D.ietf-precis-framework]). This profile is 392 deliberately not defined in terms of XMPP so that it can be reused by 393 other application protocols. 395 3.4.1.1. Preparation 397 An entity that prepares a string according to this profile MUST 398 ensure that the string consists only of Unicode code points that 399 conform to the "FreeformClass" base string class defined in 400 [I-D.ietf-precis-framework]. In addition, the string MUST be encoded 401 as UTF-8 [RFC3629]. 403 3.4.1.2. Enforcement 405 An entity that performs enforcement according to this profile MUST 406 prepare a string as described in the previous section and MUST also 407 apply the rules for the Resourcepart profile described below (these 408 rules MUST be applied in the order shown). 410 1. Width Mapping Rule: There is no width mapping rule. 412 2. Additional Mapping Rule: The additional mapping rule consists of 413 the following sub-rules. 415 1. Any instances of non-ASCII space MUST be mapped to ASCII 416 space (U+0020); a non-ASCII space is any Unicode code point 417 having a general category of "Zs", naturally with the 418 exception of U+0020. 420 2. Leading and trailing whitespace (i.e., one or more instances 421 of the ASCII space character at the beginning or end of a 422 resourcepart) MUST be removed (e.g., "stpeter " is mapped to 423 "stpeter"). 425 3. Case Mapping Rule: There is no case mapping rule. 427 4. Normalization Rule: All characters MUST be normalized using 428 Unicode Normalization Form C (NFC). 430 5. Directionality Rule: Applications MUST apply the "Bidi Rule" 431 defined in [RFC5893] (i.e., each of the six conditions of the 432 Bidi Rule must be satisfied). 434 3.4.1.3. Comparison 436 An entity that performs comparison of two strings according to this 437 profile MUST prepare each string and enforce the rules specified in 438 the previous two sections. The two strings are to be considered 439 equivalent if they are an exact octet-for-octet match (sometimes 440 called "bit-string identity"). 442 3.4.2. Applicability to XMPP 444 In some contexts, it might be appropriate to apply more restrictive 445 rules to the preparation, enforcement, and comparison of XMPP 446 resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it 447 might be appropriate to apply the rules specified in 448 [I-D.ietf-precis-nickname]. However, the application of more 449 restrictive rules is out of scope for resourceparts in general and is 450 properly defined in specifications for the relevant XMPP extensions. 452 3.5. Examples 454 The following examples illustrate a small number of JIDs that are 455 consistent with the format defined above. 457 Table 1: A sample of legal JIDs 459 +---------------------------------+---------------------------------+ 460 | # | JID | Notes | 461 +---------------------------------+---------------------------------+ 462 | 1 | juliet@example.com | A "bare JID" | 463 +---------------------------------+---------------------------------+ 464 | 2 | juliet@example.com/foo | A "full JID" | 465 +---------------------------------+---------------------------------+ 466 | 3 | juliet@example.com/foo bar | Single space in resourcepart | 467 +---------------------------------+---------------------------------+ 468 | 4 | foo\20bar@example.com | Single space in localpart, as | 469 | | | optionally escaped using the | 470 | | | XMPP "JID Escaping" extension | 471 +---------------------------------+---------------------------------+ 472 | 5 | fussball@example.com | Another bare JID | 473 +---------------------------------+---------------------------------+ 474 | 6 | fußball@example.com | The third character is LATIN | 475 | | | SMALL LETTER SHARP S (U+00DF) | 476 +---------------------------------+---------------------------------+ 477 | 7 | π@example.com | A localpart of GREEK SMALL | 478 | | | LETTER PI (U+03C0) | 479 +---------------------------------+---------------------------------+ 480 | 8 | π@example.com/Σ | A resourcepart of GREEK CAPITAL | 481 | | | LETTER SIGMA (U+03A3) | 482 +---------------------------------+---------------------------------+ 483 | 9 | π@example.com/σ | A resourcepart of GREEK SMALL | 484 | | | LETTER SIGMA (U+03C3) | 485 +---------------------------------+---------------------------------+ 486 | 10| π@example.com/ς | A resourcepart of GREEK SMALL | 487 | | | LETTER FINAL SIGMA (U+03C2) | 488 +---------------------------------+---------------------------------+ 489 | 11| henryiv@example.com/♚| A resourcepart of the Unicode | 490 | | | character BLACK CHESS KING | 491 | | | (U+265A) | 492 +---------------------------------+---------------------------------+ 493 | 12| example.com | A domainpart | 494 +---------------------------------+---------------------------------+ 495 | 13| example.com/foobar | A domainpart plus resourcepart | 496 +---------------------------------+---------------------------------+ 498 Several points are worth noting. Regarding examples 5 and 6: 499 although in German the character esszett (LATIN SMALL LETTER SHARP S, 500 U+00DF) can mostly be used interchangeably with the two characters 501 "ss", the localparts in these examples are different and (if desired) 502 a server would need to enforce a registration policy that disallows 503 one of them if the other is registered. Regarding examples 8, 9, and 504 10: case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to lowercase 505 (i.e., to GREEK SMALL LETTER SIGMA, U+03C3) during comparison would 506 result in matching the JIDs in examples 8 and 9; however, because the 507 PRECIS mapping rules do not account for the special status of GREEK 508 SMALL LETTER FINAL SIGMA (U+03C2), the JIDs in examples 8 and 10 or 509 examples 9 and 10 would not be matched. Regarding example 11: symbol 510 characters such as BLACK CHESS KING (U+265A) are allowed by the 511 PRECIS FreeformClass and thus can be used in resourceparts. 512 Regarding example 13: JIDs consisting of a domainpart and 513 resourcepart are rarely seen in the wild, but are allowed according 514 to the XMPP address format. 516 The following examples illustrate strings that are not JIDs because 517 they violate the format defined above. 519 Table 2: A sample of strings that violate the JID rules 521 +---------------------------------+---------------------------------+ 522 | # | Non-JID string | Notes | 523 +---------------------------------+---------------------------------+ 524 | 13| "juliet"@example.com | Quotation marks (U+0022) in | 525 | | | localpart | 526 +---------------------------------+---------------------------------+ 527 | 14| foo bar@example.com | Space (U+0020) in localpart | 528 +---------------------------------+---------------------------------+ 529 | 15| juliet@example.com/ foo | Leading space in resourcepart | 530 +---------------------------------+---------------------------------+ 531 | 16| <@example.com/> | Zero-length localpart and | 532 | | | resourcepart ('<' and '>') are | 533 | | | used here to show the start and | 534 | | | end of the JID in question | 535 +---------------------------------+---------------------------------+ 536 | 17| henryⅣ@example.com | The sixth character is ROMAN | 537 | | | NUMERAL FOUR (U+2163) | 538 +---------------------------------+---------------------------------+ 539 | 18| ♚@example.com | A localpart of BLACK CHESS KING | 540 | | | (U+265A) | 541 +---------------------------------+---------------------------------+ 542 | 19| juliet@ | A localpart without domainpart | 543 +---------------------------------+---------------------------------+ 544 | 20| /foobar | A resourcepart without | 545 | | domainpart | 546 +---------------------------------+---------------------------------+ 548 Here again, several points are worth noting. Regarding example 15, 549 even though ASCII SPACE (U+0020) is disallowed in the PRECIS 550 IdentifierClass, it can be escaped to "\20" in XMPP localparts by 551 using the JID Escaping rules defined in [XEP-0106], as illustrated by 552 example 4 in Table 1. Regarding example 17, the Unicode character 553 ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the 554 string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL 555 LETTER V (U+0056), but characters with compatibility equivalents are 556 not allowed in the PRECIS IdentiferClass. Regarding example 18: 557 symbol characters such as BLACK CHESS KING (U+265A) are not allowed 558 in the PRECIS IdentifierClass; however, both of the non-ASCII 559 characters in examples 17 and 18 are allowed in the PRECIS Freeform 560 class and therefore in the XMPP resourcepart (as illustrated for 561 U+265A by example 11 in Table 1). Regarding examples 19 and 20: the 562 domainpart is required in a JID. 564 4. Enforcement in JIDs and JID Parts 566 Enforcement entails applying all of the rules specified in this 567 document. Enforcement of the XMPP address format rules is the 568 responsibility of XMPP servers. Although XMPP clients SHOULD prepare 569 complete JIDs and parts of JIDs in accordance with this document 570 before including them in protocol slots within XML streams, XMPP 571 servers MUST enforce the rules wherever possible and reject stanzas 572 and other XML elements that violate the rules (for stanzas, by 573 returning a error to the sender as described in 574 Section 8.3.3.8 of [RFC6120]). 576 Entities that enforce the rules specified in this document are 577 encouraged to be liberal in what they accept by following this 578 procedure: 580 1. Where possible, map characters (e.g, through width mapping, 581 additional mapping, special mapping, case mapping, or 582 normalization) and accept the mapped string. 584 2. If mapping is not possible (e.g., because a character is 585 disallowed in the FreeformClass), reject the string and return a 586 error. 588 Enforcement applies to complete JIDs and to parts of JIDs. To 589 facilitate implementation, this document defines the concepts of "JID 590 slot", "localpart slot", and "resourcepart slot" (similar to the 591 concept of a "domain name slot" for IDNA2008 defined in 592 Section 2.3.2.6 of [RFC5890]): 594 JID Slot: An XML element or attribute explicitly designated in XMPP 595 or in XMPP extensions for carrying a complete JID. 597 Localpart Slot: An XML element or attribute explicitly designated in 598 XMPP or in XMPP extensions for carrying the localpart of a JID. 600 Resourcepart Slot: An XML element or attribute explicitly designated 601 in XMPP or in XMPP extensions for carrying the resourcepart of a 602 JID. 604 A server is responsible for enforcing the address format rules when 605 receiving protocol elements from clients where the server is expected 606 to handle such elements directly or to use them for purposes of 607 routing a stanza to another domain or delivering a stanza to a local 608 entity; two examples from [RFC6120] are the 'to' attribute on XML 609 stanzas (which is a JID slot used by XMPP servers for routing of 610 outbound stanzas) and the child of the element 611 (which is a resourcepart slot used by XMPP servers for binding of a 612 resource to an account for routing of stanzas between the server and 613 a particular client). An example from [RFC6121] is the 'jid' 614 attribute of the roster element. 616 A server is not responsible for enforcing the rules when the protocol 617 elements are intended for communication among other entities, 618 typically within the payload of a stanza that the server is merely 619 routing to another domain or delivering to a local entity. Two 620 examples are the 'initiator' attribute in the Jingle extension 621 [XEP-0166] (which is a JID slot used for client-to-client 622 coordination of multimedia sessions) and the 'nick' attribute in the 623 Multi-User Chat extension [XEP-0045] (which is a resourcepart slot 624 used for administrative purposes in the context of XMPP chatrooms). 625 In such cases, clients SHOULD enforce the rules themselves and not 626 depend on the server to do so, and client implementers need to 627 understand that not enforcing the rules can lead to a degraded user 628 experience or to security vulnerabilities. However, when an add-on 629 service (e.g., a multi-user chat service) handles a stanza directly, 630 it ought to enforce the rules as well, as defined in the relevant 631 specification for that type of service. 633 This document does not provide an exhaustive list of JID slots, 634 localpart slots, or resourcepart slots. However, implementers of 635 core XMPP servers are advised to consider as JID slots at least the 636 following elements and attributes when they are handled directly or 637 used for purposes of routing to another domain or delivering to a 638 local entity: 640 o The 'from' and 'to' stream attributes and the 'from' and 'to' 641 stanza attributes [RFC6120]. 643 o The 'jid' attribute of the roster element for contact list 644 management [RFC6121]. 646 o The 'value' attribute of the element for Privacy Lists 647 [RFC3921] [XEP-0016] when the value of the 'type' attribute is 648 "jid". 650 o The 'jid' attribute of the element for Service Discovery 651 defined in [XEP-0030]. 653 o The element for Data Forms [XEP-0004], when the 'type' 654 attribute is "jid-single" or "jid-multi". 656 o The 'jid' attribute of the element for Bookmark 657 Storage [XEP-0048]. 659 o The of the element for vCard 3.0 [XEP-0054] 660 and the child of the element for vCard 4.0 661 [XEP-0292] when the XML character data identifies an XMPP URI 662 [RFC5122]. 664 o The 'from' attribute of the element for Delayed Delivery 665 [XEP-0203]. 667 o The 'jid' attribute of the element for the Blocking 668 Command [XEP-0191]. 670 o The 'from' and 'to' attributes of the and 671 elements for Server Dialback [RFC3921], [XEP-0220]. 673 o The 'from' and 'to' attributes of the , , and 674 elements for the Jabber Component Protocol [XEP-0114]. 676 Developers of XMPP clients and specialized XMPP add-on services are 677 advised to check the appropriate specifications for JID slots, 678 localpart slots, and resourcepart slots in XMPP protocol extensions 679 such as Service Discovery [XEP-0030], Multi-User Chat [XEP-0045], 680 Publish-Subscribe [XEP-0060], SOCKS5 Bytestreams [XEP-0065], In-Band 681 Registration [XEP-0077], Roster Item Exchange [XEP-0144], and Jingle 682 [XEP-0166]. 684 5. Internationalization Considerations 686 XMPP applications MUST support IDNA2008 for domainparts as described 687 under Section 3.2, the "UsernameCaseMapped" profile for localparts as 688 described under Section 3.3, and the "Resourcepart" profile for 689 resourceparts as described under Section 3.4. This enables XMPP 690 addresses to include a wide variety of characters outside the ASCII 691 range. Rules for enforcement of the XMPP address format are provided 692 in [RFC6120] and specifications for various XMPP extensions. 694 Interoperability Note: For backward compatibility, many existing 695 XMPP implementations and deployments support IDNA2003 [RFC3490] 696 for domainparts, and the stringprep [RFC3454] profiles Nodeprep 697 and Resourceprep [RFC3920] for localparts and resourceparts. 699 6. IANA Considerations 701 6.1. PRECIS Profiles Registry 703 6.1.1. Resourcepart Profile 705 The following completed template provides the information necessary 706 for the IANA to add 'Resourcepart' to the PRECIS Profiles Registry. 708 Profile: Resourcepart. 710 Base Class: FreeformClass. 712 Applicability: Resourceparts of addresses. 714 Replaces: The Resourceprep profile of Stringprep. 716 Width Mapping Rule: Optional. 718 Additional Mapping Rule: Map non-ASCII space to ASCII space; remove 719 leading and trailing spaces. 721 Case Mapping Rule: Optional. 723 Normalization Rule: NFC. 725 Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies. 727 Enforcement: Within XMPP, servers are responsible for enforcing the 728 rules (although clients and components can also be responsible for 729 doing so, depending on the protocol slots where JIDs or JID parts 730 are used). 732 Specification: this document. [Note to RFC Editor: please change 733 "this document" to the number issued for this specification.] 735 6.2. Stringprep Profiles Registry 737 The Stringprep specification [RFC3454] did not provide for entries in 738 the Stringprep Profiles registry to be marked as anything except 739 current or not current. Because this document obsoletes RFC 6122, 740 which registered the "Nodeprep" and "Resourceprep" profiles, IANA is 741 requested at the least to mark those profiles as not current 742 (preferably with a pointer to this document). 744 7. Security Considerations 746 7.1. Reuse of PRECIS 748 The security considerations described in [I-D.ietf-precis-framework] 749 apply to the "IdentifierClass" and "FreeformClass" base string 750 classes used in this document for XMPP localparts and resourceparts, 751 respectively. The security considerations described in [RFC5890] 752 apply to internationalized domain names, which are used here for XMPP 753 domainparts. 755 7.2. Reuse of Unicode 757 The security considerations described in [UTS39] apply to the use of 758 Unicode characters in XMPP addresses. 760 7.3. Address Spoofing 762 There are two forms of address spoofing: forging and mimicking. 764 7.3.1. Address Forging 766 In the context of XMPP technologies, address forging occurs when an 767 entity is able to generate an XML stanza whose 'from' address does 768 not correspond to the account credentials with which the entity 769 authenticated onto the network (or an authorization identity provided 770 during negotiation of SASL authentication [RFC4422] as described in 771 [RFC6120]). For example, address forging occurs if an entity that 772 authenticated as "juliet@im.example.com" is able to send XML stanzas 773 from "nurse@im.example.com" or "romeo@example.net". 775 Address forging is difficult in XMPP systems, given the requirement 776 for sending servers to stamp 'from' addresses and for receiving 777 servers to verify sending domains via server-to-server authentication 778 (see [RFC6120]). However, address forging is possible if: 780 o A poorly implemented server ignores the requirement for stamping 781 the 'from' address. This would enable any entity that 782 authenticated with the server to send stanzas from any 783 localpart@domainpart as long as the domainpart matches the sending 784 domain of the server. 786 o An actively malicious server generates stanzas on behalf of any 787 registered account at the domain or domains hosted at that server. 789 Therefore, an entity outside the security perimeter of a particular 790 server cannot reliably distinguish between JIDs of the form 791 at that server and thus can authenticate only 792 the domainpart of such JIDs with any level of assurance. This 793 specification does not define methods for discovering or 794 counteracting the kind of poorly implemented or rogue servers just 795 described. However, the end-to-end authentication or signing of XMPP 796 stanzas could help to mitigate this risk, since it would require the 797 rogue server to generate false credentials for signing or encryption 798 of each stanza, in addition to modifying 'from' addresses. 800 7.3.2. Address Mimicking 802 Address mimicking occurs when an entity provides legitimate 803 authentication credentials for and sends XML stanzas from an account 804 whose JID appears to a human user to be the same as another JID. 805 Because many characters are visually similar, it is relatively easy 806 to mimic JIDs in XMPP systems. As one simple example, the localpart 807 "ju1iet" (using the Arabic numeral one as the third character) might 808 appear the same as the localpart "juliet" (using lowercase "L" as the 809 third character). 811 As explained in [RFC5890], [I-D.ietf-precis-framework], [UTR36], and 812 [UTS39], there is no straightforward solution to the problem of 813 visually similar characters. Furthermore, IDNA and PRECIS 814 technologies do not attempt to define such a solution. As a result, 815 XMPP domainparts, localparts, and resourceparts could contain such 816 characters, leading to security vulnerabilities such as the 817 following: 819 o A domainpart is always employed as one part of an entity's address 820 in XMPP. One common usage is as the address of a server or 821 server-side service, such as a multi-user chat service [XEP-0045]. 822 The security of such services could be compromised based on 823 different interpretations of the internationalized domainpart; for 824 example, a user might authorize a malicious entity at a fake 825 server to view the user's presence information, or a user could 826 join chatrooms at a fake multi-user chat service. 828 o A localpart can be employed as one part of an entity's address in 829 XMPP. One common usage is as the username of an instant messaging 830 user; another is as the name of a multi-user chat room; and many 831 other kinds of entities could use localparts as part of their 832 addresses. The security of such services could be compromised 833 based on different interpretations of the internationalized 834 localpart; for example, a user entering a single internationalized 835 localpart could access another user's account information, or a 836 user could gain access to a hidden or otherwise restricted chat 837 room or service. 839 o A resourcepart can be employed as one part of an entity's address 840 in XMPP. One common usage is as the name for an instant messaging 841 user's connected resource; another is as the nickname of a user in 842 a multi-user chat room; and many other kinds of entities could use 843 resourceparts as part of their addresses. The security of such 844 services could be compromised based on different interpretations 845 of the internationalized resourcepart; for example, two or more 846 confusable resources could be bound at the same time to the same 847 account (resulting in inconsistent authorization decisions in an 848 XMPP application that uses full JIDs), or a user could send a 849 private message to someone other than the intended recipient in a 850 multi-user chat room. 852 XMPP services and clients are strongly encouraged to define and 853 implement consistent policies regarding the registration, storage, 854 and presentation of visually similar characters in XMPP systems. In 855 particular, service providers and software implementers are strongly 856 encouraged to apply the policies recommended in 857 [I-D.ietf-precis-framework]. 859 8. Conformance Requirements 861 This section describes a protocol feature set that summarizes the 862 conformance requirements of this specification (similar feature sets 863 are provided for XMPP in [RFC6120] and [RFC6121]). This feature set 864 is appropriate for use in software certification, interoperability 865 testing, and implementation reports. For each feature, this section 866 provides the following information: 868 o A human-readable name 870 o An informational description 872 o A reference to the particular section of this document that 873 normatively defines the feature 875 o Whether the feature applies to the Client role, the Server role, 876 or both (where "N/A" signifies that the feature is not applicable 877 to the specified role) 879 o Whether the feature MUST or SHOULD be implemented, where the 880 capitalized terms are to be understood as described in [RFC2119] 882 The feature set specified here provides a basis for interoperability 883 testing and follows the spirit of a proposal made by Larry Masinter 884 within the IETF's NEWTRK Working Group in 2005 [INTEROP]. 886 Feature: address-domain-length 888 Description: Ensure that the domainpart of an XMPP address is at 889 least one octet in length and at most 1023 octets in length, and 890 that it conforms to the underlying length limits of the DNS. 892 Section: Section 3.2 894 Roles: Server MUST, client SHOULD. 896 Feature: address-domain-prep 898 Description: Ensure that the domainpart of an XMPP address conforms 899 to IDNA2008, that it contains only NR-LDH labels and U-labels (not 900 A-labels), and that all uppercase and titlecase code points are 901 mapped to their lowercase equivalents. 903 Section: Section 3.2 905 Roles: Server MUST, client SHOULD. 907 Feature: address-localpart-length 909 Description: Ensure that the localpart of an XMPP address is at 910 least one octet in length and at most 1023 octets in length. 912 Section: Section 3.3 914 Roles: Server MUST, client SHOULD. 916 Feature: address-localpart-prep 918 Description: Ensure that the localpart of an XMPP address conforms 919 to the "UsernameCaseMapped" profile. 921 Section: Section 3.3 923 Roles: Server MUST, client SHOULD. 925 Feature: address-resource-length 927 Description: Ensure that the resourcepart of an XMPP address is at 928 least one octet in length and at most 1023 octets in length. 930 Section: Section 3.4 932 Roles: Server MUST, client SHOULD. 934 Feature: address-resource-prep 936 Description: Ensure that the resourcepart of an XMPP address 937 conforms to the "Resourcepart" profile. 939 Section: Section 3.4 941 Roles: Server MUST, client SHOULD. 943 9. References 945 9.1. Normative References 947 [I-D.ietf-precis-framework] 948 Saint-Andre, P. and M. Blanchet, "Precis Framework: 949 Handling Internationalized Strings in Protocols", draft- 950 ietf-precis-framework-20 (work in progress), November 951 2014. 953 [I-D.ietf-precis-saslprepbis] 954 Saint-Andre, P. and A. Melnikov, "Username and Password 955 Preparation Algorithms", draft-ietf-precis-saslprepbis-11 956 (work in progress), November 2014. 958 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 959 STD 13, RFC 1034, November 1987. 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, March 1997. 964 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 965 10646", STD 63, RFC 3629, November 2003. 967 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 968 Specifications: ABNF", STD 68, RFC 5234, January 2008. 970 [RFC5890] Klensin, J., "Internationalized Domain Names for 971 Applications (IDNA): Definitions and Document Framework", 972 RFC 5890, August 2010. 974 [RFC5891] Klensin, J., "Internationalized Domain Names in 975 Applications (IDNA): Protocol", RFC 5891, August 2010. 977 [RFC5892] Faltstrom, P., "The Unicode Code Points and 978 Internationalized Domain Names for Applications (IDNA)", 979 RFC 5892, August 2010. 981 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 982 Internationalized Domain Names for Applications (IDNA)", 983 RFC 5893, August 2010. 985 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 986 Protocol (XMPP): Core", RFC 6120, March 2011. 988 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 989 6.3", 2013, 990 . 992 [UTR36] The Unicode Consortium, "Unicode Technical Report #36: 993 Unicode Security Considerations", November 2013, 994 . 996 9.2. Informative References 998 [I-D.ietf-precis-nickname] 999 Saint-Andre, P., "Preparation and Comparison of 1000 Nicknames", draft-ietf-precis-nickname-12 (work in 1001 progress), November 2014. 1003 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 1004 Reporting", Work in Progress, October 2005. 1006 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1007 and Support", STD 3, RFC 1123, October 1989. 1009 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 1010 With Widely Deployed DNS Software", RFC 1535, October 1011 1993. 1013 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1014 Internationalized Strings ("stringprep")", RFC 3454, 1015 December 2002. 1017 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1018 "Internationalizing Domain Names in Applications (IDNA)", 1019 RFC 3490, March 2003. 1021 See Section 1 for an explanation of why the normative 1022 reference to an obsoleted specification is needed. 1024 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1025 Protocol (XMPP): Core", RFC 3920, October 2004. 1027 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1028 Protocol (XMPP): Instant Messaging and Presence", RFC 1029 3921, October 2004. 1031 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1032 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1033 3986, January 2005. 1035 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1036 Identifiers (IRIs)", RFC 3987, January 2005. 1038 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1039 and Passwords", RFC 4013, February 2005. 1041 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1042 Security Layer (SASL)", RFC 4422, June 2006. 1044 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1045 (IRIs) and Uniform Resource Identifiers (URIs) for the 1046 Extensible Messaging and Presence Protocol (XMPP)", RFC 1047 5122, February 2008. 1049 [RFC5894] Klensin, J., "Internationalized Domain Names for 1050 Applications (IDNA): Background, Explanation, and 1051 Rationale", RFC 5894, August 2010. 1053 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1054 Internationalized Domain Names in Applications (IDNA) 1055 2008", RFC 5895, September 2010. 1057 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1058 Protocol (XMPP): Instant Messaging and Presence", RFC 1059 6121, March 2011. 1061 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 1062 Protocol (XMPP): Address Format", RFC 6122, March 2011. 1064 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1065 Internationalization in the IETF", BCP 166, RFC 6365, 1066 September 2011. 1068 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 1069 Problem Statement for the Preparation and Comparison of 1070 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 1072 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 1073 Unicode Security Mechanisms", July 2012, 1074 . 1076 [XEP-0004] 1077 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 1078 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 1080 [XEP-0016] 1081 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 1082 0016, February 2007. 1084 [XEP-0029] 1085 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 1086 XEP 0029, October 2003. 1088 [XEP-0030] 1089 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1090 Andre, "Service Discovery", XSF XEP 0030, June 2008. 1092 [XEP-0045] 1093 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 1094 2012. 1096 [XEP-0048] 1097 Blackman, R., Millard, P., and P. Saint-Andre, 1098 "Bookmarks", XSF XEP 0048, November 2007. 1100 [XEP-0054] 1101 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 1103 [XEP-0060] 1104 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1105 Subscribe", XSF XEP 0060, July 2010. 1107 [XEP-0065] 1108 Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, 1109 "SOCKS5 Bytestreams", XSF XEP 0065, April 2011. 1111 [XEP-0077] 1112 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 1113 January 2012. 1115 [XEP-0106] 1116 Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 1117 0106, June 2007. 1119 [XEP-0114] 1120 Saint-Andre, P., "Jabber Component Protocol", XSF XEP 1121 0114, March 2005. 1123 [XEP-0144] 1124 Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, 1125 August 2005. 1127 [XEP-0165] 1128 Saint-Andre, P., "Best Practices to Discourage JID 1129 Mimicking", XSF XEP 0165, December 2007. 1131 [XEP-0166] 1132 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 1133 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 1134 2009. 1136 [XEP-0191] 1137 Saint-Andre, P., "Blocking Command", XSF XEP 0191, July 1138 2012. 1140 [XEP-0203] 1141 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 1142 September 2009. 1144 [XEP-0220] 1145 Miller, J., Saint-Andre, P., and P. Hancke, "Server 1146 Dialback", XSF XEP 0220, August 2012. 1148 [XEP-0292] 1149 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 1150 0292, October 2011. 1152 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 1153 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 1154 Edition)", World Wide Web Consortium Recommendation REC- 1155 xml-20081126, November 2008, 1156 . 1158 Appendix A. Differences from RFC 6122 1160 Based on consensus derived from working group discussion, 1161 implementation and deployment experience, and formal interoperability 1162 testing, the following substantive modifications were made from RFC 1163 6122. 1165 o Changed domainpart preparation to use IDNA2008 (instead of 1166 IDNA2003). 1168 o Changed localpart preparation to use the UsernameCaseMapped 1169 profile of the PRECIS IdentifierClass (instead of the Nodeprep 1170 profile of Stringprep). 1172 o Changed resourcepart preparation to use the Resourcepart profile 1173 of the PRECIS FreeformClass (instead of the Resourceprep profile 1174 of Stringprep). 1176 o Specified that internationalized labels within domainparts must be 1177 U-labels (instead of "should be" U-labels). 1179 o Specified that fullwidth and halfwidth characters must be mapped 1180 to their decomposition mappings (previously handled through the 1181 use of NFKC). 1183 o Specified the use of Unicode Normalization Form C (instead of 1184 Unicode Normalization Form KC as specified in the Nodeprep and 1185 Resourceprep profiles of Stringprep). 1187 o Specified that servers must enforce the address formatting rules. 1189 Appendix B. Acknowledgements 1191 Thanks to Miguel Garcia, Joe Hildebrand, Jonathan Lennox, Matt 1192 Miller, and Florian Zeitz for their feedback. 1194 Some text in this document was borrowed or adapted from [RFC5890], 1195 [RFC5891], [RFC5894], and [XEP-0165]. 1197 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 1198 employing him during his work on earlier versions of this document. 1200 Author's Address 1202 Peter Saint-Andre 1203 &yet 1205 Email: peter@andyet.com 1206 URI: https://andyet.com/