Reply to Ommitted components in the 1327 mapping

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

> I must agree with Michael in that I don't like an approach where
> the strategy for handling a missing component in an RDN-O/R name
> is radically different from the strategy for representing the
> same missing component in an O/R name.

The difference is not radical; it's just different.  The difference is
due to the fact that we are using the O/R address syntax for the
mhsAssociatedDomain and nonAuthoritativeAssociatedDomain attributes, and
this syntax constrains us to use SPACE as a placeholder.  We have much more
flexibility in choosing a good placeholder strategy for the distinguished
name representations of O/R addresses.  Steve's proposal takes advantage
of this flexibility in a very nice way.

Using SPACE as a placeholder in DN's has some appeal because it seems to
provide consistency with the placeholder strategy we must use in attributes
of O/R address syntax.  However, this results in a solution which is based
upon the least common denominator rather than the best technical design.
We shouldn't let the constraints imposed by the O/R address syntax affect
the O/R to DN mapping adversely or unnecessarily.

> My favourite would still be 2) with "SPACE" (my favourite
> interpretation of the battles over SPACE in ISO was that it is
> only a placeholder because they couldn't agree to declare it
> OPTIONAL, so that there is precedent for this usage).
> Or $$$MISSING$$$.
> 
> It's not a show-stopper, but I think it actually makes the spec
> more complex to read and to implement if we add another OID-valued
> special case to the naming tree.

I disagree with your conclusion that it will make the spec more complex to
read and implement.  The problem with using placeholder values such as SPACE
and $$$MISSING$$$ is that their usage is a gamble.  We would be gambling that
these values will always be outlawed by the standards and/or that no one will
ever think to use them for any purpose other than the one we've specified.
Steve's proposal avoids these problems entirely in the case of O/R to DN
mapping.

As for implementation, empty components must be detected by the software
when it maps O/R addresses onto distinguished names in either case, and some
type of placeholder RDN must be inserted.  It is not more difficult to insert
an RDN whose value is an OID than to insert an RDN whose value is a string.
So, Steve's proposal is definitely not more difficult to implement.