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.