Reply to A simpler idea for the missing O mapping?

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

> An alternative solution would be to modify the rules regarding traversal of the DIT.
> Consider:
>     The entry we are looking for will never be the first READ, because we have already chopped
>     off an OU; this is why we are searching for the empty-O entry.
>
>     We always know that we are looking for a missing O (or other attribute), because the O/R
>     name to DIT defines a rigid hierarchy.
>
>     We always know that we are looking at exactly this level, because the chopping algorithm for
>     DIT traversal has just chopped off a component and discovered that the component "above" is
>     missing.
>
> This leads me to a question:
> Could we insert a statement saying that when the chopping reaches a missing component, the DIT
> traversal will perform a READ on an entry with the current Distinguished Name, plus a single,
> distinguished-value attribute (maybe the infamous Single Space strikes again?????)

I'm not sure that I understand your proposal.

Remember that if the first READ returns a NAME ERROR, the DSA will return
the prefix of the distinguished name which matches an entry in the DIT.
In other words, the MTA or gateway does not necessarily back up through the
O/R address one element at a time.  If the first READ returns NAME ERROR,
the effect may be to chop off several of the O/R address elements at once.

Suppose that an ADMD has both O's and OU's registered directly under its ADMD
name internally.  For example, suppose that it provides service for the
following:

     C=WS; A=XYZ; O=Red
     C=WS; A=XYZ; OU=Blue

Suppose that this ADMD has different mappings for O's than OU's.  For example,
suppose that it defined the following mapping rules:

     C=WS; A=XYZ; P=;      -->  pless.xyz.ws
     C=WS; A=XYZ; P=; O=;  -->  oless.xyz.ws

This is intended to produce the following mappings:

     C=WS; A=XYZ; O=Red     -->  red.pless.xyz.ws
     C=WS; A=XYZ; OU=Blue   -->  blue.oless.xyz.ws

If only C=WS and A=XYZ are registered in the directory, then a READ for
either "C=WS; A=XYZ; O=Red" or "C=WS; A=XYZ; OU=Blue" will produce NAME ERROR
and will yield the same matching prefix, "C=WS; A=XYZ", in both cases.  Does 
your proposal handle these cases?

I am beginning to wonder if we should consider more seriously a simpler
proposal where we require that place holder attributes be inserted into
O/R addresses when mapping them onto distinguished names.  The infamous single
space might be very useful here.  Specifically, would it really be such a
bad idea to insist that missing elements be mapped onto single space RDN's
in the DIT?  For example:

     C=WS; A=XYZ; O=Red

          would map onto the DN

     C=WS@aDMDName=XYZ@pRMDName= @mHSO=Red

and

     C=WS; A=XYZ; OU=Blue

          would map onto the DN

     
     C=WS@aDMDName=XYZ@pRMDName= @mHSO= @mHSOU=Blue

This would require that a PRMD entry and an O entry with RDN value " " be
registered in the DIT.  It looks a bit ugly, but it provides a simple solution
to the problem.

Does anyone know if the X.400 standards and/or various international profiles
allow or prohibit single space as a PRMD or O name?  If this is prohibited,
then we can safely use single space as a place holder.  If single space is
not prohibited, then there is a risk that someone might actually create a
PRMD or O whose actual name is " ".  Is this really an issue worth worrying
about?