On ti, 2007-10-02 at 10:53 -0400, ext Asveren, Tolga wrote:
> Draft: draft-ietf-sip-subnot-etags-01
> Reviewer: Tolga Asveren [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
