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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Aug 2007 12:03:05 -0400

sorry for the delay. More below:

Aki Niemi wrote:
> Hi Jonathan,

>>> 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?
> 
> 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'm not sure what that means. You mean, if the same object is delivered 
in multiple event packages? When does that happen?

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

Right, that would be a good clarification.

The other issue is you need to be clear about what you mean by 
'resource' in your text above. For example if two SIP URI are different 
but happen to resolve to the same user, is that the same resource and 
would the etags be the same? (I think no).

> 
>>> 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?
> 
> This would be a very drastic simplification, and it would not work
> for polling, which was one of the original use-cases.

Well, if you change the rule to be that, no NOTIFY is sent at all if:

1. the subscription duration in the SUBSCRIBE was zero and the etags 
matched,
2. the subscription duration in the SUBSCRIBE is non-zero, the etags 
match, and the resulting subscription has a duration matching the 
expires time with a state of active

i.e., if it 'works as asked', then there is no NOTIFY.

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

That will still send the NOTIFY, so I'm confused how that provides a 
single mechanism for covering body and NOTIFY suppression..

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

I am agreeing that suppressing the entire NOTIFY is a good feature. But 
you have to do it in cases where you are sure that the state is known to 
the client.

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

Great, thanks.

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

Sure, because of subscription state changes.

> 
>>> 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?
> 
> 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).

OK, that needs to be clearer.

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

Yes. Generally the right structure for extensions is something like:

UA Behavior

   Sending Requests

   Processing Responses

and you are mostly covering the sending of requests.

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

OK.

Thanks,
Jonathan R.
-- 
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: Aki Niemi <[email-masked]>
Date: Mon, 27 Aug 2007 09:53:51 +0300

Hi Jonathan,

There's a more substantial issue you raised which I'll cover in a
separate email. I think what you suggest makes sense, but requires a bit
of redesign. What I will do is submit the working version I have ready.
At this point there's quite a backlog of fixes so it makes sense to get
that out now. Then we can address the redesign issue.

> in multiple event packages? When does that happen?

I mean that entity-tags for presence can collide with entity-tags for
the conference package. I think it makes sense to include the Event
header field as being part of the entity.

> would the etags be the same? (I think no).

I have put in quite a bit of text around this, so let's defer this to
when I get the new version out. I think this is now covered, and that
there isn't a problem even if the entity-tags collide for notifications
in subscriptions that were made to a different URI.

<snip />

> and you are mostly covering the sending of requests.

This is fixed in the upcoming version.

Cheers,
Aki