RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
RFC 4480

Received changes through RFC Editor sync (changed abstract to 'The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.

This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.

These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]')

[Note]: 'The proto write-up (available in tracker comment log) discusses why this document was not combined with cipid and future, despite them being interconnected.  Rough consensus for this approach does
seem evident.' added by Amy Vezza

[Note]: 'The proto write-up (available in tracker comment log) discusses why this document was not combined with cipid and future, despite them being interconnected.  Rough consensus for this approach does
seem evident.' added by Ted Hardie

[Note]: 'The proto write-up (available in tracker comment log) discusses why this document was not combined with cipid and future, despite them being interconnected.  Rough consensus for this approach does
seem evident.' added by Amy Vezza

[Ballot discuss]
This document needs an Internationalization Considerations section.  I see that the note element include a "lang" attribute, but there's no discussion of how this attribute should be used or of the larger issues associated with internationalization.  Is it safe to assume that the many elements describing things like mood will need to be translated before they can be displayed to a human?

[Ballot comment]
Since the security considerations in this document reference
  draft-ietf-simple-cipid-06, the resolution of my DISCUSS on that
  document will automatically resolve similar concerns about this
  document.

[Ballot discuss]
The W3C XML Schema specs need to be added as normative references.

This document needs an Internationalization Considerations section.  I see that the note element include a "lang" attribute, but there's no discussion of how this attribute should be used or of the larger issues associated with internationalization.  Is it safe to assume that the many elements describing things like mood will need to be translated before they can be displayed to a human?

[Note]: 'The proto write-up (available in tracker comment log) discusses why this document was not combined with cipid and future, despite them being interconnected.  Rough consensus for this approach does
seem evident.' added by Ted Hardie

[Ballot comment]
From Gen-ART review by David Black:

  Of the nits below, I would place
some emphasis on improving the discussion of extensibility, as the
cross-reference to RFC 3863 doesn't make everything obvious.

The term "presentity" is used extensively in this draft; it is a new
term (at least to me) that needs a definition and/or explanation,
including how it relates to "person".  My guess from context is that
a presentity is a proxy for presence determination/reporting purposes.

Section 1, Introduction - CPIM acronym used without expansion or prior
definition.  Please supply one.

Section 3.1 Overview - The From/until? column in Figure 1 is not
explained until a few paragraphs after the table.  This might be a
pagination issue, but the Notes? column in Figure 1 is not explained
at all, which is an omission.  The text should explain all the columns
in the table just before or immediately after the table.

Near the end of Section 3.1, the following sentence describes
extensibility of enumerations:

Enumerations can be extended by elements from other namespaces.

There are a couple of important points that aren't obvious from this
statement that should be explained here:
- The namespaces for standard extensions are specified in Section 6.
- Anyone can define an extension by  defining a new namespace
(not using a standard extensions namespace).
In connection with the latter point ...

Section 6, Extending RPID - It would be useful to adapt the
following text from Section 4.2.1 of RFC 3863 to this section:

  Any developer can introduce their own element names,
  avoiding conflict by choosing an appropriate namespace URI.

to explain how to define new enumeration values without conflict, and
as part of this an explanation of "appropriate" would be useful.

One more nit: Paul Kyzivat's email address in the draft is not correct

[Note]: 'The proto write-up (available in tracker comment log) discusses why this document was not combined with cipid and future, despite them being interconnected.  Rough consensus for this approach does
seem evident.' added by Ted Hardie

IANA Last Call Comments:
Upon approval of this document the IANA will register 1 XML Namespace and 1 XML Schema at the following registries:
http://www.iana.org/assignments/xml-registry/ns.html
http://www.iana.org/assignments/xml-registry/schema.html

This is the PROTO writeup for the submission of:
draft-ietf-simple-rpid-09

1. The chairs have reviewed this version of the ID and
  ask that the IESG consider it for publication.

2. This document has been extensively reviewed by the
  working group (perhaps to the point of over-analysis).

3. The chairs do not believe further cross-area review
  is needed. Scott Hollenbeck participated in the XML
  specific engineering done in the later part of this
  documents development.

4. This document is part of a family of related documents
  (rpid, cipid, future). The consensus building process
  let to separate documents. There is pressure from a
  few working group members (notably Rohan Mahy) to
  recombine them. The WG prefers not to combine the drafts
  based on two primary concerns
      1 - Implementations can implement rpid without
          implementing cipid or future
      2 - It will be difficult to complete the combining
          editing process without reopening issues

5. The consensus around this the core concepts in this document
  is quite strong. There were compromises reflected in the
  datamodel that the working group will defend. There was activity
  around the use of XML namespaces that achieved informed consensus
  from a smaller subset of the group (the remainder are not concerned
  about this particular set of details).

6. There have been no indications of intent to appeal.

7. This document adheres to ID-nits.

8. The document appropriately splits references into
  Informative/Normative. The informative reference to
  the data model may draw comment in IESG review. It
  should not be difficult to make this reference normative.

9. Announcement Writeup

Technical Summary

This document utilizes the extention mechanisms within the
Presence Information Document Format (PIDF) adding optional
elements with additional information about the presentity
and its contacts. This extension includes information
about what the person is doing, a grouping identifier for a
tuple, when a service or device was last used, the type of
place a person is in, what media communications might
remain private, the relationship of a service tuple to
another presentity, the person's mood, the time zone it is
located in, the type of service it offers, and an icon
reflecting the presentity's status and the overall role of
the presentity.

Working Group Summary

  This document has been through many extensive working group
  discussions. It reflects a strong working group consensus.

Protocol Quality

  Robert Sparks was the PROTO sheperd for this document.

  Interoperable exchange of presence documents using these
  extensions has been seen at several of the SIP Interoperability
  Test Events (SIPITs).