Review of draft-ietf-sip-subnot-etags-01

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

* 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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On ti, 2007-10-02 at 10:53 -0400, ext Asveren, Tolga wrote:

> Draft: draft-ietf-sip-subnot-etags-01
> Reviewer: Tolga Asveren [tasverensonusnet.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.i
etf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip