draft-ietf-xmpp-address-02.txt   draft-ietf-xmpp-address-03.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco
Intended status: Standards Track July 12, 2010 Intended status: Standards Track July 26, 2010
Expires: January 13, 2011 Expires: January 27, 2011
Extensible Messaging and Presence Protocol (XMPP): Address Format Extensible Messaging and Presence Protocol (XMPP): Address Format
draft-ietf-xmpp-address-02 draft-ietf-xmpp-address-03
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 January 13, 2011. This Internet-Draft will expire on January 27, 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 22 skipping to change at page 2, line 22
2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Resourcepart . . . . . . . . . . . . . . . . . . . . . . . 6
3. Internationalization Considerations . . . . . . . . . . . . . 7 3. Internationalization Considerations . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 8 4.1. Reuse of Stringprep . . . . . . . . . . . . . . . . . . . 8
4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 8 4.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 8
4.3. Confusable Characters . . . . . . . . . . . . . . . . . . 8 4.3. Confusable Characters . . . . . . . . . . . . . . . . . . 8
4.4. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9 4.4. Address Spoofing . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Address Forging . . . . . . . . . . . . . . . . . . . 9 4.4.1. Address Forging . . . . . . . . . . . . . . . . . . . 9
4.4.2. Address Mimicking . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 11
5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 11 5.2. Resourceprep Profile of Stringprep . . . . . . . . . . . . 11
6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11 6. Conformance Requirements . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 16 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . . 16
A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . 17 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 17
A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 18
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . 19
B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 18 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . . 19
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . . 19
Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19 Appendix C. Differences From RFC 3920 . . . . . . . . . . . . . . 19
Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 19 Appendix D. Copying Conditions . . . . . . . . . . . . . . . . . 20
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 XMPP entities was network-aware entities. The address format for XMPP entities was
originally developed in the Jabber open-source community in 1999, originally developed in the Jabber open-source community in 1999,
first described by [XEP-0029] in 2002, and defined canonically by first described by [XEP-0029] in 2002, and defined canonically by
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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 identify an entity such as a functionality (e.g., a domainpart can identify an entity such as a
multi-user chat service, a publish-subscribe service, or a user multi-user chat service, a publish-subscribe service, or a user
directory). directory).
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 or "FQDN" (see a network SHOULD be a fully qualified domain name or "FQDN" (see
[DNS]); although the domainpart MAY be either an Internet Protocol [DNS]); although the domainpart is allowed to be either an Internet
(IPv4 or IPv6) address or a text label that is resolvable on a local Protocol (IPv4 or IPv6) address or a text label that is resolvable on
network (commonly called an "unqualified hostname"), it is possible a local network (commonly called an "unqualified hostname"), it is
that domainparts that are IP addresses will not be acceptable to possible that domainparts that are IP addresses will not be
other services for the sake of interdomain communication. acceptable to other services for the sake of interdomain
Furthermore, domainparts that are unqualified hostnames MUST NOT be communication. Furthermore, domainparts that are unqualified
used on public networks but MAY be used on private networks. hostnames MUST NOT be 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 consisting of a fully qualified domain name MUST be an A domainpart MUST NOT be zero bytes in length and MUST NOT be more
"internationalized domain name" as defined in [IDNA2003], that is, "a than 1023 bytes in length.
domain name in which every label is an internationalized label".
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
domainpart or comparing two XMPP domainparts, an application MUST
ensure that for each text label it is possible to apply without
failing the ToASCII operation specified in [IDNA2003] with the
UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other
than letters, digits, and hyphens). If the ToASCII operation can be
applied without failing, then the label is an internationalized
label. An internationalized domain name (and therefore an XMPP
domainpart) is constructed from its constituent internationalized
labels by following the rules specified in [IDNA2003].
Note: The ToASCII operation includes application of the [NAMEPREP] A domainpart consisting of a fully qualified domain name MUST be an
profile of [STRINGPREP] and encoding using the algorithm specified "internationalized domain name" as defined in [IDNA2003], that is, it
in [PUNYCODE]; for details, see [IDNA2003]. Although the output MUST be "a domain name in which every label is an internationalized
of the ToASCII operation is not used in XMPP, it MUST be possible label" and MUST follow the rules for construction of
to apply that operation without failing. internationalized domain names specified in [IDNA2003]. When
preparing a text label (consisting of a sequence of UTF-8 encoded
Unicode code points) for representation as an internationalized label
in the process of constructing an XMPP domainpart or comparing two
XMPP domainparts, an application MUST ensure that for each text label
it is possible to apply without failing the ToASCII operation
specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus
forbidding ASCII code points other than letters, digits, and
hyphens). If the ToASCII operation can be applied without failing,
then the label is an internationalized label. (Note: The ToASCII
operation includes application of the [NAMEPREP] profile of
[STRINGPREP] and encoding using the algorithm specified in
[PUNYCODE]; for details, see [IDNA2003].) Although XMPP applications
do not communicate the output of the ToASCII operation (called an
"ACE label") over the wire, it MUST be possible to apply that
operation without failing to each internationalized label. If an
XMPP application receives as input an ACE label, it MUST convert that
ACE label to an internationalized label using the ToUnicode operation
(see [IDNA2003]) before including the label in an XMPP domainpart
that will be communicated over the wire on an XMPP network.
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),
skipping to change at page 10, line 30 skipping to change at page 10, line 38
characters from more than one character set, or from a character set characters from more than one character set, or from a character set
not typically employed by a particular user, can be mitigated not typically employed by a particular user, can be mitigated
somewhat through intelligent presentation. In particular, every somewhat through intelligent presentation. In particular, every
human user of an XMPP technology presumably has a preferred language human user of an XMPP technology presumably has a preferred language
(or, in some cases, a small set of preferred languages), which an (or, in some cases, a small set of preferred languages), which an
XMPP application SHOULD gather either explicitly from the user or XMPP application SHOULD gather either explicitly from the user or
implicitly via the operating system of the user's device. implicitly via the operating system of the user's device.
Furthermore, every language has a range (or a small set of ranges) of Furthermore, every language has a range (or a small set of ranges) of
characters normally used to represent that language in textual form. characters normally used to represent that language in textual form.
Therefore, an XMPP application SHOULD warn the user when presenting a Therefore, an XMPP application SHOULD warn the user when presenting a
JID that uses characters outside the normal range of the user's JID that mixes characters from more than one character set or that
preferred language(s). This recommendation is not intended to uses characters outside the normal range of the user's preferred
discourage communication across language communities; instead, it language(s). This recommendation is not intended to discourage
recognizes the existence of such language communities and encourages communication across language communities; instead, it recognizes the
due caution when presenting unfamiliar character sets to human users. existence of such language communities and encourages due caution
when presenting unfamiliar character sets to human users.
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 20, line 8 skipping to change at page 20, line 19
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.
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Systems, Inc. Cisco
1899 Wyknoop Street, Suite 600 1899 Wyknoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
 End of changes. 12 change blocks. 
43 lines changed or deleted 51 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/