idnits 2.17.1 draft-ietf-xmpp-6122bis-20.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 23, 2015) is 3321 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 (-18) exists of draft-ietf-precis-saslprepbis-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR36' == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-16 -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP P. Saint-Andre 3 Internet-Draft &yet 4 Obsoletes: 6122 (if approved) March 23, 2015 5 Intended status: Standards Track 6 Expires: September 24, 2015 8 Extensible Messaging and Presence Protocol (XMPP): Address Format 9 draft-ietf-xmpp-6122bis-20 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 September 24, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6 58 3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3.1. Further Excluded Characters . . . . . . . . . . . . . 7 61 3.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4.1. Applicability to XMPP Extensions . . . . . . . . . . 9 63 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Enforcement in JIDs and JID Parts . . . . . . . . . . . . . . 13 65 5. Internationalization Considerations . . . . . . . . . . . . . 15 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 6.1. Stringprep Profiles Registry . . . . . . . . . . . . . . 15 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 7.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 16 70 7.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 16 71 7.3. Address Spoofing . . . . . . . . . . . . . . . . . . . . 16 72 7.3.1. Address Forging . . . . . . . . . . . . . . . . . . . 16 73 7.3.2. Address Mimicking . . . . . . . . . . . . . . . . . . 17 74 8. Conformance Requirements . . . . . . . . . . . . . . . . . . 18 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 9.2. Informative References . . . . . . . . . . . . . . . . . 21 78 Appendix A. Differences from RFC 6122 . . . . . . . . . . . . . 24 79 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is an 85 application profile of the Extensible Markup Language [XML] for 86 streaming XML data in close to real time between any two or more 87 network-aware entities. The address format for XMPP entities was 88 originally developed in the Jabber open-source community in 1999, 89 first described by [XEP-0029] in 2002, and then defined canonically 90 by [RFC3920] in 2004 and [RFC6122] in 2011. 92 As specified in RFC 3920 and RFC 6122, the XMPP address format used 93 the "stringprep" technology for preparation and comparison of non- 94 ASCII characters [RFC3454]. Following the migration of 95 internationalized domain names away from stringprep, this document 96 defines the XMPP address format in a way that no longer depends on 97 stringprep (see the PRECIS problem statement [RFC6885]). Instead, 98 this document builds upon the internationalization framework defined 99 by the IETF's PRECIS Working Group [I-D.ietf-precis-framework]. 101 Although every attempt has been made to ensure that the characters 102 allowed in Jabber Identifiers (JIDs) under Stringprep are still 103 allowed and handled in the same way under PRECIS, there is no 104 guarantee of strict backward compatibility because of changes in 105 Unicode and the fact that PRECIS handling is based on Unicode 106 properties, not a hardcoded table of characters. Because it is 107 possible that previously-valid JIDs might no longer be valid (or 108 previously-invalid JIDs might now be valid), operators of XMPP 109 services are advised to perform careful testing before migrating 110 accounts and other data. 112 This document obsoletes RFC 6122. 114 2. Terminology 116 Many important terms used in this document are defined in 117 [I-D.ietf-precis-framework], [RFC5890], [RFC6120], [RFC6365], and 118 [UNICODE]. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 3. Addresses 127 3.1. Fundamentals 129 An XMPP entity is anything that can communicate using XMPP. For 130 historical reasons, the network address of an XMPP entity is called a 131 Jabber Identifier ("JID"). A valid JID is a string of Unicode code 132 points [UNICODE], encoded using UTF-8 [RFC3629], and structured as an 133 ordered sequence of localpart, domainpart, and resourcepart, where 134 the first two parts are demarcated by the '@' character used as a 135 separator and the last two parts are similarly demarcated by the '/' 136 character (e.g., ). 138 The syntax for a JID is defined as follows using the Augmented 139 Backus-Naur Form (ABNF) as specified in [RFC5234]. 141 jid = [ localpart "@" ] domainpart [ "/" resourcepart ] 142 localpart = 1*1023(userbyte) 143 ; 144 ; a "userbyte" is a byte used to represent a 145 ; UTF-8 encoded Unicode code point that can be 146 ; contained in a string that conforms to the 147 ; "UsernameCaseMapped" profile of the PRECIS 148 ; IdentifierClass 149 ; 150 domainpart = IP-literal / IPv4address / ifqdn 151 ; 152 ; the "IPv4address" and "IP-literal" rules are 153 ; defined in RFC 3986, and the first-match-wins 154 ; (a.k.a. "greedy") algorithm described therein 155 ; applies to the matching process 156 ; 157 ; note well that reuse of the IP-literal rule from 158 ; RFC 3986 implies that IPv6 addresses are enclosed 159 ; in square brackets (i.e., beginning with '[' and 160 ; ending with ']') 161 ; 162 ifqdn = 1*1023(domainbyte) 163 ; 164 ; a "domainbyte" is a byte used to represent a 165 ; UTF-8 encoded Unicode code point that can be 166 ; contained in a string that conforms to RFC 5890 167 ; 168 resourcepart = 1*1023(resourcebyte) 169 ; 170 ; an "opaquebyte" is a byte used to represent a 171 ; UTF-8 encoded Unicode code point that can be 172 ; contained in a string that conforms to the 173 ; "OpaqueString" profile of the PRECIS 174 ; FreeformClass 175 ; 177 All JIDs are based on the foregoing structure. However, note that 178 the formal syntax provided above does not capture all of the rules 179 and restrictions that apply to JIDs, which are described below. 181 Each allowable portion of a JID (localpart, domainpart, and 182 resourcepart) MUST NOT be zero octets in length and MUST NOT be more 183 than 1023 octets in length, resulting in a maximum total size 184 (including the '@' and '/' separators) of 3071 octets. 186 Implementation Note: The length limits on JIDs and parts of JIDs 187 are based on octets (bytes), not characters. UTF-8 encoding can 188 result in more than one octet per character. 190 Implementation Note: When dividing a JID into its component parts, 191 an implementation needs to match the separator characters '@' and 192 '/' before applying any transformation algorithms, which might 193 decompose certain Unicode code points to the separator characters 194 (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL 195 AT decomposes to U+0040 COMMERCIAL AT, although note that this 196 decomposition does not occur under Unicode Normalization Form C, 197 which is used in this specification). 199 This document defines the native format for JIDs; see [RFC5122] for 200 information about the representation of a JID as a Uniform Resource 201 Identifier (URI) [RFC3986] or Internationalized Resource Identifier 202 (IRI) [RFC3987] and the extraction of a JID from an XMPP URI or IRI. 204 3.2. Domainpart 206 The domainpart of a JID is that portion which remains once any 207 portion from the first '/' character to the end of the string has 208 been removed (if there is a '/' character present), and then any 209 portion from the beginning of the string to the first '@' character 210 (if there is a '@' character present). The domainpart is the primary 211 identifier and is the only REQUIRED element of a JID (a mere 212 domainpart is a valid JID). Typically a domainpart identifies the 213 "home" server to which clients connect for XML routing and data 214 management functionality. However, it is not necessary for an XMPP 215 domainpart to identify an entity that provides core XMPP server 216 functionality (e.g., a domainpart can identify an entity such as a 217 multi-user chat service [XEP-0045], a publish-subscribe service 218 [XEP-0060], or a user directory). 220 The domainpart for every XMPP service MUST be a fully-qualified 221 domain name (FQDN), an IPv4 address, an IPv6 address, or an 222 unqualified hostname (i.e., a text label that is resolvable on a 223 local network). 225 Informational Note: The term "fully-qualified domain name" is not 226 well defined. In [RFC1034] it is also called an absolute domain 227 name, and the two terms are associated in [RFC1535]. The earliest 228 use of the term can be found in [RFC1123]. References to those 229 older specifications ought not to be construed as limiting the 230 characters of a fully-qualified domain name to the ASCII range; 231 for example, [RFC5890] mentions that a fully-qualified domain name 232 can contain one or more U-labels. 234 Interoperability Note: Domainparts that are IP addresses might not 235 be accepted by other services for the purpose of server-to-server 236 communication, and domainparts that are unqualified hostnames 237 cannot be used on public networks because they are resolvable only 238 on a local network. 240 If the domainpart includes a final character considered to be a label 241 separator (dot) by [RFC1034], this character MUST be stripped from 242 the domainpart before the JID of which it is a part is used for the 243 purpose of routing an XML stanza, comparing against another JID, or 244 constructing an XMPP URI or IRI [RFC5122]. In particular, such a 245 character MUST be stripped before any other canonicalization steps 246 are taken. 248 In general, the content of a domainpart is an Internationalized 249 Domain Name ("IDN") as described in the specifications for 250 Internationalized Domain Names in Applications (commonly called 251 "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as 252 defined in [RFC5890]. 254 After any and all normalization, conversion, and mapping of code 255 points as well as encoding of the string as UTF-8, a domainpart MUST 256 NOT be zero octets in length and MUST NOT be more than 1023 octets in 257 length. (Naturally, the length limits of [RFC1034] apply, and 258 nothing in this document is to be interpreted as overriding those 259 more fundamental limits.) 261 Detailed rules and considerations for preparation, enforcement, and 262 comparison are provided in the following sections. 264 3.2.1. Preparation 266 An entity that prepares a string for inclusion in an XMPP domainpart 267 slot MUST ensure that the string consists only of Unicode code points 268 that are allowed in NR-LDH labels or U-labels as defined in 269 [RFC5890]. This implies that the string MUST NOT include A-labels as 270 defined in [RFC5890]; each A-label MUST be converted to a U-label 271 during preparation of a string for inclusion in a domainpart slot. 272 In addition, the string MUST be encoded as UTF-8 [RFC3629]. 274 3.2.2. Enforcement 276 An entity that performs enforcement in XMPP domainpart slots MUST 277 prepare a string as described in the previous section and MUST also 278 apply the normalization, case-mapping, and width-mapping rules 279 defined in [RFC5892]. 281 The order in which the rules are applied for IDNA2008 (see 282 [RFC5892] and [RFC5895]) is different from the order for 283 localparts and resourceparts as described under Section 3.3 and 284 Section 3.4. 286 3.2.3. Comparison 288 An entity that performs comparison of two strings before or after 289 their inclusion in XMPP domainpart slots MUST prepare each string and 290 enforce the normalization, case-mapping, and width-mapping rules 291 specified in the previous two sections. The two strings are to be 292 considered equivalent if they are an exact octet-for-octet match 293 (sometimes called "bit-string identity"). 295 3.3. Localpart 297 The localpart of a JID is an optional identifier placed before the 298 domainpart and separated from the latter by the '@' character. 299 Typically a localpart uniquely identifies the entity requesting and 300 using network access provided by a server (i.e., a local account), 301 although it can also represent other kinds of entities (e.g., a chat 302 room associated with a multi-user chat service [XEP-0045]). The 303 entity represented by an XMPP localpart is addressed within the 304 context of a specific domain (i.e., ). 306 The localpart of a JID MUST NOT be zero octets in length and MUST NOT 307 be more than 1023 octets in length. This rule is to be enforced 308 after any normalization and mapping of code points as well as 309 encoding of the string as UTF-8. 311 The localpart of a JID is an instance of the UsernameCaseMapped 312 profile of the PRECIS IdentifierClass, which is specified in 313 [I-D.ietf-precis-saslprepbis]. The rules and considerations provided 314 in that specification MUST be applied to XMPP localparts. 316 Implementation Note: XMPP uses the Simple Authentication and 317 Security Layer (SASL) [RFC4422] for authentication. At the time 318 of this writing, some SASL mechanisms use SASLprep [RFC4013] for 319 handling of usernames and passwords; in the future these SASL 320 mechanisms will likely transition to the use of PRECIS-based 321 handling rules as specified in [I-D.ietf-precis-saslprepbis]. For 322 a detailed discussion about the implications of that transition 323 (including the potential need to modify or remove certain 324 characters in the underlying account database), see both 325 Section 6.1 and Appendix A of [I-D.ietf-precis-saslprepbis]. 327 3.3.1. Further Excluded Characters 329 In XMPP, the following characters are explicitly disallowed in XMPP 330 localparts even though they are allowed by the IdentifierClass base 331 class and the UsernameCaseMapped profile: 333 U+0022 (QUOTATION MARK), i.e., " 334 U+0026 (AMPERSAND), i.e., & 336 U+0027 (APOSTROPHE), i.e., ' 338 U+002F (SOLIDUS), i.e., / 340 U+003A (COLON), i.e., : 342 U+003C (LESS-THAN SIGN), i.e., < 344 U+003E (GREATER-THAN SIGN), i.e., > 346 U+0040 (COMMERCIAL AT), i.e., @ 348 Implementation Note: An XMPP-specific method for escaping the 349 foregoing characters (along with U+0020, i.e., ASCII SPACE) has 350 been defined in the JID Escaping specification [XEP-0106]. 352 3.4. Resourcepart 354 The resourcepart of a JID is an optional identifier placed after the 355 domainpart and separated from the latter by the '/' character. A 356 resourcepart can modify either a address or a 357 mere address. Typically a resourcepart uniquely 358 identifies a specific connection (e.g., a device or location) or 359 object (e.g., an occupant in a multi-user chat room [XEP-0045]) 360 belonging to the entity associated with an XMPP localpart at a domain 361 (i.e., ). 363 XMPP entities SHOULD consider resourceparts to be opaque strings and 364 SHOULD NOT impute meaning to any given resourcepart. In particular: 366 o Use of the '/' character as a separator between the domainpart and 367 the resourcepart does not imply that XMPP addresses are 368 hierarchical in the way that, say, HTTP URIs are hierarchical (see 369 [RFC3986] for general discussion); thus for example an XMPP 370 address of the form does not 371 identify a resource "bar" that exists below a resource "foo" in a 372 hierarchy of resources associated with the entity 373 "localpart@domainpart". 375 o The '@' character is allowed in the resourcepart and is often used 376 in the "handle" shown in XMPP chatrooms [XEP-0045]. For example, 377 the JID describes an entity who 378 is an occupant of the room with a handle 379 of . However, chatroom services do not necessarily 380 check such an asserted handle against the occupant's real JID. 382 The resourcepart of a JID MUST NOT be zero octets in length and MUST 383 NOT be more than 1023 octets in length. This rule is to be enforced 384 after any normalization and mapping of code points as well as 385 encoding of the string as UTF-8. 387 The resourcepart of a JID is an instance of the OpaqueString profile 388 of the PRECIS FreeformClass, which is specified in 389 [I-D.ietf-precis-saslprepbis]. The rules and considerations provided 390 in that specification MUST be applied to XMPP resourceparts. 392 3.4.1. Applicability to XMPP Extensions 394 In some contexts, it might be appropriate to apply more restrictive 395 rules to the preparation, enforcement, and comparison of XMPP 396 resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it 397 might be appropriate to apply the rules specified in 398 [I-D.ietf-precis-nickname]. However, the application of more 399 restrictive rules is out of scope for resourceparts in general and is 400 properly defined in specifications for the relevant XMPP extensions. 402 3.5. Examples 404 The following examples illustrate a small number of JIDs that are 405 consistent with the format defined above (note that the characters < 406 and > are used to delineate the actual JIDs and are not part of the 407 JIDs themselves). 409 Table 1: A sample of legal JIDs 411 +----------------------------------+-------------------------------+ 412 | # | JID | Notes | 413 +----------------------------------+-------------------------------+ 414 | 1 | | A "bare JID" | 415 +----------------------------------+-------------------------------+ 416 | 2 | | A "full JID" | 417 +----------------------------------+-------------------------------+ 418 | 3 | | Single space in resourcepart | 419 +----------------------------------+-------------------------------+ 420 | 4 | | At sign in resourcepart | 421 +----------------------------------+-------------------------------+ 422 | 5 | | Single space in localpart, as | 423 | | | optionally escaped using the | 424 | | | XMPP "JID Escaping" extension | 425 +----------------------------------+-------------------------------+ 426 | 6 | | Another bare JID | 427 +----------------------------------+-------------------------------+ 428 | 7 | | The third character is LATIN | 429 | | | SMALL LETTER SHARP S (U+00DF) | 430 +----------------------------------+-------------------------------+ 431 | 8 | <π@example.com> | A localpart of GREEK SMALL | 432 | | | LETTER PI (U+03C0) | 433 +----------------------------------+-------------------------------+ 434 | 9 | <Σ@example.com/foo> | A localpart of GREEK CAPITAL | 435 | | | LETTER SIGMA (U+03A3) | 436 +----------------------------------+-------------------------------+ 437 | 10| <σ@example.com/foo> | A localpart of GREEK SMALL | 438 | | | LETTER SIGMA (U+03C3) | 439 +----------------------------------+-------------------------------+ 440 | 11| <ς@example.com/foo> | A localpart of GREEK SMALL | 441 | | | LETTER FINAL SIGMA (U+03C2) | 442 +----------------------------------+-------------------------------+ 443 | 12| ; | A resourcepart of the Unicode | 444 | | | character BLACK CHESS KING | 445 | | | (U+265A) | 446 +----------------------------------+-------------------------------+ 447 | 13| | A domainpart | 448 +----------------------------------+-------------------------------+ 449 | 14| | A domainpart and resourcepart | 450 +----------------------------------+-------------------------------+ 451 | 15| | A domainpart followed by a | 452 | | | resourcepart that contains an | 453 | | | at sign | 454 +----------------------------------+-------------------------------+ 455 Several points are worth noting. Regarding examples 6 and 7: 456 although in German the character esszett (LATIN SMALL LETTER SHARP S, 457 U+00DF) can mostly be used interchangeably with the two characters 458 "ss", the localparts in these examples are different and (if desired) 459 a server would need to enforce a registration policy that disallows 460 one of them if the other is registered. Regarding examples 9, 10, 461 and 11: case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to 462 lowercase (i.e., to GREEK SMALL LETTER SIGMA, U+03C3) during 463 comparison would result in matching the JIDs in examples 9 and 10; 464 however, because the PRECIS mapping rules do not account for the 465 special status of GREEK SMALL LETTER FINAL SIGMA (U+03C2), the JIDs 466 in examples 9 and 11 or examples 10 and 11 would not be matched. 467 Regarding example 12: symbol characters such as BLACK CHESS KING 468 (U+265A) are allowed by the PRECIS FreeformClass and thus can be used 469 in resourceparts. Regarding examples 14 and 15: JIDs consisting of a 470 domainpart and resourcepart are rarely seen in the wild, but are 471 allowed according to the XMPP address format. Example 15 illustrates 472 the need for careful extraction of the domainpart as described in the 473 first paragraph of Section 3.2. 475 The following examples illustrate strings that are not JIDs because 476 they violate the format defined above. 478 Table 2: A sample of strings that violate the JID rules 480 +----------------------------------+-------------------------------+ 481 | # | Non-JID string | Notes | 482 +----------------------------------+-------------------------------+ 483 | 16| <"juliet"@example.com> | Quotation marks (U+0022) in | 484 | | | localpart | 485 +----------------------------------+-------------------------------+ 486 | 17| | Space (U+0020) in localpart | 487 +----------------------------------+-------------------------------+ 488 | 18| | Leading space in resourcepart | 489 +----------------------------------+-------------------------------+ 490 | 19| <@example.com/> | Zero-length localpart and | 491 | | | resourcepart | 492 +----------------------------------+-------------------------------+ 493 | 20| | The sixth character is ROMAN | 494 | | | NUMERAL FOUR (U+2163) | 495 +----------------------------------+-------------------------------+ 496 | 21| <♚@example.com> | A localpart of BLACK CHESS | 497 | | | KING (U+265A) | 498 +----------------------------------+-------------------------------+ 499 | 22| | A localpart without a | 500 | | | domainpart | 501 +----------------------------------+-------------------------------+ 502 | 23| | A resourcepart without a | 503 | | | domainpart | 504 +----------------------------------+-------------------------------+ 506 Here again, several points are worth noting. Regarding example 17, 507 even though ASCII SPACE (U+0020) is disallowed in the PRECIS 508 IdentifierClass, it can be escaped to "\20" in XMPP localparts by 509 using the JID Escaping rules defined in [XEP-0106], as illustrated by 510 example 4 in Table 1. Regarding example 20, the Unicode character 511 ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the 512 string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL 513 LETTER V (U+0056), but characters with compatibility equivalents are 514 not allowed in the PRECIS IdentiferClass. Regarding example 21: 515 symbol characters such as BLACK CHESS KING (U+265A) are not allowed 516 in the PRECIS IdentifierClass; however, both of the non-ASCII 517 characters in examples 20 and 21 are allowed in the PRECIS Freeform 518 class and therefore in the XMPP resourcepart (as illustrated for 519 U+265A by example 12 in Table 1). Regarding examples 22 and 23: the 520 domainpart is required in a JID. 522 4. Enforcement in JIDs and JID Parts 524 Enforcement entails applying all of the rules specified in this 525 document. Enforcement of the XMPP address format rules is the 526 responsibility of XMPP servers. Although XMPP clients SHOULD prepare 527 complete JIDs and parts of JIDs in accordance with this document 528 before including them in protocol slots within XML streams, XMPP 529 servers MUST enforce the rules wherever possible and reject stanzas 530 and other XML elements that violate the rules (for stanzas, by 531 returning a error to the sender as described in 532 Section 8.3.3.8 of [RFC6120]). 534 Entities that enforce the rules specified in this document are 535 encouraged to be liberal in what they accept by following this 536 procedure: 538 1. Where possible, map characters (e.g, through width mapping, 539 additional mapping, special mapping, case mapping, or 540 normalization) and accept the mapped string. 542 2. If mapping is not possible (e.g., because a character is 543 disallowed in the FreeformClass), reject the string and return a 544 error. 546 Enforcement applies to complete JIDs and to parts of JIDs. To 547 facilitate implementation, this document defines the concepts of "JID 548 slot", "localpart slot", and "resourcepart slot" (similar to the 549 concept of a "domain name slot" for IDNA2008 defined in 550 Section 2.3.2.6 of [RFC5890]): 552 JID Slot: An XML element or attribute explicitly designated in XMPP 553 or in XMPP extensions for carrying a complete JID. 555 Localpart Slot: An XML element or attribute explicitly designated in 556 XMPP or in XMPP extensions for carrying the localpart of a JID. 558 Resourcepart Slot: An XML element or attribute explicitly designated 559 in XMPP or in XMPP extensions for carrying the resourcepart of a 560 JID. 562 A server is responsible for enforcing the address format rules when 563 receiving protocol elements from clients where the server is expected 564 to handle such elements directly or to use them for purposes of 565 routing a stanza to another domain or delivering a stanza to a local 566 entity; two examples from [RFC6120] are the 'to' attribute on XML 567 stanzas (which is a JID slot used by XMPP servers for routing of 568 outbound stanzas) and the child of the element 569 (which is a resourcepart slot used by XMPP servers for binding of a 570 resource to an account for routing of stanzas between the server and 571 a particular client). An example from [RFC6121] is the 'jid' 572 attribute of the roster element. 574 A server is not responsible for enforcing the rules when the protocol 575 elements are intended for communication among other entities, 576 typically within the payload of a stanza that the server is merely 577 routing to another domain or delivering to a local entity. Two 578 examples are the 'initiator' attribute in the Jingle extension 579 [XEP-0166] (which is a JID slot used for client-to-client 580 coordination of multimedia sessions) and the 'nick' attribute in the 581 Multi-User Chat extension [XEP-0045] (which is a resourcepart slot 582 used for administrative purposes in the context of XMPP chatrooms). 583 In such cases, the entities involved SHOULD enforce the rules 584 themselves and not depend on the server to do so, and client 585 implementers need to understand that not enforcing the rules can lead 586 to a degraded user experience or to security vulnerabilities. 587 However, when an add-on service (e.g., a multi-user chat service) 588 handles a stanza directly, it ought to enforce the rules as well, as 589 defined in the relevant specification for that type of service. 591 This document does not provide an exhaustive list of JID slots, 592 localpart slots, or resourcepart slots. However, implementers of 593 core XMPP servers are advised to consider as JID slots at least the 594 following elements and attributes when they are handled directly or 595 used for purposes of routing to another domain or delivering to a 596 local entity: 598 o The 'from' and 'to' stream attributes and the 'from' and 'to' 599 stanza attributes [RFC6120]. 601 o The 'jid' attribute of the roster element for contact list 602 management [RFC6121]. 604 o The 'value' attribute of the element for Privacy Lists 605 [RFC3921] [XEP-0016] when the value of the 'type' attribute is 606 "jid". 608 o The 'jid' attribute of the element for Service Discovery 609 defined in [XEP-0030]. 611 o The element for Data Forms [XEP-0004], when the 'type' 612 attribute is "jid-single" or "jid-multi". 614 o The 'jid' attribute of the element for Bookmark 615 Storage [XEP-0048]. 617 o The of the element for vCard 3.0 [XEP-0054] 618 and the child of the element for vCard 4.0 619 [XEP-0292] when the XML character data identifies an XMPP URI 620 [RFC5122]. 622 o The 'from' attribute of the element for Delayed Delivery 623 [XEP-0203]. 625 o The 'jid' attribute of the element for the Blocking 626 Command [XEP-0191]. 628 o The 'from' and 'to' attributes of the and 629 elements for Server Dialback [RFC3921], [XEP-0220]. 631 o The 'from' and 'to' attributes of the , , and 632 elements for the Jabber Component Protocol [XEP-0114]. 634 Developers of XMPP clients and specialized XMPP add-on services are 635 advised to check the appropriate specifications for JID slots, 636 localpart slots, and resourcepart slots in XMPP protocol extensions 637 such as Service Discovery [XEP-0030], Multi-User Chat [XEP-0045], 638 Publish-Subscribe [XEP-0060], SOCKS5 Bytestreams [XEP-0065], In-Band 639 Registration [XEP-0077], Roster Item Exchange [XEP-0144], and Jingle 640 [XEP-0166]. 642 5. Internationalization Considerations 644 XMPP applications MUST support IDNA2008 for domainparts as described 645 under Section 3.2, the "UsernameCaseMapped" profile for localparts as 646 described under Section 3.3, and the "OpaqueString" profile for 647 resourceparts as described under Section 3.4. This enables XMPP 648 addresses to include a wide variety of characters outside the ASCII 649 range. Rules for enforcement of the XMPP address format are provided 650 in [RFC6120] and specifications for various XMPP extensions. 652 Interoperability Note: For backward compatibility, many existing 653 XMPP implementations and deployments support IDNA2003 [RFC3490] 654 for domainparts, and the stringprep [RFC3454] profiles Nodeprep 655 and Resourceprep [RFC3920] for localparts and resourceparts. 657 6. IANA Considerations 659 6.1. Stringprep Profiles Registry 661 The Stringprep specification [RFC3454] did not provide for entries in 662 the Stringprep Profiles registry to be marked as anything except 663 current or not current. Because this document obsoletes RFC 6122, 664 which registered the "Nodeprep" and "Resourceprep" profiles, IANA is 665 requested at the least to mark those profiles as not current 666 (preferably with a pointer to this document). 668 7. Security Considerations 670 7.1. Reuse of PRECIS 672 The security considerations described in [I-D.ietf-precis-framework] 673 apply to the "IdentifierClass" and "FreeformClass" base string 674 classes used in this document for XMPP localparts and resourceparts, 675 respectively. The security considerations described in [RFC5890] 676 apply to internationalized domain names, which are used here for XMPP 677 domainparts. 679 7.2. Reuse of Unicode 681 The security considerations described in [UTS39] apply to the use of 682 Unicode characters in XMPP addresses. 684 7.3. Address Spoofing 686 There are two forms of address spoofing: forging and mimicking. 688 7.3.1. Address Forging 690 In the context of XMPP technologies, address forging occurs when an 691 entity is able to generate an XML stanza whose 'from' address does 692 not correspond to the account credentials with which the entity 693 authenticated onto the network (or an authorization identity provided 694 during negotiation of SASL authentication [RFC4422] as described in 695 [RFC6120]). For example, address forging occurs if an entity that 696 authenticated as "juliet@im.example.com" is able to send XML stanzas 697 from "nurse@im.example.com" or "romeo@example.net". 699 Address forging is difficult in XMPP systems, given the requirement 700 for sending servers to stamp 'from' addresses and for receiving 701 servers to verify sending domains via server-to-server authentication 702 (see [RFC6120]). However, address forging is possible if: 704 o A poorly implemented server ignores the requirement for stamping 705 the 'from' address. This would enable any entity that 706 authenticated with the server to send stanzas from any 707 localpart@domainpart as long as the domainpart matches the sending 708 domain of the server. 710 o An actively malicious server generates stanzas on behalf of any 711 registered account at the domain or domains hosted at that server. 713 Therefore, an entity outside the security perimeter of a particular 714 server cannot reliably distinguish between JIDs of the form 715 at that server and thus can authenticate only 716 the domainpart of such JIDs with any level of assurance. This 717 specification does not define methods for discovering or 718 counteracting the kind of poorly implemented or rogue servers just 719 described. However, the end-to-end authentication or signing of XMPP 720 stanzas could help to mitigate this risk, since it would require the 721 rogue server to generate false credentials for signing or encryption 722 of each stanza, in addition to modifying 'from' addresses. 724 7.3.2. Address Mimicking 726 Address mimicking occurs when an entity provides legitimate 727 authentication credentials for and sends XML stanzas from an account 728 whose JID appears to a human user to be the same as another JID. 729 Because many characters are visually similar, it is relatively easy 730 to mimic JIDs in XMPP systems. As one simple example, the localpart 731 "ju1iet" (using the Arabic numeral one as the third character) might 732 appear the same as the localpart "juliet" (using lowercase "L" as the 733 third character). 735 As explained in [RFC5890], [I-D.ietf-precis-framework], [UTR36], and 736 [UTS39], there is no straightforward solution to the problem of 737 visually similar characters. Furthermore, IDNA and PRECIS 738 technologies do not attempt to define such a solution. As a result, 739 XMPP domainparts, localparts, and resourceparts could contain such 740 characters, leading to security vulnerabilities such as the 741 following: 743 o A domainpart is always employed as one part of an entity's address 744 in XMPP. One common usage is as the address of a server or 745 server-side service, such as a multi-user chat service [XEP-0045]. 746 The security of such services could be compromised based on 747 different interpretations of the internationalized domainpart; for 748 example, a user might authorize a malicious entity at a fake 749 server to view the user's presence information, or a user could 750 join chatrooms at a fake multi-user chat service. 752 o A localpart can be employed as one part of an entity's address in 753 XMPP. One common usage is as the username of an instant messaging 754 user; another is as the name of a multi-user chat room; and many 755 other kinds of entities could use localparts as part of their 756 addresses. The security of such services could be compromised 757 based on different interpretations of the internationalized 758 localpart; for example, a user entering a single internationalized 759 localpart could access another user's account information, or a 760 user could gain access to a hidden or otherwise restricted chat 761 room or service. 763 o A resourcepart can be employed as one part of an entity's address 764 in XMPP. One common usage is as the name for an instant messaging 765 user's connected resource; another is as the nickname of a user in 766 a multi-user chat room; and many other kinds of entities could use 767 resourceparts as part of their addresses. The security of such 768 services could be compromised based on different interpretations 769 of the internationalized resourcepart; for example, two or more 770 confusable resources could be bound at the same time to the same 771 account (resulting in inconsistent authorization decisions in an 772 XMPP application that uses full JIDs), or a user could send a 773 private message to someone other than the intended recipient in a 774 multi-user chat room. 776 XMPP services and clients are strongly encouraged to define and 777 implement consistent policies regarding the registration, storage, 778 and presentation of visually similar characters in XMPP systems. In 779 particular, service providers and software implementers are strongly 780 encouraged to apply the policies recommended in 781 [I-D.ietf-precis-framework]. 783 8. Conformance Requirements 785 This section describes a protocol feature set that summarizes the 786 conformance requirements of this specification (similar feature sets 787 are provided for XMPP in [RFC6120] and [RFC6121]). The summary is 788 purely informational and the conformance keywords of [RFC2119] as 789 used here are intended only to briefly describe the referenced 790 normative text from the body of this specification. This feature set 791 is appropriate for use in software certification, interoperability 792 testing, and implementation reports. For each feature, this section 793 provides the following information: 795 o A human-readable name 797 o An informational description 799 o A reference to the particular section of this document that 800 normatively defines the feature 802 o Whether the feature applies to the Client role, the Server role, 803 or both (where "N/A" signifies that the feature is not applicable 804 to the specified role) 806 o Whether the feature MUST or SHOULD be implemented, where the 807 capitalized terms are to be understood as described in [RFC2119] 809 The feature set specified here provides a basis for interoperability 810 testing and follows the spirit of a proposal made by Larry Masinter 811 within the IETF's NEWTRK Working Group in 2005 [INTEROP]. 813 Feature: address-domain-length 815 Description: Ensure that the domainpart of an XMPP address is at 816 least one octet in length and at most 1023 octets in length, and 817 that it conforms to the underlying length limits of the DNS. 819 Section: Section 3.2 821 Roles: Server MUST, client SHOULD. 823 Feature: address-domain-prep 825 Description: Ensure that the domainpart of an XMPP address conforms 826 to IDNA2008, that it contains only NR-LDH labels and U-labels (not 827 A-labels), and that all uppercase and titlecase code points are 828 mapped to their lowercase equivalents. 830 Section: Section 3.2 832 Roles: Server MUST, client SHOULD. 834 Feature: address-localpart-length 836 Description: Ensure that the localpart of an XMPP address is at 837 least one octet in length and at most 1023 octets in length. 839 Section: Section 3.3 841 Roles: Server MUST, client SHOULD. 843 Feature: address-localpart-prep 845 Description: Ensure that the localpart of an XMPP address conforms 846 to the "UsernameCaseMapped" profile of the PRECIS IdentifierClass. 848 Section: Section 3.3 850 Roles: Server MUST, client SHOULD. 852 Feature: address-resource-length 854 Description: Ensure that the resourcepart of an XMPP address is at 855 least one octet in length and at most 1023 octets in length. 857 Section: Section 3.4 859 Roles: Server MUST, client SHOULD. 861 Feature: address-resource-prep 863 Description: Ensure that the resourcepart of an XMPP address 864 conforms to the "OpaqueString" profile of the PRECIS 865 FreeformClass. 867 Section: Section 3.4 869 Roles: Server MUST, client SHOULD. 871 9. References 873 9.1. Normative References 875 [I-D.ietf-precis-framework] 876 Saint-Andre, P. and M. Blanchet, "Precis Framework: 877 Handling Internationalized Strings in Protocols", draft- 878 ietf-precis-framework-23 (work in progress), February 879 2015. 881 [I-D.ietf-precis-saslprepbis] 882 Saint-Andre, P. and A. Melnikov, "Username and Password 883 Preparation Algorithms", draft-ietf-precis-saslprepbis-14 884 (work in progress), March 2015. 886 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 887 STD 13, RFC 1034, November 1987. 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, March 1997. 892 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 893 10646", STD 63, RFC 3629, November 2003. 895 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 896 Specifications: ABNF", STD 68, RFC 5234, January 2008. 898 [RFC5890] Klensin, J., "Internationalized Domain Names for 899 Applications (IDNA): Definitions and Document Framework", 900 RFC 5890, August 2010. 902 [RFC5892] Faltstrom, P., "The Unicode Code Points and 903 Internationalized Domain Names for Applications (IDNA)", 904 RFC 5892, August 2010. 906 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 907 Protocol (XMPP): Core", RFC 6120, March 2011. 909 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 910 6.3", 2013, 911 . 913 [UTR36] The Unicode Consortium, "Unicode Technical Report #36: 914 Unicode Security Considerations", November 2013, 915 . 917 9.2. Informative References 919 [I-D.ietf-precis-nickname] 920 Saint-Andre, P., "Preparation and Comparison of 921 Nicknames", draft-ietf-precis-nickname-16 (work in 922 progress), March 2015. 924 [INTEROP] Masinter, L., "Formalizing IETF Interoperability 925 Reporting", Work in Progress, October 2005. 927 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 928 and Support", STD 3, RFC 1123, October 1989. 930 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 931 With Widely Deployed DNS Software", RFC 1535, October 932 1993. 934 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 935 Internationalized Strings ("stringprep")", RFC 3454, 936 December 2002. 938 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 939 "Internationalizing Domain Names in Applications (IDNA)", 940 RFC 3490, March 2003. 942 See Section 1 for an explanation of why the normative 943 reference to an obsoleted specification is needed. 945 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 946 Protocol (XMPP): Core", RFC 3920, October 2004. 948 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 949 Protocol (XMPP): Instant Messaging and Presence", RFC 950 3921, October 2004. 952 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 953 Resource Identifier (URI): Generic Syntax", STD 66, RFC 954 3986, January 2005. 956 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 957 Identifiers (IRIs)", RFC 3987, January 2005. 959 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 960 and Passwords", RFC 4013, February 2005. 962 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 963 Security Layer (SASL)", RFC 4422, June 2006. 965 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 966 (IRIs) and Uniform Resource Identifiers (URIs) for the 967 Extensible Messaging and Presence Protocol (XMPP)", RFC 968 5122, February 2008. 970 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 971 Internationalized Domain Names in Applications (IDNA) 972 2008", RFC 5895, September 2010. 974 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 975 Protocol (XMPP): Instant Messaging and Presence", RFC 976 6121, March 2011. 978 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 979 Protocol (XMPP): Address Format", RFC 6122, March 2011. 981 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 982 Internationalization in the IETF", BCP 166, RFC 6365, 983 September 2011. 985 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 986 Problem Statement for the Preparation and Comparison of 987 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 989 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 990 Unicode Security Mechanisms", July 2012, 991 . 993 [XEP-0004] 994 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 995 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 997 [XEP-0016] 998 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 999 0016, February 2007. 1001 [XEP-0029] 1002 Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF 1003 XEP 0029, October 2003. 1005 [XEP-0030] 1006 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 1007 Andre, "Service Discovery", XSF XEP 0030, June 2008. 1009 [XEP-0045] 1010 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 1011 2012. 1013 [XEP-0048] 1014 Blackman, R., Millard, P., and P. Saint-Andre, 1015 "Bookmarks", XSF XEP 0048, November 2007. 1017 [XEP-0054] 1018 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 1020 [XEP-0060] 1021 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1022 Subscribe", XSF XEP 0060, July 2010. 1024 [XEP-0065] 1025 Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, 1026 "SOCKS5 Bytestreams", XSF XEP 0065, April 2011. 1028 [XEP-0077] 1029 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 1030 January 2012. 1032 [XEP-0106] 1033 Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 1034 0106, June 2007. 1036 [XEP-0114] 1037 Saint-Andre, P., "Jabber Component Protocol", XSF XEP 1038 0114, March 2005. 1040 [XEP-0144] 1041 Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, 1042 August 2005. 1044 [XEP-0166] 1045 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 1046 S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 1047 2009. 1049 [XEP-0191] 1050 Saint-Andre, P., "Blocking Command", XSF XEP 0191, July 1051 2012. 1053 [XEP-0203] 1054 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, 1055 September 2009. 1057 [XEP-0220] 1058 Miller, J., Saint-Andre, P., and P. Hancke, "Server 1059 Dialback", XSF XEP 0220, August 2012. 1061 [XEP-0292] 1062 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 1063 0292, October 2011. 1065 [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., 1066 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 1067 Edition)", World Wide Web Consortium Recommendation REC- 1068 xml-20081126, November 2008, 1069 . 1071 Appendix A. Differences from RFC 6122 1073 Based on consensus derived from working group discussion, 1074 implementation and deployment experience, and formal interoperability 1075 testing, the following substantive modifications were made from RFC 1076 6122. 1078 o Changed domainpart preparation to use IDNA2008 (instead of 1079 IDNA2003). 1081 o Changed localpart preparation to use the UsernameCaseMapped 1082 profile of the PRECIS IdentifierClass (instead of the Nodeprep 1083 profile of Stringprep). 1085 o Changed resourcepart preparation to use the OpaqueString profile 1086 of the PRECIS FreeformClass (instead of the Resourceprep profile 1087 of Stringprep). 1089 o Specified that internationalized labels within domainparts must be 1090 U-labels (instead of "should be" U-labels). 1092 o Specified that fullwidth and halfwidth characters must be mapped 1093 to their decomposition mappings (previously handled through the 1094 use of NFKC). 1096 o Specified the use of Unicode Normalization Form C (instead of 1097 Unicode Normalization Form KC as specified in the Nodeprep and 1098 Resourceprep profiles of Stringprep). 1100 o Specified that servers must enforce the address formatting rules. 1102 Appendix B. Acknowledgements 1104 Thanks to Ben Campbell, Dave Cridland, Miguel Garcia, Joe Hildebrand, 1105 Jonathan Lennox, Matt Miller, and Florian Zeitz for their feedback. 1107 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 1108 employing him during his work on earlier versions of this document. 1110 Author's Address 1112 Peter Saint-Andre 1113 &yet 1115 Email: peter@andyet.com 1116 URI: https://andyet.com/