Reply to Reply to A simpler idea for the missing O mapping?

[[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 have thought about such an algorithm too, but I see too many problems with
the different cases which must be observed. In addition more operations must
be done every time routing or mapping is done for an organization without PRMD
or ORG than for an organization with these elements. I do not like this.

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

With this solution (I called it the RFC 1327 approach) there will be no
difference in looking up an organization with or whithout PRMD or ORG. In
addition it will be much faster than Haralds suggestion. However, this would
mean that all currently created routing trees where an empty component exists
must be changed (for example my big routing trees for my five PRMDs with
missing ORG :-( )

The advantage of this proposal is, it is well known from RFC 1327, easy to
remember and programm and this fix could be done very fast, which I think is
the most important thing at the moment.

And it would not prevent to include the solution from Kevin with the mapping
filter at a later stage.

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

What about using the value $empty? This cannot be used as a PRMD or ORG, but
as a RDN and it denotes clearly, what is meant.

Regards,

Michael