Re: Rep (2) : simple information lookup services

[Christian Huitema <[e-mail]>]

=> 
=> 1. I share Ascan and Tim vew that a minimum facility of search criterias
=> 	is needed

The single problem I have here is that I would like to emphasize simplicity,
and also to facilitate caching of previous results as well as use of inversion
tables. I don't believe that the same simple tool can be optimized for basic
look ups and for sophisticated browsings of the directory.

=> 2. In order to combine Christian view (untyped values only) with that,
=> 

When I said "UFN format", I mostly meant that a name (or search) token could
be either a text string or an attribute value assertion. The UFN format allows
one to write names as either:

	Christian Huitema, Sophia, INRIA, FR

or 	CN=Christian Huitema, OU=Sophia, INRIA, FR

or even Christian Huitema, OU="Sophia" + City="Valbonne", INRIA, FR

In fact, the winning part is the possibility to carry (and cache) simple
unspecified text strings instead of painful UFN constructs such as:

	search for (City=Sophia || OU=Sophia || O=Sophia || CN=Sophia)
	under (O=INRIA, C=FR) 

Also, if one can send that to a server, then the server can directly process
the upper part and chain the rest -- there is no need to go back to the UA for
iteration to the next level in the hierarchy. Additionally, the server can
cache for some period the results of the untyped search, which would lead to a
masive speed up.

So I guess that the ASN.1 would look like:

	SOLO-Target ::= SEQUENCE OF SOLO-Filter
	SOLO-Filter ::= CHOICE {
		untyped-text[0] OCTET STRING,
		namepart AttributeValueAssertion -- a Sequence --,
		and SET OF SOLO-Filter,
		or [2] SET OF SOLO-Filter,
		not [3] SOLO-Filter}

Note that any Distinguished Name can be defined that way -- careful choice of
tokens even leads to BER compatibility. Demonstration: RDN can be written as
and{} of name parts...

Christian Huitema