[dispatch] draft-kaplan-dispatch-domain-registration should use a different method
"Dale Worley" <dworley@nortel.com> Mon, 26 October 2009 20:31 UTC
Return-Path: <dworley@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 678973A6AD9 for <dispatch@core3.amsl.com>; Mon, 26 Oct 2009 13:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 V4S2HC++qIzv for <dispatch@core3.amsl.com>; Mon, 26 Oct 2009 13:31:50 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 252393A67E1 for <dispatch@ietf.org>; Mon, 26 Oct 2009 13:31:50 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9QKVxD24678 for <dispatch@ietf.org>; Mon, 26 Oct 2009 20:31:59 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:31:57 -0400
From: Dale Worley <dworley@nortel.com>
To: DISPATCH <dispatch@ietf.org>
In-Reply-To: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com>
References: <22A4515E-F613-49F3-8079-1142FB390113@cisco.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Mon, 26 Oct 2009 16:31:56 -0400
Message-Id: <1256589116.3748.73.camel@khone.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2009 20:31:57.0027 (UTC) FILETIME=[5CBBFB30:01CA567B]
Subject: [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: Mon, 26 Oct 2009 20:31:51 -0000
I think the proposal can be improved and controversy avoided by making three rather small changes: 1. Restrict (at least in principle) the domain name involved to be one that is properly owned or controlled by the SSP or PBX. 2. Replace the REGISTER method with a new method name. 3. Clarify that the RFC defines a mechanism for maintaining a "route to this domain" database, which may be used in various ways which are not specified by the RFC. (In particular, the SSP might use it to apply Route headers to requests, or it might use it to populate a DNS server, and then use RFC 3263 to route requests.) This loses no functionality and ensures that the database-updating remains uncoupled from the users of the database. Justifications for items 1 and 2: 1. Allowing arbitrary domain names leads to the alt-root controversy, etc. In addition, if the domain name is used only between the SSP and the PBX, and within the PBX's services, it is essentially arbitrary, in which case it might as well be a properly owned domain name. If the domain name is visible outside this region, it will have to be properly owned if we expect external elements to utilize it in accessing the PBX. In neither case is a private name space particularly useful. Of course, in practice, people will do whatever they want, but we avoid committing to support private name spaces in the future. 2. This change has more complex consequences, but I think the balance of facts is in its favor: a. It reduces the compatibility problems relative to the ad-hoc mechanisms currently deployed, since the new method makes it clear that the new, standardized mechanism is to be used. Conversely, elements wishing to remain compatible with a current ad-hoc use of REGISTER for this purpose can continue to do so. b. It avoids having to define an option-tag, as the *effect* of using a new method is the same as using an old method with a new option-tag: UASs that are unaware of the new mechanism will reject the request. (Thus demonstrating that the opinion that a new method is more radical than a new option-tag has no substance.) c. Specific mechanisms that are now defined for use with REGISTER can be recycled for use with the new method by simply referencing them in the RFC. And mechanisms that are now defined for use with REGISTER that are of no value with domain-registration (e.g., GRUU) are explicitly omitted. d. Using a new method avoids the dangerously ill-structured process of using one method for requesting multiple activities that are almost-but-not-quite the same. Let us compare the situation with that of REFER. At last count, there were five distinct uses of the REFER method. Each is distinguished by specific combinations of header fields and features of the context within which the REFER is received. This leads to several undesirable consequences: - The code at the UAS is no simpler, as there need to be five different code paths, one for each version of REFER. Currently, the dispatching is done by examining the context of the REFER, whereas if there were five methods, dispatching could be done by method name. - Because the rules for distinguishing the five cases are not explicit, implementers may easily make mistakes coding the dispatching. - Because the function of a REFER is determined by context, a REFER that is accidentally sent in a different context than which was intended may not be detected as an error and may cause inadvertent actions. - If there were separate method names, then each of the five code paths could continue to examine the context of the request, but as a validity check rather than as a dispatching decision. - Different uses of REFER have subtly different constraints on valid values for the various header fields. In the case of domain-registration REGISTERs, we are already discussing what the To-URI should be, which shows that the domain-registration REGISTER isn't really the same beast as the AOR REGISTER. And some extensions of REFER (e.g., GRUU) aren't to be used with domain-registration. We can expect further subtle differences to be discovered. e. The new method is freed from having to resemble REGISTER in aspects that are unnatural for the function of the new method. f. The claim that the new method is exactly like the old REGISTER except for the database that is populated is true in a psychological sense, but not in a coding sense -- Various details are different (the To/From headers do not have exactly the same format or interpretation, multiple Contacts are forbidden, and it's unlikely that the query formats are supported). And I doubt that there will be *any* implementation that will process the two functions with the *same* code, only with a differing parameter-value indicating the database to be updated. g. Using a new method puts the new mechanism beyond a large set of "ideological" arguments. (But most of the ideological arguments are abstract versions of the above practical considerations.) (This new method may actually *be* the RUPDATE proposed by Dean, but I haven't read into that, so I don't know.) Dale
- [dispatch] Domain Registration Draft draft-kaplan… Cullen Jennings
- Re: [dispatch] Domain Registration Draft draft-ka… Richard Shockey
- Re: [dispatch] Domain Registration Draftdraft-kap… Spencer Dawkins
- Re: [dispatch] Domain Registration Draft draft-ka… Elwell, John
- Re: [dispatch] Domain Registration Draftdraft-kap… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain RegistrationDraft draft-kap… Bharrat, Shaun
- Re: [dispatch] Domain Registration Draft draft-ka… Scott Lawrence
- Re: [dispatch] Domain Registration Draft draft-ka… Elwell, John
- Re: [dispatch] Domain Registration Draft draft-ka… Ben Campbell
- Re: [dispatch] DomainRegistration Draftdraft-kapl… Middleton, David (NSN - US/Boca Raton)
- Re: [dispatch] Domain Registration Draft draft-ka… Jamie Palmer
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- [dispatch] Fwd: Domain Registration Draft draft-k… James Palmer
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Richard Shockey
- Re: [dispatch] Domain Registration Draft draft-ka… Ben Campbell
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Middleton, David (NSN - US/Boca Raton)
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Middleton, David (NSN - US/Boca Raton)
- Re: [dispatch] Domain Registration Draft draft-ka… Francois Audet
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Paul Kyzivat
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain Registration Draft draft-ka… Bernard Aboba
- Re: [dispatch] Domain Registration Draft draft-ka… François AUDET
- Re: [dispatch] Domain Registration Draft draft-ka… Elwell, John
- Re: [dispatch] Domain Registration Draft draft-ka… Dale Worley
- Re: [dispatch] Domain RegistrationDraft draft-kap… Spencer Dawkins
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- Re: [dispatch] Domain Registration Draft draft-ka… Hadriel Kaplan
- Re: [dispatch] DomainRegistration Draft draft-kap… Brian Lindsay
- Re: [dispatch] Domain Registration Draft draft-ka… Dean Willis
- [dispatch] Using only a Require option-tag in Dom… Hadriel Kaplan
- [dispatch] draft-kaplan-dispatch-domain-registrat… Dale Worley
- Re: [dispatch] Domain RegistrationDraft draft-kap… Dale Worley
- Re: [dispatch] Domain RegistrationDraft draft-kap… Dean Willis
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Hadriel Kaplan
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Kevin P. Fleming
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Elwell, John
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Hadriel Kaplan
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Kevin P. Fleming
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Richard Shockey
- Re: [dispatch] draft-kaplan-dispatch-domain-regis… Hadriel Kaplan