From: "DRAGE, Keith \(Keith\)" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
