[Sip] Review of draft-ietf-sip-subnot-etags-01

["Asveren, Tolga" <[e-mail]>]

Draft: draft-ietf-sip-subnot-etags-01
Reviewer: Tolga Asveren [[e-mail]]
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.

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

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

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

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


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

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


Nits:
* 3. Overview of Operation, middle of the second paragraph
", and attaches includes it in a SIP-ETag" 
Just use either "attaches" or "includes"


_______________________________________________
Sip mailing list  https://www1.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