Subject: [Sip] comments on draft-ietf-sip-subnot-etags-00

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2007 10:36:54 -0400

Overall I think this document is in great shape. Some comments below, 
mostly minor:

> Changes in connectivity represent another impetus for a subscriber
>    re-subscribing.  If the subscriber's point of attachment to the
>    Internet changes, e.g., due to dynamic address allocation, the
>    subscriber needs to re-subscribe in order to update the dialog
>    endpoint, which is carried in the Contact header field of the
>    SUBSCRIBE request.
> 
>       Another option for reducing connectivity induced subscription
>       refreshes is to use the Globally Routable User Agent (UA) URI
>       (GRUU) [10] as a stable endpoint contact for subscriptions.

Yes, exactly. And here it works really well. So I would remove this 
paragraph as a motivation.

> The same problem affects fetching and polling of resource state as
>    well.  As a benchmark, if we look at the performance of HTTP [9] in
>    similar scenarios, it performs substantially better using conditional
>    requests.

I'm curious if you have actual data on this, or just speculation. most 
HTTP resources are dynamic so its not clear it actually helps http.

> NOTIFY request.  The entity tag is unique for that particular
>    resource and event notification.

You should clarify what it means to be unique for a resource *and* event 
notification. So this means if I fetch the resource with http it has a 
differnet entity tag?

> The two types of conditions available for a SUBSCRIBE are a Suppress-
>    Body-If-Match and a Suppress-Notify-If-Match; each of these header
>    fields contains the last entity-tag seen by the subscriber.  If the
>    condition evaluates to true, the first of these conditions will
>    instruct the notifier to suppress the body of the next notification
>    and the second the entire notification. 

Is there a reason we need both? Could we just have 
Suppress-Body-If-Match and if the subscription state is anything besides 
active and the subscription duration anything different than the Expires 
in the request, a NOTIFY is sent without a body?

> There is also a wildcard entity-tag with
>    a special value of "*" that always matches.

what is the use-case for this?

* I think you can actually implement this without option tags. The 
presence of the Suppress-* header fields basically plays that role.
Supported is needed if the UA is not asking for some feature in a 
request, but merely saying, its supported.

> uppress-Body-If-Match:  if this condition evaluates to true, the
>       notifier is instructed to suppress (i.e., remove) the body of the
>       first NOTIFY request following the SUBSCRIBE.  If false, the
>       notifier follows the default behavior.

Its not 'first' - its any subsequet NOTIFY whose body, had this 
specification not be in use, would contain the resource with that entity 
tag.

> Suppress-Notify-If-Match:  if this condition evaluates to true, the
>       notifier is instructed to suppress (i.e., block) the entire first
>       NOTIFY request following the SUBSCRIBE, and instead send a 204 (No
>       Notification) response.  If false, the notifier again follows the
>       default behavior.

I don't think we need a new response code. What is the justification?

>  The conditional header field can also be wildcarded using the special
>    "*" entity-tag value.  Such a condition always evaluates to true
>    regardless of the value of the current entity-tag for the resource.
> 
>    Example:
> 
>       Suppress-Notify-If-Match: *

This seems like a bad idea in fact. Why is it here?

* Section 4 needs to cover handling of the response to SUBSCRIBE (what 
happens when a 204 comes), and NOTIFY (store entity tag). Also needs to 
handle what to do in the case where the notifier doesn't support the 
mechanism.

> A notifier MUST generate entity tags for each resource it is
>    responsible for.
> 
>       The views might correspond to different groups of users that have
>       varying levels of access rights to the resource state, or to
>       subscribers that have modified their subscription using event
>       notification filtering [11].  For example, in presence [6]
>       watchers may get different levels of accuracy in geolocation
>       information, based on the presentity's privacy settings.

What do views have to do with this?

Nits:

> These procedures have a serious
>    deficiency in that they do not allow state to persist over a
>    subscription refresh, or between two consecutive polls. 

State can persist at the UA; its just that you get notified of stuff you 
already know.

>  An entity-tag is a token carried in the SIP-ETag header field, and it
>    is opaque to the client.  The notifier is free to decide the means
>    for generating an entity-tag, except for the special "*" value.

I think you mean, "The notifier is free to decide on any means for 
generating the entity-tag. It can have any value, except for "*""

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 Jul 2007 10:11:25 -0500

>>       Suppress-Notify-If-Match: *

We discussed this briefly at the microphone -- the answer can be 
paraphrased as "about half the stuff in Mohammad's notify-pause draft 
that we'll be discussing in SIPPING on Thursday."

