Session Initiation Protocol (SIP) Extension for Event State Publication
draft-ietf-sip-publish-04

[Ballot discuss]
This transfers Ted's Discuss to me (for easier clearing, at his request). 

**** Ted's Discuss Comments from 2004-04-15:

This may be easy to clear, but my reading of section 4.3 seems to indicate
that the non-normative indented text contradicts the normative text.  The non-normative
text says:
      Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a refresh PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.
This is a bit confusing to start with, as there is no reason given for why
an implementation would want to update the entity tag for a refreshed
publish request; typically used E-Tags normally do not change unless
there is a reason.  This also seems to contradict this statement:
  A publication refresh only extends the expiration time of already
  existing event state. It does not affect that event state in any
  other way. Therefore, a PUBLISH request that refreshes event state
  MUST NOT have a body.
The event state's metadata is changed if the E-Tag is changed; no other
facility using the E-tag to determine if the state has been maintained
will succeed if the e-tag has changed.
My confusion on this grew reading the same text:
    Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a modifying PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.
in section 4.4.  Is there not, in fact, a requirement that the E-tag
change given the change to event state?
Reading through the text in Section 8 on e-tags has not helped
me much, other than leaving me with the impression that the
reuse of the HTTP view of e-tags is less than the authors' suppose.
I am fine with leaving the generation of the e-tags to the implementation,
but this seems to leave when they change up to the implementation,
and that concerns me.

--------

Discuss from me, related to the SMB's comments, sent to Aki and the
chairs, 2004-04-26:

About the request for better explanation, here's what Steve and I
agreed on, which made him change from a Discuss.  In the Introduction,
please add some text within the following paragraph:

  The mechanism described in this document can be extended to support
  publication of any event state for which there exists an appropriate
  event package as defined in [1]. It is not intended to be a
  general-purpose mechanism for transport of arbitrary data, as there
  are better-suited mechanisms for this purpose.

After reference [1], try to describe the classes of
application that might want to use PUBLISH other than presence
publication.  For instance, a hypothetical successor to REGISTER?
This little bit of text should give a forward reference to Section 10
since that's where future applications using PUBLISH must go to
get more information.

[Ballot discuss]
This transfers Ted's Discuss to me (for easier clearing, at his request).  Ted's Discuss Comments from 2004-04-15:

This may be easy to clear, but my reading of section 4.3 seems to indicate
that the non-normative indented text contradicts the normative text.  The non-normative
text says:
      Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a refresh PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.
This is a bit confusing to start with, as there is no reason given for why
an implementation would want to update the entity tag for a refreshed
publish request; typically used E-Tags normally do not change unless
there is a reason.  This also seems to contradict this statement:
  A publication refresh only extends the expiration time of already
  existing event state. It does not affect that event state in any
  other way. Therefore, a PUBLISH request that refreshes event state
  MUST NOT have a body.
The event state's metadata is changed if the E-Tag is changed; no other
facility using the E-tag to determine if the state has been maintained
will succeed if the e-tag has changed.
My confusion on this grew reading the same text:
    Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a modifying PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.
in section 4.4.  Is there not, in fact, a requirement that the E-tag
change given the change to event state?
Reading through the text in Section 8 on e-tags has not helped
me much, other than leaving me with the impression that the
reuse of the HTTP view of e-tags is less than the authors' suppose.
I am fine with leaving the generation of the e-tags to the implementation,
but this seems to leave when they change up to the implementation,
and that concerns me.

--------

Discuss from me, related to the SMB's comments, sent to Aki and the
chairs, 2004-04-26:

About the request for better explanation, here's what Steve and I
agreed on, which made him change from a Discuss.  In the Introduction,
please add some text within the following paragraph:

  The mechanism described in this document can be extended to support
  publication of any event state for which there exists an appropriate
  event package as defined in [1]. It is not intended to be a
  general-purpose mechanism for transport of arbitrary data, as there
  are better-suited mechanisms for this purpose.

