simple information lookup services

[Ascan Woermann <[e-mail]>]

After numerous failed attempts, I resubmit for discussion on the list, 
a message on a subject I've called "Simple Information Lookup" services.

----

In my opinion we'll increasingly see the emergence of simple and compact 
interfaces, such as, the address books of mail user agents, that enable 
users to easily and quickly access the directory in a user-friendly manner
for specific information about objects. The user expects to enter a selection
of search criteria, and obtain in response the desired information: 
telephone number, mail address, ...

The service should make minimum resource requirements on the machine and 
communications bandwidth : It should be possible to provide such a service 
even on low-end machines (notebooks, personal organizers) operating over 
communications media such as the PSTN, mobile links, ... 

Other characteristics of such services are :
- They access the directory via a "high-level" lookup service provided by
	a search algorithm (UFN, AFRO).
- By their very simplicity, they don't require the generic DIT browsing 
	capability of (L)DAP.
- The user may be able to provide information other than just a purported 
	name to search on, e.g., the type of object or a yellow-pages search 
	attribute, i.e., more info than just a UFN.
- An architecturally attractive approach bearing in mind the resource 
	limitations, is to encapsulate the algorithm in a DUA server accessed by a 
	simple query-reply protocol -- one such high-level query typically 
	equates to 2-5 DAP operations.

Some precedents are :
1) UFN encapsulated as a server in ISODE (DASE ???), 
2) AddressFinder by somebody in Norway - I've lost the reference;
3) the ALU (Address Lookup) Service used by TS-E3X's mail agent address-book 
	prototype.

Since in my view we'll see an increasing proliferation of such services 
and protocols, it is important to discuss issues such as their positioning, 
possible standardisation and the need for general vs. specific solutions for 
different categories of applications.

To get the ball rolling and to illustrate the type of service I'm talking about,
here is an outline of what could be a general protocol, which would address 
the requirements of the various applications I've worked on :

SOLO : The Simple infOrmation LOokup protocol is a simple connectionless 
protocol consisting of 2 messages : query + reply :

	SOLO-Query ::= SEQUENCE {
		controls			SOLO-ServiceControls,
		infoSelection	SET OF AttributeType,  	 
		domain			DistinguishedName DEFAULT {},
		locationInfo	SEQUENCE OF AttributeValueAssertion OPTIONAL,
		targetInfo 		SOLO-TargetInfo }

	SOLO-ServiceControls ::= SEQUENCE {
		match 			[0] INTEGER { good(0), approximate(1) },
		maxSize			[1] INTEGER OPTIONAL,
		maxTime			[2] INTEGER OPTIONAL }

	SOLO-TargetInfo ::= CHOICE {
			item 	[0] SEQUENCE OF AttributeValueAssertion,
			and 	[1] SET OF SOLO-TargetInfo,
			or 	[2] SET OF SOLO-TargetInfo,
			not 	[3] SOLO-TargetInfo } 

	SOLO-Reply ::= SEQUENCE OF SEQUENCE {
		name 				DistinguishedName,
		infos				SET OF Attribute }
	
	-- AttributeType, AttributeValueAssertion, Attribute, DistinguishedName
	-- either X.500 ASN.1 or LDAP textual encoding 
	
	-- SOLO-Query + SOLO-Reply wrapped with request + version identifier and
	-- authentication credentials over any suitable transport

1) "domain" indicates the search area, e.g., the DN of an organization,
2) "locationInfo" consists of "purported" AVAs indicating the location of 
	objects in the search area, e.g., OU name tokens for searches in an
	organizational information base,
3) "targetInfo" consists of "purported" AVAs about the target object;
	these could be good, substring or approximate values - the algorithm 
	decides on a search strategy controlled by "match"; 
	typical attributes are one or more of the following :
		- the object class, 
		- the name (CN, S),
		- other search attributes (Title, activity, ...)

My idea is not to specify an algorithm. 
Existing search algorithms as UFN or AFRO can be adapted.

Some issues for discussion are :
- usefulness of a generic approach ? potential loss of semantics for 
	particular applications ? should we rather aim for specific solutions for 
	particular application categories ?
- the service is provided by a general algorithm : is this possible ? clients 
	(and DUA designers) often demand particular adaptions or behaviour

A proposal: these concerns could be handled to a large degree by requiring 
SOLO server implementations to document the schema, the search algorithm is 
able to search in (and any constraints) OR, probably more wisely, by 
by publishing "schema profiles", based on, for example :
	- organizational information bases - white pages RFC1384/Thomas 
		Lenggenhager's WG-NAP paper,
	- the above with parallel trees : geographical, organigrams, ...
	- the NADF schema,
	- schemas oriented towards yellow-pages searching,
The documentation would have to include a specification of the type of
objects implementations should be able to search for, and the attributes 
accepted as "locationInfo" and "targetInfo".
Identification of these "schema profiles" could be worked into
the protocol if necessary.

Note that this is not an attempt to propose a solution - more an effort to 
stimulate some thought and discussion on the subject. 

Looking forward to your comments,

Ascan Woermann

TS-E3X
Sophia-Antipolis
France