The Jabber-ID Header FieldCisco Systems, Inc.1899 Wynkoop Street, Suite 600DenverCO80202USA+1-303-308-3282psaintan@cisco.comThis document defines a header field that enables the author of an email or netnews message to include a Jabber Identifier in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.The Extensible Messaging and Presence Protocol (XMPP), documented in , 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 , and XMPP addresses are still referred to as Jabber IDs.Because almost all human users of Jabber/XMPP instant messaging and presence systems also use email systems and because many such users also use netnews systems , it can be helpful for such users to specify their Jabber IDs in the messages they author. The Jabber-ID header field provides a standard location for that information. Members of the XMPP instant messaging and presence community have been experimenting with this usage for many years. As a result, this document provides informational documentation regarding the syntax and implementation of the Jabber-ID header field, including the information necessary to register the Jabber-ID field in the Provisional Message Header Field Registry maintained by the IANA.The syntax of the Jabber-ID header field is defined below using Augmented Backus-Naur Form , where the "pathxmpp" rule is defined in the XMPP URI specification and the remaining rules are defined in the Internet Message Format specification :Although a native XMPP address can contain virtually any Unicode character , the header of an email or netnews message is allowed to contain only printable ASCII characters (see Section 2 of ). Therefore, any characters outside the ASCII range in an XMPP address needs to be converted to ASCII before inclusion in a Jabber-ID header field, in accordance with the rules specified in the XMPP URI specification . 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 specified in the URI specification .The Jabber-ID header field is associated with the author of the message; see . If the "From:" header field of an email message contains more than one mailbox, the Jabber-ID header field ought not be added to the message. There ought to be no more than one instance of the Jabber-ID header field.For a user whose XMPP address is "juliet@example.com", the corresponding Jabber-ID header field would be: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: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 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".Following the rules in 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):Upon receiving an email 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 specified in , thus yielding a Jabber Idenfitier that can be used for native communication on an XMPP network.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 Identifier (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 initiate a text chat with the author.Jabber-IDmail, netnewsprovisionalPeter Saint-Andre RFC &rfc.number;See RFC 6120Note to IANA and RFC Editor: Please replace "XXXX" with the number of the RFC that results from this specification.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 ought not depend 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 ).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. Care ought to be taken in balancing the benefits of open information exchange against the potential costs of unwanted communication. An email or netnews user agent that is capable of including the Jabber-ID header field in outgoing email or netnews messages ought 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.The security considerations discussed in , , , , and also apply to the Jabber-ID message header.Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)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]Augmented BNF for Syntax Specifications: ABNFInternet 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]Internet Message FormatQualcomm Incorporated5775 Morehouse DriveSan DiegoCA92121-1714US+1 858 651 4478presnick@qualcomm.comhttp://www.qualcomm.com/~presnick/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.Extensible Messaging and Presence Protocol (XMPP): CoreThe 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]ASCII format for network interchangeUniversity California Los Angeles (UCLA)For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0.Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
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.
Internationalized Resource Identifiers (IRIs)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.Netnews Article FormatThis 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]Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and PresenceThis 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]DomainKeys Identified Mail (DKIM) SignaturesDomainKeys 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]The Unicode Standard, Version 6.2The Unicode Consortium