Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)
draft-ietf-simple-prescaps-ext-10
Yes
(Jon Peterson)
No Objection
Lars Eggert
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Abstain
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert
(was Discuss, No Objection, Discuss)
No Objection
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
(2008-04-07)
Unknown
* 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".
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2008-03-19)
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
Abstain
Abstain
(2007-11-14)
Unknown
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.