On ti, 2007-09-18 at 11:06 -0400, ext [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
