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

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