view release on metacpan or  search on metacpan

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

      their presence.

   o  unsubscribe -- The sender is unsubscribing from another entity's
      presence.

   o  unsubscribed -- The subscription request has been denied or a
      previously-granted subscription has been cancelled.

   o  probe -- A request for an entity's current presence; SHOULD be
      generated only by a server on behalf of a user.

   o  error -- An error has occurred regarding processing or delivery of
      a previously-sent presence stanza.

   For detailed information regarding presence semantics and the
   subscription model used in the context of XMPP-based instant
   messaging and presence applications, refer to Exchanging Presence
   Information (Section 5) and Managing Subscriptions (Section 6).

2.2.2.  Child Elements

   As described under extended namespaces (Section 2.4), a presence
   stanza MAY contain any properly-namespaced child element.

   In accordance with the default namespace declaration, by default a
   presence stanza is qualified by the 'jabber:client' or
   'jabber:server' namespace, which defines certain allowable children
   of presence stanzas.  If the presence stanza is of type "error", it
   MUST include an <error/> child; for details, see [XMPP-CORE].  If the
   presence stanza possesses no 'type' attribute, it MAY contain any of



Saint-Andre                 Standards Track                     [Page 7]

RFC 3921                        XMPP IM                     October 2004


   the following child elements (note that the <status/> child MAY be
   sent in a presence stanza of type "unavailable" or, for historical
   reasons, "subscribe"):

   1.  <show/>
   2.  <status/>
   3.  <priority/>

2.2.2.1.  Show

   The OPTIONAL <show/> element contains non-human-readable XML
   character data that specifies the particular availability status of
   an entity or specific resource.  A presence stanza MUST NOT contain
   more than one <show/> element.  The <show/> element MUST NOT possess
   any attributes.  If provided, the XML character data value MUST be
   one of the following (additional availability types could be defined
   through a properly-namespaced child element of the presence stanza):

   o  away -- The entity or resource is temporarily away.

   o  chat -- The entity or resource is actively interested in chatting.

   o  dnd -- The entity or resource is busy (dnd = "Do Not Disturb").

   o  xa -- The entity or resource is away for an extended period (xa =
      "eXtended Away").

   If no <show/> element is provided, the entity is assumed to be online
   and available.

2.2.2.2.  Status

   The OPTIONAL <status/> element contains XML character data specifying
   a natural-language description of availability status.  It is
   normally used in conjunction with the show element to provide a
   detailed description of an availability state (e.g., "In a meeting").
   The <status/> element MUST NOT possess any attributes, with the
   exception of the 'xml:lang' attribute.  Multiple instances of the
   <status/> element MAY be included but only if each instance possesses
   an 'xml:lang' attribute with a distinct language value.

2.2.2.3.  Priority

   The OPTIONAL <priority/> element contains non-human-readable XML
   character data that specifies the priority level of the resource. The
   value MUST be an integer between -128 and +127.  A presence stanza
   MUST NOT contain more than one <priority/> element.  The <priority/>
   element MUST NOT possess any attributes.  If no priority is provided,



Saint-Andre                 Standards Track                     [Page 8]

RFC 3921                        XMPP IM                     October 2004


   a server SHOULD consider the priority to be zero.  For information
   regarding the semantics of priority values in stanza routing within
   instant messaging and presence applications, refer to Server Rules
   for Handling XML Stanzas (Section 11).

2.3.  IQ Syntax

   IQ stanzas provide a structured request-response mechanism.  The
   basic semantics of that mechanism (e.g., that the 'id' attribute is
   REQUIRED) are defined in [XMPP-CORE], whereas the specific semantics
   required to complete particular use cases are defined in all cases by
   an extended namespace (Section 2.4) (note that the 'jabber:client'
   and 'jabber:server' namespaces do not define any children of IQ
   stanzas other than the common <error/>).  This memo defines two such
   extended namespaces, one for Roster Management (Section 7) and the
   other for Blocking Communication (Section 10); however, an IQ stanza
   MAY contain structured information qualified by any extended
   namespace.

2.4.  Extended Namespaces

   While the three XML stanza kinds defined in the "jabber:client" or
   "jabber:server" namespace (along with their attributes and child
   elements) provide a basic level of functionality for messaging and
   presence, XMPP uses XML namespaces to extend the stanzas for the
   purpose of providing additional functionality.  Thus a message or
   presence stanza MAY contain one or more optional child elements