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

Salvatore Loreto <> Tue, 24 November 2009 08:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09D153A6892 for <>; Tue, 24 Nov 2009 00:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mqB20Dt8bnJE for <>; Tue, 24 Nov 2009 00:55:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9D0E73A62C1 for <>; Tue, 24 Nov 2009 00:55:26 -0800 (PST)
X-AuditID: c1b4fb3e-b7b90ae000005e1e-9d-4b0b9f78f648
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BA.B4.24094.97F9B0B4; Tue, 24 Nov 2009 09:55:21 +0100 (CET)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:55:20 +0100
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 09:55:20 +0100
Received: from ( []) by (Postfix) with ESMTP id 6043725C8; Tue, 24 Nov 2009 10:55:20 +0200 (EET)
Received: from (localhost []) by (Postfix) with ESMTP id 24EAF21A21; Tue, 24 Nov 2009 10:55:20 +0200 (EET)
Received: from localhost.localdomain (localhost []) by (Postfix) with ESMTP id C7E8121923; Tue, 24 Nov 2009 10:55:19 +0200 (EET)
Message-ID: <>
Date: Tue, 24 Nov 2009 10:55:19 +0200
From: Salvatore Loreto <>
User-Agent: Thunderbird (X11/20090825)
MIME-Version: 1.0
To: Adam Roach <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 24 Nov 2009 08:55:20.0617 (UTC) FILETIME=[DA1CB190:01CA6CE3]
X-Brightmail-Tracker: AAAAAA==
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, 24 Nov 2009 08:55:28 -0000

Hi Adam,

thanks for the effort in continuing this work

as one of my doubts and previously comment to use SIP to monitor HTTP 
resource was the extra HTTP round-trip to fetch the new resource state,
I am in support and I do think we should define some sort of basic 
filter parameter so that event changes state can include the new 
resource state.

I have also taken the occasion to re-read all the draft and I have an 
additional comment:

I like the possibility to Monitoring Multiple HTTP Resources,
however it is not clear to me if it is possible or not to Subscribe to a 
monitor-group URI without including the URI list.

for example, consider the case in which a client wishes to monitor the 
resources associated to Alice in draft 

does the client have to perform a GET or HEAD operation  for  each  
resource in order to  discover the 
monitor-link of each of them and only after it has discovered all the 
monitor-links Subscribe to the monitor-group including the URI list;

or it would be enough perform a GET or HEAD operation for
and subscribe to the monitor-group URI returned by the operation without 
including any URI list.

The latter would a sort of implicit registration to all the resources 
included in the monitor-group, where the
inclusion of an URI list would be a sort of filter for the subset of 
resources included in the monitor-group  the client is interested in.


Adam Roach wrote:
> There has been increasing interest in having a finalized version of 
> draft-roach-sip-http-subscribe ready for publication. I have a couple 
> of open items myself (mostly, generation of example messages), but 
> there is one open item called out in the draft at the moment. I expect 
> to take care of these in the near future, and request publication as 
> soon as feasible.
> Currently, the package mentions that notifications of HTTP resource 
> state changes don't include the actual resource state -- although it 
> leaves open the possibility that someone may define an extension to do 
> so in the future; the relevant text is:
>    When used in the HTTP monitor event package, the message/http MUST
>    NOT contain a message-body component, unless the corresponding
>    subscription has explicitly indicated the desire to receive such
>    bodies in the form of a filter.  Filters for this event package are
>    out of scope for this specification.
> In section 3.2, we ask whether this document should define a simple 
> filter parameter (e.g., "body=true") that would request that event 
> state changes include the new resource state. I *suspect* this would 
> be a very straightforward thing to define, and it may be quite useful 
> for certain usages (e.g., some of the proposed BLISS applications have 
> very, very small documents -- on the order of 4 to 40 characters or 
> so), as it would save the HTTP round-trip. On the other hand, the 
> prospect of pushing large HTTP documents through the SIP network may 
> prove problematic. (If we define this mechanism, I would definitely 
> propose that including this in a SUBSCRIBE is simply a request, and 
> give the server the option of declining to honor it).
> If you have an opinion one way or another about this topic, please 
> post is to the list.
> The current version of the document is here:
> /a
> ------------------------------------------------------------------------
> _______________________________________________
> sip-http-events mailing list