From 21b8ad2ae7c2ae9edc2098123f1fa9cfae06e26d Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 26 Oct 2007 13:51:44 +0000 Subject: [PATCH] proofread git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1318 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0084.xml | 52 ++++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/xep-0084.xml b/xep-0084.xml index 1128a295..64b19861 100644 --- a/xep-0084.xml +++ b/xep-0084.xml @@ -103,7 +103,7 @@ -

Many communication applications allow for the association of a small image or icon with a user of that application. Usually, such an "avatar" is not intended to be an accurate picture of the user's actual physical appearance, but rather a representation (often fanciful) of the user's desired self-image or a transient state of the user (such as a mood or activity). This document outlines a way to incorporate avatars into current Jabber/XMPP systems by layering this functionality on top of the XMPP &xep0060; extension ("pubsub"), specifically the &xep0163; subset ("PEP"), which is designed for use in the context of XMPP instant messaging and presence systems that conform to &rfc3921;.

+

Many communication applications allow for the association of a small image or icon with a user of that application. Usually, such an "avatar" is not intended to be an accurate picture of the user's actual physical appearance, but rather a representation (often fanciful) of the user's desired self-image or a transient state of the user (such as a mood or activity). This document defines a way to incorporate avatars into current Jabber/XMPP systems by layering this functionality on top of the XMPP &xep0060; extension ("pubsub"), specifically the &xep0163; subset ("PEP"), which is designed for use in the context of XMPP instant messaging and presence systems that conform to &rfc3921;.

The protocol defined herein uses two pubsub nodes: one node for "metadata" about the avatar state (called the "metadata node") and one for the avatar data itself (called the "data node"). This separation of metadata from data conserves bandwidth and enables both the publisher and the subscriber to cache the avatar data. (For example, a user might toggle between two or three avatars, in which case the user's contacts can display a locally cached version of the images without having to retrieve or receive the full image each time.)

This protocol also allows storage of avatar data at a URL accessible via HTTP (see &rfc2616;). By "accessible via HTTP" is meant that the data is available at an http: or https: URI. This can be helpful as a fallback mechanism if a pubsub-aware data repository is not available. It also makes it possible for avatar images to be hosted on public websites (e.g., an end-user-oriented community site) and retrieved from that site rather than handled directly by the publishing client in any fashion.

Finally, this protocol also enables XMPP applications to optionally integrate with third-party services that host user avatars (e.g., online gaming systems and virtual worlds).

@@ -139,7 +139,7 @@

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 a SHA-1 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.

+ @@ -152,7 +152,7 @@ ]]> + ]]>

If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to RFC 2616).

@@ -160,7 +160,7 @@

Whenever the publisher wishes to change its current avatar, it MUST update the metadata node.

The following example shows metadata specifying avatar data that is available in only one format ("image/png") and accessible only at the data node.

+ @@ -178,7 +178,7 @@ ]]>

The following example shows metadata specifying avatar data that is available at an HTTP URL.

+ @@ -199,7 +199,7 @@

The user's virtual pubsub service would then send the metadata notification to entities that have subscribed to the user's metadata node or contacts who have advertised an interest in receiving avatar metadata by including a &xep0115; feature of "http://www.xmpp.org/extensions/xep-0084.html#ns-metadata+notify" &NSNOTE;.

+ @@ -214,7 +214,7 @@ -
+
]]> @@ -225,8 +225,8 @@

If the subscriber does not have a locally cached copy of the avatar image, it SHOULD retrieve the data. It can do this by sending a pubsub retrieve-items request to the data node, specifying the appropriate ItemID.

@@ -238,8 +238,8 @@

The PEP service running at the user's server then SHOULD return the avatar data.

@@ -254,12 +254,12 @@ ]]>

If the <info/> element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see RFC 2616).

- -

In order to temporarily disable any avatar, the user publishes an empty <stop/> element to the metadata node (this item SHOULD NOT possess an ItemID).

+ +

In order to temporarily disable avatar publishing, the user publishes an empty <stop/> element to the metadata node (this item SHOULD NOT possess an ItemID).

+ - + @@ -271,7 +271,7 @@ ]]>

As before, subscribers to the metadata node would then receive the notification.

+ @@ -282,7 +282,7 @@ -
+
]]> @@ -404,7 +404,7 @@

The following example shows metadata specifying avatar data that is available in multiple formats ("image/png", "image/gif", and "image/mng"), where the "image/png" content-type is available only at the data node and the other content-types are available HTTP URLs.

+ @@ -443,7 +443,7 @@

The following example shows metadata specifying avatar data that is available in "image/png" at the data node and also with a pointer to an external service.

+ @@ -472,8 +472,8 @@

The pubsub "auto-subscribe" and "filtered-notifications" features enable a contact to automatically subscribe to a user's avatar. However, a contact can also explicitly determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID (&BAREJID;).

 @@ -481,12 +481,12 @@

If the user publishes avatar data to an PEP node, the result MUST contain the appropriate items.

- - + + ]]> @@ -561,9 +561,9 @@ - +