RFC 7259

The Jabber-ID Header Field 💖

• Stream: Independent Submission 🌸
• RFC number: 7259
• Category: Informational ✨
• Date: May 2014 📅
• ISSN: 2070-1721
• Author: Peter Saint-Andre, &yet 🎀
• Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates. It stands on its own 🦋

Abstract

okay so this doc defines a header field 💅 that lets the author of an email or netnews message put a Jabber ID right in the message header block. That way the author gets linked to a specific Extensible Messaging and Presence Protocol (XMPP) address. main character energy 👑

Status of This Memo

ngl this one is not an Internet Standards Track spec 🙈 It's published just for info.

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make no statement about its value for implementation or deployment. Docs the RFC Editor approves aren't a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🧚

For the current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7259. 🔗

Copyright Notice

the legal bits, kept exactly as they are 💜

Copyright (c) 2014 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  3.1.  Inclusion . . . . . . . . . . . . . . . . . . . . . . . .   3
  3.2.  Generation  . . . . . . . . . . . . . . . . . . . . . . .   3
  3.3.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   4
  3.4.  Disposition . . . . . . . . . . . . . . . . . . . . . . .   4
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
5.  Security and Privacy Considerations . . . . . . . . . . . . .   5
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7

1. Introduction ✨

okay bestie, so XMPP (documented in [RFC6120]) is a streaming XML tech 🌈 It lets any two entities on a network swap well-defined but extensible XML elements, called "XML stanzas", in close to real time. Since XMPP comes from the Jabber open-source community, one of its biggest jobs is instant messaging and presence, as covered in [RFC6121]. And honestly, XMPP addresses are still called Jabber IDs 🦋

Almost all Jabber/XMPP humans also use email [RFC5322], and lots of them use netnews too [RFC5536]. So it can be super helpful to link their Jabber IDs to the messages they write. The Jabber-ID header field gives that info a standard spot to live 🎀

The XMPP instant messaging and presence crowd has been playing with the Jabber-ID header field for years already 🔥 This doc defines its syntax and usage, plus everything needed to register the field in the Provisional Message Header Field Names registry that IANA maintains. 💅

2. Syntax 🧩

the grammar is written in Augmented Backus-Naur Form [RFC5234]. The "pathxmpp" rule comes from the XMPP URI spec [RFC5122], and everything else comes from the Internet Message Format spec [RFC5322] 💜

   Jabber-ID = SP *WSP pathxmpp *WSP CRLF

so a native XMPP address can have basically any Unicode character [UNICODE] 🌸 But email and netnews headers only allow printable ASCII characters (see Section 2 of [RFC5322]) 🙈 That means any non-ASCII characters in an XMPP address need to be converted to ASCII before they go into a Jabber-ID header field, following the rules in the XMPP URI spec [RFC5122]. Characters that are allowed in XMPP localparts and resourceparts but disallowed by the URI rules need to be percent-encoded, following the URI spec [RFC3986] 🫶 (for the ASCII range, see [RFC20]).

3. Usage 🌷

3.1. Inclusion

the Jabber-ID header field goes with the author of the message (see [RFC5322]) 🍓 If an email's "From:" header field has more than one mailbox in it, it's best not to add a Jabber-ID header field at all 💀 And to avoid confusion, it's best to only include one Jabber-ID header field per message ✨

3.2. Generation

say a user's XMPP address is juliet@example.com. Then the Jabber-ID header field would be:

   Jabber-ID: juliet@example.com

as we said, non-ASCII characters in XMPP addresses have to become ASCII before they go in a Jabber-ID header field 😭 Check out this XMPP address:

   jiři@čechy.example

in that example, ř is the Unicode character LATIN SMALL LETTER R WITH CARON, and č is LATIN SMALL LETTER C WITH CARON. It uses the "XML Notation" from [RFC3987] to show characters that can't be rendered in ASCII-only docs 🧚 For anyone who doesn't read Czech, it could be anglicized as "george@czech-lands.example" 🌈

