idnits 2.17.1 draft-saintandre-jabberid-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2014) is 3699 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 &yet 4 Intended status: Informational March 4, 2014 5 Expires: September 5, 2014 7 The Jabber-ID Header Field 8 draft-saintandre-jabberid-13 10 Abstract 12 This document defines a header field that enables the author of an 13 email or netnews message to include a Jabber ID in the message header 14 block for the purpose of associating the author with a particular 15 Extensible Messaging and Presence Protocol (XMPP) address. 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 5, 2014. 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. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.4. Disposition . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security and Privacy Considerations . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 6.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The Extensible Messaging and Presence Protocol (XMPP), documented in 69 [RFC6120], is a streaming XML technology that enables any two 70 entities on a network to exchange well-defined but extensible XML 71 elements (called "XML stanzas") in close to real time. Given XMPP's 72 heritage in the Jabber open-source community, one of the primary uses 73 for XMPP is instant messaging and presence as documented in 74 [RFC6121], and XMPP addresses are still referred to as Jabber IDs. 76 Because almost all human users of Jabber/XMPP instant messaging and 77 presence systems also use email systems [RFC5322] and because many 78 also use netnews systems [RFC5536], it can be helpful for them to 79 associate their Jabber IDs with the messages they author. The 80 Jabber-ID header field provides a standard location for that 81 information. 83 Members of the XMPP instant messaging and presence community have 84 been experimenting with the Jabber-ID header field for many years. 85 This document defines the syntax and usage of the Jabber-ID header 86 field, including the information necessary to register the field in 87 the Provisional Message Header Field Registry maintained by the IANA. 89 2. Syntax 91 The syntax of the Jabber-ID header field is defined below using 92 Augmented Backus-Naur Form [RFC5234], where the "pathxmpp" rule is 93 defined in the XMPP URI specification [RFC5122] and the remaining 94 rules are defined in the Internet Message Format specification 95 [RFC5322]: 97 Jabber-ID = SP *WSP pathxmpp *WSP CRLF 99 Although a native XMPP address can contain virtually any Unicode 100 character [UNICODE], the header of an email or netnews message is 101 allowed to contain only printable ASCII characters (see Section 2 of 102 [RFC5322]). Therefore, any characters outside the ASCII range 103 [RFC20] in an XMPP address need to be converted to ASCII before 104 inclusion in a Jabber-ID header field, in accordance with the rules 105 defined in the XMPP URI specification [RFC5122]. In addition, 106 characters allowed in XMPP localparts and XMPP resourceparts but 107 disallowed by the relevant URI rules need to be percent-encoded in 108 accordance with the rules defined in the URI specification [RFC3986]. 110 3. Usage 112 3.1. Inclusion 114 The Jabber-ID header field is associated with the author of the 115 message; see [RFC5322]. If the "From:" header field of an email 116 message contains more than one mailbox, it is best not to add the 117 Jabber-ID header field to the message. To reduce the possibility of 118 confusion, it is best to include only one instance of the Jabber-ID 119 header field in a given message. 121 3.2. Generation 123 For a user whose XMPP address is "juliet@example.com", the 124 corresponding Jabber-ID header field would be: 126 Jabber-ID: juliet@example.com 128 As noted, non-ASCII characters in XMPP addresses need to be converted 129 into ASCII before inclusion in a Jabber-ID header field. Consider 130 the following XMPP address: 132 jiři@čechy.example 134 In the foregoing example, the string "ř" stands for the Unicode 135 character LATIN SMALL LETTER R WITH CARON and the string "č" 136 stands for the Unicode character LATIN SMALL LETTER C WITH CARON, 137 following the "XML Notation" used in [RFC3987] to represent 138 characters that cannot be rendered in ASCII-only documents. For 139 those who do not read Czech, this example could be Anglicized as 140 "george@czech-lands.example". 142 Following the rules in [RFC5122] and the Jabber-ID header field 143 syntax, the resulting header field might be as shown below (note that 144 this representation includes folding white space, which is allowed in 145 accordance with the ABNF): 147 Jabber-ID: 148 ji%C5%99i@%C4%8Dechy.example 150 3.3. Processing 152 Upon receiving an email message or netnews message containing a 153 Jabber-ID header field, a user agent that supports the field ought to 154 process the field by converting any escaped characters to characters 155 outside the ASCII range in accordance with the rules defined in 156 [RFC5122], thus yielding a Jabber ID that can be used for native 157 communication on the XMPP network. 159 3.4. Disposition 161 A user agent that has processed a Jabber-ID header field can provide 162 appropriate interface elements if it has independent information 163 linking the author of the email or netnews message with the specified 164 Jabber ID (e.g., via a user-controlled address book or automated 165 directory lookup). Such interface elements might include an 166 indicator of "presence" (i.e., that the author is online and 167 available for communication via XMPP) if the user is subscribed to 168 the presence of the author, and an element that enables the user to 169 send an instant message or initiate a text chat session with the 170 author. 172 4. IANA Considerations 174 The IANA includes "Jabber-ID" in the Provisional Message Header Field 175 Names Registry. The completed registration template follows. 177 Header field name: Jabber-ID 179 Applicable protocol: mail, netnews 181 Status: provisional 183 Author/Change contoller Peter Saint-Andre 184 186 Specification document: RFC XXXX 188 Related information: See RFC 6120 190 [[Note to IANA: The Provisional Message Header Field Names Registry 191 currently includes an entry for "Jabber-ID", with a reference to 192 draft-saintandre-jabberid-08. Please update the registry entry to 193 refer to "RFC XXXX", where "XXXX" is the number of the RFC that 194 results from this specification.]] 196 [[Note to RFC Editor: Please replace "XXXX" with the number of the 197 RFC that results from this specification. Please remove this note, 198 along with the foregoing note, upon publication.]] 200 5. Security and Privacy Considerations 202 Message headers are an existing standard and are designed to easily 203 accommodate new types. Although the Jabber-ID header field could be 204 forged, this problem is inherent in Internet email and netnews; 205 however, because a forged Jabber-ID header field might break 206 automated processing, applications are discouraged from depending on 207 the Jabber-ID header field to indicate the authenticity of an email 208 or netnews message, or the identity of its author or sender. 209 Including the Jabber-ID header field among the signer header fields 210 in DomainKeys Identified Mail (DKIM) can help to mitigate against 211 forging of the header (see [RFC6376]). 213 Advertising XMPP addresses in email or netnews headers might make it 214 easier for malicious users to harvest XMPP addresses and therefore to 215 send unsolicited bulk communications to the users or applications 216 represented by those addresses. Providing such a binding between an 217 email address and a Jabber ID can also increase the possibility of 218 drawing a connection between different kinds of communications 219 traffic for purposes of surveillance and other breaches of privacy. 220 Care ought to be taken in balancing the benefits of open information 221 exchange against the potential costs of security and privacy 222 weaknesses. An email or netnews user agent that is capable of 223 including the Jabber-ID header field in outgoing email or netnews 224 messages needs to provide an option for its user to disable inclusion 225 of the Jabber-ID header field generally, on a per-recipient basis, 226 and on a per-message basis. 228 The security and privacy considerations discussed in [RFC3986], 229 [RFC3987], [RFC5122], [RFC6120], and [RFC6121] also apply to the 230 Jabber-ID message header. 232 6. References 234 6.1. Normative References 236 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 237 Resource Identifier (URI): Generic Syntax", STD 66, RFC 238 3986, January 2005. 240 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 241 Identifiers (IRIs)", RFC 3987, January 2005. 243 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 244 (IRIs) and Uniform Resource Identifiers (URIs) for the 245 Extensible Messaging and Presence Protocol (XMPP)", RFC 246 5122, February 2008. 248 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 249 Specifications: ABNF", STD 68, RFC 5234, January 2008. 251 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 252 October 2008. 254 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 255 Protocol (XMPP): Core", RFC 6120, March 2011. 257 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 258 6.3", 2013, 259 . 261 6.2. Informative References 263 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 264 October 1969. 266 [RFC5536] Murchison, K., Lindsey, C., and D. Kohn, "Netnews Article 267 Format", RFC 5536, November 2009. 269 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 270 Protocol (XMPP): Instant Messaging and Presence", RFC 271 6121, March 2011. 273 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 274 Identified Mail (DKIM) Signatures", RFC 6376, September 275 2011. 277 Appendix A. Acknowledgements 279 Thanks to Dave Cridland, Stephen Farrell, Russ Housley, and Alexey 280 Melnikov for their feedback. 282 Author's Address 284 Peter Saint-Andre 285 &yet 287 Email: ietf@stpeter.im