syntaxes-07 comments

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

> 3.3.30.  Substring Assertion

This syntax is restricted to UTF-8.  That means that it cannot be used
as the assertion syntax of an octetStringSubstringsMatch rule, if one
wants to define that.  One must instead define an 'Octet Substring
Assertion' syntax along with the matching rule.  Should it be that way?

> 3.3.34.  UTC Time

>      UTCTime         = year month day hour minute [ second ]
>                           [ u-time-zone ]

<second> from Generalized Time allows - and should allow - leap seconds,
but the UTC Time ASN.1 syntax does not.  This needs a restriction that
second=60 is invalid for UTCTime, or the use of another <second-u> =
00-59 rule for UTCTime.

See the following messages:

http://www.openldap.org/lists/ietf-ldapbis/200301/msg00039.html
Steven Legg writes:

> The UTCTime type in X.680 doesn't allow for leap seconds (60 seconds
> is an illegal value).

http://www.openldap.org/lists/ietf-ldapbis/200305/msg00088.html
Kathy Dally writes:

[about Generalized Time]

> I checked ISO 8601, and it does support leap second.


> 4.2.5.  caseIgnoreListMatch

>   The caseIgnoreListMatch rule compares an assertion value that is a
>   sequence of strings to an attribute value of a syntax (e.g., the
>   Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
>   OF the DirectoryString ASN.1 type.

Shouldn't it allow SEQUENCEs OF 'DirectoryString or one of the
alternative string types of DirectoryString', like e.g. caseIgnoreMatch
does?  Both for caseIgnoreMatch and caseIgnoreListMatch, X.520 just
refers to these strings as type DirectoryString.

The same applies to caseIgnoreListSubstringsMatch.

>   In [X.520] the assertion syntax for this matching rule is defined to
>   be:
>
>      SEQUENCE OF DirectoryString {ub-match}
>
>   i.e., different from the corresponding type for the Postal Address
>   syntax.  The choice of the Postal Address syntax for the assertion
>   syntax of the caseIgnoreListMatch in LDAP should not be seen as
>   limiting the matching rule to only apply to attributes with the
>   Postal Address syntax.

I think this text can be deleted.  What choice of Postal Address?
Postal Address is mentioned as one example syntax for this matching
rule, that's all.  And while the X.520 assertion syntax differs a bit
from the Postal Address syntax, it differs no more than e.g. the
caseIgnoreMatch syntax differs from Country String.

> 4.2.6.  caseIgnoreListSubstringsMatch

>   Note that, in terms of the LDAP-specific encoding of the Postal
>   Address syntax, the concatenated string omits the <DOLLAR> line
>   separator and the escaping of "\" and "$" characters.

I think 'the Postal Address syntax' should be 'syntaxes such as the Postal
Address syntax'.

But I don't understand this.  Assertion values will have (e.g.) Postal
Address syntax, so they escape "\" and "$".  These characters won't
match if the concatenated strings from the attribute value do not escape
them.

Also, it seems irrelevant whether or not the <DOLLAR> line separator is
omitted, since a substring may not cover a line separator anyway.  But I
guess it's cleanest to omit it when you don't escape "\" and "$".

> 4.2.7.  caseIgnoreMatch
> 4.2.8.  caseIgnoreOrderingMatch
> 4.2.9.  caseIgnoreSubstringsMatch

'a syntax whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types' does not cover IA5 String?

> 5.  Security Considerations

>   In general, the LDAP-specific encodings for syntaxes defined in this
>   document do not define canonical encodings.  That is, a
>   transformation from an LDAP-specific encoding into some other
>   encoding (e.g., BER) and back into the LDAP-specific encoding will
>   not necessarily reproduce exactly the original octets of the
>   LDAP-specific encoding.  Therefore an LDAP-specific encoding should
>   not be used where a canonical encoding is required.

This sounds strange.  An encoding of an LDAP string is a canonical
encoding of that LDAP string, even if there are different ways to spell
it (like \, vs. \hex in DNs).  OTOH, it is not a canonical encoding of
an ASN.1 value.

> 7.  IANA Considerations
>   The Internet Assigned Numbers Authority (IANA) is requested to update
>   the LDAP descriptors registry [BCP64] as indicated by the following
>   templates:

and

> 8.1.  Normative References
>   [BCP64]    Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
>              Considerations for the Lightweight Directory Access
>              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.

Should this be draft-ietf-ldapbis-bcp64-xx.txt, and a note in section 7
that bcp64 is being updated?

------------------------------------------------------------------------

Editorial comments.

General:

Sometimes you use %x<hex><hex> for a character in the ABNF, other times
you use "<character>".  You should mostly stick to one of these
variants.  (My vote is for "<character>", but looking at the other
drafts, I seem to be outvoted.)

For example:
> 3.2.  Common Definitions
>      IA5String          = *(%x00-7F)
>      HEX-DIGIT          = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
>                                 ; N.B. allows upper and lower case
>      SLASH              = %x2F  ; forward slash ("/")
I particularly like 'line-char' in 3.3.28 (Postal Address):-)
>      line-char     = ...
>                      / (%x5C "24")  ; escaped "$"
>                      ...

In IA5String, the %x<hex><hex> notation is of course natural even if you
use "<character>" notation elsewhere.

BTW, why not write hex-digit this way?

       HEX-DIGIT          = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
                                  / "a" / "b" / "c" / "d" / "e" / "f"

It's no more text, and expresses the exact grammar without resorting to
a comment which modifies it.

> 3.3.13.  Generalized Time

>      g-differential  = ( MINUS / PLUS ) hour [ minute ]
>      MINUS           = %x2D  ; minus sign ("-")

and

> 3.3.16.  Integer

>      Integer = ( HYPHEN LDIGIT *DIGIT ) / number

Either use the predefined HYPHEN in 3.3.13 and 3.3.34 (UTC Time), or
define MINUS in 3.2 (Common Definitions) and use that in 3.3.16.

> 3.3.28.  Postal Address

>   by the two hexadecimal digit code for the character.  The <HEX-DIGIT>
>   rule is defined in Section 3.2.

Postal Address does not use <HEX-DIGIT>.

> 4.2.12.  generalizedTimeOrderingMatch

>   The generalizedTimeOrderingMatch rule compares the time ordering of
>   an assertion value of the Generalized Time syntax to an attribute

Delete "the time ordering of".  It sounds strange, and seems redundant
since ordering by time is stated in the next paragraph.

-- 
Hallvard