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

["Kevin P. Fleming" <[e-mail]>]

Dale Worley wrote:

(/me hesitantly jumps into the fray)

> 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.

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
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [e-mail]
Check us out at www.digium.com & www.asterisk.org