Re: syntaxes-09 notes

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

Except where noted, I concur with Steven comments.

At 10:28 PM 2/6/2005, Steven Legg wrote:
>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 ?

First, E.123 is available from the ITU (which, BTW, allows 3 free
downloads per year).

Second, I don't think it appropriate to provide an ABNF here.
The E.123 format is best considered a free format.   While it
can certainly be argued that a more precise format would be
better, it is not generally within our scope to update X.500
syntaxes (or to introduce new syntaxes).

I do however think it would be good to add an example or two,
both here and elsewhere character string encodings are used in LDAP.


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

I see no text in ISO 8601 regarding how implementations are to deal with
character strings which do not represent dates in the Gregorian calendar.

However, ISO 8601 does say:

3.16
month, calendar
time-interval resulting from the division of a calendar year in 12 sequential time-intervals, each with a specific name
and containing a specified number of calendar days
NOTE 1 In the Gregorian calendar, the months of the calendar year, listed in their order of occurrence, are named and
contain the number of days as follows: January (31), February (28 in common years; 29 in leap years), March (31), April (30),
May (31), June (30), July (31), August (31), September (30), October (31), November (30), December (31).


This applies to LDAP string encoding as LDAP is a restriction of the ISO 8601 format.

One could even argue that ISO 8601 is clear that 20050229Z is invalid (as it
clearly doesn't represent a date in the Gregorian calendar).

>Don't know, but common sense says it should be an error for LDAP/X.500.

Well, if an implement detects this.  But can we expect implementations
to catch such things.  For instance, would you expect an implementation
to catch 20050229Z as being invalid?  Or catch invalid leap seconds?

>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 you are going to MUST it, then you should update the ABNF
to reflect that MUST (at least in cases such as 31.February).
But as this MUST actually would require implementations to know
which years are leap years, where leap seconds are valid, etc.,
I think something like:
        The above ABNF allows characters strings which do not
        represent valid dates (in the Gregorian calendar) and/or
        valid times.  Such character strings SHOULD be considered
        invalid per this syntax.

Especially given that you suggest (below) to leave it up to
implementations to decide how rigorous this checking should be.

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

I certainly don't expect servers, in general, to check that a
character string represents a valid abstract value, especially
when invalidity is not expressed in the ASN.1.
 
>>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?

ISO 8601, and hence this syntax, only cover dates in the
Gregorian 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.

We discussed at one point adding a requirement that servers
may (if not should) refuse to accept values which are not
equal to themselves.  WIthout this requirement, some odd
behavior would be allowed (such as not being able to delete
by value a previously added single value).

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

I prefer to leave keywordMatch details a local matter.


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