idnits 2.17.1 draft-ietf-xmpp-6122bis-13.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 (September 10, 2014) is 3516 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-09 -- 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) September 10, 2014 5 Intended status: Standards Track 6 Expires: March 14, 2015 8 Extensible Messaging and Presence Protocol (XMPP): Address Format 9 draft-ietf-xmpp-6122bis-13 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 March 14, 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 . . . . . . . . . . . . . . . . . . . . . 9 63 4.3.3. Comparison . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 17 72 7.1. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 17 73 7.1.1. JIDlocalIdentifierClass . . . . . . . . . . . . . . . 17 74 7.1.2. JIDresourceFreeformClass . . . . . . . . . . . . . . 18 75 7.2. Stringprep Profiles Registry . . . . . . . . . . . . . . 19 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 8.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 19 78 8.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 19 79 8.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . 19 80 8.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 20 81 8.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 20 82 9. Conformance Requirements . . . . . . . . . . . . . . . . . . 22 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 85 10.2. Informative References . . . . . . . . . . . . . . . . . 24 86 Appendix A. Differences from RFC 6122 . . . . . . . . . . . . . 28 87 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 28 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. Enforcement is 141 the responsibility of an XMPP server (although a server does not 142 need to enforce the rules every time it handles a JID or JID part; 143 see Section 5 for a detailed discussion). 145 o Comparison entails applying all of the rules specified for a 146 particular profile to two separate strings, for the purpose of 147 determining if the two strings are equivalent. 149 o Preparation entails only ensuring that the characters in an 150 individual string are allowed by the underlying PRECIS base class 151 (IdentifierClass or FreeformClass). Preparation can the 152 responsibility of an XMPP client or (in some circumstances) an 153 XMPP server (here again see Section 5 for a detailed discussion). 155 4. Addresses 157 4.1. Fundamentals 159 An XMPP entity is anything that can communicate using XMPP. For 160 historical reasons, the network address of an XMPP entity is called a 161 Jabber Identifier ("JID"). A valid JID is a string of Unicode code 162 points [UNICODE], encoded using UTF-8 [RFC3629], and structured as an 163 ordered sequence of localpart, domainpart, and resourcepart, where 164 the first two parts are demarcated by the '@' character used as a 165 separator and the last two parts are similarly demarcated by the '/' 166 character (e.g., ). 168 The syntax for a JID is defined as follows using the Augmented 169 Backus-Naur Form (ABNF) as specified in [RFC5234]. 171 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 172 localpart = 1*1023(localbyte) 173 ; 174 ; a "localbyte" is a byte used to represent a 175 ; UTF-8 encoded Unicode code point that conforms 176 ; to the "JIDlocalIdentifierClass" profile of 177 ; the 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 conforms 195 ; 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 conforms 201 ; to the "JIDresourceFreeformClass" profile of 202 ; the PRECIS FreeformClass 203 ; 205 All JIDs are based on the foregoing structure. However, note that 206 the formal syntax provided above does not capture all of the rules 207 and restrictions that apply to JIDs, which are described below. 209 Each allowable portion of a JID (localpart, domainpart, and 210 resourcepart) MUST NOT be zero octets in length and MUST NOT be more 211 than 1023 octets in length, resulting in a maximum total size 212 (including the '@' and '/' separators) of 3071 octets. 214 Implementation Note: The length limits on JIDs and parts of JIDs 215 are based on octets (bytes), not characters. UTF-8 encoding can 216 result in more than one octet per character. 218 Implementation Note: When dividing a JID into its component parts, 219 an implementation needs to match the separator characters '@' and 220 '/' before applying any transformation algorithms, which might 221 decompose certain Unicode code points to the separator characters 222 (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL 223 AT decomposes to U+0040 COMMERCIAL AT, although note that this 224 decomposition does not occur under Unicode Normalization C, which 225 is used in this specification). 227 This document defines the native format for JIDs; see [RFC5122] for 228 information about the representation of a JID as a Uniform Resource 229 Identifier (URI) [RFC3986] or Internationalized Resource Identifier 230 (IRI) [RFC3987] and the extraction of a JID from an XMPP URI or IRI. 232 4.2. Domainpart 234 The domainpart of a JID is that portion after the first '@' character 235 (if any) and before the first '/' character (if any); it is the 236 primary identifier and is the only REQUIRED element of a JID (a mere 237 domainpart is a valid JID). Typically a domainpart identifies the 238 "home" server to which clients connect for XML routing and data 239 management functionality. However, it is not necessary for an XMPP 240 domainpart to identify an entity that provides core XMPP server 241 functionality (e.g., a domainpart can identify an entity such as a 242 multi-user chat service [XEP-0045], a publish-subscribe service 243 [XEP-0060], or a user directory). 245 The domainpart for every XMPP service MUST be a fully-qualified 246 domain name (FQDN), an IPv4 address, an IPv6 address, or an 247 unqualified hostname (i.e., a text label that is resolvable on a 248 local network). 250 Informational Note: The term "fully-qualified domain name" is not 251 well defined. In [RFC1034] it is also called an absolute domain 252 name, and the two terms are associated in [RFC1535]. The earliest 253 use of the term can be found in [RFC1123]. References to those 254 older specifications ought not to be construed as limiting the 255 characters of a fully-qualified domain name to the ASCII range; 256 for example, [RFC5890] mentions that a fully-qualified domain name 257 can contain one or more U-labels. 259 Interoperability Note: Domainparts that are IP addresses might not 260 be accepted by other services for the purpose of server-to-server 261 communication, and domainparts that are unqualified hostnames 262 cannot be used on public networks because they are resolvable only 263 on a local network. 265 If the domainpart includes a final character considered to be a label 266 separator (dot) by [RFC1034], this character MUST be stripped from 267 the domainpart before the JID of which it is a part is used for the 268 purpose of routing an XML stanza, comparing against another JID, or 269 constructing an XMPP URI or IRI [RFC5122]. In particular, such a 270 character MUST be stripped before any other canonicalization steps 271 are taken. 273 In general, the content of a domainpart is an Internationalized 274 Domain Name ("IDN") as described in the specifications for 275 Internationalized Domain Names in Applications (commonly called 276 "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as 277 defined in [RFC5890]. 279 After any and all normalization, conversion, and mapping of code 280 points as well as encoding of the string as UTF-8, a domainpart MUST 281 NOT be zero octets in length and MUST NOT be more than 1023 octets in 282 length. (Naturally, the length limits of [RFC1034] apply, and 283 nothing in this document is to be interpreted as overriding those 284 more fundamental limits.) 286 Detailed rules and considerations for preparation, enforcement, and 287 comparison are provided in the following sections. 289 4.2.1. Preparation 291 An XMPP entity that prepares a string for inclusion in a domainpart 292 slot MUST ensure that the string consists only of Unicode code points 293 that are allowed in NR-LDH labels or U-labels as defined in 294 [RFC5890]. This implies that the string MUST NOT include A-labels as 295 defined in [RFC5890]; each A-label MUST be converted to a U-label 296 during preparation of a string for inclusion in a domainpart slot. 297 In addition, the string MUST be encoded as UTF-8 [RFC3629]. 299 4.2.2. Enforcement 301 An XMPP entity that performs enforcement in domainpart slots MUST 302 prepare a string as described in the previous section and MUST also 303 apply the normalization, case-mapping, and width-mapping rules 304 described below: 306 1. The string MUST consist only of Unicode code points that conform 307 to the rules specified in [RFC5892] (which includes Unicode 308 normalization). 310 2. All uppercase and titlecase code points in the string MUST be 311 mapped to their lowercase equivalents, preferably using Unicode 312 Default Case Folding as defined in Chapter 3 of the Unicode 313 Standard [UNICODE]. 315 3. Fullwidth and halfwidth characters in the string MUST be mapped 316 to their decomposition mappings. 318 These rules MUST be applied in the order shown. The reader is 319 advised that this order is different from the order for localparts 320 and resourceparts as described under Section 4.3 and Section 4.4, in 321 order to maintain consistency with the IDNA methods in both [RFC5892] 322 and [RFC5895]. 324 4.2.3. Comparison 326 An XMPP entity that performs comparison of two strings before or 327 after their inclusion in domainpart slots MUST prepare each string 328 and enforce the normalization, case-mapping, and width-mapping rules 329 specified in the previous two sections. The two strings are to be 330 considered equivalent if they are an exact octet-for-octet match 331 (sometimes called "bit-string identity"). 333 4.3. Localpart 335 The localpart of a JID is an optional identifier placed before the 336 domainpart and separated from the latter by the '@' character. 337 Typically a localpart uniquely identifies the entity requesting and 338 using network access provided by a server (i.e., a local account), 339 although it can also represent other kinds of entities (e.g., a chat 340 room associated with a multi-user chat service [XEP-0045]). The 341 entity represented by an XMPP localpart is addressed within the 342 context of a specific domain (i.e., ). 344 A localpart MUST NOT be zero octets in length and MUST NOT be more 345 than 1023 octets in length. This rule is to be enforced after any 346 normalization and mapping of code points as well as encoding of the 347 string as UTF-8. 349 Detailed rules and considerations for preparation, enforcement, and 350 comparison are provided in the following sections. 352 4.3.1. Preparation 354 An XMPP entity that prepares a string for inclusion in a localpart 355 slot MUST ensure that the string consists only of Unicode code points 356 that conform to the "IdentifierClass" base string class defined in 357 [I-D.ietf-precis-framework]. In addition, the string MUST be encoded 358 as UTF-8 [RFC3629]. 360 4.3.2. Enforcement 362 An XMPP entity that performs enforcement in localpart slots MUST 363 prepare a string as described in the previous section and MUST also 364 apply the width-mapping rules, case-mapping, normalization, and 365 exception rules for the JIDlocalIdentifierClass profile described 366 below (these rules MUST be applied in the order shown). 368 1. Fullwidth and halfwidth characters MUST be mapped to their 369 decomposition mappings. 371 2. Uppercase and titlecase characters MUST be mapped to their 372 lowercase equivalents, preferably using Unicode Default Case 373 Folding as defined in Chapter 3 of the Unicode Standard 374 [UNICODE]. 376 3. All characters MUST be normalized using Unicode Normalization 377 Form C (NFC). 379 The exclusion rule for the The JIDlocalIdentifierClass profile is as 380 follows, i.e., the characters listed below are explicitly disallowed 381 in XMPP localparts even though they are allowed by the 382 IdentifierClass base class: 384 U+0022 (QUOTATION MARK), i.e., " 386 U+0026 (AMPERSAND), i.e., & 388 U+0027 (APOSTROPHE), i.e., ' 390 U+002F (SOLIDUS), i.e., / 392 U+003A (COLON), i.e., : 394 U+003C (LESS-THAN SIGN), i.e., < 396 U+003E (GREATER-THAN SIGN), i.e., > 398 U+0040 (COMMERCIAL AT), i.e., @ 400 Implementation Note: An XMPP-specific method for escaping the 401 above-listed characters (along with U+0020, i.e., ASCII SPACE) has 402 been defined in the JID Escaping specification [XEP-0106]. 404 With regard to directionality, applications MUST apply the "Bidi 405 Rule" defined in [RFC5893] (i.e., each of the six conditions of the 406 Bidi Rule must be satisfied). 408 4.3.3. Comparison 410 An XMPP entity that performs comparison of two strings before or 411 after their inclusion in localpart slots MUST prepare each string and 412 enforce the normalization, case-mapping, and width-mapping rules 413 specified in the previous two sections. The two strings are to be 414 considered equivalent if they are an exact octet-for-octet match 415 (sometimes called "bit-string identity"). 417 4.4. Resourcepart 419 The resourcepart of a JID is an optional identifier placed after the 420 domainpart and separated from the latter by the '/' character. A 421 resourcepart can modify either a address or a 422 mere address. Typically a resourcepart uniquely 423 identifies a specific connection (e.g., a device or location) or 424 object (e.g., an occupant in a multi-user chat room [XEP-0045]) 425 belonging to the entity associated with an XMPP localpart at a domain 426 (i.e., ). 428 XMPP entities SHOULD consider resourceparts to be opaque strings and 429 SHOULD NOT impute meaning to any given resourcepart. In particular: 431 o Use of the '/' character as a separator between the domainpart and 432 the resourcepart does not imply that XMPP addresses are 433 hierarchical in the way that, say, HTTP URIs are hierarchical (see 434 [RFC3986] for general discussion); thus for example an XMPP 435 address of the form does not 436 identify a resource "bar" that exists below a resource "foo" in a 437 hierarchy of resources associated with the entity 438 "localpart@domainpart". 440 o The '@' character is allowed in the resourcepart and is often used 441 in the "handle" shown in XMPP chatrooms [XEP-0045]. For example, 442 the JID describes an entity who 443 is an occupant of the room with a handle 444 of . However, chatroom services do not necessarily 445 check such an asserted handle against the occupant's real JID. 447 A resourcepart MUST NOT be zero octets in length and MUST NOT be more 448 than 1023 octets in length. This rule is to be enforced after any 449 normalization and mapping of code points as well as encoding of the 450 string as UTF-8. 452 Detailed rules and considerations for preparation, enforcement, and 453 comparison are provided in the following sections. 455 In some contexts, it might be appropriate to apply more restrictive 456 rules to the preparation, enforcement, and comparison of XMPP 457 resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it 458 might be appropriate to apply the rules specified in 459 [I-D.ietf-precis-nickname]. However, the application of more 460 restrictive rules is out of scope for resourceparts in general and is 461 properly defined in specifications for the relevant XMPP extensions. 463 4.4.1. Preparation 465 An XMPP entity that prepares a string for inclusion in a resourcepart 466 slot MUST ensure that the string consists only of Unicode code points 467 that conform to the "FreeformClass" base string class defined in 468 [I-D.ietf-precis-framework]. In addition, the string MUST be encoded 469 as UTF-8 [RFC3629]. 471 4.4.2. Enforcement 473 An XMPP entity that performs enforcement in resourcepart slots MUST 474 prepare a string as described in the previous section and MUST also 475 apply the width-mapping rules, special mapping, additional mapping, 476 case-mapping, and normalization rules for the 477 JIDresourceFreeformClass profile described below (these rules MUST be 478 applied in the order shown). 480 1. Fullwidth and halfwidth characters MAY be mapped to their 481 decomposition mappings. 483 2. Any instances of non-ASCII space MUST be mapped to ASCII space 484 (U+0020); such an instance is any Unicode code point that has a 485 compatibility mapping of any kind (including but not limited to 486 as for U+0384 GREEK TONOS, as for U+2007 487 FIGURE SPACE, and as for U+3000 IDEOGRAPHIC SPACE) to 488 U+0020 SPACE. 490 3. So-called additional mappings MAY be applied, such as mapping of 491 characters that are similar to common delimiters (such as '@', 492 ':', '/', '+', '-', and '.', e.g., mapping of IDEOGRAPHIC FULL 493 STOP (U+3002) to FULL STOP (U+002E)) and special handling of 494 certain characters or classes of characters (e.g., mapping of 495 non-ASCII spaces to ASCII space); the PRECIS mappings document 496 [I-D.ietf-precis-mappings] describes such mappings in more 497 detail. 499 4. Uppercase and titlecase characters MAY be mapped to their 500 lowercase equivalents, preferably using Unicode Default Case 501 Folding as defined in Chapter 3 of the Unicode Standard 502 [UNICODE]. 504 5. All characters MUST be normalized using Unicode Normalization 505 Form C (NFC). 507 Finally, leading and trailing whitespace (i.e., one or more instances 508 of the ASCII space character at the beginning or end of a 509 resourcepart) MUST be removed (e.g., "stpeter " is mapped to 510 "stpeter"). 512 Note: There is no exclusion rule for the JIDresourceFreeformClass 513 profile. 515 With regard to directionality, applications MUST apply the "Bidi 516 Rule" defined in [RFC5893] (i.e., each of the six conditions of the 517 Bidi Rule must be satisfied). 519 4.4.3. Comparison 521 An XMPP entity that performs comparison of two strings before or 522 after their inclusion in resourcepart slots MUST prepare each string 523 and enforce the normalization, case-mapping, and width-mapping rules 524 specified in the previous two sections. The two strings are to be 525 considered equivalent if they are an exact octet-for-octet match 526 (sometimes called "bit-string identity"). 528 4.5. Examples 530 The following examples illustrate a small number of JIDs that are 531 consistent with the format defined above. 533 Table 1: A sample of legal JIDs 535 +---------------------------------+---------------------------------+ 536 | # | JID | Notes | 537 +---------------------------------+---------------------------------+ 538 | 1 | juliet@example.com | A "bare JID" | 539 +---------------------------------+---------------------------------+ 540 | 2 | juliet@example.com/foo | A "full JID" | 541 +---------------------------------+---------------------------------+ 542 | 3 | juliet@example.com/foo bar | Single space in resourcepart | 543 +---------------------------------+---------------------------------+ 544 | 4 | foo\20bar@example.com | Single space in localpart, as | 545 | | | optionally escaped using the | 546 | | | XMPP "JID Escaping" extension | 547 +---------------------------------+---------------------------------+ 548 | 5 | fussball@example.com | Another bare JID | 549 +---------------------------------+---------------------------------+ 550 | 6 | fußball@example.com | The third character is LATIN | 551 | | | SMALL LETTER SHARP S (U+00DF) | 552 +---------------------------------+---------------------------------+ 553 | 7 | π@example.com | A localpart of GREEK SMALL | 554 | | | LETTER PI (U+03C0) | 555 +---------------------------------+---------------------------------+ 556 | 8 | π@example.com/Σ | A resourcepart of GREEK CAPITAL | 557 | | | LETTER SIGMA (U+03A3) | 558 +---------------------------------+---------------------------------+ 559 | 9 | π@example.com/σ | A resourcepart of GREEK SMALL | 560 | | | LETTER SIGMA (U+03C3) | 561 +---------------------------------+---------------------------------+ 562 | 10| π@example.com/ς | A resourcepart of GREEK SMALL | 563 | | | LETTER FINAL SIGMA (U+03C2) | 564 +---------------------------------+---------------------------------+ 565 | 11| henryiv@example.com/♚| A resourcepart of the Unicode | 566 | | | character BLACK CHESS KING | 567 | | | (U+265A) | 568 +---------------------------------+---------------------------------+ 569 | 12| example.com | A domainpart | 570 +---------------------------------+---------------------------------+ 571 | 13| example.com/foobar | A domainpart plus resourcepart | 572 +---------------------------------+---------------------------------+ 574 Several points are worth noting. Regarding examples 5 and 6: 575 although in German the character esszett (LATIN SMALL LETTER SHARP S, 576 U+00DF) can mostly be used interchangeably with the two characters 577 "ss", the localparts in these examples are different and (if desired) 578 a server would need to enforce a registration policy that disallows 579 one of them if the other is registered. Regarding examples 8, 9, and 580 10: case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to lowercase 581 (i.e., to GREEK SMALL LETTER SIGMA, U+03C3) during comparison would 582 result in matching the JIDs in examples 8 and 9; however, because the 583 PRECIS mapping rules do not account for the special status of GREEK 584 SMALL LETTER FINAL SIGMA (U+03C2), the JIDs in examples 8 and 10 or 585 examples 9 and 10 would not be matched. Regarding example 11: symbol 586 characters such as BLACK CHESS KING (U+265A) are allowed by the 587 PRECIS FreeformClass and thus can be used in resourceparts. 588 Regarding example 13: JIDs consisting of a domainpart and 589 resourcepart are rarely seen in the wild, but are allowed according 590 to the XMPP address format. 592 The following examples illustrate strings that are not JIDs because 593 they violate the format defined above. 595 Table 2: A sample of strings that violate the JID rules 597 +---------------------------------+---------------------------------+ 598 | # | Non-JID string | Notes | 599 +---------------------------------+---------------------------------+ 600 | 13| "juliet"@example.com | Quotation marks (U+0022) in | 601 | | | localpart | 602 +---------------------------------+---------------------------------+ 603 | 14| foo bar@example.com | Space (U+0020) in localpart | 604 +---------------------------------+---------------------------------+ 605 | 15| juliet@example.com/ foo | Leading space in resourcepart | 606 +---------------------------------+---------------------------------+ 607 | 16| <@example.com/> | Zero-length localpart and | 608 | | | resourcepart ('<' and '>' are | 609 | | | used here to show the start and | 610 | | | end of the JID in question) | 611 +---------------------------------+---------------------------------+ 612 | 17| henryⅣ@example.com | The sixth character is ROMAN | 613 | | | NUMERAL FOUR (U+2163) | 614 +---------------------------------+---------------------------------+ 615 | 18| ♚@example.com | A localpart of BLACK CHESS KING | 616 | | | (U+265A) | 617 +---------------------------------+---------------------------------+ 618 | 19| juliet@ | A localpart without domainpart | 619 +---------------------------------+---------------------------------+ 620 | 20| /foobar | A resourcepart without | 621 | | domainpart | 622 +---------------------------------+---------------------------------+ 624 Here again, several points are worth noting. Regarding example 15, 625 even though ASCII SPACE (U+0020) is disallowed in the PRECIS 626 IdentifierClass, it can be escaped to "\27" in XMPP localparts by 627 using the JID Escaping rules defined in [XEP-0106], as illustrated by 628 example 4 in Table 1. Regarding example 17, the Unicode character 629 ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the 630 string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL 631 LETTER V (U+0056), but characters with compatibility equivalents are 632 not allowed in the PRECIS IdentiferClass. Regarding example 18: 633 symbol characters such as BLACK CHESS KING (U+265A) are not allowed 634 in the PRECIS IdentifierClass; however, both of the non-ASCII 635 characters in examples 17 and 18 are allowed in the PRECIS Freeform 636 class and therefore in the XMPP resourcepart (as illustrated for 637 U+265A by example 11 in Table 1). Regarding examples 19 and 20: the 638 domainpart is required in a JID. 640 5. Enforcement in JIDs and JID Parts 642 Enforcement entails applying all of the rules specified in this 643 document. Enforcement of the XMPP address format rules is the 644 responsibility of XMPP servers. Although XMPP clients SHOULD prepare 645 complete JIDs and parts of JIDs in accordance with this document 646 before including them in protocol slots within XML streams (such that 647 JIDs and parts of JIDs are in conformance), XMPP servers MUST enforce 648 the rules wherever possible and reject stanzas and other XML elements 649 that violate the rules (for stanzas, by returning a 650 error to the sender as described in Section 8.3.3.8 of [RFC6120]). 652 Enforcement applies to complete JIDs and to parts of JIDs. To 653 facilitate implementation, this document defines the concepts of "JID 654 slot", "localpart slot", and "resourcepart slot" (similar to the 655 concept of a "domain name slot" for IDNA2008 defined in 656 Section 2.3.2.6 of [RFC5890]): 658 JID Slot: An XML element or attribute explicitly designated in XMPP 659 or in XMPP extensions for carrying a complete JID. 661 Localpart Slot: An XML element or attribute explicitly designated in 662 XMPP or in XMPP extensions for carrying the localpart of a JID. 664 Resourcepart Slot: An XML element or attribute explicitly designated 665 in XMPP or in XMPP extensions for carrying the resourcepart of a 666 JID. 668 A server is responsible for enforcing the address format rules when 669 receiving protocol elements from clients where the server is expected 670 to handle such elements directly or to use them for purposes of 671 routing a stanza to another domain or delivering a stanza to a local 672 entity; two examples from [RFC6120] are the 'to' attribute on XML 673 stanzas (which is a JID slot used by XMPP servers for routing of 674 outbound stanzas) and the child of the element 675 (which is a resourcepart slot used by XMPP servers for binding of a 676 resource to an account for routing of stanzas between the server and 677 a particular client). An example from [RFC6121] is the 'jid' 678 attribute of the roster element. 680 A server is not responsible for enforcing the rules when the protocol 681 elements are intended for communication among other entities, 682 typically within the payload of a stanza that the server is merely 683 routing to another domain or delivering to a local entity. Two 684 examples are the 'initiator' attribute in the Jingle extension 685 [XEP-0166] (which is a JID slot used for client-to-client 686 coordination of multimedia sessions) and the 'nick' attribute in the 687 Multi-User Chat extension [XEP-0045] (which is a resourcepart slot 688 used for administrative purposes in the context of XMPP chatrooms). 689 In such cases, clients SHOULD enforce the rules themselves and not 690 depend on the server to do so, and client implementers need to 691 understand that not enforcing the rules can lead to a degraded user 692 experience or to security vulnerabilities. However, when an add-on 693 service (e.g., a multi-user chat service) handles a stanza directly, 694 it ought to enforce the rules as well, as defined in the relevant 695 specification for that type of service. 697 This document does not provide an exhaustive list of JID slots, 698 localpart slots, or resourcepart slots. However, implementers of 699 core XMPP servers are advised to consider as JID slots at least the 700 following elements and attributes when they are handled directly or 701 used for purposes of routing to another domain or delivering to a 702 local entity: 704 o The 'from' and 'to' stream attributes and the 'from' and 'to' 705 stanza attributes [RFC6120]. 707 o The 'jid' attribute of the roster element for contact list 708 management [RFC6121]. 710 o The 'value' attribute of the element for Privacy Lists 711 [RFC3921] [XEP-0016] when the value of the 'type' attribute is 712 "jid". 714 o The 'jid' attribute of the element for Service Discovery 715 defined in [XEP-0030]. 717 o The element for Data Forms [XEP-0004], when the 'type' 718 attribute is "jid-single" or "jid-multi". 720 o The 'jid' attribute of the element for Bookmark 721 Storage [XEP-0048]. 723 o The of the element for vCard 3.0 [XEP-0054] 724 and the child of the element for vCard 4.0 726 [XEP-0292] when the XML character data identifies an XMPP URI 727 [RFC5122]. 729 o The 'from' attribute of the element for Delayed Delivery 730 [XEP-0203]. 732 o The 'jid' attribute of the element for the Blocking 733 Command [XEP-0191]. 735 o The 'from' and 'to' attributes of the and 736 elements for Server Dialback [RFC3921], [XEP-0220]. 738 o The 'from' and 'to' attributes of the , , and 739 elements for the Jabber Component Protocol [XEP-0114]. 741 Developers of XMPP clients and specialized XMPP add-on services are 742 advised to check the appropriate specifications for JID slots, 743 localpart slots, and resourcepart slots in XMPP protocol extensions 744 such as Service Discovery [XEP-0030], Multi-User Chat [XEP-0045], 745 Publish-Subscribe [XEP-0060], SOCKS5 Bytestreams [XEP-0065], In-Band 746 Registration [XEP-0077], Roster Item Exchange [XEP-0144], and Jingle 747 [XEP-0166]. 749 6. Internationalization Considerations 751 XMPP applications MUST support IDNA2008 for domainparts as described 752 under Section 4.2, the "JIDlocalIdentifierClass" profile for 753 localparts as described under Section 4.3, and the 754 "JIDresourceFreeformClass" profile for resourceparts as described 755 under Section 4.4. This enables XMPP addresses to include a wide 756 variety of characters outside the ASCII range. Rules for enforcement 757 of the XMPP address format are provided in [RFC6120] and 758 specifications for various XMPP extensions. 760 Interoperability Note: For backward compatibility, many existing 761 XMPP implementations and deployments support IDNA2003 [RFC3490] 762 for domainparts, and the stringprep [RFC3454] profiles Nodeprep 763 and Resourceprep [RFC3920] for localparts and resourceparts. 765 7. IANA Considerations 767 7.1. PRECIS Profiles Registry 769 7.1.1. JIDlocalIdentifierClass 771 The following completed template provides the information necessary 772 for the IANA to add 'JIDlocalIdentifierClass' to the PRECIS Profiles 773 Registry. 775 Name: JIDlocalIdentifierClass. 777 Applicability: Localparts of XMPP addresses. 779 Base Class: IdentifierClass. 781 Replaces: Nodeprep. 783 Width Mapping: Map fullwidth and halfwidth characters to their 784 decomposition mappings. 786 Additional Mappings: None required or recommended. 788 Case Mapping: Map uppercase and titlecase characters to lowercase. 790 Normalization: NFC. 792 Directionality: The "Bidi Rule" defined in RFC 5893 applies. 794 Exclusions: Eight legacy characters in the ASCII range: U+0022, 795 U+0026, U+0027, U+002F, U+003A, U+003C, U+003E, U+0040. 797 Enforcement: In general, XMPP servers are responsible for enforcing 798 the rules (although XMPP clients and components can also be 799 responsible for doing so, depending on the JID slots, localpart 800 slots, and resourcepart slots where JIDs or parts of JIDs are 801 used). 803 Specification: this document. [Note to RFC Editor: please change 804 "this document" to the number issued for this specification.] 806 7.1.2. JIDresourceFreeformClass 808 The following completed template provides the information necessary 809 for the IANA to add 'JIDresourceFreeformClass' to the PRECIS Profiles 810 Registry. 812 Profile: JIDresourceFreeformClass. 814 Applicability: Resourceparts of XMPP addresses. 816 Base Class: FreeformClass 818 Replaces: The Resourceprep profile of Stringprep. 820 Width Mapping: Optional. 822 Additional Mappings: Map non-ASCII space to ASCII space. 824 Case Mapping: Optional. 826 Normalization: NFC. 828 Directionality: The "Bidi Rule" defined in RFC 5893 applies. 830 Exclusions: None. 832 Enforcement: In general, XMPP servers are responsible for enforcing 833 the rules (although XMPP clients and components can also be 834 resonsible for doing so, depending on the protocol slots where 835 JIDs or parts of JIDs are used). 837 Specification: this document. [Note to RFC Editor: please change 838 "this document" to the number issued for this specification.] 840 7.2. Stringprep Profiles Registry 842 The Stringprep specification [RFC3454] did not provide for entries in 843 the Stringprep Profiles registry to be marked as anything except 844 current or not current. Because this document obsoletes RFC 6122, 845 which registered the "Nodeprep" and "Resourceprep" profiles, IANA is 846 requested at the least to mark those profiles as not current, and if 847 possible to mark them as a deprecated (with a pointer to this 848 document). 850 8. Security Considerations 852 8.1. Reuse of PRECIS 854 The security considerations described in [I-D.ietf-precis-framework] 855 apply to the "IdentifierClass" and "FreeformClass" base string 856 classes used in this document for XMPP localparts and resourceparts, 857 respectively. The security considerations described in [RFC5890] 858 apply to internationalized domain names, which are used here for XMPP 859 domainparts. 861 8.2. Reuse of Unicode 863 The security considerations described in [UTS39] apply to the use of 864 Unicode characters in XMPP addresses. 866 8.3. Address Spoofing 868 There are two forms of address spoofing: forging and mimicking. 870 8.3.1. Address Forging 872 In the context of XMPP technologies, address forging occurs when an 873 entity is able to generate an XML stanza whose 'from' address does 874 not correspond to the account credentials with which the entity 875 authenticated onto the network (or an authorization identity provided 876 during negotiation of SASL authentication [RFC4422] as described in 877 [RFC6120]). For example, address forging occurs if an entity that 878 authenticated as "juliet@im.example.com" is able to send XML stanzas 879 from "nurse@im.example.com" or "romeo@example.net". 881 Address forging is difficult in XMPP systems, given the requirement 882 for sending servers to stamp 'from' addresses and for receiving 883 servers to verify sending domains via server-to-server authentication 884 (see [RFC6120]). However, address forging is possible if: 886 o A poorly implemented server ignores the requirement for stamping 887 the 'from' address. This would enable any entity that 888 authenticated with the server to send stanzas from any 889 localpart@domainpart as long as the domainpart matches the sending 890 domain of the server. 892 o An actively malicious server generates stanzas on behalf of any 893 registered account at the domain or domains hosted at that server. 895 Therefore, an entity outside the security perimeter of a particular 896 server cannot reliably distinguish between JIDs of the form 897 at that server and thus can authenticate only 898 the domainpart of such JIDs with any level of assurance. This 899 specification does not define methods for discovering or 900 counteracting the kind of poorly implemented or rogue servers just 901 described. However, the end-to-end authentication or signing of XMPP 902 stanzas could help to mitigate this risk, since it would require the 903 rogue server to generate false credentials for signing or encryption 904 of each stanza, in addition to modifying 'from' addresses. 906 8.3.2. Address Mimicking 908 Address mimicking occurs when an entity provides legitimate 909 authentication credentials for and sends XML stanzas from an account 910 whose JID appears to a human user to be the same as another JID. 911 Because many characters are visually similar, it is relatively easy 912 to mimic JIDs in XMPP systems. As one simple example, the localpart 913 "ju1iet" (using the Arabic numeral one as the third character) might 914 appear the same as the localpart "juliet" (using lowercase "L" as the 915 third character). 917 As explained in [RFC5890], [I-D.ietf-precis-framework], [UTR36], and 918 [UTS39], there is no straightforward solution to the problem of 919 visually similar characters. Furthermore, IDNA and PRECIS 920 technologies do not attempt to define such a solution. As a result, 921 XMPP domainparts, localparts, and resourceparts could contain such 922 characters, leading to security vulnerabilities such as the 923 following: 925 o A domainpart is always employed as one part of an entity's address 926 in XMPP. One common usage is as the address of a server or 927 server-side service, such as a multi-user chat service [XEP-0045]. 928 The security of such services could be compromised based on 929 different interpretations of the internationalized domainpart; for 930 example, a user might authorize a malicious entity at a fake 931 server to view the user's presence information, or a user could 932 join chatrooms at a fake multi-user chat service. 934 o A localpart can be employed as one part of an entity's address in 935 XMPP. One common usage is as the username of an instant messaging 936 user; another is as the name of a multi-user chat room; and many 937 other kinds of entities could use localparts as part of their 938 addresses. The security of such services could be compromised 939 based on different interpretations of the internationalized 940 localpart; for example, a user entering a single internationalized 941 localpart could access another user's account information, or a 942 user could gain access to a hidden or otherwise restricted chat 943 room or service. 945 o A resourcepart can be employed as one part of an entity's address 946 in XMPP. One common usage is as the name for an instant messaging 947 user's connected resource; another is as the nickname of a user in 948 a multi-user chat room; and many other kinds of entities could use 949 resourceparts as part of their addresses. The security of such 950 services could be compromised based on different interpretations 951 of the internationalized resourcepart; for example, two or more 952 confusable resources could be bound at the same time to the same 953 account (resulting in inconsistent authorization decisions in an 954 XMPP application that uses full JIDs), or a user could send a 955 private message to someone other than the intended recipient in a 956 multi-user chat room. 958 XMPP services and clients are strongly encouraged to define and 959 implement consistent policies regarding the registration, storage, 960 and presentation of visually similar characters in XMPP systems. In 961 particular, service providers and software implementers are strongly 962 encouraged to apply the policies recommended in 963 [I-D.ietf-precis-framework]. 965 9. Conformance Requirements 967 This section describes a protocol feature set that summarizes the 968 conformance requirements of this specification (similar feature sets 969 are provided for XMPP in [RFC6120] and [RFC6121]). This feature set 970 is appropriate for use in software certification, interoperability 971 testing, and implementation reports. For each feature, this section 972 provides the following information: 974 o A human-readable name 976 o An informational description 978 o A reference to the particular section of this document that 979 normatively defines the feature 981 o Whether the feature applies to the Client role, the Server role, 982 or both (where "N/A" signifies that the feature is not applicable 983 to the specified role) 985 o Whether the feature MUST or SHOULD be implemented, where the 986 capitalized terms are to be understood as described in [RFC2119] 988 The feature set specified here provides a basis for interoperability 989 testing and follows the spirit of a proposal made by Larry Masinter 990 within the IETF's NEWTRK Working Group in 2005 [INTEROP]. 992 Feature: address-domain-length 994 Description: Ensure that the domainpart of an XMPP address is at 995 least one octet in length and at most 1023 octets in length, and 996 that it conforms to the underlying length limits of the DNS. 998 Section: Section 4.2 1000 Roles: Server MUST, client SHOULD. 1002 Feature: address-domain-prep 1004 Description: Ensure that the domainpart of an XMPP address conforms 1005 to IDNA2008, that it contains only NR-LDH labels and U-labels (not 1006 A-labels), and that all uppercase and titlecase code points are 1007 mapped to their lowercase equivalents. 1009 Section: Section 4.2 1011 Roles: Server MUST, client SHOULD. 1013 Feature: address-localpart-length 1015 Description: Ensure that the localpart of an XMPP address is at 1016 least one octet in length and at most 1023 octets in length. 1018 Section: Section 4.3 1020 Roles: Server MUST, client SHOULD. 1022 Feature: address-localpart-prep 1024 Description: Ensure that the localpart of an XMPP address conforms 1025 to the "JIDlocalIdentifierClass" profile. 1027 Section: Section 4.3 1029 Roles: Server MUST, client SHOULD. 1031 Feature: address-resource-length 1033 Description: Ensure that the resourcepart of an XMPP address is at 1034 least one octet in length and at most 1023 octets in length. 1036 Section: Section 4.4 1038 Roles: Server MUST, client SHOULD. 1040 Feature: address-resource-prep 1042 Description: Ensure that the resourcepart of an XMPP address 1043 conforms to the "JIDresourceFreeformClass" profile. 1045 Section: Section 4.4 1047 Roles: Server MUST, client SHOULD. 1049 10. References 1051 10.1. Normative References 1053 [I-D.ietf-precis-framework] 1054 Saint-Andre, P. and M. Blanchet, "Precis Framework: 1055 Handling Internationalized Strings in Protocols", draft- 1056 ietf-precis-framework-18 (work in progress), September 1057 2014. 1059 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1060 STD 13, RFC 1034, November 1987. 1062 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1063 Requirement Levels", BCP 14, RFC 2119, March 1997. 1065 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1066 10646", STD 63, RFC 3629, November 2003. 1068 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1069 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1071 [RFC5890] Klensin, J., "Internationalized Domain Names for 1072 Applications (IDNA): Definitions and Document Framework", 1073 RFC 5890, August 2010. 1075 [RFC5891] Klensin, J., "Internationalized Domain Names in 1076 Applications (IDNA): Protocol", RFC 5891, August 2010. 1078 [RFC5892] Faltstrom, P., "The Unicode Code Points and 1079 Internationalized Domain Names for Applications (IDNA)", 1080 RFC 5892, August 2010. 1082 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 1083 Internationalized Domain Names for Applications (IDNA)", 1084 RFC 5893, August 2010. 1086 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1087 Protocol (XMPP): Core", RFC 6120, March 2011. 1089 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 1090 6.3", 2013, 1091 . 1093 [UTR36] The Unicode Consortium, "Unicode Technical Report #36: 1094 Unicode Security Considerations", November 2013, 1095 . 1097 10.2. Informative References 1099 [I-D.ietf-precis-mappings] 1100 Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS 1101 classes", draft-ietf-precis-mappings-08 (work in 1102 progress), June 2014. 1104 [I-D.ietf-precis-nickname] 1105 Saint-Andre, P., "Preparation and Comparison of 1106 Nicknames", draft-ietf-precis-nickname-09 (work in 1107 progress), January 2014. 1109 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 1110 Reporting", Work in Progress, October 2005. 1112 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1113 and Support", STD 3, RFC 1123, October 1989. 1115 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 1116 With Widely Deployed DNS Software", RFC 1535, October 1117 1993. 1119 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1120 Internationalized Strings ("stringprep")", RFC 3454, 1121 December 2002. 1123 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1124 "Internationalizing Domain Names in Applications (IDNA)", 1125 RFC 3490, March 2003. 1127 See Section 1 for an explanation of why the normative 1128 reference to an obsoleted specification is needed. 1130 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1131 Protocol (XMPP): Core", RFC 3920, October 2004. 1133 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1134 Protocol (XMPP): Instant Messaging and Presence", RFC 1135 3921, October 2004. 1137 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1138 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1139 3986, January 2005. 1141 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1142 Identifiers (IRIs)", RFC 3987, January 2005. 1144 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1145 Security Layer (SASL)", RFC 4422, June 2006. 1147 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 1148 (IRIs) and Uniform Resource Identifiers (URIs) for the 1149 Extensible Messaging and Presence Protocol (XMPP)", RFC 1150 5122, February 2008. 1152 [RFC5894] Klensin, J., "Internationalized Domain Names for 1153 Applications (IDNA): Background, Explanation, and 1154 Rationale", RFC 5894, August 2010. 1156 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1157 Internationalized Domain Names in Applications (IDNA) 1158 2008", RFC 5895, September 2010. 1160 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1161 Protocol (XMPP): Instant Messaging and Presence", RFC 1162 6121, March 2011. 1164 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 1165 Protocol (XMPP): Address Format", RFC 6122, March 2011. 1167 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1168 Internationalization in the IETF", BCP 166, RFC 6365, 1169 September 2011. 1171 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 1172 Problem Statement for the Preparation and Comparison of 1173 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 1175 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 1176 Unicode Security Mechanisms", July 2012, 1177 . 1179 [XEP-0004] 1180 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 1181 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 1183 [XEP-0016] 1184 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 1185 0016, February 2007. 1187 [XEP-0029] 1188 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 1189 XEP 0029, October 2003. 1191 [XEP-0030] 1192 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1193 Andre, "Service Discovery", XSF XEP 0030, June 2008. 1195 [XEP-0045] 1196 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 1197 2012. 1199 [XEP-0048] 1200 Blackman, R., Millard, P., and P. Saint-Andre, 1201 "Bookmarks", XSF XEP 0048, November 2007. 1203 [XEP-0054] 1204 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 1206 [XEP-0060] 1207 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1208 Subscribe", XSF XEP 0060, July 2010. 1210 [XEP-0065] 1211 Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, 1212 "SOCKS5 Bytestreams", XSF XEP 0065, April 2011. 1214 [XEP-0077] 1215 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 1216 January 2012. 1218 [XEP-0106] 1219 Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 1220 0106, June 2007. 1222 [XEP-0114] 1223 Saint-Andre, P., "Jabber Component Protocol", XSF XEP 1224 0114, March 2005. 1226 [XEP-0144] 1227 Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, 1228 August 2005. 1230 [XEP-0165] 1231 Saint-Andre, P., "Best Practices to Discourage JID 1232 Mimicking", XSF XEP 0165, December 2007. 1234 [XEP-0166] 1235 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 1236 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 1237 2009. 1239 [XEP-0191] 1240 Saint-Andre, P., "Blocking Command", XSF XEP 0191, July 1241 2012. 1243 [XEP-0203] 1244 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 1245 September 2009. 1247 [XEP-0220] 1248 Miller, J., Saint-Andre, P., and P. Hancke, "Server 1249 Dialback", XSF XEP 0220, August 2012. 1251 [XEP-0292] 1252 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 1253 0292, October 2011. 1255 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 1256 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 1257 Edition)", World Wide Web Consortium Recommendation REC- 1258 xml-20081126, November 2008, 1259 . 1261 Appendix A. Differences from RFC 6122 1263 Based on consensus derived from working group discussion, 1264 implementation and deployment experience, and formal interoperability 1265 testing, the following substantive modifications were made from RFC 1266 6122. 1268 o Changed domainpart preparation to use IDNA2008 (instead of 1269 IDNA2003). 1271 o Changed localpart preparation to use the JIDlocalIdentifierClass 1272 profile of the PRECIS IdentifierClass (instead of the Nodeprep 1273 profile of Stringprep). 1275 o Changed resourcepart preparation to use the 1276 JIDresourceFreeformClass profile of the PRECIS FreeformClass 1277 (instead of the Resourceprep profile of Stringprep). 1279 o Specified that internationalized labels within domainparts must be 1280 U-labels (instead of "should be" U-labels). 1282 o Specified that fullwidth and halfwidth characters must be mapped 1283 to their decomposition mappings (previously handled through the 1284 use of NFKC). 1286 o Specified the use of Unicode Normalization Form C (instead of 1287 Unicode Normalization Form KC as specified in the Nodeprep and 1288 Resourceprep profiles of Stringprep). 1290 o Specified that servers must enforce the address formatting rules. 1292 Appendix B. Acknowledgements 1294 Thanks to Miguel Garcia, Joe Hildebrand, Matt Miller, and Florian 1295 Zeitz for their feedback. 1297 Some text in this document was borrowed or adapted from [RFC5890], 1298 [RFC5891], [RFC5894], and [XEP-0165]. 1300 Author's Address 1302 Peter Saint-Andre 1303 &yet 1304 P.O. Box 787 1305 Parker, CO 80134 1306 USA 1308 Email: peter@andyet.net