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