view release on metacpan or  search on metacpan

doc/rfc3920-notes.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

1.  Introduction

doc/rfc3920-notes.txt  view on Meta::CPAN

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

   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)). {=clientportnumber}

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,
   <juliet@example.com> is able to exchange messages, presence, and
   other information with <romeo@example.net>.  This pattern is familiar
   from messaging protocols (such as [SMTP]) that make use of network
   addressing standards.  Communications between any two servers are
   OPTIONAL.  {=s2soptional} 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)). {=serverportnumber}



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


3.  Addressing Scheme

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 the 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
   profile of [STRINGPREP] as documented in Appendix A of this memo; the
   allowable character sequences that conform to the resource rule are
   defined by the Resourceprep profile of [STRINGPREP] as documented in
   Appendix B of this memo; and the sub-domain rule makes reference to
   the concept of an internationalized domain label as described in
   [IDNA].)


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

      {=jidformat}

   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
   addressed as <room@service> (where "room" is the name of the chat
   room and "service" is the hostname of the multi-user chat service)
   and a specific occupant of such a room could be addressed as
   <room@service/nick> (where "nick" is the occupant's room nickname).
   Many other JID types are possible (e.g., <domain/resource> could be a
   server-side script or service).

   Each allowable portion of a JID (node identifier, domain identifier,
   and resource identifier) MUST NOT be more than 1023 bytes in length,
   resulting in a maximum total size (including the '@' and '/'
   separators) of 3071 bytes. {=jidsizes}




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


3.2.  Domain Identifier

{=jid-domain}

   The domain identifier is the primary identifier and is the only
   REQUIRED element of a JID (a mere domain identifier is a valid JID).
   It usually represents the network gateway or "primary" server to