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

["Elwell, John" <[e-mail]>]

Adam,

Thanks. I checked the diff and it seems you have addressed all my concerns.

John 

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]] 
> Sent: 30 November 2009 17:17
> To: Elwell, John
> Cc: SIP HTTP Subscription Package
> Subject: Re: [sip-http-events] Fwd: New Version Notification 
> for draft-roach-sip-http-subscribe-03
> 
> 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
>