An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors
draft-ietf-simple-xml-patch-ops-04

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.

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.

  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.

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...