Skip to main content

Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information
RFC 5263

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from simple-chairs@ietf.org to (None)
2012-08-22
10 (System) post-migration administrative database adjustment to the Yes position for Lisa Dusseault
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for David Ward
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2008-09-11
10 (System) This was part of a ballot set with: draft-ietf-simple-partial-pidf-format, draft-ietf-simple-partial-publish, draft-ietf-simple-xml-patch-ops
2008-09-11
10 Cindy Morgan [Note]: 'RFC 5261
RFC 5262
RFC 5263
RFC 5264' added by Cindy Morgan
2008-09-11
10 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2008-09-11
10 Cindy Morgan [Note]: 'RFC 5261' added by Cindy Morgan
2008-09-11
10 (System) RFC published
2008-06-11
10 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-06-10
10 (System) IANA Action state changed to No IC from In Progress
2008-06-10
10 (System) IANA Action state changed to In Progress
2008-06-10
10 Amy Vezza IESG state changed to Approved-announcement sent
2008-06-10
10 Amy Vezza IESG has approved the document
2008-06-10
10 Amy Vezza Closed "Approve" ballot
2008-06-10
10 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2008-04-04
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-04-04
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-04-01
10 David Ward [Ballot Position Update] Position for David Ward has been changed to No Objection from Discuss by David Ward
2008-02-27
10 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-01-21
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-01-21
10 (System) New version available: draft-ietf-simple-partial-notify-10.txt
2007-12-08
10 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Yes from Discuss by Lisa Dusseault
2007-11-29
10 Chris Newman
[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 …
[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.
2007-11-29
10 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2007-11-01
10 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-11-01
10 Amy Vezza State Changes to IESG Evaluation from IESG Evaluation - Defer by Amy Vezza
2007-11-01
10 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-11-01
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-11-01
10 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2007-10-31
10 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-10-31
10 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-10-31
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-10-31
10 Lisa Dusseault
[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 …
[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".
2007-10-31
10 Lisa Dusseault [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault
2007-10-31
10 Russ Housley
[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 …
[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.
2007-10-31
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-10-31
10 David Ward
[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 …
[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.
2007-10-31
10 David Ward [Ballot Position Update] New position, Discuss, has been recorded by David Ward
2007-10-30
10 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2007-10-30
10 Tim Polk
[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 …
[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.
2007-10-30
10 Tim Polk
[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 …
[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.
2007-10-30
10 Tim Polk
[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 …
[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...
2007-10-30
10 Tim Polk
[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 …
[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.
2007-10-30
10 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2007-10-30
10 Tim Polk
[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 …
[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.
2007-10-27
10 Lars Eggert
[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 …
[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.
2007-10-27
10 Lars Eggert
[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:
>    …
[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.
2007-10-27
10 Lars Eggert
[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 …
[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.
2007-10-27
10 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2007-10-26
10 Samuel Weiler Request for Telechat review by SECDIR Completed. Reviewer: Charles Clancy.
2007-10-19
10 (System) Removed from agenda for telechat - 2007-10-18
2007-10-17
10 Amanda Baber IANA Evaluation comments:

NO IANA Considerations section.
We understand this document to have NO IANA Actions.
2007-10-16
10 Samuel Weiler Request for Telechat review by SECDIR is assigned to Charles Clancy
2007-10-16
10 Samuel Weiler Request for Telechat review by SECDIR is assigned to Charles Clancy
2007-10-15
10 Lars Eggert State Changes to IESG Evaluation - Defer from IESG Evaluation by Lars Eggert
2007-10-12
10 Jon Peterson State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jon Peterson
2007-10-12
10 Jon Peterson Placed on agenda for telechat - 2007-10-18 by Jon Peterson
2007-10-12
10 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2007-10-12
10 Jon Peterson Ballot has been issued by Jon Peterson
2007-10-12
10 Jon Peterson Created "Approve" ballot
2007-10-12
10 (System) Ballot writeup text was added
2007-10-12
10 (System) Last call text was added
2007-10-12
10 (System) Ballot approval text was added
2007-06-14
10 Jon Peterson State Changes to Waiting for AD Go-Ahead from Waiting for Writeup by Jon Peterson
2007-04-24
10 Jon Peterson State Changes to Waiting for Writeup from AD Evaluation::AD Followup by Jon Peterson
2007-04-24
10 Jon Peterson
Waiting for XML patch ops to advance.
2007-02-27
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-27
09 (System) New version available: draft-ietf-simple-partial-notify-09.txt
2006-11-05
10 Jon Peterson State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jon Peterson
2006-09-28
10 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2006-07-25
10 Dinara Suleymanova
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 …
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.
2006-07-25
10 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-07-24
08 (System) New version available: draft-ietf-simple-partial-notify-08.txt
2006-06-09
07 (System) New version available: draft-ietf-simple-partial-notify-07.txt
2005-10-21
06 (System) New version available: draft-ietf-simple-partial-notify-06.txt
2005-05-24
05 (System) New version available: draft-ietf-simple-partial-notify-05.txt
2005-02-21
04 (System) New version available: draft-ietf-simple-partial-notify-04.txt
2004-10-27
03 (System) New version available: draft-ietf-simple-partial-notify-03.txt
2004-04-20
02 (System) New version available: draft-ietf-simple-partial-notify-02.txt
2004-04-02
(System) Posted related IPR disclosure: Nokia's Statement about IPR claimed in draft-ietf-simple-partial-notify
2004-01-21
01 (System) New version available: draft-ietf-simple-partial-notify-01.txt
2003-09-29
00 (System) New version available: draft-ietf-simple-partial-notify-00.txt