Hi Dale,
Thanks for the review.
ext [EMAIL PROTECTED] wrote:
> 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 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 />
> 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".
Fixed.
> 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".
Right, we have SIP-ETag defined in RFC 3903 already.
> Sections 3 and 4.2:
>
> "two types of Xs" is better phrased "two Xs".
Fixed.
> 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.
Fixed.
> 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."
Much better. Fixed.
> 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".
Fixed.
> 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.
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
_______________________________________________
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
