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

[Ballot comment]
* The term "display" a  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".

[Ballot comment]
Section 4., paragraph 0:
>  4.  Usage guidelines

  So this section and the note in Section 1.2 seem to boil down to that
  no capabilities that are published using this schema can actually be
  relied upon for anything - they're all just hints that may or may not
  describe actual capabilities or preferences. What is this good for,
  then?


Section 10.2., paragraph 2:
>    [14]  Handley, M. and V. Jacobson, "SDP: Session Description
>          Protocol", RFC 2327, April 1998.

  Obsoleted by RFC 4566.

[Ballot discuss]
Section 7.1., paragraph 4:
>    XML:

  DISCUSS: Doesn't validate. ("    [3]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
>          and Instant Messaging", RFC 2778, February 2000.

  DISCUSS: DOWNREF.


Section 10.1., paragraph 8:
>    [8]  Moats, R., "A URN namespace for IETF documents", RFC 2648,
>          Aug. 1999.

  DISCUSS: DOWNREF.

[Ballot comment]
Section 10.2., paragraph 2:
>    [14]  Handley, M. and V. Jacobson, "SDP: Session Description
>          Protocol", RFC 2327, April 1998.

  Obsoleted by RFC 4566.

[Ballot discuss]
Section 4., paragraph 0:
>  4.  Usage guidelines

  So this section and the note in Section 1.2 seem to boil down to that
  no capabilities that are published using this schema can actually be
  relied upon for anything - they're all just hints that may or may not
  describe actual capabilities or preferences. What is this good for,
  then?


Section 7.1., paragraph 4:
>    XML:

  DISCUSS: Doesn't validate. ("    [3]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
>          and Instant Messaging", RFC 2778, February 2000.

  DISCUSS: DOWNREF.


Section 10.1., paragraph 8:
>    [8]  Moats, R., "A URN namespace for IETF documents", RFC 2648,
>          Aug. 1999.

  DISCUSS: DOWNREF.

[Ballot discuss]
Lisa has raised some pretty serious flaws in the protocol.  I'd like to
see an editorial pass to address those as well as a few others:

* The  element needs to support an xml:lang or lang
  attribute to comply with BCP 18 (RFC 2277).

* The "message" top-level type includes an "external-body" subtype.
  Does  imply support for that (and the security considerations
  that come with it)?  I hope not but it would be good to say so.
  RFC 2046 also says "Future subtypes of "message" intended for use
  with email should be restricted to "7bit" encoding."  For EAI
  compatibility it would be helpful to explicitly permit the 8bit
  and binary content-transfer-encodings for message types in SIP
  transport.

* The term "display" a  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".

Nit: BCP 47 (language tags) is now RFC 4646.  Referencing this through
  RFC 2987 picks up a very-out-of-date version, that doesn't allow the
  3-letter ISO639-2 codes, in particular.

Concern: Having priority under both "service capabilities" and "device capabilities"is pretty complex.  Is this actually a useful distinction?
If the service supports something but the device does not (or vice
versa), is a watcher going to be able to use that or does
it just push the work to merge the two levels onto the watcher (after
incurring bandwidth and interoperability cost)?

* My understanding of schema is a bit weak, but my reading is this
  schema only permits extensions by entities in new namespaces.
  It would not be possible, for example, to add a new element to
  this schema in the same namespace.  If an extension to this document
  did so, it would be incompatible with the schema.  The schema also
  does not allow extension attributes at all.  Either allow all the
  degrees of freedom intended (and state the exclusion of others) or
  state in the prose the purpose of the schema (as Lisa suggested)
  so it doesn't preclude extensibility.

[Ballot comment]
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  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.

[Ballot discuss]
This is DISCUSS discuss.  I would like to understand how a PUA should interpret conflicts in
the various elements.  Many elements, such as event-packages, include both
and  elements.  While a UA has an incentive to specify only correct
information, errors can and will occur.  If an event-package is listed as both supported
and not supported, which takes precendence?  Is there any guidance to a PUA on handling
conflicting values?  How about guidance to a UA for validation of capabilty info?

