Re: I-D ACTION:draft-ietf-ldapbis-syntaxes-10.txt

[Steven Legg <steven.legg@eb2bcom.com>]

Folks,

Here are the technical changes made to the syntaxes draft between version 09
and version 10:

   Added a note that conversions between the BER and LDAP-specific encodings
   of Directory String values "SHOULD be done in a manner consistent with the
   Transcode step of the string preparation algorithms [PREP] for LDAP."

   With regard to the validity of GeneralizedTime values permitted by the ABNF,
   the following note has been added:

      The above ABNF allows character strings which do not represent valid
      dates (in the Gregorian calendar) and/or valid times
      (e.g., February 31, 1994). Such character strings SHOULD be considered
      invalid for this syntax.

   A similar note has been added for UTCTime.

   For telephone numbers, E.123 doesn't seem to allow much leeway for
   international numbers. It basically boils down to whether hyphens and/or
   spaces are used to separate groups of numbers. I've added these examples,
   which more or less cover the possibilities:

      Examples:
         +1 512 315 0280
         +1-512-315-0280
         +61 3 9896 7830

   In the ABNF for the Teletex Terminal Identifier syntax the <ttx-value-char>
   rule has been renamed to <ttx-value-octet>.

   The MUST in the note regarding the AssertionValue in a SubstringFilter
   has been dropped:

      Note that an AssertionValue in a SubstringFilter [PROT] conforms to the
      assertion syntax of the equality matching rule for the attribute type
      rather than the assertion syntax of the substrings matching rule for the
      attribute type.

   The following comment now introduces the matching rules for which string
   preparation is relevant:

      Nominated character strings in assertion and attribute values are
      prepared according to the string preparation algorithms [PREP] for LDAP
      when evaluating the following matching rules:

   The description of the semantics of uniqueMemberMatch have been changed
   to this:

      The rule evaluates to TRUE if and only if the <distinguishedName>
      components of the assertion value and attribute value match according to
      the distinguishedNameMatch rule and either, the <BitString> component is
      absent from both the attribute value and assertion value, or the
      <BitString> component is present in both the attribute value and the
      assertion value and the <BitString> component of the assertion value
      matches the <BitString> component of the attribute value according to
      the bitStringMatch rule.

      Note that this matching rule has been altered from its description in
      X.520 [X.520] in order to make the matching rule commutative. Server
      implementors should consider using the original X.520 semantics (where
      the matching was less exact) for approximate matching of attributes with
      uniqueMemberMatch as the equality matching rule.

The noteworthy editorial changes are these:

   Appendix B has been reworded to read as the changes from RFC 2252.

   References to ABNF rules that are no longer used have been removed.

   The names of the stringprep steps have been revised to the names used
   in the latest stringprep draft.

Regards,
Steven