From 80189d08dc30a1e0d1f2e2b454306740b9a551a5 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 2 Feb 2007 03:40:00 +0000 Subject: [PATCH] 0.9 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@490 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0084.xml | 113 ++++++++++++++++----------------------------------- 1 file changed, 36 insertions(+), 77 deletions(-) diff --git a/xep-0084.xml b/xep-0084.xml index 3f0b493d..face85c1 100644 --- a/xep-0084.xml +++ b/xep-0084.xml @@ -10,7 +10,7 @@ This document defines an XMPP protocol extension for exchanging user avatars. &LEGALNOTICE; 0084 - Deferred + Experimental Standards Track Standards @@ -23,16 +23,16 @@ XEP-0008 - avatar + TO BE ASSIGNED &stpeter; &pgmillard; &temas; &xvirge; 0.9 - 2007-01-04 + 2007-02-01 psa -

Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization.

 +

Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization; modified experimental namespaces to conform to XEP-0053.

 0.8 @@ -107,8 +107,6 @@

The process for publishing and updating user avatars is as follows:

    -
  1. User creates metadata node
    2. -
  2. User creates data node for "image/png" content-type
  3. User publishes avatar data for "image/png" content-type to data node and optionally publishes other content-types to HTTP URLs
  4. User publishes notification of updated avatar to metadata node, with ItemID that matches SHA1 hash of image data for "image/png" content-type (note: this is a hash of the image data itself, not the base64-encoded version)
  5. Subscribers receive notification
    6. @@ -116,55 +114,16 @@
  6. Optionally, user disables avatar display.

This process flow is described more fully in the following sections.

-

Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in XEP-0163.

- -

In order to publish notifications related to its avatar, the user MUST first create a node for his or her avatar metadata:

- - - - - - - http://jabber.org/protocol/pubsub#node_config - - - - - - - - - ]]> -

The NodeID MUST be "http://jabber.org/protocol/avatar#metadata" and the access model SHOULD be "presence". Note: If the default access model (see XEP-0163) is the same as the desired access model, the user can send an empty <configure/> element rather than including a data form as shown above.

- - ]]> - - -

Next, the user SHOULD create a node for his or her avatar data (however, note that data publication via XMPP is not required since the data could be made available at an HTTP URL):

- - - - - - - ]]> -

If the user creates a data note, the NodeID MUST be "http://jabber.org/protocol/avatar#data" and the access model SHOULD be "presence".

- - ]]> - +

Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in XEP-0163, since such support simplifies avatar publication. The following examples assume the availability of a PEP service.

Before updating the avatar metadata node, the publisher MUST make sure that the avatar data is available at the data node or URL. When publishing the avatar data to the data node, the publisher MUST ensure that the value of the pubsub ItemID is the SHA1 hash of the data for the "image/png" content-type (this is used by the subscriber to determine if a locally cached copy can be displayed).

The following example illustrates the XML structure to be sent when publishing avatar data to the data node.

- + - + qANQR1DBwU4DX7jmYZnncm... @@ -182,9 +141,9 @@ - + - + - + - + - + @@ -240,9 +199,9 @@ - + - + qANQR1DBwU4DX7jmYZnncm... @@ -259,7 +218,7 @@ - + @@ -271,9 +230,9 @@ - + - + @@ -289,14 +248,14 @@

The PEP subset of pubsub requires that there shall exist a one-to-one relationship between namespaces and nodes. Because the protocol defined herein stipulates the use of two nodes (one for avatar data and one for avatar metadata), we define two namespaces, each with a corresponding root element:

    -
  • <data xmlns='http://jabber.org/protocol/avatar#data'/>
    • -
  • <metadata xmlns='http://jabber.org/protocol/avatar#metadata'/>
    • +
  • <data xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-data'/>
    • +
  • <metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'/>

These are further specified below.

The <data/> element is used to communicate the avatar data itself, and only for the "image/png" content-type (support for which is REQUIRED):

+ IMAGE DATA ]]> @@ -314,7 +273,7 @@

The <info/> child element is used to communicate avatar metadata:

+

The <pointer/> child element is used to point to an avatar that is not published via pubsub or HTTP, but rather is provided by a third-party service such as an online gaming system or virtual world:

+ ... APPLICATION-SPECIFIC DATA ... - + ]]>

The <pointer/> element MAY possess the following attributes if the publishing application has the relevant information:

    @@ -365,7 +324,7 @@

    The <stop/> child element is used to signal that avatar publishing has been disabled:

    + ]]> @@ -380,9 +339,9 @@ - + - + - + - + - - + + ]]> @@ -485,8 +444,8 @@

    This document makes use of IANA-registered content types, but requires no interaction with &IANA;.

    - -

    The ®ISTRAR; shall include 'http://jabber.org/protocol/avatar#data' and 'http://jabber.org/protocol/avatar#metadata' in its registry of protocol namespaces.

    + +

    Until this specification advances to a status of Draft, its associated namespaces shall be "http://www.xmpp.org/extensions/xep-0084.html#ns-data" and "http://www.xmpp.org/extensions/xep-0084.html#ns-metadata"; upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.

         @@ -496,8 +455,8 @@ @@ -511,8 +470,8 @@