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

Adam Roach <> Mon, 30 November 2009 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B2373A67F1 for <>; Mon, 30 Nov 2009 11:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x7QzeATk7YZv for <>; Mon, 30 Nov 2009 11:12:36 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 25F3D28C10C for <>; Mon, 30 Nov 2009 11:12:35 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id nAUJCMVk042544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 13:12:22 -0600 (CST) (envelope-from
Message-ID: <>
Date: Mon, 30 Nov 2009 13:12:22 -0600
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20091121 Thunderbird/3.0
MIME-Version: 1.0
To: "Elwell, John" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: SIP HTTP Subscription Package <>
Subject: Re: [sip-http-events] Fwd: New Version Notification for draft-roach-sip-http-subscribe-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP HTTP Events <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Nov 2009 19:12:38 -0000

I've produced a new version of the document incorporating these changes. 
See the diff here:


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