RE: non-UTF8 string Substrings matching

["Steven Legg" <steven.legg@adacel.com.au>]

Kurt,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> 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.

There isn't a standard LDAP syntax for TeletexString so in the first
instance I would argue that the TeletexString substrings assertion
syntax is undefined rather than disallowed. Our server implementation
does support TeletexString as a syntax and, by analogy with the
teletexString choice in a DirectoryString, its string encoding is
the equivalent UTF-8 character string (the BER encoding is still
a regulation TeletexString). So in the second instance I would argue
that it is only the ;binary encoding of the TeletexString assertion
syntax that is not currently allowed (but ought to be, of course).

In my component matching rules draft I have continued the theme
by defining the LDAP string encoding of all the ASN.1 string types
(in the componentFilterMatch assertion syntax) to be UTF-8.
The actual ASN.1 string type only needs to come into play when
dealing with the binary encoding.

Regards,
Steven 

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