%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-0049 rosternotes http://www.xmpp.org/schemas/rosternotes.xsd Stefan Strigler steve@zeank.in-berlin.de zeank@jwchat.org &stpeter; 1.1pre2 in progress, last updated 2007-09-24 psa

Specified use of PEP as a storage mechanism in addition to existing jabber:iq:private method.

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 either &xep0060; or &xep0049; in order to store the data format defined above; however, other methods could be used, such as HTTP.

A client may use Publish-Subscribe (XEP-0060) for data storage, specifically through the use of personal data nodes hosted at the user's virtual publish-subscribe service as described in &xep0223;.

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 ... ]]>

A client may use Private Data Storage (XEP-0049) for data storage.

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

Note: The private XML storage protocol does not provide notifications to all connected resources, only an acknowledgement to the uploading resource.

]]> 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.

Security considerations related to private XML storage are described in XEP-0049.

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 ]]>