Proposed changes

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

David Chadwick, editor of X.518 (iso 9594 part 4), has offered to submit
a defect report regarding the issue of values consisting only of spaces.
Thanks, in advance, David.

X.520 currently contains the following text:

==========================================================================

   7.1 String matching rules

   In the matching rules specified in 7.1.1 through 7.1.11, the following
   spaces are regarded as not significant:

     *  leading spaces (i.e., those preceding the first printing character);

     *  trailing spaces (i.e., those following the last printing character);

     *  multiple consecutive internal spaces (these are taken as equivalent
        to a single space character).

   In the matching rules to which these apply, the strings to be matched shall
   be matched as if the insignificant spaces were not present in either string.

==========================================================================

I propose that a defect report be written such that the text in section 7.1
is modified as follows:

==========================================================================

   7.1 String matching rules

   In the matching rules specified in 7.1.1 through 7.1.11, the following
   spaces are regarded as not significant:

     *  leading spaces (i.e., those preceding the first character which is
        not a space);

     *  trailing spaces (i.e., those following the last character which is
        not a space);

     *  multiple consecutive internal spaces (these are taken as equivalent
        to a single space character).

   Strings consisting entirely of spaces are allowed.  A string consisting
   entirely of spaces is equivalent to a string containing exactly one space,
   with that space being significant.

   In the matching rules to which these apply, the strings to be matched shall
   be matched as if the insignificant spaces were not present in either string.

==========================================================================

The proposed text eliminates the poorly defined term "printing character", it
clearly indicates that strings comprised entirely of spaces are supported,
and it defines how to handle them.


Despite that this clarification to the standard will clearly allow for objects
with RDN aDMDName=<BLANK>, this name will probably continue to cause us
problems, as Harald has pointed out.  Harald proposed that PRMD names/addresses
associated with ADMD=<BLANK> be placed directly under their respective
country's root.  This neatly avoids all current and potential problems with
the blank name, and it continues to support the reversible mapping of O/R
addresses to X.500 DN's (i.e. if PRMD is immediately subordinate to country,
insert ADMD=<BLANK> when mapping from DN to O/R address).  It does not
complicate implementation of directory capable X.400 MTA's enough to matter.

I support Harald's proposal.  No one on this list has opposed the proposal.
Does this imply a consensus?