[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