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

[Adam Roach <[e-mail]>]

Thanks. These will be fixed in the -05.

/a

On 12/1/09 3:29 AM, Shida Schubert wrote:
> Adam,
>
>   Just reviewed the 04 version of the draft.
>
>   Beside the few nits indicated below, the draft looked solid. Thanks for working on this.
>
>   Section 3.1/Last sentence of last paragraph :  "section Section 4"
>   Section 4.5.1/Last Paragraph :  "contain a the same"
>
>   Regards
>    Shida
>
> On Dec 1, 2009, at 4:12 AM, Adam Roach wrote:
>
>    
>> I've produced a new version of the document incorporating these changes. See the diff here:
>>
>> http://tools.ietf.org/rfcdiff?url2=draft-roach-sip-http-subscribe-04.txt
>>
>> /a
>>
>> On 11/30/09 11:17 AM, Adam Roach wrote:
>>      
>>> 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
>>> _______________________________________________
>>> sip-http-events mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sip-http-events
>>>        
>> _______________________________________________
>> sip-http-events mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sip-http-events
>>      
>