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 PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
