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

From: "Vrancken, Johnny" <[email-masked]>
Date: Mon, 25 Sep 2006 11:36:15 +0200

Hi Aki,

Here are some comments on your document. 

PAGE 2  "When such a condition fails, the event state is not sent in a
notification."
COMMENT: As you have introduced the conditions "Suppress-Body-If-Match"
and "Suppress-Notify-If-Match", you may have that the event state is not
sent in a notification or no notification is sent at all.

PAGE 4:  "... the SIP events framework does not include different
protocol methods for initial  subscriptions, subscription refreshes and
fetches inside and outside of the SIP dialog."
COMMENT: the same holds for terminating a subscription (unsubscription)

PAGE 5: REQ1: "... triggered by a subscription refresh, ..."
COMMENT: the same holds for a subscription termination (unsubscription)

PAGE 6: "If the entity-tags match, either an empty entity body is sent
in a notification, or no notification is sent"
COMMENT: "An empty entity body" could be misinterpreted as e.g. "an
empty presence document" in the presence context (e.g. <presence
entity="XXX" />), so it is recommended to reformulate it as "a
notification without a body".

PAGE 7: "The views might correspond to different groups of users that
have varying levels of access rights to the resource state."
COMMENT: you may add "and/or subscribers that have indicated via a
subscription filter interest in a particular view of the resource
state."

PAGE 7: "... the local entity-tag for the resource and the subscriber
provided entity-tag ..."
COMMENT: should be "... the local entity-tag for the resource state to
be notified and the subscriber provided entity-tag ...", as there might
be several different entity tags per resource - see section 4.1

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.

PAGE 8: "When a condition to suppress a NOTIFY is true, i.e., the local
entity-tag and the subscriber provided entity-tag in a
Suppress-Notify-If-Match ..."
COMMENT: To align it with the text of section 4.1: "When a condition for
suppressing a NOTIFY request is true, i.e., the local entity-tag for the
resource state to be notified and the subscriber provided entity-tag in
a Suppress-Notify-If-Match ..."

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

General COMMENT: Applicability of the ETag mechanism for resource 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.

Kind regards,

Johnny Vrancken

_______________________________________________
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, 26 Sep 2006 10:37:41 +0300

Hi Johnny,

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

> Content-Type header field is only required if the message body is not

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

<snip />

> provide multiple entity-tag values for these headers.

True, but the grammar for these only allows a single entity-tag.

> not receive information (NOTIFY request) about which one of entity-tags

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

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.

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

Can you elaborate why there would need to be a need for additional
specification?

Cheers,
Aki