[Note that I will miss this week's call, so I would appreciate feedback before the call by email.]

[Ballot discuss]
This is DISCUSS discuss.  I would like to understand how a PUA should interpret conflicts in
the various elements.  Many elements, such as event-packages, include both
and  elements.  While a UA has an incentive to specify only correct
information, errors can and will occur.  If an event-package is listed as both supported
and not supported, which takes precendence?  Is there any guidance to a PUA on handling
conflicting values?  How about guidance to a UA for validation of capabilty info?

[Note that I will miss this week's call, so I would appreciate feedback before the call by email.]

[Ballot discuss]
This is DISCUSS discuss.  I would like to understand how a PUA should interpret conflicts in
the various elements.  Many elements, such as event-packages, include both
and  elements.  While a UA has an incentive to specify only correct
information, errors can and will occur.  Is there any guidance to a PUA on handling conflicting
values?  How about guidance to a UA for validation of capabilty info?

[Note that I will miss this week's call, so I would appreciate feedback before the call by email.]

[Ballot discuss]
This is DISCUSS discuss.  I would like to understand how a PUA should interpret conflicts in
the various elements.  Many elements, such as event-packages, include both
and  elements.  While a UA has an incentive to specify only correct
information, errors can and will occur.  Is there any guidance to a PUA on handling conflicting
values?  How about guidance to a UA for validation of capabilty info?

[Note that I will miss this week's call, so I would appreciate feedback before the call by email.]

[Ballot discuss]
This is DISCUSS discuss.  I would like to understand how a PUA should interpret conflicts in
the various elements.  Many elements, such as event-packages, include both
and  elements.  While a UA has an incentive to specify only correct
information, errors can and will occur.  Is there any guidance to a PUA on handling conflicting
values?  How about guidance to a UA for validation of capabilty info?

[Note that I will miss this week's call, so I would appreciate feedback from the authors or
wg chairs by email.]

[Ballot discuss]
3.2.14.  element

  The  element lists the event packages supported by a
  service.

  The  element can contain two elements:
  and .  Event packages that are supported by the service
  can be listed under  element and event packages that are
  not supported by the service can be listed under
  element.

    and  elements can contain ,
  , , , , ,
  , , and
  followed by any number of optional extension elements from other
  namespaces.

  Any value that is registered with IANA for the SIP Event types
  namespace registry can be used as a value of an extension element.

I think there is a lack of references on what the values provided in this section means. I also are missing a reference to the document defining the referenced registry.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "(XML) ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
---- -------------- -------------- ----------
pidf:caps urn:ietf:params:xml:ns:pidf:caps [pidf:caps]
[RFC-simple-prescaps-ext-08]

We understand the above to be the only IANA Action for this
document.

PROTO Write-up

1.a) The chairs have reviewed this version of the ID and
ask that the IESG consider it for publication.
Robert Sparks will act as the document shepherd.

1.b) This document has been sufficiently reviewed by the
working group.

1.c) The chairs do not believe further cross-area review is needed.
This document received particular XML-oriented scrutiny as part of
the later stages of preparing the rpid, cipid, and simple-future
drafts that were recently approved. The schema definitions and
examples in this document survive the IETF-tools schema validation
tool.

1.d) The primary WG review of this document took place over a year ago.
It has lingered long in the processing queue for other work
(notably the SIMPLE presence data model) to complete. The chairs
believe the changes since that review to be small enough that
an additional WGLC is unnecessary. The working group has been
repeatedly reminded recently that we would be requesting
publication
of this document.

1.e) There is strong working group consensus behind this document.

1.f) There has been no indication of appeal or extreme discontent
associated
with this document.

1.g) This document conforms to the requirements in ID-nits.

1.h) The document appropriately separates normative and informative
references.

1.i) Announcement Writeups:

Technical Summary
This memo introduces a SIP specific extension mechanism to the
Presence Information Document Format to represent SIP User Agent
capabilities using the SIP feature tags defined in RFC3840. With
this extension presence applications based on SIP can express richer
and more usable presence data compared to the baseline PIDF.

Working Group Summary
This document reflects the consensus of the SIMPLE working group.

Protocol Quality
Robert Sparks is the shepherd for this document.