Hi Keith,
Thanks for a thorough read. Responses inline.
ext Drage, Keith (Keith) wrote:
> 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.
Fixed.
> 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.
You probably mean section 21.
Added the following text to a new section titled "Protocol Element Definitions":
<section anchor="proto_resp" title="204 (No Notification)
Response Code">
<t>
The 204 (No Notification) response code indicates that
the request was successful, but the notification associated
with the request will not be sent.
</t>
<t>
The response code is added to the "Success" production rule
in the <xref target="RFC3261">SIP</xref> message grammar.
</t>
</section>
This new section also includes similar sub-sections on the new header
fields, as well as the "Grammar" section.
> 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.
Done.
> 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.
Done.
> 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).
Yes, the extension is usable with all event packages.
> 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".
Fixed.
> 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.
While I agree that a different title might be more descriptive of the
content of the section, I would prefer to keep the flow diagrams in
place, right next to the description of the functionality. This way the
implementer need not jump back and forth between text and the examples
section (which I intend to add as soon as I get around to generating
some real message dumps).
> 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.
Fixed by adding one such normative statement.
> 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).
Done.
> 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.
Fixed.
> 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.
Changed to:
<t>
Such a successful conditional SUBSCRIBE request
MUST extend the subscription expiry time.
</t>
> 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.
Added:
<t>
Some event packages may support a scheme where
notifications contain state differentials, or <xref
target="RFC3265">state deltas</xref> instead of complete
resource state.
</t>
> 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).
Done.
> 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.
Added into section titled "Protocol Element Definitions":
<t>
This header field is allowed to appear in any
request, but it's behavior is only defined for the
SUBSCRIBE request.
</t>
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 protected] for questions on current sip
Use [email protected] for new developments on the application of sip
