view release on metacpan or  search on metacpan

doc/rfc3920.txt  view on Meta::CPAN

Network Working Group                                P. Saint-Andre, Ed.
Request for Comments: 3920                    Jabber Software Foundation
Category: Standards Track                                   October 2004


        Extensible Messaging and Presence Protocol (XMPP): Core

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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.            Standards Track                     [Page 1]

RFC 3920                       XMPP Core                    October 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.   Generalized Architecture . . . . . . . . . . . . . . . . . .   3
   3.   Addressing Scheme  . . . . . . . . . . . . . . . . . . . . .   5
   4.   XML Streams  . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.   Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.   Use of SASL  . . . . . . . . . . . . . . . . . . . . . . . .  27
   7.   Resource Binding . . . . . . . . . . . . . . . . . . . . . .  37
   8.   Server Dialback  . . . . . . . . . . . . . . . . . . . . . .  41
   9.   XML Stanzas  . . . . . . . . . . . . . . . . . . . . . . . .  48
   10.  Server Rules for Handling XML Stanzas  . . . . . . . . . . .  58
   11.  XML Usage within XMPP  . . . . . . . . . . . . . . . . . . .  60
   12.  Core Compliance Requirements . . . . . . . . . . . . . . . .  62
   13.  Internationalization Considerations  . . . . . . . . . . . .  64
   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  64
   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  69
   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  71
   A.   Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . .  75
   B.   Resourceprep . . . . . . . . . . . . . . . . . . . . . . . .  76
   C.   XML Schemas  . . . . . . . . . . . . . . . . . . . . . . . .  78
   D.   Differences Between Core Jabber Protocols and XMPP . . . . .  87
   Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . .  89
   Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . .  89
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .  89
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  90

doc/rfc3920.txt  view on Meta::CPAN

   error to the sender by way of the sender's server.

10.3.  Subdomain

   If the hostname of the domain identifier portion of the JID contained
   in the 'to' attribute matches a subdomain of one of the configured
   hostnames of the server itself, the server MUST either process the
   stanza itself or route the stanza to a specialized service that is
   responsible for that subdomain (if the subdomain is configured), or
   return an error to the sender (if the subdomain is not configured).

10.4.  Mere Domain or Specific Resource

   If the hostname of the domain identifier portion of the JID contained
   in the 'to' attribute matches a configured hostname of the server
   itself and the JID contained in the 'to' attribute is of the form
   <domain> or <domain/resource>, the server (or a defined resource
   thereof) MUST either process the stanza as appropriate for the stanza
   kind or return an error stanza to the sender.

10.5.  Node in Same Domain

   If the hostname of the domain identifier portion of the JID contained
   in the 'to' attribute matches a configured hostname of the server
   itself and the JID contained in the 'to' attribute is of the form
   <node@domain> or <node@domain/resource>, the server SHOULD deliver
   the stanza to the intended recipient of the stanza as represented by
   the JID contained in the 'to' attribute.  The following rules apply:

   1.  If the JID contains a resource identifier (i.e., is of the form
       <node@domain/resource>) and there exists a connected resource
       that matches the full JID, the recipient's server SHOULD deliver
       the stanza to the stream or session that exactly matches the
       resource identifier.

   2.  If the JID contains a resource identifier and there exists no
       connected resource that matches the full JID, the recipient's
       server SHOULD return a <service-unavailable/> stanza error to the
       sender.





Saint-Andre, Ed.            Standards Track                    [Page 59]

RFC 3920                       XMPP Core                    October 2004


   3.  If the JID is of the form <node@domain> and there exists at least
       one connected resource for the node, the recipient's server
       SHOULD deliver the stanza to at least one of the connected
       resources, according to application-specific rules (a set of
       delivery rules for instant messaging and presence applications is
       defined in [XMPP-IM]).

11.  XML Usage within XMPP

11.1.  Restrictions

   XMPP is a simplified and specialized protocol for streaming XML
   elements in order to exchange structured information in close to real
   time.  Because XMPP does not require the parsing of arbitrary and
   complete XML documents, there is no requirement that XMPP needs to
   support the full feature set of [XML].  In particular, the following
   restrictions apply.

   With regard to XML generation, an XMPP implementation MUST NOT inject
   into an XML stream any of the following:

   o  comments (as defined in Section 2.5 of [XML])

   o  processing instructions (Section 2.6 therein)

   o  internal or external DTD subsets (Section 2.8 therein)

   o  internal or external entity references (Section 4.2 therein) with
      the exception of predefined entities (Section 4.6 therein)

   o  character data or attribute values containing unescaped characters
      that map to the predefined entities (Section 4.6 therein); such
      characters MUST be escaped

   With regard to XML processing, if an XMPP implementation receives
   such restricted XML data, it MUST ignore the data.

11.2.  XML Namespace Names and Prefixes

   XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to
   create strict boundaries of data ownership.  The basic function of
   namespaces is to separate different vocabularies of XML elements that
   are structurally mixed together.  Ensuring that XMPP-compliant XML is
   namespace-aware enables any allowable XML to be structurally mixed
   with any data element within XMPP.  Rules for XML namespace names and
   prefixes are defined in the following subsections.





Saint-Andre, Ed.            Standards Track                    [Page 60]

RFC 3920                       XMPP Core                    October 2004


11.2.1.  Streams Namespace

   A streams namespace declaration is REQUIRED in all XML stream
   headers.  The name of the streams namespace MUST be
   'http://etherx.jabber.org/streams'.  The element names of the
   <stream/> element and its <features/> and <error/> children MUST be
   qualified by the streams namespace prefix in all instances.  An
   implementation SHOULD generate only the 'stream:' prefix for these
   elements, and for historical reasons MAY accept only the 'stream:'
   prefix.

11.2.2.  Default Namespace

   A default namespace declaration is REQUIRED and is used in all XML
   streams in order to define the allowable first-level children of the
   root stream element.  This namespace declaration MUST be the same for