RE: non-UTF8 string Substrings matching

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

What do I mean by strings?

LDAP specifies a string encoding of attribute values and a string encoding
of distinguished names. The encoding specifies UTF-8. These are the
'strings' of LDAP.

Some attributes do not have a string encoding. Their values are not
'strings'.

Therefore, I would not expect a substrings matching rule for certificate or
jpegPhoto.

CommonName is a string. If its value is "Ron" then I would expect that this
is the target for matching. Even if specified as cn;binary, I would still
expect the value to be matched to be "Ron" and not #1203526f6e.

You now say that you wish to match T.61 strings. What have these got to do
with LDAP? LDAP values are required to be specified in UTF-8. Where are you
trying to go with this?

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 25 October 2000 4:18
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: non-UTF8 string Substrings matching


At 06:04 PM 10/24/00 +1100, Ramsay, Ron wrote:
>I don't think xx;binary is an appropriate target for this discussion. It is
>a way of specifying the transfer syntax. The matching rules should address
>only the (conceptual) stored syntax.

I have three targets for this discussion:
  X.500 octetStringSubstringsMatch rule
  Teletex (T.61) teletexString matching via
    default mode transfer
  Teletex (T.61) directoryString matching via
    ;binary mode transfer

Due to the UTF-8 restriction of the transfer syntax, these substrings
assertions are currently not allowed.  In my option, the transfer syntax
should not be restricted to UTF-8.  I believe that any assertion
value valid per the matching rule should be transferrable (using
default or ;binary transfer).

Many implementations of LDAPv3 ignore the UTF-8 restriction upon
the substrings transfer syntax and instead restrict the asserted
value per the matching rule syntax.  Likewise, most LDAPv2
implementations ignore the IA5 (ASCII) restriction upon the
substrings transfer syntax.

This behavior, IMO, is consistent with X.500 and should be allowed.
Note that allowing it does not require any change to the actual
BER encoding used in the protocol.  That is, the needed change to
the ASN.1 is notational.

>Further, I cannot see the point of extending substring-match to
non-strings.

By non-strings, do you meant non-UTF8 strings? or non-textual strings?
or non- something else strings?