[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syntaxes-09 notes

To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Subject: Re: syntaxes-09 notes
From: Steven Legg <steven.legg@eb2bcom.com>
Date: Mon, 07 Feb 2005 17:28:10 +1100
Cc: ietf-ldapbis@OpenLDAP.org
In-reply-to: <HBF.20041108wdc@bombur.uio.no>
References: <HBF.20041108wdc@bombur.uio.no>
User-agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113


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

Follow-Ups:
- Re: syntaxes-09 notes
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>

Prev by Date: Re: strange uniqueMemberMatch
Next by Date: Re: Requesting individual schema elements
Index(es):
- Chronological
- Thread