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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Please review the changes made in this revision to ensure
they adequately and appropriately address issues raised
during (and subsequent to) the previous WG Last Call.
It is my intent to forward this revision to the IESG for
consideration within a week or so.

-- Kurt, LDAPBIS co-chair

At 09:30 PM 2/28/2005, Steven Legg wrote:

>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