Skip to main content

RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
draft-ietf-simple-rpid-10

Yes

(Allison Mankin)
(Jon Peterson)
(Ted Hardie)

No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Mark Townsley)
(Sam Hartman)
(Scott Hollenbeck)

Note: This ballot was opened for revision 10 and is now closed.

Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Ted Hardie Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-11-23) Unknown
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
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2005-11-28) Unknown
  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.
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown