Re: [sip-http-events] HTTP Subscribe: Remaining Open Issue

Adam Roach <> Tue, 01 December 2009 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 469C93A6809 for <>; Tue, 1 Dec 2009 13:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ptt2+QMdo0F2 for <>; Tue, 1 Dec 2009 13:51:13 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id E0B4F3A6783 for <>; Tue, 1 Dec 2009 13:51:12 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id nB1Lovdl010707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 15:50:58 -0600 (CST) (envelope-from
Message-ID: <>
Date: Tue, 01 Dec 2009 15:50:57 -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: Rifaat Shekh-Yusef <>
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] HTTP Subscribe: Remaining Open Issue
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: Tue, 01 Dec 2009 21:51:14 -0000

On 12/1/09 9:40 AM, Rifaat Shekh-Yusef wrote:
> 1. Section 3.2, Monitoring Multiple HTTP Resources
> I like the ability to monitor multiple resources, but I am not sure
> about the approach.
> I tend to agree with Salvatore's comments below.
> With services that have established a hierarchical and descriptive
> structure of URIs,
> the ability to monitor a group of resources by monitoring the parent
> resource would be the best solution.
> I am not suggesting that this approach should replace the existing RLS
> approach.

This document is designed to be completely agnostic to the underlying 
application that is making use of HTTP. I think it would be reasonable 
for someone to define -- in another document -- the means by which one 
would apply it to specific applications (such as ones where there is an 
implicit relationship between URLs based on some external rules, like 
those described in draft-zourzouvillys-bliss-ach-http-api).

But I would not support adding this kind of application-specific 
functionality to the base SIP HTTP subscribe draft.

>   2. Section 5, Example Message Flow
> In step 9: is the body of the NOTIFY message, which has the HTTP 200 OK,
> really needed in this case?

Yes, it is. Unless you communicate some content identifier (such as etag 
or content-md5), there are race conditions in which clients can think 
they have the most recent version of a document when, in fact, they don't.