Subject: RE: [Sip] Re: Comments on draft-niemi-sip-subnot-etags-01

From: "Vrancken, Johnny" <[email-masked]>
Date: Wed, 27 Sep 2006 18:09:38 +0200

Hi Aki,

See replies inline ...

Kind regards,
Johnny

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]] 
Sent: dinsdag 26 september 2006 9:38
To: Vrancken, Johnny
Cc: [email-masked]
Subject: [Sip] Re: Comments on draft-niemi-sip-subnot-etags-01

Hi Johnny,

Thanks for the feedback. A couple of comments inline; the rest I patched
into my working copy.

ext Vrancken, Johnny kirjoitti:
> PAGE 7: "The Content-Type header field of the NOTIFY request is set an
> appropriate value, depending on the event package, but  .....The
> Content-Length MUST be set to zero, and no payload is attached to the
> message."
> COMMENT: The first part of this sentence is to be omitted, as a
> Content-Type header field is only required if the message body is not
> empty.

The way this was intended to work was that the notifier sends a NULL
body, like this:

...
Content-Type: application/pidf+xml
Content-Length: 0

What you're suggesting is that the notifier sends no body at all. I
think that might not work, as some UAs might reject a NOTIFY that has no
body (as it's supposed to always have one).

[Johnny] This problem also has popped up in OMA-PAG interoperability tests.
RFC3265 states that there could be empty NOTIFY messages (section 3.1.6.2), so UA's should/must be prepared to receive a NOTIFY request without a body. I think a body in a NOTIFY request is only required, if you have to convey information that is not contained in the NOTIFY request headers.
The new Suppress-Body-If-Match header you introduced may result in NOTIFY request without a body, isn't it?

Considering the descriptions of Content-Length (§20.14) and Content-Type (§20.15) in RFC 3261:
* "the Content-Length header MUST be set to zero if no body is present in a message."
* "the Content-Type header MUST be present if the body is not empty", hence there is not a MUST for the cases where the body is empty. 
Moreover, in RFC3265 (section 7.1) the Content-Type header for NOTIFYs has a "*", meaning (according to RFC 3261 section 20) that "the header field is required if the message body is not empty".

<snip />

> PAGE 9: "and entity-tag in RFC3265"
> COMMENT: entity-tag is defined in RFC3903
> 
> PAGE 9: Grammar
> COMMENT: the syntax of the new header allows a subscriber to supply only
> a single entity-tag value. The syntax of similar header fields for
> conditional requests in RFC2616 (If-Match, If-None-Match) allows to
> provide multiple entity-tag values for these headers.

True, but the grammar for these only allows a single entity-tag.
[Johnny] I assume you want to say that in the current version of your document the Suppress-Body-If-Match and Suppress-Notify-If-Match header only allow to provide a single entity-tag.

> Therefore, it can be considered to allow multiple entity-tag values for
> the new Suppress-Body-If-Match header. If there is a match, the NOTIFY
> request will contain the entity-tag of the resource state that is valid.
> Allowing multiple entity-tag values for the Suppress-Notify-If-Match
> header is not meaningful, as the subscriber, in case of a match, does
> not receive information (NOTIFY request) about which one of entity-tags
> is valid.

I'm not sure if you're arguing for or against having multiple
entity-tags in these fields.

[Johnny]I'm arguing for having multiple entity-tags for the Suppress-Body-If-Match header, merely to have a syntax similar to If-Match and If-None-Match in RFC2616.
You mentioned that optionally the notifier could keep record in a journal of recent resource states and their associated entity tags. The subscriber could do the same.
A use case that crosses my mind is an RLS server that makes back-end subscriptions of behalf of different watchers to the same resource. Hence, the RLS server may have stored multiple entity-tags (and associated state information) for this resource. When the RLS server sends a back-end SUBSCRIBE request for a resource, it could supply e.g. the most recently received entity-tags pertaining to this resource.
But if you decide to allow only a single entity-tag for the Suppress-Body-If-Match header, I will not be disappointed.

As entity-tags in SIP events are always tied to a subscription anyway,
there's no use-case I came up with that would actually make use of more
than a single entity-tag. Similarly, I dropped the notion of weak entity
tags, as they are a contentious issue even in HTTP and I had absolutely
no idea how they would work in SIP.
[Johnny]When you state "As entity-tags in SIP events are always tied to a subscription", do you mean subscription in general or a particular subscription? As I understood it, an entity-tag uniquely references/identifies a particular resource state in a subscriber / notifier information exchange. 

> General COMMENT: Applicability of the ETag mechanism for resoure list
> subscriptions.
> The document focuses on an ETag mechanism for subscriptions targeted on
> a single resource. However, one can also subscribe for a resource list
> (RFC4662). In that case, the resulting NOTIFY requests comprise the
> resource state of no / one / multiple resources in addition to Resource
> List Meta Information (RLMI) pertaining to the resource list
> subscription. This RLMI information contains information about the
> individual resources and the status of the virtual subscriptions.
> Your document preferably should include a statement about the
> applicability of the ETag mechanism for resource list subscriptions.
> You may either state that
> 1. it is out of scope of the document
> 2. the mechanism also can be applied to resource list subscriptions. In
> that case you need to clearly specify what the ETag represents (e.g.
> does it also include the full RLMI information ?)
> 3. you could consider to exchange a set of ETags, one for each resource
> in the list. In the NOTIFY request, these ETags can be included in the
> RLMI information but for the SUBSCRIBE request a new mechanism is to be
> introduced to exchange the ETags of the individual resources.

I think this mechanism applies to resource-list subscriptions
out-of-the-box, as it should to any type of subscriptions. The etags
work on the level of subscriptions, and really don't care what event
package is carried on top.
[Johnny]I don't get your point. I agree that the etag mechanism works for any event package.

Can you elaborate why there would need to be a need for additional
specification?
[Johnny] Suppose you are polling the event state of a resource list.
The resulting NOTIFY request contains an etag, RLMI information about the N resources in the list (resource info, info on the back-end subscriptions), and the resource state of M resources for which successfully a back-end subscription was made.
Suppose that in a subsequent poll for the same resource list, the resource state of the same M resources has not changed but some RLMI information has changed, e.g.
 - information about a resource in the resource list has changed 
 - information about a back-end subscription has changed
 - a resource is added / deleted, for which for whatever reason no resource state is notified
Does the notifier generated local entity tag and the subscriber provided etag match in this case?

In the above resource list polling example and assuming that a single entity tag is used for the whole resource list,  ALL M resource states are to be included in the resulting NOTIFY request if there is a change in ONE of the resource states. If entity tags per resource were conveyed, then only the resource state of the resources that actually have changed would have to be notified.
Please note that usage of a set of Etags (one per resource) in case of a resource list subscription is just a suggestion, nothing more.

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

_______________________________________________
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