syntaxes-09 notes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

> 3.3.11.  Facsimile Telephone Number

>    The <telephone-number> is a string of printable characters that
>    complies with the internationally agreed format for representing
>    international telephone numbers [E.123].

It would be nice if a description (maybe ABNF) of this syntax is added,
similar to the ABNF of GeneralizedTime.  (Or maybe put it under
telephoneNumber and refer to that.)

> 3.3.13.  Generalized Time
>
>    A value of the Generalized Time syntax is a character string
>    representing a date and time.  The LDAP-specific encoding of a value
>    of this syntax is a restriction of the format defined in [ISO8601],
>    and is described by the following ABNF:

I don't remember if anyone answered this: Is a date like 31.february an
error according to ISO8601?  If so, is it an error for a GeneraliedTime?
If so, the grammar does not fully describe the syntax, but only says how
to parse a correct value.  A similar question for leap seconds that
occur at a time when leap seconds may not occur, or even leap seconds at
a time when they could have occurred but didn't: MUST/MAY the server
return failure for these?  Also, how about pre-Gregorian years (whatever
that means, since the gregorian calendar was introduced at different
times) - MAY/MUST the server reject invalid dates in the Julian calendar?

>       GeneralizedTime = century year month day hour
>                            [ minute [ second ] ] [ fraction ]
>                            g-time-zone

I suggest to make this the first definition on the list of ABNF
definitions, in stead of putting it in the middle.

> 3.3.32.  Teletex Terminal Identifier

>       ttx-value-char = %x00-23

This does not seem to be a character - at least I don't know which
character set it would be from - so I suggest to call it ttx-value-octet
(or -byte).  I haven't yet checked the X.520 definition, though.

> 4.  Matching Rules

>    When modifying entries, matching rules are used to identify values to
>    be deleted and to prevent an attribute from containing two equal
>    values.

s/equal/equivalent/.  Same change in 4.2.15 (distinguishedNameMatch).

> 4.1.  General Considerations

>    The
>    conditions under which an AttributeValueAssertion or
>    MatchingRuleAssertion evaluates to Undefined are specified elsewhere
>    [PROT].

That may be true for filters, but I can't tell if it is true for other
cases, like looking up an entry via an LDAPDN which contains an AVA
where the value does not have the correct syntax.  And maybe stringprep
could turn such an invalid value into a valid one...  I need to check
that.

>    Note that the AssertionValue in a SubstringFilter
>    [PROT] MUST conform to the assertion syntax of the equality matching
>    rule

s/AssertionValue/AssertionValues/.
s/MUST conform/conform//?

Prepend "Conceptually," as in [protocol]:

>    The entire
>    SubstringFilter is converted into an assertion value of the
>    substrings matching rule prior to applying the rule.

> 4.2.  Matching Rule Definitions
>
>    When evaluating the numericStringMatch, numericStringSubstringsMatch,
>    caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch,
>    caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch,
>    caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
>    caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
>    directoryStringFirstComponentMatch, telephoneNumberMatch and
>    telephoneNumberSubstringsMatch matching rules the assertion value and
>    attribute value are prepared according to the string preparation
>    algorithms [PREP] for LDAP before being compared.

Also wordMatch (which employs caseIgnoreMatch).

That list is getting unwieldy.  I would reorder and tabulate a bit:

   When evaluating the matching rules:
    caseExactMatch,  caseExactOrderingMatch,  caseExactSubstringsMatch,
    caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
    caseExactIA5Match,
    caseIgnoreIA5Match,   caseIgnoreIA5SubstringsMatch,
    caseIgnoreListMatch,  caseIgnoreListSubstringsMatch,
    numericStringMatch,   numericStringSubstringsMatch,
    telephoneNumberMatch, telephoneNumberSubstringsMatch,
    directoryStringFirstComponentMatch,
    wordMatch,
   then the assertion value (...)

Also add something like:

     Note that some matching rules parse the input values somewhat before
     before applying [PREP] to them, e.g. substrings, word and
     caseIgnoreList matching urles.

> 4.2.1.  bitStringMatch

>    If the corresponding ASN.1 type does have a named bit list then
>    bitStringMatch operates as above except that trailing zero bits in
>    the attribute and assertion values are treated as absent.

What is a named bit list?  I can think of two meanings for which the
above would be wrong, and one where it would be right.  Given that, it's
a bit hard to review this rule:-)

> 4.2.21.  keywordMatch

Maybe this rule should RECOMMEND that the implementation applies [PREP]?

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

Editorial comments:

> 3.2.  Common Definitions

>    The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
>    <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
>    [MODELS].

<OCTET> is no longer used here.

> 3.3.1.  Attribute Type Description

Suggest to indent the example like other examples in the draft, with a
line break in front of this text:

>    For example, the following definition of the createTimestamp
>    attribute type from [MODELS] is also a value of the Attribute Type
>    Description syntax (note: line breaks have been added for readability
>    - they are not part of the value when transfered in protocol).
>
>       ( 2.5.18.1 NAME 'createTimestamp'
>          EQUALITY generalizedTimeMatch
>          ORDERING generalizedTimeOrderingMatch
>          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
>          SINGLE-VALUE NO-USER-MODIFICATION
>          USAGE directoryOperation )

> 3.3.7.  DIT Content Rule Description

>       Example:
>          ( 2.5.6.4 DESC 'content rule for organization'
>             NOT ( x121Address $ telexNumber ) )
>
>    Note: a line break has been added for readability - it is not part of
>    the value.

Indent that paragraph to be aligned with "Example:".

> 3.3.28.  Postal Address

>    The <HEX-DIGIT>
>    rule is defined in Section 3.2.

...and it is not used anywhere in this draft.

> Appendix B. Changes from RFC 2252 & RFC 2256

No reference to RFC 3698?

>    This annex lists the significant differences between this
>    specification and RFC 2252 and Sections 6 and 8 of RFC 2256.

But parts of it is worded as a 'differences to RFC 2252' list:

>    2.  The major part of Sections 4, 5 and 7 has been moved to [MODELS]
>        and revised.

of rfc2252.

>    14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
>        Terminal Identifier and Telex Number syntaxes from RFC 2256 have
>        been incorporated.

...in 2252.  It was already in 2256, so this is no change to <2252+2256>.
Same with point 26.

-- 
Hallvard