Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03

[Adam Roach <[e-mail]>]

John:

Thanks for the review. Responses inline.


On 11/30/09 9:42 AM, Elwell, John wrote:
> Adam,
>
> I reviewed this again and it looks almost ready to go. Just a few comments:
>
> - In Abstract: "This document further proposes that the HTTP work necessary to make
>     such a mechanism work be extensible to support protocols other than
>     SIP for monitoring HTTP resources."
> The only further mention of this seems to be in section 3 "Handling for
>     other URI schemes is out of scope for the current document, although
>     we expect future specifications to define procedures for monitoring
>     via other protocols."
> To justify the wording in Abstract I would expect more than this. I would propose deletion of the words in Abstract.
>    

I've deleted them. I had originally intended to say more on this topic, 
and wanted to make sure that this aspect of the "monitor" link 
association was as externally visible as possible. But I agree that it 
doesn't make much sense, given the current content of the document.

> - In section 1: "Such subscriptions do not carry the content associated with
>     the resource -- the HTTP protocol is still used to transfer the
>     contents of HTTP resources."
> With the addition of the body= parameter, this isn't always true.
>    

I propose changing this to:

       Such subscriptions do not necessarily carry the content
       associated with the resource.  In the cases that the content
       is not conveyed, the HTTP protocol is still used to transfer
       the contents of HTTP resources.


> - In section 4..2: "this parameter
>     indicates to the server that the client wishes to receive a message-
>     body component in the message/http bodies sent in NOTIFY messages."
>
> The terminology used here ("message body component", "bodies") seems to be inconsistent with terminology used in SIP in general and RFC 5621 in particular, i.e., a "message body" (singular) and "body parts". In fact this inconsistency in terminology occurs in other sections, which I haven't pulled out specifically. In the particular case of the sentence above, shouldn't it say something like "wishes to receive message/http body part(s) in NOTIFY messages"?
>    

If your objection is the use of "message bodies" instead of "body 
parts," then I think you're conflating two things. "Body parts" is 
exclusively a MIME multipart term, not a SIP term. In the 
sip-http-subscribe document, we're not talking about multiple MIME body 
parts on a single NOTIFY message (which would be "body parts"). We're 
talking about multiple NOTIFY messages, and the respective single 
message body associated with each of them. It's a one-to-one 
relationship, without the use of MIME multipart mechanisms.

The rest of the prose you quote is slightly awkward because this is a 
rather confusing concept that I'm having a hard time putting into prose. 
We're talking about two different kinds of messages that use the same 
terminology.

There is a SIP message. It contains a message body.
The SIP message body is an HTTP message. The HTTP message also contains 
a message-body.

The parameter is trying to talk about the HTTP body part, not the SIP 
body part.

I've tried to clean this section up; does this sound right to you?

             If present and set to "true" in a SUBSCRIBE request,
             this parameter indicates to the server that the client
             wishes to receive a message-body component in the
             message/http message bodies sent in NOTIFY messages.

             If a server receives a SUBSCRIBE message with a "Event"
             header field "body" parameter set to "true", it MAY
             choose to include a message-body component in the
             message/http message bodies that it sends in NOTIFY
             messages.  Alternatively, it MAY decline to send such
             message-bodies, even when this parameter is present,
             based on local policy.  In particular, it would be quite
             reasonable for servers to have a policy of not including
             HTTP message-bodies larger than a relatively small
             number of bytes.

(I also made a sweep of the use of "body" and "bodies" elsewhere in the 
document to make sure they are consistent).

> - In section 4.7 "In the case that the NOTIFIER has insufficient information to return
>     any useful information about the underlying HTTP resource, it may
>     return a body that is zero bytes long."
> What motivated this? Would termination of the subscription be an alternative possibility?
>    

This would generally be a temporary condition. Imagine that the notifier 
has to perform an asynchronous operation -- such as a back-end 
subscription -- to obtain the information about the HTTP resource.

> Some nits...
>    

Thanks; I've fixed these.

/a