idnits 2.17.1 draft-saintandre-xmpp-i18n-03.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 (March 14, 2011) is 4785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-blanchet-precis-framework-00 == Outdated reference: A later version (-09) exists of draft-ietf-precis-problem-statement-01 -- 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 3491 (Obsoleted by 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) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: Informational March 14, 2011 5 Expires: September 15, 2011 7 Internationalized Addresses in XMPP 8 draft-saintandre-xmpp-i18n-03 10 Abstract 12 The Extensible Messaging and Presence Protocol (XMPP) as defined in 13 RFC 3920 used stringprep in the preparation and comparison of non- 14 ASCII characters within XMPP addresses. This document explores a 15 post-stringprep approach to XMPP addresses. 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 September 15, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Proposed PRECIS String Classes . . . . . . . . . . . . . . . . 4 53 2.1. Domaineythings . . . . . . . . . . . . . . . . . . . . . . 5 54 2.2. Nameythings . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3. Wordythings . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.4. Stringythings . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Subclassing . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. XMPP Use of PRECIS String Classes . . . . . . . . . . . . . . 8 60 5.1. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. XMPP Migration Issues . . . . . . . . . . . . . . . . . . . . 9 63 7. XMPP Protocol Slots . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. JID Slot . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.2. Localpart Slot . . . . . . . . . . . . . . . . . . . . . . 10 66 7.3. Resourcepart Slot . . . . . . . . . . . . . . . . . . . . 11 67 7.4. Wordything Slot . . . . . . . . . . . . . . . . . . . . . 11 68 7.5. Stringything Slot . . . . . . . . . . . . . . . . . . . . 11 69 8. XMPP Error Handling . . . . . . . . . . . . . . . . . . . . . 11 70 9. XMPP User Interface Issues . . . . . . . . . . . . . . . . . . 12 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 74 13. Informative References . . . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 The Extensible Messaging and Presence Protocol [RFC6120] is a widely- 80 deployed technology for real-time communication, commonly used for 81 instant messaging (IM) among human users but also for communication 82 among automated systems. XMPP addresses (also called "JabberIDs" or 83 JIDs) are of the form , where the 84 localpart and resourcepart are formally optional but quite common 85 because they are used to identify clients and other entities on the 86 network. In some sense, XMPP addresses have always been 87 internationalized, because the developers of the original Jabber 88 open-source project intended that all data sent over the wire would 89 consist of UTF-8 encoded Unicode code points. However, at that time 90 (1999) the Jabber developers were quite unsophisticated about 91 internationalization, nor could they simply re-use a reliable 92 internationalization technology that had been developed by the wider 93 Internet community (as they could, for example, by re-using Secure 94 Sockets Layer and Transport Layer Security for channel encryption); 95 this lack of sophistication is evident in the community's first 96 attempt at formally defining the format for JabberIDs in early 2002 97 [XEP-0029]. 99 When the first instantiation of the IETF's XMPP WG was formed in late 100 2002, IDNA2003 [RFC3490] had not yet been published and stringprep 101 [RFC3454] was a new technology. During its work on [RFC3920], the 102 XMPP WG absorbed as best it could the advice of internationalization 103 experts regarding appropriate methods for preparing and comparing 104 XMPP addresses; however, the participants in the XMPP WG were 105 ignorant of internationalization and therefore did not necessarily 106 make fully-informed decisions. As a result of this early work, in 107 [RFC3920] the XMPP WG decided to re-use IDNA2003 [RFC3490] and 108 Nameprep [RFC3491] for the domainpart of a JID and to define two 109 additional stringprep profiles: Nodeprep for the localpart and 110 Resourceprep for the resourecepart. 112 Since the publication of [RFC3920] in 2004, the Internet community 113 has gained more experience with internationalization. In particular, 114 IDNA2003, which is based on stringprep, has been superseded by 115 IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894]), 116 which does not use stringprep. This migration away from stringprep 117 for internationalized domain names has prompted other "customers" of 118 stringprep to consider new approaches to the preparation and 119 comparison of internationalized addresses. As a result, the IETF has 120 formed the PRECIS WG as a common forum for seeking solutions to the 121 problem statement outlined in [PROBLEM]. 123 This document has two purposes: (1) provide input to the PRECIS WG 124 and (2) help inform the decisions of the XMPP WG regarding 125 internationalization of XMPP addresses, eventually leading to 126 replacement of [RFC6122]. Note well that so far this document 127 present only the author's opinions, and that it does not reflect the 128 consensus of the XMPP WG or the PRECIS WG. 130 2. Proposed PRECIS String Classes 132 Both [PROBLEM] and [FRAMEWORK] propose that it might be valuable to 133 think of internationalized addresses in terms of broad "string 134 classes". Application technologies like XMPP could either borrow 135 such a string class unchanged or "profile" such a string class with 136 modifications. 138 This document does not yet make recommendations about borrowing or 139 adapting more general string classes, in part because those classes 140 are not yet clearly defined. However, as input to further 141 discussion, this document explores four string classes that are used 142 in XMPP: 144 o Domain names. These are defined in IDNA specification and re-used 145 in XMPP and other applications. However, additional guidelines 146 might be helpful for applications (or at least for XMPP) to fill 147 the gap between what was provided in IDNA2003 (such as 148 normalization and various mapping steps) and what is now provided 149 in IDNA2008. For consistency with the next three string classes 150 we call these "domaineythings". 152 o Username-like things. Such a "nameything" is a word or set of 153 words that is used to identify or address a network entity such as 154 a user, an account, a venue (e.g., a chatroom), an information 155 source (e.g., a feed), or a collection of data (e.g., a file). An 156 XMPP localpart is a kind of nameything, but might profile a base 157 definition of nameythings developed by the PRECIS WG. 159 o Password-like things. Such a "wordything" is a sequence of 160 letters, numbers, and symbols that is used as a secret for access 161 to some resource on a network (e.g., an account or a venue). In 162 XMPP, wordythings are often used by clients to authenticate with 163 servers, as provided in various SASL mechanisms. 165 o Free-form things. Such a "stringything" is a sequence of letters, 166 numbers, symbols, spaces, and other code points that is used for 167 more expressive purposes in an application protocol. An XMPP 168 resourcepart is a kind of stringything, but might profile a base 169 definition of stringythings developed by the PRECIS WG. 171 The following subsections discuss these string classes in more 172 detail, with reference to the properties described in Section 3 of 173 [PROBLEM] (input restrictions, normalization, case mapping, and 174 bidirectionality). 176 2.1. Domaineythings 178 The IDNA2008 protocol is defined in [RFC5890], [RFC5891], [RFC5892], 179 [RFC5893], and [RFC5894]. However, IDNA2008 covers a smaller range 180 of topics than IDNA2003 [RFC3490]. In particular, normalization and 181 mappings are out of scope for IDNA2008 (although one possible 182 approach is described informationally in [RFC5895]). The XMPP WG, or 183 even the PRECIS WG, might want to choose a normalization form and a 184 set of mappings that would be recommended or required for use on the 185 wire, despite the fact that these matters were not specified in a 186 normative way for IDNA2008. This is especially important in modern 187 application protocols that communicate using UTF-8-encoded Unicode 188 code points instead of 8-bit or 7-bit ASCII (as in older application 189 protocols such as [RFC5322]). 191 2.2. Nameythings 193 Most application technologies need a special class of strings that 194 can be used to include or communicate things like usernames, chatroom 195 names, file names, and data feed names. We group such things into a 196 bucket called "nameythings". Ideally, the PRECIS WG would define a 197 "nameything" class that could be profiled by various application 198 technologies. We suggest that the base class would have the 199 following features: 201 o Control characters (e.g., U+0000 through U+001F) would be 202 disallowed. 203 o Space characters (U+0020, along with any code point having a 204 GeneralCategory of Zs) would be disallowed. 205 o All other 7-bit ASCII characters (i.e., U+0021 through U+007E) 206 would be protocol-valid, even if their Unicode GeneralCategory is 207 disallowed by the rules specified below. 208 o As with IDNA2008, any character that has a compatibility 209 equivalent would be disallowed. 210 o Uppercase and titlecase code points would be mapped to their 211 lowercase equivalents. 212 o The normalization form would be NFD (see below). 213 o Profiles of the base class would be able to exclude specific code 214 points that are included in the base. 215 o Profiles of the base class would be able to exclude character 216 classes with other properties (e.g., math symbols) that are 217 included in the base. 219 OPEN ISSUE: Should symbol characters outside the 7-bit ASCII range be 220 disallowed? 222 OPEN ISSUE: How to handle right-to-left code points? It might be 223 reasonable to simply use the "Bidi Rule" from [RFC5893], however "." 224 is allowed in nameythings and the Bidi Rule is probably too complex 225 for our purposes because domaineythings have internal structure 226 (based around the "." character) whereas nameythings do not. 228 2.3. Wordythings 230 Many application technologies need a special class of strings that 231 can be used to communicate secrets that are typically used as 232 passwords or passphrases. We group such things into a bucket called 233 "wordythings". Ideally, the PRECIS WG would define a "wordything" 234 class that could be profiled by various application technologies. We 235 suggest that the base class would have the following features: 237 o Control characters (e.g., U+0000 through U+001F) would be 238 disallowed. 239 o Space characters (U+0020, along with any code point having a 240 GeneralCategory of Zs) would be disallowed. 241 o All other 7-bit ASCII characters (i.e., U+0021 through U+007E) 242 would be protocol-valid, even if their Unicode GeneralCategory is 243 disallowed by the rules specified below. 244 o Any character that has a compatibility equivalent would be 245 disallowed. 246 o In order to maximize the entropy of passwords and passphrases, 247 uppercase and titlecase code points would be protocol-valid and 248 would not be mapped to their lowercase equivalents. 249 o The normalization form would be NFD (see below). 250 o Profiles of the base class would be able to exclude specific code 251 points that are included in the base. 252 o Profiles of the base class would be able to exclude character 253 classes with other properties (e.g., math symbols) that are 254 included in the base. 256 Although some application protocols use passwords and passphrases 257 directly, others re-use technologies that themselves use passwords in 258 some deployments (e.g., this is true of XMPP, which re-uses Simple 259 Authentication and Security Layer or SASL [RFC4422]). 261 2.4. Stringythings 263 Some application technologies need a special class of strings that 264 can be used in a free-form way. We group such things into a bucket 265 called "stringythings". Ideally, the PRECIS WG would define a 266 "stringything" class that could be profiled by various application 267 technologies. We suggest that the base class would have the 268 following features: 270 o Control characters (e.g., U+0000 through U+001F) would be 271 disallowed. 272 o Space characters (U+0020, along with any code point having a 273 GeneralCategory of Zs) would be protocol-valid. 274 o All other 7-bit ASCII characters (i.e., U+0021 through U+007E) 275 would be protocol-valid, even if their Unicode GeneralCategory is 276 disallowed by the rules specified below. 277 o Characters with compatibility equivalents would be protocol-valid. 278 o Uppercase and titlecase code points would protocol-valid and would 279 not be mapped to their lowercase equivalents. 280 o The normalization form would be NFD (see below). 281 o Profiles of the base class would be able to exclude specific code 282 points that are included in the base. 283 o Profiles of the base class would be able to exclude character 284 classes with other properties (e.g., math symbols) that are 285 included in the base. 287 OPEN ISSUE: How to handle right-to-left code points? It might be 288 reasonable to simply use the "Bidi Rule" from [RFC5893], however "." 289 is allowed in stringythings and the Bidi Rule is probably too complex 290 for our purposes because domaineythings have internal structure 291 (based around the "." character) whereas stringythings do not. 293 3. Normalization 295 Following IDNA2003, existing stringprep profiles all use Unicode 296 Normalization Form KC (NFKC), which performs canonical decomposition 297 and compatibility decomposition, followed by canonical and 298 compatibility recomposition (regarding normalization forms, see 299 [UAX15]). This choice made sense in IDNA2003 because the DNS packet 300 format has fixed-length labels, and NFKC in effect compresses a 301 sequence of characters into the smallest number of bytes possible by 302 performing recomposition. However, experience with some of the 303 application protocols that are currently using NFKC has shown that 304 recomposition is an expensive operation to perform in application 305 servers. In addition, the application protocols that use stringprep 306 all use TCP with security-layer or application-layer compression, so 307 fixing the length of strings is much less important. 309 What matters most in application protocols is ensuring that network 310 entities (such as clients and servers) all communicate a consistent 311 string representation over the wire. For this purpose, Normalization 312 Form D (NFD), which simply performs canonical decomposition, provides 313 the most efficient approach. As noted above, we can disallow any 314 characters that would require compatibility decomposition, thus 315 removing the need for compatibility decomposition and recomposition. 316 This is what happened in IDNA2008, enabling IDNA technologies to move 317 from NFKC to NFC. If the same basic approach is taken in the PRECIS 318 WG, while at the same time removing the need for recomposition 319 entirely (by making code points with compatibility equivalents), NFKC 320 (the most complex and therefore most computationally intensive 321 normalization form) can be replaced with NFD (the least complex and 322 therefore least computationally intensive normalization form). 323 Another relevant factor is that NFD(x) = NFD(NFD(x)), which means 324 that application servers can be optimized for the case where the 325 normalization has already occurred. In general, using NFD will 326 likely result in significant performance improvements within 327 application servers. 329 4. Subclassing 331 The opportunity for subclassing PRECIS string classes opens the 332 possibility that different applications technologies will subclass a 333 given class in different ways. For example, imagine that the XMPP 334 community defines a detailed subclass of "nameything" that is 335 optimized for the comparison of JabberIDs. However, the email 336 community might do the same for email addresses. At that point, the 337 XMPP comparison methods might diverge significantly from the mail 338 comparison methods, leading to interoperability problems if a given 339 deployment makes use of the same usernames for both JabberIDs and 340 email addresses. The PRECIS WG needs to consider these matters and 341 find a productive balance between compatibility within an application 342 technology and interoperability across application technologies. 344 5. XMPP Use of PRECIS String Classes 346 5.1. Localpart 348 The localpart of an XMPP address would be redefined as a profile or 349 subclass of the PRECIS "nameything" class. The following additional 350 restrictions would apply: 352 o Space characters (U+0020, along with any code point having a 353 GeneralCategory of Zs) would be disallowed. 354 o The following Unicode code points would be disallowed: U+0022 ("), 355 U+0026 (&), U+0027 ('), U+002F (/), U+003A (:), U+003C (<), U+003E 356 (>), U+0040 (@). 358 OPEN ISSUE: Should symbol characters outside the 7-bit ASCII range be 359 disallowed? 361 5.2. Resourcepart 363 The resourcepart of an XMPP address would be redefined as a profile 364 or subclass of the PRECIS "stringything" class, or might even simply 365 use the identity subclass of "stringything". 367 6. XMPP Migration Issues 369 Any move away from Nameprep, Nodeprep, and Resourceprep as they are 370 defined today will inevitably introduce the potential for migration 371 issues, such as JIDs that were not ambiguous before the migration but 372 that become ambiguous after the migration. These issues need to be 373 clearly defined and well understood so that the costs and benefits of 374 any change can be properly assessed -- especially if the change might 375 have an impact on authentication (e.g., as described in [RFC3920]), 376 authorization (e.g., presence subscriptions as described in 377 [RFC6121]), access (e.g., joining a chatroom as described in 378 [XEP-0045]), identification (e.g., in XMPP URIs or IRIs as described 379 in [RFC5122]), and other security-related functions. 381 7. XMPP Protocol Slots 383 IDNA2008 defined the concept of a "domain name slot", i.e., "a 384 protocol element or a function argument or a return value (and so on) 385 explicitly designated for carrying a domain name" (Section 2.3.2.6 of 386 [RFC5890]). Similarly, the XMPP community can define the concepts of 387 a "JID slot", a "localpart slot", and a "resourcepart slot" (and 388 might re-use the concepts of a "nameything slot", "wordything slot", 389 and "stringything slot" from PRECIS specifications). The community 390 has yet to determine the full inventory of such slots. However, the 391 following subsections provide a start at such an inventory. 393 7.1. JID Slot 395 In XMPP systems, JabberIDs can appear in at least the following 396 slots: 398 o Core [RFC6120]: the 'from' and 'to' stream attributes; the 'from' 399 and 'to' stanza attributes. 400 o IM [RFC6121]: the 'jid' attribute of the roster element. 401 o Privacy Lists [RFC3921], [XEP-0016]: the 'value' attribute of the 402 element when the value of the 'type' attribute is "jid". 403 o Data Forms [XEP-0004]: the element when the 'type' 404 attribute is "jid-single" or "jid-multi". 406 o Flexible Offline Message Retrieval [XEP-0013]: the 'jid' attribute 407 of the element. 408 o Service Discovery [XEP-0030]: the 'jid' attribute of the 409 element. 410 o Extended Stanza Addressing [XEP-0033]: the 'jid' attribute of the 411
element. 412 o Multi-User Chat [XEP-0045]: the 'actor' child of the 413 element; the 'jid' attribute of the element; the 'from' 414 and 'to' attributes of the and elements; the 415 'jid' attribute of the element. 416 o Bookmarks [XEP-0048]: the 'jid' attribute of the 417 element. 418 o vCards [XEP-0054]: the of the element. 419 o Jabber Search [XEP-0055]: the 'jid' attribute of the 420 element. 421 o Publish-Subscribe [XEP-0060]: the 'jid' attribute of the 422 , , , , and 423 elements; the 'publisher' attribute of the 424 element. 425 o SOCKS5 Bytestreams [XEP-0065]: the 'jid' attribute of the 426 and elements. 427 o Advanced Message Processing [XEP-0079]: the 'from' and 'to' 428 attributes of the element. 429 o Jabber Component Protocol [XEP-0114]: the 'from' and 'to' 430 attributes of the , , and elements. 431 o Message Archiving [XEP-0136]: the 'with' attribute of the , 432 , and elements. 433 o Roster Item Exchange [XEP-0144]: the 'jid' attribute of the 434 element. 435 o Jingle [XEP-0166]: the 'initiator' and 'responder' attributes of 436 the element. 437 o Delayed Delivery [XEP-0203]: the 'from' attribute of the 438 element. 439 o Simple Communications Blocking [XEP-0191]: the 'jid' attribute of 440 the element. 441 o Server Dialback [RFC3921], [XEP-0220]: the 'from' and 'to' 442 attributes of the and elements. 443 o Direct MUC Invitations [XEP-0249]: the 'jid' attribute of the 444 element. 446 7.2. Localpart Slot 448 In XMPP systems, localparts can appear in at least the following 449 slots: 451 o Multi-User Chat [XEP-0045]: the element. 453 o In-Band Registration [XEP-0077]: the element. 455 7.3. Resourcepart Slot 457 In XMPP systems, resourceparts can appear in at least the following 458 slots: 460 o Core [RFC6120]: the child of the element. 461 o Multi-User Chat [XEP-0045]: the 'nick' attribute of the 462 element. 463 o Bookmarks [XEP-0048]: the 'nick' attribute of the 464 element. 465 o Jabber Search [XEP-0055]: the 'nick' attribute of the and 466 elements. 467 o Publish-Subscribe [XEP-0060]: the 'node' attribute of the 468
element (this might actually be a "stringything slot" 469 but typically it is handled as a resourcepart). 471 7.4. Wordything Slot 473 In XMPP systems, generic "wordythings" can appear in at least the 474 following slots: 476 o Multi-User Chat [XEP-0045]: the child of the 477 and elements. 478 o Bookmarks [XEP-0048]: the 'password' attribute of the 479 element. 480 o Direct MUC Invitations [XEP-0249]: the 'password' attribute of the 481 element. 483 7.5. Stringything Slot 485 In XMPP systems, generic "stringythings" can appear in at least the 486 following slots: 488 o Flexible Offline Message Retrieval [XEP-0013]: the 'node' 489 attribute of the element. 490 o Extended Stanza Addressing [XEP-0033]: the 'node' attribute of the 491
element. 492 o Publish-Subscribe [XEP-0060]: the 'node' attribute of various XML 493 elements. 495 8. XMPP Error Handling 497 Both the core XMPP specifications and various XMPP extensions might 498 need to define more robust error handling. Although this topic has 499 yet to be explored in detail, it is likely that specifications can 500 more widely use the existing error condition defined 501 in [RFC6120]. 503 9. XMPP User Interface Issues 505 [RFC5895] introduces the helpful concept of "the dividing line 506 between user interface and protocol" and applies that concept to the 507 complexs process of translating the user's (presumed) intentions into 508 bits on the wire. IDNA2003 conflated user interface processing and 509 machine-readable protocols, and in many ways XMPP inherited that same 510 error. It would be desirable for XMPP technologies to define a clear 511 dividing line between user interface and protocol. This might mean 512 that the XMPP community will need to define recommended mappings that 513 are applied to a string before it is considered a JID (or the 514 localpart of resourcepart of a JID). 516 10. Security Considerations 518 The inclusion of non-ASCII characters in XMPP addresses has important 519 security implications, such as the ability to mimic characters or 520 entire addresses through the inclusion of "confusable characters" 521 (see [RFC4690] and [RFC5890]). These issues are explored at some 522 length in [RFC6122]. Other security considerations might apply and 523 will be described in a future version of this specification. 525 11. IANA Considerations 527 This document defines no actions for the IANA. 529 12. Acknowledgements 531 Special thanks to Joe Hildebrand for extensive discussions about 532 internationalization and XMPP. Many participants in the XMPP WG 533 Interim Meeting in February 2011 provided valuable feedback. Thanks 534 also to Jack Erwin, Matt Miller, and Tory Patnoe for additional 535 discussions. 537 13. Informative References 539 [FRAMEWORK] 540 Blanchet, M., "Precis Framework: Handling 541 Internationalized Strings in Protocols", 542 draft-blanchet-precis-framework-00 (work in progress), 543 July 2010. 545 [PROBLEM] Blanchet, M. and A. Sullivan, "Stringprep Revision Problem 546 Statement", draft-ietf-precis-problem-statement-01 (work 547 in progress), December 2010. 549 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 550 Internationalized Strings ("stringprep")", RFC 3454, 551 December 2002. 553 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 554 "Internationalizing Domain Names in Applications (IDNA)", 555 RFC 3490, March 2003. 557 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 558 Profile for Internationalized Domain Names (IDN)", 559 RFC 3491, March 2003. 561 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 562 Protocol (XMPP): Core", RFC 3920, October 2004. 564 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 565 Protocol (XMPP): Instant Messaging and Presence", 566 RFC 3921, October 2004. 568 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 569 Security Layer (SASL)", RFC 4422, June 2006. 571 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 572 Recommendations for Internationalized Domain Names 573 (IDNs)", RFC 4690, September 2006. 575 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 576 (IRIs) and Uniform Resource Identifiers (URIs) for the 577 Extensible Messaging and Presence Protocol (XMPP)", 578 RFC 5122, February 2008. 580 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 581 October 2008. 583 [RFC5890] Klensin, J., "Internationalized Domain Names for 584 Applications (IDNA): Definitions and Document Framework", 585 RFC 5890, August 2010. 587 [RFC5891] Klensin, J., "Internationalized Domain Names in 588 Applications (IDNA): Protocol", RFC 5891, August 2010. 590 [RFC5892] Faltstrom, P., "The Unicode Code Points and 591 Internationalized Domain Names for Applications (IDNA)", 592 RFC 5892, August 2010. 594 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 595 Internationalized Domain Names for Applications (IDNA)", 596 RFC 5893, August 2010. 598 [RFC5894] Klensin, J., "Internationalized Domain Names for 599 Applications (IDNA): Background, Explanation, and 600 Rationale", RFC 5894, August 2010. 602 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 603 Internationalized Domain Names in Applications (IDNA) 604 2008", RFC 5895, September 2010. 606 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 607 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-22 (work 608 in progress), December 2010. 610 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 611 Protocol (XMPP): Instant Messaging and Presence", 612 draft-ietf-xmpp-3921bis-20 (work in progress), 613 January 2011. 615 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 616 Protocol (XMPP): Address Format", 617 draft-ietf-xmpp-address-09 (work in progress), 618 January 2011. 620 [UAX15] The Unicode Consortium, "Unicode Standard Annex #15: 621 Unicode Normalization Forms", September 2010. 623 [XEP-0004] 624 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 625 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 627 [XEP-0013] 628 Saint-Andre, P. and C. Kaes, "Flexible Offline Message 629 Retrieval", XSF XEP 0013, July 2005. 631 [XEP-0016] 632 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF 633 XEP 0016, February 2007. 635 [XEP-0029] 636 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 637 XEP 0029, October 2003. 639 [XEP-0030] 640 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 641 Andre, "Service Discovery", XSF XEP 0030, June 2008. 643 [XEP-0033] 644 Hildebrand, J. and P. Saint-Andre, "Extended Stanza 645 Addressing", XSF XEP 0033, September 2004. 647 [XEP-0045] 648 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 649 July 2008. 651 [XEP-0048] 652 Blackman, R., Millard, P., and P. Saint-Andre, 653 "Bookmarks", XSF XEP 0048, November 2007. 655 [XEP-0054] 656 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 658 [XEP-0055] 659 Saint-Andre, P., "Jabber Search", XSF XEP 0055, 660 September 2009. 662 [XEP-0060] 663 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 664 Subscribe", XSF XEP 0060, July 2010. 666 [XEP-0065] 667 Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, 668 "SOCKS5 Bytestreams", XSF XEP 0065, April in progress, 669 last updated 2010. 671 [XEP-0077] 672 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 673 September 2009. 675 [XEP-0079] 676 Miller, M. and P. Saint-Andre, "Advanced Message 677 Processing", XSF XEP 0079, November 2005. 679 [XEP-0114] 680 Saint-Andre, P., "Jabber Component Protocol", XSF 681 XEP 0114, March 2005. 683 [XEP-0136] 684 Paterson, I., Perlow, J., Saint-Andre, P., Karneges, J., 685 Tsvyashchenko, A., and Y. Leboulanger, "Message 686 Archiving", XSF XEP 0136, June 2010. 688 [XEP-0144] 689 Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, 690 August 2005. 692 [XEP-0166] 693 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 694 S., and J. Hildebrand, "Jingle", XSF XEP 0166, 695 December 2009. 697 [XEP-0191] 698 Saint-Andre, P., "Simple Communications Blocking", XSF 699 XEP 0191, February 2007. 701 [XEP-0203] 702 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 703 September 2009. 705 [XEP-0220] 706 Miller, J., Saint-Andre, P., and P. Hancke, "Server 707 Dialback", XSF XEP 0220, March 2010. 709 [XEP-0249] 710 Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249, 711 December 2009. 713 Author's Address 715 Peter Saint-Andre 716 Cisco 717 1899 Wyknoop Street, Suite 600 718 Denver, CO 80202 719 USA 721 Phone: +1-303-308-3282 722 Email: psaintan@cisco.com