From 54ad7a7bf9e31f771ae56aefaf4d5dfe6dfe19ca Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 18 Jun 2007 16:56:38 +0000 Subject: [PATCH] 0.10 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@966 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0084.xml | 50 +++++++++++++++++++++++++++++++++----------------- 1 file changed, 33 insertions(+), 17 deletions(-) diff --git a/xep-0084.xml b/xep-0084.xml index 01929bf8..3a905831 100644 --- a/xep-0084.xml +++ b/xep-0084.xml @@ -28,6 +28,12 @@ &pgmillard; &temas; &xvirge; + + 0.10 + 2007-06-18 + psa +

Changed height and width attributes from required to recommended; updated security considerations to reflect problems with SHA-1; further specified datatypes.

 + 0.9 2007-02-01 @@ -178,7 +184,7 @@ ]]> -

Note the inclusion of &xep0033; information about the publishing resource (see XEP-0163 and XEP-0060 for details).

+

Depending on node configuration, the item may include &xep0033; information about the publishing resource (see XEP-0163 and XEP-0060 for details).

Upon receiving the notification, each subscriber SHOULD determine if it has a locally cached copy of that avatar (which it can determine by searching for an image identified by the ItemID). If the subscriber already has a locally cached copy of the avatar image, it MUST NOT retrieve the image data.

@@ -277,11 +283,11 @@

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

- ]]> @@ -289,9 +295,12 @@

The <info/> child element MUST possess the following attributes:

  • bytes -- The size of the image data in bytes.
    • -
  • height -- The height of the image in pixels.
  • id -- The SHA1 hash of the image data for the specified content-type.
  • type -- The IANA-registered content type of the image data.
    • +
+

The <info/> child element SHOULD possess the following attributes:

+
    +
  • height -- The height of the image in pixels.
  • width -- The width of the image in pixels.

The <info/> element MAY possess the following attribute:

@@ -398,7 +407,7 @@ -

A contact can determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID (&BAREJID;):

+

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;):

-

Certain restrictions are placed upon the image. First, the image height and width SHOULD be between thirty-two (32) and ninety-six (96) pixels. The suggested size is sixty-four (64) pixels high and sixty-four (64) pixels wide. Images SHOULD be square, but this is not required. Finally, images SHOULD use less than eight (8) kilobytes of data.

+

The following restrictions apply to the image:

+
    +
  1. The image height and width SHOULD be between thirty-two (32) and ninety-six (96) pixels.
    2. +
  2. The suggested size is sixty-four (64) pixels high and sixty-four (64) pixels wide.
    3. +
  3. The image SHOULD be square.
    4. +
  4. The image SHOULD use less than eight (8) kilobytes of data.
    5. +
-

If a user has multiple online resources at the same time, each resource MAY publish a different avatar. A user SHOULD subscribe to his or her own metadata in order to know the avatars that are being published to all resources. The PEP service SHOULD include the replyto address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars.

+

If a user has multiple online resources at the same time, each resource MAY publish a different avatar. The PEP service SHOULD include the replyto address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars.

 -

When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar using the "get-items" method described in XEP-0060.

+

When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate &xep0115; information or using the "get-items" method described in XEP-0060.

It is the responsibility of the receiving application to determine which avatar format to retrieve (e.g., "image/gif" rather than "image/png") and to determine the appropriate method for retrieval (e.g., HTTP rather than pubsub).

@@ -441,7 +456,8 @@ -

There are no security features or concerns related to this proposal.

+

See XEP-0060 and XEP-0163 regarding security considerations related to the underlying transport protocol.

+

It is possible that output of the SHA-1 hashing algorithm can result in collisions; however, the use of SHA-1 in producing a hash of the avatar data is not security-critical.

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

@@ -480,8 +496,8 @@ - - + + @@ -493,12 +509,12 @@ - + - + - - + +