Re: [Sip] Review of draft-ietf-sip-subnot-etags-01
Aki Niemi <aki.niemi@nokia.com> Mon, 25 February 2008 21:55 UTC
Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B773328D16A; Mon, 25 Feb 2008 13:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.775
X-Spam-Level:
X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOEchhVJKfOQ; Mon, 25 Feb 2008 13:55:12 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7963A6E24; Mon, 25 Feb 2008 13:16:35 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DAA3A6E21 for <sip@core3.amsl.com>; Mon, 25 Feb 2008 13:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Ekq2-8uCou for <sip@core3.amsl.com>; Mon, 25 Feb 2008 13:16:33 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7095F3A6E6D for <sip@ietf.org>; Mon, 25 Feb 2008 13:10:25 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1PLAAHS030568; Mon, 25 Feb 2008 23:10:16 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:09:01 +0200
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Feb 2008 23:09:01 +0200
Received: from [10.162.253.189] (essapo-nirac253189.europe.nokia.com [10.162.253.189]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1PL8sCR012314; Mon, 25 Feb 2008 23:08:59 +0200
From: Aki Niemi <aki.niemi@nokia.com>
To: "ext Asveren, Tolga" <tasveren@sonusnet.com>
In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71882E7@sonusmail04.sonusnet.com>
References: <033458F56EC2A64E8D2D7B759FA3E7E71882E7@sonusmail04.sonusnet.com>
Organization: Nokia Devices R&D
Date: Mon, 25 Feb 2008 23:08:53 +0200
Message-Id: <1203973733.6192.49.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1
X-OriginalArrivalTime: 25 Feb 2008 21:09:01.0308 (UTC) FILETIME=[A4F093C0:01C877F2]
X-Nokia-AV: Clean
Cc: sip@ietf.org
Subject: Re: [Sip] Review of draft-ietf-sip-subnot-etags-01
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
On ti, 2007-10-02 at 10:53 -0400, ext Asveren, Tolga wrote: > Draft: draft-ietf-sip-subnot-etags-01 > Reviewer: Tolga Asveren [tasveren@sonusnet.com] > Review Date: 2 October 2007 > Review Deadline: > Status: post-WGLC > > Summary: This draft is on the right track for publication and requires a > few additions/clarifications before publication > > Detailed Comments: > > * 1.2 Terminology , definition of representation > The definition of "representation" does not provide a definition. There > are just some statements about "representation". I am not sure whether > such a definition is necessary either. I would suggest deleting > "representation" from this section. Done. > * 3. Overview of Operations, remembering entity-tags for all versions > Why is it necessary for the notifier to remember all versions of an > entity? To check entity-tags in SUBSCRIBEs to determine whether an > update has happened, it just needs to know the entity-tag for the last > version. Yes, but if the same entity-tag was given to a subscriber in the past, how would the notifier know which one the subscriber is using? > To generate unique entity-tags, it can just use a counter with > some extra information to deal with restart situations, e.g. some > information extracted from current time. Right, generating unique entity-tags doesn't require much more than this. The extra information can be a timestamp and the resource URI for instance. That would already fulfill the uniqueness property. > * 5.2 Generating SUBSCRIBE requests, presence of multiple conditional > headers > I assume simultaneous presence of both "Suppress-Body-If-Match" and > "Suppress-Notify-If-Match" is allowed. This could be useful for > polling/resuming a previous subscription scenarios, where the subscriber > isn't sure about the capabilities of the notifier. Mentioning about this > possibility could be useful IMHO: > "It should be noted that subscribers MAY include both > Suppress-Body-If-Match and Suppress-Notify-If-Match conditional header > fields together in a SUBSCRIBE request. This type of usage could be > utilized for the cases where the subscriber is not sure about the > suppressing capabilities of the notifier." > I guess, we would also need to define what a notifier should do upon > receipt of both headers: > "If a notifier receives both Suppress-Notify-If-Match and > Suppress-Body-If-Match headers, it SHOULD suppress the notification if > the condition evaluates to true if it has this capability. Otherwise it > SHOULD suppress the body of the notification if it has this capability. > If the notifier can't do either of these, it simply SHOULD ignore these > headers." You're correct. The new draft version does exactly this but in another way, i.e., there is now only one header field that does all that the previous two did separately. > * 5.4 Polling or Fetching Resource State, meta-information query > What is a real life use case for meta-information query? What value > would learning current entity-tag value provide from subscriber > perspective? This was probably a little too sci-fi. I've removed the text. > * 6.1 Generating Entity-tags > "For example, one possible method is to implement the entity-tag as a > simple counter, incrementing it by one for each generated notification > per resource" > I have a few questions regarding this sentence: > i- Multiple notifications to different subscribers could be generated > for the same state. I don't think all these should cause a new e-tag > value. AFAICS, the rule for a new entity-tag is as follows: > "If a notification is generated for the current state and if the state > changes, a new entity-tag MUST be assigned". I believe the draft says exactly this. Can you point to specific text that needs fixing? > ii- What about notifier restarts? It may be helpful to indicate about > some differentiator between cycles, e.g. some information based on > current time. I guess the crucial point is to make sure that the same > entity-tag is not reused for two different versions because that may > suppress necessary state notifications. A timestamp is a good idea in any case, given the uniqueness requirement for an etag. I'm reluctant to specifying any fixed (normative or otherwise) specification of the entity-tag, but to leave it as an implementation detail. Implementors don't need help here, and are likely to come up with a better one that suits them better anyway. > It is still tolerable if the > notifier -for whatever reason- uses two different entity-tags for the > same version at two distinct times. Maybe a sentence could be added > about this : "Subscribers MUST not assume that a notifier will always > use the same entity-tag for a specific version. Especially after > notifier restarts, this MAY not be the case." The way this needs to work for the subscriber is that a new NOTIFY always resets the entity. I added a sentence on this based on Brian's comments. Still, if you think this needs to be more explicit, I'm open to suggestions. > * Forking > RFC3265 4.4.9 has the following: > " If such behavior is not allowed, the first potential > dialog-establishing message will create a dialog. All subsequent NOTIFY > messages which correspond to the SUBSCRIBE message (i.e., match "To", > "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and > "Event" header "id" parameter) but which do not match the dialog would > be rejected with a 481 response. Note that the 200-class response to > the SUBSCRIBE can arrive after a matching NOTIFY has been received; such > responses might not correlate to the same dialog established by the > NOTIFY. Except as required to complete the SUBSCRIBE transaction, such > non-matching 200-class responses are ignored. " > It could make sense to amend this behavior. Consider the case, where the > SUBSCRIBE forks and the first 200/NOTIFY arrives from a notifier which > does not support suppressing and after a short while subscriber receives > the NOTIFY from another notifier with an entity-tag. It could be > preferable for the subscriber to terminate the first dialog and continue > the second one. Possible in theory, but in reality, how likely is it that this will be a problem? I just find it an incredibly bad idea to build a system that behaves this way. > * Implicit Subscriptions, REFER > I think this mechanism is applicable for implicit subscriptions as well. > It could be an idea to mention this somewhere (maybe in 2.3. > Requirements) > To say a sentence or two about REFER initiated subscriptions could be > useful as well. I guess it doesn't make much sense to use suppressing > capability in this case: "Although technically it is possible to use > notification/body suppressing capability for REFER initiated > subscriptions, this is not seen as desirable considering the REFER use > case." Hmm... Good point. AFAICS, this should work as-is with REFER subscriptions as well. I added this to section 4: The conditional notification mechanism is independent of the way in which subscriptions are installed. In other words, the mechanism supports implicit subscriptions, such as those associated with the <xref target="RFC3515">REFER method</xref>. > > Nits: > * 3. Overview of Operation, middle of the second paragraph > ", and attaches includes it in a SIP-ETag" > Just use either "attaches" or "includes" Fixed. Thanks for the review! Cheers, Aki _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Review of draft-ietf-sip-subnot-etags-01 Asveren, Tolga
- [Sip] Review of draft-ietf-sip-subnot-etags-01 Avshalom Houri
- Re: [Sip] Review of draft-ietf-sip-subnot-etags-01 Aki Niemi
- Re: [Sip] Review of draft-ietf-sip-subnot-etags-01 Aki Niemi