draft-ietf-xmpp-core-22.txt

pwlib源码库

XMPP Working Group                                  P. Saint-Andre (ed.)
Internet-Draft                                Jabber Software Foundation
Expires: September 17, 2004                               March 19, 2004


        Extensible Messaging and Presence Protocol (XMPP): Core
                        draft-ietf-xmpp-core-22

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 17, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This memo defines the core features of the Extensible Messaging and
   Presence Protocol (XMPP), a protocol for streaming Extensible Markup
   Language (XML) elements in order to exchange structured information
   in close to real time between any two network endpoints.  While XMPP
   provides a generalized, extensible framework for exchanging XML data,
   it is used mainly for the purpose of building instant messaging and
   presence applications that meet the requirements of RFC 2779.









Saint-Andre (ed.)      Expires September 17, 2004               [Page 1]

Internet-Draft                 XMPP Core                      March 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Generalized Architecture . . . . . . . . . . . . . . . . . . .  4
   3.  Addressing Scheme  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  XML Streams  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   6.  Use of SASL  . . . . . . . . . . . . . . . . . . . . . . . . . 26
   7.  Resource Binding . . . . . . . . . . . . . . . . . . . . . . . 37
   8.  Server Dialback  . . . . . . . . . . . . . . . . . . . . . . . 40
   9.  XML Stanzas  . . . . . . . . . . . . . . . . . . . . . . . . . 47
   10. Server Rules for Handling XML Stanzas  . . . . . . . . . . . . 56
   11. XML Usage within XMPP  . . . . . . . . . . . . . . . . . . . . 59
   12. Core Compliance Requirements . . . . . . . . . . . . . . . . . 61
   13. Internationalization Considerations  . . . . . . . . . . . . . 63
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 63
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 68
       Normative References . . . . . . . . . . . . . . . . . . . . . 71
       Informative References . . . . . . . . . . . . . . . . . . . . 73
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 74
   A.  Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
   B.  Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . . 76
   C.  XML Schemas  . . . . . . . . . . . . . . . . . . . . . . . . . 78
   D.  Differences Between Core Jabber Protocols and XMPP . . . . . . 86
       Intellectual Property and Copyright Statements . . . . . . . . 88


























Saint-Andre (ed.)      Expires September 17, 2004               [Page 2]

Internet-Draft                 XMPP Core                      March 2004


1. Introduction

1.1 Overview

   The Extensible Messaging and Presence Protocol (XMPP) is an open XML
   [XML] protocol for near-real-time messaging, presence, and
   request-response services.  The basic syntax and semantics were
   developed originally within the Jabber open-source community, mainly
   in 1999.  In 2002, the XMPP WG was chartered with developing an
   adaptation of the Jabber protocol that would be suitable as an IETF
   instant messaging (IM) and presence technology.  As a result of work
   by the XMPP WG, the current memo defines the core features of XMPP;
   the extensions required to provide the instant messaging and presence
   functionality defined in RFC 2779 [IMP-REQS] are specified in
   Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
   and Presence [XMPP-IM].

1.2 Terminology

   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [TERMS].

1.3 Contributors

   Most of the core aspects of the Extensible Messaging and Presence
   Protocol were developed originally within the Jabber open-source
   community in 1999.  This community was founded by Jeremie Miller, who
   released source code for the initial version of the jabberd server in
   January 1999.  Major early contributors to the base protocol also
   included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave
   Smith.  Work by the XMPP Working Group has concentrated especially on
   security and internationalization; in these areas, protocols for the
   use of TLS and SASL were originally contributed by Rob Norris, and
   stringprep profiles were originally contributed by Joe Hildebrand.
   The error code syntax was suggested by Lisa Dusseault.

1.4 Acknowledgements

   Thanks are due to a number of individuals in addition to the
   contributors listed.  Although it is difficult to provide a complete
   list, the following individuals were particularly helpful in defining
   the protocols or in commenting on the specifications in this memo:
   Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan
   Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov,
   Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey
   Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David



Saint-Andre (ed.)      Expires September 17, 2004               [Page 3]

Internet-Draft                 XMPP Core                      March 2004


   Waite.  Thanks also to members of the XMPP Working Group and the IETF
   community for comments and feedback provided throughout the life of
   this memo.

2. Generalized Architecture

