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

"Hutton, Andrew" <> Tue, 24 November 2009 08:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB7B53A68F1 for <>; Tue, 24 Nov 2009 00:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w+QkyQmxQB4M for <>; Tue, 24 Nov 2009 00:41:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5F60B3A685E for <>; Tue, 24 Nov 2009 00:41:17 -0800 (PST)
Received: from senmx11-mx ([] []) by with ESMTP id BT-MMP-104485; Tue, 24 Nov 2009 09:41:12 +0100
Received: from (unknown []) by senmx11-mx (Server) with ESMTP id BCC691EB81F0; Tue, 24 Nov 2009 09:41:12 +0100 (CET)
Received: from ([]) by ([]) with mapi; Tue, 24 Nov 2009 09:41:12 +0100
From: "Hutton, Andrew" <>
To: Adam Roach <>, SIP HTTP Subscription Package <>
Date: Tue, 24 Nov 2009 09:41:13 +0100
Thread-Topic: [sip-http-events] HTTP Subscribe: Remaining Open Issue
Thread-Index: AcpsXucb98A5Smx/TJml0TOYj4zkLgAgFciA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_101C6067BEC68246B0C3F6843BCCC1E30672CA70F3MCHP058Agloba_"
MIME-Version: 1.0
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:41:19 -0000

Hi Adam,

I like that the filter mechanism will be useful for this event package and I agree with your proposal that it should be a request which the server can decline.

My personal preference would be to include this simple filter in the draft I don't think it should cause too much complexity.


From: [] On Behalf Of Adam Roach
Sent: 23 November 2009 17:03
To: SIP HTTP Subscription Package
Subject: [sip-http-events] HTTP Subscribe: Remaining Open Issue

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: