Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

[[e-mail]]

   From: "DRAGE, Keith \(Keith\)" <[e-mail]>

   This is to announce a Working Group Last Call for 

   http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-01.txt

Comments on draft-ietf-sip-subnot-etags-01.

Overall, a very well-written document!

I have one technical issue (which is probably insoluble and can only
be documented) and a number of nits.

* Section 4 specifies that a resource is identified by one or more
URIs.  It seems to be implicit that one URI always identifies the same
resource.  Without that, it would be difficult to use ETags
effectively, since ETags are only unique for a single resource.

In the general case, the mapping from URIs to resources involves the
full complexity of SIP routing.  This means that without additional
information, the subscriber does not know that request-URI that it
uses always maps into the same resource URI, and so has no absolute
guarantee that the space of ETags it is working with does not change
over time.

One assumes that all SUBSCRIBEs within a subscription are routed to
the same destination URI because the refresh SUBSCRIBEs are sent using
the route-set and contact.  But a "resumed" subscription does not have
this protection.

It is not clear that there is any solution to these problems, and we
may only be able to document that the subscriber is responsible for
assuring that successive subscription requests are delivered to the
same resource.

* Section 3 contains the line:

   notification, and attaches includes it in a SIP-ETag header field of

The words "attaches includes" seem to be incorrect.  Perhaps only
"includes" was intended?

* In section 3, it is emphasized that ETags are only unique "for a
resource and event package".  Checking RFC 3265, "event-package"
explicitly excludes any parameters attached to the event package name
in the "Event" header.

* Section 3 and other sections contain examples of SUBSCRIBE requests
which receive a 202 response.  It may be worth mentioning that 200
responses are also possible (if the notifier can determine without
delay that the request is authorized).

* Section 5.2 contains the statement:

   Unlike the condition introduced for the SIP PUBLISH [1] method, these
   conditions do not apply to the SUBSCRIBE request itself, but to the
   resulting NOTIFY request.

This is not strictly true, as success of the Suppress-Notify-If-Match
condition causes the SUBSCRIBE to receive a 204 response.
  
* Section 5.3 states:

   When a subscriber receives a NOTIFY request that contains a SIP-ETag
   header field, it MUST store the entity-tag.

This seems to be an awkward description.  The subscriber only needs to
store the entity-tag if it wishes to avail itself of the subnot-etags
mechanism later.  I think it would be clearer to say something like:

   In order for a subscriber to use this mechanism, when it receives a
   NOTIFY request that contains a SIP-ETag header field, it must store
   the entity-tag for later use.

* Section 5.7 shows a subscription being terminated:

          Subscriber                               Notifier
          ----------                               --------

          (1) SUBSCRIBE       -------->
              Suppress-Notify-If-Match: ega23
              Expires: 0

But it seems to me that most subscribers will only terminate a
subscription when they are no longer interested in the state of the
resource, and so it would be more straightforward to use "*" to ensure
that they do not receive a NOTIFY that they are not interested in:

          (1) SUBSCRIBE       -------->
              Suppress-Notify-If-Match: *
              Expires: 0

* In sections 7.2 and 7.3, "it's" is used where "its" should be used.
(That is one of the irregularities of English -- "it's" is reserved as
the contraction of "it is".)

   This header field is allowed to appear in any request, but [its]
   behavior is only defined for the SUBSCRIBE request.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip