Subject: [Sip] Comments on draft-ietf-sip-subnot-etags-00

From: Qian Sun <[email-masked]>
Date: Wed, 04 Jul 2007 16:09:13 +0800

Hi, 
I am not sure whether the following description in this draft is enough for the usage of Entity-tags with filtering.

      "5.1.  Generating Entity-tags
      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]."

My consideration is:
If a subscriber has a subscription with filter F1, the current corresponding entity-tag is E1. Then the same subscriber MUST NOT send SUBSCRIBE with a new filter F2 and the entity-tag E1 in the conditional header field.
i.e., if a subscriber changes filter for an event state, the Suppress-XXX-If-Match should not be used.
The client of subscriber has to record the last filter for event state and compare filters.

Cheers,
Qian

_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Tue, 17 Jul 2007 12:52:40 +0300

Hi Qian,

And sorry for a late answer to your comment. I have been on vacation
enjoying the beautiful Finnish summer. ;)

ext Qian Sun wrote:
> Hi, I am not sure whether the following description in this draft is
> enough for the usage of Entity-tags with filtering.
> 
> "5.1.  Generating Entity-tags 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]."
> 
> My consideration is: If a subscriber has a subscription with filter
> F1, the current corresponding entity-tag is E1. Then the same
> subscriber MUST NOT send SUBSCRIBE with a new filter F2 and the
> entity-tag E1 in the conditional header field. i.e., if a subscriber
> changes filter for an event state, the Suppress-XXX-If-Match should
> not be used. The client of subscriber has to record the last filter
> for event state and compare filters.

If I understand your concern correctly, the problem is with filtering
and not with subnot-etags. I think a subscription that installs a
filter, or disables/removes it could effectively be an action that
itself changes the event state, and causes an if-match condition to fail.

But this all depends on the actual implementation of the filtering
system. In other words, this seems like an implementation detail of the
filtering system.

At the moment, I am not aware of any existing filtering implementations,
so I'm reluctant to adding any specific text to the draft either. If
this becomes a problem, we can always write an update to the filtering
specifications.

Cheers,
Aki

---

From: Qian Sun <[email-masked]>
Date: Wed, 18 Jul 2007 11:29:29 +0800

Hi Aki,

As I know, OMA PAG has adopted both filtering and this subnot-etags, maybe some companies are developing their products according to OMA specification. 

Cheers,
Qian

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 5:53 PM
To: ext Qian Sun
Cc: 'IETF SIP List'
Subject: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00

Hi Qian,

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Wed, 18 Jul 2007 09:53:14 +0300

Hi Qian,

ext Qian Sun wrote:
> Hi Aki,
> 
> As I know, OMA PAG has adopted both filtering and this subnot-etags,
> maybe some companies are developing their products according to OMA
> specification.

If that's the case then would this be something for which the OMA PAG
specifications could maybe provide some clarification?

Cheers,
Aki

---

From: [email-masked]
Date: Thu, 19 Jul 2007 00:19:51 -0400

Technical issues:

What if both Suppress-Body-If-Match and SuppressN-Notify-If-Match are
specified?  We probably don't really care, but the document should
make it clear if the combination is standardized or not.

The entity-tag values for a single resource are the same across
subscriptions, but it is not clear whether they are in some sense the
same between subscriptions for different resources, or for different
resource-IDs that refer to "the same" underlying resource.  This may
have significance for renewed subscriptions whose initial requests are
sent to the same resource AOR but which are ultimately routed to
different but "equivalent" resource-IDs.

Nits:

Section 2.2

   o  Relatively low rate of actual notifications triggered by actual
      state changes

Better phrased "Relatively low rate of notifications triggered by
state changes".

Section 3:

The entity-tag header is "SIP-ETag", but the "SIP-" portion is
redundant.  I suppose it's too late to change it to just "ETag".

Sections 3 and 4.2:

"two types of Xs" is better phrased "two Xs".

Section 4.5:

   2.  If the condition evaluates to true, the notifier sends a 204 (No
       Notification) response sends no NOTIFY request.

Should be "sends a 204 (No Notification) response and sends no NOTIFY
request.

Section 5.1:

   The notifier is free to decide the means for generating an
   entity-tag, except for the special "*" value.

Better phrased "free to decide how to generate the entity-tag values,
except that no entity-tag may be the special "*" value."

Section 5.3:

   the notifier MUST suppress the resulting NOTIFY request, and
   generate a 204 (No Notification) "No Notification" response.

Should be "a 204 (No Notification) response".

Sections 8.3 and 8.4:

   This document registers two new SIP header field names.  These
   headers are defined by the following information, which has been
   added to the header fields sub-registry under
   http://www.iana.org/assignments/sip-parameters.

This paragraph is duplicated, and it appears to be addressing both
header registrations together, rather than either one alone.

Dale

---

From: Aki Niemi <[email-masked]>
Date: Thu, 19 Jul 2007 13:41:45 +0300

Hi Dale,

Thanks for the review.

> make it clear if the combination is standardized or not.

The combination makes no sense, and should receive a 400 Bad Request.
Perhaps the following patch to Section 4.2., 1st paragraph:

OLD:

> When creating a conditional SUBSCRIBE request, the subscriber MUST
>    include a conditional header field including an entity-tag to the

NEW:

> When creating a conditional SUBSCRIBE request, the subscriber MUST
>    include a single conditional header field including an entity-tag to the
               ^^^^^^

(I cut out the next technical issue into a separate email with a new
subject, as I think it may require a bit more discussion.)

<snip />

> Better phrased "Relatively low rate of notifications triggered by

Fixed.

> redundant.  I suppose it's too late to change it to just "ETag".

Right, we have SIP-ETag defined in RFC 3903 already.

> "two types of Xs" is better phrased "two Xs".

Fixed.

> Should be "sends a 204 (No Notification) response and sends no NOTIFY

Fixed.

> except that no entity-tag may be the special "*" value."

Much better. Fixed.

> Should be "a 204 (No Notification) response".

Fixed.

> header registrations together, rather than either one alone.

Changed each instance to:

   This document registers a new SIP header field called
   Suppress-{Body, Notify}-If-Match. This header field is defined by
   the following information, which has been added to the header
   fields sub-registry under
   http://www.iana.org/assignments/sip-parameters.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Thu, 19 Jul 2007 13:44:29 +0300

I split out this issue from Dale's email into a separate message.

> different but "equivalent" resource-IDs.

Qian also had similar comments; obviously this seems to be something the
draft does not define clearly enough. I suspect Section 5.1. would need
additional text explaining the model behind etags in more detail.

However, before we try to come up with that text, let's see if we are on
common ground on some basic assumptions (as I suspect we might not be
there 100%). For the most parts the model should be equivalent to that
in HTTP (or at least to my reading of RFC2616).

Here are the assumptions under which subnot-etags are currently defined:

- There is a single authoritative notifier agent responsible for any
single resource.

- A resource is identified using a SIP URI.

- A subscriber subscribes to a resource using the SIP URI.

- With a successful subscription, a subscriber gets access to an entity
from the resource. (Entity is HTTP lingo, and basically means a certain
"view" of the resource state.)

- An entity can be influenced by different external data, e.g., filter
rules, authorization rules, etc.

- There is a one-to-many relationship between the resource and the
entities.

- Each entity has an assigned entity-tag.

- There is a one-to-many relationship between an entity and its versions
(different etag values, of which only one is current).

- An entity-tag must be unique across all versions of all entities from
a resource.

- The rest are implementation details.

Comments?

Cheers,
Aki

---

From: [email-masked]
Date: Thu, 19 Jul 2007 10:11:56 -0400

From: Aki Niemi <[email-masked]>

Often a subscriber will send the SUBSCRIBE to a URI which is not the
request-URI of the SUBSCRIBE when it reaches the notifier agent.  This
happens due to normal SIP request routing, but the routing can also
change with time.

Each entity has a succession of versions.  Each version of each entity
has an assigned entity-tag.

Does this rule out hash-based entity-tags, which are only
probabalistically unique?

Dale

---

From: Aki Niemi <[email-masked]>
Date: Fri, 20 Jul 2007 11:55:21 +0300

Hi Dale,

> happens due to normal SIP request routing, but the routing can also

Correct, but are you saying there might be more than one agent with a
different idea on the entity-tags of entities pertaining to a certain
resource? In other words, that the resource has multiple agents that may
have a different view of the resource state?

I believe this is disallowed per RFC3265 already.

> has an assigned entity-tag.

Yes.

> probabalistically unique?

No, I think this MUST statement should probably be followed with an
implementation note that talks about what's reasonably unique in this
context.

Cheers,
Aki

---

From: [email-masked]
Date: Fri, 20 Jul 2007 07:05:27 -0400

I doubt things could work with multiple agents that have a different
view of the resource state.

But there might be multiple agents with different addresses, from whom
you request the state of the same resource using different SIP URIs.
(Which ultimately might all be destinations reached by sending
requests to the same AOR.)

I don't think it interferes with the subnot mechanism, but my point is
that a resource might *not* have a single, specific SIP URI, either as
the request-URI when the SUBSCRIBE reaches the agent(s) which can
deliver its state, or as the address to which UAs subscribe.

All you need to make subnot work is that every UA agrees on which
subscriptions are "for the same resource", and that all notifiers for
"the same resource" generate the same etags for the same state, and
different etags for different state.

Dale

---

From: Aki Niemi <[email-masked]>
Date: Mon, 23 Jul 2007 17:22:06 +0300

Hi Dale,

> deliver its state, or as the address to which UAs subscribe.

That's fine. I think aliases work as long as the relationship is clear.
A single resource can have multiple URIs pointing to it, and each
resource will only ever have a single agent responsible for it.

> different etags for different state.

Right, that would need to be spelled out in section 5.1., I think.

Cheers,
Aki

---

From: [email-masked]
Date: Mon, 23 Jul 2007 17:01:55 -0400

I probably didn't make myself clear, in that this is just a matter of
wording and terminology.  But if the RFC isn't worded correctly,
people might create non-workable implementations.

Dale