Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)
RFC 5196

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

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) (was Discuss, No Objection, Discuss) No Objection

(Russ Housley) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2008-04-07)
No email
send info
* The term "display" a <language> as used by RFC 2987 implies the
  ability for the device to speak the language (misleading
  terminology, IMHO).  For interoperability, it should be clear whether
  this is referring to the device's ability or the user's preference.
  If it's not the latter, and there isn't a way to express the latter,
  I suspect this tag is likely to be an interoperability problem.
  It also seems odd to put this under "service capabilities" rather
  than "device capabilities".

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

(Lisa Dusseault) Abstain

Comment (2007-11-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I don't think that the application element, defined as indicating "that service supports application media type", is very well defined.  Is a reference to 3840 missing?  With that link, does this become solid enough to avoid ambiguity?

I note that this document describes not just capabilities, but also preferences or policy (the priority bars, possibly languages, )

FWIW, the Allow header in HTTP, which is compared to the <methods> element, has not been a successful capabilities advertisement tool. Then again this is such a different situation (clients advertising what methods can be received, instead of services advertising what methods a resource supports) that I do not know if there are useful lessons there.

Much of the information in this spec seems to be redundant.  In particular, I can imagine an extension being advertised in "extensions" element, requiring also the "method" element and "schemes" element to contain perfectly predictable stuff.  Redundancy can be helpful or can offer opportunities for inconsistency.  

I believe the singular of "automata" is "automaton", not "automata".

The languages element indicates a capability to *display* a language.  Is there no way to indicate a *preference* for a language? E.g. I prefer English and French over Spanish even though I can display them all?  I would lay odds clients will use this as a preference.  Many clients are capable of displaying vast numbers of languages but not all, and won't bother listing all the ones they can display.

The priority stuff seems completely duplicated and redundant -- once under device capabilities, once elsewhere.

The description element is insufficiently internationalized -- it doesn't indicate what language to use to display.

The XML schema doesn't indicate how it is to be used safely -- e.g. should not be used for validation.

The security considerations are ridiculous.  There no way an agent will get meaningful permission from a user to publish this information.