If we move forward with the notify-pause stuff (which I think would be a 
good idea), then we need to have clarity around how these two mechanisms 
interact -- and whether it even makes sense in the etags document if 
we're going to develop a more complete way to address these use cases in 
the pause draft.

/a

---

From: Aki Niemi <[email-masked]>
Date: Tue, 24 Jul 2007 18:50:56 +0300

Inline.

> that we'll be discussing in SIPPING on Thursday."

As I said in the session today, this is not to pause a subscription at
all; it only affects the very next NOTIFY that the SUBSCRIBE is about to
generate. So I don't see where the overlap here is. (However, there is
considerable overlap with the notify-pause and the throttle draft, which
I used to author long ago when my hair was a lot shorter...)

The use-cases for the wildcard are as follows (also mentioned at the end
of 4.3.):

- Heartbeat, or liveliness check. Using Suppress-Notify-If-Match: *, the
watcher can check whether a resource is alive: a 204 response says it
is, a 404 says it is not.

- Meta-data retrieval. Just like a HEAD in HTTP, a SUBSCRIBE with
Suppress-Body-If-Match: * will generate a NOTIFY without the body but
with the full header, including the current SIP-ETag.

I agree that these are not cornerstone use-cases for this draft, but
they represent some low-hanging fruit that would be difficult to add as
an extension.

I think it is beneficial to make notifiers understand wildcards from the
very beginning.

(I believe it is also a trivial implementation effort. I mean it's a
single additional string comparison in addition to matching the given
etag value with the current etag value of the resource, which the
notifier in any case needs to perform.)

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Tue, 24 Jul 2007 19:36:08 +0300

Hi Jonathan,

Thanks for the feedback. Inline.

> paragraph as a motivation.

Done.

> HTTP resources are dynamic so its not clear it actually helps http.

I haven't looked at any empirical data on this. This comment is more
about the protocol itself, not the web as such.

And while most actual content may be dynamic, think of the dozens of
pictures that a typical web page has as backgrounds, delimiters, and
other graphics. These things rarely change, even if the actual content
of the page changes; a refresh GET really should not replay all those
jpegs.

I would make a simile here to a typical SIP notification generated
because of a refresh.

> notification. So this means if I fetch the resource with http it has a

My working copy says:

	The entity-tag MUST be unique across all versions of
	all entities for a resource.

I think we should also add "...and event package" just to be clear.

I think we should also add that the subscriber should never assume that
the entity-tags are shared between notification and, say, SIP event
publication or HTTP.

> in the request, a NOTIFY is sent without a body?

This would be a very drastic simplification, and it would not work for
polling, which was one of the original use-cases.

In fact, another way of doing this is to *always* use
Suppress-Body-If-Match: * in refreshes, according to the current draft.

I still believe the ability to suppress the entire NOTIFY is a valuable
feature, but as Rohan pointed out, it may also have backwards
compatibility issues, as it is a more substantial change to RFC3265.

> request, but merely saying, its supported.

The only reason it's there, actually, is for the subscriber to give a
hint to the notifier, that etags are supported. This is when a SUBSCRIBE
has no Suppress-*, i.e., it's the very first SUBSCRIBE.

However, I agree it adds very, very little value. I'll remove it.

> specification not be in use, would contain the resource with that entity

Ahh, I see. Now I understand why Adam was seeing the overlap with
notify-pause.

It's 'first' intentionally. The mechanism is supposed to only affect the
very NOTIFY that the SUBSCRIBE is about to generate. It could be 'any
subsequent' but would there be any reason that a notifier replays
notifications if there's no change?

> I don't think we need a new response code. What is the justification?

It is to enable the subscriber to destroy its handle as soon as the 204
is received, instead of keeping it indefinitely in case there is a
NOTIFY forthcoming (it may not ever come).

> handle what to do in the case where the notifier doesn't support the

I can add text to the numbered lists of 4.x sections about storing the
entity tags. The very last bullets of each of 4.x sections do talk about
what the subscriber is to do with the 204. Should there be a sub-section
in section 4 that has normative text on these though?

> What do views have to do with this?

Here view == entity, but clearly the view should be in double quotes, as
it's not a term that is clearly defined anywhere. However, The next
version will have section 5.1. strengthened to make this part of the
model (hopefully) clear.

> State can persist at the UA; its just that you get notified of stuff you

True. I'll reword:

...deficiency in that they provide no tools to avoid replaying event
notifications that are already known to the UA.

> generating the entity-tag. It can have any value, except for "*""

True, this is already fixed in my working copy. Dale made the same
correction.

Cheers,
Aki