Re: syntaxes-09 notes

Hallvard,

Apologies for sitting on this for so long.

Hallvard B Furuseth wrote:
>>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.)

I don't have a copy of E.123. Can anyone else help out with this ?
> 
> 
>>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?

Don't know, but common sense says it should be an error for LDAP/X.500.
I've added this text following the ABNF for GeneralizedTime (and similar
for UTCTime):

    A character string conforming to the ABNF MUST be a valid date and time.
    For example, 1994023100Z is not a legal value for Generalized Time
    (February 31, 1994).

> If so, is it an error for a GeneraliedTime?

I'm making it so.

> 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?

This is a big rat hole. I think we just leave it to implementors to decide
how thorough they want to be in deciding what a "valid" time is.

> 
> 
>>      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.

Okay.

> 
> 
>>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.

A ttx-value is either an OCTET STRING or the raw octets of a TeletexString.
I've renamed <ttx-value-char> to <ttx-value-octet>.

> 
> 
>>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).

We talk about equality matching rules, not equivalence matching rules,
so I think it is appropriate to say "equal".

> 
> 
>>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.

That case at least is still a [PROT] issue.

> And maybe stringprep
> could turn such an invalid value into a valid one...

Stringprep only gets invoked to do the matching, and matching won't be attempted
if the syntax is wrong.

 > 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/.

I've changed that to "an AssertionValue" since there isn't an ASN.1 type
called AssertionValues. The same change should be made to 4.5.1.7.2 of
the protocols draft.

> s/MUST conform/conform//?

Okay, since the imperative belongs to the protocols draft.

> 
> Prepend "Conceptually," as in [protocol]:
> 
> 
>>   The entire
>>   SubstringFilter is converted into an assertion value of the
>>   substrings matching rule prior to applying the rule.

Okay.

> 
> 
>>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.

This statement is bogus and misleading for the substrings matching rules,
the first component matching rules and wordMatch.

I've revised this to:

    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:

       numericStringMatch,
       numericStringSubstringsMatch,

       etc.

       telehoneNumberSubstringsMatch and
       wordMatch.
> 
> 
> Also wordMatch (which employs caseIgnoreMatch).

Okay.

> 
> 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 (...)

This looks like there's been a formatting error to me.
A single column works best.

> 
> 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.

I think "Nominated characters string in" captures this now.

> 
> 
>>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?

It's part of the ASN.1 notation for a BIT STRING type.
I've added a reference to X.680.

 > 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]?

Does anyone want to second the motion ? It may require some wordsmithing
in [PREP] as it doesn't have an Insignificant Character Removal step for
keywordMatch.

> 
> ========================================================================
> 
> 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.

Okay.

> 
>>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:

Okay.

> 
> 
>>   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:".

Okay.

> 
> 
>>3.3.28.  Postal Address
> 
> 
>>   The <HEX-DIGIT>
>>   rule is defined in Section 3.2.
> 
> 
> ...and it is not used anywhere in this draft.

Okay.

> 
> 
>>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.
> 

I've revised Appendix B to read consistently as the set of changes
from RFC 2252.

Thanks,
Steven