RE: Objections to draft-ietf-ldapext-psearch-01.txt

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Got my vote too.

> -----Original Message-----
> From:	Surendra Reddy [SMTP:skreddy@us.oracle.com]
> Sent:	Saturday, 15 August 1998 2:59
> To:	Ed Reed, Scott Isaacson, Dave Huntbach (Ed Reed);
> ietf-ldapext@netscape.com
> Subject:	RE: Objections to draft-ietf-ldapext-psearch-01.txt
> 
> I  agree with Ed.
> 
> -Surendra
> 
> 
	[Alan Lloyd]  Eds note > 
> > Based on the above reasons, we don't believe that the LDAP 
> > community should adopt or promote the mechanism described for 
> > common use, much less forward it for consideration on any 
> > standards track.  Instead, we believe work should go forward, as 
> > described in (4) above, with a more generally useful mechanism.
> > 
> > Best regards,
> > 
> > 
> > 
> > -------------------
> > Ed Reed, Technologist
> > Novell, Inc.
> > +1 801 861 3320
> >
[Alan Lloyd]  - sent to the LDUP list today.
to John (Merrils) and list  - having just returned from a long US/europe
trip. and seeing all
the LDAP extensions for:
Persistent searches, Transactions, triggers, signed operations (which
should be signed audit records) and initiating replication processes. I
am concerned that if these extensions applied together by a naughty
client what would an ldap server do. ie if transcation IDs lock
resource, then how does one replicate in, what happens to a ldap server
with persistent searches and triggers if one zaps in 200,k entries in
replication processes.

In addition most of the extensions being added do not work well in a
distributed model. ie to put a transaction state, a trigger state and a
persistent search state accross a distributed system where you do not
know how many servers actually are involved with such a search operation
- all hell will break loose..

But I suppose this is really upto the LDAP server (non X.500 types)
implementors to sort out. All I can do is wish them good luck. - and the
customers that use them.
regards alan


>