2.1 Overview

   Although XMPP is not wedded to any specific network architecture, to
   date it usually has been implemented via a client-server architecture
   wherein a client utilizing XMPP accesses a server over a [TCP]
   connection, and servers also communicate with each other over TCP
   connections.

   The following diagram provides a high-level overview of this
   architecture (where "-" represents communications that use XMPP and
   "=" represents communications that use any other protocol).

   C1----S1---S2---C3
         |
   C2----+--G1===FN1===FC1

   The symbols are as follows:

   o  C1, C2, C3 = XMPP clients

   o  S1, S2 = XMPP servers

   o  G1 = A gateway that translates between XMPP and the protocol(s)
      used on a foreign (non-XMPP) messaging network

   o  FN1 = A foreign messaging network

   o  FC1 = A client on a foreign messaging network


2.2 Server

   A server acts as an intelligent abstraction layer for XMPP
   communications.  Its primary responsibilities are:

   o  to manage connections from or sessions for other entities, in the
      form of XML streams (Section 4) to and from authorized clients,
      servers, and other entities

   o  to route appropriately-addressed XML stanzas (Section 9) among
      such entities over XML streams




Saint-Andre (ed.)      Expires September 17, 2004               [Page 4]

Internet-Draft                 XMPP Core                      March 2004


   Most XMPP-compliant servers also assume responsibility for the
   storage of data that is used by clients (e.g., contact lists for
   users of XMPP-based instant messaging and presence applications); in
   this case, the XML data is processed directly by the server itself on
   behalf of the client and is not routed to another entity.

2.3 Client

   Most clients connect directly to a server over a [TCP] connection and
   use XMPP to take full advantage of the functionality provided by a
   server and any associated services.  Multiple resources (e.g.,
   devices or locations) MAY connect simultaneously to a server on
   behalf of each authorized client, with each resource differentiated
   by the resource identifier of an XMPP address (e.g., <node@domain/
   home> vs. <node@domain/work>) as defined under Addressing Scheme
   (Section 3).  The RECOMMENDED port for connections between a client
   and a server is 5222, as registered with the IANA (see Port Numbers
   (Section 15.9)).

2.4 Gateway

   A gateway is a special-purpose server-side service whose primary
   function is to translate XMPP into the protocol used by a foreign
   (non-XMPP) messaging system, as well as to translate the return data
   back into XMPP.  Examples are gateways to email (see [SMTP]),
   Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message
   Service (SMS), and legacy instant messaging services such as AIM,
   ICQ, MSN Messenger, and Yahoo! Instant Messenger.  Communications
   between gateways and servers, and between gateways and the foreign
   messaging system, are not defined in this document.

2.5 Network

   Because each server is identified by a network address and because
   server-to-server communications are a straightforward extension of
   the client-to-server protocol, in practice the system consists of a
   network of servers that inter-communicate.  Thus, for example,
   <[e-mail]> is able to exchange messages, presence, and
   other information with <[e-mail]>.  This pattern is familiar
   from messaging protocols (such as [SMTP]) that make use of network
   addressing standards.  Communications between any two servers are
   OPTIONAL.  If enabled, such communications SHOULD occur over XML
   streams that are bound to [TCP] connections.  The RECOMMENDED port
   for connections between servers is 5269, as registered with the IANA
   (see Port Numbers (Section 15.9)).

3. Addressing Scheme




Saint-Andre (ed.)      Expires September 17, 2004               [Page 5]

Internet-Draft                 XMPP Core                      March 2004


3.1 Overview

   An entity is anything that can be considered a network endpoint
   (i.e., an ID on the network) and that can communicate using XMPP.
   All such entities are uniquely addressable in a form that is
   consistent with RFC 2396 [URI].  For historical reasons, the address
   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,
   node identifier, and resource identifier.

   The syntax for a JID is defined below using Augmented Backus-Naur
   Form as defined in [ABNF].  The IPv4address and IPv6address rules are
   defined in Appendix B of [IPv6]; the allowable character sequences
   that conform to the node rule are defined by the Nodeprep (Appendix
   A) profile of [STRINGPREP] as documented in this memo; the allowable
   character sequences that conform to the resource rule are defined by
   the Resourceprep (Appendix B) profile of [STRINGPREP] as documented
   in this memo; and the sub-domain rule makes reference to the concept
   of a domain label as described in [IDNA].

      jid             = [ node "@" ] domain [ "/" resource ]
      domain          = fqdn / address-literal
      fqdn            = (sub-domain 1*("." sub-domain))
      sub-domain      = ([IDNA] conformant domain label)
      address-literal = IPv4address / IPv6address

   All JIDs are based on the foregoing structure.  The most common use
   of this structure is to identify an instant messaging user, the
   server to which the user connects, and the user's connected resource
   (e.g., a specific client) in the form of <user@host/resource>.
   However, node types other than clients are possible; for example, a
   specific chat room offered by a multi-user chat service could be