Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information
draft-ietf-simple-partial-notify-10

[Ballot comment]
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:
  Bob
I'd prefer something like this:
 
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.

[Ballot discuss]
I support the XML diff work but I'd like to clarify a couple things.

DISCUSS issue

The draft avoids defining any errors.  I think that might be an error.  Even though there's no transport for errors, it seems like it would be easy and good to define some element names that can be used for errors in log files, command-line responses and in applications as defined in the future.  Am I missing something that's hard about this?

Since changes are added sequentially, isn't it possible for one change to undo another?  If we imagine logging a human making XML changes, we could end up with a complete record of changes, including things added and then deleted.  This is opposed to a direct diff.  Should there be a recommendation of paring down diffs before being sent on the wire so that they don't provide unnecessary changes?  This could be done by applying the log-every-action style diff to the original document, then by deriving the changes between the original and new document. 

Can the error described in paragraph 6 of section 4.2 be avoided?  I'll send separately an example of what I *think* causes the error, and I don't see why an error is necessary.


COMMENTS

I really wish section 4.2, especially paragraphs 1 and 6, could be clearer.  I am still not sure I could rewrite them myself, having had to reread them over and over, but I can try if that would help.

"ascendants" is not the opposite of "descendents" in this context -- replace the word with "ancestors".

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

[Ballot discuss]
The lack of information about the overall state machine of "patching" or partially modifying data is difficult to understand how it all can be outside the scope of the specification. The docs primarily focus on the mechanics of modifying the data but, don't explore the rules of the state machine at all. Thus, it is potentially difficult for interoperable implementations to emerge if there is no guidance on error conditions and logic to follow at certain decision points (when to patch vs wholesale replace). Pointers to docs that have the state machine would suffice but, the sections that state that this data is outside the scope of the spec give no reference.

[Ballot discuss]
partial notify and partial-publish seem inconsistent with respect to generation of
partial presence documents:

In partial-notify:

The third paragraph in section 4.4 begins "When the PA generates a partial presence
document", and the following paragraph begins "The PA MUST construct the partial
presence document according to the following logic:"

This seems to rule out the PA forwarding a partial presence document generated at the
PUA.  Is this intentional?  It seems inconsistent with partial-publish, but clearly provides
a higher level of control for the PA.

If the PA is required to generate the partial presence document, then it can guarantee that
a partial presence document actually results in changes.  (This would support the first item
in Lars' discuss.)  Alternatively, the processing rules for  (see section 4.3.2 in
partial-publish) could require an additional step, comparing the "old" and "new" presence
documents to determine if changes resulted from the application of the partial presence
doument.  In this case,  the PA could still forward the PUA provided partial presence
document.

[Ballot discuss]
partial notify and partial-publish seem inconsistent with respect to generation of
partial presence documents:

In partial-notify:

The third paragraph in section 4.4 begins "When the PA generates a partial presence
document", and the following paragraph begins "The PA MUST construct the partial
presence document according to the following logic:"

This seems to rule out the PA forwarding a partial presence document genreated at the
PUA.  Is this intentional?  It seems inconsistent with partial-publish, but clearly provides
a higher level of control for the PA.

