Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
"Scott Lawrence" <scott.lawrence@nortel.com> Thu, 28 May 2009 13:52 UTC
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941B53A6ED1 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.21
X-Spam-Level:
X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 TXmAIbag22Rb for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:52:30 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6FD273A6DF8 for <dispatch@ietf.org>; Thu, 28 May 2009 06:52:30 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4SDqpf00243; Thu, 28 May 2009 13:52:51 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 09:53:58 -0400
From: Scott Lawrence <scott.lawrence@nortel.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com> <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
Content-Type: text/plain
Organization: Nortel Networks
Date: Thu, 28 May 2009 09:53:55 -0400
Message-Id: <1243518835.3422.10.camel@scott>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 May 2009 13:53:59.0176 (UTC) FILETIME=[C00CD080:01C9DF9B]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 13:52:31 -0000
On Thu, 2009-05-28 at 08:53 +0200, Christer Holmberg wrote: > > So, the idea is to use the existing SIP SUB/NOT mechanism. The only > "new" thing is to provide the conditions as part of the subscription. What's new about that? The target of a SUBSCRIBE is a URI, which can include parameters. Putting a body on a SUBSCRIBE request that further extends those parameters is already allowed (eg RFC 5367), and a server is free to use any part of a SUBSCRIBE request to determine whether or not to create a subscription and what data to send in the resulting NOTIFY messages. Neither defining an event package for a particular application (which is what this appears to be), nor defining how to communicate parameters in the requests used by that application require any change to the protocol. While I'm sure this is interesting work, I don't see any reason why it should consume IETF working group time - you'd spend almost all the time educating other participants about the application requirements. I'd say go ahead and develop what you need, and if you think it would be useful to publish the results as an Informational document there's no reason not to do so as an individual submission. Of course, if you find some prohibition or constraint in the existing specifications that you think needs modifying, then that would be worth IETF review.
- [dispatch] Draft: CBUS (Condition-based URI Subsc… Christer Holmberg
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Joel M. Halpern
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Cullen Jennings
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Scott Lawrence
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Dale Worley
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Dale Worley
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Dean Willis
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Christer Holmberg
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Christer Holmberg
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Scott Lawrence
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Dean Willis
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Christer Holmberg
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Christer Holmberg
- Re: [dispatch] Draft: CBUS (Condition-based URI S… Dale Worley