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

[Aki Niemi <[e-mail]>]

On ti, 2007-09-18 at 11:06 -0400, ext [e-mail]
wrote:
> 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.

Yes.

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

The subscriber really need not know. It is the notifier's responsibility
to keep the entity-tags unique across all of the insanely difficult SIP
routing that it may deploy in front of it.

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

Correct.

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

This isn't the subscriber's problem. Moreover, I really doubt that it is
even feasible to build a system where a new subscription sent to the
same AoR will randomly reach a different notifier instance that is in no
way synchronized (as in state, entity-tag values, etc) with the other
instances.

> * 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?

Fixed in -02.

> * 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 4 defines the entity to include the Event header field, which
includes all of the parameters.

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

Fixed in -02. It now says 202 (or 200).

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

Yes it is. A PUBLISH request will succeed (with a 2xx) or fail (412)
based on the condition; whereas a SUBSCRIBE will always succeed (with a
2xx) regardless of whether the "suppress" condition is true or not. This
is because the condition only affects the NOTIFYs that follow.

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

Fixed in -02.

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

Yes, this is also an option.

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

Fixed in -02.

Thanks for the review!

Cheers,
Aki

> Dale

_______________________________________________
Sip mailing list  http://www.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