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

From: Aki Niemi <[email-masked]>
Date: Mon, 02 Oct 2006 14:26:27 +0300

ext Vrancken, Johnny kirjoitti:
> 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?

Here's the relevant thread where this was discussed a while ago, and to
which I was referring:

http://www1.ietf.org/mail-archive/web/simple/current/msg04057.html

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

Yup, but as the thread above also points out, section 20.15. says:

>    The Content-Type header field MUST be present if
>    the body is not empty.  If the body is empty, and a Content-Type
>    header field is present, it indicates that the body of the specific
>    type has zero length (for example, an empty audio file).

That said, however, I'm not sure whether suppressing the body of a
NOTIFY actually constitutes such a content/no-content choice. Basically,
I could go either way on this, i.e., null body (Content-Type but
zero-length) or no body at all (no Content-Type, zero-length).

Any other opinions?

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

Right.

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

But that link was already broken in RFC3903, where entity-tag is
specified. In hindsight, we probably would have been better off
inventing a new name, like event-tag. Just to avoid the confusion...

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

I would think that the RLS aggregates resource state it receives via the
backend subscriptions. For instance, even if there are n buddies
watching M, the RLS only makes a single backend subscription to M.

In turn, each of n would get a unique entity-tag that points to some
aggregate set of resource states; these sets would probably often not be
a proper subset of each other (I don't have myself on my buddy list, but
most people on my buddy list have me as their buddy).

So I still don't quite see how juggling with multiple entity-tags in the
backend would work.

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

I mean, there is only ever a one-to-one relationship between an
entity-tag and a subscription. In other words, you never juggle with
more than one etag per a given {dialog, event, id} tuple (or did I miss
some?) ;-)

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

I would say yes, the etag would change, since the RLMI is also part of
the state.

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

I'm not sure I'm convinced on the idea of multiple etags. To me, it
seems logical to have whatever the event package considers full state
(here, it would be resource state plus meta-info) be identifiable by a
single etag.

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

---

From: "Vrancken, Johnny" <[email-masked]>
Date: Tue, 3 Oct 2006 09:52:36 +0200

Hi Aki,

Thanks for clarifying the distinction between "no body" and "null body"
in a SIP message, something I wasn't aware of. 
I have no strong opinion on whether "no body" or "null body" is to be
notified in case Suppress-Body-If-Match applies.

> watching M, the RLS only makes a single backend subscription to M.

This might be true on particular conditions, but surely is not generally
the case. One of the preconditions is that the RLS has access to and can
apply M's authorization rules (subscription authorizations and privacy
filters).

Please note that I support promoting your document as a WG item, as it
is a rather simple means to reduce the message size and number of
messages between UAC and UAS.

Kind regards,
Johnny