If the PA is required to generate the partial presence document, then it can guarantee that
a partial presence document actually results in changes.  (This would support the first item
in Lars discuss.  If not, the processing rules for  (see 4.3.2 in partial-publish)
would require an additional step, comparing the "old" and "new" presence documents to
deteremin if changes resulted from the application of the partial presence doument.

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

[Ballot discuss]
partial notify and partial-publish seem inconcsistent wrt generation of
partial presence documents:

In partial-notify:

The third paragraph in section 4.4 begins "When the PA generates a partial presence
document", and the following paragraph begins "The PA MUST construct the partial
presence document according to the following logic:"

This seems to rule generation of the partial presence document at the PUA.  Is this
intentional?  It seems inconsistent with partial-publish, but clearly provides a higher level
of control for the PA.

If the PA is required to generate the partial presence document, then it can guarantee that
a partial presence document actually results in changes.  (This would support the first item
in Lars discuss.  If not, the processing rules for  (see 4.3.2 in partial-publish)
would require an additional step, comparing the "old" and "new" presence documents to
deteremin if changes resulted from the application of the partial presence doument.

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

[Ballot discuss]
draft-ietf-simple-partial-notify-09, Section 4.4., paragraph 3:
>    When the PA generates a partial presence document, the PA SHOULD
>    include only that presence information that has changed compared to
>    the previous notifications.  It is up to the PA's local policy to
>    determine what is considered as a change to the previous state.

  DISCUSS: This SHOULD means that the PA may choose to include presence
  information in the partial notification that has not changed. If I
  understand Section 4.5 correctly, the watcher simply applies the
  content of a partial notification to its data, without checking
  whether this actually results in a change. This seems problematic, if
  the watcher uses the reception of a notification as a trigger for some
  other actions. This problem would go away if the SHOULD were replaced
  by a MUST. The corresponding text in draft-ietf-simple-partial-publish
  isn't as specific, but seems to imply a MUST. Or is there a specific
  reason for leaving it as a SHOULD here?

draft-ietf-simple-partial-notify-09, Section 8., paragraph 3:
>    [3]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
>        Instant Messaging", RFC 2778, February 2000.

  DISCUSS: DOWNREF.

draft-ietf-simple-partial-pidf-format-08, Section 5.2., paragraph 5:
>         
>                    "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
>              [2]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
>        Instant Messaging", RFC 2778, February 2000.

  DISCUSS: DOWNREF.

draft-ietf-simple-partial-pidf-format-08, Section 12.1., paragraph 5:
>    [5]  Moats, R., "A URN namespace for IETF documents", RFC 2648,
>        Aug. 1999.

  DISCUSS: DOWNREF.

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

[Ballot discuss]
draft-ietf-simple-partial-notify-09, Section 4.4., paragraph 3:
>    When the PA generates a partial presence document, the PA SHOULD
>    include only that presence information that has changed compared to
>    the previous notifications.  It is up to the PA's local policy to
>    determine what is considered as a change to the previous state.

  DISCUSS: This SHOULD means that the PA may choose to include presence
  information in the partial notification that has not changed. If I
  understand Section 4.5 correctly, the watcher simply applies the
  content of a partial notification to its data, without checking
  whether this actually results in a change. This seems problematic, if
  the watcher uses the reception of a notification as a trigger for some
  other actions. This problem would go away if the SHOULD were replaced
  by a MUST. The corresponding text in draft-ietf-simple-partial-publish
  isn't as specific, but seems to imply a MUST. Or is there a specific
  reason for leaving it as a SHOULD here?

draft-ietf-simple-partial-notify-09, Section 8., paragraph 3:
>    [3]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
>        Instant Messaging", RFC 2778, February 2000.

  DISCUSS: DOWNREF.

draft-ietf-simple-partial-pidf-format-08, Section 5.2., paragraph 5:
>         
>                    "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
>              [2]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
>        Instant Messaging", RFC 2778, February 2000.

  DISCUSS: DOWNREF.

draft-ietf-simple-partial-pidf-format-08, Section 12.1., paragraph 5:
>    [5]  Moats, R., "A URN namespace for IETF documents", RFC 2648,
>        Aug. 1999.

PROTO Write-up

1.a) The chairs have reviewed this version of the ID and
    ask that the IESG consider it for publication.

1.b) This document has been sufficiently reviewed by the
    working group. It has been through a few rounds of WGLCs
    and the solution has been completely changed once.

1.c) The chairs do not believe further cross-area review
    is needed.
   
1.d) This document completes a set of required documents needed by
    3GPP in order to have a fully functioning SIMPLE presence that
    can cope with the low bandwidth and high latency of the 3G
    wireless environment. There are no concerns from the WG chairs.

1.e) This document reflects a strong consensus position from
    the working group.

1.f) There have been no indications of intent to appeal.

1.g) This document adheres to ID-nits.

1.h) The document appropriately splits references into
    Informative/Normative.

1.i) Announcement Write-up

Technical Summary

The Presence Information Document Format (PIDF) was defined in the IMPP
WG that specifies the baseline XML based format for describing presence
information.  One of the characteristic of the PIDF is that the document
always needs to carry all presence information available for the presentity.
In some environments like 3G networks where low bandwidth and high latency
links can exist it is often beneficial to limit the amount of transported
information over the network.

Presence delivered using the Presence Event Package for the Session
Initiation Protocol is represented in PIDF.  When any subset of the
elements change, even just a single element, a new document containing
the full set of elements is sent in a SIP NOTIFY request.
This memo defines an extension allowing delivery of only the presence
data that has actually changed.

Working Group Summary

This document reflects WG consensus. It defines the behaviour of the
watcher and presence agent when it comes to generating or receiving
SIP NOTIFY requests with partial PIDF as the payload.
The working group has been working on this draft for years and have
arrived at this after several re-starts.

This I-D has a strong dependency on draft-ietf-simple-partial-pidf-format-06

Protocol Quality

  Hisham Khartabil was the PROTO shepherd for this document.