draft-ietf-xmpp-address-00.txt   draft-ietf-xmpp-address-01.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track April 7, 2010 Intended status: Standards Track July 7, 2010
Expires: October 9, 2010 Expires: January 8, 2011
Extensible Messaging and Presence Protocol (XMPP): Address Format Extensible Messaging and Presence Protocol (XMPP): Address Format
draft-ietf-xmpp-address-00 draft-ietf-xmpp-address-01
Abstract Abstract
This document defines the format for addresses used in the Extensible This document defines the format for addresses used in the Extensible
Messaging and Presence Protocol (XMPP), including support for non- Messaging and Presence Protocol (XMPP), including support for non-
ASCII characters. ASCII characters.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2010. This Internet-Draft will expire on January 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Domainpart . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 6
3. Internationalization Considerations . . . . . . . . . . . . . 7 3. Internationalization Considerations . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Stringprep Profiles . . . . . . . . . . . . . . . . . . . 7 4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 8
4.2. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 8 4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Address Forging . . . . . . . . . . . . . . . . . . . 8 4.3. Confusable Characters . . . . . . . . . . . . . . . . . . 8
4.2.2. Address Mimicking . . . . . . . . . . . . . . . . . . 9 4.4. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Address Forging . . . . . . . . . . . . . . . . . . . 9
4.4.2. Address Mimicking . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 10 5.1. Nodeprep Profile of Stringprep . . . . . . . . . . . . . . 10
5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 10 5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 11
6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11 6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 15 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 16
A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 16 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 16
A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 16 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 16
A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 16 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 17
A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 17
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18
B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 18 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 18
B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 18 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 18 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 18
B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 18 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 18
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 18 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19
Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 18 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19
Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19 Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Extensible Messaging and Presence Protocol [XMPP] is an The Extensible Messaging and Presence Protocol [XMPP] is an
application profile of the Extensible Markup Language [XML] for application profile of the Extensible Markup Language [XML] for
streaming XML data in close to real time between any two or more streaming XML data in close to real time between any two or more
network-aware entities. The address format for such entities was network-aware entities. The address format for such entities was
originally developed in the Jabber open-source community in 1999 originally developed in the Jabber open-source community in 1999
(thus for historical reasons the native address of an XMPP entity is (thus for historical reasons the native address of an XMPP entity is
called a Jabber Identifier or JID). In essence, a JID contains up to called a Jabber Identifier or JID). In essence, a JID contains up to
three parts, in the arrangement <localpart@domainpart/resourcepart> three parts, in the arrangement <localpart@domainpart/resourcepart>
(where the localpart and resourcepart are both discretionary and each (where the localpart and resourcepart are both discretionary and each
part can contain nearly any Unicode code point, encoded according to part can contain nearly any Unicode code point [UNICODE], encoded
[UTF-8]). The JID format was first described by [XEP-0029] in 2002- according to [UTF-8]). The JID format was first described by
2003, then defined canonically by [RFC3920] in 2004. As defined in [XEP-0029] in 2002, then defined canonically by [RFC3920] in 2004.
RFC 3920, the XMPP address format re-uses the "stringprep" technology As defined in RFC 3920, the XMPP address format re-uses the
for preparation of non-ASCII characters [STRINGPREP], including the "stringprep" technology for preparation of non-ASCII characters
Nameprep profile for internationalized domain names as specified in [STRINGPREP], including the Nameprep profile for internationalized
[NAMEPREP] and [IDNA2003] as well as two XMPP-specific profiles for domain names as specified in [NAMEPREP] and [IDNA2003] along with two
the localpart and resourcepart. Since the publication of RFC 3920, XMPP-specific profiles for the localpart and resourcepart. Since the
IDNA2003 has been superseded by IDNA2008, and other protocols that publication of RFC 3920, IDNA2003 has been superseded by IDNA2008
use stringprep (including XMPP) have begun to migrate away from that (see [IDNA-PROTO] and related documents). As a result, other
technology. Because work on improved handling of internationalized protocols that use stringprep (including XMPP) have begun to migrate
addresses is currently in progress, specifying the XMPP address from stringprep toward more "modern" approaches. Because work on
format in the revisions to RFC 3920 would unacceptably delay the improved handling of internationalized addresses is currently in
revision process. Therefore, this specification provides progress, specifying the XMPP address format in the specification
documentation of the XMPP address format from RFC 3920, with the that obsoletes RFC 3920 would unacceptably delay the revision
intent that it can be superseded once work on a new approach to process. Therefore, this specification provides updated
internationalization is complete. documentation of the XMPP address format (essentially copied from RFC
3920), with the intent that it can be superseded once work on a new
approach to internationalization is complete.
2. Addresses 2. Addresses
2.1. Overview 2.1. Overview
An ENTITY is anything that is network-addressable and that can An ENTITY is anything that is network-addressable and that can
communicate using XMPP. For historical reasons, the native address communicate using XMPP. For historical reasons, the native address
of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID
contains a set of ordered elements formed of an XMPP localpart, contains a set of ordered elements formed of an XMPP localpart,
domainpart, and resourcepart. domainpart, and resourcepart.
The syntax for a JID is defined as follows using the Augmented The syntax for a JID is defined as follows using the Augmented
Backus-Naur Form as specified in [ABNF]. Backus-Naur Form as specified in [ABNF].
jid = [ localpart "@" ] domain [ "/" resource ] jid = [ localpart "@" ] domainpart [ "/" resourcepart ]
localpart = 1*(nodepoint) localpart = 1*(nodepoint)
; a "nodepoint" is a UTF-8 encoded Unicode code ; a "nodepoint" is a UTF-8 encoded Unicode code
; point that satisfies the Nodeprep profile of ; point that satisfies the Nodeprep profile of
; stringprep ; stringprep
domain = fqdn / address-literal domainpart = IP-literal / IPv4address / ifqdn
fqdn = *(ldhlabel ".") toplabel ; the "IPv4address" and "IP-literal" rules are
ldhlabel = letdig [*61(ldh) letdig] ; defined in RFC 3986, and the first-match-wins
toplabel = ALPHA *61(ldh) letdig ; (a.k.a. "greedy") algorithm described in RFC
letdig = ALPHA / DIGIT ; 3986 applies to the matching process
ldh = ALPHA / DIGIT / "-" ifqdn = 1*(namepoint)
address-literal = IPv4address / IPv6address ; a "namepoint" is a UTF-8 encoded Unicode
; the "IPv4address" and "IPv6address" rules are ; code point that satisfies the Nameprep
; defined in RFC 3986 ; profile of stringprep
resource = 1*(resourcepoint) resourcepart = 1*(resourcepoint)
; a "resourcepoint" is a UTF-8 encoded Unicode ; a "resourcepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Resourceprep ; code point that satisfies the Resourceprep
; profile of stringprep ; profile of stringprep
All JIDs are based on the foregoing structure. One common use of All JIDs are based on the foregoing structure. One common use of
this structure is to identify a messaging and presence account, the this structure is to identify a messaging and presence account, the
server that hosts the account, and a connected resource (e.g., a server that hosts the account, and a connected resource (e.g., a
specific device) in the form of <localpart@domain/resource>. specific device) in the form of <localpart@domain/resource>.
However, localparts other than clients are possible; for example, a However, localparts other than clients are possible; for example, a
specific chat room offered by a multi-user conference service (see specific chat room offered by a multi-user chat service (see
[XEP-0045]) could be addressed as <room@service> (where "room" is the [XEP-0045]) is addressed as <room@service> (where "room" is the name
name of the chat room and "service" is the hostname of the multi-user of the chat room and "service" is the hostname of the multi-user chat
conference service) and a specific occupant of such a room could be service) and a specific occupant of such a room could be addressed as
addressed as <room@service/nick> (where "nick" is the occupant's room <room@service/nick> (where "nick" is the occupant's room nickname).
nickname). Many other JID types are possible (e.g., <domain/ Many other JID types are possible (e.g., <domain/resource> could be a
resource> could be a server-side script or service). server-side script or service).
Each allowable portion of a JID (localpart, domainpart, and Each allowable portion of a JID (localpart, domainpart, and
resourcepart) MUST NOT be more than 1023 bytes in length, resulting resourcepart) MUST NOT be zero bytes in length and MUST NOT be more
in a maximum total size (including the '@' and '/' separators) of than 1023 bytes in length, resulting in a maximum total size
3071 bytes. (including the '@' and '/' separators) of 3071 bytes.
Note: While the format of a JID is consistent with [URI], an Although the format of a JID is roughly consistent with [URI], an
entity's address on an XMPP network MUST be represented as a JID entity's address on an XMPP network MUST be represented as a JID
(without a URI scheme) and not a [URI] or [IRI] as specified in (without a URI scheme) and not a [URI] or [IRI] as specified in
[XMPP-URI]; the latter specification is provided only for [XMPP-URI]; the latter specification is provided only for
identification and interaction outside the context of the XMPP identification and interaction outside the context of the XMPP wire
wire protocol itself. protocol itself.
Implementation Note: When dividing a JID into its component parts,
an implementation needs to match the separator characters '@' and
'/' before applying any transformation algorithms, which might
decompose certain Unicode code points to the separator characters
(e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040
COMMERCIAL AT).
2.2. Domainpart 2.2. Domainpart
The DOMAINPART of a JID is that portion after the '@' character (if The DOMAINPART of a JID is that portion after the '@' character (if
any) and before the '/' character (if any); it is the primary any) and before the '/' character (if any); it is the primary
identifier and is the only REQUIRED element of a JID (a mere identifier and is the only REQUIRED element of a JID (a mere
domainpart is a valid JID). Typically a domainpart identifies the domainpart is a valid JID). Typically a domainpart identifies the
"home" server to which clients connect for XML routing and data "home" server to which clients connect for XML routing and data
management functionality. However, it is not necessary for an XMPP management functionality. However, it is not necessary for an XMPP
domainpart to identify an entity that provides core XMPP server domainpart to identify an entity that provides core XMPP server
functionality (e.g., a domainpart can identity an entity such as a functionality (e.g., a domainpart can identify an entity such as a
multi-user conference service, a publish-subscribe service, or a user multi-user chat service, a publish-subscribe service, or a user
directory). directory).
Note: A single server can service multiple domainparts, i.e.,
multiple local domains; this is typically referred to as virtual
hosting.
The domainpart for every server or service that will communicate over The domainpart for every server or service that will communicate over
a network SHOULD be a fully qualified domain name (see [DNS]); while a network SHOULD be a fully qualified domain name or "FQDN" (see
the domainpart MAY be either an Internet Protocol (IPv4 or IPv6) [DNS]); although the domainpart MAY be either an Internet Protocol
address or a text label that is resolvable on a local network (IPv4 or IPv6) address or a text label that is resolvable on a local
(commonly called an "unqualified hostname"), it is possible that network (commonly called an "unqualified hostname"), it is possible
domainparts that are IP addresses will not be acceptable to other that domainparts that are IP addresses will not be acceptable to
services for the sake of interdomain communication. Furthermore, other services for the sake of interdomain communication.
domainparts that are unqualified hostnames MUST NOT be used on public Furthermore, domainparts that are unqualified hostnames MUST NOT be
networks but MAY be used on private networks. used on public networks but MAY be used on private networks.
Note: If the domainpart includes a final character considered to Note: If the domainpart includes a final character considered to
be a label separator (dot) by [IDNA2003] or [DNS], this character be a label separator (dot) by [IDNA2003] or [DNS], this character
MUST be stripped from the domainpart before the JID of which it is MUST be stripped from the domainpart before the JID of which it is
a part is used for the purpose of routing an XML stanza, comparing a part is used for the purpose of routing an XML stanza, comparing
against another JID, or constructing an [XMPP-URI]; in particular, against another JID, or constructing an [XMPP-URI]; in particular,
the character MUST be stripped before any other canonicalization the character MUST be stripped before any other canonicalization
steps are taken, such as application of the [NAMEPREP] profile of steps are taken, such as application of the [NAMEPREP] profile of
[STRINGPREP] or completion of the ToASCII operation as described [STRINGPREP] or completion of the ToASCII operation as described
in [IDNA2003]. in [IDNA2003].
A domainpart MUST be an "internationalized domain name" as defined in A domainpart consisting of a fully qualified domain name MUST be an
[IDNA2003], that is, "a domain name in which every label is an "internationalized domain name" as defined in [IDNA2003], that is, "a
internationalized label". When preparing a text label (consisting of domain name in which every label is an internationalized label".
a sequence of Unicode code points) for representation as an When preparing a text label (consisting of a sequence of properly-
encoded Unicode code points) for representation as an
internationalized label in the process of constructing an XMPP internationalized label in the process of constructing an XMPP
domainpart or comparing two XMPP domainparts, an application MUST domainpart or comparing two XMPP domainparts, an application MUST
ensure that for each text label it is possible to apply without ensure that for each text label it is possible to apply without
failing the ToASCII operation specified in [IDNA2003] with the failing the ToASCII operation specified in [IDNA2003] with the
UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other
than letters, digits, and hyphens). If the ToASCII operation can be than letters, digits, and hyphens). If the ToASCII operation can be
applied without failing, then the label is an internationalized applied without failing, then the label is an internationalized
label. An internationalized domain name (and therefore an XMPP label. An internationalized domain name (and therefore an XMPP
domainpart) is constructed from its constituent internationalized domainpart) is constructed from its constituent internationalized
labels by following the rules specified in [IDNA2003]. labels by following the rules specified in [IDNA2003].
skipping to change at page 6, line 21 skipping to change at page 6, line 24
In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a
"domain name slot". "domain name slot".
2.3. Localpart 2.3. Localpart
The LOCALPART of a JID is an optional identifier placed before the The LOCALPART of a JID is an optional identifier placed before the
domainpart and separated from the latter by the '@' character. domainpart and separated from the latter by the '@' character.
Typically a localpart uniquely identifies the entity requesting and Typically a localpart uniquely identifies the entity requesting and
using network access provided by a server (i.e., a local account), using network access provided by a server (i.e., a local account),
although it can also represent other kinds of entities (e.g., a chat although it can also represent other kinds of entities (e.g., a chat
room associated with a multi-user conference service). The entity room associated with a multi-user chat service). The entity
represented by an XMPP localpart is addressed within the context of a represented by an XMPP localpart is addressed within the context of a
specific domain. specific domain.
A localpart MUST NOT be zero bytes in length and, as for all portions A localpart MUST NOT be zero bytes in length and MUST NOT be more
of a JID, MUST NOT be more than 1023 bytes in length. than 1023 bytes in length.
A localpart MUST be formatted such that the Nodeprep profile of A localpart MUST be formatted such that the Nodeprep profile of
[STRINGPREP] can be applied without failing (see Appendix A). Before [STRINGPREP] can be applied without failing (see Appendix A). Before
comparing two localparts, an application MUST first ensure that the comparing two localparts, an application MUST first ensure that the
Nodeprep profile has been applied to each identifier (the profile Nodeprep profile has been applied to each identifier (the profile
need not be applied each time a comparison is made, as long as it has need not be applied each time a comparison is made, as long as it has
been applied before comparison). been applied before comparison).
2.4. Resourcepart 2.4. Resourcepart
The resourcepart of a JID is an optional identifier placed after the The resourcepart of a JID is an optional identifier placed after the
domainpart and separated from the latter by the '/' character. A domainpart and separated from the latter by the '/' character. A
resourcepart can modify either a <localpart@domain> address or a mere resourcepart can modify either a <localpart@domainpart> address or a
<domain> address. Typically a resourcepart uniquely identifies a mere <domainpart> address. Typically a resourcepart uniquely
specific connection (e.g., a device or location) or object (e.g., a identifies a specific connection (e.g., a device or location) or
participant in a multi-user conference room) belonging to the entity object (e.g., an occupant in a multi-user chat room) belonging to the
associated with an XMPP localpart at a local domain. entity associated with an XMPP localpart at a local domain.
When an XMPP address does not include a resourcepart (i.e., when it When an XMPP address does not include a resourcepart (i.e., when it
is of the form <domain> or <localpart@domain>), it is referred to as is of the form <domainpart> or <localpart@domainpart>), it is
a BARE JID. When an XMPP address includes a resourcepart (i.e., when referred to as a BARE JID. When an XMPP address includes a
it is of the form <domain/resource> or <localpart@domain/resource>), resourcepart (i.e., when it is of the form <domain/resource> or
is referred to as a FULL JID. <localpart@domain/resource>), is referred to as a FULL JID.
A resourcepart MUST NOT be zero bytes in length and, as for all A resourcepart MUST NOT be zero bytes in length and MUST NOT be more
portions of a JID, MUST NOT be more than 1023 bytes in length. than 1023 bytes in length.
A resourcepart MUST be formatted such that the Resourceprep profile A resourcepart MUST be formatted such that the Resourceprep profile
of [STRINGPREP] can be applied without failing (see Appendix B). of [STRINGPREP] can be applied without failing (see Appendix B).
Before comparing two resourceparts, an application MUST first ensure Before comparing two resourceparts, an application MUST first ensure
that the Resourceprep profile has been applied to each identifier that the Resourceprep profile has been applied to each identifier
(the profile need not be applied each time a comparison is made, as (the profile need not be applied each time a comparison is made, as
long as it has been applied before comparison). long as it has been applied before comparison).
Note: For historical reasons, the term "resource identifier" is Note: For historical reasons, the term "resource identifier" is
often used in XMPP to refer to the optional portion of an XMPP often used in XMPP to refer to the optional portion of an XMPP
address that follows the domainpart and the "/" separator address that follows the domainpart and the "/" separator
character; to help prevent confusion between an XMPP "resource character; to help prevent confusion between an XMPP "resource
identifier" and the meanings of "resource" and "identifier" identifier" and the meanings of "resource" and "identifier"
provided in Section 1.1 of [URI], this specification typically provided in Section 1.1 of [URI], this specification uses the term
uses the term "resourcepart" instead of "resource identifier" (as "resourcepart" instead of "resource identifier" (as in RFC 3920).
in RFC 3920).
XMPP entities SHOULD consider resourceparts to be opaque strings and XMPP entities SHOULD consider resourceparts to be opaque strings and
SHOULD NOT impute meaning to any given resourcepart. In particular, SHOULD NOT impute meaning to any given resourcepart. In particular:
the use of the '/' character as a separator between the domainpart
and the resourcepart does not imply that XMPP addresses are o Use of the '/' character as a separator between the domainpart and
hierarchical in the way that, say, HTTP addresses are hierarchical; the resourcepart does not imply that XMPP addresses are
thus for example an XMPP address of the form hierarchical in the way that, say, HTTP addresses are
<localpart@domain/foo/bar> does not identify a resource "bar" that hierarchical; thus for example an XMPP address of the form
exists below a resource "foo" in a hierarchy of resources associated <localpart@domain/foo/bar> does not identify a resource "bar" that
with the entity "localpart@domain". exists below a resource "foo" in a hierarchy of resources
associated with the entity "localpart@domain".
o The '@' character is allowed in the resourcepart, and is often
used in the "nick" shown in XMPP chatrooms. For example, the JID
<room@chat.example.com/user@host> describes an entity who is an
occupant of the room <room@chat.example.com> with an (asserted)
nick of <user@host>. However, chatroom services do not
necessarily check such an asserted nick against the occupant's
real JID.
3. Internationalization Considerations 3. Internationalization Considerations
An XMPP server MUST support and enforce [IDNA2003] for domainparts, An XMPP server MUST support and enforce [IDNA2003] for domainparts,
the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and the Nodeprep (Appendix A) profile of [STRINGPREP] for localparts, and
the Resourceprep (Appendix B) profile of [STRINGPREP] for the Resourceprep (Appendix B) profile of [STRINGPREP] for
resourceparts; this enables XMPP addresses to include a wide variety resourceparts; this enables XMPP addresses to include a wide variety
of Unicode characters outside the US-ASCII range. of characters outside the US-ASCII range.
4. Security Considerations 4. Security Considerations
4.1. Stringprep Profiles 4.1. Reuse of Stringprep
XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for The security considerations described in [STRINGPREP] apply to the
processing of domainparts; for security considerations related to Nodeprep (Appendix A) and Resourceprep (Appendix B) profiles defined
Nameprep, refer to the appropriate section of [NAMEPREP]. in this document for XMPP localparts and resourceparts. The security
considerations described in [STRINGPREP] and [NAMEPREP] apply to the
Nameprep profile that is re-used here for XMPP domainparts.
In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep 4.2. Reuse of Unicode
(Appendix A) for localparts and Resourceprep (Appendix B) for
resourceparts. The security considerations described in [UNICODE-SEC] apply to the
use of Unicode characters in XMPP addresses.
4.3. Confusable Characters
The Unicode and ISO/IEC 10646 repertoires have many characters that The Unicode and ISO/IEC 10646 repertoires have many characters that
look similar. In many cases, users of security protocols might look similar (so-called "confusable characters"). In many cases,
perform visual matching, such as when comparing the names of trusted users of security protocols might perform visual matching, such as
third parties. Because it is impossible to map similar-looking when comparing the names of trusted third parties. Because it is
characters without a great deal of context (such as knowing the fonts impossible to map similar-looking characters without a great deal of
used), stringprep does nothing to map similar-looking characters context (such as knowing the fonts used), stringprep does nothing to
together, nor to prohibit some characters because they look like map similar-looking characters together, nor to prohibit some
others. characters because they look like others. Some specific suggestions
about identification and handling of confusable characters appear in
the Unicode Security Considerations [UNICODE-SEC].
A localpart can be employed as one part of an entity's address in A localpart can be employed as one part of an entity's address in
XMPP. One common usage is as the username of an instant messaging XMPP. One common usage is as the username of an instant messaging
user; another is as the name of a multi-user conference room; and user; another is as the name of a multi-user chat room; and many
many other kinds of entities could use localparts as part of their other kinds of entities could use localparts as part of their
addresses. The security of such services could be compromised based addresses. The security of such services could be compromised based
on different interpretations of the internationalized localpart; for on different interpretations of the internationalized localpart; for
example, a user entering a single internationalized localpart could example, a user entering a single internationalized localpart could
access another user's account information, or a user could gain access another user's account information, or a user could gain
access to a hidden or otherwise restricted chat room or service. access to a hidden or otherwise restricted chat room or service.
A resourcepart can be employed as one part of an entity's address in A resourcepart can be employed as one part of an entity's address in
XMPP. One common usage is as the name for an instant messaging XMPP. One common usage is as the name for an instant messaging
user's connected resource; another is as the nickname of a user in a user's connected resource; another is as the nickname of a user in a
multi-user conference room; and many other kinds of entities could multi-user chat room; and many other kinds of entities could use
use resourceparts as part of their addresses. The security of such resourceparts as part of their addresses. The security of such
services could be compromised based on different interpretations of services could be compromised based on different interpretations of
the internationalized resourcepart; for example, a user could attempt the internationalized resourcepart; for example, a user could attempt
to initiate multiple connections with the same name, or a user could to initiate multiple connections with the same name, or a user could
send a message to someone other than the intended recipient in a send a message to someone other than the intended recipient in a
multi-user conference room. multi-user chat room.
4.2. Address Spoofing Further discussion is provided under Section 4.4.2.
As discussed in [XEP-0165], there are two forms of address spoofing: 4.4. Address Spoofing
forging and mimicking.
4.2.1. Address Forging There are two forms of address spoofing: forging and mimicking.
4.4.1. Address Forging
In the context of XMPP technologies, address forging occurs when an In the context of XMPP technologies, address forging occurs when an
entity is able to generate an XML stanza whose 'from' address does entity is able to generate an XML stanza whose 'from' address does
not correspond to the account credentials with which the entity not correspond to the account credentials with which the entity
authenticated onto the network (or an authorization identity provided authenticated onto the network (or an authorization identity provided
during SASL negotiation). For example, address forging occurs if an during SASL negotiation). For example, address forging occurs if an
entity that authenticated as "juliet@im.example.com" is able to send entity that authenticated as "juliet@im.example.com" is able to send
XML stanzas from "nurse@im.example.com" or "romeo@example.net". XML stanzas from "nurse@im.example.com" or "romeo@example.net".
Address forging is difficult in XMPP systems, given the requirement Address forging is difficult in XMPP systems, given the requirement
for sending servers to stamp 'from' addresses and for receiving for sending servers to stamp 'from' addresses and for receiving
servers to verify sending domains via server-to-server servers to verify sending domains via server-to-server authentication
authentication. However, address forging is not impossible, since a (see [XMPP]). However, address forging is not impossible, since a
rogue server could forge JIDs at the sending domain by ignoring the rogue server could forge JIDs at the sending domain by ignoring the
stamping requirement. A rogue server could even forge JIDs at other stamping requirement. Therefore, an entity outside the security
domains by means of a DNS poisoning attack if [DNSSEC] is not used. perimeter of a particular server cannot reliably distinguish between
This specification does not define methods for discovering or bare JIDs of the form <localpart@domainpart> at that server and thus
counteracting such rogue servers. can authenticate only the domainpart of such JIDs with any level of
assurance. This specification does not define methods for
discovering or counteracting such rogue servers.
Note: An entity outside the security perimeter of a particular server Furthermore, it is possible for an attacker to forge JIDs at other
cannot reliably distinguish between bare JIDs of the form domains by means of a DNS poisoning attack if DNS security extensions
<localpart@domain> at that server, since the server could forge any [DNSSEC] are not used.
such JID; therefore only the domainpart can be authenticated or
authorized with any level of assurance.
4.2.2. Address Mimicking 4.4.2. Address Mimicking
Address mimicking occus when an entity provides legitimate Address mimicking occus when an entity provides legitimate
authentication credentials for and sends XML stanzas from an account authentication credentials for and sends XML stanzas from an account
whose JID appears to a human user to be the same as another JID. For whose JID appears to a human user to be the same as another JID. For
example, in some XMPP clients the address "paypa1@example.org" example, in some XMPP clients the address "paypa1@example.org"
(spelled with the number one as the final character of the localpart) (spelled with the number one as the final character of the localpart)
might appear to be the same as "paypal@example.org (spelled with the might appear to be the same as "paypal@example.org (spelled with the
lower-case version of the letter "L"), especially on casual visual lower-case version of the letter "L"), especially on casual visual
inspection; this phenomenon is sometimes called "typejacking". A inspection; this phenomenon is sometimes called "typejacking". A
more sophisticated example of address mimicking might involve the use more sophisticated example of address mimicking might involve the use
of characters from outside the US-ASCII range, such as the Cherokee of characters from outside the US-ASCII range, such as the Cherokee
characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead
of the US-ASCII characters "STPETER". of the US-ASCII characters "STPETER".
In some examples of address mimicking, it is unlikely that the In some examples of address mimicking, it is unlikely that the
average user could tell the difference between the real JID and the average user could tell the difference between the real JID and the
fake JID. (Naturally, there is no way to distinguish with full fake JID. (Indeed, there is no way to distinguish with full
certainty which is the fake JID and which is the real JID; in some certainty which is the fake JID and which is the real JID; in some
communication contexts, the JID with Cherokee characters might be the communication contexts, the JID with Cherokee characters might be the
real JID and the JID with US-ASCII characters might thus appear to be real JID and the JID with US-ASCII characters might thus appear to be
the fake JID.) Because JIDs can contain almost any Unicode the fake JID.) Because JIDs can contain almost any Unicode
character, it can be relatively easy to mimic some JIDs in XMPP character, it can be relatively easy to mimic some JIDs in XMPP
systems. The possibility of address mimicking introduces security systems. The possibility of address mimicking introduces security
vulnerabilities of the kind that have also plagued the World Wide vulnerabilities of the kind that have also plagued the World Wide
Web, specifically the phenomenon known as phishing. Web, specifically the phenomenon known as phishing.
Mimicked addresses that involve characters from only one character As noted in [IDNA-DEFS], "there are no comprehensive technical
set or from the character set typically employed by a particular user solutions to the problems of confusable characters". Mimicked JIDs
are not easy to combat (e.g., the simple typejacking attack that involve characters from only one character set or from the
previously described, which relies on a surface similarity between character set typically employed by a particular user are not easy to
the characters "1" and "l" in some presentations). However, mimicked combat (e.g., the simple typejacking attack previously described,
addresses that involve characters from more than one character set, which relies on a surface similarity between the characters "1" and
or from a character set not typically employed by a particular user, "l" in some presentations). However, mimicked addresses that involve
can be mitigated somewhat through intelligent presentation. In characters from more than one character set, or from a character set
particular, every human user of an XMPP technology presumably has a not typically employed by a particular user, can be mitigated
preferred language (or, in some cases, a small set of preferred somewhat through intelligent presentation. In particular, every
languages), which an XMPP application SHOULD gather either explicitly human user of an XMPP technology presumably has a preferred language
from the user or implicitly via the operating system of the user's (or, in some cases, a small set of preferred languages), which an
device. Furthermore, every language has a range (or a small set of XMPP application SHOULD gather either explicitly from the user or
ranges) of characters normally used to represent that language in implicitly via the operating system of the user's device.
textual form. Therefore, an XMPP application SHOULD warn the user Furthermore, every language has a range (or a small set of ranges) of
when presenting a JID that uses characters outside the normal range characters normally used to represent that language in textual form.
of the user's preferred language(s). This recommendation is not Therefore, an XMPP application SHOULD warn the user when presenting a
intended to discourage communication across language communities; JID that uses characters outside the normal range of the user's
instead, it recognizes the existence of such language communities and preferred language(s). This recommendation is not intended to
encourages due caution when presenting unfamiliar character sets to discourage communication across language communities; instead, it
human users. recognizes the existence of such language communities and encourages
due caution when presenting unfamiliar character sets to human users.
For more detailed recommendations regarding prevention of address
mimicking in XMPP systems, refer to [XEP-0165].
5. IANA Considerations 5. IANA Considerations
The following sections update the registrations provided in The following sections update the registrations provided in
[RFC3920]. [RFC3920].
5.1. Nodeprep Profile of Stringprep 5.1. Nodeprep Profile of Stringprep
The Nodeprep profile of stringprep is defined under Nodeprep The Nodeprep profile of stringprep is defined under Nodeprep
(Appendix A). The IANA has registered Nodeprep in the stringprep (Appendix A). The IANA has registered Nodeprep in the stringprep
skipping to change at page 11, line 24 skipping to change at page 11, line 42
6. Conformance Requirements 6. Conformance Requirements
This section describes a protocol feature set that summarizes the This section describes a protocol feature set that summarizes the
conformance requirements of this specification. This feature set is conformance requirements of this specification. This feature set is
appropriate for use in software certification, interoperability appropriate for use in software certification, interoperability
testing, and implementation reports. For each feature, this section testing, and implementation reports. For each feature, this section
provides the following information: provides the following information:
o A human-readable name o A human-readable name
o An informational description o An informational description
o A reference to the particular section of this document that o A reference to the particular section of this document that
normatively defines the feature normatively defines the feature
o Whether the feature applies to the Client role, the Server role, o Whether the feature applies to the Client role, the Server role,
or both (where "N/A" signifies that the feature is not applicable or both (where "N/A" signifies that the feature is not applicable
to the specified role) to the specified role)
o Whether the feature MUST or SHOULD be implemented, where the o Whether the feature MUST or SHOULD be implemented, where the
capitalized terms are to be understood as described in [TERMS] capitalized terms are to be understood as described in [KEYWORDS]
Note: The feature set specified here attempts to adhere to the The feature set specified here attempts to adhere to the concepts and
concepts and formats proposed by Larry Masinter within the IETF's formats proposed by Larry Masinter within the IETF's NEWTRK Working
NEWTRK Working Group in 2005, as captured in [INTEROP]. Although Group in 2005, as captured in [INTEROP]. Although this feature set
this feature set is more detailed than called for by [REPORTS], it is more detailed than called for by [REPORTS], it provides a suitable
provides a suitable basis for the generation of implementation basis for the generation of implementation reports to be submitted in
reports to be submitted in support of advancing this specification support of advancing this specification from Proposed Standard to
from Proposed Standard to Draft Standard in accordance with Draft Standard in accordance with [PROCESS].
[PROCESS].
Feature: address-domain-length Feature: address-domain-length
Description: Ensure that the domainpart of an XMPP address is Description: Ensure that the domainpart of an XMPP address is at
limited to 1023 bytes in length. least one byte in length and at most 1023 bytes in length.
Section: Section 2.2 Section: Section 2.2
Roles: Both MUST. Roles: Both MUST.
Feature: address-domain-prep Feature: address-domain-prep
Description: Ensure that the domainpart of an XMPP address conforms Description: Ensure that the domainpart of an XMPP address conforms
to the Nameprep profile of Stringprep. to the Nameprep profile of Stringprep.
Section: Section 2.2 Section: Section 2.2
Roles: Client SHOULD, Server MUST. Roles: Client SHOULD, Server MUST.
Feature: address-localpart-length Feature: address-localpart-length
Description: Ensure that the localpart of an XMPP address is limited Description: Ensure that the localpart of an XMPP address is at
to 1023 bytes in length. least one byte in length and at most 1023 bytes in length.
Section: Section 2.3 Section: Section 2.3
Roles: Both MUST. Roles: Both MUST.
Feature: address-localpart-prep Feature: address-localpart-prep
Description: Ensure that the localpart of an XMPP address conforms Description: Ensure that the localpart of an XMPP address conforms
to the Nodeprep profile of Stringprep. to the Nodeprep profile of Stringprep.
Section: Section 2.3 Section: Section 2.3
Roles: Client SHOULD, Server MUST. Roles: Client SHOULD, Server MUST.
Feature: address-resource-length Feature: address-resource-length
Description: Ensure that the resourcepart of an XMPP address is Description: Ensure that the resourcepart of an XMPP address is at
limited to 1023 bytes in length. least one byte in length and at most 1023 bytes in length.
Section: Section 2.4 Section: Section 2.4
Roles: Both MUST. Roles: Both MUST.
Feature: address-resource-prep Feature: address-resource-prep
Description: Ensure that the resourcepart of an XMPP address Description: Ensure that the resourcepart of an XMPP address
conforms to the Resourceprep profile of Stringprep. conforms to the Resourceprep profile of Stringprep.
Section: Section 2.2 Section: Section 2.2
Roles: Client SHOULD, Server MUST. Roles: Client SHOULD, Server MUST.
7. References 7. References
7.1. Normative References 7.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 12, line 47 skipping to change at page 13, line 20
7.1. Normative References 7.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[IDNA2003] [IDNA2003]
Faltstrom, P., Hoffman, P., and A. Costello, Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[NAMEPREP] [NAMEPREP]
Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003. RFC 3491, March 2003.
[STRINGPREP] [STRINGPREP]
Hoffman, P. and M. Blanchet, "Preparation of Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. December 2002.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
3.2.0", 2000. 3.2.0", 2000.
The Unicode Standard, Version 3.2.0 is defined by The The Unicode Standard, Version 3.2.0 is defined by The
Unicode Standard, Version 3.0 (Reading, MA, Addison- Unicode Standard, Version 3.0 (Reading, MA, Addison-
Wesley, 2000. ISBN 0-201-61633-5), as amended by the Wesley, 2000. ISBN 0-201-61633-5), as amended by the
Unicode Standard Annex #27: Unicode 3.1 Unicode Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the Unicode (http://www.unicode.org/reports/tr27/) and by the Unicode
Standard Annex #28: Unicode 3.2 Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
[UNICODE-SEC]
The Unicode Consortium, "Unicode Technical Report #36:
Unicode Security Considerations", 2008.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-06 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-09 (work
in progress), March 2010. in progress), June 2010.
7.2. Informative References 7.2. Informative References
[DNS] Mockapetris, P., "Domain names - implementation and [DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[IDNA-DEFS] [IDNA-DEFS]
Klensin, J., "Internationalized Domain Names for Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
draft-ietf-idnabis-defs-13 (work in progress), draft-ietf-idnabis-defs-13 (work in progress),
January 2010. January 2010.
[IDNA-PROTO]
Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol",
draft-ietf-idnabis-protocol-18 (work in progress),
January 2010.
[INTEROP] Masinter, L., "Formalizing IETF Interoperability [INTEROP] Masinter, L., "Formalizing IETF Interoperability
Reporting", draft-ietf-newtrk-interop-reports-00 (work in Reporting", draft-ietf-newtrk-interop-reports-00 (work in
progress), October 2005. progress), October 2005.
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision [PROCESS] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
skipping to change at page 14, line 40 skipping to change at page 15, line 23
Andre, "Service Discovery", XSF XEP 0030, June 2008. Andre, "Service Discovery", XSF XEP 0030, June 2008.
[XEP-0045] [XEP-0045]
Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
January in progress, last updated 2010. January in progress, last updated 2010.
[XEP-0060] [XEP-0060]
Millard, P., Saint-Andre, P., and R. Meijer, "Publish- Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Subscribe", XSF XEP 0060, September 2008. Subscribe", XSF XEP 0060, September 2008.
[XEP-0165]
Saint-Andre, P., "Best Practices to Prevent JID
Mimicking", XSF XEP 0165, December 2007.
[XEP-0271]
Saint-Andre, P. and R. Meijer, "XMPP Nodes", XSF XEP 0271,
June 2009.
[XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F.,
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20060816, August 2006, xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
[XMPP-URI] [XMPP-URI]
Saint-Andre, P., "Internationalized Resource Identifiers Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
skipping to change at page 19, line 6 skipping to change at page 19, line 27
This profile specifies checking bidirectional strings, as described This profile specifies checking bidirectional strings, as described
in Section 6 of [STRINGPREP]. in Section 6 of [STRINGPREP].
Appendix C. Differences From RFC 3920 Appendix C. Differences From RFC 3920
Based on consensus derived from implementation and deployment Based on consensus derived from implementation and deployment
experience as well as formal interoperability testing, the following experience as well as formal interoperability testing, the following
substantive modifications were made from RFC 3920. substantive modifications were made from RFC 3920.
o Corrected the ABNF syntax for JIDs to prevent zero-length o Corrected the ABNF syntax to (1) ensure consistency with [URI] and
localparts, domainparts, and resourceparts. [IRI], and (2) prevent zero-length localparts, domainparts, and
resourceparts.
o To avoid confusion with the term "node" as used in [XEP-0030] and o To avoid confusion with the term "node" as used in [XEP-0030] and
[XEP-0060] (see also [XEP-0271]), changed the term "node [XEP-0060], changed the term "node identifier" to "localpart" (but
identifier" to "localpart" (but retained the name "Nodeprep" for retained the name "Nodeprep" for backward compatibility).
backward compatibility).
o To avoid confusion with the terms "resource" and "identifier" as o To avoid confusion with the terms "resource" and "identifier" as
used in [URI], changed the term "resource identifier" to used in [URI], changed the term "resource identifier" to
"resourcepart". "resourcepart".
o Corrected the nameprep processing rules to require use of the o Corrected the nameprep processing rules to require use of the
UseSTD3ASCIIRules flag. UseSTD3ASCIIRules flag.
Appendix D. Copying Conditions Appendix D. Copying Conditions
Regarding this entire document or any portion of it, the author makes Regarding this entire document or any portion of it, the author makes
no guarantees and is not responsible for any damage resulting from no guarantees and is not responsible for any damage resulting from
its use. The author grants irrevocable permission to anyone to use, its use. The author grants irrevocable permission to anyone to use,
modify, and distribute it in any way that does not diminish the modify, and distribute it in any way that does not diminish the
rights of anyone else to use, modify, and distribute it, provided rights of anyone else to use, modify, and distribute it, provided
that redistributed derivative works do not contain misleading author that redistributed derivative works do not contain misleading author
or version information. Derivative works need not be licensed under or version information. Derivative works need not be licensed under
similar terms. similar terms.
Index
B
Bare JID 6
D
Domainpart 4
E
Entity 3
F
Full JID 6
J
Jabber Identifier 3
L
Localpart 6
R
Resourcepart 6
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Cisco Systems, Inc.
1899 Wyknoop Street, Suite 600
Denver, CO 80202
USA
Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
 End of changes. 66 change blocks. 
235 lines changed or deleted 244 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/