If the presence stanza received from the other resource does not contain the update child element, then the other resource does not support vCard-based avatars. The following rules apply when a client receives a presence broadcast from another resource of its own JID: This introduces the potential of conflict between the resources regarding the user's avatar image. Jabber/XMPP allows multiple resources to authenticate for the same JID simultaneously. Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child). If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new stanza with character data in the element. If there is no avatar image to be advertised, the photo element MUST be empty, i.e.: Example 7. User Is Not Ready to Advertise an Image ¶ If a client is not yet ready to advertise an image, it MUST send an empty update child element, i.e.: Example 6. If a client supports the protocol defined herein, it MUST include the update child element in every presence broadcast it sends and SHOULD also include the update child in directed presence stanzas (e.g., directed presence sent when joining Multi-User Chat (XEP-0045) rooms). The following rules apply to inclusion of the update child element () in presence broadcasts: Server Returns vCard on Behalf of User Rules ¶Ĥ.1 Inclusion of Update Data in Presence ¶ Contact's Client Requests User's vCard ¶Įxample 5.
#EJABBERD AVATAR FULL#
If not, it retrieves the sender's full vCard in accordance with the protocol flow described in XEP-0054 (note that this request is sent to the user's bare JID, not full JID): Example 4. When the recipient's client receives the hash of the avatar image, it SHOULD check the hash to determine if it already has a cached copy of that avatar image. The user's server then broadcasts that presence information to all contacts who are subscribed to the user's presence information. Entities need to be able to process both and may prefer to emit lower-case for compatibility. Note that while XML Schema defines the canonical representation of hexadecimal values to be upper-case, the historical use throughout the XMPP ecosystem has established lower-case use. User's Client Includes Avatar Hash in Presence Broadcast ¶ This is done by putting the hash encoded as hexadecimal digits as the XML character data of the child of an element qualified by the 'vcard-temp:x:update' namespace, as shown in the following example: Example 3. This hash is then included in the user's presence information. Next, the user's client computes the SHA1 hash of the avatar image data itself (not the base64-encoded version) in accordance with RFC 3174.
User's Client Publishes Avatar Data to vCard 2. Enable a contact to retrieve a user's avatar image without requesting it of the user's particular client, thus preserving bandwidth.īefore informing contacts of the user's avatar, the user's client first publishes the avatar data to the user's public vCard using the protocol defined in vcard-temp (XEP-0054).Enable a contact to retrieve a user's avatar image if the user is offline.
0 kommentar(er)
