One document matched: draft-saintandre-jabberid-13.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="info" docName="draft-saintandre-jabberid-13" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="Jabber-ID">The Jabber-ID Header Field</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>&yet</organization>
<address>
<email>ietf@stpeter.im</email>
</address>
</author>
<date/>
<abstract>
<t>This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t>The Extensible Messaging and Presence Protocol (XMPP), documented in <xref target='RFC6120'/>, is a streaming XML technology that enables any two entities on a network to exchange well-defined but extensible XML elements (called "XML stanzas") in close to real time. Given XMPP's heritage in the Jabber open-source community, one of the primary uses for XMPP is instant messaging and presence as documented in <xref target='RFC6121'/>, and XMPP addresses are still referred to as Jabber IDs.</t>
<t>Because almost all human users of Jabber/XMPP instant messaging and presence systems also use email systems <xref target='RFC5322'/> and because many also use netnews systems <xref target='RFC5536'/>, it can be helpful for them to associate their Jabber IDs with the messages they author. The Jabber-ID header field provides a standard location for that information.</t>
<t>Members of the XMPP instant messaging and presence community have been experimenting with the Jabber-ID header field for many years. This document defines the syntax and usage of the Jabber-ID header field, including the information necessary to register the field in the Provisional Message Header Field Registry maintained by the IANA.</t>
</section>
<section title="Syntax" anchor="syntax">
<t>The syntax of the Jabber-ID header field is defined below using Augmented Backus-Naur Form <xref target='RFC5234'/>, where the "pathxmpp" rule is defined in the XMPP URI specification <xref target='RFC5122'/> and the remaining rules are defined in the Internet Message Format specification <xref target='RFC5322'/>:</t>
<figure>
<artwork><![CDATA[
Jabber-ID = SP *WSP pathxmpp *WSP CRLF
]]></artwork>
</figure>
<t>Although a native XMPP address can contain virtually any Unicode character <xref target='UNICODE'/>, the header of an email or netnews message is allowed to contain only printable ASCII characters (see Section 2 of <xref target='RFC5322'/>). Therefore, any characters outside the ASCII range <xref target='RFC20'/> in an XMPP address need to be converted to ASCII before inclusion in a Jabber-ID header field, in accordance with the rules defined in the XMPP URI specification <xref target='RFC5122'/>. In addition, characters allowed in XMPP localparts and XMPP resourceparts but disallowed by the relevant URI rules need to be percent-encoded in accordance with the rules defined in the URI specification <xref target='RFC3986'/>.</t>
</section>
<section title="Usage" anchor="usage">
<section title="Inclusion" anchor="inclusion">
<t>The Jabber-ID header field is associated with the author of the message; see <xref target='RFC5322'/>. If the "From:" header field of an email message contains more than one mailbox, it is best not to add the Jabber-ID header field to the message. To reduce the possibility of confusion, it is best to include only one instance of the Jabber-ID header field in a given message.</t>
</section>
<section title="Generation" anchor="generation">
<t>For a user whose XMPP address is "juliet@example.com", the corresponding Jabber-ID header field would be:</t>
<figure>
<artwork><![CDATA[
Jabber-ID: juliet@example.com
]]></artwork>
</figure>
<t>As noted, non-ASCII characters in XMPP addresses need to be converted into ASCII before inclusion in a Jabber-ID header field. Consider the following XMPP address:</t>
<figure>
<artwork><![CDATA[
jiři@čechy.example
]]></artwork>
</figure>
<t>In the foregoing example, the string "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON and the string "č" stands for the Unicode character LATIN SMALL LETTER C WITH CARON, following the "XML Notation" used in <xref target='RFC3987'/> to represent characters that cannot be rendered in ASCII-only documents. For those who do not read Czech, this example could be Anglicized as "george@czech-lands.example".</t>
<t>Following the rules in <xref target='RFC5122'/> and the Jabber-ID header field syntax, the resulting header field might be as shown below (note that this representation includes folding white space, which is allowed in accordance with the ABNF):</t>
<figure>
<artwork><![CDATA[
Jabber-ID:
ji%C5%99i@%C4%8Dechy.example
]]></artwork>
</figure>
</section>
<section title="Processing" anchor="processing">
<t>Upon receiving an email message or netnews message containing a Jabber-ID header field, a user agent that supports the field ought to process the field by converting any escaped characters to characters outside the ASCII range in accordance with the rules defined in <xref target='RFC5122'/>, thus yielding a Jabber ID that can be used for native communication on the XMPP network.</t>
</section>
<section title="Disposition" anchor="disposition">
<t>A user agent that has processed a Jabber-ID header field can provide appropriate interface elements if it has independent information linking the author of the email or netnews message with the specified Jabber ID (e.g., via a user-controlled address book or automated directory lookup). Such interface elements might include an indicator of "presence" (i.e., that the author is online and available for communication via XMPP) if the user is subscribed to the presence of the author, and an element that enables the user to send an instant message or initiate a text chat session with the author.</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>The IANA includes "Jabber-ID" in the Provisional Message Header Field Names Registry. The completed registration template follows.</t>
<t>
<list style='hanging'>
<t hangText='Header field name:'>Jabber-ID</t>
<t hangText='Applicable protocol:'>mail, netnews</t>
<t hangText='Status:'>provisional</t>
<t hangText='Author/Change contoller'>Peter Saint-Andre <mailto:stpeter@jabber.org></t>
<t hangText='Specification document:'>RFC XXXX</t>
<t hangText='Related information:'>See RFC 6120</t>
</list>
</t>
<t>[[Note to IANA: The Provisional Message Header Field Names Registry currently includes an entry for "Jabber-ID", with a reference to draft-saintandre-jabberid-08. Please update the registry entry to refer to "RFC XXXX", where "XXXX" is the number of the RFC that results from this specification.]]</t>
<t>[[Note to RFC Editor: Please replace "XXXX" with the number of the RFC that results from this specification. Please remove this note, along with the foregoing note, upon publication.]]</t>
</section>
<section title="Security and Privacy Considerations" anchor="security">
<t>Message headers are an existing standard and are designed to easily accommodate new types. Although the Jabber-ID header field could be forged, this problem is inherent in Internet email and netnews; however, because a forged Jabber-ID header field might break automated processing, applications are discouraged from depending on the Jabber-ID header field to indicate the authenticity of an email or netnews message, or the identity of its author or sender. Including the Jabber-ID header field among the signer header fields in DomainKeys Identified Mail (DKIM) can help to mitigate against forging of the header (see <xref target='RFC6376'/>).</t>
<t>Advertising XMPP addresses in email or netnews headers might make it easier for malicious users to harvest XMPP addresses and therefore to send unsolicited bulk communications to the users or applications represented by those addresses. Providing such a binding between an email address and a Jabber ID can also increase the possibility of drawing a connection between different kinds of communications traffic for purposes of surveillance and other breaches of privacy. Care ought to be taken in balancing the benefits of open information exchange against the potential costs of security and privacy weaknesses. An email or netnews user agent that is capable of including the Jabber-ID header field in outgoing email or netnews messages needs to provide an option for its user to disable inclusion of the Jabber-ID header field generally, on a per-recipient basis, and on a per-message basis.</t>
<t>The security and privacy considerations discussed in <xref target='RFC3986'/>, <xref target='RFC3987'/>, <xref target='RFC5122'/>, <xref target='RFC6120'/>, and <xref target='RFC6121'/> also apply to the Jabber-ID message header.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='214067' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC3987'>
<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author initials='M.' surname='Duerst' fullname='M. Duerst'>
<organization /></author>
<author initials='M.' surname='Suignard' fullname='M. Suignard'>
<organization /></author>
<date year='2005' month='January' />
<abstract>
<t>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.</t><t> The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.</t></abstract></front>
<seriesInfo name='RFC' value='3987' />
<format type='TXT' octets='111190' target='http://www.rfc-editor.org/rfc/rfc3987.txt' />
</reference>
<reference anchor='RFC5122'>
<front>
<title>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2008' month='February' />
<abstract>
<t>This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5122' />
<format type='TXT' octets='55566' target='http://www.rfc-editor.org/rfc/rfc5122.txt' />
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='Peter W.
Resnick' role='editor'>
<organization>Qualcomm Incorporated</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-1714</code>
<country>US</country></postal>
<phone>+1 858 651 4478</phone>
<email>presnick@qualcomm.com</email>
<uri>http://www.qualcomm.com/~presnick/</uri></address></author>
<date year='2008' month='October' />
<abstract>
<t>This document specifies the Internet
Message Format (IMF), a syntax for text messages
that are sent between computer users, within
the framework of "electronic mail"
messages. This specification is a revision of
Request For Comments (RFC) 2822, which
itself superseded Request For Comments (RFC)
822, "Standard for the Format of ARPA
Internet Text Messages", updating it to
reflect current practice and incorporating
incremental changes that were specified in
other RFCs.</t></abstract></front>
<seriesInfo name='RFC' value='5322' />
<format type='TXT' octets='122322' target='http://www.rfc-editor.org/rfc/rfc5322.txt' />
<format type='HTML' octets='213393' target='http://xml.resource.org/public/rfc/html/rfc5322.html' />
<format type='XML' octets='174234' target='http://xml.resource.org/public/rfc/xml/rfc5322.xml' />
</reference>
<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.3.0/">
<front>
<title>The Unicode Standard, Version 6.3</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2013" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC20'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.' surname='Cerf' fullname='Vint Cerf'>
<organization>University California Los Angeles (UCLA)</organization></author>
<date year='1969' day='16' month='October' />
<abstract>
<t>For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.</t></abstract></front>
<seriesInfo name='RFC' value='20' />
<format type='TXT' octets='18504' target='http://www.rfc-editor.org/rfc/rfc20.txt' />
</reference>
<reference anchor='RFC5536'>
<front>
<title>Netnews Article Format</title>
<author initials='K.' surname='Murchison' fullname='K. Murchison'>
<organization /></author>
<author initials='C.' surname='Lindsey' fullname='C. Lindsey'>
<organization /></author>
<author initials='D.' surname='Kohn' fullname='D. Kohn'>
<organization /></author>
<date year='2009' month='November' />
<abstract>
<t>This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5536' />
<format type='TXT' octets='71817' target='http://www.rfc-editor.org/rfc/rfc5536.txt' />
</reference>
<reference anchor='RFC6121'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6121' />
<format type='TXT' octets='244800' target='http://www.rfc-editor.org/rfc/rfc6121.txt' />
</reference>
<reference anchor='RFC6376'>
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'>
<organization /></author>
<author initials='M.' surname='Kucherawy' fullname='M. Kucherawy'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.</t><t> This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6376' />
<format type='TXT' octets='176999' target='http://www.rfc-editor.org/rfc/rfc6376.txt' />
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Dave Cridland, Stephen Farrell, Russ Housley, and Alexey Melnikov for their feedback.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:19 |