draft-ietf-xmpp-core-23.txt   draft-ietf-xmpp-core-24.txt 
XMPP Working Group P. Saint-Andre, Ed. XMPP Working Group P. Saint-Andre, Ed.
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: October 11, 2004 April 12, 2004 Expires: November 4, 2004 May 6, 2004
Extensible Messaging and Presence Protocol (XMPP): Core Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-core-23 draft-ietf-xmpp-core-24
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 11, 2004. This Internet-Draft will expire on November 4, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo defines the core features of the Extensible Messaging and This memo defines the core features of the Extensible Messaging and
Presence Protocol (XMPP), a protocol for streaming Extensible Markup Presence Protocol (XMPP), a protocol for streaming Extensible Markup
Language (XML) elements in order to exchange structured information Language (XML) elements in order to exchange structured information
skipping to change at page 2, line 21 skipping to change at page 2, line 21
5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . . 36 7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . . 36
8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . . 39 8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . . 39
9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 47
10. Server Rules for Handling XML Stanzas . . . . . . . . . . . . 56 10. Server Rules for Handling XML Stanzas . . . . . . . . . . . . 56
11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . . 58 11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . . 58
12. Core Compliance Requirements . . . . . . . . . . . . . . . . . 60 12. Core Compliance Requirements . . . . . . . . . . . . . . . . . 60
13. Internationalization Considerations . . . . . . . . . . . . . 61 13. Internationalization Considerations . . . . . . . . . . . . . 61
14. Security Considerations . . . . . . . . . . . . . . . . . . . 62 14. Security Considerations . . . . . . . . . . . . . . . . . . . 62
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
Normative References . . . . . . . . . . . . . . . . . . . . . 69 Normative References . . . . . . . . . . . . . . . . . . . . . 69
Informative References . . . . . . . . . . . . . . . . . . . . 71 Informative References . . . . . . . . . . . . . . . . . . . . 71
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 72
A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . . 74 B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . . 74
C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 75 C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 75
D. Differences Between Core Jabber Protocols and XMPP . . . . . . 84 D. Differences Between Core Jabber Protocols and XMPP . . . . . . 84
Intellectual Property and Copyright Statements . . . . . . . . 86 Intellectual Property and Copyright Statements . . . . . . . . 86
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
The Extensible Messaging and Presence Protocol (XMPP) is an open XML The Extensible Messaging and Presence Protocol (XMPP) is an open XML
[XML] protocol for near-real-time messaging, presence, and [XML] protocol for near-real-time messaging, presence, and
request-response services. The basic syntax and semantics were request-response services. The basic syntax and semantics were
developed originally within the Jabber open-source community, mainly developed originally within the Jabber open-source community, mainly
in 1999. In 2002, the XMPP WG was chartered with developing an in 1999. In 2002, the XMPP WG was chartered with developing an
adaptation of the Jabber protocol that would be suitable as an IETF adaptation of the Jabber protocol that would be suitable as an IETF
instant messaging (IM) and presence technology. As a result of work instant messaging (IM) and presence technology. As a result of work
by the XMPP WG, the current memo defines the core features of XMPP; by the XMPP WG, the current memo defines the core features of XMPP
the extensions required to provide the instant messaging and presence 1.0; the extensions required to provide the instant messaging and
functionality defined in RFC 2779 [IMP-REQS] are specified in presence functionality defined in RFC 2779 [IMP-REQS] are specified
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging in Extensible Messaging and Presence Protocol (XMPP): Instant
and Presence [XMPP-IM]. Messaging and Presence [XMPP-IM].
1.2 Terminology 1.2 Terminology
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [TERMS]. 2119 [TERMS].
1.3 Contributors 1.3 Contributors
skipping to change at page 6, line 9 skipping to change at page 6, line 9
An entity is anything that can be considered a network endpoint An entity is anything that can be considered a network endpoint
(i.e., an ID on the network) and that can communicate using XMPP. (i.e., an ID on the network) and that can communicate using XMPP.
All such entities are uniquely addressable in a form that is All such entities are uniquely addressable in a form that is
consistent with RFC 2396 [URI]. For historical reasons, the address consistent with RFC 2396 [URI]. For historical reasons, the 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 a domain identifier, contains a set of ordered elements formed of a domain identifier,
node identifier, and resource identifier. node identifier, and resource identifier.
The syntax for a JID is defined below using Augmented Backus-Naur The syntax for a JID is defined below using Augmented Backus-Naur
Form as defined in [ABNF]. The IPv4address and IPv6address rules are Form as defined in [ABNF]. (The IPv4address and IPv6address rules
defined in Appendix B of [IPv6]; the allowable character sequences are defined in Appendix B of [IPv6]; the allowable character
that conform to the node rule are defined by the Nodeprep (Appendix sequences that conform to the node rule are defined by the Nodeprep
A) profile of [STRINGPREP] as documented in this memo; the allowable profile of [STRINGPREP] as documented in Appendix A of this memo; the
character sequences that conform to the resource rule are defined by allowable character sequences that conform to the resource rule are
the Resourceprep (Appendix B) profile of [STRINGPREP] as documented defined by the Resourceprep profile of [STRINGPREP] as documented in
in this memo; and the sub-domain rule makes reference to the concept Appendix B of this memo; and the sub-domain rule makes reference to
of a domain label as described in [IDNA]. the concept of a domain label as described in [IDNA].)
jid = [ node "@" ] domain [ "/" resource ] jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain)) fqdn = (sub-domain 1*("." sub-domain))
sub-domain = ([IDNA] conformant domain label) sub-domain = ([IDNA] conformant domain label)
address-literal = IPv4address / IPv6address address-literal = IPv4address / IPv6address
All JIDs are based on the foregoing structure. The most common use All JIDs are based on the foregoing structure. The most common use
of this structure is to identify an instant messaging user, the of this structure is to identify an instant messaging user, the
server to which the user connects, and the user's connected resource server to which the user connects, and the user's connected resource
skipping to change at page 7, line 28 skipping to change at page 7, line 28
the domain identifier and separated from the latter by the '@' the domain identifier and separated from the latter by the '@'
character. It usually represents the entity requesting and using character. It usually represents the entity requesting and using
network access provided by the server or gateway (i.e., a client), network access provided by the server or gateway (i.e., a client),
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 chat service). The entity room associated with a multi-user chat service). The entity
represented by a node identifier is addressed within the context of a represented by a node identifier is addressed within the context of a
specific domain; within instant messaging and presence applications specific domain; within instant messaging and presence applications
of XMPP this address is called a "bare JID" and is of the form of XMPP this address is called a "bare JID" and is of the form
<node@domain>. <node@domain>.
A node identifier MUST be formatted such that the Nodeprep (Appendix A node identifier MUST be formatted such that the Nodeprep profile of
A) profile of [STRINGPREP] can be applied to it without failing. [STRINGPREP] can be applied to it without failing. Before comparing
Before comparing two node identifiers, a server MUST (and a client two node identifiers, a server MUST (and a client SHOULD) first apply
SHOULD) first apply the Nodeprep profile to each identifier. the Nodeprep profile to each identifier.
3.4 Resource Identifier 3.4 Resource Identifier
The resource identifier is an optional tertiary identifier placed The resource identifier is an optional tertiary identifier placed
after the domain identifier and separated from the latter by the '/' after the domain identifier and separated from the latter by the '/'
character. A resource identifier may modify either a <node@domain> character. A resource identifier may modify either a <node@domain>
or mere <domain> address. It usually represents a specific session, or mere <domain> address. It usually represents a specific session,
connection (e.g., a device or location), or object (e.g., a connection (e.g., a device or location), or object (e.g., a
participant in a multi-user chat room) belonging to the entity participant in a multi-user chat room) belonging to the entity
associated with a node identifier. A resource identifier is opaque associated with a node identifier. A resource identifier is opaque
to both servers and other clients, and is typically defined by a to both servers and other clients, and is typically defined by a
client implementation when it provides the information necessary to client implementation when it provides the information necessary to
complete Resource Binding (Section 7) (although it may be generated complete Resource Binding (Section 7) (although it may be generated
by a server on behalf of a client), after which it is referred to as by a server on behalf of a client), after which it is referred to as
a "connected resource". An entity MAY maintain multiple connected a "connected resource". An entity MAY maintain multiple connected
resources simultaneously, with each connected resource differentiated resources simultaneously, with each connected resource differentiated
by a distinct resource identifier. by a distinct resource identifier.
A resource identifier MUST be formatted such that the Resourceprep A resource identifier MUST be formatted such that the Resourceprep
(Appendix B) profile of [STRINGPREP] can be applied to it without profile of [STRINGPREP] can be applied to it without failing. Before
failing. Before comparing two resource identifiers, a server MUST comparing two resource identifiers, a server MUST (and a client
(and a client SHOULD) first apply the Resourceprep profile to each SHOULD) first apply the Resourceprep profile to each identifier.
identifier.
3.5 Determination of Addresses 3.5 Determination of Addresses
After SASL negotiation (Section 6) and, if appropriate, Resource After SASL negotiation (Section 6) and, if appropriate, Resource
Binding (Section 7), the receiving entity for a stream MUST determine Binding (Section 7), the receiving entity for a stream MUST determine
the initiating entity's JID. the initiating entity's JID.
For server-to-server communications, the initiating entity's JID For server-to-server communications, the initiating entity's JID
SHOULD be the authorization identity, derived from the authentication SHOULD be the authorization identity, derived from the authentication
identity as defined by the Simple Authentication and Security Layer identity as defined by the Simple Authentication and Security Layer
skipping to change at page 14, line 19 skipping to change at page 14, line 19
value of at least "1.0" in the initial stream header, the receiving value of at least "1.0" in the initial stream header, the receiving
entity MUST send a <features/> child element (prefixed by the streams entity MUST send a <features/> child element (prefixed by the streams
namespace prefix) to the initiating entity in order to announce any namespace prefix) to the initiating entity in order to announce any
stream-level features that can be negotiated (or capabilities that stream-level features that can be negotiated (or capabilities that
otherwise need to be advertised). Currently this is used only to otherwise need to be advertised). Currently this is used only to
advertise Use of TLS (Section 5), Use of SASL (Section 6), and advertise Use of TLS (Section 5), Use of SASL (Section 6), and
Resource Binding (Section 7) as defined herein, and for Session Resource Binding (Section 7) as defined herein, and for Session
Establishment as defined in [XMPP-IM]; however, the stream features Establishment as defined in [XMPP-IM]; however, the stream features
functionality could be used to advertise other negotiable features in functionality could be used to advertise other negotiable features in
the future. If an entity does not understand or support some the future. If an entity does not understand or support some
features, it SHOULD silently ignore them. features, it SHOULD silently ignore them. If one or more security
features (e.g., TLS and SASL) need to be successfully negotiated
before a non-security-related feature (e.g., Resource Binding) can be
offered, the non-security-related feature SHOULD NOT be included in
the stream features that are advertised before the relevant security
features have been negotiated.
4.7 Stream Errors 4.7 Stream Errors
The root stream element MAY contain an <error/> child element that is The root stream element MAY contain an <error/> child element that is
prefixed by the streams namespace prefix. The error child MUST be prefixed by the streams namespace prefix. The error child MUST be
sent by a compliant entity (usually a server rather than a client) if sent by a compliant entity (usually a server rather than a client) if
it perceives that a stream-level error has occurred. it perceives that a stream-level error has occurred.
4.7.1 Rules 4.7.1 Rules
skipping to change at page 15, line 7 skipping to change at page 15, line 11
at all), the server SHOULD provide the server's authoritative at all), the server SHOULD provide the server's authoritative
hostname in the 'from' attribute of the stream header sent before hostname in the 'from' attribute of the stream header sent before
termination. termination.
4.7.2 Syntax 4.7.2 Syntax
The syntax for stream errors is as follows: The syntax for stream errors is as follows:
<stream:error> <stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'> <text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'>
OPTIONAL descriptive text OPTIONAL descriptive text
</text> </text>
[OPTIONAL application-specific condition element] [OPTIONAL application-specific condition element]
</stream:error> </stream:error>
The <error/> element: The <error/> element:
o MUST contain a child element corresponding to one of the defined o MUST contain a child element corresponding to one of the defined
stanza error conditions defined below; this element MUST be stanza error conditions defined below; this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace
skipping to change at page 29, line 35 skipping to change at page 29, line 35
terminology, "additional data with success") if required by the terminology, "additional data with success") if required by the
chosen SASL mechanism. Upon receiving the <success/> element, chosen SASL mechanism. Upon receiving the <success/> element,
the initiating entity MUST initiate a new stream by sending an the initiating entity MUST initiate a new stream by sending an
opening XML stream header to the receiving entity (it is not opening XML stream header to the receiving entity (it is not
necessary to send a closing </stream> tag first, since the necessary to send a closing </stream> tag first, since the
receiving entity and initiating entity MUST consider the original receiving entity and initiating entity MUST consider the original
stream to be closed upon sending or receiving the <success/> stream to be closed upon sending or receiving the <success/>
element). Upon receiving the new stream header from the element). Upon receiving the new stream header from the
initiating entity, the receiving entity MUST respond by sending a initiating entity, the receiving entity MUST respond by sending a
new XML stream header to the initiating entity, along with any new XML stream header to the initiating entity, along with any
available features (but NOT including the STARTTLS feature) or an available features (but not including the STARTTLS and SASL
empty <features/> element (to signify that no additional features features) or an empty <features/> element (to signify that no
are available); any such additional features not defined herein additional features are available); any such additional features
MUST be defined by the relevant extension to XMPP. not defined herein MUST be defined by the relevant extension to
XMPP.
6.3 SASL Definition 6.3 SASL Definition
The profiling requirements of [SASL] require that the following The profiling requirements of [SASL] require that the following
information be supplied by a protocol definition: information be supplied by a protocol definition:
service name: "xmpp" service name: "xmpp"
initiation sequence: After the initiating entity provides an opening initiation sequence: After the initiating entity provides an opening
XML stream header and the receiving entity replies in kind, the XML stream header and the receiving entity replies in kind, the
receiving entity provides a list of acceptable authentication receiving entity provides a list of acceptable authentication
skipping to change at page 52, line 39 skipping to change at page 52, line 39
stanza with a further error stanza; this helps to prevent looping. stanza with a further error stanza; this helps to prevent looping.
9.3.2 Syntax 9.3.2 Syntax
The syntax for stanza-related errors is as follows: The syntax for stanza-related errors is as follows:
<stanza-kind to='sender' type='error'> <stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here] [RECOMMENDED to include sender XML here]
<error type='error-type'> <error type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
xml:lang='langcode'>
OPTIONAL descriptive text OPTIONAL descriptive text
</text> </text>
[OPTIONAL application-specific condition element] [OPTIONAL application-specific condition element]
</error> </error>
</stanza-kind> </stanza-kind>
The stanza-kind is one of message, presence, or iq. The stanza-kind is one of message, presence, or iq.
The value of the <error/> element's 'type' attribute MUST be one of The value of the <error/> element's 'type' attribute MUST be one of
the following: the following:
skipping to change at page 56, line 15 skipping to change at page 56, line 15
10. Server Rules for Handling XML Stanzas 10. Server Rules for Handling XML Stanzas
Compliant server implementations MUST ensure in-order processing of Compliant server implementations MUST ensure in-order processing of
XML stanzas between any two entities. XML stanzas between any two entities.
Beyond the requirement for in-order processing, each server Beyond the requirement for in-order processing, each server
implementation will contain its own "delivery tree" for handling implementation will contain its own "delivery tree" for handling
stanzas it receives. Such a tree determines whether a stanza needs stanzas it receives. Such a tree determines whether a stanza needs
to be routed to another domain, processed internally, or delivered to to be routed to another domain, processed internally, or delivered to
a resource associated with a connected node. The following rules a resource associated with a connected node. The following rules
apply to a "mere" XMPP server, but MAY be further specified or apply:
overridden by a particular class of application servers (e.g., an
instant messaging and presence server as defined in [XMPP-IM]):
10.1 No 'to' Address 10.1 No 'to' Address
If the stanza possesses no 'to' attribute, the server SHOULD process If the stanza possesses no 'to' attribute, the server SHOULD process
it on behalf of the entity that sent it. Because all stanzas it on behalf of the entity that sent it. Because all stanzas
received from other servers MUST possess a 'to' attribute, this rule received from other servers MUST possess a 'to' attribute, this rule
applies only to stanzas received from a registered entity (such as a applies only to stanzas received from a registered entity (such as a
client) that is connected to the server. If the server receives a client) that is connected to the server. If the server receives a
presence stanza with no 'to' attribute, the server SHOULD broadcast presence stanza with no 'to' attribute, the server SHOULD broadcast
it to the entities that are subscribed to the sending entity's it to the entities that are subscribed to the sending entity's
skipping to change at page 61, line 23 skipping to change at page 61, line 18
(including ensuring that domain identifiers are internationalized (including ensuring that domain identifiers are internationalized
domain names as defined in [IDNA]) domain names as defined in [IDNA])
o XML streams (Section 4), including Use of TLS (Section 5), Use of o XML streams (Section 4), including Use of TLS (Section 5), Use of
SASL (Section 6), and Resource Binding (Section 7) SASL (Section 6), and Resource Binding (Section 7)
o The basic semantics of the three defined stanza kinds (i.e., o The basic semantics of the three defined stanza kinds (i.e.,
<message/>, <presence/>, and <iq/>) as specified in stanza <message/>, <presence/>, and <iq/>) as specified in stanza
semantics (Section 9.2) semantics (Section 9.2)
o Generation (and, where appropriate, handling) of error syntax and o Generation (and, where appropriate, handling) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas semantics related to streams, TLS, SASL, and XML stanzas
In addition, a server SHOULD support the following core protocol: In addition, a server MAY support the following core protocol:
o Server dialback (Section 8) o Server dialback (Section 8)
12.2 Clients 12.2 Clients
A client MUST support the following core protocols in order to be A client MUST support the following core protocols in order to be
considered compliant: considered compliant:
o XML streams (Section 4), including Use of TLS (Section 5), Use of o XML streams (Section 4), including Use of TLS (Section 5), Use of
SASL (Section 6), and Resource Binding (Section 7) SASL (Section 6), and Resource Binding (Section 7)
skipping to change at page 66, line 4 skipping to change at page 65, line 50
14.9 Use of base64 in SASL 14.9 Use of base64 in SASL
Both the client and the server MUST verify any [BASE64] data received Both the client and the server MUST verify any [BASE64] data received
during SASL negotiation. An implementation MUST reject (not ignore) during SASL negotiation. An implementation MUST reject (not ignore)
any characters that are not explicitly allowed by the base64 any characters that are not explicitly allowed by the base64
alphabet; this helps to guard against creation of a covert channel alphabet; this helps to guard against creation of a covert channel
that could be used to "leak" information. An implementation MUST NOT that could be used to "leak" information. An implementation MUST NOT
break on invalid input and MUST reject any sequence of base64 break on invalid input and MUST reject any sequence of base64
characters containing the pad ('=') character if that character is characters containing the pad ('=') character if that character is
included as something other than the last character of the data (e.g. included as something other than the last character of the data (e.g.
"=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow
attacks and other attacks on the implementation. Base encoding attacks and other attacks on the implementation. Base 64 encoding
visually hides otherwise easily recognized information, such as visually hides otherwise easily recognized information, such as
passwords, but does not provide any computational confidentiality. passwords, but does not provide any computational confidentiality.
Base 64 encoding MUST follow the definition in Section 3 of RFC 3548 Base 64 encoding MUST follow the definition in Section 3 of RFC 3548
[BASE64]. [BASE64].
14.10 Stringprep Profiles 14.10 Stringprep Profiles
XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for
processing of domain identifiers; for security considerations related processing of domain identifiers; for security considerations related
to Nameprep, refer to the appropriate section of [NAMEPREP]. to Nameprep, refer to the appropriate section of [NAMEPREP].
skipping to change at page 70, line 7 skipping to change at page 70, line 7
[GSS-API] Linn, J., "Generic Security Service Application Program [GSS-API] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997. Interface, Version 2", RFC 2078, January 1997.
[HTTP-TLS] [HTTP-TLS]
Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello, [IDNA] 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.
[IMP-REQS]
Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing [IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[LANGTAGS] [LANGTAGS]
Alvestrand, H., "Tags for the Identification of Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
[NAMEPREP] [NAMEPREP]
Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003. 3491, March 2003.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[SASL] Myers, J., "Simple Authentication and Security Layer [SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[SRV] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [SRV] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[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,
skipping to change at page 71, line 35 skipping to change at page 71, line 34
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", [DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version [IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996. 4rev1", RFC 2060, December 1996.
[IMP-REQS]
Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
RFC 1459, May 1993. RFC 1459, May 1993.
[JSF] Jabber Software Foundation, "Jabber Software Foundation", [JSF] Jabber Software Foundation, "Jabber Software Foundation",
<http://www.jabber.org/>. <http://www.jabber.org/>.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[SIMPLE] SIMPLE Working Group, "SIMPLE WG", <http://www.ietf.org/ [SIMPLE] SIMPLE Working Group, "SIMPLE WG", <http://www.ietf.org/
html.charters/simple-charter.html>. html.charters/simple-charter.html>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[USINGTLS] [USINGTLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
2595, June 1999. 2595, June 1999.
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
draft-ietf-xmpp-im-21 (work in progress), January 2004. draft-ietf-xmpp-im-22 (work in progress), April 2004.
Author's Address Author's Address
Peter Saint-Andre (editor) Peter Saint-Andre (editor)
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
Appendix A. Nodeprep Appendix A. Nodeprep
 End of changes. 21 change blocks. 
46 lines changed or deleted 50 lines changed or added

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