[Ballot discuss]
When the PKIX WG developed RFC 3709, it was important that the
  content referenced by a URI did not change from the time that the
  URI was provided to the time that the URI was referenced.  Thus,
  the certificate extension includes two items, the URI and a hash
  of the content.  It is not clear to me whether there is a similar
  integrity concern in this context or not.  If it is a concern, no
  mechanism is available to detect the content change.  If it is not
  a very big concern, then the consequences of content change ought
  to be discussed in the security considerations.

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

I think there needs to be some discussion of internationalization issues in this document, particularly as they relate to the display-name element and IRIs.  I could be wrong, though, so let's discuss ahead of the telechat if at all possible.

[Ballot discuss]
I think there needs to be some discussion of internationalization issues in this document, particularly as they relate to the display-name element and IRIs.  I could be wrong, though, so let's discuss ahead of the telechat if at all possible.

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-cipid-06

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

2. This document has been sufficiently reviewed by the
  working group. The community of interest is smaller
  than that for RPID, but still sufficient for substantive
  review.

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
  led 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. This document reflects the active participation of a
  slightly smaller set of the working group than most, but
  the working group as a whole understands the document's
  contents and agrees to request its publication.

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.

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 focuses on providing "business card" like
information in a presence document, including a card element
that can hold a vCard, a display name, a URI for a homepage,
a URI for an icon representing the presentity, a URI for
a map related to the presentity, and a URI for a sound
related to the entity.

Working Group Summary

  This document reflects WG consensus. It is related to, and was
  split out from, the Rich Presence Information Document format
  (RPID) work to facilitate building consensus. 

Protocol Quality

  Robert Sparks was the PROTO shepherd for this document.