Subject: [Sip] Subnot-etags: refactoring

From: Aki Niemi <[email-masked]>
Date: Mon, 27 Aug 2007 10:37:02 +0300

All,

Currently, the draft explicitly scopes the conditional notification
mechanism to the very first NOTIFY that gets triggered by a SUBSCRIBE.
Jonathan made a proposal to refactor the subnot-etags so that the
mechanism would conditionally suppress either the entire notification or
the notification body of any subsequent NOTIFY.

For example, if the entity-tags match this would automatically suppress
the NOTIFY immediately after a subscription refresh, as well as any
NOTIFY bodies thereafter where the entity-tag has not changed, but e.g.,
the subscription state has.

In practice, we would now only have a single "Suppress-If-Match" header
field, and the notifier's behavior would be altered to suppress
everything if the entity-tags match and there are no other reportable
changes; otherwise if the entity-tags match but the subscription-state
has changed, the notifier only suppresses the body.

I think this is a great idea since both the efficiency of the mechanism
increases (suppresses more redundant information), while the complexity
actually decreases (there is now only a single behavior for the notifier
to follow). However, this does require some pretty extensive changes to
the draft, which makes this maybe more of a redesign after all ;).

But I'm at least convinced this is what we should do, so I will go ahead
and make those changes, unless someone vehemently disagrees.

Objections?

Cheers,
Aki

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Mon, 27 Aug 2007 09:45:06 -0500

I'm still pretty uncomfortable with suppressing the entire NOTIFY for
a refresh subscription. There are mechanics that involve the  
Subscription-State
header and its possible extension that I fear we will interact with  
in unexpected ways.

I will admit that all the specific instances of that I can think of  
right now you can work
around by being really careful with the success response to the  
reSUBSCRIBE. Can
anybody come up with a case (or imagine an extension) where the  
response to the
reSUBSCRIBE won't have the right stuff?

I'm ok with suppressing bodies of subsequent NOTIFYs.

RjS

---

From: Aki Niemi <[email-masked]>
Date: Thu, 30 Aug 2007 10:26:25 +0300

ext Robert Sparks wrote:
> header and its possible extension that I fear we will interact with in
> unexpected ways.

The way this works now is that we are explicit on what is considered the
"entity" and what is not. In the current version of the draft, we
explicitly say that the "entity" is the event data in the body plus
Content-* and Entity fields in the header. On the other hand,
subscription state is *not* part of the entity, and therefore not
covered by the entity-tag.

This then gives the notifier three choices when it gets a SUBSCRIBE
requesting for conditional notification. It will either:

1) report nothing (204 response) if neither entity nor subscription
state have changed;
2) suppress the body if only the subscription state has changed;
3) send a full notify if the entity has changed

So I think this solves your concern, since the notifier can always
report the changes, even in the subscription refresh. Before, this was
actually quite poorly defined.

> anybody come up with a case (or imagine an extension) where the response
> to the

I believe currently there are none. However, if in the future there are
extensions that should be considered to be part of the "entity" or
subscription state, then those event-packages would need to define this
behavior. In practice, they would need to cover cases where changes in
these additional header fields would trigger a NOTIFY without the body,
or a NOTIFY with a body and a changed entity-tag.

Cheers,
Aki

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Aug 2007 09:30:34 -0500

Ok - sounds like we're good then.
I'll keep an eye on making sure this is clear to the implementor  
during LC review.

RjS

On Aug 30, 2007, at 2:26 AM, Aki Niemi wrote:

>> response