Skip to main content

Presence Information Data Format (PIDF) Extension for Partial Presence
RFC 5262


(Jon Peterson)
(Lisa Dusseault)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Sam Hartman)

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

Lars Eggert
(was Discuss) No Objection
Comment (2007-10-27) Unknown
All four documents have serious idnits (missing IANA sections, etc.) that need to be fixed.

draft-ietf-simple-partial-notify-09, Section 8., paragraph 8:
>    [8]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
>         RFC 2246, January 1999.

  Obsoleted  by RFC 4346.

draft-ietf-simple-partial-pidf-format-08, Section 12.2., paragraph 4:
>    [12]  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
>          Mail Extensions (MIME) Part Four: Registration Procedures",
>          RFC 2048, November 1996.

  Obsoleted by RFC 4288, RFC 4289.

draft-ietf-simple-xml-patch-ops-03, Section 12.1., paragraph 9:
>    [9]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
>          RFC 2279, January 1998.

  Obsoleted by RFC 3629.
Jon Peterson Former IESG member
Yes () Unknown

Lisa Dusseault Former IESG member
(was Discuss) Yes
Yes () Unknown

Chris Newman Former IESG member
(was Discuss) No Objection
No Objection (2007-11-29) Unknown
Revision -04 of patch-ops appears to address the majority of my discuss
comments so I have cleared my discuss position.

However, simply referring to RFC 3023 for the security considerations
of the media type results in a fairly low-quality security considerations
section.  RFC 4288 states media types MUST state whether they contain
problematic active content, and I could continue to hold a discuss
position based on failure to address that MUST, however I'm not
convinced the improvement of fixing that one issue merits the delay
so I won't.  But if you need to update for other reasons or wish to
improve the document, please fix it.  The security considerations
for application/patch-ops-error+xml could be shorter and more
helpful for implementers and security analysts than the XML ones.

I'm concerned about one design choice for the xml-patch-ops format.

IMHO, it would be highly desirable if the schema for the document to be patched could largely be used on the patch itself.  While most structural
constraints wouldn't carry across well, it would be very nice if value
typing constraints were reusable.  Unfortunately, the use of entity
values in the patch to carry attribute values for the final document
makes such reuse problematic.

Were I designing a format like this, instead of this:
   <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
I'd prefer something like this:
   <addattr sel="doc/foo[@id='ert4773']"><foo user="Bob"/></addattr>
this way the patch retains attribute/value structure that parallels the
document to be patched and the schema attribute validation for attribute
"user" of entity "foo" can be applied to both the patch and the
final document.

I suspect it's too late to consider changing this, but it is a design
consideration for this sort of thing.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

David Ward Former IESG member
(was Discuss) No Objection
No Objection () Unknown

Magnus Westerlund 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 (2007-10-31) Unknown
  When giving examples in the text, it would be helpful if one could
  easily tell which parts of the example are literal, and which parts
  are names for things to be replaced.  For example, the <add> element
  text talks about the 'type' attribute equalling "@attr", but then it
  becomes clear that the intention is an at-sign followed by the name
  of the attribute to be added.

  A few entries in the References Section are never used in the text.

  In the description of the Basic presence agent operation (section 3.1),
  the wording is a bit confusing.  Is the following interpretation the
  one that is intended?  If the only value in the Accept header that is
  supported by the Presentitiy is the default, then the full PDIF
  document will be sent.
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection (2007-10-30) Unknown
In partial-publish:

The examples in section 6 would be more compelling if "[Replace wth real content length]"
in M(1) and M(3) was actually replaced with the content length.

In patch-ops:

Jeff Hutzelman propsoed more concise text for teh security considerations section.  This text
was accepted by the author, but does not appear in the RFC Editors note as yet...