Subject: [xmpp] 3920bis: architecture

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Sep 2009 13:46:06 -0600

I've rewritten the Architecture section of 3920bis, which has always
struck me as fairly weak. Here is the result from my working copy
(further tweaks are possible). The most significant references are to:

EMAIL-ARCH = D. Crocker, RFC 5598: Internet Mail Architecture

REST = R. Fielding, "Architectural Styles and the Design of
Network-based Software Architectures",
http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

***

2.  Architecture

   XMPP provides a technology for the asynchronous, end-to-end exchange
   of structured data by means of direct, persistent XML streams among a
   distributed network of globally-addressable, presence-aware clients
   and servers.  Because this architectural style involves ubiquitous
   knowledge of network availability and a conceptually unlimited number
   of concurrent information transactions in the context of a given
   client-to-server or server-to-server session, we could label it
   "Availability for Concurrent Transactions" (ACT) to distinguish it
   from the "Representational State Transfer" [REST] architectural style
   familiar from the World Wide Web. Although the architecture of XMPP
   is similar in important ways to that of the email network (see
   [EMAIL-ARCH]), it introduces several modifications to facilitate
   near-real-time communication.  The salient features of this ACTive
   architectural style are as follows.

2.1.  Global Addresses

   As with email, XMPP uses globally-unique addresses (based on the
   Domain Name System) in order to route and deliver messages over the
   network.  All XMPP entities are addressable on the network, most
   particularly clients and servers but also various additional services
   that can be accessed by clients and servers.  In general, server
   addresses are of the form "domain.tld" (e.g., "im.example.com"),
   accounts hosted at a server are of the form "[email-masked]"
   (e.g., "[email-masked]"), and a particular connected device or
   resource that is currently authorized for interaction on behalf of an
   account is of the form "[email-masked]/resource" (e.g.,
   "[email-masked]/balcony").  XMPP addresses are defined under
   Section 3.

2.2.  Presence

   XMPP includes the ability for an entity to advertise its network
   availability or "presence" to other entities.  Such availability for
   communication is signalled end-to-end via dedicated communication
   primitives in XMPP (the <presence/> stanza).  Although knowledge of
   network availability is not strictly necessary for the exchange of
   XMPP messages, it facilitates real-time interaction because the
   originator of a message can know before initiating communication that
   the intended recipient is online and available.  XMPP presence is
   defined in [xmpp-im].

2.3.  Persistent Streams

   Availability for communication is also built into point-to-point
   connections (e.g., a discrete client-to-server or server-to-server
   connection) through the use of direct, persistent XML streams between
   the entity that initiated the connection (either a client or a
   server) and the entity that received the connection (a server).  Thus
   either party to a stream knows that it can immediately push data to
   the other party for immediate routing or delivery.  XML streams are
   defined under Section 5.

2.4.  Structured Data

   The basic unit of meaning in XMPP is not an XML stream (which simply
   provides the transport for point-to-point communication) but an XML
   "stanza", which is essentially a fragment of XML that is sent over a
   stream.  The root element of a stanza includes routing attributes
   (such as "from" and "to" addresses) and the child elements of the
   stanza contain a payload for delivery to the intended recipient.  XML
   stanzas are defined under Section 9.

2.5.  Distributed Network

   In practice, XMPP consists of a network of clients and servers that
   inter-communicate (however, communication between any two given
   deployed servers is strictly OPTIONAL).  Thus, for example, the user
   <[email-masked]> associated with the server <im.example.com>
   might be able to exchange messages, presence, and other structured
   data with the user <[email-masked]> associated with the server
   <example.net>.  This pattern is familiar from messaging protocols
   that make use of global addresses, such as the email network (see
   [SMTP] and [EMAIL-ARCH]).  As a result, end-to-end communication in
   XMPP is logically peer-to-peer but physically client-to-server-to-
   server-to-client, as illustrated in the following diagram.

     example.net ---------------- im.example.com
        |                                |
        |                                |
   [email-masked]           [email-masked]

      Note: Architectures that employ XML streams (Section 5) and XML
      stanzas (Section 9) but that establish peer-to-peer connections
      directly between clients using technologies based on [LINKLOCAL]
      have been deployed, but such architectures are not described in
      this specification and are best described as "XMPP-like"; for
      details, see [XEP-0174].  In addition, XML streams can be
      established end-to-end over any reliable transport, including
      extensions to XMPP itself; however, such methods are out of scope
      for this specification.

2.6.  Server

   A SERVER is an entity whose primary responsibilities are to:

   o  Manage XML streams (Section 5) with local clients and deliver XML
      stanzas (Section 9) to those clients over the negotiated streams.
   o  Subject to local service policies on server-to-server
      communication, manage XML streams (Section 5) with foreign servers
      and route XML stanzas (Section 9) to those servers over the
      negotiated streams.

   Depending on the application, the secondary responsibilities of an
   XMPP server can include:

   o  Storing XML data that is used by clients (e.g., contact lists for
      users of XMPP-based instant messaging and presence applications as
      defined in [xmpp-im]); in this case, the relevant XML stanza is
      handled directly by the server itself on behalf of the client and
      is not routed to a foreign server or delivered to a local entity.
   o  Hosting local services that also use XMPP as the basis for
      communication but that provide additional functionality beyond
      that defined in this document or in [xmpp-im]; examples include
      multi-user conferencing services as specified in [XEP-0045] and
      publish-subscribe services as specified in [XEP-0060].

2.7.  Client

   A CLIENT is an entity that establishes an XML stream with a server by
   authenticating using the credentials of a local account and that then
   completes resource binding (Section 8) in order to enable delivery of
   XML stanzas via the server to the client.  A client then uses XMPP to
   communicate with its server, other clients, and any other accessible
   entities on a network.  Multiple clients can connect simultaneously
   to a server on behalf of a local account, where each client is
   differentiated by the resource identifier portion of an XMPP address
   (e.g., <localpart@domain/home> vs. <localpart@domain/work>), as
   defined under Section 3 and Section 8.

***

/psa

---

From: Dave Cridland <[email-masked]>
Date: Tue, 01 Sep 2009 21:04:21 +0100

>    familiar from the World Wide Web. Although the architecture of  

I do like that. I feel guilty for promoting yet more cheesy contrived  
acronyms, but I do like that.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Kevin Smith <[email-masked]>
Date: Wed, 2 Sep 2009 07:27:07 +0100

> acronyms, but I do like that.

I feel no such guilt; it looks good. Thanks Peter.

/K