Hi Jonathan,
Thanks for the feedback. Inline.
ext Jonathan Rosenberg wrote:
> 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.
Done.
>> 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.
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.
>> 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 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.
>> 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.
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.
>> 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.
>> 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?
>> 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).
> * 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?
>
>> 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.
> 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.
True. I'll reword:
...deficiency in that they provide no tools to avoid replaying event
notifications that are already known to the UA.
>> 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 "*""
True, this is already fixed in my working copy. Dale made the same
correction.
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
