%ents; ]>
Annotations This document defines an XML data format for making annotations about XMPP roster items and other entities. &LEGALNOTICE; 0145 Proposed Standards Track Standards Council XMPP Core XEP-0060 XEP-0223 rosternotes http://www.xmpp.org/schemas/rosternotes.xsd Stefan Strigler steve@zeank.in-berlin.de zeank@jwchat.org &stpeter; 1.1pre3 in progress, last updated 2007-09-27 psa

Specified use of publish-subscribe private information nodes as the preferred storage mechanism.

 1.0 2006-03-23 psa

Per a vote of the Jabber Council, advanced to Active.

 0.2 2005-07-15 psa

Editorial review: changed type to Historical; changed namespace to storage:rosternotes; corrected schema; specified use of DateTime profile from XEP-0082; corrected some small textual errors.

 0.1 2004-11-05 st

Initial version.

Many modern IM clients offer functionality that enables a user to make notes about the contacts in their roster. This is helpful if such contacts do not have meaningful information in their vCard or if the user needs to remember additional information related to a roster item. To define such functionality, we specify a <storage> element (similar to that introduced in &xep0048;) and appropriate child elements, qualified by a new namespace of 'storage:rosternotes'. While the <storage/> element can be stored using any XML storage mechanism, this document describes two such methods that are specific to XMPP.

Annotations are stored using a <storage/> element qualified by the 'storage:rosternotes' namespace. This element contains a collection of one or more <note/> elements, each representing a note about a given entity. For any given JID there MUST NOT be more than one note.

The 'jid' attribute of the <note/> element SHOULD be used without a resource, i.e., it SHOULD be a bare JID (&BAREJID;) rather than a full JID (&FULLJID;). Along with the annotation a client MAY choose to store the creation time ('cdate') and modification time ('mdate') as attributes to the <note/> element containing the annotation; these attributes MUST conform to the DateTime profile specified in &xep0082; and the timezone SHOULD be UTC.

Seems to be a good writer Oh my sweetest love ... ]]>

Note: All notes are stored as a "bundle" within the same <storage/> element.

It is RECOMMENDED to use &xep0060; for data storage, specifically through the use of personal data nodes hosted at the user's virtual publish-subscribe service as described in &xep0223; and illustrated in the following sections.

Note: In the past, &xep0049; was the recommended method (see the archived version of this specification at <http://www.xmpp.org/extensions/attic/xep-0048-1.0.html>). In addition, other methods could be used, such as HTTP or WebDAV.

Seems to be a good writer Oh my sweetest love ... http://jabber.org/protocol/pubsub#publish-options true whitelist ]]> ]]>

The stored data is automatically pushed to all of the user's connected resources.

Seems to be a good writer Oh my sweetest love ... Seems to be a good writer Oh my sweetest love ... ]]>

In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in XEP-0060.

]]> Seems to be a good writer Oh my sweetest love ... ]]>

Security considerations related to object persistent via publish-subscribe are described in XEP-0060 and XEP-0223.

No interaction with &IANA; is required as a result of this document.

No action by the ®ISTRAR; is required, since the 'storage:rosternotes' namespace is already included in the protocol namespaces registry (see &NAMESPACES;).

 The protocol documented by this schema is defined in XEP-0145: http://www.xmpp.org/extensions/xep-0145.html ]]>