Re: evaluation: draft-legg-ldapext-component-matching

[hardie@qualcomm.com]

Steve,
	I think this draft takes a slightly different road
than RFC 3454-style stringprep.  The way I look at it, stringprep
profiles define a set of steps which must be taken in order
to correctly store a string or compare two strings
within a particular protocol context (from section 1.2 of
RFC 3454).  In a sense, it provides a set of mechanisms
that allow you to manipulate a set of data so that well-known
matching rules can be safely (and simply) applied.
	This draft takes the other direction--it leaves
the data as is, but uses generic matching rules against
user-identified component parts to allow for
arbitrarily complex attribute matching.  Some of those
generic matching rules relate to string matching (section
4.2.1.1 has a list), but they derive from types set up
in draft-legg-gser-abnf, which has both ABNF and
ASN.1 definitions for them.  While stringprep profiles
could be used in the definitions of some of the generic
matching rules, I am not sure it is the right fit, since
the actual matches won't fit within the basic stringprep
theory.
	If there are more particular problems you have
specific string matching profiles, let me know.  Also,
both Harald and Russ have extensive experience here
(certainly much more than mine), and I'd be happy to
have their opinion on how this fits.
			regards,
				Ted Hardie


At 5:13 PM -0400 6/25/03, Steve Bellovin wrote:
>                     Yes    No-Objection  Discuss *  Abstain 
>
> Steve Bellovin      [   ]     [   ]       [ x ]      [   ]
>
> Does this document need a Stringprep profile per RFC 3454?  If not,
> I'd think that any applications that use it would need one, which
> means that this shoould at least point to 3454.  (Unless, of
> course, I don't know what I'm talking about, which is quite likely
> in this space.)