Reply to editorial comments to routing document

["Kevin E. Jordan" <[e-mail]>]

> 22.2 - underspecified O/R addresses.   I have mandated an approach to
> be followed, IN THE CONTEXT OF X.400, whereas you suggest that it
> should be optional.   I have tightened the text in this area, and
> invite you to review it.   I do not believe that this sort of thing
> should be left to implementor choice.

Oops!  Before now, I assumed that this section proposed an optional solution
to handling underspecified addresses.  I strongly object to making this
approach mandatory.  Doing so forces every administrator to create many
aliases which will clutter the directory unnecessarily.  This creates a
very significant administrative problem.

Our implementation uses the directory search operation to solve this problem
in a clean way.  We provide optional "searchBase" and "searchStyle" attributes
in each node of the routing tree.  These attributes tell the MTA where to
search for user entries associated with that point in the X.400 hierarchy,
and they also tell the MTA what kind of search operation to execute.   This
eliminates any possible need to proliferate aliases.

I do not object to offering 22.2 as suggested and optional solution, but I
object very much to making it mandatory.  Our implementation should handle it
properly should some administrator choose to define his/her directory using it.
However, 22.2 proposes a solution which is administration and data intensive.
Our approach, using controlled search, is much easier to administer, avoids
proliferation of alias entries, and has not created a performance problem
in practice.

Note also that alias entries not only create an administrative problem, but
they can easily create performance problems too.  Resolution of aliases often
requires many X.500 DAP/DSP operations and can involve several DSA's.  This
is especially true when an alias entry is held by one DSA and the entry it
references is held by a different DSA.  In many such situations, a controlled
search may actually require less X.500 overhead than an alias resolution.

In deploying X.500 directories at many customer and internal sites, we have
learned many practical lessons about maximizing success and performance, and
one of these is:

         Avoid aliases!