After reference [1], try to describe the classes of
application that might want to use PUBLISH other than presence
publication.  For instance, a hypothetical successor to REGISTER?
This little bit of text should give a forward reference to Section 10
since that's where future applications using PUBLISH must go to
get more information.

[Ballot comment]
Tables 2 and 3 would be clearer if the document reproduced the key from p. 160 of RFC 3261.

I'm extremely confused by this document, since I don't understand what's being published.  Or rather, I do understand one thing that can be published -- CPIM presence announcements, since that's what's in the example -- but what else can be published?  In what format?  Is this CPIM-specific?  If not, how can an ESC function if it has to "composit" (not my idea of a verb!) arbitrarily different things.

There are unexpanded acronyms (UAC, UAS, PUA)

[Ballot discuss]
I'm extremely confused by this document, since I don't understand what's being published.  Or rather, I do understand one thing that can be published -- CPIM presence announcements, since that's what's in the example -- but what else can be published?  In what format?  Is this CPIM-specific?  If not, how can an ESC function if it has to "composit" (not my idea of a verb!) arbitrarily different things.

There are unexpanded acronyms (UAC, UAS, PUA)

[Ballot discuss]
I'm extremely confused by this document, since I don't understand what's being published.  Or rather, I do understand one thing that can be published -- CPIM presence announcements, since that's what's in the example -- but what else can be published?  In what format?  Is this CPIM-specific?  If not, how can an ESC function if it has to "composit" (not my idea of a verb!) arbitrarily different things.

[Ballot discuss]
This may be easy to clear, but my reading of section 4.3 seems to indicate
that the non-normative indented text contradicts the normative text.  The non-normative
text says:

      Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a refresh PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.

This is a bit confusing to start with, as there is no reason given for why
an implementation would want to update the entity tag for a refreshed
publish request; typically used E-Tags normally do not change unless
there is a reason.  This also seems to contradict this statement:

  A publication refresh only extends the expiration time of already
  existing event state. It does not affect that event state in any
  other way. Therefore, a PUBLISH request that refreshes event state
  MUST NOT have a body.

The event state's metadata is changed if the E-Tag is changed; no other
facility using the E-tag to determine if the state has been maintained
will succeed if the e-tag has changed.

My confusion on this grew reading the same text:

    Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a modifying PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.

in section 4.4.  Is there not, in fact, a requirement that the E-tag
change given the change to event state?

Reading through the text in Section 8 on e-tags has not helped
me much, other than leaving me with the impression that the
reuse of the HTTP view of e-tags is less than the authors' suppose.

I am fine with leaving the generation of the e-tags to the implementation,
but this seems to leave when they change up to the implementation,
and that concerns me.

[Ballot discuss]
This may be easy to clear, but my reading of section 4.3 seems to indicate
that the non-normative indented text contradicts the normative text.  The non-normative
text says:

      Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a refresh PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.

This is a bit confusing to start with, as there is no reason give for why
an implementation would want to update the entity tag for refreshed
published request; typical use E-Tags is normally not to change them unless
there is a reason.  This also seems to contradict this statement:

  A publication refresh only extends the expiration time of already
  existing event state. It does not affect that event state in any
  other way. Therefore, a PUBLISH request that refreshes event state
  MUST NOT have a body.

The event state's metadata is changed if the E-Tag is changed; no other
facility using the E-tag to determine if the state has been maintained
will succeed if the e-tag has changed.

My confusion on this grew reading the same text:

    Like the 2xx response to an initial PUBLISH request, the 2xx
      response to a modifying PUBLISH request will contain a SIP-ETag
      header field with an entity-tag. There is no requirement that this
      entity-tag is the same one as was given in the SIP-If-Match header
      field of the request.

in section 4.4.  Is there not, in fact, a requirement that the E-tag
change given the change to event state?

Reading through the text in Section 8 on e-tags has not helped
me much, other than leaving me with the impression that the
reuse of the HTTP view of e-tags is less than the authors' suppose.

I am fine with leaving the generation of the e-tags to the implementation,
but this seems to leave when they change up to the implmentation,
and that concerns me.