Presence Information Data Format (PIDF) Extension for Partial Presence
draft-ietf-simple-partial-pidf-format-10
Yes
(Jon Peterson)
(Lisa Dusseault)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 10 and is now closed.
Jon Peterson Former IESG member
Yes
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
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(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.
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
draft-ietf-simple-xml-patch-ops-03: 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. draft-ietf-simple-partial-pidf-format-08: A few entries in the References Section are never used in the text. draft-ietf-simple-partial-notify-09: 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...