Subject: [Sip] Comments on draft-niemi-sip-subnot-etags-03.txt

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 12 Mar 2007 18:54:40 +0100

These are mainly presentation issues. I did not find anything to comment on technically.

1)	Throughout the document, put response code usage in the format of RFC 3261 conventions, i.e. "204 (No Notification) response", not "204 response" or "204 "No Notification" response.

2)	There appears to be no text in the document that defines a semantic for the 204 header response. I am thinking of text like that which appears for each response in RFC 3261 section 20.

3)	In the text, there are a couple of instances where we have "Note that...". I am not convinced that either of this text is auxiliary text to the main document, in which case delete the words "Note that". If it is auxiliary text, follow the RFC 3261 convention and indent it.

4)	Section 8 (IANA considerations). I have a preference for seeing where possible the new material going into the IANA table in the format it has to be put in. Can you reformat this text as given in e.g. draft-ietf-sip-uri-list message. I think I also have a preference for putting the two new header fields in separate sections.

5)	RFC 3265 defines guidelines to be followed by the writers of new packages. Is there any requirement to update those guidelines to indclude usage of this extension or can this extension be used at will for SUBCRIBE requests for all packages? I think the latter is true, but I would like to see it confirmed (on list rather than in document).

6)	In the overview of operation (Section 3), clearly identify the header fields; I would prefer to see: "and includes an entity-tag in the Suppress-Notify-If-Match header field" rather than "and includes a Suppress-Notify-If-Match condition".

7)	Section 4 is entitled "Subscriber Behaviour", therefore I would not have expected to see examples (section 4.3, section 4.4 and section 4.5, and section 4.6) in this section, as the examples cover both the subscriber and notifier behaviour. I suspect you need to move these into a section by themselves, but you do need to consider the relationship with section 2 flow diagrams as well.

8)	In section 4, we apparently have no normative requirements on the subscriber. We seem to miss explicitly stating that the subscriber MUST support the two header fields as described, and generate them in accordance with the semantics given.

9)	Section 5.1, change:

   The entity-tag MAY be
   remembered longer than this, e.g., for implementing journaled state
   differentials (Section 5.4).

To:

   The notifier MAY remember the entity-tag longer than this, e.g., 
   for implementing journaled state differentials (Section 5.4).

10) Section 5.2:

   When a condition for suppressing a NOTIFY body is true, i.e., the
   local entity-tag for the resource state and the subscriber provided
   entity-tag in a Suppress-Body-If-Match header field match, the
   notifier MUST suppress the body of the resulting NOTIFY request.  The
   NOTIFY MUST NOT contain a Content-Type header field, the Content-
   Length MUST be set to zero, and no payload is attached to the
   message.

We seem to be trying to say the same thing twice in RFC 2119 language here. Either we state the "MUST suppress" in RFC 2119 language and then indicate the consequence of that supression in non RFC 2119 language, or we do it the other way round, i.e. MUST treat headers as described, with the effect of supressing the body.

Note that in section 5.3 you have chose the former manner:

   When a condition in a SUBSCRIBE request to suppress a NOTIFY request
   is true, i.e., the local entity-tag of the resource and the entity-
   tag in a Suppress-Notify-If-Match header field of a SUBSCRIBE request
   match, the notifier MUST suppress the resulting NOTIFY request, and
   generate a 204 ("No Notification)" response.

11)	Section 5.3. How do I conform to the following...

   Such a successful conditional SUBSCRIBE request MUST otherwise work
   the same as one without the condition.

I feel that we could get this a bit more precise.

12)	Section 5.4:
  
   5.4.  State Differentials

   A notifier can optionally keep track of the state changes of a
   resource, e.g., storing the changes in a journal.  If a condition
   fails, the notifier MAY send a state differential in the NOTIFY
   rather than the full state of the event resource.  This is only
   possible if the event package and the subscriber both support a
   payload format that has this capability.

Where are state differentials defined. We need at least a reference here.

13)	Section 6

We either need an ABNF reference here, or a statement that it extendes the ABNF defined in RFC 3261 (where we have the ABNF reference).

14)	We describe the behaviour of the new header fields in regard to SUBSCRIBE and NOTIFY, but fail to say what the usage requirements are in relationship to other methods. Whether you do this in the format of RFC 3261 table 2 and 3, or by writing text I do not mind, but it does need to occur.

Regards

Keith

_______________________________________________
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