Following [RFC5122] and the Jabber-ID header field syntax, the header field might end up looking like this. Note that this version includes folding white space, which is allowed by the ABNF ✨

   Jabber-ID:
          ji%C5%99i@%C4%8Dechy.example

3.3. Processing

when a user agent gets an email or netnews message with a Jabber-ID header field, a user agent that supports the field ought to process it 🔥 It converts any escaped characters back into characters outside the ASCII range, following the rules in [RFC5122]. The result is a Jabber ID that can be used for native communication on the XMPP network 💖

3.4. Disposition

a user agent that has processed a Jabber-ID header field can show useful interface elements, but only if it has independent info linking the author of the email or netnews message to that Jabber ID 👑 For example, that info might come from a user-controlled address book or an automated directory lookup 📒 Those elements might include a "presence" indicator (so you can see the author is online and available for XMPP chat), but only if the user is subscribed to the author's presence 🍓 They might also include something that lets the user send an instant message or start a text chat session with the author 💬

4. IANA Considerations 📋

IANA has added "Jabber-ID" to the Provisional Message Header Field Names registry 🎀 Here's the completed registration template:

   Header field name:  Jabber-ID

   Applicable protocol:  mail, netnews

   Status:  provisional

   Author/Change controller  Peter Saint-Andre <stpeter@jabber.org>
   Specification document:  RFC 7259

   Related information:  See RFC 6120

5. Security and Privacy Considerations 🚨

okay this section is SERIOUS, bestie 😭 Message headers are an existing standard, and they're built to easily fit new types. Yes, the Jabber-ID header field could be forged, but that problem is baked into Internet email and netnews. Still, a forged Jabber-ID header field might break automated processing, so applications are discouraged from relying on it to show that a message is authentic, or to show who its author or sender is 🙈 Including the Jabber-ID header field in the signer header fields of DomainKeys Identified Mail (DKIM) can help protect against forging the header (see [RFC6376]) 🔐

⚠️ Advertising XMPP addresses in email or netnews headers can make it easier for bad actors to harvest them. Then they can send unsolicited bulk messages to the users or applications behind those addresses. Tying an email address to a Jabber ID can also make it easier to connect different kinds of communication traffic, which can lead to surveillance and other privacy breaches 😱

So care ought to be taken to balance the benefits of open information exchange against the possible costs of security and privacy weaknesses 💜 An email or netnews user agent that can include the Jabber-ID header field in outgoing messages needs to give its user an option to turn that off. The option needs to work in three ways: generally, per recipient, and per message 🛡️

the security and privacy considerations in [RFC3986], [RFC3987], [RFC5122], [RFC6120], and [RFC6121] also apply to the Jabber-ID message header 🌸

6. References 📚

6.1. Normative References

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC5122]  Saint-Andre, P., "Internationalized Resource Identifiers
              (IRIs) and Uniform Resource Identifiers (URIs) for the
              Extensible Messaging and Presence Protocol (XMPP)", RFC
              5122, February 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              6.3", (Mountain View, CA: The Unicode Consortium, 2013.
              ISBN 978-1-936213-08-5),
              <http://www.unicode.org/versions/Unicode6.3.0/>.

6.2. Informative References

   [RFC20]    Cerf, V., "ASCII format for network interchange", RFC 20,
              October 1969.

   [RFC5536]  Murchison, K., Lindsey, C., and D. Kohn, "Netnews Article
              Format", RFC 5536, November 2009.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence", RFC
              6121, March 2011.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", RFC 6376, September
              2011.

Appendix A. Acknowledgements 🫶

big thanks to Dave Cridland, Stephen Farrell, Russ Housley, and Alexey Melnikov for their feedback 💕

Author's Address 💌

   Peter Saint-Andre
   &yet

   EMail: ietf@stpeter.im