RE: revised LDAPEXT charter

[Yoram Yaacovi <yoramy@MICROSOFT.com>]

Some of us entertained a similar problem about a year ago, when buddy lists
became IN, mainly in conjunction with dynamic LDAP. Since buddy lists need
to track the online/offline state of users, couldn't it be simply one
dynamic attribute on the user DS object ?

The catch, of course, was notifications. Once the user changes status (goes
online), the LDAP server needs to notify the client that the user state
changed, and this is very unnatural to LDAP with its client-asks,
server-answers approach. Having the client poll the server once in a while
conforms to the LDAP paradigm, but is inaccurate time-wise and inefficient. 

At the time, I thought that we could add this functionality into LDAP and I
actually thought about drafting it. But as time went by, the
client-initiated approach of LDAP became more obvious and dominant, and as
we needed to get V3 out of the door, it became less of a fit in my mind, and
maybe the subject of another protocol or a specialized LDAP extension. Once
server-initiated operations are supported (even if only as a result of an
earlier client-initiated operation), you could implement all kind of
features that require notifications. I still feel that this belongs to
another protocol.

You wanted an opinion. You got it.

Yoram

	-----Original Message-----
	From:	Harald Tveit Alvestrand [SMTP:Harald.Alvestrand@maxware.no]
	Sent:	Tuesday, January 20, 1998 1:59 PM
	To:	Mark Wahl
	Cc:	ietf-ldapext@netscape.com
	Subject:	Re: revised LDAPEXT charter

	Mark,

	thanks for the charter update.
	I'm CCing this message to the LDAPEXT list, because I think
	we need to work this out with the list.

	I'm definitely of the opinion that the Right Target for
	triggered search is Experimental, not Proposed.

	I think it is an out-and-out bad idea to hack this
	functionality straight into the general LDAP service;
	it basically splits the LDAP server community into two
	parts that will be optimized for different purposes.

	The extension is basically allowing the definition of
	arbitrary-complexity search expressions, each of which
	must be executed at each and every update of the database
	(and in the scenarios where it makes sense, updates are
	expected to be frequent). A server that is optimized for
	such queries will be a VERY different beast from the
	read-mostly, relatively-static data that most current
	LDAP implementations are created for.

	(The wahl-trigger seems better than the psearch
	draft in this regard, because it allows the code
	to be isolated to that part of the server dealing with
	the changelog - but I'm not sure the functionality
	here is what people want.)

	Note that there are other protocols being proposed
	that are explicitly aimed at change notification;
	RVP (draft-calsyn-rvp-00.txt) is only one of them.

	What is the opinion of other people on the list?


	                       Harald A

	NOTE: New Email address: Harald.Alvestrand@maxware.no
	I am working for Maxware (www.maxware.no) as of Dec 1, 1997