More on implications of 22.2

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

Consider what will be necessary at a typical site if the site wants its users
to be reachable by underspecified O/R addresses, and 22.2 is mandatory.
Assume that all users' mailboxes are actually located under at least one level
of OU.  For example, a typical user's full mailbox address looks like:

    S=Surname; G=Givenname; OU=An-ou; O=An-o; P=A-prmd; A=An-admd; C=ZZ

Suppose that this site also wants its users to be reachable by underspecified
forms such as:

    S=Surname
    S=Surname; I=G

If the site has, for example, 3000 users, then 9000 entries will be required
at the OU level (3000 real user entries, and 6000 alias entries).

When underspecified addressing is supported, usually it is also acceptable
to omit OU's, and O's too.  Many sites prefer to externalize addresses which
do not expose OU's and O's.  This works perfectly well as long as all
exposed names are unique relative to the PRMD.

So, if a site would like to implement full support of underspecified addresses,
then, by 22.2, it will be necessary to create aliases at every level of the
X.400 O/R address tree where underspecification is desired.  In the example
above, this would require defining 9000 alias entries under the O level and
9000 alias entries under the PRMD level.  Thus, in order to support
underspecified addresses fully, it will be necessary to create and maintain
3000 mailbox entries and 24,000 aliases.

These numbers would increase by an additional 27,000 if there were four levels
of OU's at the site.

The number of entries you will need can be calculated by the following formula:

     users * npu * levels

where:

    users - the number of users you have

      npu - the number of alternate names you will allow per user, including
            the real mailbox name

   levels - the number of levels of X.400 hierarchy for which
            underspecification will be supported

Of course, you'll also need some good administrative tools to add, modify, and
delete all related entries when a user's address changes, when new users
are registered, and when users depart.  These tools will need to be quite
clever, as it may not be easy to find all of the aliases that reference an
entry which has been changed or deleted.

P.S. - Our implementation, which uses controlled directory search, fully
       supports underspecified addressing without having to add or maintain
       a single alias entry.

       Although I obviously believe that our approach is better, I'm not
       necessarily advocating that it be standardized by MHS-DS.  I am simply
       pointing it out as an alternative to 22.2.  It is an approach that
       is implemented and is being used quite successfully at a large number
       and wide variety of sites.  Has the approach specified in 22.2 actually
       been implemented anywhere?  Does anyone have practical experience with
       this approach?  Given that there are reasonable and practical
       alternatives available, and also given that there are very significant
       administrative implications in 22.2, let's not mandate 22.2.