Re: [sip-http-events] HTTP Subscribe: Remaining Open Issue
"Rifaat Shekh-Yusef" <rifatyu@nortel.com> Tue, 01 December 2009 15:40 UTC
Return-Path: <RIFATYU@nortel.com>
X-Original-To: sip-http-events@core3.amsl.com
Delivered-To: sip-http-events@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476573A67E2 for <sip-http-events@core3.amsl.com>; Tue, 1 Dec 2009 07:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKtLXaLMThYW for <sip-http-events@core3.amsl.com>; Tue, 1 Dec 2009 07:40:52 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F22543A67B8 for <sip-http-events@ietf.org>; Tue, 1 Dec 2009 07:40:51 -0800 (PST)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nB1FeA811474; Tue, 1 Dec 2009 15:40:10 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 01 Dec 2009 10:40:05 -0500
Message-ID: <90243C8A881F8D419D855264D9636F3A02922807@zcarhxm2.corp.nortel.com>
In-Reply-To: <4B0B9F77.2060103@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sip-http-events] HTTP Subscribe: Remaining Open Issue
Thread-Index: Acps4+GjuLbHH+YASdeR2nlkQZMzoAFM6Rgw
References: <4B0AC057.5040703@nostrum.com> <4B0B9F77.2060103@ericsson.com>
From: Rifaat Shekh-Yusef <rifatyu@nortel.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>, Adam Roach <adam@nostrum.com>
Cc: SIP HTTP Subscription Package <sip-http-events@ietf.org>
Subject: Re: [sip-http-events] HTTP Subscribe: Remaining Open Issue
X-BeenThere: sip-http-events@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP HTTP Events <sip-http-events.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-http-events>, <mailto:sip-http-events-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-http-events>
List-Post: <mailto:sip-http-events@ietf.org>
List-Help: <mailto:sip-http-events-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-http-events>, <mailto:sip-http-events-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 15:40:53 -0000
Hi Adam, Thanks for pushing this important work forward. I have the following comments: 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. 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? Regards, Rifaat -----Original Message----- From: sip-http-events-bounces@ietf.org [mailto:sip-http-events-bounces@ietf.org] On Behalf Of Salvatore Loreto Sent: Tuesday, November 24, 2009 3:55 AM To: Adam Roach Cc: SIP HTTP Subscription Package Subject: Re: [sip-http-events] HTTP Subscribe: Remaining Open Issue 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 draft-zourzouvillys-bliss-ach-http-api-01 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 https://api.example.com/alice/ach/ 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. /Sal 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: > > http://tools.ietf.org/html/draft-roach-sip-http-subscribe-02 > > /a > ---------------------------------------------------------------------- > -- > > _______________________________________________ > sip-http-events mailing list > sip-http-events@ietf.org > https://www.ietf.org/mailman/listinfo/sip-http-events > _______________________________________________ sip-http-events mailing list sip-http-events@ietf.org https://www.ietf.org/mailman/listinfo/sip-http-events
- [sip-http-events] HTTP Subscribe: Remaining Open … Adam Roach
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Elwell, John
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Theo Zourzouvillys
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Shida Schubert
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Hutton, Andrew
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Salvatore Loreto
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Adam Roach
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Rifaat Shekh-Yusef
- Re: [sip-http-events] HTTP Subscribe: Remaining O… Adam Roach