Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 28 October 2009 15:15 UTC

Return-Path: <HKaplan@acmepacket.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 EDDE23A67FD for <dispatch@core3.amsl.com>; Wed, 28 Oct 2009 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level:
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599]
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 aOuDAtBSeVAL for <dispatch@core3.amsl.com>; Wed, 28 Oct 2009 08:15:00 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EB7003A672E for <dispatch@ietf.org>; Wed, 28 Oct 2009 08:14:59 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Oct 2009 11:15:14 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Oct 2009 11:15:14 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "Kevin P. Fleming" <kpfleming@digium.com>
Date: Wed, 28 Oct 2009 11:15:13 -0400
Thread-Topic: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method
Thread-Index: AcpX13cE0TJJ6oSyR9SgGT/mAoz72gABNH5w
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31A0A9D344C@mail>
References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com> <1256589116.3748.73.camel@khone.us.nortel.com> <4AE84F28.3040008@digium.com>
In-Reply-To: <4AE84F28.3040008@digium.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] draft-kaplan-dispatch-domain-registration should use a different method
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: Wed, 28 Oct 2009 15:15:01 -0000

Hi Kevin, 
The intent of the draft, and part of the rationale for using REGISTER in fact, is that it's processing is NOT different.  It's not different on Proxies, and it's not different on UAC's other than adding that tag string.  It's not even actually that different on UAS's - it's real "difference" to the UAS/Registrar is the logical Database it updates, and the key it uses to lookup in that database.

The "routing" portion of the draft, which uses the database and uses loose-routing to reach the IP-PBX, is different than how 3261 routes to the AoR database populated by REGISTER.  But that's not tied to the REGISTER request method name, obviously.

It's true that affecting a different database is a change for REGISTER.  But if using a option-tag or header to indicate that is "more complex and harder to maintain" than using a new method name, then we're in real trouble.  Because PUBLISH and SUBSCRIBE effectively do that with every different event package, without changing the method name, afaict. 

-hadriel

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Kevin P. Fleming
> Sent: Wednesday, October 28, 2009 10:03 AM
> Cc: DISPATCH
> 
> I agree with Dale's points here rather strongly; when writing the UAS
> code to handle requests, it is much more logical and straightforward to
> inspect option tags and header fields when the purpose of doing so is
> sanity checking and for subtly adjusting the behavior of the request.
> When the option tags and/or header field values are used to cause a
> different operation to be performed, the code gets much more complex and
> harder to maintain.
>
> On the UAC side, I can't see how the need to take the existing
> (pre-standard) code and modify it to use a new method name is going to
> be any more burden than modifying that same code to conform to the
> standard... since there are very few (if any) existing implementations
> that already conform to the proposed standard. The UAC side of this
> proposal is very easy to implement in either case.
> 
> I haven't seen any comments in this thread about how the re-use of
> REGISTER for a different purpose would affect proxies in the route path;
> if a proxy has to inspect option tags and header values to decide how to
> route a request, that increases complexity as well, which is avoided if
> the request uses a different method.
> 
> --
> Kevin P. Fleming