From list@netscape.com  Thu Jun  1 06:32:30 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18486
	for <ldapext-archive@odin.ietf.org>; Thu, 1 Jun 2000 06:32:30 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e51APF227176;
	Thu, 1 Jun 2000 03:25:15 -0700 (PDT)
Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA10839; Thu, 1 Jun 2000 03:29:07 -0700 (PDT)
Resent-Date: Thu, 1 Jun 2000 03:29:07 -0700 (PDT)
From: Hm0y8tn4h@po.cnet-sc.ne.jp
DATE: 01 Jun 00 6:43:39 AM
Message-ID: <aI257qKl4OC>
SUBJECT: great web hosting deals  gghy 
Resent-Message-ID: <"jxwZV.A._oC.yrjN5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more PER MONTH OR MORE TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL OUR OFFICE.

YOU CAN CHANGE YOUR SITE AS MUCH AS YOU WANT with no extra charge!  UNLIMITED TRAFFIC -- no extra charge!


A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE.

FOR DETAILS CALL 1 888 248 0765  or fax 240 337 8325

PES WEB HOSTING -- 

____________________________________________________

WE do bulk email for you!
Call 888 248 0765 to promote your business today!
Half million email blast $495.00.
One million email blast $1275.00
Two million email blast $2500.00
For further information if you are outside the USA fax 240 337 8325
________________________________________________________

Get your estate planned today!
Avoid the prying eyes of the public!
Creditor proof your assets from those who want to get your 
money!
For further details fax 240 337 8325                                      





From list@netscape.com  Thu Jun  1 06:33:16 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18498
	for <ldapext-archive@odin.ietf.org>; Thu, 1 Jun 2000 06:33:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e51ARo227625;
	Thu, 1 Jun 2000 03:27:50 -0700 (PDT)
Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA12259; Thu, 1 Jun 2000 03:31:43 -0700 (PDT)
Resent-Date: Thu, 1 Jun 2000 03:31:43 -0700 (PDT)
Message-Id: <200006011031.GAA18453@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ldapext@netscape.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
Date: Thu, 01 Jun 2000 06:31:35 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"wAo2DB.A.L_C.NujN5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Extension Working Group of the IETF.

	Title		: Connection-less Lightweight Directory Access Protocol
	Author(s)	: L. Johasson, R. Hedberg
	Filename	: draft-ietf-ldapext-cldap-00.txt
	Pages		: 10
	Date		: 31-May-00
	
This memo describes modifications to LDAP version 3[1] to allow
transport of a subset of the LDAP protocol over connection-less
transport. The case of UDP/IP is covered in detail in this memo but
other transport layers are possible.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-cldap-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapext-cldap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapext-cldap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000531112014.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldapext-cldap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldapext-cldap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000531112014.I-D@ietf.org>

--OtherAccess--

--NextPart--




From list@netscape.com  Thu Jun  1 09:21:58 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22689
	for <ldapext-archive@odin.ietf.org>; Thu, 1 Jun 2000 09:21:57 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e51DFv208178;
	Thu, 1 Jun 2000 06:15:57 -0700 (PDT)
Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA15928; Thu, 1 Jun 2000 06:19:50 -0700 (PDT)
Resent-Date: Thu, 1 Jun 2000 06:19:50 -0700 (PDT)
Message-Id: <3.0.5.32.20000601061936.00962d70@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 01 Jun 2000 06:19:36 -0700
To: Internet-Drafts@ietf.org
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
Cc: ietf-ldapext@netscape.com
In-Reply-To: <200006011031.GAA18453@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"bLp3vC.A.e4D.1LmN5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

RFC2222, 3.:
   The Simple Authentication and Security Layer (SASL) is a method for
   adding authentication support to connection-based protocols. 

I-D, Abstract:
   This memo describes modifications to LDAP version 3[1] to allow
   transport of a subset of the LDAP protocol over connection-less
   transport.

I-D, Security considerations

   Unlike CLDAP verison 2[3] it is possible for a CLDAPv3 client to
   establish a secure association to a CLDAPv3 server by a SASL bind
   which can establish an integrity or security layer. 

How?



From list@netscape.com  Thu Jun  1 11:28:20 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25773
	for <ldapext-archive@odin.ietf.org>; Thu, 1 Jun 2000 11:28:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e51FJdS21314;
	Thu, 1 Jun 2000 08:19:39 -0700 (PDT)
Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA23831; Thu, 1 Jun 2000 08:26:44 -0700 (PDT)
Resent-Date: Thu, 1 Jun 2000 08:26:44 -0700 (PDT)
Message-Id: <3.0.5.32.20000601082637.0093c7f0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 01 Jun 2000 08:26:37 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
In-Reply-To: <200006011031.GAA18453@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"e4aqhC.A.6zF.zCoN5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Additional comments:

The document should be updated to use RFC 2119 terminology
statement.  I will assume it uses MUST, SHOULD per 2119.

Section 2:
> Encoded packets must be small enough to fit inside a datagram
> no bigger than the size of the MTU of the transport mechanism."

Why the MUST?  Would the protocol not work if the MTU was
exceeded?  I would think SHOULD would sufficient... with a
statement as to why (ip fragmentation?).

Section 4:
> Therefore the application using CLDAPv3 have to handle packet loss.

And duplication.  And reorderring.

> One way of aiding this would be to add something like a
> packet sequence number in the PDUs sent from the server
> to the client, how this is to be done is outside the scope
> of this document.

I would argue that this complete within the scope of this
document and should be addressed in the I-D.

In addition the draft should address issues regarding the
association (or lack thereof) of a session to a particular
client.

> They (servers) must also check the version field of the LDAP PDU

An LDAP PDU does not have a version request.


> 6. Security considerations

Given SASL/TLS are designed for connection-oriented application
protocols, I suggest looking into use of IPSEC transport mode
to provide security services.






From list@netscape.com  Fri Jun  2 12:33:25 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06856
	for <ldapext-archive@odin.ietf.org>; Fri, 2 Jun 2000 12:33:24 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e52GRpW28766;
	Fri, 2 Jun 2000 09:27:51 -0700 (PDT)
Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA03140; Fri, 2 Jun 2000 09:31:45 -0700 (PDT)
Resent-Date: Fri, 2 Jun 2000 09:31:45 -0700 (PDT)
Message-Id: <200006021631.JAA09686@nasnfs.eng.sun.com>
Date: Fri, 2 Jun 2000 09:34:59 -0700 (PDT)
From: James Kempf <James.Kempf@Eng.Sun.COM>
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Subject: SLP Schema OIDs
To: ietf-ldapext@netscape.com, ipp@pwg.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: AZGTdJ6KBa+chQgFAtErbQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Resent-Message-ID: <"1v_CwB.A.rw.wF-N5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

In response to concern expressed by IPP group members about the use
of Sun-assigned OIDs in the SLP template to schema conversion draft,
I attempted to obtain a nonaffiliated root from IANA. Unfortuantely,
they have not yet replied to my request. So, in an
effort to move the SLP template conversion draft forward, I obtained
an Enterprise Number from IANA for SrvLoc.Org, for which I've been
assigned as the responsible party. SrvLoc.Org is the web site we've
been using for SLP information. I will use this enterprise number to
derive the OIDs for the SLP template draft.

If anybody has any objection to this, please let me know.

		jak



From list@netscape.com  Fri Jun  2 22:52:47 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20971
	for <ldapext-archive@odin.ietf.org>; Fri, 2 Jun 2000 22:52:46 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e532lJW12743;
	Fri, 2 Jun 2000 19:47:20 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e532pD225357;
	Fri, 2 Jun 2000 19:51:13 -0700 (PDT)
Resent-Date: Fri, 2 Jun 2000 19:51:13 -0700 (PDT)
Date: Fri, 2 Jun 2000 19:11:09 -0700 (PDT)
Message-Id: <200006030211.e532B9T09237@ywing.netscape.com>
From: rfioffshore@angelfire.com
To: ietf-ldapext@netscape.com
Subject:  $name Here is a question for you.
X-Reply-To:  rfi1@success4unme.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"4Z-93C.A.3KG.fKHO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

$name, would you like some great information? I am asking you this because I would like to share 
something with you.
 
 With your Permission I would like you to recieve an information packet.

 If you would like to learn about something really good, then please just reply to this e-mail with info in the 
subject. You will get an auto- response with a full information package.
  mailto:rfi1@success4unme.com

 Thank you for your time. You will not regret it.

  Sincerely.
  Your friend.




From list@netscape.com  Sat Jun  3 01:56:52 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27498
	for <ldapext-archive@odin.ietf.org>; Sat, 3 Jun 2000 01:56:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e535pSW21549;
	Fri, 2 Jun 2000 22:51:28 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e535tNg01731;
	Fri, 2 Jun 2000 22:55:23 -0700 (PDT)
Resent-Date: Fri, 2 Jun 2000 22:55:23 -0700 (PDT)
Date: Sat, 3 Jun 2000 10:34:16 -0500
From: garyfrench@hotpop.com
Message-Id: <200006031534.KAA03047@dandy.magnitka.ru>
To: fd09la@jkflap.com.netscape.com
Subject: Earn A Serious Income From Home!!!!!!
Resent-Message-ID: <"wiW4q.A.ra.J3JO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...

We're searching for only 10 elite individuals with the work ethic
necessary to generate a cash-flow for themselves of $2,000 - 5,000
per week, and to increase that to over $20,000 per month, in as
little as four to six months. And you know what? If you really
have a burning desire and commitment, we guarantee you that 
you'll reach this explosive income!

Can you read a short script to our qualified leads, and then turn 
the interested prospects over to our electronic sales medium?
(you will not be required to do any selling.)

Do you have the self-discipline to ignore the TV for a couple
of hours per day?

Are you looking for a legitimate home-based business opportunity,
that is not multi-level marketing, or a chain-letter scheme?

If you would like to build an amazing income that will grow 
lightning-fast and have you profit $1,000.00 every time only 
one prospect makes a purchase, then this is for you!

You can build the business under our guidance and support without
having to attend meetings or sell people things they don't need.

Call NOW our TOLL FREE, PRE-RECORDED Message:1-888-605-2501

We market a real product, that pays real commissions to you,
$1,000.00 per sale, just for making the initial contacts.
With our turnkey lead generation systems you'll always talk 
to people who actually WANT to talk to you.

You have nothing to lose, there's no risk involved, nor 
is there any obligation whatsoever, and you may be qualified
to earn thousands of extra dollars per month!

So call now! The call is FREE, and there is absolutely no obligation,
So what have you got to lose? Call Toll Free 1-888-605-2501

P.S. You literally have a once-in-a-lifetime opportunity to 
GET INVOLVED NOW! Don't let this one go by. You have 
absolutely nothing to lose! This could be the most fascinating 
and profitable business of your life! REALLY....

Please, serious inquiries only.









To be removed from our mailing list please
send an email to:   t10069@HotPOP.com    and place remove
in the subject
Thank you



From list@netscape.com  Sat Jun  3 11:03:36 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07948
	for <ldapext-archive@odin.ietf.org>; Sat, 3 Jun 2000 11:03:31 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e53EvkW25264;
	Sat, 3 Jun 2000 07:57:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e53F1f216655;
	Sat, 3 Jun 2000 08:01:41 -0700 (PDT)
Resent-Date: Sat, 3 Jun 2000 08:01:41 -0700 (PDT)
Date: Sat, 3 Jun 2000 08:01:30 -0700 (PDT)
Message-Id: <200006031501.e53F1IT03788@ywing.netscape.com>
From: homeowners2000@goodday.net.netscape.com
To: Friend@netscape.com
Subject:  A Must For All Homeowners!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"u20A_.A.pDE.T3RO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Homeowners, You MUST see this! Our manager program WILL save you literally $ 
THOUSANDS and THOUSANDS of dollars without refinancing, it will cut YEARS off your 
mortgage without increasing your payment, it will build equity in your home 300% faster. 
You'll be able to audit your loan automatically to find lender mistakes which occur about 
50% of the time according to the F.D.I. C. It's FREE and requires NO CHANGE in your 
current mortgage agreement at all, NONE!
To get your FREE copy of the manager software for Windows 95, please send $2 to cover 
the cost of S&H to : DRS / PO Box 360 / Holbrook, MA 02343. I will send it out the same 
day that I recieve your request. I promise this is EVERYTHING that you have read, it will 
cost you NOTHING, and it WILL save you many, many thousands of dollars ($40,000-
$150,000)....so why would you want to keep giving all that money to the bank when you 
can just use our manager program, and keep all the savings for you and your family? 
Send today and start saving! This IS the BEST move EVER for you! Thousands are using 
this right now,  and soon you will be too! This offer is applicable in the U.S.A. only !




From list@netscape.com  Sun Jun  4 02:56:38 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28848
	for <ldapext-archive@odin.ietf.org>; Sun, 4 Jun 2000 02:56:37 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e546p7W28271;
	Sat, 3 Jun 2000 23:51:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e546t3k26227;
	Sat, 3 Jun 2000 23:55:03 -0700 (PDT)
Resent-Date: Sat, 3 Jun 2000 23:55:03 -0700 (PDT)
Date: Sat, 3 Jun 2000 23:54:58 -0700 (PDT)
Message-Id: <200006040654.e546swL08494@ywing.netscape.com>
From: makeit@KIOX.aol.com
To: ietf-ldapext@BLTI.netscape.com
Subject:  Guaranteed Earnings! Proven Results! Free Info! -CCDD
X-Reply-To:  kamar@myfreeoffice.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"sBRaKD.A.bZG.G1fO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Guaranteed!  Would you like to make extra money part-time from the comfort of your own home? All you 
need is a computer and internet access and we can show you how to make a nice extra income. We will 
only be accepting the first 27 people who respond to this email. So reply to this email for more info today! 
For complete details about this FREE incredible offer, please reply to this email SEND BLANK EMAIL NOW! 
mailto:clickto@getresponse.com




From list@netscape.com  Sun Jun  4 04:08:04 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06058
	for <ldapext-archive@odin.ietf.org>; Sun, 4 Jun 2000 04:08:04 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5481RW01597;
	Sun, 4 Jun 2000 01:01:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5485KE07530;
	Sun, 4 Jun 2000 01:05:20 -0700 (PDT)
Resent-Date: Sun, 4 Jun 2000 01:05:20 -0700 (PDT)
Date: Sun, 4 Jun 2000 02:06:28 +1200
From: WTqJ99Pb3@cbccts.sk.ca
Message-ID: <nXCS7v2X33Lo1uk4T>
Subject: Re: > WARNING: Anyone Has Access To YOUR Computer!!! < kloqkex
X-MIMETrack: Itemize by SMTP Server on Smithers.GlobalBrain/GlobalBrain(Release 5.0.3 (Intl)|21
 March 2000) at 06/04/2000 07:58:39 PM,
	MIME-CD by Trend MailScan on Smithers.GlobalBrain/GlobalBrain(Release 5.0.3
 (Intl)|21 March 2000) at 06/04/2000 07:58:39 PM,
	MIME-CD complete at 06/04/2000 07:58:39 PM,
	Serialize by Router on Smithers.GlobalBrain/GlobalBrain(Release 5.0.3 (Intl)|21
 March 2000) at 06/04/2000 08:03:55 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Resent-Message-ID: <"Jbd1dC.A.S1B.-2gO5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



  Are you aware that anyone can access your computer, and
  view your activities if you have accessed the WWW or simply
  use the Internet for e-mail?

  There is a software program that "secretly" records computer
  activity in alarming detail.  It records the date, activity
  time, name of the program or webpage visited, and every
  single keystroke entered.  This data can be compressed and
  e-mailed to any address for inspection.  The silent install
  feature ensures that the report is generated without your detection.

  Do you know that web sites record your visits and your e-mail address?

  Now you may not have anything to hide or be embarrassed about,
  nevertheless if you value your privacy then please DON'T WAIT!!!
  Fill out your order form below then fax it to us immediately.  You will
  be downloading your complete copy within 48 hours.

  When ordering your very own copy by 06/12/00 YOU pay
  ONLY $29.95 after this date the cost is 44.95

  You will receive detailed instructional guidance on how to cover your
  cyber tracks and preserve your privacy rights.

  Ok, you may or may not have anything to hide, nevertheless this
  document is relevant if you:

  => View "adult" sites
  => Use e-mail to transmit private information
  => Visit newsgroups
  => Participate in chat rooms
  => Engage in online shopping
  => Pursue romantic liaisons on the web
  => Want to protect the privacy of your children on the Internet
  => Have an e-business
  => Want to conduct your activities anonymously
  => Are generally concerned about your privacy and security

  POWER TIPS FOR INTERNET PRIVACY
  manual will show you how to:

  => Remove the evidence of all activities on your computer
     (which could be used  by individuals intent on maligning
     you or your reputation).
  => Cover the tracks of your activities on the myriad of
     other portals involved in cyber circuitry.
  => Prevent web sites from collecting information about you every
     time you log on to their site.
  => Protect the transmission and receipt of e-mail messages.
  => Avoid becoming a victim of credit card and identity theft.
  => Conduct your cyber activities anonymously.
  => Empower you to reclaim your most precious possession - your privacy.

  Your privacy is too important to risk allowing access
  by anyone to your private files and data.  DON'T WAIT
  to get started, order your copy today.

  If YOU know someone who could benefit from this Special Offer,
  simply print this Application form for them or send them this email.
  Orders can ONLY be processed with this Special Internet Form.

  We accept Visa, MasterCard, American Express & Checks by Fax.

  Fax Order Center:  (559) 991-8166

               - - - - - - CUT HERE - - - - - -

        - - - THE POWER TIPS FOR INTERNET PRIVACY - - -

  Please read both statments below, then put your initials
  next to the correct statement.

  _____Yes! Send me the POWER TIPS FOR INTERNET PRIVACY
  today for a total amount of $44.95 (price includes S/H)

  _____Yes! I am order by 06/12/00 please send me the
  POWER TIPS FOR INTERNET PRIVACY today for a total
  amount of ONLY $29.95 (price includes S/H)

  *** For your security, the billing information MUST MATCH
  that on your credit card or we cannot process your order.

  DATE

  AUTH CODE: 02LL

  YOUR NAME OR COMPANY NAME

  ADDRESS

  CITY, STATE, ZIP

  PHONE NUMBERS (      ) _ _ _ - _ _ _ _

  YOUR EMAIL ADDRESS

  TO ENSURE ACCURACY, PLEASE TYPE OR CLEARLY SPELL
  YOUR EMAIL ADDRESS AGAIN:

  TYPE OF CREDIT CARD OR PAYMENT:

  ____VISA ____MASTERCARD ____AMEX ____CHECK-BY-FAX

  CREDIT CARD#

  EXPIRATION DATE____/________ (MM/YYYY)

  NAME ON CARD

  AMOUNT $

  (Required)
  AUTHORIZATION SIGNATURE:____________________

  Fax Order Center:  (559) 991-8166

     - - - - - - CUT HERE - - - - - -

  CHECK BY FAX SERVICES!

  If you would like to fax a check, paste your check to the bottom of
  your completed order form then fax it to the order center above.

  If you fax a check, there is no need for you to send the original check.
  We will draft up a new check, with the exact information from your
  original check.  All checks will be held for bank clearance.
  (7-14 days)  Make payable to:  T.E.

  We will get an incredible response to this offer and all fax lines may be
busy,
  please, keep trying...you'll be glad you did!!!

             =-=-REMOVE INSTRUCTIONS-=-=

  If you no longer wish to receive these Special Internet Offers,
  please send us a blank e-mail to plsrmvme09@bigfoot.com with "remove"
  in the subject field. Or you may Click Here
    mailto:plsrmvme09@bigfoot.com?subject=remove



From list@netscape.com  Sun Jun  4 18:53:33 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10321
	for <ldapext-archive@odin.ietf.org>; Sun, 4 Jun 2000 18:53:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e54Mm7W29911;
	Sun, 4 Jun 2000 15:48:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e54Mq4g16570;
	Sun, 4 Jun 2000 15:52:04 -0700 (PDT)
Resent-Date: Sun, 4 Jun 2000 15:52:04 -0700 (PDT)
From: Publishers@mx-212.fsnet.co.uk
Message-Id: <200006042243.RAA18906@naucalpan>
To: Publisher@mx-202.fsnet.co.uk.netscape.com
Date: Sun, 04 Jun 00 12:43:52 EST
Subject: Publishing Company for Sale!
Resent-Message-ID: <"ALfG2D.A.iCE.R2tO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

See information about Free Credit Application Below!

My Multi-Million Dollar 
Publishing Company 
ONLY $149

Free Pre-Approved Merchant Account Application with Order!! 
To Start Your Business Out Right!!

If you ever wanted "the easy way out" to make a lot of money
with a business of your own....
Here is the EASIEST WAY TO START!

I'm writing this letter to let you in on something that'll blow
you away. What I'm about to present is something I've 
never done before...something that I'll never do again....
So PAY ATTENTION!

For the past few years...I've have been running ads in 
newspapers & magazines, by direct mail, and throughout 
the internet.  These ads were always small and very cheap...

On these ads, we have been selling little manuals.  These
manuals have sold for anywhere between $10 to $99 each.  
We always ran different ads for each manual we were selling.  

I like selling information because NOBODY can put a price on 
it...ESPECIALLY when it is your own...The Sky is the Limit!

Plus it is very cheap to reproduce How-To manuals.  It costs 
between 40 cents and $3 to print the entire print manuals and 
around 35 cents to copy the manuals on disk.  AND you can 
sell them for up to $99 each.   That is one hell of a markup!

These manuals tell you how to get a car with no money down 
and no credit...another one tells you how to avoid taxes by 
depositing income offshore...now you may not be interested in 
saving money by going offshore...but believe me....there are 
MILLIONS OF PEOPLE WHO DO...and they are willing to pay 
me to teach them!!! 

Well this is where the unbelievable offer comes in...I hope you
are sitting down for this one...because this is a once in a 
lifetime chance for you.  I do not know of an easier way to 
become financially independent...In fact THERE IS NO EASIER 
WAY!!!  
The next few paragraphs will reveal everything to you.

I am willing to sell you my entire informational product line 
with FULL REPRINT RIGHTS and complete step-by-step 
instructions on how to start your mail order information business 
with very little money. 

Remember, these are PROVEN WINNERS.  If you are 
stumped on something to sell or if you are having trouble 
writing a good ad, I have also included an entire book on 
disk to help you produce KILLER ads!

This entire package which I call a Publishing Company in a 
Box will come on 1 CD containing over 2000 'Hot-Selling' 
Books, Reports And Manuals ready to print and sell, Sell, 
SELL! It also will come with a signed letter giving YOU FULL 
REPRINT RIGHTS allowing you to sell them for as much as 
you want and however you want.  You Can even sell the entire
kit to someone else to resale on their own!  You also receive 
copies of KILLER ads which can fill your mailbox with cash!

I am not even going to ask you for any of the money either...
What you make is yours to keep .  In fact...you get to make a 
ton of money on these manuals for as long as you wish...and 
you will never have to pay me another red cent in royalties!

I am even going to print out and prepare our #1 selling report 
which contains the secrets of obtaining credit without a credit
check and producing an offshore income without taxes so that 
you will be able to take it down to your local copy shop and be 
ready to sell it the same day you have received it. Watch out 
though - one individual is making $70,000 a month on this report 
alone!  (Why - Because you can include a FREE offshore credit 
application for those with bad or no credit with this report and 
explode your mailbox with orders) Note: THIS APPLICATION IS 
INCLUDED!

All I ask for is...$149 and I will include FREE Priority Mail 
Shipping!  Yes, I said $149.  There are no zeros missing.  
Plus if you order before  June 10, 2000 I will include 
4 extra special bonuses...

Bonus #1 - "Search Engine Magic" on disk.  This report will 
shoot your web site up to the top of the search engine listings.
Other web advertisers are selling this manual for $99 by 
itself - But I will give it to you for FREE with this package.

Bonus #2 - The report "How to Make at least $1,600 a week 
online...Starting Now!" which is taking the internet by storm 
will be included absolutely FREE! 

Bonus #3 - I will include special details about a secret source
for direct mail leads that can produce cash orders along with 
out KILLER ads.  And another source will be given which 
allows you to advertise nationwide through newspapers to 
70,000,000 readers for as low as 7 cents per word.

Bonus #4 - I also will include a pre-approved application for 
a merchant account for your business benefit.  Taking credit 
cards will increase your business up to 100%.  The normal 
$195 application fee will be waved with this pre-approved 
application.  

But there is one drawback... I am sending this ad to 10,000 
other people...and I will only allow 50 kits to be sold.  It 
wouldn't make much sense if I sold this kit to 1,000 or 2,000 
people...The market would be saturated with these same 
manuals... 
and I don't want to do that.  To make sure that the people in 
this offer get the same results I have...ONLY 50 people can have 
it for $149.00!

Chances are, I will get all 50 within a week's time.  So if this 
is something you are interested in...RUSH me a check or money 
order for $149.00 TODAY to insure your future business.

But, even if you decide to pass this up...Don't sweat it.  It's
not like I am going to be mad or anything like that.  I know I 
will get my 50 order limit really fast.  And anyone who gets 
their check into me late... I will simply send it back.

For only $149.00, I am going to let you have the easiest money 
you will ever make.  The manuals are written, the ads are 
presented, the advertising plan is laid out, and all you have 
to do is print them out for pennies and place the ads.

Do it today! Rush me your payment of $149.00 right now...and 
get your very own MILLION DOLLAR publishing company going!

You can start with one or two manuals...even the day you 
receive the package...and then expand to include ALL of them!

For $149.00, you have everything you need to make a killing 
with your very own business.  If you want to make real 
money - then this offer is for you!

"I took the report "Search Engine Magic" and sold over 50 
copies on disk within 2 weeks! They sold for $99 and I was 
able to copy them for under 50 cents each.  Wait till I start 
marketing the other products included in this line!!!"
Joe Fisher - Internet Marketer

To rush order this "MILLION DOLLAR Publishing Company in 
a Box" simply fill out the order form below and fax it to 
our 24 hour  order line at:

FAX ORDER LINE:
1 (212) 504-8032

Regular Mail to:
Financial Systems
P.O. Box 301
Orange, Ma 01364

ORDER FORM
--------------------------------------------------------------
Please send to:

Your Name__________________________________________
 
Your Address________________________________________
 
Your City____________________________________________
 
State / Zip___________________________________________
 
Phone #: ____________________________________________
(For problems with your order only. No salesmen will call.)
 
Email Address_______________________________________

We Accept Checks or Money Orders along with all Major Credit 
Cards 
including Visa, MasterCard and American Express.  (NOTE - We 
only 
ship to the address listed on the credit card)

(Please Fill Out Below Section and Make sure that the above name 
and address are listed as it appears on the card) for $149.00

Credit Card Number:________________________________

Expiration Date___________________________

Signature:_________________________

Date:____________________

[  ] YES! Please rush my Publishing Company in a Box.  I 
understand I have FULL REPRINT Rights and can sell any of 
the items for whatever price I desire, even the entire kit.

[  ] DOUBLE YES!  I am ordering before June 10, 2000!  
Please include the extra special bonuses!

* Please check one of the following payment options:
[  ] I am faxing a check (Do not send original, we will make a 
draft from the faxed check)

[  ] I am faxing or mailing my credit card number. (Note your 
card will be charged for $149.00 and we only ship to the address 
on the card)

[  ] I am enclosing a check or money order for $149.00!

Note - If ordering outside continental US, please add $5 to S&H

P.S. Don't forget you will receive 2,000 Manuals, Books, and 
Reports (Some of which are up to 200 pages each)...all for 
$149...You have full reprint and resale rights to make as much 
money as you want without ever paying any royalties whatsoever!


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
If you have received this message in error and would
like to be removed from future mailings, please reply
with the word remove in the subject. x
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



From list@netscape.com  Mon Jun  5 01:23:45 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16614
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 01:23:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e555IHW16211;
	Sun, 4 Jun 2000 22:18:17 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e555MEQ17605;
	Sun, 4 Jun 2000 22:22:14 -0700 (PDT)
Resent-Date: Sun, 4 Jun 2000 22:22:14 -0700 (PDT)
Date: Mon, 5 Jun 2000 12:17:49 +0700
From: paulvic2000@usa.net
To: <ietf-ldapext@netscape.com>
Subject: We can get rich by helping each other
Reply-To: sample@whynot.net.netscape.com
X-PMFLAGS: 10322341.10
X-UIDL: 10293287_192832.222
Comments: Authenticated Sender is <user122@whynot.net>
Message-Id: <57592998_32469111>
Resent-Message-ID: <"-EH_vB.A.iSE.EkzO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


We can make thousands of $ by helping each other

Dear Friend,

This letter is about an opportunity to make an incredible amount of
Money ( CASH !!!) in a very short time. 

Not another chain letter and 100 % legal
Not a MLM
No member hunting
No forever ad placing
No so and so

Just your meager $ 6.00 one time investment
Mailing six letters
And your favorite one time advertising 

Can  make you THOUSANDS or even HUNDRED OF THOUSANDS $

Skeptical ? Read on

The cost is only $6.00! This is the 16th day since I started receiving 
$ cash, and so far I have received $5,845 (in $1 Bills)...so I guess 
this is really working! Give it a try! All I did was follow the 
instructions in the letter that I received below, and sent out some 
e-mail to people who responded to my ads.

Here is a testimony from one of the thousands who have benefited from
this simple investment plan :

"I'm a retired attorney, and about a year ago a man came to me with
a letter. The letter he brought to me is the same letter before you now.
He asked me to verify that this letter was legal. I told him that I would
review it and get back to him. When I first read the letter, I thought
it was some off the wall idea to make money. A week later I met again with
my client to discuss the issue. I told him that the letter will be all
right. I was curious about the letter, so he told me how it worked. I thought
it was a long shot, so I decided against participating. Before my client
left, I asked him to keep me updated as to his results. About two months
later he called me to tell me that he had received more than $800,000.00
in cash! I didn't believe him so he asked me to try the plan and see for
myself."

"I thought about it for a few days and decided that there was not much
to lose. I followed the instructions exactly and mailed out 200 letters.
Sure enough the money started coming in! It came slowly at first, but after
three weeks I was getting more than I could open in a day. After three
months the money stopped coming. I kept a precise record of my earnings
and at the end it totaled $868,439.00. I earn a good living as an attorney,
but as anyone in the legal profession will tell you, there is a lot of
stress that comes with the territory. I decided if things worked out, I
would retire from practice and play golf. This time I sent out 500 letters.
Well, three months later, I had totaled $2,344,178.00."

"I met my old client for lunch to find out exactly how it works. He
told me that there were a few similar letters going around. What made this
one different is the fact that there were six names on the letter, not
three like most others. That act alone resulted in more returns. The other
factor was the advice I gave him in making sure the whole thing was perfectly
legal, since no one wants to risk doing anything illegal. I bet now you
are curious about what little changes I told him to make. Well, if you
send a letter like this one out, to be legal, you must sell something if
you expect to received a dollar. I told him that anyone sending a dollar
must received something in RETURN. So when you send a dollar to each of
the six names on the list, you must include a slip of paper saying, "Please
add me to your mailing list" and include your name and mailing address.
This is the key to the program. The item you will received for your dollar
sent, is THIS letter and the right to earn thousands."

Follow the simple instructions EXACTLY, and in less than three months
you should receive MORE THAN $80,000.00 IN COLD HARD CASH!

1) IMMEDIATELY send $1.00 (US$) to each of the six people listed below.
THE SOONER YOU SEND THE "$1.00 LETTERS" THE SOONER YOU CAN START GETTING
A RETURN! Wrap the dollar in a note saying :-

"PLEASE ADD ME TO YOUR MAILING LIST"

1. N.K. Miles, P.O. Box 112, Redan, GA 30074
2. W. McCray, 4026 Berry Hill Trail Stone Mountain, GA 30083
3. R. Snyder, PO Box 2734 Poulsbo, WA 98370
4. W. Clapp, 520 Washington Blvd. #395, Marina Del Rey, CA 90292
5. C Enzenga, 1707 Manning Rd Glen Burnie, MD 21061
6. Pisespong Varasarin, 73/035-2 Moo Ban Muang-Ake(Ake Burapa 6),
Lak 6, Muang, Pathumthani 12000, Thailand

2) REMOVE the NAME and ADDRESS of #1 (at the top of the list, here is
N.K. Miles) and move the rest of the names UP one position. Then place
YOUR name in the #6 spot. This is best done by saving this to a file and
entering your information at #6. Be careful when you type the addresses.
Don't forget to PROOFREAD them. Make SURE that the names and addresses
are correct. After finishing the process, it should look like this :

1. W. McCray, 4026 Berry Hill Trail Stone Mountain, GA 30083
2. R. Snyder, PO Box 2734 Poulsbo, WA 98370
3. W. Clapp, 520 Washington Blvd. #395, Marina Del Rey, CA 90292
4. C Enzenga, 1707 Manning Rd Glen Burnie, MD 21061
5. Pisespong Varasarin, 73/035-2 Moo Ban Muang-Ake(Ake Burapa 6),
Lak 6, Muang, Pathumthani 12000, Thailand
6. YOUR NAME, YOUR ADDRESS

3) When you have COMPLETED the above instructions, you have several
options on how you market the letter - through the Postal Service, through
E-mail, through posting in "FREE CLASSIFIED ADS" and "NEWSGROUPS" ON THE
INTERNET, or through whatever way you think is most effective.

To send this letter out to thousands of people and increase your profits,
I suggest you use a Bulk E-mail company. Any opportunity seekers target mailing
list providers will work. If you don't know any of them, our mailing list
members can help you. Just ask them when you send your $ 1 bill.

THIS IS A SERVICE AND IS 100% LEGAL because we will email you download 
site of :-
1. "Secrets of Internet Marketing" e-Book
2. More than 650 New Reports and Full Reprint & Resell Rights ! 
3. Several ready to download HOW TO and GUIDE TO reports
4. Free bulk email software
5. And much more about internet marketing resources to explode your
online sale.
 

Some internet marketers applied some of those tactics and made hundreds of $
extra money. While others spent a lot of money in order to gain the knowledge.
Yours FREE !! 
 
Above are by products of what you will get, abundant of $ 1 bill in your
mail box everyday!!

This letter has been proven perfectly legal for all of the above as
long as you follow the instructions, because you are purchasing membership
in our exclusive mailing list. The more you send out, the more YOU will
make. We strongly encourage you to mail this letter to family, friends,
and relatives as well.

THIS IS A SERVICE AND IS 100% LEGAL. (Refer to title 18, section 1302
&amp;1341 of the US Postal and Lottery Laws)

Assume for example you get a 8% return rate :-

1) When you mail out 200 letters, ONLY 16 people send you $1.00

2) Those 16 people mail out 200 letters, (3200 letters) and ONLY 256
people send you $1.00

3) Those 256 people mail out 200 letters, (51,200 letters) and ONLY
4, 096 people send you $1.00

4) Those 4,096 people mail out 200 letters (812,200 letter) and ONLY
65,536 people send you $1.00

5) Those 69,536 people mail out 200 letters (13,107,200 letters) and
ONLY 1,048,576 people send you $1.00.

At the Next level your name-drops off the list.

Think about it. Look what you WILL have BEFORE your name-drops
off the list! I know this looks and sounds unbelievable. Just try it, and
you will be happy that you did because you will received proof when THOUSANDS
of ONE-DOLLAR BILLS start to pile up!

This formula is SCIENTIFIC and UNBEATABLE number game.It has 
been proven to thousands as the EASIEST WAY to make A LOT OF MONEY beyond
their imagination !!

***MAKE SURE you send***
 
One US dollar to each of the six names on the list. 
This is VERY IMPORTANT.
Don't left out even one of them or this program will not work.

With a note saying 
"PLEASE ADD ME TO YOUR MAILING LIST"
My email address is................
 
(Your email address is optional ; fill it only if you want to download 
free reports, E-books and internet marketing resources)

What should you do after receiving each $ 1 bill ? You should send
thank you email(if they send you their email addresses) to each of
them. Inform them internet marketing resource download site.(like
the one you will receive from our mailing list members who receive
$ 1 bill from you). 


Here is sample of thank you email.
=============================================================
WELCOME TO MILLIONAIRE MAILING LIST CLUB THANK YOU FOR JOINING 
OUR MAILING LIST MEMBERS.
DOWNLOAD SITE IS http://................
=============================================================

It will be quite tedius for you to send 5,000 thank you emails if
you receive 5,000 envelopes. (Don't forget each envelope will be 
stuffed with $ 1 bill. That means you receive $ 5,000 !!) 
Don't worry you don't have to send them all together at once. 
Further, bulk email software which you can download from our site 
will help you a lot. It can send thousands of email an hour at 
one click.

HONESTY is the most important factor to make this system work. Rule
of the game is a must to follow.So please don't derail this wonderful
method of making a fortune !!

You've read this far, so let me ask you one simple question :

WHAT HAVE YOU GOT TO LOSE?

In the worst case, you get zero response (least possibility if you
strictly follow our steps). You waste 6.00 = a piece of Mcdonald
+ a medium fry.

In a fair case, you get $ 600.00 - $ 2,000.00. More than 100 times of
your initial investment.

In a better case, you get $ 10,000.00 - $ 50,000.00. You will have a
great deal of extra money for a new car,your dream house or free money
for travelling around the world with hard cash in your pocket.

In the best case, $ 100,000.00 - $ 300,000.00, what would you do with
this pile of money ? You may have to take a seat and start thinking about
it now.

Even with a 1% return you will still get $50,000.00 in 90 DAYS!!! 

What you can gain is an income, like the example in this letter. You will have
a very small expense, but you will reap HUGE potential returns. 


What do you have to lose?
 

I invite you to JOIN our mailing list RIGHT NOW!

Thanks you for your time.

GOOD LUCK & BEST WISHES TO YOU !!!

*****************************************************************
This is one time message no need to remove. You will not receive
it again.



From list@netscape.com  Mon Jun  5 01:25:32 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16883
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 01:25:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e555K9W16650;
	Sun, 4 Jun 2000 22:20:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e555O7A18627;
	Sun, 4 Jun 2000 22:24:07 -0700 (PDT)
Resent-Date: Sun, 4 Jun 2000 22:24:07 -0700 (PDT)
Date: Sun, 4 Jun 2000 22:24:03 -0700 (PDT)
Message-Id: <200006050524.e555O3R16826@xwing.netscape.com>
From: loseweightfast@visualcities.com
To: loseweightfast@visualcities.com
Subject: FREE SAMPLE!  Look and feel great!  100% Guarantee!
Resent-Message-ID: <"xW7mEC.A.hiE.1lzO5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

    ,

100% Money Back Guarantee and FREE SAMPLES!!!  

http://www.aaadiet.com

"I Lost 40 Pounds in 2 Months!  So can YOU!!!"


1-800-701-THIN (8446)


FREE SAMPLES HAVE BEEN ARRANGED FOR YOU!!!


Come and see what 30 Million have and are using to Look And Feel GREAT!!!



We Specialize in Weight Loss, Weight Gain and in the Finest Nutrition, Health and Fitness, Beauty and Personal Care in the WORLD.  Now in 47 Countries!

http://www.aaadiet.com





________________________________________________________
This Message was Sent To You BY REQUEST.  IF you wish to be removed from all future mailings, please reply with the subject "Remove" and this software will automatically block you 
from all future mailings.  INCLUDING OUR FREE OFFERS AND SWEEPSTAKES!!!





From list@netscape.com  Mon Jun  5 10:32:00 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03299
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 10:31:59 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55ENH116258;
	Mon, 5 Jun 2000 07:23:17 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55EUV200703;
	Mon, 5 Jun 2000 07:30:31 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 07:30:31 -0700 (PDT)
content-class: urn:content-classes:message
Subject: Error Code returned when Critical Extension fails
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFCEFA.B81550DC"
Date: Mon, 5 Jun 2000 07:31:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0
Message-ID: <96BABA22ECEAEA45B53D08D63E1B5678527F69@DF-SPIKE.platinum.corp.microsoft.com>
Thread-Topic: Error Code returned when Critical Extension fails
Thread-Index: Ab/O+pVEAHyIqBtaSSO/SzNQct9plA==
From: "Michael Armijo" <micharm@Exchange.Microsoft.com>
To: <ietf-ldapext@netscape.com>
X-OriginalArrivalTime: 05 Jun 2000 14:31:21.0866 (UTC) FILETIME=[B849E6A0:01BFCEFA]
Resent-Message-ID: <"kVk8FB.A.nK.Gm7O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFCEFA.B81550DC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I wanted to get clarification from the WG on which error code should be
used when an operation with a critical control fails due to an error
within the control.

A simple example would be a failed critical VLV control (let's say due
to a missing Sort control).

The most obvious answer would be unavailableCriticalExtension (12), but
it is not explicitly defined for this condition on RFC 2251 (or in the
Result Codes draft). =20

I would like clarification from the WG on this to make sure we are all
agreed on how to handle this condition.

thanks,
Michael

------_=_NextPart_001_01BFCEFA.B81550DC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4384.0">
<TITLE>Error Code returned when Critical Extension fails</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">I wanted to get clarification from the =
WG on which error code should be used when an operation with a critical =
control fails due to an error within the control.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A simple example would be a failed =
critical VLV control (let's say due to a missing Sort control).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The most obvious answer would be =
unavailableCriticalExtension (12), but it is not explicitly defined for =
this condition on RFC 2251 (or in the Result Codes draft).&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like clarification from the WG =
on this to make sure we are all agreed on how to handle this =
condition.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">thanks,<BR>
Michael</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFCEFA.B81550DC--



From list@netscape.com  Mon Jun  5 11:02:46 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04022
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 11:02:45 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55Es5119192;
	Mon, 5 Jun 2000 07:54:06 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55F1Kg11189;
	Mon, 5 Jun 2000 08:01:20 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 08:01:20 -0700 (PDT)
Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECD7A@MAILSRVNT02>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: "'James Kempf'" <James.Kempf@Eng.Sun.COM>, ietf-ldapext@netscape.com,
        ipp@pwg.org
Subject: RE: IPP> SLP Schema OIDs
Date: Mon, 5 Jun 2000 08:00:56 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Resent-Message-ID: <"SP_u9D.A.duC.-C8O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi James,

Fine - using the 'srvloc.org' enterprise root sounds good.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  (co-editor of SLP and LDAP printer schemas)
  High North Inc

-----Original Message-----
From: James Kempf [mailto:James.Kempf@Eng.Sun.COM]
Sent: Friday, June 02, 2000 9:35 AM
To: ietf-ldapext@netscape.com; ipp@pwg.org
Subject: IPP> SLP Schema OIDs


In response to concern expressed by IPP group members about the use
of Sun-assigned OIDs in the SLP template to schema conversion draft,
I attempted to obtain a nonaffiliated root from IANA. Unfortuantely,
they have not yet replied to my request. So, in an
effort to move the SLP template conversion draft forward, I obtained
an Enterprise Number from IANA for SrvLoc.Org, for which I've been
assigned as the responsible party. SrvLoc.Org is the web site we've
been using for SLP information. I will use this enterprise number to
derive the OIDs for the SLP template draft.

If anybody has any objection to this, please let me know.

		jak



From list@netscape.com  Mon Jun  5 11:27:43 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04581
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 11:27:41 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55FIcW23376;
	Mon, 5 Jun 2000 08:18:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55FMZs19216;
	Mon, 5 Jun 2000 08:22:35 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 08:22:35 -0700 (PDT)
Message-Id: <3.0.5.32.20000605082231.0093c510@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 05 Jun 2000 08:22:31 -0700
To: "Michael Armijo" <micharm@Exchange.Microsoft.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: Error Code returned when Critical Extension fails
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <96BABA22ECEAEA45B53D08D63E1B5678527F69@DF-SPIKE.platinum.c
 orp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"w-Vb8D.A.2rE.6W8O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 07:31 AM 6/5/00 -0700, Michael Armijo wrote: 
>I wanted to get clarification from the WG on which error code
>should be used when an operation with a critical control fails
>due to an error within the control.
>A simple example would be a failed critical VLV control (let's say
>due to a missing Sort control). 
>The most obvious answer would be unavailableCriticalExtension (12),
>but it is not explicitly defined for this condition on RFC 2251
>(or in the Result Codes draft).  

Yiks.  Actually, RFC 2251 has a typo.
  s/unavailableCriticalExtension/unsupportedCriticialExtension/
or
  s/unsupportedCriticalExtension/unavailableCriticialExtension/

However, with either spelling, 12 should be used as indicated
in 4.1.12.

I would suggest the return a different resultCode (which
should be described by the control specification).   For
a invalid controlValue, I suggest protocolError.

Kurt





From list@netscape.com  Mon Jun  5 11:48:34 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04946
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 11:48:34 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55Fds125090;
	Mon, 5 Jun 2000 08:39:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55Fl9E28914;
	Mon, 5 Jun 2000 08:47:09 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 08:47:09 -0700 (PDT)
Message-Id: <200006051546.RAA01048@mail.su.se>
X-Mailer: exmh version 2.1.1 10/15/1999
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
cc: ietf-ldapext@netscape.com
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt 
In-Reply-To: Message from "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 
   of "Thu, 01 Jun 2000 08:26:37 PDT." <3.0.5.32.20000601082637.0093c7f0@infidel.boolean.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Mon, 05 Jun 2000 17:41:25 +0200
From: Leif Johansson <leifj@it.su.se>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e55Fl6P28884
Resent-Message-ID: <"JUhKs.A.aDH.7t8O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit


Hi Kurt,

Thanks for keeping us on the straight and narrow :-) Your comments
were right on the mark as usual.

> Additional comments:
> 
> The document should be updated to use RFC 2119 terminology
> statement.  I will assume it uses MUST, SHOULD per 2119.

absolutely

> 
> Section 2:
> > Encoded packets must be small enough to fit inside a datagram
> > no bigger than the size of the MTU of the transport mechanism."
> 
> Why the MUST?  Would the protocol not work if the MTU was
> exceeded?  I would think SHOULD would sufficient... with a
> statement as to why (ip fragmentation?).

Handling fragmentation would (imho) make the protocol too complicated
to bother with as an alternative to tcp. Reordering and retransmission
is "trouble" enough (see below). The note imho MUST be a MUST but the
reason SHOULD (MUST ?) be clearly stated!

> 
> Section 4:
> > Therefore the application using CLDAPv3 have to handle packet loss.
> 
> And duplication.  And reorderring.
> 

agree, but (see below) ...

> > One way of aiding this would be to add something like a
> > packet sequence number in the PDUs sent from the server
> > to the client, how this is to be done is outside the scope
> > of this document.
> 
> I would argue that this complete within the scope of this
> document and should be addressed in the I-D.

Well, any solution would seem to require adding controls (or other protocol
elements). We were hoping to move all such additions to experimental drafts.

> 
> In addition the draft should address issues regarding the
> association (or lack thereof) of a session to a particular
> client.
> 
> > They (servers) must also check the version field of the LDAP PDU
> 
> An LDAP PDU does not have a version request.

You are absolutely right -- I don't know what got into us here. This note 
must go away. I had a thought when writing this but it was unclear which.

> 
> 
> > 6. Security considerations
> 
> Given SASL/TLS are designed for connection-oriented application
> protocols, I suggest looking into use of IPSEC transport mode
> to provide security services.
> 
> 
> 
> 

You are right again. Do you know the reason why sasl is only specified for
connection-oriented protocols? Would this be "fixable" by amending sasl or
is there some "real" reason behind keeping sasl connection-oriented only.
In anyway specifying IPSEC would seem to be the "right" thing to do.

	Cheers leif





From list@netscape.com  Mon Jun  5 12:49:10 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06145
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 12:49:10 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55GhQW07639;
	Mon, 5 Jun 2000 09:43:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55GTUM02100;
	Mon, 5 Jun 2000 09:29:30 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 09:29:30 -0700 (PDT)
Message-Id: <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 05 Jun 2000 09:28:45 -0700
To: Leif Johansson <leifj@it.su.se>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt 
Cc: ietf-ldapext@netscape.com
In-Reply-To: <200006051546.RAA01048@mail.su.se>
References: <Message from "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
 <3.0.5.32.20000601082637.0093c7f0@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"uGkkQ.A.Tc.VV9O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 05:41 PM 6/5/00 +0200, Leif Johansson wrote:
>> Section 2:
>> > Encoded packets must be small enough to fit inside a datagram
>> > no bigger than the size of the MTU of the transport mechanism."
>> 
>> Why the MUST?  Would the protocol not work if the MTU was
>> exceeded?  I would think SHOULD would sufficient... with a
>> statement as to why (ip fragmentation?).
>
>Handling fragmentation would (imho) make the protocol too complicated
>to bother with as an alternative to tcp.

CLDAP is not complicated by IP fragmentation.  IP implementations
must support IP fragmentations and applications protocols should
care less of fragmentation occurs or not.  There should be no
interoperability issue.

I concur that fragmentation is expensive, but this fact alone
is insufficient justification for the MUST.

The SHOULD would be sufficient, I suggest something on the
lines of:
  Implementations SHOULD avoid sending PDUs which require
  fragmentation at lower levels as reassembly is expensive.
  Implementations MAY use path MTU discovery or other means
  for determining an MTU restriction.  Implementations
  MUST be capable of accepting and generating PDU of size X.

The latter requirement necessary to ensure an implementation
can respond to a critical (simple) request.  Not sure what
value X should take.

>Do you know the reason why sasl is only specified for
>connection-oriented protocols? Would this be "fixable" by amending sasl or
>is there some "real" reason behind keeping sasl connection-oriented only.

SASL requires connection-oriented, reliable transport by design.
It cannot be easily amended to support connection-less, unreliable
transports.

>In anyway specifying IPSEC would seem to be the "right" thing to do.

Yes, and we'd need to define a secure authentication mechanism
for CLDAP.  I would suggest adding an authentication choice
external [4] which would use lower level credentials exchanged
at lower level to establish CLDAP session level authentication
(and authorization).  That is, it would work like SASL "External",
but be SASL-less.



From list@netscape.com  Mon Jun  5 13:37:08 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07220
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 13:37:08 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55HUcW16194;
	Mon, 5 Jun 2000 10:30:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55HYag03220;
	Mon, 5 Jun 2000 10:34:36 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 10:34:36 -0700 (PDT)
Date: Mon, 05 Jun 2000 12:32:52 -0500
From: Mark Wahl <M.Wahl@innosoft.com>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
In-reply-to: "Your message of Mon, 05 Jun 2000 09:28:45 PDT."
 <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
Sender: wahl@austin.innosoft.com
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
Cc: Leif Johansson <leifj@it.su.se>, ietf-ldapext@netscape.com
Message-id: <13425.960226372@threadgill.austin.innosoft.com>
MIME-version: 1.0
X-Mailer: exmh version 2.0.2 2/24/98
Content-type: text/plain; charset=us-ascii
Resent-Message-ID: <"LRMX-D.A.6x.qS-O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


I would prefer that the SASL EXTERNAL mechanism be used to pick up the 
IPSEC credentials to the LDAP level, rather than a new protocol field.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Innosoft, part of Sun Microsystems, Inc.'s iPlanet alliance



From list@netscape.com  Mon Jun  5 14:07:11 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07797
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 14:07:10 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55Hvq115608;
	Mon, 5 Jun 2000 10:57:52 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55I57U17962;
	Mon, 5 Jun 2000 11:05:07 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 11:05:07 -0700 (PDT)
Message-Id: <s93b94cf.011@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 05 Jun 2000 11:53:35 -0600
From: "Sukanta Ganguly" <SGANGULY@novell.com>
To: <leifj@it.su.se>, <Kurt@openldap.org>
Cc: <ietf-ldapext@netscape.com>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e55I46P17580
Resent-Message-ID: <"B5Fh5D.A.9VE.Mv-O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Hi,
  You folks state that IP fragmentation is not a issue with CLDAP. Where would one have an implementation wherein the reliability that we expect from TCP could be taken care of? I guess I am having a difficult time understanding as to where would the UDP packet retransmissions in case of losses would be handled? There are many more to the related issue like packet re-ordering etc.
  If we do not have this in the Network layer (i.e. layer 3) then either the application needs to handle them, which would be another overhead that the LDAP server needs to handle/manage or the application clearly would not care for it. I can't imagine the case where in LDAP applications are ignorant to the fact that some of the data they send and receive may not actually come to them. LDAP which is a application level protocol is very order sensitive and users would be really pissed if they do not get the data which they have stored within the speicific Directory (and I am not even mentioning the uncertiaties due to the lossely consistent replication models).
  I think there needs to be serious effort in addressing them as the CLDAP server implementors would have a great deal of heart burn implementing them.
  

SG

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 06/05/00 10:29AM >>>
At 05:41 PM 6/5/00 +0200, Leif Johansson wrote:
>> Section 2:
>> > Encoded packets must be small enough to fit inside a datagram
>> > no bigger than the size of the MTU of the transport mechanism."
>> 
>> Why the MUST?  Would the protocol not work if the MTU was
>> exceeded?  I would think SHOULD would sufficient... with a
>> statement as to why (ip fragmentation?).
>
>Handling fragmentation would (imho) make the protocol too complicated
>to bother with as an alternative to tcp.

CLDAP is not complicated by IP fragmentation.  IP implementations
must support IP fragmentations and applications protocols should
care less of fragmentation occurs or not.  There should be no
interoperability issue.

I concur that fragmentation is expensive, but this fact alone
is insufficient justification for the MUST.

The SHOULD would be sufficient, I suggest something on the
lines of:
  Implementations SHOULD avoid sending PDUs which require
  fragmentation at lower levels as reassembly is expensive.
  Implementations MAY use path MTU discovery or other means
  for determining an MTU restriction.  Implementations
  MUST be capable of accepting and generating PDU of size X.

The latter requirement necessary to ensure an implementation
can respond to a critical (simple) request.  Not sure what
value X should take.

>Do you know the reason why sasl is only specified for
>connection-oriented protocols? Would this be "fixable" by amending sasl or
>is there some "real" reason behind keeping sasl connection-oriented only.

SASL requires connection-oriented, reliable transport by design.
It cannot be easily amended to support connection-less, unreliable
transports.

>In anyway specifying IPSEC would seem to be the "right" thing to do.

Yes, and we'd need to define a secure authentication mechanism
for CLDAP.  I would suggest adding an authentication choice
external [4] which would use lower level credentials exchanged
at lower level to establish CLDAP session level authentication
(and authorization).  That is, it would work like SASL "External",
but be SASL-less.




From list@netscape.com  Mon Jun  5 14:14:21 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07900
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 14:14:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55I29W22304;
	Mon, 5 Jun 2000 11:02:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55I60E18742;
	Mon, 5 Jun 2000 11:06:00 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 11:06:00 -0700 (PDT)
Message-Id: <3.0.5.32.20000605110519.009436e0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 05 Jun 2000 11:05:19 -0700
To: Mark Wahl <M.Wahl@innosoft.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: SASL/EXTERNAL and CLDAP
Cc: Leif Johansson <leifj@it.su.se>, ietf-ldapext@netscape.com
In-Reply-To: <13425.960226372@threadgill.austin.innosoft.com>
References: <"Your message of Mon, 05 Jun 2000 09:28:45 PDT." <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"C0XlrB.A.OkE.Fw-O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 12:32 PM 6/5/00 -0500, Mark Wahl wrote:
>I would prefer that the SASL EXTERNAL mechanism be used to pick up the 
>IPSEC credentials to the LDAP level, rather than a new protocol field.

I agree that SASL/EXTERNAL can and should be used to pick lower
level credentials associated with connection.  Those credentials
can be provided by TLS, IPSEC, or other lower layer associated
with the connection.

However, SASL (including SASL/EXTERNAL) cannot be used with
connectionless protocols, you must have a connection to use
SASL.  CLDAP should not overload/redefine any existing
authentication choice nor any specification of those choices.

Given that Connection-less LDAP cannot make use of SASL, it
should (must) define a separate choice (and specification)
which provide for secure authentication.  This choice can be
based upon SASL/EXTERNAL, but it is not SASL/EXTERNAL as it
would be defined in a manner which supports connection-less
transports.

Kurt




From list@netscape.com  Mon Jun  5 14:22:56 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08007
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 14:22:55 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55IDp118313;
	Mon, 5 Jun 2000 11:13:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55IL6625271;
	Mon, 5 Jun 2000 11:21:06 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 11:21:06 -0700 (PDT)
Message-ID: <393BEDAD.AF04356C@netscape.com>
Date: Mon, 05 Jun 2000 14:13:01 -0400
From: mcs@netscape.com (Mark C Smith)
Organization: iPlanet E-Commerce Solutions
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ldapext@netscape.com
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
References: <200006011031.GAA18453@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"Q9R-BB.A.LKG.Q--O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Internet-Drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the LDAP Extension Working Group of the IETF.
> 
>         Title           : Connection-less Lightweight Directory Access Protocol
>         Author(s)       : L. Johasson, R. Hedberg
>         Filename        : draft-ietf-ldapext-cldap-00.txt
>         Pages           : 10
>         Date            : 31-May-00

Section 3 says:

   ... Note that it is
   possible for a client to issue a modifying request (add, delete,
   moddn, modify) together with a control or an extended request which
   modifies the directory such that the response is too large to fit in
   a datagram which would make it impossible for the client to know if
   the requested operation was successful or not. For this reason
   servers implementing this protocol must respond with an error of
   unwillingToPerform(53) if such a request is received.

Does the above mean that a server must determine the size of a response
before it actually carries it out?  That might be tricky to implement.

Also, I'd prefer to see a more specific error introduced for this case
(or just use resultsTooLarge).  An unwillingToPerform error may be
returned for other reasons, and it would be nice to unambiguously tell
the client "This can't be done over UDP, please try again over TCP."  In
fact, I'd like to see the client's recommended behavior with respect to
error recovery and use of LDAP over TCP (when a CLDAP request fails)
spelled out in the draft.

It would also be valuable to provide a "scope" or "requirements"
section.  For example, I think a useful CLDAP protocol could omit all of
the update operations (keeping compare and search).

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?



From list@netscape.com  Mon Jun  5 14:27:25 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08090
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 14:27:24 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55IID119303;
	Mon, 5 Jun 2000 11:18:13 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55IPS627144;
	Mon, 5 Jun 2000 11:25:28 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 11:25:28 -0700 (PDT)
Message-Id: <4.3.1.0.20000605112941.00ade3d0@pop.walltech.com>
X-Sender: bgreenblatt@pop.walltech.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 05 Jun 2000 11:31:51 -0700
To: "Kurt D. Zeilenga" <Kurt@openldap.org>, Mark Wahl <M.Wahl@innosoft.com>
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject: Re: SASL/EXTERNAL and CLDAP
Cc: Leif Johansson <leifj@it.su.se>, ietf-ldapext@netscape.com
In-Reply-To: <3.0.5.32.20000605110519.009436e0@infidel.boolean.net>
References: <13425.960226372@threadgill.austin.innosoft.com>
 <"Your message of Mon, 05 Jun 2000 09:28:45 PDT." <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"k73VhB.A.alG.RC_O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:05 AM 06/05/2000 -0700, Kurt D. Zeilenga wrote:
>At 12:32 PM 6/5/00 -0500, Mark Wahl wrote:
> >I would prefer that the SASL EXTERNAL mechanism be used to pick up the
> >IPSEC credentials to the LDAP level, rather than a new protocol field.
>
>I agree that SASL/EXTERNAL can and should be used to pick lower
>level credentials associated with connection.  Those credentials
>can be provided by TLS, IPSEC, or other lower layer associated
>with the connection.
>
>However, SASL (including SASL/EXTERNAL) cannot be used with
>connectionless protocols, you must have a connection to use
>SASL.  CLDAP should not overload/redefine any existing
>authentication choice nor any specification of those choices.


Why couldn't I write a draft titled "Using SASL/EXTERNAL mechanism in 
connectionless protocols"?  As I read RFC 2222, it only says that it 
defines how to use SASL over connection oriented protocols.  It doesn't 
appear to say that there is no way to ever use SASL/EXTERNAL within UDP.

Bruce

>Given that Connection-less LDAP cannot make use of SASL, it
>should (must) define a separate choice (and specification)
>which provide for secure authentication.  This choice can be
>based upon SASL/EXTERNAL, but it is not SASL/EXTERNAL as it
>would be defined in a manner which supports connection-less
>transports.
>
>Kurt



From list@netscape.com  Mon Jun  5 14:57:39 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08576
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 14:57:39 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55Imt126786;
	Mon, 5 Jun 2000 11:48:55 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55IuAA13087;
	Mon, 5 Jun 2000 11:56:10 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 11:56:10 -0700 (PDT)
Message-ID: <393BF890.FE48C54B@netscape.com>
Date: Mon, 05 Jun 2000 14:59:28 -0400
From: mcs@netscape.com (Mark C Smith)
Organization: iPlanet E-Commerce Solutions
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
CC: Michael Armijo <micharm@Exchange.Microsoft.com>, ietf-ldapext@netscape.com
Subject: Re: Error Code returned when Critical Extension fails
References: <3.0.5.32.20000605082231.0093c510@infidel.boolean.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"__36dD.A.FMD.If_O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

I agree with Kurt -- documents that describe controls should specify
what result codes are returned.  In the example you mentioned, the VLV
draft defines a sortControlMissing code that will be returned in the
virtualListViewResult field of the virtualListViewResponse (i.e., within
the VLV response control).  But I do not see where the draft specifies
what value is to be returned for the search request itself in this
situation, i.e., in the resultCode field of the LDAPResult (it should).

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?


"Kurt D. Zeilenga" wrote:
> 
> At 07:31 AM 6/5/00 -0700, Michael Armijo wrote:
> >I wanted to get clarification from the WG on which error code
> >should be used when an operation with a critical control fails
> >due to an error within the control.
> >A simple example would be a failed critical VLV control (let's say
> >due to a missing Sort control).
> >The most obvious answer would be unavailableCriticalExtension (12),
> >but it is not explicitly defined for this condition on RFC 2251
> >(or in the Result Codes draft).
> 
> Yiks.  Actually, RFC 2251 has a typo.
>   s/unavailableCriticalExtension/unsupportedCriticialExtension/
> or
>   s/unsupportedCriticalExtension/unavailableCriticialExtension/
> 
> However, with either spelling, 12 should be used as indicated
> in 4.1.12.
> 
> I would suggest the return a different resultCode (which
> should be described by the control specification).   For
> a invalid controlValue, I suggest protocolError.



From list@netscape.com  Mon Jun  5 15:04:22 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08709
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 15:04:21 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55IwuW00630;
	Mon, 5 Jun 2000 11:58:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55J2sc16529;
	Mon, 5 Jun 2000 12:02:54 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 12:02:54 -0700 (PDT)
Message-Id: <3.0.5.32.20000605120230.009449e0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 05 Jun 2000 12:02:30 -0700
To: "Sukanta Ganguly" <SGANGULY@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
Cc: <leifj@it.su.se>, <ietf-ldapext@netscape.com>
In-Reply-To: <s93b94cf.012@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"PJ800C.A.1BE.bl_O5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:53 AM 6/5/00 -0600, Sukanta Ganguly wrote:
>Hi,
>  You folks state that IP fragmentation is not a issue with CLDAP.

It is an issue...  I argue that implementations should avoid
IP fragmentation but must be able to interoperate in the face
of IP fragmentation.

>Where would one have an implementation wherein the reliability
>that we expect from TCP could be taken care of?

Note that IP fragmentation occurs below TCP.  The IP deals with
the fragmentation/reassembly, not TCP.  TCP needs to be able to
retransmit lost whole IP datagrams.  It should, of course, avoid
IP fragmentation where possible.

Likewise, UDP doesn't see fragments.  It sees whole IP datagrams.
If the IP layer cannot reassemble, then the datagram is dropped
and UDP ignores it like it would any other dropped datagram.
CLDAP should avoid causing IP fragmentation and must deal with
lost, duplicated, and/or reordered of UDP datagrams.

>I guess I am having a difficult time understanding as to where would the UDP packet retransmissions in case of losses would be handled? There are many more to the related issue like packet re-ordering etc.

The CLDAP specification must specify the behavior of implementations
in face of lost, duplicated, and/or reordered whole UDP datagrams
irregardless of whether this is to handled at or above
CLDAP.  The current spec needs work here... it's rev 0 afterall.

>  If we do not have this in the Network layer (i.e. layer 3) then either the application needs to handle them, which would be another overhead that the LDAP server needs to handle/manage or the application clearly would not care for it.

Handling of such must be done by both peers, whether at, below, or
above the CLDAP layer.

> I can't imagine the case where in LDAP applications are ignorant to the fact that some of the data they send and receive may not actually come to them.

I can.  Data availability is not a constant.

>  I think there needs to be serious effort in addressing them as the CLDAP server implementors would have a great deal of heart burn implementing them.

s/server/client and server/   It's a two way street.

I do concur that CLDAP specification is a significant undertaking.






From list@netscape.com  Mon Jun  5 15:40:53 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09279
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 15:40:52 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55JVs103643;
	Mon, 5 Jun 2000 12:31:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55JdAk04612;
	Mon, 5 Jun 2000 12:39:10 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 12:39:10 -0700 (PDT)
Message-Id: <3.0.5.32.20000605123828.0092aae0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 05 Jun 2000 12:38:28 -0700
To: Bruce Greenblatt <bgreenblatt@directory-applications.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: SASL/EXTERNAL and CLDAP
Cc: Mark Wahl <M.Wahl@innosoft.com>, Leif Johansson <leifj@it.su.se>,
        ietf-ldapext@netscape.com
In-Reply-To: <4.3.1.0.20000605112941.00ade3d0@pop.walltech.com>
References: <3.0.5.32.20000605110519.009436e0@infidel.boolean.net>
 <13425.960226372@threadgill.austin.innosoft.com>
 <"Your message of Mon, 05 Jun 2000 09:28:45 PDT." <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"ynHcQ.A.sHB.cHAP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:31 AM 6/5/00 -0700, Bruce Greenblatt wrote:
>Why couldn't I write a draft titled "Using SASL/EXTERNAL mechanism in 
>connectionless protocols"?

SASL/EXTERNAL is a part of SASL.  SASL is designed for use
by application protocols which use connection oriented transports.
Though one can base a new framework for application protocols
which use connectionless transports, any Standard Track specification
for such must be complete.  Defining a connectionless SASL/EXTERNAL
without connectionless SASL makes no sense to me.  Anyways, such
work would likely be out of scope of CLDAP and LDAPext WG.

CLDAP must provide a secure authentication mechanism designed
for use with the intended transport.   In lieu of a general
framework supporting connectionless transports, I suggest a
simple, yet secure authentication choice be added.  However,
there may be other choices, I would suggest we consult the
Security Area folks for a recommendation in this area.



From list@netscape.com  Mon Jun  5 15:49:27 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09349
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 15:49:26 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55JhlW08123;
	Mon, 5 Jun 2000 12:43:47 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55Jlks10053;
	Mon, 5 Jun 2000 12:47:46 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 12:47:46 -0700 (PDT)
Message-Id: <3.0.5.32.20000605124742.00921200@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 05 Jun 2000 12:47:42 -0700
To: mcs@netscape.com (Mark C Smith)
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt
Cc: ietf-ldapext@netscape.com
In-Reply-To: <393BEDAD.AF04356C@netscape.com>
References: <200006011031.GAA18453@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"UFSfTB.A.rcC.gPAP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 02:13 PM 6/5/00 -0400, Mark C Smith wrote:
>It would also be valuable to provide a "scope" or "requirements"
>section.  For example, I think a useful CLDAP protocol could omit all of
>the update operations (keeping compare and search).

Note that standard track protocol with update operations need
a mandatory to implement secure authentication mechanism....
remove update operations, remove the requirement for secure
authentication...

I would agree with Mark that CLDAP would remain useful
without update operations.

Kurt



From list@netscape.com  Mon Jun  5 15:50:19 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09392
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 15:50:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55JfZ105649;
	Mon, 5 Jun 2000 12:41:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55Jmno10985;
	Mon, 5 Jun 2000 12:48:49 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 12:48:49 -0700 (PDT)
Date: Mon, 5 Jun 2000 12:47:44 -0700 (PDT)
From: "Booker C. Bense" <bbense@networking.stanford.edu>
To: Bruce Greenblatt <bgreenblatt@directory-applications.com>
cc: "Kurt D. Zeilenga" <Kurt@openldap.org>, Mark Wahl <M.Wahl@innosoft.com>,
        Leif Johansson <leifj@it.su.se>, ietf-ldapext@netscape.com
Subject: Re: SASL/EXTERNAL and CLDAP
In-Reply-To: <4.3.1.0.20000605112941.00ade3d0@pop.walltech.com>
Message-ID: <Pine.GSO.4.20.0006051215250.28130-100000@shred.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"VBIj2C.A.lqC.fQAP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

On Mon, 5 Jun 2000, Bruce Greenblatt wrote:

> At 11:05 AM 06/05/2000 -0700, Kurt D. Zeilenga wrote:
> >At 12:32 PM 6/5/00 -0500, Mark Wahl wrote:
> > >I would prefer that the SASL EXTERNAL mechanism be used to pick up the
> > >IPSEC credentials to the LDAP level, rather than a new protocol field.
> >
> >I agree that SASL/EXTERNAL can and should be used to pick lower
> >level credentials associated with connection.  Those credentials
> >can be provided by TLS, IPSEC, or other lower layer associated
> >with the connection.
> >
> >However, SASL (including SASL/EXTERNAL) cannot be used with
> >connectionless protocols, you must have a connection to use
> >SASL.  CLDAP should not overload/redefine any existing
> >authentication choice nor any specification of those choices.
> 
> 
> Why couldn't I write a draft titled "Using SASL/EXTERNAL mechanism in 
> connectionless protocols"?  As I read RFC 2222, it only says that it 
> defines how to use SASL over connection oriented protocols.  It doesn't 
> appear to say that there is no way to ever use SASL/EXTERNAL within UDP.
> 
> Bruce

- There are two essential "features" to SASL. The first is a means of
choosing authentication and the second is strictly defining what you
have to do successfully authenticate using that method. Both are
heavily dependent on the underlying notion of a "session" to provide
their security. While it might be possible to design a secure
"application profile" for a connectionless protocol, I can't see how
you could do without essentially duplicating the TCP stack. There are
just far too many assumptions inherent in SASL to just blindly 
apply the methods and assume you have done an adequate job of 
security.

- I certainly believe it is possible to have an authenticated
UDP based protocol, but I think you'd be much better off designing
it from scratch rather than attempting to jam one and only one
SASL method into it. 

- While I can certainly see the advantages of CLDAP, I think that
there needs to be a clearly defined scope of what you can and can't
do via the protocol. The application need as I see it is for searching
on at most a few fields and returning a brief answer. There is also
a need for authentication of some sort to allow access control. 
Data integrity and privacy would be useful, but will be very
complicated to implement. ( How do you build "session keys" in the
absence of a session?) The only model I know of that solves these
problems is the tgt service of kerberos, it does it by very strictly
limiting the kinds of requests you can make and the resulting answers
you will get. 
 
- Any attempt to duplicate the full range of ldap will essentially
require reimplementing TCP. A pointless exercise at best. 

- Booker c. Bense 




From list@netscape.com  Mon Jun  5 16:19:48 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09797
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 16:19:48 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55KEPW13488;
	Mon, 5 Jun 2000 13:14:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55KINE23700;
	Mon, 5 Jun 2000 13:18:23 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 13:18:23 -0700 (PDT)
Message-Id: <4.3.1.0.20000605132129.00ad9590@pop.walltech.com>
X-Sender: bgreenblatt@pop.walltech.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 05 Jun 2000 13:25:32 -0700
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject: Re: SASL/EXTERNAL and CLDAP
Cc: Mark Wahl <M.Wahl@innosoft.com>, Leif Johansson <leifj@it.su.se>,
        ietf-ldapext@netscape.com
In-Reply-To: <3.0.5.32.20000605123828.0092aae0@infidel.boolean.net>
References: <4.3.1.0.20000605112941.00ade3d0@pop.walltech.com>
 <3.0.5.32.20000605110519.009436e0@infidel.boolean.net>
 <13425.960226372@threadgill.austin.innosoft.com>
 <"Your message of Mon, 05 Jun 2000 09:28:45 PDT." <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"y5YZMB.A.8xF.OsAP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 12:38 PM 06/05/2000 -0700, Kurt D. Zeilenga wrote:
>At 11:31 AM 6/5/00 -0700, Bruce Greenblatt wrote:
> >Why couldn't I write a draft titled "Using SASL/EXTERNAL mechanism in
> >connectionless protocols"?
>
>SASL/EXTERNAL is a part of SASL.  SASL is designed for use
>by application protocols which use connection oriented transports.


Yes, I know that.  RFC 2222 (which defines SASL) doesn't say that you can't 
use it inside of UDP as Mark Wahl suggested.  It seems as if it would be 
straightforward to define the mechanism that would allow this to work in 
such a way that the SASL "pick(s) up the IPSEC credentials to the LDAP 
level".  SASL (i.e. RFC 2222) doesn't prevent this, it just doesn't define 
how it works.

Bruce


>Though one can base a new framework for application protocols
>which use connectionless transports, any Standard Track specification
>for such must be complete.  Defining a connectionless SASL/EXTERNAL
>without connectionless SASL makes no sense to me.  Anyways, such
>work would likely be out of scope of CLDAP and LDAPext WG.
>
>CLDAP must provide a secure authentication mechanism designed
>for use with the intended transport.   In lieu of a general
>framework supporting connectionless transports, I suggest a
>simple, yet secure authentication choice be added.  However,
>there may be other choices, I would suggest we consult the
>Security Area folks for a recommendation in this area.



From list@netscape.com  Mon Jun  5 18:46:46 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12147
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 18:46:46 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e55Mbj101528;
	Mon, 5 Jun 2000 15:37:45 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e55MUmA20540;
	Mon, 5 Jun 2000 15:30:48 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 15:30:48 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000606002040.03b7aef8@dokka.kvatro.no>
X-Sender: hta@dokka.maxware.no
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Jun 2000 00:27:42 +0200
To: Bruce Greenblatt <bgreenblatt@directory-applications.com>,
        "Kurt D. Zeilenga" <Kurt@openldap.org>
From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
Subject: Is CLDAP connectionless or not?
Cc: Mark Wahl <M.Wahl@innosoft.com>, Leif Johansson <leifj@it.su.se>,
        ietf-ldapext@netscape.com
In-Reply-To: <4.3.1.0.20000605132129.00ad9590@pop.walltech.com>
References: <3.0.5.32.20000605123828.0092aae0@infidel.boolean.net>
 <4.3.1.0.20000605112941.00ade3d0@pop.walltech.com>
 <3.0.5.32.20000605110519.009436e0@infidel.boolean.net>
 <13425.960226372@threadgill.austin.innosoft.com>
 <"Your message of Mon, 05 Jun 2000 09:28:45 PDT." <3.0.5.32.20000605092845.0095ae60@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"o4HvOB.A.wAF.WoCP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I think the SASL debate actually evolves out of a deeper problem with the 
CLDAP draft itself:

Is it a specification for running an LDAP session over UDP, or is it a 
specification for running LDAP queries in connectionless mode?

In the first case, the spec is incomplete; it needs to essentially rebuild 
all of TCP's machinery in order to get reliably delivered requests and 
responses.
(Perhaps it wants to use SCTP?)
But the server has to remember which clients are connected; thus, it can 
use SASL.

In the second case, the spec is incomplete, because it needs to guard 
against weird stuff like mismatching responses from old queries with new 
responses, and it needs to pick at least one mandatory-to-implement 
security mechanism if it's going to be applicable to anything but Read.
The server can then just reply to a request and forget about it, saving 
gobs of time by not having state information, just like the DNS does.
But it can't use SASL.

                                Harald


--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no



From list@netscape.com  Mon Jun  5 23:08:01 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15751
	for <ldapext-archive@odin.ietf.org>; Mon, 5 Jun 2000 23:08:00 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e562GEW26080;
	Mon, 5 Jun 2000 19:16:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e562JXw24278;
	Mon, 5 Jun 2000 19:19:33 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 19:19:33 -0700 (PDT)
Date: Mon, 5 Jun 2000 19:18:54 -0700 (PDT)
Message-Id: <200006060218.e562Is918116@xwing.netscape.com>
From: WasSkeptical@hotmail.com
To: @netscape.com
Subject:  Have Some Fun (and maybe make some money)
X-Reply-To:  Anyone@hotmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"kgK5QC.A.46F.q-FP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

(You were referred to me as someone who has expressed an interest in 
being offered opportunities.  If this message has reached you by mistake, please 
forgive the intrusion.)

ReferEveryone has started. IT'S FREE! You can make real money in it!  The
number one spot is going to have 1 million people in his downline in 180
days. It has already been two weeks and he is well on his way!! Why do those 1
million effect you? Because it is a 3x10 FORCED Matrix!! You can get paid a
small amount on everyone in your 3x10 matrix, as well as a bonus on everyone
you personally sponsor. The #1 guy in the company, sent an ad to 550
people. Over 100 of them signed up right then! NOW is your chance!

My sponsor has been in for 2 weeks and has over 400 in his downline! Just
sponsor 1 or 2 friends and your 3x10 matrix will fill up in REAL TIME on
your personal account webpage!! You have over 89,000 spots available! If you
earn only $1 on each member (you earn money when your downline buys products
that EVERYONE will want!) $1 a month per member, would be over one million a
year. But don't even worry about the millions, if you had 1000 members in
your downline, would you be happy with an extra $10,000 a year? That would
pay anyones extra bills!

The company has just announced their MAIN product!  It is smaller than a pack of 
cigarettes and can be connected anywhere to a phone line to provide long distance 
service at 3.3 cents per minute!   It is the best price ANYWHERE and every 
household will be buying one. Commissions will be about $6 on each level!! Plus a 
$30 referral fee!  In addition, they are completing their tie-in with a major jewelry 
web site that has over 24,000 pieces at 10% over manufacturers' cost.  This site 
would make your local jeweler jealous, and if you want to, you can sign him up in 
your downline and let him buy from the site!  (There will be many more such great 
bargains offered to members in the near future.)

Why get in now? The grandfather clause. If you get in within the next day or
two, you will be grandfathered in and you won't need to sponsor anyone to
qualify for commissions on your DOWNLINE! Now is the time to act! Go to
http://www.refereveryone.com/id/ab1813 and sign up and get ready to earn
money!  (It's so easy, it takes less than 2 minutes to sign up.)





From list@netscape.com  Tue Jun  6 04:41:07 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29938
	for <ldapext-archive@odin.ietf.org>; Tue, 6 Jun 2000 04:41:06 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e568R0113046;
	Tue, 6 Jun 2000 01:27:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e566UtQ28305;
	Mon, 5 Jun 2000 23:30:55 -0700 (PDT)
Resent-Date: Mon, 5 Jun 2000 23:30:55 -0700 (PDT)
Message-Id: <200006060630.IAA20874@mail.su.se>
X-Mailer: exmh version 2.1.1 10/15/1999
To: mcs@netscape.com (Mark C Smith)
cc: ietf-ldapext@netscape.com
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt 
In-Reply-To: Message from mcs@netscape.com (Mark C Smith) 
   of "Mon, 05 Jun 2000 14:13:01 EDT." <393BEDAD.AF04356C@netscape.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 06 Jun 2000 08:25:52 +0200
From: Leif Johansson <leifj@it.su.se>
Resent-Message-ID: <"45JIMC.A.55G.dqJP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

> Internet-Drafts@ietf.org wrote:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the LDAP Extension Working Group of the IETF.
> > 
> >         Title           : Connection-less Lightweight Directory Access Protocol
> >         Author(s)       : L. Johasson, R. Hedberg
> >         Filename        : draft-ietf-ldapext-cldap-00.txt
> >         Pages           : 10
> >         Date            : 31-May-00
> 
> Section 3 says:
> 
>    ... Note that it is
>    possible for a client to issue a modifying request (add, delete,
>    moddn, modify) together with a control or an extended request which
>    modifies the directory such that the response is too large to fit in
>    a datagram which would make it impossible for the client to know if
>    the requested operation was successful or not. For this reason
>    servers implementing this protocol must respond with an error of
>    unwillingToPerform(53) if such a request is received.
> 
> Does the above mean that a server must determine the size of a response
> before it actually carries it out?  That might be tricky to implement.
> 

No, the server can just choose to refuse to serve anything containing a
control in a modifying request or it can implement something that would
"guess" the size of the reply in some way.

> Also, I'd prefer to see a more specific error introduced for this case
> (or just use resultsTooLarge).  An unwillingToPerform error may be
> returned for other reasons, and it would be nice to unambiguously tell
> the client "This can't be done over UDP, please try again over TCP."  In
> fact, I'd like to see the client's recommended behavior with respect to
> error recovery and use of LDAP over TCP (when a CLDAP request fails)
> spelled out in the draft.

Good point, I agree. The recommended client behaviour of fallback to TCP
you indicate is indeed the one we were thinking about and that will need
to be stated more explicitly.


> 
> It would also be valuable to provide a "scope" or "requirements"
> section.  For example, I think a useful CLDAP protocol could omit all of
> the update operations (keeping compare and search).

Yes, why not.

> 
> -- 
> Mark Smith
> Directory Product Development / iPlanet E-Commerce Solutions
> My words are my own, not my employer's.            Got LDAP?
> 




From list@netscape.com  Tue Jun  6 05:41:54 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00328
	for <ldapext-archive@odin.ietf.org>; Tue, 6 Jun 2000 05:41:50 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e569ZxM06442;
	Tue, 6 Jun 2000 02:35:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e569dvc07036;
	Tue, 6 Jun 2000 02:39:57 -0700 (PDT)
Resent-Date: Tue, 6 Jun 2000 02:39:57 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000606112536.037ade10@dokka.kvatro.no>
X-Sender: hta@dokka.maxware.no
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Jun 2000 11:37:25 +0200
To: Leif Johansson <leifj@it.su.se>, mcs@netscape.com (Mark C Smith)
From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt 
Cc: ietf-ldapext@netscape.com
In-Reply-To: <200006060630.IAA20874@mail.su.se>
References: <Message from mcs@netscape.com (Mark C Smith)  of "Mon, 05 Jun 2000 14:13:01 EDT." <393BEDAD.AF04356C@netscape.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"a6Xd3.A.ktB.sbMP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

FWIW, I think the approach of "just" embedding raw LDAP requests in UDP 
packets is wrong; it offers too little support for solving the problems 
noted here.

A better approach would be to update RFC 1798, and include 3 parts in the 
UDP packet:

- A "wrapper" function
- A "control information" block, which could be used for security, 
authentication or just sequence numbers
- An LDAP request or response

It's no accident that this is almost exactly what SNMP does!
I'd like to structure the document set like this:

- A basic standard describing the wrapper, an extremely primitive control
   info block (basically just enough to correlate requests with responses
   reliably), a basic retransmission strategy, and a basic profile saying
   "if you use this simple stuff, only use Search, and expect to be spoofed".

- An extension that describes how to do an adequate security layer (whether
   it's IPSec, SASL-with-secure-session-ID, or something else), how to achieve
   at-most-once semantics for update operations, and an extended
   profile saying "it makes sense to do almost any LDAP operation with this".

This should achieve the goal of making the document the current authors 
want out the door short and easy to write, while not painting ourselves 
into a corner we don't want to be in.

                      Harald


--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no



From list@netscape.com  Tue Jun  6 06:07:00 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00456
	for <ldapext-archive@odin.ietf.org>; Tue, 6 Jun 2000 06:06:59 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e56A04M10882;
	Tue, 6 Jun 2000 03:00:06 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e568CPE13856;
	Tue, 6 Jun 2000 01:12:25 -0700 (PDT)
Resent-Date: Tue, 6 Jun 2000 01:12:25 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000606100122.02ebfbc0@dokka.kvatro.no>
X-Sender: hta@dokka.maxware.no
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Jun 2000 10:09:28 +0200
To: Leif Johansson <leifj@it.su.se>
From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
Subject: Re: Is CLDAP connectionless or not? 
Cc: Bruce Greenblatt <bgreenblatt@directory-applications.com>,
        "Kurt D. Zeilenga" <Kurt@openldap.org>,
        Mark Wahl <M.Wahl@innosoft.com>, ietf-ldapext@netscape.com
In-Reply-To: <200006060717.JAA24121@mail.su.se>
References: <Message from Harald Tveit Alvestrand <Harald@Alvestrand.no>
 <4.3.2.7.2.20000606002040.03b7aef8@dokka.kvatro.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"2CoXd.A.GYD.nJLP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 09:12 06.06.2000 +0200, Leif Johansson wrote:
> > I think the SASL debate actually evolves out of a deeper problem with the
> > CLDAP draft itself:
> >
> > Is it a specification for running an LDAP session over UDP, or is it a
> > specification for running LDAP queries in connectionless mode?
> >
>
>Both and none. In order to be able to use read with access-control you need,
>as someone already pointed out, to be able to identify a session, defined by
>a completed bind which does require something beyond what is provided in the
>draft. For anonymous reads the situation is different.

Then I think we need to be able to tell the difference between the two modes.
And even with anonymous reads, there should be a reason why the client 
trusts the answers from the server.
(The DNS, as currently deployed, has the request ID as its sole "security". 
It's just slightly more than nothing, and clearly not Good Enough.)

Also, if you have a "session" that is entirely unprotected against 
insert/remove attacks, you have a security problem.
Imagine someone inserting extra replies into your search result, for instance.

                  Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no



From list@netscape.com  Tue Jun  6 07:34:22 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01117
	for <ldapext-archive@odin.ietf.org>; Tue, 6 Jun 2000 07:34:21 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e56BSo823845;
	Tue, 6 Jun 2000 04:28:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e567HbQ05987;
	Tue, 6 Jun 2000 00:17:37 -0700 (PDT)
Resent-Date: Tue, 6 Jun 2000 00:17:37 -0700 (PDT)
Message-Id: <200006060717.JAA24121@mail.su.se>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Harald Tveit Alvestrand <Harald@Alvestrand.no>
cc: Bruce Greenblatt <bgreenblatt@directory-applications.com>,
        "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        Mark Wahl <M.Wahl@innosoft.com>, ietf-ldapext@netscape.com
Subject: Re: Is CLDAP connectionless or not? 
In-Reply-To: Message from Harald Tveit Alvestrand <Harald@Alvestrand.no> 
   of "Tue, 06 Jun 2000 00:27:42 +0200." <4.3.2.7.2.20000606002040.03b7aef8@dokka.kvatro.no> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Tue, 06 Jun 2000 09:12:24 +0200
From: Leif Johansson <leifj@it.su.se>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e567HZP05957
Resent-Message-ID: <"nwWro.A.LdB.QWKP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit


> I think the SASL debate actually evolves out of a deeper problem with the 
> CLDAP draft itself:
> 
> Is it a specification for running an LDAP session over UDP, or is it a 
> specification for running LDAP queries in connectionless mode?
> 

Both and none. In order to be able to use read with access-control you need,
as someone already pointed out, to be able to identify a session, defined by
a completed bind which does require something beyond what is provided in the
draft. For anonymous reads the situation is different.

You may not care about reordering of packets in a search response -- the 
searchResultDone packet might be uninteresting for an application where
results not returned within a very short time are dropped anyway -- or even, 
heaven forbid, about loss of packets in a search response. Some applications 
may care to get a reply back from modify-operations :-) This is imho best 
handled with a set of controls and/or exops. 

For instance if you really care about getting all your search responses in 
the right order you can either (sketching here so please forgive some 
handwaving) add a control with a sequence number or create an exop response 
which contained a SEQUENCE OF ldap pdu's. Which is better? I don't know.
Does it absolutely have to go into this draft? I hope not :-)

> In the first case, the spec is incomplete; it needs to essentially rebuild 
> all of TCP's machinery in order to get reliably delivered requests and 
> responses.

Not all of it. Reordering may not be an issue, packet loss may not be an 
issue. An extra set of controls could be considered a tool for selecting which 
aspects
of a full connection is interesting to the application. Having said that I 
absolutely agree that if we get close to finding ourselves implementing tcp
in LDAP/UDP to get basic functionality the project must be dropped.

	Cheers Leif




From list@netscape.com  Tue Jun  6 10:48:31 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08950
	for <ldapext-archive@odin.ietf.org>; Tue, 6 Jun 2000 10:48:30 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e56EdjO03637;
	Tue, 6 Jun 2000 07:39:45 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e56El1I22272;
	Tue, 6 Jun 2000 07:47:01 -0700 (PDT)
Resent-Date: Tue, 6 Jun 2000 07:47:01 -0700 (PDT)
Message-Id: <200006061446.QAA06069@mail.su.se>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Harald Tveit Alvestrand <Harald@Alvestrand.no>
cc: ietf-ldapext@netscape.com
Subject: Re: I-D ACTION:draft-ietf-ldapext-cldap-00.txt 
In-Reply-To: Message from Harald Tveit Alvestrand <Harald@Alvestrand.no> 
   of "Tue, 06 Jun 2000 15:41:05 +0200." <4.3.2.7.2.20000606153629.0bded9e8@dokka.kvatro.no> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Tue, 06 Jun 2000 16:41:55 +0200
From: Leif Johansson <leifj@it.su.se>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e56EkxP22240
Resent-Message-ID: <"3d4PaB.A.mbF.j7QP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit



> I'd rather make it
> 
> SEQUENCE {
>     controls SEQUENCE {
>          requestID INTEGER,
>          ...  -- note - "extensible" is a 97-ism
>     }
>     CHOICE {
>        [0] LDAPRequest
>        [1] LDAPResponse
>     }
> }
> if that's simpler.

Hmmm, and this is different from LDAPMessage how? I thought you wanted to 
compress sessions where multiple responses are returned by stuffing them
in one PDU. Is there a SEQUENCE missing from the above somewhere? Or are
you "only" looking at session management? In the latter case I also don't
see how this is based on 1789 which is _all_ about multiple PDUs (search-
results actually) in one datagram.

> 
> you mean give people rope enough to hang themselves in 15 different ways? :-)
> 

Absolutely :-) But seriously, some might actually learn not to. 

	Cheers Leif



From list@netscape.com  Wed Jun  7 02:19:00 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07226
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 02:19:00 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e576ADO18282;
	Tue, 6 Jun 2000 23:10:13 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e576HU207178;
	Tue, 6 Jun 2000 23:17:30 -0700 (PDT)
Resent-Date: Tue, 6 Jun 2000 23:17:30 -0700 (PDT)
Message-Id: <s93d8f32.065@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 06 Jun 2000 23:44:39 -0600
From: "Haripriya S" <SHARIPRIYA@novell.com>
To: "<"<ietf-ldapext@netscape.com>
Subject: Query on RFC 2252
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e576HR107130
Resent-Message-ID: <"Ui9OmD.A.gvB.4jeP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

In RFC 2252 definition of Content Rule, there is a "NOT" oid. Is this NOT definition inherited to subclasses of the structural object class corresponding to the content rule? That is, can a subclass override it with a MUST or MAY for the same oid?

Thanks
Haripriya



From list@netscape.com  Wed Jun  7 02:58:55 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07341
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 02:58:55 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e576rVw16699;
	Tue, 6 Jun 2000 23:53:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e576vUM15419;
	Tue, 6 Jun 2000 23:57:30 -0700 (PDT)
Resent-Date: Tue, 6 Jun 2000 23:57:30 -0700 (PDT)
From: Martin.Rahm@nokia.com
Message-ID: <453FD4452B6CD311A95F0008C7731DCD02D93419@eseis10nok>
To: ietf-ldapext@netscape.com
Subject: Intense LDAP write operations
Date: Wed, 7 Jun 2000 09:57:21 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"tGrOkD.A.jwD.YJfP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm



From list@netscape.com  Wed Jun  7 03:19:36 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07457
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 03:19:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e577E3w18886;
	Wed, 7 Jun 2000 00:14:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e577I2I20406;
	Wed, 7 Jun 2000 00:18:02 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 00:18:02 -0700 (PDT)
Message-Id: <200006070717.JAA32471@mail.su.se>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Martin.Rahm@nokia.com
cc: ietf-ldapext@netscape.com
Subject: Re: Intense LDAP write operations 
In-Reply-To: Message from Martin.Rahm@nokia.com 
   of "Wed, 07 Jun 2000 09:57:21 +0300." <453FD4452B6CD311A95F0008C7731DCD02D93419@eseis10nok> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 Jun 2000 09:12:17 +0200
From: Leif Johansson <leifj@it.su.se>
Resent-Message-ID: <"wgIznC.A.T-E.ocfP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


> Hi,
> 
> I am working on a problem where LDAP would be used to keep a directory with
> user data.  One concern I have is that LDAP is supposed to be less efficient
> when it comes to intense write operations.
> 
> Can LDAP handle millions of users data in a directory where some of the data
> (a few attributes) needs to be updated very frequently?  How would that
> affect performance and is LDAP effective when the searched data must be
> returned prompty with very little delay?
> 
> If anyone has any comments on this, I would appreciate it,
> 
> Martin Rahm
> 

I can't see any reason why there should be any inherent performance hit on
writes in LDAP. The reason why most servers are slow on writes is that they
update indexes for each write operation.

	Cheers Leif



From list@netscape.com  Wed Jun  7 03:44:30 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07571
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 03:44:30 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e577dCw20717;
	Wed, 7 Jun 2000 00:39:12 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e577hBM26266;
	Wed, 7 Jun 2000 00:43:11 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 00:43:11 -0700 (PDT)
From: Martin.Rahm@nokia.com
Message-ID: <453FD4452B6CD311A95F0008C7731DCD02D9341C@eseis10nok>
To: leifj@it.su.se
Cc: ietf-ldapext@netscape.com
Subject: RE: Intense LDAP write operations 
Date: Wed, 7 Jun 2000 10:42:21 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"LmXZlC.A._ZG.O0fP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

>> Hi,
>> 
>> I am working on a problem where LDAP would be used to keep a 
>directory with user data.  One concern I have is that LDAP is supposed to 
>be less efficient when it comes to intense write operations.
>> 
>> Can LDAP handle millions of users data in a directory where some of the
data
>> (a few attributes) needs to be updated very frequently?  How would that
>> affect performance and is LDAP effective when the searched data must be
>> returned promptly with very little delay?
>> 
>> If anyone has any comments on this, I would appreciate it,



>I can't see any reason why there should be any inherent 
>performance hit on writes in LDAP. The reason why most servers are slow on
>writes is that they update indexes for each write operation.
>
>	Cheers Leif

Leif et al,

Is that index update done also when the attribute of an object is only
changed or can that be by-passed when the data is only altered and no
changes are made to the structure of the directory?  If it is possible,
would by-passing the index update make the write operation faster?

mvh,

Martin



From list@netscape.com  Wed Jun  7 03:56:27 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07634
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 03:56:26 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e577oow21631;
	Wed, 7 Jun 2000 00:50:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e577snA28504;
	Wed, 7 Jun 2000 00:54:49 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 00:54:49 -0700 (PDT)
Sender: Ludovic.Poitou@france.Sun.COM
Message-ID: <393DFF5A.6E373AFF@France.sun.com>
Date: Wed, 07 Jun 2000 09:52:58 +0200
From: Ludovic Poitou <ludovic.poitou@france.Sun.COM>
Organization: Sun Microsystems Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin.Rahm@nokia.com
CC: leifj@it.su.se, ietf-ldapext@netscape.com
Subject: Re: Intense LDAP write operations
References: <453FD4452B6CD311A95F0008C7731DCD02D9341C@eseis10nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"z7Tzb.A.A9G.I_fP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Martin.Rahm@nokia.com wrote:

> >> Hi,
> >>
> >> I am working on a problem where LDAP would be used to keep a
> >directory with user data.  One concern I have is that LDAP is supposed to
> >be less efficient when it comes to intense write operations.
> >>
> >> Can LDAP handle millions of users data in a directory where some of the
> data
> >> (a few attributes) needs to be updated very frequently?  How would that
> >> affect performance and is LDAP effective when the searched data must be
> >> returned promptly with very little delay?
> >>
> >> If anyone has any comments on this, I would appreciate it,
>
> >I can't see any reason why there should be any inherent
> >performance hit on writes in LDAP. The reason why most servers are slow on
> >writes is that they update indexes for each write operation.
> >
> >       Cheers Leif
>
> Leif et al,
>
> Is that index update done also when the attribute of an object is only
> changed or can that be by-passed when the data is only altered and no
> changes are made to the structure of the directory?  If it is possible,
> would by-passing the index update make the write operation faster?
>

The index update usually only occurs when an attribute is modified and this
attribute is indexed.

You need to index attributes when they appear very often in search filters.
This improves the search performances but reduces the modification
performances (when the attribute indexed is present in the modification).

Regards,

Ludovic.

> mvh,
>
> Martin

--
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France





From list@netscape.com  Wed Jun  7 03:59:52 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07668
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 03:59:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e577oxO25633;
	Wed, 7 Jun 2000 00:51:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e577wH229707;
	Wed, 7 Jun 2000 00:58:17 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 00:58:17 -0700 (PDT)
Message-Id: <s93da30d.094@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 07 Jun 2000 01:14:56 -0600
From: "Subbu K. k." <KKSUBRAMANIAM@novell.com>
To: <ietf-ldapext@netscape.com>, <Martin.Rahm@nokia.com>
Subject: Re: Intense LDAP write operations
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-7
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e577wF129664
Resent-Message-ID: <"BCSMO.A.pPH.YCgP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

I dont think this was the sweet spot planned for directories. Writes would entail applying locks on the data store which would impact the regular search, retrieval and any sync operations. You also need to deal with atomicity of updates to the group of attributes and the latency of propagation of changes across multiple copies of the data store. A transactional database may be a better choice.

Are you sure you need a directory service and not a transactional database engine that supports LDAP in addition to SQL?

Subbu K. K
Ż---------------------------------------------
K. K. Subramaniam
Product Manager, Novell Directory Services (UNIX)
Novell

>>> <Martin.Rahm@nokia.com> 06/07/00 12:27PM >>>
Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm




From list@netscape.com  Wed Jun  7 04:07:10 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07759
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 04:07:09 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5780Cw22955;
	Wed, 7 Jun 2000 01:00:12 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5784Cg03081;
	Wed, 7 Jun 2000 01:04:12 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 01:04:12 -0700 (PDT)
Message-ID: <004401bfd056$86b13af0$924cb183@tkklpr.tele.fi>
From: "Ismo Heikkonen" <ismo.heikkonen@sonera.com>
To: <Martin.Rahm@nokia.com>, <ietf-ldapext@netscape.com>
References: <453FD4452B6CD311A95F0008C7731DCD02D93419@eseis10nok>
Subject: Re: Intense LDAP write operations
Date: Wed, 7 Jun 2000 11:01:02 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by smtp.dave.sonera.fi id LAA12949
Resent-Message-ID: <"pUutlC.A.tv.6HgP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

because LDAP is just an interface to the directory, the performance
of  LDAP server is up to the quality of the server implementation
used. 
LDAP does not define any database structure or indexing technologies
to be used;
each vendor can design these items quite freely. 
The LDAP protocol itself is quite efficient, comparable with any
other protocol
you run over TCP layer.
So by selecting or building efficient LDAP server where the need for
intense 
write operations has been taken into account, it is a reasonable
solution.

Ismo

- ----- Original Message ----- 
From: <Martin.Rahm@nokia.com>
To: <ietf-ldapext@netscape.com>
Sent: Wednesday, June 07, 2000 9:57 AM
Subject: Intense LDAP write operations


Hi,

I am working on a problem where LDAP would be used to keep a
directory with
user data.  One concern I have is that LDAP is supposed to be less
efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of
the data
(a few attributes) needs to be updated very frequently?  How would
that
affect performance and is LDAP effective when the searched data must
be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1 Int.

iQA/AwUBOT3lHuqdT0kbnEDTEQIlgACfeL4KcJJISdVwBoVy8ruu5Dv9MYQAoNsu
xxZT4wVfzliBmncQBGt7FirV
=Eh3f
-----END PGP SIGNATURE-----




From list@netscape.com  Wed Jun  7 06:10:52 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08434
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 06:10:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57A5Gw00527;
	Wed, 7 Jun 2000 03:05:16 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57A9FE29928;
	Wed, 7 Jun 2000 03:09:15 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 03:09:15 -0700 (PDT)
From: hahnt@us.ibm.com
X-Priority: 3 (Normal)
Importance: Normal
To: ietf-ldapext@netscape.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF42325A51.A3C8A37F-ON852568F7.00336427@pok.ibm.com>
Date: Wed, 7 Jun 2000 05:21:20 -0400
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.3 (Intl)|17 May 2000) at
 07/06/2000 06:09:10 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Resent-Message-ID: <"ou1xWB.A.OTH.J9hP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
Subject: Unidentified subject!
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Greetings,

In general, due to the wide variety of database engine implementations on
which different LDAP
directories are based, it is safe to say that 'your mileage may vary'.  As
everyone has indicated,
update performance is related to all the extra things a directory server
might do as a result
of the modify operation.  What these things are is dependent upon the
underlying database
implementation upon which the directory is based.

Thus, some existing implementations may offer fast update performance while
others may not.

> Hi,
>
> I am working on a problem where LDAP would be used to keep a directory
with
> user data.  One concern I have is that LDAP is supposed to be less
efficient
> when it comes to intense write operations.
>
> Can LDAP handle millions of users data in a directory where some of the
data
> (a few attributes) needs to be updated very frequently?  How would that
> affect performance and is LDAP effective when the searched data must be
> returned prompty with very little delay?
>
> If anyone has any comments on this, I would appreciate it,
>
> Martin Rahm

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



From list@netscape.com  Wed Jun  7 07:32:37 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09179
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 07:32:36 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57BQww05416;
	Wed, 7 Jun 2000 04:26:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57BUwo14787;
	Wed, 7 Jun 2000 04:30:58 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 04:30:58 -0700 (PDT)
Reply-To: <kfenley@ozemail.com.au>
From: "Kim Fenley" <kfenley@ozemail.com.au>
To: <hahnt@us.ibm.com>, <ietf-ldapext@netscape.com>
Subject: RE: Unidentified subject! LDAP search times and databases
Date: Thu, 8 Jun 2000 09:37:27 +1000
Message-ID: <NEBBLECJGLMAGGDFLPDOAENDCAAA.kfenley@ozemail.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <OF42325A51.A3C8A37F-ON852568F7.00336427@pok.ibm.com>
Importance: Normal
Resent-Message-ID: <"9AFjFC.A.nmD.wJjP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Martin

More on Tim Hahn comments.


There are many factors that will influence the search times on LDAP
Directories.

The Database its self - here many are built on a proprietary DB and so not
as well developed as are the industrial strength Dabs.

Then there is the issue of indexing of Attributes.  The more Attributes
indexed the faster the search, but there are drawback in other areas and are
dependent on how the Directory is structured.  A lot can't index all
Attributes as it has a server performance impact.

Next is the fact that many directories requests to the backend DB are via
SQL, which requires row and column search.  This is probably the most
limiting factor.  The larger the number of entries the slower the search.

When you combine all these different factors together you end up with poor
search times.  Many vendors now run schema in memory to increase search
performance and large hardware platforms to make up for the poor performance
of the Directory engine.  This leads to other issues of data integrity and
robustness if power is lost, caching of schema in and out of memory - some
systems seem to stop with this happens.

I know one only one LDAP Directory that overcomes all these issues and runs
on an industrial strength backend DB which provides predictable sub-second
searches, full rollback, auditing and logging and has 30+ patents on the use
of a RDBMS for Directories.  This is why the other vendors who use RDMBS
technology are unable to compete, as they have to use standard SQL calls.
The Patents cover how you use a standard RDBMS as an OO D/B without the SQL
row and Column problem and this is where the high search times from a RDBMS
come from.  It also does both Distribution and Replication, load sharing and
support millions of concurrent user accesses over 100's of millions of
entries.

The Computer Associates - eTrust Directory (formally (OpenDirectory).  Its
the only truly Distributed operational Directory and is an infrastructure
Directory, not a Desktop solution or network or address book derived
Directory.  Its been replacing LDAP Server technology in Banks and Carriers
sectors where performance, failover, scalability, reliability, robustness,
fully indexed Attributes and 1000s of searches per second of a  predictable
nature.  Have a look at:

www.opendirectory.com.au

Kim





-----Original Message-----
From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com]
Sent: Wednesday, 7 June 2000 7:21 PM
To: ietf-ldapext@netscape.com
Subject: Unidentified subject!


Greetings,

In general, due to the wide variety of database engine implementations on
which different LDAP
directories are based, it is safe to say that 'your mileage may vary'.  As
everyone has indicated,
update performance is related to all the extra things a directory server
might do as a result
of the modify operation.  What these things are is dependent upon the
underlying database
implementation upon which the directory is based.

Thus, some existing implementations may offer fast update performance while
others may not.

> Hi,
>
> I am working on a problem where LDAP would be used to keep a directory
with
> user data.  One concern I have is that LDAP is supposed to be less
efficient
> when it comes to intense write operations.
>
> Can LDAP handle millions of users data in a directory where some of the
data
> (a few attributes) needs to be updated very frequently?  How would that
> affect performance and is LDAP effective when the searched data must be
> returned prompty with very little delay?
>
> If anyone has any comments on this, I would appreciate it,
>
> Martin Rahm

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681




From list@netscape.com  Wed Jun  7 10:11:27 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10821
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 10:11:27 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57E1RO17787;
	Wed, 7 Jun 2000 07:01:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57E8jY21747;
	Wed, 7 Jun 2000 07:08:45 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 07:08:45 -0700 (PDT)
Sender: rsalz@xwing.netscape.com
Message-ID: <393E5743.F7ECFFCB@caveosystems.com>
Date: Wed, 07 Jun 2000 10:08:03 -0400
From: Rich Salz <rsalz@caveosystems.com>
Organization: Caveo Systems, LLC
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin.Rahm@nokia.com
CC: ietf-ldapext@netscape.com
Subject: Re: Intense LDAP write operations
References: <453FD4452B6CD311A95F0008C7731DCD02D93419@eseis10nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
Resent-Message-ID: <"4Xd5Z.A.XTF.qdlP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

> One concern I have is that LDAP is supposed to be less efficient
> when it comes to intense write operations.

There is nothing intrinsic to the LDAP specifications that make writes less
efficient.

The answer to your question will completely depend upon the quality of the
server
that you use.  Speak to your vendor(s).
	/r$



From list@netscape.com  Wed Jun  7 11:19:25 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12737
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 11:19:24 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57FD7w24075;
	Wed, 7 Jun 2000 08:13:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57FCIU12803;
	Wed, 7 Jun 2000 08:12:18 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 08:12:18 -0700 (PDT)
Message-Id: <3.0.5.32.20000607081111.009437a0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 07 Jun 2000 08:11:11 -0700
To: Rich Salz <rsalz@caveosystems.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: Intense LDAP write operations
Cc: Martin.Rahm@nokia.com, ietf-ldapext@netscape.com
In-Reply-To: <393E5743.F7ECFFCB@caveosystems.com>
References: <453FD4452B6CD311A95F0008C7731DCD02D93419@eseis10nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"-HT_S.A.hDD.-YmP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 10:08 AM 6/7/00 -0400, Rich Salz wrote:
>> One concern I have is that LDAP is supposed to be less efficient
>> when it comes to intense write operations.
>
>There is nothing intrinsic to the LDAP specifications that make writes less
>efficient.

I concur.  However, LDAP does not offer a number of other
features, such as client/server transactions, which might
be needed.

When folks start talking about intense write operations,
I generally refer them to Tim Howes' article "LDAP: Use
as Directed" <http://www.data.com/issue/990207/ldap.html>.
  "LDAP isn't a replacement for relational databases
  (and never will be)."

Kurt



From list@netscape.com  Wed Jun  7 11:31:28 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13254
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 11:31:27 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57FQ5w25820;
	Wed, 7 Jun 2000 08:26:05 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57FU4E18625;
	Wed, 7 Jun 2000 08:30:04 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 08:30:04 -0700 (PDT)
Message-ID: <4C71A343EBC6D311B9E1006008360637059FB0@ENABLEMAILSRV>
From: TGullotta@access360.com
To: KKSUBRAMANIAM@novell.com, ietf-ldapext@netscape.com, Martin.Rahm@nokia.com
Subject: RE: Intense LDAP write operations
Date: Wed, 7 Jun 2000 08:38:49 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-7"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e57FU2118585
Resent-Message-ID: <"sQKSfC.A.fiE.6pmP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Subbu,

Has Novell done any benchmarks on read vs. write operations? It seems that
in a lot of directory implementations, although not every entry is being
updated that frequently, if you have a million or so users, just periodic
updates to entries could add up when you look at the total number of users.
I would think this is realistic. Is it a problem with NDS?

Tony Gullotta
Lead System Architect
access360


-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com]
Sent: Wednesday, June 07, 2000 12:15 AM
To: ietf-ldapext@netscape.com; Martin.Rahm@nokia.com
Subject: Re: Intense LDAP write operations


I dont think this was the sweet spot planned for directories. Writes would
entail applying locks on the data store which would impact the regular
search, retrieval and any sync operations. You also need to deal with
atomicity of updates to the group of attributes and the latency of
propagation of changes across multiple copies of the data store. A
transactional database may be a better choice.

Are you sure you need a directory service and not a transactional database
engine that supports LDAP in addition to SQL?

Subbu K. K
Ż---------------------------------------------
K. K. Subramaniam
Product Manager, Novell Directory Services (UNIX)
Novell

>>> <Martin.Rahm@nokia.com> 06/07/00 12:27PM >>>
Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm



From list@netscape.com  Wed Jun  7 13:42:02 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16930
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 13:42:02 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57HXRO13224;
	Wed, 7 Jun 2000 10:33:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57HekM29199;
	Wed, 7 Jun 2000 10:40:46 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 10:40:46 -0700 (PDT)
Message-ID: <438D12915E64D2118AB10000F8C1C078034023D9@zcard00e.ca.nortel.com>
From: "James Benedict" <grunt@nortelnetworks.com>
To: "Kurt D. Zeilenga" <Kurt@openldap.org>, Rich Salz <rsalz@caveosystems.com>
Cc: Martin.Rahm@nokia.com, ietf-ldapext@netscape.com
Subject: RE: Intense LDAP write operations
Date: Wed, 7 Jun 2000 13:39:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD0A7.53739DA8"
Resent-Message-ID: <"_Lw5OD.A.zHH.ckoP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFD0A7.53739DA8
Content-Type: text/plain;
	charset="ISO-8859-1"

I also agree.  However, there may be issues related to replication, whether
LDUP or proprietary, that may affect an LDAP server's overall efficiciency
for intense writes.  For instance: replication delay adds an additional
delay between the time an entry is updated and the time that update becomes
fully visible.

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, June 07, 2000 11:11 AM
> To: Rich Salz
> Cc: Martin.Rahm@nokia.com; ietf-ldapext@netscape.com
> Subject: Re: Intense LDAP write operations
> 
> 
> At 10:08 AM 6/7/00 -0400, Rich Salz wrote:
> >> One concern I have is that LDAP is supposed to be less efficient
> >> when it comes to intense write operations.
> >
> >There is nothing intrinsic to the LDAP specifications that 
> make writes less
> >efficient.
> 
> I concur.  However, LDAP does not offer a number of other
> features, such as client/server transactions, which might
> be needed.
> 
> When folks start talking about intense write operations,
> I generally refer them to Tim Howes' article "LDAP: Use
> as Directed" <http://www.data.com/issue/990207/ldap.html>.
>   "LDAP isn't a replacement for relational databases
>   (and never will be)."
> 
> Kurt
> 
> 

------_=_NextPart_001_01BFD0A7.53739DA8
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Intense LDAP write operations</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I also agree.&nbsp; However, there may be issues =
related to replication, whether LDUP or proprietary, that may affect an =
LDAP server's overall efficiciency for intense writes.&nbsp; For =
instance: replication delay adds an additional delay between the time =
an entry is updated and the time that update becomes fully =
visible.</FONT></P>

<P><FONT SIZE=3D2>James A Benedict</FONT>
<BR><FONT SIZE=3D2>Advisor, IP Directory Systems Architecture</FONT>
<BR><FONT SIZE=3D2>Preside Policy Services</FONT>
<BR><FONT SIZE=3D2>NORTEL NETWORKS</FONT>
<BR><FONT SIZE=3D2>Ph:&nbsp; (613) 763-3909</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kurt D. Zeilenga [<A =
HREF=3D"mailto:Kurt@OpenLDAP.org">mailto:Kurt@OpenLDAP.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, June 07, 2000 11:11 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Rich Salz</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Martin.Rahm@nokia.com; =
ietf-ldapext@netscape.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Intense LDAP write =
operations</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 10:08 AM 6/7/00 -0400, Rich Salz =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; One concern I have is that LDAP is =
supposed to be less efficient</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; when it comes to intense write =
operations.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;There is nothing intrinsic to the LDAP =
specifications that </FONT>
<BR><FONT SIZE=3D2>&gt; make writes less</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;efficient.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I concur.&nbsp; However, LDAP does not offer a =
number of other</FONT>
<BR><FONT SIZE=3D2>&gt; features, such as client/server transactions, =
which might</FONT>
<BR><FONT SIZE=3D2>&gt; be needed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; When folks start talking about intense write =
operations,</FONT>
<BR><FONT SIZE=3D2>&gt; I generally refer them to Tim Howes' article =
&quot;LDAP: Use</FONT>
<BR><FONT SIZE=3D2>&gt; as Directed&quot; &lt;<A =
HREF=3D"http://www.data.com/issue/990207/ldap.html" =
TARGET=3D"_blank">http://www.data.com/issue/990207/ldap.html</A>&gt;.</F=
ONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; &quot;LDAP isn't a replacement for =
relational databases</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; (and never will be).&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kurt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD0A7.53739DA8--



From list@netscape.com  Wed Jun  7 15:16:39 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18651
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 15:16:35 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57J7VO27012;
	Wed, 7 Jun 2000 12:07:31 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57JEn617090;
	Wed, 7 Jun 2000 12:14:49 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 12:14:49 -0700 (PDT)
Message-ID: <01E1D01C12D7D211AFC70090273D20B101D34971@sothmxs06.entrust.com>
From: Christopher Oliva <Chris.Oliva@entrust.com>
To: "'LDAP EXT'" <ietf-ldapext@netscape.com>
Subject: clarification: ;binary
Date: Wed, 7 Jun 2000 15:14:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"8kk6pB.A.qKE.o8pP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


I often have to explain this issue to people so I thought I would raise it
once again on the list and hope that it will get clarified in the updated
version of RFC 2251.

There are four common interpretations for the use of ";binary":

1) It is used to override the BNF string syntax of values by encoding them
in BER
2) It is used to transport values where the only known/possible syntax is a
complex ASN.1 syntax (i.e. attributeCertificate)
3) It can optionally be used to transport values that have the "Binary"
syntax (the values must be BER encoded).
4) It is used to transport values that are non-printable (i.e. a string of
bytes that is not UTF8).

As far as I'm aware, the ldap RFCs do not state that ";binary" and a BER
encoding of values must be used for case number 4. In other words, there are
cases where an attribute syntax is a non-printable string of bytes and the
use of ";binary" is not required. One example of this is the Octet String
syntax.

For example, if I have an attribute named "private" with an Octet String
syntax, I can transmit this in ldap with the attribute description "private"
and encoded as 2 bytes "FFFF". It is not necessary to transmit this with the
attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Chris.



From list@netscape.com  Wed Jun  7 15:53:49 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19333
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 15:53:48 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57Jkiw11878;
	Wed, 7 Jun 2000 12:46:44 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57Jois06444;
	Wed, 7 Jun 2000 12:50:44 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 12:50:44 -0700 (PDT)
Date: Wed, 7 Jun 2000 12:50:41 -0700 (PDT)
Message-Id: <200006071950.e57Jof923785@xwing.netscape.com>
From: m_raborn@mail.com
To: ietf-ldapext@netscape.com
Subject:  May I Have Your.... -BRBJ
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"7eoylC.A.SkB.TeqP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hello,

May I have your permission to send you information 
on a simple yet highly profitable Internet business 
you can easily run from home using your computer.

This is a one-time request - 
your address has already been "removed".

We market the #1 Internet product Around the World.
Small Businesses and Families need it, want it
..and everyone can afford it!

Available to anyone, in Any Country - we are now 
in over 160 Countries, and expanding Every Week.
(You are paid weekly - in US funds - via Debit Card!)

There is no hype, speculation, pyramid games, etc.
and No Selling!

If you are serious about your financial future,
just hit reply, type "Send Me More Info"
and we'll let you be the judge.

Sincerely,

Millie
Loris, South Carolina
=================


Billions will be earned from the Internet this year.
   Would you like your share??
   Learn how to earn YOUR fortune on the Internet.








From list@netscape.com  Wed Jun  7 18:12:30 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21518
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 18:12:29 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57M3bO23336;
	Wed, 7 Jun 2000 15:03:37 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57MAuI17751;
	Wed, 7 Jun 2000 15:10:56 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 15:10:56 -0700 (PDT)
Message-Id: <3.0.5.32.20000607141708.0094a510@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 07 Jun 2000 14:17:08 -0700
To: Christopher Oliva <Chris.Oliva@entrust.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: clarification: ;binary
Cc: "'LDAP EXT'" <ietf-ldapext@netscape.com>
In-Reply-To: <01E1D01C12D7D211AFC70090273D20B101D34971@sothmxs06.entrust
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"gszbDC.A.3UE.uhsP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 03:14 PM 6/7/00 -0400, Christopher Oliva wrote:
>
>I often have to explain this issue to people so I thought I would raise it
>once again on the list and hope that it will get clarified in the updated
>version of RFC 2251.
>
>There are four common interpretations for the use of ";binary":
>
>1) It is used to override the BNF string syntax of values by encoding them
>in BER

This interpretation is close.  attribute descriptions with the
";binary" option are transferred using the BER encoding of their
syntax wrapped in an octetString.  Some attribute types must
be transferred using this mechanisms, others may (depending
upon implementation support).

>2) It is used to transport values where the only known/possible syntax is a
>complex ASN.1 syntax (i.e. attributeCertificate)

No. ;binary may be used with any and all attribute types (assuming
server support) irregardless of whether a string syntax is available.

>3) It can optionally be used to transport values that have the "Binary"
>syntax (the values must be BER encoded).

Yes, and this is generally recommended and in some cases required.

>4) It is used to transport values that are non-printable (i.e. a string of
>bytes that is not UTF8).

No.  It's used to transfer BER encoded (per syntax) attribute values
(wrapped in an octetString).

>As far as I'm aware, the ldap RFCs do not state that ";binary" and a BER
>encoding of values must be used for case number 4. In other words, there are
>cases where an attribute syntax is a non-printable string of bytes and the
>use of ";binary" is not required. One example of this is the Octet String
>syntax.

Correct.  The lack of ;binary does not imply that the value is
a printable string.  It's whatever the syntax defines as a
"string" representation.  That could be any old blob.

>For example, if I have an attribute named "private" with an Octet String
>syntax, I can transmit this in ldap with the attribute description "private"
>and encoded as 2 bytes "FFFF". It is not necessary to transmit this with the
>attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Yes.  We RFC 2252, 4.3 for clarification.





From list@netscape.com  Wed Jun  7 18:23:35 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21696
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 18:23:35 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e57MHxw07847;
	Wed, 7 Jun 2000 15:18:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e57MLxM23235;
	Wed, 7 Jun 2000 15:21:59 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 15:21:59 -0700 (PDT)
Message-Id: <200006072219.XAA05061@ibmc.up.pt>
Date: Wed, 07 Jun 00 16:20:34 EST
From: HomeHelp@foof.fsnet.co.uk
To: HomeHelp@foof.fsnet.co.uk
Subject: Attention: Homeowners & Soon To Be Homeowners
Resent-Message-ID: <"KBzfJB.A.XqF.GssP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hit reply to be removed.

Homeowners, let the power of the internet
work for you.  Fill in our quick loan request form
and you will get competitive mortgage quotes
from 3 of over 150 lenders signed up
for our service.

When lenders compete you win.

Cash back refinances
No Equity 2nd Trust Deeds
Debt Consolidation
No Income Verification
The most competitive interest rates!


Lenders are standing by, ready to approve your
loan today!  They will contact you, often
minutes after filling in the form or when it's best 
for you.  

Visit this site: 

http://204048631/?SP0602

(If web site doesn't come right up, please try back later)


-Save Time
-Save Money
-Save Aggravation

There is NEVER any fee to consumers for using this service.


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Copyright © 1999, 2000 eWorld Marketing, Inc. 1-888-418-2575. 
This is not a solicitation or offer to lend money. eWorld Marketing 
is not a lender, broker or other financial intermediary. We provide 
marketing services to the mortgage industry. 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



From list@netscape.com  Wed Jun  7 21:37:09 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23662
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 21:37:08 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e581Vcw03525;
	Wed, 7 Jun 2000 18:31:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e581Zck14322;
	Wed, 7 Jun 2000 18:35:38 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 18:35:38 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01E8C93F@aspams01.cai.com>
From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
To: Christopher Oliva <Chris.Oliva@entrust.com>,
        "'LDAP EXT'"
	 <ietf-ldapext@netscape.com>
Subject: RE: clarification: ;binary
Date: Thu, 8 Jun 2000 11:39:51 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"HWWoeC.A.XfD.ohvP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I agree with 1), 2) and 3).

I think you are wrong on 4). In the case of jpegPhoto and audio, the string
of bytes is sent as an octet string without using ;binary.

In fact, I believe that LDAP requires there always be a displayable encoding
except where this would lead to corruption of the data (certificates, for
example) or where the syntax was audio or jpegPhoto. This may also include
octet string but I can't be sure.

;binary is used to override the string encoding. It is also used for
certificates but I think this is because certificates once had a string
encoding.

I agree that the statements in RFC 2252 could be clarified.

On that subject, would it be worth starting a list of things in LDAP that
need clarification. I know I have two issues:

1) It is not clear when 'operational' attributes should be specifically
requested to be returned in a search response. 'namingContexts' is
interesting in that it is defined as an operational attribute that can only
appear in the root DSE? 'ldapVersions' is not marked in this way? Mark Wahl
has suggested that all attributes in the root DSE should be returned as if
they are not operational, but I think this doesn't really clarify matters.

2) The extended response 'protocolError' MAY be returned. This is
unsatisfactory. I tried to return it to a previous version of MS ADSI. I
don't think it expect it. And this is the problem - if it is not a MUST then
clients needn't support it, so servers CANNOT use it.

Ron.

-----Original Message-----
From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
Sent: Thursday, 8 June 2000 5:15
To: 'LDAP EXT'
Subject: clarification: ;binary



I often have to explain this issue to people so I thought I would raise it
once again on the list and hope that it will get clarified in the updated
version of RFC 2251.

There are four common interpretations for the use of ";binary":

1) It is used to override the BNF string syntax of values by encoding them
in BER
2) It is used to transport values where the only known/possible syntax is a
complex ASN.1 syntax (i.e. attributeCertificate)
3) It can optionally be used to transport values that have the "Binary"
syntax (the values must be BER encoded).
4) It is used to transport values that are non-printable (i.e. a string of
bytes that is not UTF8).

As far as I'm aware, the ldap RFCs do not state that ";binary" and a BER
encoding of values must be used for case number 4. In other words, there are
cases where an attribute syntax is a non-printable string of bytes and the
use of ";binary" is not required. One example of this is the Octet String
syntax.

For example, if I have an attribute named "private" with an Octet String
syntax, I can transmit this in ldap with the attribute description "private"
and encoded as 2 bytes "FFFF". It is not necessary to transmit this with the
attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Chris.



From list@netscape.com  Wed Jun  7 21:46:11 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24593
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 21:46:10 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e581VtO21583;
	Wed, 7 Jun 2000 18:31:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e581dEo17328;
	Wed, 7 Jun 2000 18:39:14 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 18:39:14 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01E8C9AE@aspams01.cai.com>
From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
To: "Kurt D. Zeilenga" <Kurt@openldap.org>,
        Christopher Oliva
	 <Chris.Oliva@entrust.com>
Cc: "'LDAP EXT'" <ietf-ldapext@netscape.com>
Subject: RE: clarification: ;binary
Date: Thu, 8 Jun 2000 11:43:28 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"PMvkfC.A.WOE.BlvP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Kurt,

It is not true that

"attribute descriptions with the
";binary" option are transferred using the BER encoding of their
syntax wrapped in an octetString."

Attributes should be transferred using their native encoding. If they are
strings then an encoding is defined for them which is simply wrapping in an
octet string.

BER values are NOT wrapped in octet strings.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, 8 June 2000 7:17
To: Christopher Oliva
Cc: 'LDAP EXT'
Subject: Re: clarification: ;binary


At 03:14 PM 6/7/00 -0400, Christopher Oliva wrote:
>
>I often have to explain this issue to people so I thought I would raise it
>once again on the list and hope that it will get clarified in the updated
>version of RFC 2251.
>
>There are four common interpretations for the use of ";binary":
>
>1) It is used to override the BNF string syntax of values by encoding them
>in BER

This interpretation is close.  attribute descriptions with the
";binary" option are transferred using the BER encoding of their
syntax wrapped in an octetString.  Some attribute types must
be transferred using this mechanisms, others may (depending
upon implementation support).

>2) It is used to transport values where the only known/possible syntax is a
>complex ASN.1 syntax (i.e. attributeCertificate)

No. ;binary may be used with any and all attribute types (assuming
server support) irregardless of whether a string syntax is available.

>3) It can optionally be used to transport values that have the "Binary"
>syntax (the values must be BER encoded).

Yes, and this is generally recommended and in some cases required.

>4) It is used to transport values that are non-printable (i.e. a string of
>bytes that is not UTF8).

No.  It's used to transfer BER encoded (per syntax) attribute values
(wrapped in an octetString).

>As far as I'm aware, the ldap RFCs do not state that ";binary" and a BER
>encoding of values must be used for case number 4. In other words, there
are
>cases where an attribute syntax is a non-printable string of bytes and the
>use of ";binary" is not required. One example of this is the Octet String
>syntax.

Correct.  The lack of ;binary does not imply that the value is
a printable string.  It's whatever the syntax defines as a
"string" representation.  That could be any old blob.

>For example, if I have an attribute named "private" with an Octet String
>syntax, I can transmit this in ldap with the attribute description
"private"
>and encoded as 2 bytes "FFFF". It is not necessary to transmit this with
the
>attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Yes.  We RFC 2252, 4.3 for clarification.




From list@netscape.com  Wed Jun  7 22:26:34 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24786
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 22:26:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e582HvO27657;
	Wed, 7 Jun 2000 19:17:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e582PG603174;
	Wed, 7 Jun 2000 19:25:16 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 19:25:16 -0700 (PDT)
Message-Id: <3.0.5.32.20000607192505.0094c4a0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 07 Jun 2000 19:25:05 -0700
To: "Ramsay, Ron" <Ron.Ramsay@ca.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: RE: clarification: ;binary
Cc: Christopher Oliva <Chris.Oliva@entrust.com>,
        "'LDAP EXT'" <ietf-ldapext@netscape.com>
In-Reply-To: <E7E4455BFFB4D311BC78009027D0D18C01E8C9AE@aspams01.cai.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"Hm9kQC.A.Ox.KQwP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:43 AM 6/8/00 +1000, Ramsay, Ron wrote:
>BER values are NOT wrapped in octet strings.

RFC 2252, 4.3.1  Binary Transfer of Values
                                                                
   This encoding format is used if the binary encoding is requested by
   the client for an attribute, or if the attribute syntax name is
   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
   AttributeValue or AssertionValue field is a BER-encoded instance of
   the attribute value or a matching rule assertion value ASN.1 data
   type as defined for use with X.500. (The first byte inside the OCTET
   STRING wrapper is a tag octet.  However, the OCTET STRING is still
   encoded in primitive form.)




From list@netscape.com  Wed Jun  7 22:46:01 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25837
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 22:46:00 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e582eOw09865;
	Wed, 7 Jun 2000 19:40:24 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e582iOw07579;
	Wed, 7 Jun 2000 19:44:24 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 19:44:24 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01E8CEF9@aspams01.cai.com>
From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
Cc: "'LDAP EXT'" <ietf-ldapext@netscape.com>
Subject: RE: clarification: ;binary
Date: Thu, 8 Jun 2000 12:48:36 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"HFlD4D.A.A2B.GiwP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Kurt,

Yes, but then string values returned as binary are sent as one octet string
inside another. It simply depends on where you see the value ending and the
LDAP encoding beginning.

If this is what you meant, I'm sorry, but it certainly was not clear from
the context, particularly as you were discussing the wrapping of string
values as octet strings without mentioning that these octet strings would be
wrapped again to form the PDU.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, 8 June 2000 12:25
To: Ramsay, Ron
Cc: Christopher Oliva; 'LDAP EXT'
Subject: RE: clarification: ;binary


At 11:43 AM 6/8/00 +1000, Ramsay, Ron wrote:
>BER values are NOT wrapped in octet strings.

RFC 2252, 4.3.1  Binary Transfer of Values
                                                                
   This encoding format is used if the binary encoding is requested by
   the client for an attribute, or if the attribute syntax name is
   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
   AttributeValue or AssertionValue field is a BER-encoded instance of
   the attribute value or a matching rule assertion value ASN.1 data
   type as defined for use with X.500. (The first byte inside the OCTET
   STRING wrapper is a tag octet.  However, the OCTET STRING is still
   encoded in primitive form.)



From list@netscape.com  Wed Jun  7 23:11:33 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25958
	for <ldapext-archive@odin.ietf.org>; Wed, 7 Jun 2000 23:11:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5836Dw11923;
	Wed, 7 Jun 2000 20:06:13 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e583ADg14350;
	Wed, 7 Jun 2000 20:10:13 -0700 (PDT)
Resent-Date: Wed, 7 Jun 2000 20:10:13 -0700 (PDT)
Message-Id: <3.0.5.32.20000607201006.00926420@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 07 Jun 2000 20:10:06 -0700
To: "Ramsay, Ron" <Ron.Ramsay@ca.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: RE: clarification: ;binary
Cc: "'LDAP EXT'" <ietf-ldapext@netscape.com>
In-Reply-To: <E7E4455BFFB4D311BC78009027D0D18C01E8CEF9@aspams01.cai.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"N7X_qC.A.vfD.S6wP5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 12:48 PM 6/8/00 +1000, Ramsay, Ron wrote:
>Yes, but then string values returned as binary are sent as one octet string
>inside another.

If the syntax of the attribute is octetString, yes, the ;binary
attribute value, an OCTET STRING, will include the octetString
value.  Likewise, if you transfer cn;binary, the attribute value,
an OCTET STRING, should contain a BER encoded DirectoryString.
And if you transfer certificate;binary, the attribute value, an
OCTET STRING, contains the BER encoded certificate.

I see how my previous comment might have been confusing.

Kurt



From list@netscape.com  Thu Jun  8 05:50:09 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10394
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 05:50:04 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e589fHO24168;
	Thu, 8 Jun 2000 02:41:17 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e589mak07847;
	Thu, 8 Jun 2000 02:48:36 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 02:48:36 -0700 (PDT)
Message-Id: <s93f168f.052@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 08 Jun 2000 03:32:35 -0600
From: "Subbu K. k." <KKSUBRAMANIAM@novell.com>
To: <TGullotta@access360.com>, <ietf-ldapext@netscape.com>,
        <Martin.Rahm@nokia.com>
Subject: RE: Intense LDAP write operations
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e589mY107791
Resent-Message-ID: <"I3GBi.A.45B.yv2P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Not really. It is just that when you have millions of objects, they tend to be read much more often than modified. For instance, when a user object is created, it is read thousands of times before it gets updated. Operationally, NDS does update its database internally for its replication status etc. The last login time attribute does get updated for every login, but this is an operational attribute.

NDS itself uses a transactional database to ensure full integrity and incremental replication to ensure scalability. It has tested to hold more than 1 billion objects on a single E450. As installed, it just takes less than a megabyte for its database.

Subbu K. K.

>>> <TGullotta@access360.com> 06/07/00 09:08PM >>>
Subbu,

Has Novell done any benchmarks on read vs. write operations? It seems that
in a lot of directory implementations, although not every entry is being
updated that frequently, if you have a million or so users, just periodic
updates to entries could add up when you look at the total number of users.
I would think this is realistic. Is it a problem with NDS?

Tony Gullotta
Lead System Architect
access360


-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com] 
Sent: Wednesday, June 07, 2000 12:15 AM
To: ietf-ldapext@netscape.com; Martin.Rahm@nokia.com 
Subject: Re: Intense LDAP write operations


I dont think this was the sweet spot planned for directories. Writes would
entail applying locks on the data store which would impact the regular
search, retrieval and any sync operations. You also need to deal with
atomicity of updates to the group of attributes and the latency of
propagation of changes across multiple copies of the data store. A
transactional database may be a better choice.

Are you sure you need a directory service and not a transactional database
engine that supports LDAP in addition to SQL?

Subbu K. K
?---------------------------------------------
K. K. Subramaniam
Product Manager, Novell Directory Services (UNIX)
Novell

>>> <Martin.Rahm@nokia.com> 06/07/00 12:27PM >>>
Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm




From list@netscape.com  Thu Jun  8 06:59:27 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10901
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 06:59:27 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58Arww11351;
	Thu, 8 Jun 2000 03:53:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58Avxo21362;
	Thu, 8 Jun 2000 03:57:59 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 03:57:59 -0700 (PDT)
Message-Id: <200006081057.GAA10810@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ldapext@netscape.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ldapext-sorting-03.txt
Date: Thu, 08 Jun 2000 06:57:54 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"wN1h7D.A.YNF.1w3P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Extension Working Group of the IETF.

	Title		: LDAP Control Extension for Server Side Sorting of 
                          Search Results
	Author(s)	: T. Howes, M. Wahl, A. Anantha
	Filename	: draft-ietf-ldapext-sorting-03.txt
	Pages		: 6
	Date		: 07-Jun-00
	
This  document  describes two LDAPv3 control extensions for  server side
sorting of search results. These controls allows a client to specify the
attribute types and  matching rules a  server should  use when returning
the results to an LDAP search request.  The controls may be useful when
the  LDAP client  has limited  functionality or  for some  other reason
cannot sort the results  but still needs them sorted.  Other permissible
controls on search operations are not defined in this extension.
 
The sort controls allow a server to return a result code for the sorting
of the results  that is independent  of the result code returned for the
search operation.
 
The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to
be interpreted as described in [bradner97].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-sorting-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapext-sorting-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapext-sorting-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000607121559.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldapext-sorting-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ldapext-sorting-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000607121559.I-D@ietf.org>

--OtherAccess--

--NextPart--




From list@netscape.com  Thu Jun  8 11:10:28 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09313
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 11:10:28 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58F1ZO15559;
	Thu, 8 Jun 2000 08:01:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58F8tM00457;
	Thu, 8 Jun 2000 08:08:55 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 08:08:55 -0700 (PDT)
Message-Id: <3.0.5.32.20000608080628.00934100@pop.walltech.com>
X-Sender: bgreenblatt@pop.walltech.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Thu, 08 Jun 2000 08:06:28 -0700
To: ietf-ldapext@netscape.com
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject: Re: I-D ACTION:draft-ietf-ldapext-sorting-03.txt
In-Reply-To: <200006081057.GAA10810@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"k3AGhD.A.rG.Fc7P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

There is a glaring error on the first line of this draft...  

Also, the draft needs to be more explicit about where a MatchingRuleID
comes from (i.e. it should point to clause 4.1.9 of RFC 2251).  Other than
that, the draft looks very good!

Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi



From list@netscape.com  Thu Jun  8 11:20:34 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09544
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 11:20:34 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58FBBO17084;
	Thu, 8 Jun 2000 08:11:11 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58FIVE03916;
	Thu, 8 Jun 2000 08:18:31 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 08:18:31 -0700 (PDT)
DATE: 08 Jun 00 11:36:53 AM
FROM: BDSwIp1js@kardelen.setra.net.tr
Message-ID: <1Xy7W16XhFZS825E3y>
SUBJECT: great web hosting deals 
Resent-Message-ID: <"35NGLD.A.g8.Fl7P5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more PER MONTH  TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

WE HAVE BOTH UNIX AND NT MACHINES WITH FRONT PAGE EXTENSIONS FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE.

FOR DETAILS CALL 1 888 248 0765  or fax 240 337 8325

PES WEB HOSTING -- 
_______________________________________________________________

Want to do bulk email?

Ask us how today!

GET YOUR MESSAGE DELIVERED TO 500,000 PEOPLE FOR ONLY $550.00.

OR HAVE YOUR MESSAGE DELIVERED TO OVER 1 MILLION 
PEOPLE FOR ONLY $1200.00.

Call 1888 248 0765 for FURTHER INFORMATION today!
  or fax 240 337 8325

_________________________________________________________________

Get your own offshore trust! 
PROTECT YOUR PERSONAL ASSETS FROM LAWSUITS or Do SOME ESTATE PLANNING TO MINIMIZE THOSE INHERITANCE TAXES!
GET THAT OFFSHORE BANK ACCOUNT YOU ALWAYS WANTED!

For further information please fax 240 337 8325




THANK YOU






From list@netscape.com  Thu Jun  8 11:57:39 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10242
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 11:57:38 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58FpCw07415;
	Thu, 8 Jun 2000 08:51:12 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58FtD620639;
	Thu, 8 Jun 2000 08:55:13 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 08:55:13 -0700 (PDT)
Message-ID: <01E1D01C12D7D211AFC70090273D20B101D34979@sothmxs06.entrust.com>
From: Christopher Oliva <Chris.Oliva@entrust.com>
To: "'Ramsay, Ron'" <Ron.Ramsay@ca.com>,
        "'LDAP EXT'"
	 <ietf-ldapext@netscape.com>
Subject: RE: clarification: ;binary
Date: Thu, 8 Jun 2000 11:55:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"q1LY4D.A.xBF.fH8P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


In your response, you stated:

"In fact, I believe that LDAP requires there always be a displayable
encoding except ..." 

That is the misconception that leads to the confusion about ";binary" and
the transmission of values within the ldap protocol.

In fact, there is no requirement in RFC 2251 that states that attribute
values MUST be printable (or can be displayed). It does encourage this goal,
but states that some values may not be displayable. RFC 2252 gives audio as
an example.

You can generalize the use of ;binary to two cases:

Case (1):
It is the attribute syntax that determines whether the ";binary" mechanism
must be used, and not the actual value itself (before encoding for
transmission)i.e. the issue is not whether or not the value can be diplayed.
For example, the Certificate syntax requires the ";binary" mechanism but
Octet String does not and yet Octet String can be used to transmit either
printable or non-printable values. In the case where an Octet String syntax
is used to transmit a non-printable value, there is no need to use the
";binary" mechanism. The example I have is the Octet String value composed
of two non-printable bytes "FFFF". This is transferred as FFFF and does not
require the ;binary attribute option.

Case (2):
The user wishes to use the BER encoding of the data in order to override the
"regular" ldap representation. In this case, if you have the Octet String
value "FFFF", you can encode this as "0402FFFF" for transmission along with
the ;binary attribute option. (You're not really gaining much by doing this
for the Octet String syntax.) But it is important to note that this is not
required by ldap v3.

Chris.


-----Original Message-----
From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
Sent: Wednesday, June 07, 2000 9:40 PM
To: Christopher Oliva; 'LDAP EXT'
Subject: RE: clarification: ;binary


I agree with 1), 2) and 3).

I think you are wrong on 4). In the case of jpegPhoto and audio, the string
of bytes is sent as an octet string without using ;binary.

In fact, I believe that LDAP requires there always be a displayable encoding
except where this would lead to corruption of the data (certificates, for
example) or where the syntax was audio or jpegPhoto. This may also include
octet string but I can't be sure.

;binary is used to override the string encoding. It is also used for
certificates but I think this is because certificates once had a string
encoding.

I agree that the statements in RFC 2252 could be clarified.

On that subject, would it be worth starting a list of things in LDAP that
need clarification. I know I have two issues:

1) It is not clear when 'operational' attributes should be specifically
requested to be returned in a search response. 'namingContexts' is
interesting in that it is defined as an operational attribute that can only
appear in the root DSE? 'ldapVersions' is not marked in this way? Mark Wahl
has suggested that all attributes in the root DSE should be returned as if
they are not operational, but I think this doesn't really clarify matters.

2) The extended response 'protocolError' MAY be returned. This is
unsatisfactory. I tried to return it to a previous version of MS ADSI. I
don't think it expect it. And this is the problem - if it is not a MUST then
clients needn't support it, so servers CANNOT use it.

Ron.

-----Original Message-----
From: Christopher Oliva [mailto:Chris.Oliva@entrust.com]
Sent: Thursday, 8 June 2000 5:15
To: 'LDAP EXT'
Subject: clarification: ;binary



I often have to explain this issue to people so I thought I would raise it
once again on the list and hope that it will get clarified in the updated
version of RFC 2251.

There are four common interpretations for the use of ";binary":

1) It is used to override the BNF string syntax of values by encoding them
in BER
2) It is used to transport values where the only known/possible syntax is a
complex ASN.1 syntax (i.e. attributeCertificate)
3) It can optionally be used to transport values that have the "Binary"
syntax (the values must be BER encoded).
4) It is used to transport values that are non-printable (i.e. a string of
bytes that is not UTF8).

As far as I'm aware, the ldap RFCs do not state that ";binary" and a BER
encoding of values must be used for case number 4. In other words, there are
cases where an attribute syntax is a non-printable string of bytes and the
use of ";binary" is not required. One example of this is the Octet String
syntax.

For example, if I have an attribute named "private" with an Octet String
syntax, I can transmit this in ldap with the attribute description "private"
and encoded as 2 bytes "FFFF". It is not necessary to transmit this with the
attribute description "private;binary" and encoded as 4 bytes "0402FFFF".

Chris.



From list@netscape.com  Thu Jun  8 12:44:07 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11577
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 12:44:07 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58Gcew16889;
	Thu, 8 Jun 2000 09:38:41 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58GgfU24709;
	Thu, 8 Jun 2000 09:42:41 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 09:42:41 -0700 (PDT)
Date: Thu, 08 Jun 2000 11:05:19 -0500 (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
From: zainprov@swbell.net
Subject: Shocking LOSE 10-100lbs. DESTINY
To: ietf-ldapext@netscape.com
Message-id: <0FVU00BIBFCTSN@mta5.rcsntx.swbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=unknown-8bit
Resent-Message-ID: <"6Z9t4B.A.fBG._z8P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Hello From Destiny,

You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!   
LOOK! http://home.swbell.net/zainprov/destiny.htm



We hope things are going well for you.  Good luck, God Bless, and 
HAVE A GREAT DAY!



Either you are someone else subscribed to our list.  To be removed
Simply reply with a blank email.  

Thank you,

Sherry Wilson



From list@netscape.com  Thu Jun  8 12:51:56 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11853
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 12:51:55 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58Gh7O00621;
	Thu, 8 Jun 2000 09:43:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58GoRM28589;
	Thu, 8 Jun 2000 09:50:27 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 09:50:27 -0700 (PDT)
Message-Id: <3.0.3.32.20000608173502.0069cd94@mailhome.rdg.opengroup.org>
X-Sender: cjh@mailhome.rdg.opengroup.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 08 Jun 2000 17:35:02 +0100
To: directory@opengroup.org, dirconnect-attendees@opengroup.org,
        ietf-ldapext@netscape.com
From: Chris Harding <c.harding@opengroup.org>
Subject: Calling LDAP Application Developers
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"YKQcH.A.49G.Q78P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi -

With IBM, iPlanet, Iris, and Microsoft now registered for DirConnect6
(Novell still to confirm), you have a great chance to test your LDAP
applications against the major server implementations!

DirConnects are informal interoperability testing events. There is a set of
test data and associated tests availale to run, or you can do your own
tests. They are engineering events - if something doesn't work when you try
to interoperate with another product, you have a chance to sort the problem
out at an engineering level with the vendor concerned.

DirConnect 6 will be held in Austin, Texas on June 21-22. You don't need to
make elaborate preparations - just put your application on a laptop and get
on a plane!

This DirConnect is being held jointly by The Open Group and the Directory
Interoperability Forum (DIF), with reduced attendance rates for members of
either organization.

You can find out more about the event, and register for it, via
http://www.opengroup.org/directory/dc6/index.htm

Be there!



Regards,

Chris
+++++

========================================================================
                     THE DIRECTORY-ENABLED ENTERPRISE:
                     26-27 June, 2000   Austin, Texas
    
                 The State-of-the-Art of Directory Products, 
                          The Customer Perspective,
                The Vision of the Directory-Enabled Enterprise.

                 http://www.opengroup.org/public/member/q300/

           Chris Harding
  T H E    Directory Program Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:c.harding@opengroup.org  Phone:  +44 118 950 8311 x2262
           WWW: http://www.opengroup.org   Mobile: +44 771 8588820  
========================================================================



From list@netscape.com  Thu Jun  8 14:03:00 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13211
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 14:03:00 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58Hs3O12044;
	Thu, 8 Jun 2000 10:54:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58I1N201199;
	Thu, 8 Jun 2000 11:01:23 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 11:01:23 -0700 (PDT)
Message-Id: <200006081801.LAA17838@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2829 on Authentication Methods for LDAP
Cc: rfc-ed@ISI.EDU, ietf-ldapext@netscape.com
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 08 Jun 2000 11:01:10 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Resent-Message-ID: <"FwMRlC.A.wQ.u99P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2829

        Title:	    Authentication Methods for LDAP
        Author(s):  M. Wahl, H. Alvestrand, J. Hodges, R. Morgan 
        Status:     Standards Track
	Date:       May 2000
        Mailbox:    Mark.Wahl@innosoft.com,
                    Harald.Alvestrand@maxware.no,
                    Jeff.Hodges@Stanford.edu, 
                    Bob.Morgan@Stanford.edu 
        Pages:      16
        Characters: 33471
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-ldapext-authmeth-04.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2829.txt


This document specifies particular combinations of security
mechanisms which are required and recommended in LDAP [1]
implementations.

This document is a product of the LDAP Extension Working Group of the
IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <000608105902.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2829

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2829.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <000608105902.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--



From list@netscape.com  Thu Jun  8 14:07:56 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13261
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 14:07:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58HxAO13630;
	Thu, 8 Jun 2000 10:59:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58I4HE05257;
	Thu, 8 Jun 2000 11:04:17 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 11:04:17 -0700 (PDT)
Message-Id: <200006081804.LAA18445@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2830 on LDAPv3: Extension for Transport Layer Security
Cc: rfc-ed@ISI.EDU, ietf-ldapext@netscape.com
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 08 Jun 2000 11:04:10 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Resent-Message-ID: <"nN9nEB.A.lRB.fA-P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2830

        Title:	    Lightweight Directory Access Protocol (v3):
                    Extension for Transport Layer Security 
        Author(s):  J. Hodges, R. Morgan, M. Wahl
        Status:     Standards Track
	Date:       May 2000
        Mailbox:    JHodges@oblix.com, rlmorgan@washington.edu,
                    Mark.Wahl@innosoft.com 
        Pages:      12
        Characters: 24469
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-ldapext-ldapv3-tls-06.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2830.txt


This document defines the "Start Transport Layer Security (TLS)
Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an
LDAP extended request.

This document is a product of the LDAP Extension Working Group of the
IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <000608110154.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2830

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2830.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <000608110154.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--



From list@netscape.com  Thu Jun  8 14:12:59 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13306
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 14:12:57 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58I7Sw03701;
	Thu, 8 Jun 2000 11:07:29 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58IBTw08918;
	Thu, 8 Jun 2000 11:11:29 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 11:11:29 -0700 (PDT)
Message-Id: <200006081807.LAA18869@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2831 on Digest SASL Mechanism
Cc: rfc-ed@ISI.EDU, ietf-ldapext@netscape.com
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 08 Jun 2000 11:07:38 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Resent-Message-ID: <"-jzyBD.A.oKC.PH-P5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2831

        Title:	    Using Digest Authentication as a SASL Mechanism 
        Author(s):  P. Leach, C. Newman
        Status:     Standards Track
	Date:       May 2000
        Mailbox:    paulle@microsoft.com, chris.newman@innosoft.com
        Pages:      27
        Characters: 58124
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-leach-digest-sasl-05.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2831.txt


This specification defines how HTTP Digest Authentication [Digest] can
be used as a SASL [RFC 2222] mechanism for any protocol that has a
SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC
2195] and as a convenient way to support a single authentication
mechanism for web, mail, LDAP, and other protocols.

This document is a product of the LDAP Extension Working Group of the
IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <000608110522.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2831

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2831.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <000608110522.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--



From list@netscape.com  Thu Jun  8 16:59:26 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16720
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 16:59:24 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e58Krvw29900;
	Thu, 8 Jun 2000 13:53:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e58Kvw629890;
	Thu, 8 Jun 2000 13:57:58 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 13:57:58 -0700 (PDT)
From: John_Payne@motorcity2.lotus.com
X-Lotus-FromDomain: NOTES@ALPHABETA
Sender: John_Payne@motorcity2.lotus.com
To: ietf-ldapext@netscape.com
Message-ID: <852568F8.007239C3.00@motorcity2.lotus.com>
Date: Thu, 8 Jun 2000 15:58:51 -0400
Subject: Re: clarification: ;binary
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Resent-Message-ID: <"kMqd_B.A.oSH.UjAQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



O.K. I will bite.

I agree that the RFC 2252 section 4.3 requires clarification.  The text is way
open to misinterpretations and interoperability problems because of text like
"to the greatest extent possible" and "string encoding".

Maybe it's a hang up from LDAP V2 but when I see "string encoding" I
automaticaly think of something like base-64 etc. and further more the wording
sort of strongly encourages printable strings.  I agree it doesn't state that it
must be a printable string but it seems to me that the implication is that
internaly it can be treated using 'conventional' string operations such as
strcpy.  To me it seems to imply that if you can't handle the value as a
"string" then it should be flagged with the ";binary" option.

I would suggest thet "string encoding" be replaced by "Directory String" and the
ambiguity would pretty much go away.




From list@netscape.com  Thu Jun  8 20:15:16 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19458
	for <ldapext-archive@odin.ietf.org>; Thu, 8 Jun 2000 20:15:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5909kw01278;
	Thu, 8 Jun 2000 17:09:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e590DlA09171;
	Thu, 8 Jun 2000 17:13:47 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 17:13:47 -0700 (PDT)
Message-Id: <200006082352.QAA29593@avocet.prod.itd.earthlink.net>
X-Sender: pcmarketing@mail.earthlink.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 08 Jun 2000 17:07:53 -0700
To: (Recipient list suppressed)
From: pcmarketing@earthlink.net
Subject: Internet Networkers Unite
Mime-Version: 1.0
Content-Type: multipart/alternative;
	types="text/plain,text/html";
	boundary="=====================_9873425==_.ALT"
Resent-Message-ID: <"015AS.A.gNC.4aDQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--=====================_9873425==_.ALT
Content-Type: text/plain; charset="us-ascii"

This is not a spam. We are either both members of the same opt-in group or
have
communicated before. If you wish to be removed from this mailing list reply to
this email with remove in the subject line and you will be removed
immediately.

INTERNET NETWORKERS UNITE!! 

"Although we continue to think we live in an industrial society, we have in
fact changed to an economy based on the creation and distribution of
information." 

"In our new information economy, the strategic resource is information. With
information as the strategic resource access to our economic system is much
easier" 

"The productivity of information (movement of information) has already become
the key to... economic achievement."      
MEGATRENDS, John Naisbitt 

NETWORKING 

People getting together sharing ideas, information, and resources. 

OUR GOAL

1.      Develop a network of People who want to make money on the internet
2.      Increase our cash flow so we can take advantage of the many lucrative
opportunities available on the internet today
3.      Set up a medium of exchange so we can pay and receive money quickly
4.      Help others do the same

The first opportunity will accomplish All Four Goals, plus start building the
foundation for a future that you always wanted. The income potential of this
opportunity is enormous and yet it is so simple and it pays quickly!

The cost is only $15 one time. 

I have to admit, the first time I saw this I was a procrastinator. I didn't
believe it would really work and left it lying on my desk to follow up on
"sometime"! One day I was in my office, got out a calculator, started working
the numbers and realized what a tremendous opportunity this could be. I became
extremely excited!

What I love most about this program is that it only takes a few minutes and
then I can forget all about it! 

I'm sure you have seen old programs where you had to send cash by mail and
then
mail the program information out to 20 or 50 or 100 people! You were never
sure
if your cash arrived safely and you had to get letters printed, address
envelopes, stuff the letter in the envelope, put a stamp on it and drive it to
the post office.

That has all changed with the INTERNET and E-GOLD. If you haven't used e-gold
yet, you are in for a real treat. It's called e-gold because it is electronic
currency and it is backed by real gold, not like our Federal Reserve Notes
that
are not backed by anything! 

Payment is INSTANT and completely anonymous! I'll tell you how to open your
account a little later. (Goal #3 Set up a medium of exchange)

This is the FASTEST, EASIEST program you will ever find. If you need extra
money next week, this is the opportunity you have been looking for. There are
no monthly fees. 

You are going to pay three people, $5 each -- a total of $15 -- to have them
put you on their email list so they can send you information pertaining to
future opportunities. (Goal #1 Develop a network) 

This keeps our program 100% legal: 

(Refer to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or
Title
18, Section 3005 in the US code, also in the code of federal regulations,
Volume 16, Sections 255 and 436.)

You are paying to be put on a mailing list so that you can stay informed to
future opportunities.

Now let's talk about Goal #2: INCREASING OUR CASH FLOW

HOW DOES an extra $100, $500 and even THOUSANDS of dollars sound in the NEXT
TWO WEEKS? You can not lose if you will network this information with others.
ACT QUICKLY.

The Response has been INCREDIBLE and FAST!

----------------------------------------------------------------

Testimonials:

----------------------------------------------------------------

I CAN'T BELIEVE IT!!! With under an hour of work I have made over US $9,000 in
the last three weeks...and my investment was just $15!!! 
Thank you
Robert, Westminster, California

----------------------------------------------------------------

More than $6,000.00 has already been deposited to my e-gold account...
Mark, London, England

----------------------------------------------------------------

If you START TODAY, you could see results as soon as tomorrow, or even later
today! Remember, I said this program is quick and easy. You just send out
emails to your prospects and when they participate, money is sent to your
e-gold account and you can withdrawal you money anytime.

Send a few messages or send a lot. You decide how much money you need! It
is so
easy to send an email and so easy to pay with e-gold that nearly everyone
jumps
at this opportunity.

If you only send out 20 emails and each of those people recognize the gold
(literally) they have in their hands -- you will have $100 deposited to your
e-gold account within days. If they each only send out 20 emails and each of
those 400 people recognize the gold in their hands, you will have another
$1,000 deposited, easily in TWO WEEKS OR LESS! If those 400 people each send
only 20 emails and each of those people respond you would have $40,000
deposited in your e-gold account! 

$15 equals $40,000! And if you received only 1/10th of that, you still have
$4,000. Is that worth an hour of your time. Remember, this is only the
beginning.

NETWORKING - People getting together sharing ideas, information, and
resources.
INTERNET NETWORKERS UNITE! 

Once you understand the power here, you will have to get your first batch of
emails out tonight or you won't be able to sleep!

Send an email to everyone you know. Send email to everyone who sends an email
to you. They will be glad you did. Follow the simple instructions and in weeks
or even days you will have thousands of dollars in your e-gold account. 

This program has a very HIGH RESPONSE RATE because it is fast, easy and only
costs $15.
----------------------------------------------------------------

FOLLOW THESE SIMPLE STEPS:

1) Go to: http://www.e-gold.com/ and open an account, if you don't have one
already. You will need to fund your new account. You can do that on the e-gold
site or use: 

http://www.goldchanger.com or 
http://golddirectory.com or 
http://pecb.com/gold-age . 

They all charge a fee for converting your currency to gold so check and see
which best suits your needs. Be sure to put a little extra in your account to
cover e-gold's 1% transaction fees.

2) Access your e-gold account and click on SPEND. Spend $5 to all three e-gold
accounts on the list that is at the end of this email, putting 'Networker' in
the MEMO. 

NOTE: You don't have to wait for your name to rise to the top of the list like
you do in other programs. You start earning immediately!

3) Delete the #1 account from the list. Move the other two numbers UP and ADD
YOUR e-gold account # to the list in the # 3 (BOTTOM) position.

4) Send out as many copies of this letter as you can! REMEMBER, no spamming!
You probably get messages every day from people inviting you to join their
programs. Send them this email in return! 

Visit FFA links pages and bulletin boards. Respond to ads. When they send you
their information, answer back with this email! (Goal #4 Helping Others)
Your contact source is unlimited. It's so easy. THAT'S IT! To send your letter
by Email follow these instructions:

1)      Go to "edit" and "select all"
2)      Go to "edit" and "copy"
3)      Start a new Email message
4)      Address your Email and put "Internet Networkers Unite" or a Title of
your choice in the subject block
5)      Put your cursor in the body text area of the message and then Go to
"edit" and "paste". After you have pasted this article to your new Email,
delete the old Subject, Date, To, From, Etc.
6)      Go to where the e-gold account numbers are listed. Delete the top
account number and add your account number to the bottom of the list as number
3. 

THAT'S IT! YOU'RE DONE, YOU'RE THROUGH! NO WAITING! You start collecting your
payments immediately. The payments will be sent to you by people like
yourself,
who are willing to invest US$15 and less than one hour to receive as much as
US$40,000 or more in cash.

If you don't receive all the cash you want within two weeks, simply send out
more emails.

Fellow Networkers, this is a real opportunity and only the beginning! There
are
many more high paying programs on the internet today, but if you don't have
the
cash or a network of other like-minded people that's all they are is just
opportunities. You can do this - it's low cost, easy and very lucrative!

I Hope You Join us!!

EMAIL YOUR LETTERS OUT TODAY - - -

To recap:

1.)     JOIN E-Gold if you're not a member yet
2.)     SPEND $5.00 to each account on the list
3.)     REMOVE the account in #1 position from the list
4.)     MOVE the other accounts on the list up one position
5.)     ADD your own account in position #3

E-GOLD ACCOUNTS

1. 140277
2. 140282 
3. 112938

If you are new to e-gold, I recommend you spend some time on their web site
learning how the system works. Basically, once your account is open, you can
fund it by either having someone else transfer e-gold into your account or by
exchanging some of your currency into gold. After you have collected a lot of
e-gold, you may use it to pay bills, pay other people, actually take delivery
of gold or you can cash-out and be paid in whatever currency you desire.
One of
the big advantages to using e-gold is that it is international.

It's EASY, It's FAST, but you do have to TAKE ACTION. Get started today. You
could see results within HOURS.








--=====================_9873425==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
This is not a spam. We are either both members of the same opt-in group
or have communicated before. If you wish to be removed from this mailing
list reply to this email with remove in the subject line and you will be
removed immediately.<br>
<br>
<b><u>INTERNET NETWORKERS UNITE!!</b></u> <br>
<br>
&quot;Although we continue to think we live in an industrial society, we
have in fact changed to an economy based on the creation and distribution
of information.&quot; <br>
<br>
&quot;In our new information economy, the strategic resource is
information. With information as the strategic resource access to our
economic system is much easier&quot; <br>
<br>
&quot;The productivity of information (movement of information) has
already become the key to... economic achievement.&quot;
<font size=2><b>
<dl>
<dl>
<dl>
<dl>
<dd>MEGATRENDS, John Naisbitt</font></b><font size=3> <br>
<br>
<b><u>
</dl>
</dl>
</dl>
</dl>NETWORKING</b></u> <br>
<br>
People getting together sharing ideas, information, and resources. <br>
<br>
<b><u>OUR GOAL<br>
<br>
</b></u>1.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Develop a
network of People who want to make money on the internet<br>
2.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Increase our cash
flow so we can take advantage of the many lucrative opportunities
available on the internet today<br>
3.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Set up a medium of
exchange so we can pay and receive money quickly<br>
4.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Help others do the
same<br>
<br>
The first opportunity will accomplish All Four Goals, plus start building
the foundation for a future that you always wanted. The income potential
of this opportunity is enormous and yet it is so simple and it pays
quickly!<br>
<br>
The cost is only $15 one time. <br>
<br>
I have to admit, the first time I saw this I was a procrastinator. I
didn't believe it would really work and left it lying on my desk to
follow up on &quot;sometime&quot;! One day I was in my office, got out a
calculator, started working the numbers and realized what a tremendous
opportunity this could be. I became extremely excited!<br>
<br>
What I love most about this program is that it only takes a few minutes
and then I can forget all about it! <br>
<br>
I'm sure you have seen old programs where you had to send cash by mail
and then mail the program information out to 20 or 50 or 100 people! You
were never sure if your cash arrived safely and you had to get letters
printed, address envelopes, stuff the letter in the envelope, put a stamp
on it and drive it to the post office.<br>
<br>
That has all changed with the INTERNET and E-GOLD. If you haven't used
e-gold yet, you are in for a real treat. It's called e-gold because it is
electronic currency and it is backed by real gold, not like our Federal
Reserve Notes that are not backed by anything! <br>
<br>
Payment is INSTANT and completely anonymous! I'll tell you how to open
your account a little later. (Goal #3 Set up a medium of exchange)<br>
<br>
This is the FASTEST, EASIEST program you will ever find. If you need
extra money next week, this is the opportunity you have been looking for.
There are no monthly fees. <br>
<br>
You are going to pay three people, $5 each -- a total of $15 -- to have
them put you on their email list so they can send you information
pertaining to future opportunities. (Goal #1 Develop a network) <br>
<br>
This keeps our program 100% legal: <br>
<br>
(Refer to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or
Title 18, Section 3005 in the US code, also in the code of federal
regulations, Volume 16, Sections 255 and 436.)<br>
<br>
You are paying to be put on a mailing list so that you can stay informed
to future opportunities.<br>
<br>
Now let's talk about Goal #2: INCREASING OUR CASH FLOW<br>
<br>
HOW DOES an extra $100, $500 and even THOUSANDS of dollars sound in the
NEXT TWO WEEKS? You can not lose if you will network this information
with others. ACT QUICKLY.<br>
<br>
The Response has been INCREDIBLE and FAST!<br>
<br>
----------------------------------------------------------------<br>
<br>
Testimonials:<br>
<br>
----------------------------------------------------------------<br>
<br>
I CAN'T BELIEVE IT!!! With under an hour of work I have made over US
$9,000 in the last three weeks...and my investment was just $15!!! <br>
Thank you<br>
Robert, Westminster, California<br>
<br>
----------------------------------------------------------------<br>
<br>
More than $6,000.00 has already been deposited to my e-gold
account...<br>
Mark, London, England<br>
<br>
----------------------------------------------------------------<br>
<br>
If you START TODAY, you could see results as soon as tomorrow, or even
later today! Remember, I said this program is quick and easy. You just
send out emails to your prospects and when they participate, money is
sent to your e-gold account and you can withdrawal you money
anytime.<br>
<br>
Send a few messages or send a lot. You decide how much money you need! It
is so easy to send an email and so easy to pay with e-gold that nearly
everyone jumps at this opportunity.<br>
<br>
If you only send out 20 emails and each of those people recognize the
gold (literally) they have in their hands -- you will have $100 deposited
to your e-gold account within days. If they each only send out 20 emails
and each of those 400 people recognize the gold in their hands, you will
have another $1,000 deposited, easily in TWO WEEKS OR LESS! If those 400
people each send only 20 emails and each of those people respond you
would have $40,000 deposited in your e-gold account! <br>
<br>
$15 equals $40,000! And if you received only 1/10th of that, you still
have $4,000. Is that worth an hour of your time. Remember, this is only
the beginning.<br>
<br>
NETWORKING - People getting together sharing ideas, information, and
resources. INTERNET NETWORKERS UNITE! <br>
<br>
Once you understand the power here, you will have to get your first batch
of emails out tonight or you won't be able to sleep!<br>
<br>
Send an email to everyone you know. Send email to everyone who sends an
email to you. They will be glad you did. Follow the simple instructions
and in weeks or even days you will have thousands of dollars in your
e-gold account. <br>
<br>
This program has a very HIGH RESPONSE RATE because it is fast, easy and
only costs $15.<br>
----------------------------------------------------------------<br>
<br>
FOLLOW THESE SIMPLE STEPS:<br>
<br>
1) Go to:
</font><a href="http://www.e-gold.com/" eudora="autourl"><font color="#0000FF"><u>http://www.e-gold.com/</a></font></u><font color="#000000">
and open an account, if you don't have one already. You will need to fund
your new account. You can do that on the e-gold site or use: <br>
<br>
</font><font color="#0000FF"><u><a href="http://www.goldchanger.com/" eudora="autourl">http://www.goldchanger.com</a></font></u><font color="#000000">
or <br>
</font><font color="#0000FF"><u><a href="http://golddirectory.com/" eudora="autourl">http://golddirectory.com</a></font></u><font color="#000000">
or <br>
</font><a href="http://pecb.com/gold-age" eudora="autourl"><font color="#0000FF"><u>http://pecb.com/gold-age</a></font></u><font color="#000000">
. <br>
<br>
They all charge a fee for converting your currency to gold so check and
see which best suits your needs. Be sure to put a little extra in your
account to cover e-gold's 1% transaction fees.<br>
<br>
2) Access your e-gold account and click on SPEND. Spend $5 to all three
e-gold accounts on the list that is at the end of this email, putting
'Networker' in the MEMO. <br>
<br>
NOTE: You don't have to wait for your name to rise to the top of the list
like you do in other programs. You start earning immediately!<br>
<br>
3) Delete the #1 account from the list. Move the other two numbers UP and
ADD YOUR e-gold account # to the list in the # 3 (BOTTOM) position.<br>
<br>
4) Send out as many copies of this letter as you can! REMEMBER, no
spamming! You probably get messages every day from people inviting you to
join their programs. Send them this email in return! <br>
<br>
Visit FFA links pages and bulletin boards. Respond to ads. When they send
you their information, answer back with this email! (Goal #4 Helping
Others)<br>
Your contact source is unlimited. It's so easy. THAT'S IT! To send your
letter by Email follow these instructions:<br>
<br>
1)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Go to
&quot;edit&quot; and &quot;select all&quot;<br>
2)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Go to
&quot;edit&quot; and &quot;copy&quot;<br>
3)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Start a new Email
message<br>
4)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Address your Email
and put &quot;Internet Networkers Unite&quot; or a Title of your choice
in the subject block<br>
5)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Put your cursor in
the body text area of the message and then Go to &quot;edit&quot; and
&quot;paste&quot;. After you have pasted this article to your new Email,
delete the old Subject, Date, To, From, Etc.<br>
6)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Go to where the
e-gold account numbers are listed. Delete the top account number and add
your account number to the bottom of the list as number 3. <br>
<br>
THAT'S IT! YOU'RE DONE, YOU'RE THROUGH! NO WAITING! You start collecting
your payments immediately. The payments will be sent to you by people
like yourself, who are willing to invest US$15 and less than one hour to
receive as much as US$40,000 or more in cash.<br>
<br>
If you don't receive all the cash you want within two weeks, simply send
out more emails.<br>
<br>
Fellow Networkers, this is a real opportunity and only the beginning!
There are many more high paying programs on the internet today, but if
you don't have the cash or a network of other like-minded people that's
all they are is just opportunities. You can do this - it's low cost, easy
and very lucrative!<br>
<br>
I Hope You Join us!!<br>
<br>
EMAIL YOUR LETTERS OUT TODAY - - -<br>
<br>
To recap:<br>
<br>
1.)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>JOIN E-Gold if you're not
a member yet<br>
2.)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>SPEND $5.00 to each
account on the list<br>
3.)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>REMOVE the account in #1
position from the list<br>
4.)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MOVE the other accounts
on the list up one position<br>
5.)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>ADD your own account in
position #3<br>
<br>
E-GOLD ACCOUNTS<br>
<br>
1. 140277<br>
2. 140282 <br>
3. 112938<br>
<br>
If you are new to e-gold, I recommend you spend some time on their web
site learning how the system works. Basically, once your account is open,
you can fund it by either having someone else transfer e-gold into your
account or by exchanging some of your currency into gold. After you have
collected a lot of e-gold, you may use it to pay bills, pay other people,
actually take delivery of gold or you can cash-out and be paid in
whatever currency you desire. One of the big advantages to using e-gold
is that it is international.<br>
<br>
It's EASY, It's FAST, but you do have to TAKE ACTION. Get started today.
You could see results within HOURS.<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font><br>
</html>

--=====================_9873425==_.ALT--



From list@netscape.com  Fri Jun  9 01:13:25 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25175
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 01:13:25 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5957ww24606;
	Thu, 8 Jun 2000 22:07:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e595C0g22791;
	Thu, 8 Jun 2000 22:12:00 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 22:12:00 -0700 (PDT)
Date: Fri, 9 Jun 2000 00:12:09 -0500
From: mlmhistory@ethos.st
Message-Id: <200006090512.AAA05000@crack.>
Reply-To: mlmhistory@ethos.st
To: mlmhistory@ethos.st
Subject: Private-Elite-Offshore-Banking-CyberClub
Resent-Message-ID: <"uUHauD.A.rjF.eyHQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Private-Elite-Offshore-Banking-CyberClub
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Yes, you've been hearing about this and seeing all the excitement
and all the Emails.  People are going NUTS over this...

Now it's time for you to do your due diligence...
many are flat out getting RICH with this hi-tech and
VERY unique opportunity...see for yourself just WHY.

Don't let this pass you by.

You are POTENTIALLY only 90 Days away from Total Financial Freedom.
                   
- Many have already earned $80,000 to $100,000 in just 8 weeks.
- Many at 5-Figure Income PER WEEK in 10 Weeks.

  (You will be able to talk to these ordinary folks)

Member Benefits Include:
- Your own Offshore Private Bank Account with ATM Debit Card.
- Encrypted Software for Private Online Banking anywhere in the 
  World.
- Member-Only access to International Financial Opportunities.
- Daily Direct Deposits into your Offshore Account.
- Withdraw cash at any ATM.
- Bulletproof Asset Protection.
- THE MOST POWERFUL COMPENSATION PLAN IN THE WORLD.
- Capitalize on Exponential Growth - 78 countries in only 12 Weeks.

Access to this Cyber-Club is by INVITATION ONLY.

For information and consideration Send an Email to:

mailto:autoreply@ethos.st?subject=CyberClub

Note:  Please make sure the word

  -    CyberClub    -  

is in the Subject Field. 

Click here and send:  mailto:autoreply@ethos.st?subject=CyberClub

---------------------------------------------------------------------------------------------------------------------------------


Please note:
PS -  THIS IS NOT A SPAM.  You have received this email 
because you have either sent us your offer or requested information
from us in the past thereby adding yourself on our in-house mailing list. 
We do not sell our lists to anyone.

Removal Instructions:  Reply to this Email and type  "Remove"   in the
Subject Field.   mailto:mlmhistory@ethos.st?subject=Remove

---------------------------------------------------------------------------------------------------------------------------------


Seize the Day.
Thanks,
Carpe Diem





From list@netscape.com  Fri Jun  9 02:16:08 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06177
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 02:16:07 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5967LO01652;
	Thu, 8 Jun 2000 23:07:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e596Eg204385;
	Thu, 8 Jun 2000 23:14:42 -0700 (PDT)
Resent-Date: Thu, 8 Jun 2000 23:14:42 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01EE5458@aspams01.cai.com>
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: "Subbu K. k." <KKSUBRAMANIAM@novell.com>, TGullotta@access360.com,
        ietf-ldapext@netscape.com, Martin.Rahm@nokia.com
Subject: RE: Intense LDAP write operations
Date: Fri, 9 Jun 2000 16:18:50 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"yIaH2.A.FEB.QtIQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

If you are worried about capacity and scaleability - well replicated systems
dont scale - Just consider the telephone system - we log on where we are and
use local calls, national calls and long distance calls - ie the
authentication base is distributed. X.500 is a distributed system in that it
forms a distributed system infrastructure.. ie one does not need to
replicate AU to the US, US to the UK and so on..

It seems odd that one would put a billion objects in one server and then
have to replicate this all over the place? Becuase one could not have a
distributed system.

In addition the real test for a directory is not lots of objects that
replicate - its the ability to have these objects distributed  - as well as
having a distributed service that can handle high user concurrency - eg 100s
of Ms of users - all logging on in seconds and all wanting directory service
information...in seconds.

In terms of design - with multi LDAP/DAP/DSP/DISP backbone load balancing /
alternate DSA modules - coupled to DSA processes, with one or more DBs, etc
- we can do fault tolerant, load balancing distributed/replicated meshed
based global directory services and integrate LDAP servers. So the issues of
read/write requirements is met in the operation system design of the
directory service..


Replicated systems... one only does this for fault tolerance.. If you
replicate names/passworrd/certs/CRLs, ACI for millions of entries all over
the world then - one will have a considerable security issue to deal with..

regards alan

-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com]
Sent: Thursday, June 08, 2000 7:33 PM
To: TGullotta@access360.com; ietf-ldapext@netscape.com;
Martin.Rahm@nokia.com
Subject: RE: Intense LDAP write operations


Not really. It is just that when you have millions of objects, they tend to
be read much more often than modified. For instance, when a user object is
created, it is read thousands of times before it gets updated.
Operationally, NDS does update its database internally for its replication
status etc. The last login time attribute does get updated for every login,
but this is an operational attribute.

NDS itself uses a transactional database to ensure full integrity and
incremental replication to ensure scalability. It has tested to hold more
than 1 billion objects on a single E450. As installed, it just takes less
than a megabyte for its database.

Subbu K. K.

>>> <TGullotta@access360.com> 06/07/00 09:08PM >>>
Subbu,

Has Novell done any benchmarks on read vs. write operations? It seems that
in a lot of directory implementations, although not every entry is being
updated that frequently, if you have a million or so users, just periodic
updates to entries could add up when you look at the total number of users.
I would think this is realistic. Is it a problem with NDS?

Tony Gullotta
Lead System Architect
access360


-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com] 
Sent: Wednesday, June 07, 2000 12:15 AM
To: ietf-ldapext@netscape.com; Martin.Rahm@nokia.com 
Subject: Re: Intense LDAP write operations


I dont think this was the sweet spot planned for directories. Writes would
entail applying locks on the data store which would impact the regular
search, retrieval and any sync operations. You also need to deal with
atomicity of updates to the group of attributes and the latency of
propagation of changes across multiple copies of the data store. A
transactional database may be a better choice.

Are you sure you need a directory service and not a transactional database
engine that supports LDAP in addition to SQL?

Subbu K. K
?---------------------------------------------
K. K. Subramaniam
Product Manager, Novell Directory Services (UNIX)
Novell

>>> <Martin.Rahm@nokia.com> 06/07/00 12:27PM >>>
Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm



From list@netscape.com  Fri Jun  9 03:15:17 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06916
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 03:15:16 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5976UO05156;
	Fri, 9 Jun 2000 00:06:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e597Dpk15565;
	Fri, 9 Jun 2000 00:13:51 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 00:13:51 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01EE58D3@aspams01.cai.com>
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: hahnt@us.ibm.com, ietf-ldapext@netscape.com
Subject: RE: Unidentified subject! LDAP updates
Date: Fri, 9 Jun 2000 17:18:01 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"jNrQv.A.zyD.tkJQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Some LDAP servers may be fast - and may be its becuase they are memory based
DITS - But if they power fail with lots of updates in the tubes they may
corrrupt their DIT.. Other approaches may use DBs without any DB commitment.
Others (ours) uses RDB technology (with 32 world patents on it) with 2 phase
commit.. So is fast really fast but no integrity .... and is slow - because
it does the job correctly...really slow..

I bet a 747 can go faster if one took out the life rafts and the life
support systems, etc!!!


I look at this issue this way.. If I was building a global bank,  a carrier
V-ISP system, an auto makers on line system, a government infrastructure for
10s if not 100s of millions of global EC customers who use the directory
service to authenticate (as globally distributed users) in milliseconds at
the rates of thousands a second -  because that is my business - eg ON LINE
services for my authenticated customers..to my back end services...

I would want to use a highly scaleable, industry standard, distributed
directory infrastructure (not a set of servers where they replicate
everything and manually index some attributes) - This service would/does
hold maybe 200 attributes per user - such as certs, Vip status, service
profiles, etc, etc.. so as a business I would know everything about them as
they logged on - in terms of their service privileges and status. 

So is the choice with LDAP servers - have a really fast update system with
no system scale, capacity or integrity - because you time protocol
interactions - or do you want the same reliability of a distributed
information system as provided by traditional RDBs.. a system that you put
all your customer information in so you can authenticate them quickly,
globally and with update integrity  and get revenue for the best on line EC
service..

After all - the last thing any company wants to do is invest in a global
online EC service strategy and then get their three/ten million customers on
line - to then find the directory used - crashes and burns....


" I just spent twenty years growing my business to 20m customers... and when
I built my on line EC system for them with a cheap low integrity
directory... I lost them all in 10 seconds..."


Please consider...

Somethings are normally faster because they have left something out..eg
integrity..

ie do any of these "fast update tests" apply access controls, DIT schema and
structure tests,, ????



regards alan

-----Original Message-----
From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com]
Sent: Wednesday, June 07, 2000 7:21 PM
To: ietf-ldapext@netscape.com
Subject: Unidentified subject!


Greetings,

In general, due to the wide variety of database engine implementations on
which different LDAP
directories are based, it is safe to say that 'your mileage may vary'.  As
everyone has indicated,
update performance is related to all the extra things a directory server
might do as a result
of the modify operation.  What these things are is dependent upon the
underlying database
implementation upon which the directory is based.

Thus, some existing implementations may offer fast update performance while
others may not.

> Hi,
>
> I am working on a problem where LDAP would be used to keep a directory
with
> user data.  One concern I have is that LDAP is supposed to be less
efficient
> when it comes to intense write operations.
>
> Can LDAP handle millions of users data in a directory where some of the
data
> (a few attributes) needs to be updated very frequently?  How would that
> affect performance and is LDAP effective when the searched data must be
> returned prompty with very little delay?
>
> If anyone has any comments on this, I would appreciate it,
>
> Martin Rahm

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



From list@netscape.com  Fri Jun  9 04:27:38 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07458
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 04:27:38 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e598M8w07852;
	Fri, 9 Jun 2000 01:22:08 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e598QAU02168;
	Fri, 9 Jun 2000 01:26:10 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 01:26:10 -0700 (PDT)
Reply-To: "Colin.Robbins" <Colin.Robbins@nexor.com>
From: Colin Robbins <Colin.Robbins@nexor.com>
To: "'kfenley'" <kfenley@ozemail.com.au>, "'hahnt'" <hahnt@us.ibm.com>,
        "'ietf-ldapext'" <ietf-ldapext@netscape.com>
Subject: RE: Unidentified subject! LDAP search times and databases
Date: Fri, 9 Jun 2000 09:25:35 +0100
Message-ID: <000f01bfd1ec$49529860$ea353fc1@nexor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <NEBBLECJGLMAGGDFLPDOAENDCAAA.kfenley@ozemail.com.au>
Resent-Message-ID: <"Eu5q7B.A.gh.goKQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

>
> I know one only one LDAP Directory that overcomes all these
> issues and runs
> on an industrial strength backend DB which provides
> predictable sub-second
> searches, full rollback, auditing and logging and has 30+
> patents on the use
> of a RDBMS for Directories.

Sorry folks, I really don't like using this lists for vendor messages, but
OpenDirectory is not the only product in the world with an industrial
strength backed DB overcoming these problems.   There are several.

> This is why the other vendors
> who use RDMBS
> technology are unable to compete, as they have to use
> standard SQL calls.
> The Patents cover how you use a standard RDBMS as an OO D/B
> without the SQL
> row and Column problem and this is where the high search
> times from a RDBMS
> come from.

If I understand this correctly, you are saying you have several patents to
implement an OODB on top of a RDBMS.  The implication is you need an OODB to
implement an efficient LDAP Directory.

I certainly agree with the implication.  This is why at NEXOR we decided to
implement our Directory product using an industrial strength OODB from
Versant Technologies (http://www.versant.com).  This approach has all the
benefits you refer to, with the added advantage on not having the overhead
of mapping onto a RDBMS.

As to the original question posted - this approach of using an OODB, enables
us to manage "intense write" scenarios, with very little impact upon search
performance.   You only get a blockage if the attribute being modified, is
the target of a concurrent search and pointed to be the search index - the
DSA needs to wait for a read lock to check the attribute.  In our experience
this occurrence is rare.

Once again, sorry for using this list for a vendor message, but I fell
compelled to respond when I see messages suggesting there is only one good
product in the world.

Colin Robbins
NEXOR

Tel:  +44 115 952 0583
Email:  Colin.Robbins@nexor.com
WWW:  http://www.nexor.com



From list@netscape.com  Fri Jun  9 07:45:35 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09049
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 07:45:35 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59BahO21072;
	Fri, 9 Jun 2000 04:36:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59Bi4w14542;
	Fri, 9 Jun 2000 04:44:04 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 04:44:04 -0700 (PDT)
From: "Alexis Bor" <alexis.bor@directoryworks.com>
To: "Colin.Robbins" <Colin.Robbins@nexor.com>,
        "'kfenley'" <kfenley@ozemail.com.au>, "'hahnt'" <hahnt@us.ibm.com>,
        "'ietf-ldapext'" <ietf-ldapext@netscape.com>
Subject: RE: Unidentified subject! LDAP search times and databases
Date: Fri, 9 Jun 2000 07:44:08 -0400
Message-ID: <NDBBIIDPMPGNNDBGKGAJOECIDBAA.alexis.bor@directoryworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <000f01bfd1ec$49529860$ea353fc1@nexor.co.uk>
Resent-Message-ID: <"OrGKyC.A.ziD.CiNQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Out of curiosity, have you tried this with a server that has, let's say
10,000,000 entries in it and trying to add entries with 100 or so
attributes?  How fast can you do that?  Cache management starts to get in
your way, since you won't have enough memory on your system, not to mention
specific operating system overhead that kicks in.

I did a couple of years ago and it left me wondering...And I hope that
people have looked into this since then...

-- Alexis

Alexis Bor
Directory Works, Inc.
alexis.bor@directoryworks.com
http://www.directoryworks.com

-----Original Message-----
From: Colin Robbins [mailto:Colin.Robbins@nexor.com]
Sent: Friday, June 09, 2000 4:26 AM
To: 'kfenley'; 'hahnt'; 'ietf-ldapext'
Subject: RE: Unidentified subject! LDAP search times and databases

>
> I know one only one LDAP Directory that overcomes all these
> issues and runs
> on an industrial strength backend DB which provides
> predictable sub-second
> searches, full rollback, auditing and logging and has 30+
> patents on the use
> of a RDBMS for Directories.

Sorry folks, I really don't like using this lists for vendor messages, but
OpenDirectory is not the only product in the world with an industrial
strength backed DB overcoming these problems.   There are several.

> This is why the other vendors
> who use RDMBS
> technology are unable to compete, as they have to use
> standard SQL calls.
> The Patents cover how you use a standard RDBMS as an OO D/B
> without the SQL
> row and Column problem and this is where the high search
> times from a RDBMS
> come from.

If I understand this correctly, you are saying you have several patents to
implement an OODB on top of a RDBMS.  The implication is you need an OODB to
implement an efficient LDAP Directory.

I certainly agree with the implication.  This is why at NEXOR we decided to
implement our Directory product using an industrial strength OODB from
Versant Technologies (http://www.versant.com).  This approach has all the
benefits you refer to, with the added advantage on not having the overhead
of mapping onto a RDBMS.

As to the original question posted - this approach of using an OODB, enables
us to manage "intense write" scenarios, with very little impact upon search
performance.   You only get a blockage if the attribute being modified, is
the target of a concurrent search and pointed to be the search index - the
DSA needs to wait for a read lock to check the attribute.  In our experience
this occurrence is rare.

Once again, sorry for using this list for a vendor message, but I fell
compelled to respond when I see messages suggesting there is only one good
product in the world.

Colin Robbins
NEXOR

Tel:  +44 115 952 0583
Email:  Colin.Robbins@nexor.com
WWW:  http://www.nexor.com



From list@netscape.com  Fri Jun  9 08:11:09 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09566
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 08:11:08 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59C5gw21919;
	Fri, 9 Jun 2000 05:05:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59C9iM20555;
	Fri, 9 Jun 2000 05:09:44 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 05:09:44 -0700 (PDT)
Message-Id: <s9408a23.091@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 09 Jun 2000 03:41:08 -0600
From: "Subbu K. k." <KKSUBRAMANIAM@novell.com>
To: <alan.lloyd@ca.com>, <ietf-ldapext@netscape.com>
Subject: RE: Intense LDAP write operations
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e59C9f120523
Resent-Message-ID: <"yZoXTD.A.xAF.G6NQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

[Moderator, I am not sure if I am violating the intent of this list in continuing this discussion. If so, pls. let me know and I can take this on a separate discussion group. Thanks in advance]

Alan,

Actually, the exercise was taken to see how far we could push the limits before eDirectory breaks down (It didnt, in this case. We had to stop the exercise at 1+ billion objects to show it in an event).

Billion objects may sound like a lot today but so did 640KB of address space for PCs in 1984!

Not all entries need necessarily be personal secrets. In your specific example, it does makes sense to have a global directory for mobile phone numbers (projected to cross 1 billion by 2003) that is updated by regional admins but seen as one by the mobile phone owners. Global knowledge bases like Human Genome will contain about 3 billion codes. Replication may take a 'long' time and may even be filtered, but since they dont change much, it makes sense to have the directory automatically replicate this where scientists actually need them.

I dont think the assumption that there is a trade-off between (capacity,concurrency,search time) is necessarily true. With proper design (as in NDS eDirectory) that exploits the usage pattern for directories, it is possible to retain essentially flat search times thru hundreds of millions of entries.

Subbu K. K.
>>> "Lloyd, Alan" <Alan.Lloyd@ca.com> 06/09/00 11:45AM >>>
If you are worried about capacity and scaleability - well replicated systems
dont scale - Just consider the telephone system - we log on where we are and
use local calls, national calls and long distance calls - ie the
authentication base is distributed. X.500 is a distributed system in that it
forms a distributed system infrastructure.. ie one does not need to
replicate AU to the US, US to the UK and so on..

It seems odd that one would put a billion objects in one server and then
have to replicate this all over the place? Becuase one could not have a
distributed system.

In addition the real test for a directory is not lots of objects that
replicate - its the ability to have these objects distributed  - as well as
having a distributed service that can handle high user concurrency - eg 100s
of Ms of users - all logging on in seconds and all wanting directory service
information...in seconds.

In terms of design - with multi LDAP/DAP/DSP/DISP backbone load balancing /
alternate DSA modules - coupled to DSA processes, with one or more DBs, etc
- we can do fault tolerant, load balancing distributed/replicated meshed
based global directory services and integrate LDAP servers. So the issues of
read/write requirements is met in the operation system design of the
directory service..


Replicated systems... one only does this for fault tolerance.. If you
replicate names/passworrd/certs/CRLs, ACI for millions of entries all over
the world then - one will have a considerable security issue to deal with..

regards alan

-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com] 
Sent: Thursday, June 08, 2000 7:33 PM
To: TGullotta@access360.com; ietf-ldapext@netscape.com;
Martin.Rahm@nokia.com 
Subject: RE: Intense LDAP write operations


Not really. It is just that when you have millions of objects, they tend to
be read much more often than modified. For instance, when a user object is
created, it is read thousands of times before it gets updated.
Operationally, NDS does update its database internally for its replication
status etc. The last login time attribute does get updated for every login,
but this is an operational attribute.

NDS itself uses a transactional database to ensure full integrity and
incremental replication to ensure scalability. It has tested to hold more
than 1 billion objects on a single E450. As installed, it just takes less
than a megabyte for its database.

Subbu K. K.

-------------------
K. K. Subramaniam,                                                
Product Manager, NDS eDirectory (UNIX/Linux)
Novell Software, Bangalore                                  Ph: +91 (80) 572-1856x2212

>>> <TGullotta@access360.com> 06/07/00 09:08PM >>>
Subbu,

Has Novell done any benchmarks on read vs. write operations? It seems that
in a lot of directory implementations, although not every entry is being
updated that frequently, if you have a million or so users, just periodic
updates to entries could add up when you look at the total number of users.
I would think this is realistic. Is it a problem with NDS?

Tony Gullotta
Lead System Architect
access360


-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com] 
Sent: Wednesday, June 07, 2000 12:15 AM
To: ietf-ldapext@netscape.com; Martin.Rahm@nokia.com 
Subject: Re: Intense LDAP write operations


I dont think this was the sweet spot planned for directories. Writes would
entail applying locks on the data store which would impact the regular
search, retrieval and any sync operations. You also need to deal with
atomicity of updates to the group of attributes and the latency of
propagation of changes across multiple copies of the data store. A
transactional database may be a better choice.

Are you sure you need a directory service and not a transactional database
engine that supports LDAP in addition to SQL?

Subbu K. K
?---------------------------------------------
K. K. Subramaniam
Product Manager, Novell Directory Services (UNIX)
Novell

>>> <Martin.Rahm@nokia.com> 06/07/00 12:27PM >>>
Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm



From list@netscape.com  Fri Jun  9 08:18:00 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09723
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 08:17:59 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59CCXw22801;
	Fri, 9 Jun 2000 05:12:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59CGZw22541;
	Fri, 9 Jun 2000 05:16:35 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 05:16:35 -0700 (PDT)
Reply-To: "Colin.Robbins" <Colin.Robbins@nexor.com>
From: Colin Robbins <Colin.Robbins@nexor.com>
To: "'Alexis Bor'" <alexis.bor@directoryworks.com>,
        "'kfenley'" <kfenley@ozemail.com.au>, "'hahnt'" <hahnt@us.ibm.com>,
        "'ietf-ldapext'" <ietf-ldapext@netscape.com>
Subject: RE: Unidentified subject! LDAP search times and databases
Date: Fri, 9 Jun 2000 13:16:02 +0100
Message-ID: <003101bfd20c$7bd1a2c0$ea353fc1@nexor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <NDBBIIDPMPGNNDBGKGAJOECIDBAA.alexis.bor@directoryworks.com>
Resent-Message-ID: <"yhQZP.A.yfF.iAOQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

No, we have not tried that specific test, but it would be fun to try.
If you want to try it out in your test rig, I am sure we can get you the
software...

If such a test were performed, I have every confidence that the object
caching model of the Versant OODB would provide excellent results.

Colin

> -----Original Message-----
> From: Alexis Bor [mailto:alexis.bor@directoryworks.com]
> Sent: 09 June 2000 12:44
> To: Colin.Robbins; 'kfenley'; 'hahnt'; 'ietf-ldapext'
> Subject: RE: Unidentified subject! LDAP search times and databases
>
>
> Out of curiosity, have you tried this with a server that has,
> let's say
> 10,000,000 entries in it and trying to add entries with 100 or so
> attributes?  How fast can you do that?  Cache management
> starts to get in
> your way, since you won't have enough memory on your system,
> not to mention
> specific operating system overhead that kicks in.
>
> I did a couple of years ago and it left me wondering...And I hope that
> people have looked into this since then...
>
> -- Alexis
>
> Alexis Bor
> Directory Works, Inc.
> alexis.bor@directoryworks.com
> http://www.directoryworks.com
>



From list@netscape.com  Fri Jun  9 08:57:14 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10583
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 08:57:14 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59CmLO26030;
	Fri, 9 Jun 2000 05:48:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59Ctgo00925;
	Fri, 9 Jun 2000 05:55:42 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 05:55:42 -0700 (PDT)
From: "Alexis Bor" <alexis.bor@directoryworks.com>
To: "Colin.Robbins" <Colin.Robbins@nexor.com>,
        "'kfenley'" <kfenley@ozemail.com.au>, "'hahnt'" <hahnt@us.ibm.com>,
        "'ietf-ldapext'" <ietf-ldapext@netscape.com>
Subject: RE: Unidentified subject! LDAP search times and databases
Date: Fri, 9 Jun 2000 08:55:42 -0400
Message-ID: <NDBBIIDPMPGNNDBGKGAJMECJDBAA.alexis.bor@directoryworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <003101bfd20c$7bd1a2c0$ea353fc1@nexor.co.uk>
Resent-Message-ID: <"rI5HsB.A.FO.NlOQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Colin,
I don't have access to that test system at the moment, but next time I do,
I'll keep it in mind.  I suspect that it will work well, based on what I
know about Versant and some other factors, but it would be fun to see...

-- Alexis

Alexis Bor
Directory Works, Inc.
alexis.bor@directoryworks.com
http://www.directoryworks.com

-----Original Message-----
From: Colin Robbins [mailto:Colin.Robbins@nexor.com]
Sent: Friday, June 09, 2000 8:16 AM
To: 'Alexis Bor'; 'kfenley'; 'hahnt'; 'ietf-ldapext'
Subject: RE: Unidentified subject! LDAP search times and databases

No, we have not tried that specific test, but it would be fun to try.
If you want to try it out in your test rig, I am sure we can get you the
software...

If such a test were performed, I have every confidence that the object
caching model of the Versant OODB would provide excellent results.

Colin

> -----Original Message-----
> From: Alexis Bor [mailto:alexis.bor@directoryworks.com]
> Sent: 09 June 2000 12:44
> To: Colin.Robbins; 'kfenley'; 'hahnt'; 'ietf-ldapext'
> Subject: RE: Unidentified subject! LDAP search times and databases
>
>
> Out of curiosity, have you tried this with a server that has,
> let's say
> 10,000,000 entries in it and trying to add entries with 100 or so
> attributes?  How fast can you do that?  Cache management
> starts to get in
> your way, since you won't have enough memory on your system,
> not to mention
> specific operating system overhead that kicks in.
>
> I did a couple of years ago and it left me wondering...And I hope that
> people have looked into this since then...
>
> -- Alexis
>
> Alexis Bor
> Directory Works, Inc.
> alexis.bor@directoryworks.com
> http://www.directoryworks.com
>



From list@netscape.com  Fri Jun  9 09:49:23 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11592
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 09:49:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59Dhuw29558;
	Fri, 9 Jun 2000 06:43:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59Dlwc13730;
	Fri, 9 Jun 2000 06:47:58 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 06:47:58 -0700 (PDT)
From: "Alexis Bor" <alexis.bor@directoryworks.com>
To: "Lloyd, Alan" <Alan.Lloyd@ca.com>,
        "Subbu K. k." <KKSUBRAMANIAM@novell.com>, <TGullotta@access360.com>,
        <ietf-ldapext@netscape.com>, <Martin.Rahm@nokia.com>
Subject: RE: Intense LDAP write operations
Date: Fri, 9 Jun 2000 09:48:02 -0400
Message-ID: <NDBBIIDPMPGNNDBGKGAJKECMDBAA.alexis.bor@directoryworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <E7E4455BFFB4D311BC78009027D0D18C01EE5458@aspams01.cai.com>
Resent-Message-ID: <"kvQ5YD.A.KWD.NWPQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Alan,
You said that replicated systems are for fault tolerance only.  I don't
think you would agree with yourself on that point.  You are totally ignoring
the need for increasing capacity.  The bottlenecks are not only the
computing system that the directory is running on, but also the
infrastructure itself.  For example, the network is a bottleneck at some
point and if you are looking for increasing response time, then the packet
queuing time to transition the network is significant as well.  The internet
is a great example of unpredictable queuing time - we all see that some days
are worse than others - which is not acceptable for a directory when it is
used as part of the infrastructure services.

-- Alexis

Alexis Bor
Directory Works, Inc.
alexis.bor@directoryworks.com
http://www.directoryworks.com

-----Original Message-----
From: Lloyd, Alan [mailto:Alan.Lloyd@ca.com]
Sent: Friday, June 09, 2000 2:19 AM
To: Subbu K. k.; TGullotta@access360.com; ietf-ldapext@netscape.com;
Martin.Rahm@nokia.com
Subject: RE: Intense LDAP write operations

(text deleted)

Replicated systems... one only does this for fault tolerance.. If you
replicate names/passworrd/certs/CRLs, ACI for millions of entries all over
the world then - one will have a considerable security issue to deal with..

regards alan





From list@netscape.com  Fri Jun  9 14:49:07 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17171
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 14:49:06 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59Ie5O07396;
	Fri, 9 Jun 2000 11:40:06 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59IlRY05741;
	Fri, 9 Jun 2000 11:47:27 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 11:47:27 -0700 (PDT)
From: <45dsfsdafFH@camilla.inf.hist.no>
To: <ietf-ldapext@netscape.com>
Date: Wed, 7 Jun 2000 11:08:42
Message-Id: <190.643629.621675@mail.mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"j-rmTD.A.RZB.-uTQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more PER MONTH  TODAY for your web site, 
WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

WE HAVE BOTH UNIX AND NT MACHINES WITH FRONT PAGE EXTENSIONS 
FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  or fax 240 337 8325

PES WEB HOSTING -- 
_______________________________________________________________

Want to do bulk email?

Ask us how today!

GET YOUR MESSAGE DELIVERED TO 500,000 PEOPLE FOR ONLY $550.00.

OR HAVE YOUR MESSAGE DELIVERED TO OVER 1 MILLION 
PEOPLE FOR ONLY $1200.00.

Call 1888 248 0765 for FURTHER INFORMATION today!
  or fax 240 337 8325

_________________________________________________________________

Get your own offshore trust! 
PROTECT YOUR PERSONAL ASSETS FROM LAWSUITS or Do SOME ESTATE 
PLANNING TO MINIMIZE THOSE INHERITANCE TAXES!
GET THAT OFFSHORE BANK ACCOUNT YOU ALWAYS WANTED!

For further information please fax 240 337 8325




THANK YOU



 
 
 
 
 
 
 
 
 
 



From list@netscape.com  Fri Jun  9 15:52:43 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18143
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 15:52:42 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59Jl7w25610;
	Fri, 9 Jun 2000 12:47:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59JpAU03343;
	Fri, 9 Jun 2000 12:51:10 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 12:51:10 -0700 (PDT)
From: John_Payne@motorcity2.lotus.com
X-Lotus-FromDomain: NOTES@ALPHABETA
Sender: John_Payne@motorcity2.lotus.com
To: ietf-ldapext@netscape.com
Message-ID: <852568F9.006C182E.00@motorcity2.lotus.com>
Date: Fri, 9 Jun 2000 14:52:04 -0400
Subject: RE: Intense LDAP write operations (sort of)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Resent-Message-ID: <"S_h4lC.A.1z.sqUQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



O.K. This may be getting a little bit off-topic, but this discussion about
replication, intense write operations etc. does raise one very good issue.
Tuning such a distributed/replicated information base is a very complex and
ongoing activity based on changing usage patterns, volatility of the information
etc. etc.  I have seen very little discussion here about statistics gathering
and monitoring/management of the directory.  Is there another RFC/mailing list
for this topic?




From list@netscape.com  Fri Jun  9 16:17:03 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18374
	for <ldapext-archive@odin.ietf.org>; Fri, 9 Jun 2000 16:17:02 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e59KBWw29758;
	Fri, 9 Jun 2000 13:11:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e59KFYw13122;
	Fri, 9 Jun 2000 13:15:34 -0700 (PDT)
Resent-Date: Fri, 9 Jun 2000 13:15:34 -0700 (PDT)
Date: Fri, 09 Jun 2000 15:14:18 -0500
From: Mark Wahl <M.Wahl@innosoft.com>
Subject: Re: Intense LDAP write operations (sort of)
In-reply-to: "Your message of Fri, 09 Jun 2000 14:52:04 EDT."
 <852568F9.006C182E.00@motorcity2.lotus.com>
Sender: wahl@austin.innosoft.com
To: John_Payne@motorcity2.lotus.com
Cc: ietf-ldapext@netscape.com
Message-id: <18245.960581658@threadgill.austin.innosoft.com>
Resent-Message-ID: <"ahQfZD.A.qMD.kBVQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


The MADMAN working group covered Messaging and Directory server monitoring,
and have published a few MIBs for this purpose.  If you have additional 
ideas for server variables to be monitored, I would recommend checking with
the chairs of this WG to see how best to go about exploring this.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance



From list@netscape.com  Sat Jun 10 04:19:27 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07064
	for <ldapext-archive@odin.ietf.org>; Sat, 10 Jun 2000 04:19:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5A8Dpw02947;
	Sat, 10 Jun 2000 01:13:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5A8Hrg07046;
	Sat, 10 Jun 2000 01:17:53 -0700 (PDT)
Resent-Date: Sat, 10 Jun 2000 01:17:53 -0700 (PDT)
Date: Sat, 10 Jun 2000 01:17:49 -0700 (PDT)
Message-Id: <200006100817.e5A8Hmc06666@ywing.netscape.com>
From: <Douglas.Hoyt.Douglas_Hoyt@excite.com>
To: ietf-ldapext@netscape.com
Subject:  ietf-ldapext Please check out this new Internet Opportunity!
X-Reply-To:  Douglas_Hoyt@excite.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"m5u3hB.A.utB.vmfQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

 I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail 
in error, or you are no longer interested, please reply with "remove" in the subject.  Thank you.

Hi, 
My name is Doug Hoyt and I would like to share a genuine, NO RISK opportunity with you. Skeptical 
already?
Good! 

Unlike other internet opportunities that you might have seen, what I have to share with you invites close 
scrutiny - even with a skeptical eye. It is first and foremost a CONSUMER OPPORTUNITY. 

It also offers you the ability to have a share of a new Internet Mall to buy at wholesale for yourself or to 
send others to and make commissions on their purchases. 

Besides this, it also offers a unique and innovative networking program using a principle we call 
"REFERNET" Marketing. No hyped "pie in the sky" program or "get rich quick" scheme, but rather a credible 
and realistic way to save money and gradually develop what can become a large, recurring residual 
income. 

The best thing about this opportunity? You can "try it before you buy it". That's right. You  can join the  Club 
for FREE with no risk or obligation. As a Club Member, you will be able to shop at our membership
mall.  You will also be able be entered into Postlaunch and receive a FREE position in the Club's network. 
Watch as others join your downline and see how our innovative network building program works. 

To learn more about the Club and our exciting REFERNET Marketing Program and Postlaunch, visit my web 
page at http://www.expage.com/hoytassociatesinc 

Remember, you have nothing to lose and potentially a lot to gain! 

Thank you.
Doug Hoyt 




From list@netscape.com  Sat Jun 10 11:49:57 2000
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09375
	for <ldapext-archive@odin.ietf.org>; Sat, 10 Jun 2000 11:49:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5AFeTO04426;
	Sat, 10 Jun 2000 08:40:29 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5AFlq619604;
	Sat, 10 Jun 2000 08:47:52 -0700 (PDT)
Resent-Date: Sat, 10 Jun 2000 08:47:52 -0700 (PDT)
Date: Sat, 10 Jun 2000 08:47:38 -0700 (PDT)
Message-Id: <200006101547.e5AFlc924268@xwing.netscape.com>
From: moneyman@williesmail.com
To: 487lskjhf79.RQVF@netscape.com
Subject:  please read   -  my appologies 4 the multiple messages - server error
X-Reply-To:  moneyman@williesmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"CXKaoC.A.wxE.nMmQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hi my Friend, 
	 
	We have corresponded before, and I have found an unbeatable business opportuntiy 
that I just had to share with you. Please look-

Lets get strait to the facts:
 
*Guaranteed $10,000+ for you in only 2 months time after you meet 2 VERY EASY requirements 
that you can take care of in one day. Plus a sufficient amount of consistent, monthly residual 
income checks that will sustain you for the rest of your life. All this for a small once a year 
investment. And the opportunity to recieve $100,000+ in your first year.

* This company has the FIRST pay plan of its kind to be copyrighted with a patent pending in 
the U.S. Patent and Trademark Office. The company is growing at 6,224%. This business is 
offering $5,000 to anyone who shows them a better pay plan- . This lets you know from the start 
that this company means business. BIG TIME.

* NO:  Employers, employees, collections, quotas, inventories, deliveries , commuting, 
complicated paperwork, No EXPERIENCE NECESSARY

*YES:  Immediate cash, low start-up cost, speedy success system, tax benifits, total 
diversification

Do this  EASY home business ,when after you complete your 2 easy requirements, you will never 
think about working again. Period. You will be able to retire. Now, you have alot more time to 
enjoy your your family and hobbies.  Sound nice? Take the advantage of this "safe, guaranteed" 
bussiness opportunity. If you are tired of your job, working long hours, living from paycheck to 
paycheck, or wouldn't mind more monthly income: send an email back to me at   
moneyman@williesmail.com   with " send  info" typed in the subject line. Don't think " it sounds 
too good to be true" and delete this email before you look into this incredible opportunity. Trust 
me. You will be glad you did. I promise. - Even if you're content with your job/career,  you should 
never pass up a GUARANTEED $10,000+ in 2  months, and the opportunity to recieve $100,000+ 
in your first year. This is like no opportunity that you have ever seen. You will be amazed and 
excited. Please reply at your earliest convenience, every day you delay is worth a considerable 
amount of money...  

Again, I appologise for the multiple messages- server error.


-------------------------------------------------------------------------------------------------------------------------------
This is a one time email. No need to ask to be removed. I will never send you anything again, 
unless you request information from me.  Thank you.
 ------------------------------------------------------------------------------------------------------------------------------




From list@netscape.com  Sat Jun 10 20:53:24 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11688
	for <ldapext-archive@odin.ietf.org>; Sat, 10 Jun 2000 20:53:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5B0lNw11583;
	Sat, 10 Jun 2000 17:47:23 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5B0pQk12341;
	Sat, 10 Jun 2000 17:51:26 -0700 (PDT)
Resent-Date: Sat, 10 Jun 2000 17:51:26 -0700 (PDT)
Date: Sat, 10 Jun 2000 17:51:18 -0700 (PDT)
Message-Id: <200006110051.e5B0pHc26716@ywing.netscape.com>
From: thislink@thislink.com
To: @netscape.com
Subject:  Free products and resources
X-Reply-To:  thislink@thislink.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"REUmCD.A.PAD.MKuQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Free at www.thislink.com - products, ads, recipes, golf, gardening, health, computers, and 
more. Please stop by and visit the many resources, tips, and services that we have to offer. 
Shopping at www.thislink.com benefits charity! 
Thank you and have a nice day... 

I received your e-mail as someone that might be interested in the above information. If this 
message has reached you by mistake, please forgive the intrusion. If I received your e-mail in 
error, or you are no longer interested, please reply with "remove" in the subject to 
unsubscribe@thislink.com 




From list@netscape.com  Sat Jun 10 22:07:41 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12896
	for <ldapext-archive@odin.ietf.org>; Sat, 10 Jun 2000 22:07:40 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5B21Ww14684;
	Sat, 10 Jun 2000 19:01:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5B25aM27962;
	Sat, 10 Jun 2000 19:05:36 -0700 (PDT)
Resent-Date: Sat, 10 Jun 2000 19:05:36 -0700 (PDT)
Date: Sun, 11 Jun 2000 11:04:11 +0900
Message-ID: <B0000006537@www.webjin.co.kr>
To: fd09@jkflap.com.netscape.com
From: <markallen@HotPOP.com>
Subject: Find Out Any Info From Your PC!!!
Resent-Message-ID: <"tIlb3D.A.i0G.uPvQ5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com




"THE INTERNET SPY AND YOU 2000"

Shows you how to get the facts on anyone.

CONFIDENTIAL
The SOFTWARE They Wanted BANNED In all 50 States! Why?  Because these secrets were never intended to reach your eyes....

Get the facts on anyone using the Internet!
Locate Missing Persons, find Lost Relatives, obtain Addresses and 
Phone Numbers of old school friends, even Skip Trace Dead Beat Spouses. This is not a Private Investigator, but a sophisticated SOFTWARE program DESIGNED to automatically CRACK YOUR CASE with links to thousands of Public record databases. Find out SECRETS about your relatives, friends, enemies, and everyone else! -- even your spouse!  With the New INTERNET SPY AND YOU - 2000

It's absolutely astounding!  Here's some of what you can learn:

License plate numbers!
Get anyone's name and address with just a license plate number! 
(Find that girl you met in traffic!)

DRIVING RECORDS!
Get anyone's driving record!

Social security number!
Trace anyone by social security number!

ADDRESSES!
Get anyone's address with just a name!

Unlisted phone numbers!
Get anyone's phone number with just a name-even unlisted numbers!

LOCATE!
Long lost friends, relatives, a past lover who broke your heart!
Now with Full Internet Search.

E-mail!
Send anonymous e-mail completely untraceable!

Dirty secrets!
Discover dirty secrets your in-laws don't want you to know!

Investigate anyone!
Use the source that private investigators use (all on the Internet) secretly!

Ex-spouse!
Learn how to get information on an ex-spouse that will help you win in court!  (Dig up old skeletons)

Criminal search-Backround check!
Find out about you daughters boyfriend! (or her husband)

Neighbors!
Learn all about your mysterious neighbors!  Find out what they have to hide!

People you work with!
Be astonished by what you'll learn about people you work with!

Education verification!
Did he really graduate college?  Find out!

INTERNET SPY AND YOU 2000
Software will help you discover ANYTHING about anyone, with clickable hyperlinks and no typing in Internet addresses!

Just insert our floppy disk and Go!

It's INCREDIBLE what you can find out using Internet Spy and You 2000 and the Internet!  You'll be riveted 
to your computer screen!  The software they're trying to ban!  Before it's too late!

LIMITED TIME OFFER: ORDER TODAY!
Only $15.00 US (Postage Paid)

WORKS WITH ALL BROWSERS AND ALL VERSIONS OF AOL!

ORDER TODAY:
SEND Only $15.00 US
(CASH, CHECK, OR MONEY ORDER)
(ARIZONA RESIDENTS ADD 7% ARIZONA STATE SALES TAX)


(ORDERS OUTSIDE THE USA, ADD $5.00 and must send US CASH, No checks, no money orders!)


TO:
N Duran
Dept U1
PO BOX  8051
Mesa, AZ  85214-8051

(ALL ORDERS MAILED WITHIN 48 HOURS OF RECEIVING THEM)

MAKE YOUR CHECK PAYABLE TO:
N DURAN

(Please Print Clearly Your Name and Address)
                                                                                   
Name__________________________________________

Address________________________________________

City/State/ZIP___________________________________

E-mail Address__________________________________



SORRY NO MAC VERSION AVAILABLE AT THIS TIME.
THIS PROGRAM WILL NOT WORK WITH M/S 3.11 AND OLDER.

Copyright © 1998-1999 
All Rights Reserved
**********************************************************************
THIS MAILING IS DONE BY AN INDEPENDENT MARKETING CO.
To be removed from our mailing list please
send an email to: c100@HotPOP.com    
and place remove in the subject
Thank you
*********************************************************




From list@netscape.com  Sun Jun 11 20:28:23 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10415
	for <ldapext-archive@odin.ietf.org>; Sun, 11 Jun 2000 20:28:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5C0Kfw22902;
	Sun, 11 Jun 2000 17:20:41 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5C0Ojs28490;
	Sun, 11 Jun 2000 17:24:45 -0700 (PDT)
Resent-Date: Sun, 11 Jun 2000 17:24:45 -0700 (PDT)
X-Sender: hilal@kanafani.club24.co.uk
From: "hilal@kanafani.club24.co.uk" <hilal@kanafani.club24.co.uk>
To: "Opt-In List 1" <hilal@kanafani.club24.co.uk>
Date: Mon, 12 Jun 2000 01:22:09 +0100
Subject: Who Needs To Win The Lottery?
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <E131I0H-0003fo-00@mailhost.netscapeonline.co.uk>
Resent-Message-ID: <"ng5bIB.A.w8G.M3CR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

How would you like to make $5.5Million with a $38 investment?

Ofcourse you would....I mean who wouldn't!?!?!

The question is...HOW???

Well guess what I have the answer, and I bet you don't believe me.
That's okay, I wouldn't believe me either, but IT'S TRUE!!

Check it out for yourself....all you have to do is reply to this message with
"SHOW ME THE MONEY" as the subject and I will tell you how. What have you 
got to lose?? If you're not convinced you can forget you ever read it!!

Thankyou for your time,

hilal@kanafani.club24.co.uk

----------------------------------------------------------------------
This is NOT spam. Your Email was obtained from a Safe Opt-IN List.
If you do not wish to recieve anymore Emails then Please Reply to
this message with "REMOVE" as the subject.
Sorry for any inconvenience.
----------------------------------------------------------------------






From list@netscape.com  Sun Jun 11 21:15:51 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10653
	for <ldapext-archive@odin.ietf.org>; Sun, 11 Jun 2000 21:15:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5C16wO08693;
	Sun, 11 Jun 2000 18:06:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5C1EOY09477;
	Sun, 11 Jun 2000 18:14:24 -0700 (PDT)
Resent-Date: Sun, 11 Jun 2000 18:14:24 -0700 (PDT)
Date: Sun, 11 Jun 2000 18:13:54 -0700 (PDT)
Message-Id: <200006120113.e5C1Dp904796@xwing.netscape.com>
From: advisor@GPFC.winning.com.netscape.com
To: @netscape.com
Subject:  Re: please read 
X-Reply-To:  advisor@winning.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"2EODNB.A.jTC.ulDR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Sorry for my intrusion again. If you recieved the message below from the address 
moneyman@williesmail.com - and responded with " send info ", I regret to say that I could 
not recieve it. Williesmail.com went down and will not be up in a while. If you want to get the 
information about his opportunity, please send  " send info " typed in the subject line to 
advisor@winning.com . Then I will be able to rush you the information. If you recieved the 
message below from the address  advisor@winning.com  - and responded with " send info ", 
then everything is fine. Thanks so much. God Bless

---------------------------------------------------------------------------------------------
Lets get strait to the facts:
 
*Guaranteed $10,000+ for you in only 2 months time after you meet 2 VERY EASY requirements 
that you can take care of in one day. Plus a sufficient amount of consistent, monthly residual 
income checks that will sustain you for the rest of your life. All this for a small once a year 
investment. And the opportunity to recieve $100,000+ in your first year.

* This company has the FIRST pay plan of its kind to be copyrighted with a patent pending in 
the U.S. Patent and Trademark Office. The company is growing at 6,224%. This business is 
offering $5,000 to anyone who shows them a better pay plan- . This lets you know from the start 
that this company means business. BIG TIME.

* NO:  Employers, employees, collections, quotas, inventories, deliveries , commuting, 
complicated paperwork, No EXPERIENCE NECESSARY

*YES:  Immediate cash, low start-up cost, speedy success system, tax benifits, total 
diversification

Do this  EASY home business ,when after you complete your 2 easy requirements, you will never 
think about working again. Period. You will be able to retire. Now, you have alot more time to 
enjoy your your family and hobbies.  Sound nice? Take the advantage of this "safe, guaranteed" 
bussiness opportunity. If you are tired of your job, working long hours, living from paycheck to 
paycheck, or wouldn't mind more monthly income: send an email back to me at   
moneyman@williesmail.com   with " send  info" typed in the subject line. Don't think " it sounds 
too good to be true" and delete this email before you look into this incredible opportunity. Trust 
me. You will be glad you did. I promise. - Even if you're content with your job/career,  you should 
never pass up a GUARANTEED $10,000+ in 2  months, and the opportunity to recieve $100,000+ 
in your first year. This is like no opportunity that you have ever seen. You will be amazed and 
excited. Please reply at your earliest convenience, every day you delay is worth a considerable 
amount of money...  

Again, I appologise for the multiple messages- server error.


-------------------------------------------------------------------------------------------------------------------------------
This is a one time email. No need to ask to be removed. I will never send you anything again, 
unless you request information from me.  Thank you.
 ------------------------------------------------------------------------------------------------------------------------------





From list@netscape.com  Mon Jun 12 16:15:02 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10332
	for <ldapext-archive@odin.ietf.org>; Mon, 12 Jun 2000 16:15:01 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5CK63O06810;
	Mon, 12 Jun 2000 13:06:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5CKDVg02719;
	Mon, 12 Jun 2000 13:13:31 -0700 (PDT)
Resent-Date: Mon, 12 Jun 2000 13:13:31 -0700 (PDT)
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431032AA04D@zcard007.ca.nortel.com>
From: "Nancy-M Greene" <ngreene@nortelnetworks.com>
To: "'ietf-ldapext@netscape.com'" <ietf-ldapext@netscape.com>
Subject: interest in SIGOPS RFC2649
Date: Mon, 12 Jun 2000 15:30:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFD4A4.9C7FC02A"
Resent-Message-ID: <"QILeZB.A.op.pRUR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFD4A4.9C7FC02A
Content-Type: text/plain

Has anyone implemented, or is anyone thinking of implementing Experimental
RFC2649 " An LDAP Control and Schema for Holding Operation Signatures"?

thx,
Nancy
------------------------------------------------------------------------
Nancy M. Greene 
Service Provider and Carrier Group, Nortel Networks
T: (514) 271-7221 E: ngreene@nortelnetworks.com

------_=_NextPart_001_01BFD4A4.9C7FC02A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>interest in SIGOPS RFC2649</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Has anyone =
implemented, or is anyone thinking of implementing Experimental RFC2649 =
&quot; An LDAP Control and Schema for Holding Operation =
Signatures&quot;?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">thx,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Nancy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Comic Sans =
MS">--------------------------------------------------------------------=
----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Nancy M. Greene </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Service Provider and Carrier =
Group, Nortel Networks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Comic Sans MS">T: (514) 271-7221 E: =
ngreene@nortelnetworks.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFD4A4.9C7FC02A--



From list@netscape.com  Mon Jun 12 19:37:22 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13029
	for <ldapext-archive@odin.ietf.org>; Mon, 12 Jun 2000 19:37:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5CNVow05118;
	Mon, 12 Jun 2000 16:31:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5CNZuE29214;
	Mon, 12 Jun 2000 16:35:56 -0700 (PDT)
Resent-Date: Mon, 12 Jun 2000 16:35:56 -0700 (PDT)
Message-Id: <200006130051.JAA21075@ns.links-inc.co.jp>
From: "Jason Storm" <barb29t@arabia.com>
Subject: Boost Sales  # 4B7
To: big87o@links-inc.co.jp
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Mon, 12 Jun 2000 18:27:18 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5CNZr129121
Resent-Message-ID: <"5g-28B.A.fHH.aPXR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

              
WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS
!
 
INTERNET (Auction Vendors & Online Mall Stores Too!)
STOREFRONT OR MAIL ORDER MERCHANTS

WE SPECIALIZE IN APPROVING YOU!
 

APPLY TODAY AND START FOR JUST $9.95!

FREE APPLICATION!!
FREE PROGRAMMING!!

DON'T LOSE ANOTHER SALE!

APPLY TO ACCEPT CREDIT CARDS 
AND CALL (888) 264-9272 
 

DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!!



************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:merch345@yahoo.com?subject=remove
************************************************************





From list@netscape.com  Mon Jun 12 21:05:12 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13916
	for <ldapext-archive@odin.ietf.org>; Mon, 12 Jun 2000 21:05:11 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5D0uDO19498;
	Mon, 12 Jun 2000 17:56:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5D13gU05604;
	Mon, 12 Jun 2000 18:03:42 -0700 (PDT)
Resent-Date: Mon, 12 Jun 2000 18:03:42 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01F26A4D@aspams01.cai.com>
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: John_Payne@motorcity2.lotus.com, ietf-ldapext@netscape.com
Subject: RE: Intense LDAP write operations (sort of)
Date: Tue, 13 Jun 2000 11:08:03 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"qXr7VB.A.MXB.shYR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



Some comments.

Once one gets into distribution - ie different name space in different
servers - and one can apply distributed searching with domain based access
controls and distributed trust/authentication enforced - as per X.500 then
things get a little more complex re management and performance.

In addition - to avoid the above points other factors make life very
difficult for those who only have replicating LDAP servers or LDAP protocol
"routing" technologies..

Attribute indexing.
Some servers manually index or have limited indexing capabilities (we index
everything automatically) - so in the former case a search on attribute type
A in server X is different from attribute M in server X - and when you
string a lot of these types of servers together - with eg. LDAP routing
functions the problem is compounded - because there is NO SEARCH (or
update)constiency across this type of system and if these operations are
queued with updates then how long is the update ... its a bit like the web.
So how do you interpret a MIB ?? when you dont know what the indexing,
routing and queueing properties of these servers are. 

DIT sizes.. 
Some vendors enjoy the fact that they have one billion entries per server...
why would you do this?. My answer is becuase you HAVE TO.. No distribution.
And specifically if one can only index a few attributes with DIT sizes like
this in one server, this will place considerable search overheads on the
server and if these are queued with updates then how long is the update.

Component Matching. 
If you do an update during someone else (a security administrator)
retreiving millions of certs because the directory does not have cert/crl
component matching - how long is the update. 

Replicate everything to everywhere: LDAP server mode. 
If one update is a less than a few milliseconds in one server .. wow.. But
if you MUST HAVE a number of replicated servers all over the world - then
surely the update time and cost is explosive ... comms, processing, logging,
integrity and reliability, back ups and all that...Lets say as a scenario
that each update across ten servers is worth at least $10 of operational and
resource costs.


System integrity: 
If you dont apply ACI, DIT integrity, OC and attribute checking before the
update and 2 phase commit during the update - what have you got.. Well if it
isnt a distributed  directory, then all it is is a unscaleable, high
operational cost, low integrity, single server, LDAP attribute store.

AND WHY would I want one of those to run an on line business with..

It may have taken 20 years to get a few million customers.. with a poor
directory strategy - you can loose these in minutes.. and your stock
value!!!



After all - a directory service is the scaleable, extensible OO information
infrastructure with logical views (based on trusted interfaces, consistent
auth and ACI) for customers and staff alike and it is necessary for User
Service provisioning, DEN, PKI, CRM, PBX, CTI and user authentication
applications - as well as White, Blue, Green, Yellow (Customer Facing) and
Catalogue (Purchasing) type applications..

Why would I even consider something that could not provide scaling
flexibility, consistent behaviour as well as information integrity - when
developing ones global EC infrastructure.


When you get into distributed information systems - life is different. It is
not very useful to say that a single server with a fixed update operation -
does it in xx milliseconds. Specifically when its integrity features are not
explained. The issue that we address is building a deterministic, high
integrity, operational distributed directory infrastructure for 300M+
identified and profiled users - globally.




regards as always alan



-----Original Message-----
From: John_Payne@motorcity2.lotus.com
[mailto:John_Payne@motorcity2.lotus.com]
Sent: Saturday, June 10, 2000 4:52 AM
To: ietf-ldapext@netscape.com
Subject: RE: Intense LDAP write operations (sort of)




O.K. This may be getting a little bit off-topic, but this discussion about
replication, intense write operations etc. does raise one very good issue.
Tuning such a distributed/replicated information base is a very complex and
ongoing activity based on changing usage patterns, volatility of the
information
etc. etc.  I have seen very little discussion here about statistics
gathering
and monitoring/management of the directory.  Is there another RFC/mailing
list
for this topic?



From list@netscape.com  Mon Jun 12 21:08:48 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13960
	for <ldapext-archive@odin.ietf.org>; Mon, 12 Jun 2000 21:08:48 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5D0xrO20209;
	Mon, 12 Jun 2000 17:59:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5D17M607370;
	Mon, 12 Jun 2000 18:07:22 -0700 (PDT)
Resent-Date: Mon, 12 Jun 2000 18:07:22 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01F26AC6@aspams01.cai.com>
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: Alexis Bor <alexis.bor@directoryworks.com>, ietf-ldapext@netscape.com
Subject: RE: Intense LDAP write operations
Date: Tue, 13 Jun 2000 11:11:42 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"WvLBrD.A.yyB.IlYR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I know - I was just seeing if anybody noticed :-)

regards alan

-----Original Message-----
From: Alexis Bor [mailto:alexis.bor@directoryworks.com]
Sent: Friday, June 09, 2000 11:48 PM
To: Lloyd, Alan; Subbu K. k.; TGullotta@access360.com;
ietf-ldapext@netscape.com; Martin.Rahm@nokia.com
Subject: RE: Intense LDAP write operations


Alan,
You said that replicated systems are for fault tolerance only.  I don't
think you would agree with yourself on that point.  You are totally ignoring
the need for increasing capacity.  The bottlenecks are not only the
computing system that the directory is running on, but also the
infrastructure itself.  For example, the network is a bottleneck at some
point and if you are looking for increasing response time, then the packet
queuing time to transition the network is significant as well.  The internet
is a great example of unpredictable queuing time - we all see that some days
are worse than others - which is not acceptable for a directory when it is
used as part of the infrastructure services.

-- Alexis

Alexis Bor
Directory Works, Inc.
alexis.bor@directoryworks.com
http://www.directoryworks.com

-----Original Message-----
From: Lloyd, Alan [mailto:Alan.Lloyd@ca.com]
Sent: Friday, June 09, 2000 2:19 AM
To: Subbu K. k.; TGullotta@access360.com; ietf-ldapext@netscape.com;
Martin.Rahm@nokia.com
Subject: RE: Intense LDAP write operations

(text deleted)

Replicated systems... one only does this for fault tolerance.. If you
replicate names/passworrd/certs/CRLs, ACI for millions of entries all over
the world then - one will have a considerable security issue to deal with..

regards alan




From list@netscape.com  Mon Jun 12 21:35:33 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14215
	for <ldapext-archive@odin.ietf.org>; Mon, 12 Jun 2000 21:35:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5D1TJw23332;
	Mon, 12 Jun 2000 18:29:19 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5D1XPU19479;
	Mon, 12 Jun 2000 18:33:25 -0700 (PDT)
Resent-Date: Mon, 12 Jun 2000 18:33:25 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01F397E9@aspams01.cai.com>
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: "Subbu K. k." <KKSUBRAMANIAM@novell.com>, ietf-ldapext@netscape.com
Subject: RE:     Some more  Intense LDAP write operations
Date: Tue, 13 Jun 2000 11:37:41 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"FQkYsC.A.9vE.j9YR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I am an old timer - we (ICL) used to run a bank or London Transport on 128Kb
- 
The Four Yorkshiremen - Monty Python :-)

Re the flat search times? (engineering report required) - well is this all
about single server tuning, search prediction, caching and  selection of
index mechanisms.. ie does one gets the "spanners"  out when you add more
schema configuration,  more objects, more attributes, more access controls,
more applications, more clients,  etc and when one adds more replicated
servers (because the system is not distributed) then its not just one
mechanic - its a team of them working with miners lamps (night time) and
being totally synchronised..

Is this a new olympic sport in the making - synchronised LDAP server
management? :-)



Distributed directories provide a distributed scaleable, context (country or
application) designed capacity directory  for globally distributed
organisations who also want the ability to manage their own part of the
system -  and let administrators do a global search and say.. how many
customers across the world have I got with this service..how many of my
customers with certs have their certs expire next week..


See the telephone service... ie it does not replicate everything to every
where..
A Virtual ISP service is users and services working via internet, telephones
and television access onto the public and secure private global internets. -
Sorry I just cannot engineer these things with LDAP replicate everything to
everywhere servers.. 

A database is 30 year old technology, it is good for storing what has
happened in a transaction - at a central place.. a service.

Directories are distributed - and are ideal for storing what things are and
what they can do.. 
However, a directory needs to use underlying database engineering in each
server to enable the same integrity and product tools.. ie a directory (ours
) is a distributed OO application that uses databases as its storage,
indexing and data retrieval system. note 32 patents on this OO directory
application of RDBs.


My role is to design large scale EC infrastructure for businesses. If a
solution requires more people than the servers being installed then it is
not a solution.


regards alan 




-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com]
Sent: Friday, June 09, 2000 7:41 PM
To: alan.lloyd@ca.com; ietf-ldapext@netscape.com
Subject: RE: Intense LDAP write operations


[Moderator, I am not sure if I am violating the intent of this list in
continuing this discussion. If so, pls. let me know and I can take this on a
separate discussion group. Thanks in advance]

Alan,

Actually, the exercise was taken to see how far we could push the limits
before eDirectory breaks down (It didnt, in this case. We had to stop the
exercise at 1+ billion objects to show it in an event).

Billion objects may sound like a lot today but so did 640KB of address space
for PCs in 1984!

Not all entries need necessarily be personal secrets. In your specific
example, it does makes sense to have a global directory for mobile phone
numbers (projected to cross 1 billion by 2003) that is updated by regional
admins but seen as one by the mobile phone owners. Global knowledge bases
like Human Genome will contain about 3 billion codes. Replication may take a
'long' time and may even be filtered, but since they dont change much, it
makes sense to have the directory automatically replicate this where
scientists actually need them.

I dont think the assumption that there is a trade-off between
(capacity,concurrency,search time) is necessarily true. With proper design
(as in NDS eDirectory) that exploits the usage pattern for directories, it
is possible to retain essentially flat search times thru hundreds of
millions of entries.

Subbu K. K.
>>> "Lloyd, Alan" <Alan.Lloyd@ca.com> 06/09/00 11:45AM >>>
If you are worried about capacity and scaleability - well replicated systems
dont scale - Just consider the telephone system - we log on where we are and
use local calls, national calls and long distance calls - ie the
authentication base is distributed. X.500 is a distributed system in that it
forms a distributed system infrastructure.. ie one does not need to
replicate AU to the US, US to the UK and so on..

It seems odd that one would put a billion objects in one server and then
have to replicate this all over the place? Becuase one could not have a
distributed system.

In addition the real test for a directory is not lots of objects that
replicate - its the ability to have these objects distributed  - as well as
having a distributed service that can handle high user concurrency - eg 100s
of Ms of users - all logging on in seconds and all wanting directory service
information...in seconds.

In terms of design - with multi LDAP/DAP/DSP/DISP backbone load balancing /
alternate DSA modules - coupled to DSA processes, with one or more DBs, etc
- we can do fault tolerant, load balancing distributed/replicated meshed
based global directory services and integrate LDAP servers. So the issues of
read/write requirements is met in the operation system design of the
directory service..


Replicated systems... one only does this for fault tolerance.. If you
replicate names/passworrd/certs/CRLs, ACI for millions of entries all over
the world then - one will have a considerable security issue to deal with..

regards alan

-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com] 
Sent: Thursday, June 08, 2000 7:33 PM
To: TGullotta@access360.com; ietf-ldapext@netscape.com;
Martin.Rahm@nokia.com 
Subject: RE: Intense LDAP write operations


Not really. It is just that when you have millions of objects, they tend to
be read much more often than modified. For instance, when a user object is
created, it is read thousands of times before it gets updated.
Operationally, NDS does update its database internally for its replication
status etc. The last login time attribute does get updated for every login,
but this is an operational attribute.

NDS itself uses a transactional database to ensure full integrity and
incremental replication to ensure scalability. It has tested to hold more
than 1 billion objects on a single E450. As installed, it just takes less
than a megabyte for its database.

Subbu K. K.

-------------------
K. K. Subramaniam,                                                
Product Manager, NDS eDirectory (UNIX/Linux)
Novell Software, Bangalore                                  Ph: +91 (80)
572-1856x2212

>>> <TGullotta@access360.com> 06/07/00 09:08PM >>>
Subbu,

Has Novell done any benchmarks on read vs. write operations? It seems that
in a lot of directory implementations, although not every entry is being
updated that frequently, if you have a million or so users, just periodic
updates to entries could add up when you look at the total number of users.
I would think this is realistic. Is it a problem with NDS?

Tony Gullotta
Lead System Architect
access360


-----Original Message-----
From: Subbu K. k. [mailto:KKSUBRAMANIAM@novell.com] 
Sent: Wednesday, June 07, 2000 12:15 AM
To: ietf-ldapext@netscape.com; Martin.Rahm@nokia.com 
Subject: Re: Intense LDAP write operations


I dont think this was the sweet spot planned for directories. Writes would
entail applying locks on the data store which would impact the regular
search, retrieval and any sync operations. You also need to deal with
atomicity of updates to the group of attributes and the latency of
propagation of changes across multiple copies of the data store. A
transactional database may be a better choice.

Are you sure you need a directory service and not a transactional database
engine that supports LDAP in addition to SQL?

Subbu K. K
?---------------------------------------------
K. K. Subramaniam
Product Manager, Novell Directory Services (UNIX)
Novell

>>> <Martin.Rahm@nokia.com> 06/07/00 12:27PM >>>
Hi,

I am working on a problem where LDAP would be used to keep a directory with
user data.  One concern I have is that LDAP is supposed to be less efficient
when it comes to intense write operations.

Can LDAP handle millions of users data in a directory where some of the data
(a few attributes) needs to be updated very frequently?  How would that
affect performance and is LDAP effective when the searched data must be
returned prompty with very little delay?

If anyone has any comments on this, I would appreciate it,

Martin Rahm



From list@netscape.com  Tue Jun 13 09:34:53 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07638
	for <ldapext-archive@odin.ietf.org>; Tue, 13 Jun 2000 09:34:52 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5DDPsO13713;
	Tue, 13 Jun 2000 06:25:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5DDXNM14266;
	Tue, 13 Jun 2000 06:33:23 -0700 (PDT)
Resent-Date: Tue, 13 Jun 2000 06:33:23 -0700 (PDT)
Date: Tue, 13 Jun 2000 06:30:25 -0700 (PDT)
Message-Id: <200006131330.e5DDUO929780@xwing.netscape.com>
From: web@AOPY.netfortune.com
To: .ANAF@netscape.com
Subject:  The I.R.S. is giving Refunds. Do you qualify? -GQER
X-Reply-To:  websuccess@execs.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"5N-40D.A.ReD.hgjR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


Hello, 

Financial security can't be achieved while doing a "job" making someone else 
rich. 

Now is the time for you to make money and build financial security with the 
HOTTEST internet opportunity available to anyone. Here is what TOP marketers 
on the net are calling the most powerful business income system yet. 

This is literally the most fool-proof and stable income generating internet 
business ever seen. You can build it from anywhere..... it's so finely tuned. The 
I.R.S supported tax savings generate $5,000 to $10,000 guaranteed Extra Tax 
REFUND annually, 

IN ADDITION to the income generated by your webstore and from your 
organization you get easy to earn Free CAR and Free HOUSE Bonuses. YOU 
own them not the company. YOUR "Title" and YOUR "Deed". 

Your TURN-KEY Internet Store Operates 24-7-365 and is stocked with over 400 
awesome, high quality products that SELL. Many are EXCLUSIVE! 

Your Internet Store does all of the selling for you and the company ships Out 
The Products FOR YOU AUTOMATICALLY! 

Your AUTOMATED MONEY-MAKING SYSTEM includes the following: 

NO Large Investment
NO Inventory
NO Face to Face Rejection
NO Need to Deliver Products
NO Repeat Sales Presentations
NO Pressuring Customers to Purchase
NO Billings or Collections
NO Complicated Paperwork
NO RISK - make money back in 90 days 

All You Do Is USE THE *AUTOMATED* SYSTEM and CASH THE CHECKS! 

Get all the details now--before others get in first! 

Click Email and request exciting details - mailto:websuccess@execs.com 

You will be glad that you did! 

Thank you and have a great day! 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To be removed from our mailing list 
just click on the link below:
mailto:cancelcar@hotmail.com?subject=Remove
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 






From list@netscape.com  Tue Jun 13 20:12:59 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25424
	for <ldapext-archive@odin.ietf.org>; Tue, 13 Jun 2000 20:12:58 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5E03uO22035;
	Tue, 13 Jun 2000 17:03:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5E0BQk10024;
	Tue, 13 Jun 2000 17:11:26 -0700 (PDT)
Resent-Date: Tue, 13 Jun 2000 17:11:26 -0700 (PDT)
Message-Id: <3.0.5.32.20000613171122.0094d9d0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 13 Jun 2000 17:11:22 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: I-D: OpenLDAP Root Service: An experimental LDAP referral
  service
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"QRszgD.A.mbC.t2sR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

An I-D describing this experimental service is available for
your review:
  http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-root-00.txt

Please provide comments to this list or directly to the
author.

Regards, Kurt



From list@netscape.com  Tue Jun 13 20:13:58 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25451
	for <ldapext-archive@odin.ietf.org>; Tue, 13 Jun 2000 20:13:57 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5E08O525975;
	Tue, 13 Jun 2000 17:08:24 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5E0CWs10980;
	Tue, 13 Jun 2000 17:12:32 -0700 (PDT)
Resent-Date: Tue, 13 Jun 2000 17:12:32 -0700 (PDT)
Message-Id: <3.0.5.32.20000613171228.009532a0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 13 Jun 2000 17:12:28 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: revised passwd-exop I-D, LAST CALL
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"EOaBaD.A.HrC.u3sR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

A revised passwd-exop I-D is now available.
  http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwd-exop-02.txt

New in this draft:
+ clarified requirement to publish support for operation in the root DSE.
+ clarified that if oldPassword cannot* be verified or is incorrect,
    non-success should be returned.  (* latest draft is missing the
    not in cannot and will be repaired in a subsequent revision).
+ numerous editorial changes 

As the author of this individual submission, I hereby issue a
LAST CALL for comments.  The purpose of this LAST CALL is to
give you an opportunity to comment on the I-D before submission
to the IESG for review as a Proposed Standard.  Please post your
comments regarding to this list or privately by 30 June 2000.

Please note that this LAST CALL is not an IETF nor a WG LAST
CALL.  This last call does not supplant nor replace any review
required by the IESG/IETF standardization process.  It is made
by the author solely for the purposes of obtain feedback prior
to submission.

Regards, Kurt



From list@netscape.com  Tue Jun 13 22:03:30 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27466
	for <ldapext-archive@odin.ietf.org>; Tue, 13 Jun 2000 22:03:29 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5E1sR805722;
	Tue, 13 Jun 2000 18:54:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5E21vY29657;
	Tue, 13 Jun 2000 19:01:57 -0700 (PDT)
Resent-Date: Tue, 13 Jun 2000 19:01:57 -0700 (PDT)
Date: Tue, 13 Jun 2000 19:01:48 -0700 (PDT)
Message-Id: <200006140201.e5E21ix01146@ywing.netscape.com>
From: homeownersgroup@goodday.net.netscape.com
To: Homeowners.UATJ@netscape.com
Subject:  $2 Will Return Thousands!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"6w00E.A._OH.UeuR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

ATTENTION HOMEOWNERS!
Our mortgage software will save you THOUSANDS of dollars off your present mortgage 
without increasing your current payment, without refinancing, without making any 
changes in your current mortgage at all. NONE! This will also cut years off your mortgage 
( 7 -15 yrs. ), and will build equity in your home 300% faster! You’ll be able to audit your 
loan automatically to find lender mistakes which occur 50% of the time according to the 
F.D.I.C. It’s FREE and it’s being used by thousands of homeowners right now. 
To get your FREE copy of the mortgage software for windows 95, please send $2 ( two 
dollars ) to cover the cost of shipping & handling to: DRS / P.O. Box 360 / Holbrook, MA 
02343 The software will be sent out the same day that I receive your request, and I 
promise that you will be 100% satisfied, and that this will cut $40,000- $150,000 off your 
current mortgage! You MUST see this for yourself and start putting the savings into YOUR 
pockets, instead of the banks! This will be the BEST move that you’ll ever make! Why 
didn’t someone come out with this sooner? Offer is valid ONLY in the U.S.A. 




From list@netscape.com  Wed Jun 14 00:07:45 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00091
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 00:07:45 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5E3wh814596;
	Tue, 13 Jun 2000 20:58:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5E46D200838;
	Tue, 13 Jun 2000 21:06:13 -0700 (PDT)
Resent-Date: Tue, 13 Jun 2000 21:06:13 -0700 (PDT)
Content-Type: text/plain;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Reply-To: emailingnow@post.com
Message-Id: <4tp75dw0b70f.nxch6k2bo32@webcom.com>
Subject: ADV - 10 MILLION  ADDRESSES!
From: reach10million@posts.com
To: fed@%domain.netscape.com
Date: Fri, 12 Nov 1999 21:04:22 -0800
Resent-Message-ID: <"ZVe5-C.A.uM.0SwR5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8BIT

 10 MILLION
 EMAIL ADDRESSES
 FOR ONLY $99 

       
  You want to make some money? 

 we can put you in touch with over 10 million people at virtually no cost.

 Can you make one cent from each of theses names?

If you can you have a profit of over $250,000.00 


      That's right, we have 10 Million  Fresh  email 

addresses that we will sell for only $99. These are all 

fresh addresses  with no duplications. They are 

all sorted and ready to be mailed.  That is the best 

deal anywhere today!  Imagine selling a product for 

only $5 and getting only a 1/10% response.   That's  

$1,350,000 in your pocket !!! 
 
 Don't believe it? People are making that kind of 

money right now by doing the same thing, that is 

why you get so much email from people selling you 

their product....it works!  we will even include,

a  FREE demo copy of the worlds leading  BULK MAILING

SOFTARE!

These 10 Million email addresses and software are     

yours to keep, so you can use them over and 

over and they come on 1 CD.  

This offer is not for everyone.

If you can not see  just how excellent the

 risk / reward ratio in this offer is then there is 

nothing we can do for you. 

To make money you must stop dreaming 

and TAKE ACTION.


****************************************

10 MILLION email addresses on CD

These name are all in text files

ready to mail!!! (includes bulk mailing sotware)

$99.00


*************************************************************
VISA/MC ONLY

STEP 1:  Print out the below ORDER FORM
STEP 2:  Type or Print your order information into the form
STEP 3:  FAX Your order to us.

FAX TO: 415-704-3071 (Order with confidence.  This is a secure fax area.
Only our qualified sales team will have access to your order 
information)


                                     ORDER FORM(Print clearly with DARK pen)
************************************************************************************************
Name:                   ________________________________  

Address:                ________________________________ * *BILLING ADDRESS ONLY

City, State, ZIP:       ________________________________  

Country:                ______________   (International Orders)  

Phone Number:           ______________   (In case we can't make out your order) 


METHOD OF PAYMENT- CREDIT CARD ONLY
[   ]Visa   [   ]MasterCard

Credit Card #:  __________________________________

Exp Date: _______________

Signature: ____________________________ (Required)

E-Mail Address: ____________________________ *(PRINT CLEARLY!!)

************************************************************************************************

        WE WILL BILL 99.00  to your account plus the following shipping costs

        SHIPPING  COST OF 4.85 FIRST CLASS MAIL
        INTERNATIOMAL ORDERS ADD 25.00 U.S. DOLLARS

 
        
 
ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL, QUICKLY, PROPERLY, LEGALLY PROVIDED WITH ORDER


Copyright 2000
All rights reserved



From list@netscape.com  Wed Jun 14 09:18:54 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19406
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 09:18:54 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EDDEH25092;
	Wed, 14 Jun 2000 06:13:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EDHNs15202;
	Wed, 14 Jun 2000 06:17:23 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 06:17:23 -0700 (PDT)
Message-Id: <3.0.5.32.20000614061718.0095ec40@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 06:17:18 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Unrecognized critical control & referrals
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"M7ZmIB.A.HtD.hX4R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

RFC 2251, 4.1.2:
   If the server does not recognize the control type and the criticality
   field is TRUE, the server MUST NOT perform the operation, and MUST
   instead return the resultCode unsupportedCriticalExtension.

There seems to me the need for an exception to the MUST to allow
a server to return a referral instead of unsupportedCriticalExtension.
If the request would, if the control was not marked critical,
have returned a referral result, shouldn't that same referral be
returned when the control is critical?

Kurt
 



From list@netscape.com  Wed Jun 14 10:31:17 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22494
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 10:31:16 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EEM5820963;
	Wed, 14 Jun 2000 07:22:05 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EETZU18541;
	Wed, 14 Jun 2000 07:29:35 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 07:29:35 -0700 (PDT)
Message-ID: <EB21C070AA75D311A0AC0090271EC45C0338DA0E@us-tr-exch-1.tr.unisys.com>
From: "Salter, Thomas A" <Thomas.Salter@unisys.com>
To: "Kurt D. Zeilenga" <Kurt@openldap.org>, ietf-ldapext@netscape.com
Subject: RE: Unrecognized critical control & referrals
Date: Wed, 14 Jun 2000 10:29:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"lq_uMD.A.JhE.Nb5R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

The server can only do that if it knows something about the control.  If the
server can somehow tell that it would have returned a referral even if it
supported the control, then it can go ahead and return the referral.

For instance, you could build a server that recognizes the sort control, but
does not support it.  It could safely return a referral (or even a single
result), but would need to return unsupportedCriticalExtension if the search
returned two or more entries.

In the general case the server can't guess about nature of the control.  For
all it knows, the control has some obscure meaning such as "under no
circumstances return a referral for this request".

I think the key words in the RFC are correct: "... does not recognize ...".
This allows a server to recognize, but not support, a control.

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
 > Sent: Wednesday, June 14, 2000 9:17 AM
 > To: ietf-ldapext@netscape.com
 > Subject: Unrecognized critical control & referrals
 > 
 > 
 > RFC 2251, 4.1.2:
 >    If the server does not recognize the control type and the 
 > criticality
 >    field is TRUE, the server MUST NOT perform the operation, and MUST
 >    instead return the resultCode unsupportedCriticalExtension.
 > 
 > There seems to me the need for an exception to the MUST to allow
 > a server to return a referral instead of 
 > unsupportedCriticalExtension.
 > If the request would, if the control was not marked critical,
 > have returned a referral result, shouldn't that same referral be
 > returned when the control is critical?
 > 
 > Kurt
 >  
 > 



From list@netscape.com  Wed Jun 14 11:51:17 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25909
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 11:51:17 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EFfw829321;
	Wed, 14 Jun 2000 08:41:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EFnTI08982;
	Wed, 14 Jun 2000 08:49:29 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 08:49:29 -0700 (PDT)
Message-Id: <3.0.5.32.20000614084920.0095f3d0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 08:49:20 -0700
To: "Salter, Thomas A" <Thomas.Salter@unisys.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: RE: Unrecognized critical control & referrals
Cc: ietf-ldapext@netscape.com
In-Reply-To: <EB21C070AA75D311A0AC0090271EC45C0338DA0E@us-tr-exch-1.tr.u
 nisys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"EzsWWC.A.aLC.Gm6R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I've always assumed that a server which recongizes a control
supports that control.  Note that the RFC2251 never uses
the term "supported" in the context of controls though it
does state to return the unsupportedCriticalExtension
(unavailableCriticalExtension [12]) resultCode.

Anyways, I agree that the server should return
unsupportedCriticalExtension (unavailableCriticalExtension [12])
in this case.

	Kurt

At 10:29 AM 6/14/00 -0400, Salter, Thomas A wrote:
>The server can only do that if it knows something about the control.  If the
>server can somehow tell that it would have returned a referral even if it
>supported the control, then it can go ahead and return the referral.
>
>For instance, you could build a server that recognizes the sort control, but
>does not support it.  It could safely return a referral (or even a single
>result), but would need to return unsupportedCriticalExtension if the search
>returned two or more entries.
>
>In the general case the server can't guess about nature of the control.  For
>all it knows, the control has some obscure meaning such as "under no
>circumstances return a referral for this request".
>
>I think the key words in the RFC are correct: "... does not recognize ...".
>This allows a server to recognize, but not support, a control.
>
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> > Sent: Wednesday, June 14, 2000 9:17 AM
> > To: ietf-ldapext@netscape.com
> > Subject: Unrecognized critical control & referrals
> > 
> > 
> > RFC 2251, 4.1.2:
> >    If the server does not recognize the control type and the 
> > criticality
> >    field is TRUE, the server MUST NOT perform the operation, and MUST
> >    instead return the resultCode unsupportedCriticalExtension.
> > 
> > There seems to me the need for an exception to the MUST to allow
> > a server to return a referral instead of 
> > unsupportedCriticalExtension.
> > If the request would, if the control was not marked critical,
> > have returned a referral result, shouldn't that same referral be
> > returned when the control is critical?
> > 
> > Kurt
> >  
> > 
>
>



From list@netscape.com  Wed Jun 14 12:55:21 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28084
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 12:55:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EGnRH22455;
	Wed, 14 Jun 2000 09:49:28 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EGrag27942;
	Wed, 14 Jun 2000 09:53:36 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 09:53:36 -0700 (PDT)
Date: Wed, 14 Jun 2000 11:51:22 -0500
From: Mark Wahl <M.Wahl@innosoft.com>
Subject: WG Last Call: draft-ietf-ldapext-locate-02.txt
Sender: wahl@austin.innosoft.com
To: ietf-ldapext@netscape.com
Reply-to: M.Wahl@innosoft.com
Message-id: <10766.961001482@threadgill.austin.innosoft.com>
Resent-Message-ID: <"ZKt0PC.A.M0G.Oi7R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


The purpose of this message is to initiate an LDAPEXT
working group last call on the "Discovering LDAP Services
with DNS" Internet Draft.

WHAT DOCUMENT?

The document in last call is:

   draft-ietf-ldapext-locate-02.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on Friday, June 30, 2000.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
forward the document to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the document is revised. We then ask our ADs to put
forward the revised document to the IESG for proposed
standard status.

3) Major issues are raised and no consensus is reached on
the list. In this case, we slink back and discuss things
until consensus is reached, at which time another working
group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the document
is with the IESG. The IESG reads it and may approve the
documents (with or without changes), or send the document
back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward
for a two-week last call to the entire IETF, and after
successful completion the document is published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the document forward again when we
believe they're ready.

WHAT SHOULD I DO?

You should read the document, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me.

Read, enjoy, and send your comments in!

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance



From list@netscape.com  Wed Jun 14 13:07:28 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28457
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 13:07:27 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EGwK810335;
	Wed, 14 Jun 2000 09:58:20 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EH5ps07013;
	Wed, 14 Jun 2000 10:05:51 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 10:05:51 -0700 (PDT)
Date: Wed, 14 Jun 2000 12:04:38 -0500
From: Mark Wahl <M.Wahl@innosoft.com>
Subject: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Sender: wahl@austin.innosoft.com
To: ietf-ldapext@netscape.com
Reply-to: M.Wahl@innosoft.com
Message-id: <11035.961002278@threadgill.austin.innosoft.com>
Resent-Message-ID: <"q5M3XD.A.LtB.ut7R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


The purpose of this message is to initiate an LDAPEXT
working group last call on the "LDAP Control for a 
Duplicate Entry Representation of Search Results" Internet
Draft.

WHAT DOCUMENT?

The document in last call is:

   draft-ietf-ldapext-dupent-03.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on Friday, June 30, 2000.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
forward the document to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the document is revised. We then ask our ADs to put
forward the revised document to the IESG for proposed
standard status.

3) Major issues are raised and no consensus is reached on
the list. In this case, we slink back and discuss things
until consensus is reached, at which time another working
group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the document
is with the IESG. The IESG reads it and may approve the
documents (with or without changes), or send the document
back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward
for a two-week last call to the entire IETF, and after
successful completion the document is published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the document forward again when we
believe they're ready.

WHAT SHOULD I DO?

You should read the document, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me.

Read, enjoy, and send your comments in!

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance



From list@netscape.com  Wed Jun 14 13:12:40 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28580
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 13:12:39 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EH2f811387;
	Wed, 14 Jun 2000 10:02:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EHADQ09771;
	Wed, 14 Jun 2000 10:10:13 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 10:10:13 -0700 (PDT)
Date: Wed, 14 Jun 2000 12:08:54 -0500
From: Mark Wahl <M.Wahl@innosoft.com>
Subject: WG Last Call: draft-just-ldapv3-rescodes-02.txt
Sender: wahl@austin.innosoft.com
To: ietf-ldapext@netscape.com
Reply-to: M.Wahl@innosoft.com
Message-id: <12680.961002534@threadgill.austin.innosoft.com>
Resent-Message-ID: <"oEqz3C.A.OYC.zx7R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


The purpose of this message is to initiate an LDAPEXT
working group last call on the "LDAPv3 Result Codes: 
Definitions and Appropriate Use" Internet Draft.

WHAT DOCUMENT?

The document in last call is:

   draft-just-ldapv3-rescodes-02.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately 
three weeks. It will end on Friday, July 7, 2000.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
forward the document to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the document is revised. We then ask our ADs to put
forward the revised document to the IESG for proposed
standard status.

3) Major issues are raised and no consensus is reached on
the list. In this case, we slink back and discuss things
until consensus is reached, at which time another working
group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the document
is with the IESG. The IESG reads it and may approve the
documents (with or without changes), or send the document
back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward
for a two-week last call to the entire IETF, and after
successful completion the document is published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the document forward again when we
believe they're ready.

WHAT SHOULD I DO?

You should read the document, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me.

Read, enjoy, and send your comments in!

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance



From list@netscape.com  Wed Jun 14 14:17:10 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00818
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 14:17:07 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EI74822679;
	Wed, 14 Jun 2000 11:07:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EIEZM19652;
	Wed, 14 Jun 2000 11:14:35 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 11:14:35 -0700 (PDT)
Message-Id: <3.0.5.32.20000614111431.00956250@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 11:14:31 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
In-Reply-To: <11035.961002278@threadgill.austin.innosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"R9EXDB.A.syE.Ku8R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Some comments...

How does this control behave in the face of subtypes of the
provided AttributeDescriptions?

It should be an error to specify "cn;binary,cn".  I don't
think ";binary" actually makes sense in this context as
this mechanism does not specify how the attribute is to
be transferred (this should be clearly stated).  I would
recommend stating that clients SHOULD NOT specify options
which indicate transfer encoding.

RFC 2019 edits.  There are a number of lowercase should, must,
may's in the document.  I suggest that the author review each
of these and, where appropriate, use the uppercase varient.

The document is missing a "Security Considerations" section.
This must be included.  In particular, I would suggest detailing
DoS attacks using this control... just imagine specifying all
the schema related attributes on a subschema subentry search...
(this is hinted at in section 7).

4.1:
   An AttributeDescription should only occur once in the list.  If an
   AttributeDescription is included in the DuplicateEntryRequest
   multiple times, the server should return an unwillingToPerform error
   in the DuplicateEntryResponse.

I believe that unwillingToPerform should not be used to indicate
this error.  I suggest protocolError.

4.2:
DuplicateEntryResponse ::= SEQUENCE {
          result   ENUMERATED { ... }

Is this list of possible result codes a restriction?  If so,
is a MUST, SHOULD, or MAY?  I suggest other codes be allowed
as appropriate.  Also wherever a resultCode is returned,
optional human readable text should be provided as well.

   operations error    (1),  -- server internal failure
             ^ typo

Also, note my past and future comments regarding operationsError
v. other.  I believe other is more appropriate for internal
failures and operationsError is more appropriate for request
sequencing errors.  This, of course, is an rfc2251bis/errcodes
issue (which we should address separately).

   attributeType   AttributeDescription OPTIONAL

I believe it inappropriate for this control to return this
information.  This feature should be part of a more general
disclose error information control.

Examples:

I suggest using a base DN and domains reserved for examples,
such as "dc=example,dc=net" and example.com.  I would also
avoid using trademarked names in the examples (though I
do chuckle at Elmer's e-mail address).



From list@netscape.com  Wed Jun 14 14:53:31 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01967
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 14:53:30 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EIfI800244;
	Wed, 14 Jun 2000 11:41:18 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EIils04665;
	Wed, 14 Jun 2000 11:44:47 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 11:44:47 -0700 (PDT)
Message-Id: <3.0.5.32.20000614114434.0095cbd0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 11:44:34 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
In-Reply-To: <3.0.5.32.20000614111431.00956250@infidel.boolean.net>
References: <11035.961002278@threadgill.austin.innosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"3jTau.A.PGB.YK9R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Additionally, I believe it might be generally useful for
clients to be able to distinguished duplicated entries
from non-duplicated entries returned by a search with
this control.  I suggest that a control be returned
in each LDAPMessage which contains a duplicated entry.

In particular, this would be useful where the server was
able to return duplicate entries for a subset of the
requested entries and the control was marked non-critical.

For example, user requests duplicate entries for the
attribute description "givenName,sn".  The server
has disallows duplicating entries where multiple
listed attributed contain multiple values.  That is,
it will generate duplicates for a given entry
if only givenName has duplicates and only if sn
has duplicates, but not if both givenName and sn
have duplicates.  This would be avoid generating
NxM entries for the N values of givenname and
the M values of sn.

There are likely other cases where the control was
provided only to a subset of the entries returned.

Oh, and another implementation note, servers which
chain requests should avoid passing this control to
other servers by splitting chained results itself.



From list@netscape.com  Wed Jun 14 16:02:45 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03418
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 16:02:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EJusL26274;
	Wed, 14 Jun 2000 12:56:55 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EK13s14748;
	Wed, 14 Jun 2000 13:01:03 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 13:01:03 -0700 (PDT)
Message-Id: <3.0.5.32.20000614072033.009329d0@pop.walltech.com>
X-Sender: bgreenblatt@pop.walltech.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 07:20:33 -0700
To: "Kurt D. Zeilenga" <Kurt@openldap.org>, ietf-ldapext@netscape.com
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject: Re: Unrecognized critical control & referrals
In-Reply-To: <3.0.5.32.20000614061718.0095ec40@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"aEBrcD.A.AmD.8R-R5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 06:17 AM 6/14/2000 -0700, Kurt D. Zeilenga wrote:
>RFC 2251, 4.1.2:
>   If the server does not recognize the control type and the criticality
>   field is TRUE, the server MUST NOT perform the operation, and MUST
>   instead return the resultCode unsupportedCriticalExtension.
>
>There seems to me the need for an exception to the MUST to allow
>a server to return a referral instead of unsupportedCriticalExtension.
>If the request would, if the control was not marked critical,
>have returned a referral result, shouldn't that same referral be
>returned when the control is critical?
>

Since there is no way to know what the extension might be, there is now way
to know if returning the referral is the right behavior.  What if the
critical extension is "Don't return referrals"?  This text MUST stay as it
is... Bruce

>Kurt
> 
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi



From list@netscape.com  Wed Jun 14 19:04:23 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05650
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 19:04:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5EMtE819548;
	Wed, 14 Jun 2000 15:55:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5EN2kA03809;
	Wed, 14 Jun 2000 16:02:46 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 16:02:46 -0700 (PDT)
Date: Wed, 14 Jun 2000 16:02:27 -0700 (PDT)
Message-Id: <200006142302.e5EN2Qx29795@ywing.netscape.com>
From: matt2@getresponse.com
To: @netscape.com
Subject:  Kiss Your Boss Godbye -HYHV
X-Reply-To:  matt2@getresponse.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"WM76x.A.B7.U8AS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

This message comes to you in good faith as a result of your previous interest in internet business 
opportunities.  If you do not wish to remain on the opt-in list reply with remove in the subject line.

Here is the simplest way for us all to make some money on the internet.  It is based purely on rapid 
multiplication of participants, is legal and what's more it is failsafe in that you can check it out before 
parting with a very small sum.

 It will cost you $10 all in.  And you are able to verify that all is above board before you invest even that 
small amount.  Here is what you do.

Step 1: 	e mail the following 2 people and ask them if they have received their $5 from me (Matt)

a.	Cody Burgat e mail:  cburgat@earthlink.net

b.	Susan Azar e mail:	SusanAzar@msn.com

UNLIKE ANY OTHER PROGRAMME THIS ALLOWS YOU TO VERIFY THAT PEOPLE ARE SENDING MONEY 
AND ARE NOT CHEATING.  IF YOU DO NOT GET A YES FROM THE ABOVE DO NOT PROCEED.  Under US 
law the programme is legal if we are compiling a mailing list.

Step 2:	Send $5 to the person at position 3 with the message: "Please add me to your mailing list and 
send details of Phase 2."

Step 3:	Send $5 to the person at position 4 with the message "Please add me to your mailing list."

DO NOT SEND ANY MORE MONEY

Step 4:	Reply to me for details of Phase 2 where I will show you how to duplicate what you have done 
using free advertising on the internet.  Most people will not take part but we only need about 20 and there 
are millions of opportunity seekers on the net.


Now copy this letter and edit it as follows:

1.	Move position 4 to position 2 and delete position 2

2.	Move position 1 to position 4

3.	Move position 3 to position 1

4.	Enter your own details in position 3


BE SURE TO COPY EACH PERSON'S DETAILS CORRECTLY


POSITION 1:	Susan Azar
		386 B Street
		Ashland, OR 97520
		USA

	e mail:	Susan Azar@msn.com

POSITION 2:	Cody Burgat
		PO Box 741
		La Porte,CO 80535
		USA

	e mail:	cburgat@earthlink.net

POSITION 3	Matthew Paterson
		Inglewood
		Blebo Craigs
		Cupar
		Fife
		KY15 5UG
		Scotland
		UK

	e mail:	matt2@getresponse.com

POSITION 4	Jon Brelig
		2009 Rangeview Drive
		Fort Collins,CO 80524
		USA

	e mail:	brelig@frii.com
	




From list@netscape.com  Wed Jun 14 19:49:29 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06140
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 19:49:28 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5ENe4b29827;
	Wed, 14 Jun 2000 16:40:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5ENiCc22483;
	Wed, 14 Jun 2000 16:44:12 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 16:44:12 -0700 (PDT)
Message-Id: <3.0.5.32.20000614164408.00951c10@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 16:44:08 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-locate-02.txt
In-Reply-To: <10766.961001482@threadgill.austin.innosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"pKSwI.A.7eF.LjBS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

A couple of quick comments:

Section 3: DN -> domain mapping

The section should state that the mapping results in a fully
qualified domain name.

I would also like to see examples provided.


Also, from the Minutes from AU.

>Questions asked included:
> - Are there problems with converting dc-based DNs to DNS names? what are the 
>   character set restrictions? 

Though I believe DC's choice of IA5 will require it to be replaced
eventually, that's outside the scope of this work.

>- if client can't find the SRV record with a exact lookup of the DNS name,
>  should it walk up the tree?  If not, then does this need to be explicitly
>  called out?

No, yes.




From list@netscape.com  Wed Jun 14 19:58:38 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06190
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 19:58:37 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5ENqxb01836;
	Wed, 14 Jun 2000 16:52:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5ENv8I28198;
	Wed, 14 Jun 2000 16:57:08 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 16:57:08 -0700 (PDT)
Message-Id: <s947c43e.070@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 14 Jun 2000 17:43:19 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <ietf-ldapext@netscape.com>, <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5ENv5128148
Resent-Message-ID: <"1KkCrC.A.63G.SvBS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 12:14:53 PM >>>

>How does this control behave in the face of subtypes of the
>provided AttributeDescriptions?

If an attribute is specified, only that attribute is considered for returning duplicate entries, subtypes of that attribute are not considered. I'll add text to make this clear.

>It should be an error to specify "cn;binary,cn".  I don't
>think ";binary" actually makes sense in this context as
>this mechanism does not specify how the attribute is to
>be transferred (this should be clearly stated).  I would
>recommend stating that clients SHOULD NOT specify options
>which indicate transfer encoding.

hmm. The Server Side Sorting control doesn't go into this level of detail either. What happens with that control in this case? I agree that it doesn't make sense in the Duplicate Entries draft. Though I don't think we need to go to these depths of detail, I'll add something along these lines nonetheless.

>RFC 2019 edits.  There are a number of lowercase should, must,
>may's in the document.  I suggest that the author review each
>of these and, where appropriate, use the uppercase varient.

Thanks, in reviewing I also found a few should's that should be MUSTs.

>The document is missing a "Security Considerations" section.
>This must be included.  In particular, I would suggest detailing
>DoS attacks using this control... just imagine specifying all
>the schema related attributes on a subschema subentry search...
>(this is hinted at in section 7).

Yes, I'll add.

>4.1:
>   An AttributeDescription should only occur once in the list.  If an
>   AttributeDescription is included in the DuplicateEntryRequest
>   multiple times, the server should return an unwillingToPerform error
>   in the DuplicateEntryResponse.
>
>I believe that unwillingToPerform should not be used to indicate
>this error.  I suggest protocolError.

I agree. I lifted this verbatim from the Server Side Sorting draft which still has this wording. I'll fix for the dupent draft.

>4.2:
>DuplicateEntryResponse ::= SEQUENCE {
>          result   ENUMERATED { ... }
>
>Is this list of possible result codes a restriction?  If so,
>is a MUST, SHOULD, or MAY?  I suggest other codes be allowed
as appropriate.  

Again, I lifted the way I did this from the sorting draft. What's nice about this list is that it gives more specific meanings to the errors listed. I will do something to make it allowable to send any LDAP result code (tho some make absolutely no sense), and simply list the ones that have specific meanings in the draft.

>Also wherever a resultCode is returned,
>optional human readable text should be provided as well.

Fine, I'll add that capability.

>   operations error    (1),  -- server internal failure
>             ^ typo

Thanks.

>Also, note my past and future comments regarding operationsError
>v. other.  I believe other is more appropriate for internal
>failures and operationsError is more appropriate for request
>sequencing errors.  This, of course, is an rfc2251bis/errcodes
>issue (which we should address separately).

yes

>   attributeType   AttributeDescription OPTIONAL
>
>I believe it inappropriate for this control to return this
>information.  This feature should be part of a more general
>disclose error information control.

I don't think it's inappropriate, especially where it's optional. Again I lifted this from the SSS control. I wonder why these complaints weren't lodged against it as well? If you feel strongly, I'll remove it and state that the server MAY include this information in the errorMessage (which I will also add as I stated above).

>Examples:
>
>I suggest using a base DN and domains reserved for examples,
>such as "dc=example,dc=net" and example.com.  I would also
>avoid using trademarked names in the examples (though I
>do chuckle at Elmer's e-mail address).

sigh. Fine.

Jim



From list@netscape.com  Wed Jun 14 20:06:46 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06296
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 20:06:45 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F00vb03494;
	Wed, 14 Jun 2000 17:00:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F054U02012;
	Wed, 14 Jun 2000 17:05:04 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 17:05:04 -0700 (PDT)
Message-Id: <3.0.5.32.20000614170450.00955100@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 17:04:50 -0700
To: M.Wahl@innosoft.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-just-ldapv3-rescodes-02.txt
Cc: ietf-ldapext@netscape.com
In-Reply-To: <12680.961002534@threadgill.austin.innosoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"WsgYpB.A.Af.v2BS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Does this document update RFC 2251?

I believe it should.  RFC 2251 needs to updated in
this area and this document should provide it.  If it
doesn't update RFC 2251, I suggest it be submitted on
the Informational track as it would only be providing
guidiance to implementors, not refined specifications.

I believe the document needs some form of applicability
statement.

Kurt







From list@netscape.com  Wed Jun 14 20:33:57 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06633
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 20:33:50 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F0Of806493;
	Wed, 14 Jun 2000 17:24:41 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F0WDo25120;
	Wed, 14 Jun 2000 17:32:13 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 17:32:13 -0700 (PDT)
Message-Id: <3.0.5.32.20000614173208.00938a50@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 17:32:08 -0700
To: "Jim Sermersheim" <JIMSE@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s947c43e.070@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"NShj2B.A.GIG.LQCS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 05:43 PM 6/14/00 -0600, Jim Sermersheim wrote:
>>RFC 2019 edits.

s/2019/2119/  (not sure why I continuely refer to IPv6 over FDDI)

>>There are a number of lowercase should, must,
>>may's in the document.  I suggest that the author review each
>>of these and, where appropriate, use the uppercase varient.
>
>Thanks, in reviewing I also found a few should's that should be MUSTs.

Can you provide details (or a revised draft)?






From list@netscape.com  Wed Jun 14 20:49:41 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06735
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 20:49:40 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F0ef808915;
	Wed, 14 Jun 2000 17:40:41 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F0mCg01770;
	Wed, 14 Jun 2000 17:48:12 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 17:48:12 -0700 (PDT)
Message-Id: <s947d28a.011@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 14 Jun 2000 18:44:22 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <ietf-ldapext@netscape.com>, <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5F0m8101698
Resent-Message-ID: <"DCFBUC.A.3a.JfCS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 12:45:14 PM >>>
>Additionally, I believe it might be generally useful for
>clients to be able to distinguished duplicated entries
>from non-duplicated entries returned by a search with
>this control.  I suggest that a control be returned
>in each LDAPMessage which contains a duplicated entry.

Interesting, if this were done, we'd need to define exactly when this control is to be returned. For example, a search result entry is returned that _would_ have been split into duplicates if it had multi-values, but it wasn't because it happened to have a single value, does it come with a control? 

>In particular, this would be useful where the server was
>able to return duplicate entries for a subset of the
>requested entries and the control was marked non-critical.

If the mechanism allows for partial support, I would think the semantics of the criticality field would change. Users will probably expect that whether or not the mechanism is serviced fully or partially, it won't fail even when marked critical. To allow for that, we could introduce yet another field that modifies the semantics of a critical control (call it partialAllowed). Given a critical control, if partialAllowed is TRUE, the operation will still succeed as long as the control is supported on one or more entries (even if those entries don't produce duplicates). If partialAllowed is FALSE and the control is critical, then the server must be able to apply the control to all search result entries, otherwise the entire operation fails.

I'll wait for your feedback before diving into this one.

>Oh, and another implementation note, servers which
>chain requests should avoid passing this control to
>other servers by splitting chained results itself.

OK.

Jim




From list@netscape.com  Wed Jun 14 21:25:57 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07094
	for <ldapext-archive@odin.ietf.org>; Wed, 14 Jun 2000 21:25:57 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F1Gs812565;
	Wed, 14 Jun 2000 18:16:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F1OQk15177;
	Wed, 14 Jun 2000 18:24:26 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 18:24:26 -0700 (PDT)
Message-Id: <3.0.5.32.20000614182420.0094e100@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 18:24:20 -0700
To: "Jim Sermersheim" <JIMSE@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s947d28a.011@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"EGxbAC.A.vsD.IBDS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 06:44 PM 6/14/00 -0600, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 12:45:14 PM >>>
>>Additionally, I believe it might be generally useful for
>>clients to be able to distinguished duplicated entries
>>from non-duplicated entries returned by a search with
>>this control.  I suggest that a control be returned
>>in each LDAPMessage which contains a duplicated entry.
>
>Interesting, if this were done, we'd need to define exactly when this control is to be returned. For example, a search result entry is returned that _would_ have been split into duplicates if it had multi-values, but it wasn't because it happened to have a single value, does it come with a control? 

No.  Only duplicated entries would have control.

>>In particular, this would be useful where the server was
>>able to return duplicate entries for a subset of the
>>requested entries and the control was marked non-critical.
>
>If the mechanism allows for partial support,

It already does per 4.2:
   A result field is provided here to allow feedback in the case where
   the criticality of the request control is FALSE, and the server
   could not process the control - yet it could complete the search
   operation successfully.

That is, the server completed the search but failed to split all
entries as requested.

>I would think the semantics of the criticality field would change.

Actually, we should review the additional semantics of upon the
criticality flag proposed in the I-D.  Per RFC 2251:
   If the control is unrecognized or inappropriate but the criticality
   field is FALSE, the server MUST ignore the control.

I think the specification should allow partial processing based upon
the criticality flag of the control.  If such is desirable, then
a separate flag (within the control value) should be used.

>Users will probably expect that whether or not the mechanism is serviced fully or partially, it won't fail even when marked critical.

Precisely why the control value should specify whether the
server may provide partial processing.

>To allow for that, we could introduce yet another field that modifies the semantics of a critical control (call it partialAllowed).

An paritial field should modify the semantics of the control irregardless
of whether it's critical or not.  The critical flag should be used
by the server (which recongizes the control) to determine if the
specified control value (partial flag, attribute descriptions) is
appropriate or not.

>Given a critical control, if partialAllowed is TRUE, the operation will still succeed as long as the control is supported on one or more entries (even if those entries don't produce duplicates). If partialAllowed is FALSE and the control is critical, then the server must be able to apply the control to all search result entries, otherwise the entire operation fails.

Again, we should be careful not to overload the semantics of the
critical flag.



From list@netscape.com  Thu Jun 15 00:04:37 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11176
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 00:04:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F3sM823189;
	Wed, 14 Jun 2000 20:54:22 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F41sI27172;
	Wed, 14 Jun 2000 21:01:54 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 21:01:54 -0700 (PDT)
Message-Id: <s947fd62.087@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Wed, 14 Jun 2000 21:47:16 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <Kurt@openldap.org>
Cc: <ietf-ldapext@netscape.com>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5F41h127109
Resent-Message-ID: <"dyV8bC.A.7nG.wUFS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 7:24:20 PM >>>
>>Interesting, if this were done, we'd need to define exactly when this control is to be returned. For example, a search result entry is returned that _would_ have been split into duplicates if it had multi-values, but it wasn't because it happened to have a single value, does it come with a control? 
>
>No.  Only duplicated entries would have control.

In that case, can't the client just infer whether it's getting duplicates back or not based on the exsistence of duplicated DN's and/or the presence of multi-valued attr's where none should be?

>>>In particular, this would be useful where the server was
>>>able to return duplicate entries for a subset of the
>>>requested entries and the control was marked non-critical.
>>
>>If the mechanism allows for partial support,
>
>It already does per 4.2:
>   A result field is provided here to allow feedback in the case where
>   the criticality of the request control is FALSE, and the server
>   could not process the control - yet it could complete the search
>   operation successfully.
>
>That is, the server completed the search but failed to split all
>entries as requested.

No, it may not be clear, but the intent here is that this is an "all or nothing" control. Either the control is supported across the entire set of results or it's not.

>I think the specification should allow partial processing based upon
>the criticality flag of the control.  If such is desirable, then
>a separate flag (within the control value) should be used.

You mean "I *don't* think the..." right?

<snip>

>Again, we should be careful not to overload the semantics of the
>critical flag.

Agreed, if the control is critical, it must work as specified. the partialAllowed flag within the controlValue would be one of the specifiers.

Jim



From list@netscape.com  Thu Jun 15 00:24:19 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11345
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 00:24:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F4FM824768;
	Wed, 14 Jun 2000 21:15:22 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F4MsA05417;
	Wed, 14 Jun 2000 21:22:54 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 21:22:54 -0700 (PDT)
Message-Id: <3.0.5.32.20000614212245.0096fbf0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 14 Jun 2000 21:22:45 -0700
To: "Jim Sermersheim" <JIMSE@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s947fd62.088@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"96Sy-D.A.RUB.coFS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 09:47 PM 6/14/00 -0600, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 7:24:20 PM >>>
>>>Interesting, if this were done, we'd need to define exactly when this control is to be returned. For example, a search result entry is returned that _would_ have been split into duplicates if it had multi-values, but it wasn't because it happened to have a single value, does it come with a control? 
>>
>>No.  Only duplicated entries would have control.
>
>In that case, can't the client just infer whether it's getting duplicates back or not based on the exsistence of duplicated DN's and/or the presence of multi-valued attr's where none should be?

No, because the result code might be sizeLimitExceeded after
one of many dups were returned.  (I assume this is how the
control interacts with sizeLimits... this should be specified).

>>>>In particular, this would be useful where the server was
>>>>able to return duplicate entries for a subset of the
>>>>requested entries and the control was marked non-critical.
>>>
>>>If the mechanism allows for partial support,
>>
>>It already does per 4.2:
>>   A result field is provided here to allow feedback in the case where
>>   the criticality of the request control is FALSE, and the server
>>   could not process the control - yet it could complete the search
>>   operation successfully.
>>
>>That is, the server completed the search but failed to split all
>>entries as requested.
>
>No, it may not be clear, but the intent here is that this is an "all or nothing" control. Either the control is supported across the entire set of results or it's not.

So, the server must first run through all the entries to determine
if it able to honor the control before returning a single entry.

>>I think the specification should allow partial processing based upon
>>the criticality flag of the control.  If such is desirable, then
>>a separate flag (within the control value) should be used.
>
>You mean "I *don't* think the..." right?
Yes.

><snip>
>
>>Again, we should be careful not to overload the semantics of the
>>critical flag.
>
>Agreed, if the control is critical, it must work as specified.

It MUST work as specified if recongized and appropriate.  Otherwise,
ignored if not critical or unavailableCriticalExtension if critical.

>the partialAllowed flag within the controlValue would be one of the specifiers.

Yes.



From list@netscape.com  Thu Jun 15 02:14:57 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23944
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 02:14:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5F69Jb06532;
	Wed, 14 Jun 2000 23:09:19 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5F6DSg12258;
	Wed, 14 Jun 2000 23:13:28 -0700 (PDT)
Resent-Date: Wed, 14 Jun 2000 23:13:28 -0700 (PDT)
Message-Id: <s9481e22.030@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 15 Jun 2000 00:06:53 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <Kurt@openldap.org>
Cc: <ietf-ldapext@netscape.com>
Subject: Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5F6DQ112212
Resent-Message-ID: <"PcTaTC.A.F_C.HQHS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 10:22:45 PM >>>
<snip>
>>In that case, can't the client just infer whether it's getting duplicates back or not based on the exsistence of duplicated DN's and/or the presence of multi-valued attr's where none should be?
>
>No, because the result code might be sizeLimitExceeded after
>one of many dups were returned.  (I assume this is how the
>control interacts with sizeLimits... this should be specified).

Bah... fine.

<snip>
>>No, it may not be clear, but the intent here is that this is an "all or nothing" control. Either the control is supported across the entire set of results or it's not.
>
>So, the server must first run through all the entries to determine
>if it able to honor the control before returning a single entry.

Before you introduced the notion of the control being able to handle partial support, the thought was that the server can either support the control or not. The scenario above (timeLimit or sizeLimit exceeded) does present a problem though. I'm going to add the partial support stuff, so this discussion is moot now.

<snip>
agreed

Thanks.

Jim



From list@netscape.com  Thu Jun 15 12:52:19 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07719
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 12:52:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5FGkKb17778;
	Thu, 15 Jun 2000 09:46:20 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5FGoTQ16345;
	Thu, 15 Jun 2000 09:50:29 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 09:50:29 -0700 (PDT)
Message-Id: <3.0.5.32.20000615095022.009a4480@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 15 Jun 2000 09:50:22 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: employeenumber<=1100008
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"iSiGN.A.B_D.UlQS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I've been reviewing the BLITS 2.3 and a question regarding the
Less-Than-Or-Equal-To (3.3.2.1.4) test.
  http://www.opengroup.org/directory/dc5/blits0/blits23.htm#3.3.2.1

The test uses the filter (employeenumber<=1100008) expecting a
subset of the entries in the DIT to be returned.  However,
employeenumber is defined in RFC 2798, 2.4 as:
   ( 2.16.840.1.113730.3.1.3
      NAME 'employeeNumber'
      DESC 'numerically identifies an employee within an organization'
      EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15                      
      SINGLE-VALUE )

Note the lack of an ORDERING matching rule.  Per X.501, 12.4.5:
  If no ordering matching rule is indicated the Directory shall treat
  any assertion of an ordering match using the syntax provided by the
  Directory Abstract Service as undefined.

That is, the filter should evaluate to undefined and per three
value logic, no entries should be returned.  Is this correct?

If not correct, how does the server determine a suitable
matching rule to use?

	Kurt



From list@netscape.com  Thu Jun 15 13:48:05 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09989
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 13:48:04 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5FHcg828957;
	Thu, 15 Jun 2000 10:38:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5FHkFU18987;
	Thu, 15 Jun 2000 10:46:15 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 10:46:15 -0700 (PDT)
Message-ID: <ED026032A3FCD211AEDA00105A9C4696017C1087@sothmxs05.entrust.com>
From: Mike Just <mike.just@entrust.com>
To: "'Kurt D. Zeilenga'" <Kurt@openldap.org>, M.Wahl@innosoft.com
Cc: ietf-ldapext@netscape.com,
        Kristianne Leclair
	 <kristianne.leclair@entrust.com>,
        "'Jim Sermersheim'" <JIMSE@novell.com>,
        "'Mark Smith'" <mcs@netscape.com>
Subject: RE: WG Last Call: draft-just-ldapv3-rescodes-02.txt
Date: Thu, 15 Jun 2000 13:46:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"E4li2D.A.QoE.lZRS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

The draft adds/changes portions of 2251 that are relevant to result codes.
I believe that Mark had indicated at the last IETF meeting that this draft
(along with other suggested updates) would be included in the eventual
update to 2251. At that point, it specifications would be requirement for
conformance with 2251.

I indicated at the last meeting that this document should be on the
standards track since it does add to, as well as amend 2251. Whereas if it
just gathered and combined information from 2251 and X.511, informational
status might be more appropriate. As an example, the description of
operationsError differs somewhat from 2251 since 2251 indicates that this
error code may be returned from a Bind operation attempt. On the other hand,
we specify that operationsError is applicable to all operations except Bind.

Once this draft reaches RFC status, implementers can choose to conform to it
(assuming that they do not already).  

Would a paragraph summarizing these points above better indicate the
applicability of the document for you?

Thanks,
Mike J. 


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, June 14, 2000 8:05 PM
> To: M.Wahl@innosoft.com
> Cc: ietf-ldapext@netscape.com
> Subject: Re: WG Last Call: draft-just-ldapv3-rescodes-02.txt
> 
> 
> Does this document update RFC 2251?
> 
> I believe it should.  RFC 2251 needs to updated in
> this area and this document should provide it.  If it
> doesn't update RFC 2251, I suggest it be submitted on
> the Informational track as it would only be providing
> guidiance to implementors, not refined specifications.
> 
> I believe the document needs some form of applicability
> statement.
> 
> Kurt
> 
> 
> 
> 
> 



From list@netscape.com  Thu Jun 15 13:57:40 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10271
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 13:57:39 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5FHmR800754;
	Thu, 15 Jun 2000 10:48:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5FHtxQ25948;
	Thu, 15 Jun 2000 10:55:59 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 10:55:59 -0700 (PDT)
Message-Id: <3.0.5.32.20000615105536.0096b100@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 15 Jun 2000 10:55:36 -0700
To: Mike Just <mike.just@entrust.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: RE: WG Last Call: draft-just-ldapv3-rescodes-02.txt
Cc: M.Wahl@innosoft.com, ietf-ldapext@netscape.com,
        Kristianne Leclair <kristianne.leclair@entrust.com>,
        "'Jim Sermersheim'" <JIMSE@novell.com>,
        "'Mark Smith'" <mcs@netscape.com>
In-Reply-To: <ED026032A3FCD211AEDA00105A9C4696017C1087@sothmxs05.entrust
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"VKKwhB.A.AVG.tiRS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 01:46 PM 6/15/00 -0400, Mike Just wrote:
>The draft adds/changes portions of 2251 that are relevant to result codes.

So, it updates RFC 2251.

>I believe that Mark had indicated at the last IETF meeting that this draft
>(along with other suggested updates) would be included in the eventual
>update to 2251. At that point, it specifications would be requirement for
>conformance with 2251.

If it add/changes (updates) 2251, it's applies as soon as it's approved
as a Proposed Standard. 

>I indicated at the last meeting that this document should be on the
>standards track since it does add to, as well as amend 2251. Whereas if it
>just gathered and combined information from 2251 and X.511, informational
>status might be more appropriate. As an example, the description of
>operationsError differs somewhat from 2251 since 2251 indicates that this
>error code may be returned from a Bind operation attempt. On the other hand,
>we specify that operationsError is applicable to all operations except Bind.
>
>Once this draft reaches RFC status, implementers can choose to conform to it
>(assuming that they do not already).  

It makes zero sense to have two specifications for error handling.
Either RFC 2251 is the definitive or this document, once approved,
is.

>Would a paragraph summarizing these points above better indicate the
>applicability of the document for you?

Yes.



From list@netscape.com  Thu Jun 15 14:14:59 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10931
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 14:14:58 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5FI9Fb01087;
	Thu, 15 Jun 2000 11:09:15 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5FIDOE06592;
	Thu, 15 Jun 2000 11:13:24 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 11:13:24 -0700 (PDT)
Message-Id: <3.0.3.32.20000615191136.006da9ec@mailhome.rdg.opengroup.org>
X-Sender: cjh@mailhome.rdg.opengroup.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 15 Jun 2000 19:11:36 +0100
To: "Kurt D. Zeilenga" <Kurt@openldap.org>, ietf-ldapext@netscape.com
From: Chris Harding <c.harding@opengroup.org>
Subject: Re: (c.harding 42357) employeenumber<=1100008
In-Reply-To: <3.0.5.32.20000615095022.009a4480@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"ldGjvB.A.kmB.AzRS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi, Kurt -

Thanks for raising this. It looks as though the author of that particular
test (me) may have made an unwarranted assumption about employeenumber.
I'll revise that test in the update to BLITS that I'm doing for the
DirConnect next week.

At 09:50 AM 15/06/00 -0700, Kurt D. Zeilenga wrote:
>I've been reviewing the BLITS 2.3 and a question regarding the
>Less-Than-Or-Equal-To (3.3.2.1.4) test.
>  http://www.opengroup.org/directory/dc5/blits0/blits23.htm#3.3.2.1
>
>The test uses the filter (employeenumber<=1100008) expecting a
>subset of the entries in the DIT to be returned.  However,
>employeenumber is defined in RFC 2798, 2.4 as:
>   ( 2.16.840.1.113730.3.1.3
>      NAME 'employeeNumber'
>      DESC 'numerically identifies an employee within an organization'
>      EQUALITY caseIgnoreMatch
>      SUBSTR caseIgnoreSubstringsMatch
>      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15                      
>      SINGLE-VALUE )
>
>Note the lack of an ORDERING matching rule.  Per X.501, 12.4.5:
>  If no ordering matching rule is indicated the Directory shall treat
>  any assertion of an ordering match using the syntax provided by the
>  Directory Abstract Service as undefined.
>
>That is, the filter should evaluate to undefined and per three
>value logic, no entries should be returned.  Is this correct?
>
>If not correct, how does the server determine a suitable
>matching rule to use?
>
>	Kurt
>
>
>

Regards,

Chris
+++++

========================================================================
                     THE DIRECTORY-ENABLED ENTERPRISE:
                     26-27 June, 2000   Austin, Texas
    
                 The State-of-the-Art of Directory Products, 
                          The Customer Perspective,
                The Vision of the Directory-Enabled Enterprise.

                 http://www.opengroup.org/public/member/q300/

           Chris Harding
  T H E    Directory Program Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:c.harding@opengroup.org  Phone:  +44 118 950 8311 x2262
           WWW: http://www.opengroup.org   Mobile: +44 771 8588820  
========================================================================



From list@netscape.com  Thu Jun 15 15:59:05 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13247
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 15:59:04 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5FJdg818224;
	Thu, 15 Jun 2000 12:39:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5FJlF218088;
	Thu, 15 Jun 2000 12:47:15 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 12:47:15 -0700 (PDT)
Content-return: allowed
Date: Thu, 15 Jun 2000 15:46:54 -0400
From: "Herbers, Brett" <Brett.Herbers@usa.xerox.com>
To: "'ietf-ldapext@netscape.com'" <ietf-ldapext@netscape.com>
Message-id: 
 <F124A4236064D211859A0008C74CE35D018D7929@usa0815ms1.eng.mc.xerox.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Resent-Message-ID: <"0qbCnD.A.QaE.CLTS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

	Hello,
		I got the word that you might be able to help me with a
problem that has arose, so I though that I might look into it.  I heard that
you knew LDAP and DL's fairly well.  I have currently implementd an ldap
client in C for the Xerox global address book.  This client is in the Unix
operating system.  It works great, however it is not recognizing the
distribution lists from the central location of the global address book.  Is
there a way to implement distribution lists in LDAP?? If so, what is the
best way to go about it??  We do not want to totally implement distribution
lists in our client, we only want the client to retrieve DL's from the Xerox
LDAP server.  Thanks for your consideration of this message. Thanks Again!!

	Brett L. Herbers
	Software Development (OSG)
	Bld. 820
	Fairport, NY







From list@netscape.com  Thu Jun 15 21:23:29 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19305
	for <ldapext-archive@odin.ietf.org>; Thu, 15 Jun 2000 21:23:28 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5G1Hmj19034;
	Thu, 15 Jun 2000 18:17:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5G1Brs14915;
	Thu, 15 Jun 2000 18:11:54 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 18:11:54 -0700 (PDT)
Message-ID: <E7E4455BFFB4D311BC78009027D0D18C01FFEEF1@aspams01.cai.com>
From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
To: "Herbers, Brett" <Brett.Herbers@usa.xerox.com>,
        "'ietf-ldapext@netscape.com'" <ietf-ldapext@netscape.com>
Subject: RE: 
Date: Fri, 16 Jun 2000 11:10:56 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"0M7df.A.fkD.F7XS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I would suggest using the groupOfNames attribute in an DL entry.

Ron.

-----Original Message-----
From: Herbers, Brett [mailto:Brett.Herbers@usa.xerox.com]
Sent: Friday, 16 June 2000 5:47
To: 'ietf-ldapext@netscape.com'
Subject: 


	Hello,
		I got the word that you might be able to help me with a
problem that has arose, so I though that I might look into it.  I heard that
you knew LDAP and DL's fairly well.  I have currently implementd an ldap
client in C for the Xerox global address book.  This client is in the Unix
operating system.  It works great, however it is not recognizing the
distribution lists from the central location of the global address book.  Is
there a way to implement distribution lists in LDAP?? If so, what is the
best way to go about it??  We do not want to totally implement distribution
lists in our client, we only want the client to retrieve DL's from the Xerox
LDAP server.  Thanks for your consideration of this message. Thanks Again!!

	Brett L. Herbers
	Software Development (OSG)
	Bld. 820
	Fairport, NY






From list@netscape.com  Fri Jun 16 02:54:33 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06992
	for <ldapext-archive@odin.ietf.org>; Fri, 16 Jun 2000 02:54:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5G6mgH15059;
	Thu, 15 Jun 2000 23:48:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5G6qq610315;
	Thu, 15 Jun 2000 23:52:52 -0700 (PDT)
Resent-Date: Thu, 15 Jun 2000 23:52:52 -0700 (PDT)
Date: Thu, 15 Jun 2000 23:52:25 -0700 (PDT)
Message-Id: <200006160652.e5G6qLk28902@xwing.netscape.com>
From: wholesale1a@KXYT.hotmail.com
To: ietf-ldapext@UBRE.netscape.com
Subject:  Over $50,000.00 For ietf-ldapext In 90 Days Or Less -XLBE
X-Reply-To:  wholesale1a@hotmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"aXWYID.A.qgC.C7cS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Subject: Over $50,000.00 For ietf-ldapext In 90 Days Or Less

Hello ietf-ldapext,

>>Your address is included on a list of prospective entrepreneurs
>>who wish to receive information pertaining to Home Business
>>Opportunities. If you wish to learn about an exceptional
>>opportunity in the Home Business arena...Read On. If this
>>message offends you or angers you in anyway ... Please respond
>>with "remove" as the subject ... Please delete immediately and
>>you will not receive this message again.>box. See legal disclaimer at the end of this text. Thank 
you.
>_________________________________________________________________________
__
_________
>
>>
>> "AS SEEN ON NATIONAL T.V."
>>
>> Thank you for your time and Interest.
>> This is the letter you've been hearing about in the news lately.
>>
>> Due to the popularity of this letter on the internet, a major
>> nightly news program recently devoted an entire show to the
>> investigation of the program, described below, to see if it really
>> can make people money.
>>
>> The show also investigated whether or not the program was
>> legal. Their findings proved once and for all that there are,
>> absolutely no laws prohibiting the participation in the program.
>> This has helped to show people that this is a simple, harmless
>> and fun way to make some extra money at home.
>>
>> The results of this show have been truly remarkable. Since so
>> many people are participating now, those involved are doing much
>> better than ever before. Everyone makes more as
>> more people try it out. It is very, very exciting to be a part of
>> this plan. You will understand once you experience it.
>>
>> "HERE IT IS, BELOW"
>>
>> ================================================
>> ================================================
>>
>> *** Print This Now For Future Reference ***
>>
>> The following income opportunity is one you may be
>> interested in taking a look at.  It can be started with VERY
>> LITTLE investment and the income return is TREMENDOUS!!!
>>
>> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>>
>> If you would like  to make at least $50,000 in less than 90
>> days! Please read the enclosed program...THEN READ IT
>> AGAIN!!!
>>
>> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>>
>> THIS IS A LEGITIMATE, LEGAL, MONEY MAKING
>> OPPORTUNITY.   It does not require you to come into
>> contact with people, do any hard work and best of all, you
>> never have to leave the house except to get the mail.  If you
>> believe that someday you'll get that big break that you've
>> been waiting for, THIS IS IT!  Simply follow the instructions,
>> and your dreams will come true.  This  e-mail marketing
>> program works perfectly...100%, EVERY TIME.  E-mail is the
>> sales tool of the future.  Take advantage of this
>> non-commercialized method of advertising NOW!!!  The
>> longer you wait, the more people will be doing business using
>> e-mail. Get your piece of this program now!
>>
>> MULTI-LEVEL MARKETING (MLM) has finally gained
>> respectability.  It is being taught in the Harvard Business
>> School, both Stanford Research and the Wall Street
>> Journal have stated that between 50% and 65% of all goods
>> and services will be sold through multi-level methods by the
>> late 1990's.  This is a Multi-Billion Dollar industry and of
>> the 500,000 millionaires in the U.S., 20% (100,000)  made
>> their fortune in the last few years in MLM.  Moreover,
>> statistics show 45 people become millionaires everyday
>> through Multi-Level Marketing.
>>
>> You may have heard this story before, but over the summer
>> Donald Trump made an appearance on the David Letterman
>> Show. Dave asked him what he would do if he lost
>> everything and had to start over from scratch. Without
>> hesitating, Trump said he would find a good network
>> marketing company and get to work.  The audience started
>> to hoot and boo him. He looked out at the audience and
>> dead-panned his response - "That's why I'm sitting up here
>> and you are all sitting out there!"
>>
>> With network marketing you have two sources of income.
>> Direct commissions from sales you make yourself and
>> commissions from sales made by people you introduce to the
>> business.
>>
>> Residual income is the secret of the wealthy. It means
>> investing time or money once and getting paid again and
>> again and again.  In network marketing, it also means getting
>> paid for the work of others.
>>
>> The enclosed information is something I almost let slip
>> through my fingers.  Fortunately, sometime later I re-read
>> everything and gave some thought and study to it.
>>
>> My name is Ellie Gilbert. Two years ago, the
>> corporation I worked for, the past twelve years, down-sized
>> and my position was eliminated.  After many unproductive job
>> interviews, I decided to open my own business.  Over the
>> past year, I incurred many unforeseen financial problems. I
>> owed my family, friends and creditors over $40,000..
>> I just couldn't seem to make ends meet.
>> I had to refinance and borrow against my home to support
>> my family and struggling business.
>> AT THAT MOMENT something significant happened in my life
>> and I am writing to share the experience in hopes that
>> this will change your life, FINANCIALLY, FOREVER!!!
>>
>> In mid December, I received this program via e-mail.  Six
>> month's prior to receiving this program I had been sending
>> away for information on various business opportunities. All of
>> the programs I received, in my opinion, were not cost
>> effective.  They were either too difficult for me to
>> comprehend or the initial investment was too much for me to
>> risk to see if they would work or not. One claimed that I
>> would make a million dollars in one year...it didn't tell me
>> I'd have to write a best selling book to make it!
>>
>> But, as I was saying, in December of 1997 I received this
>> program. I didn't send for it, or ask for it, they just got my
>> name off a mailing list. THANK GOODNESS FOR THAT!
>> After reading it several times, to make sure I was reading it
>> correctly, I couldn't believe my eyes.  Here was a MONEY
>> MAKING PHENOMENON. I could invest as much as I
>> wanted to start, without putting me further into debt.  After I
>> got a pencil and paper and figured it out, I would at least get
>> my money back.  But like most of you I was still a little
>> skeptical and a little worried about the legal aspects of it all.
>> So I checked it out with the U.S. Post Office (1-800-725-
>> 2161 24-hrs) and they confirmed that it is indeed legal!
>> After determining the program was LEGAL and NOT A
>> CHAIN LETTER, I decided  "WHY NOT."
>>
>> Initially I sent out 10,000 e-mails. The great thing
>> about e-mail is that I don't need any money for printing
>> to send out the program, and because
>> all of my orders are fulfilled via e-mail, the only expense is my
>> time. I'm telling you as it is, I hope it doesn't turn you off,
>> but I promised myself that I would not "rip-off" anyone, no
>> matter how much money it cost me.
>>
>> In less than one week, I was starting to receive orders for
>> REPORT #1. By January 13, I had received 26 orders for
>> REPORT #1. Your goal is to "RECEIVE at least 20
>> ORDERS FOR REPORT #1 WITHIN 2 WEEKS. If you
>> don't, SEND OUT MORE PROGRAMS UNTIL YOU DO!"
>> My first step in making $50,000 in 90 days was done. By
>> January 30, I had received 196 orders for REPORT #2.
>> Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR
>> REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT
>> MORE PROGRAMS UNTIL YOU DO.  ONCE YOU HAVE
>> 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL
>> MAKE YOUR $50,000 GOAL."  Well, I had 196 orders for
>> REPORT #2, 96 more than I needed.  So I sat back and
>> relaxed. By March 1, of my e-mailing of 10,000, I received
>> $58,000 with more coming in every day.
>>
>
>
>I paid off ALL my debts and bought a much needed new car.
>> Please take time to read the attached program, IT WILL
>> CHANGE YOUR LIFE FOREVER! Remember, it won't

>> work if you don't try it. This program does work, but you must
>> follow it EXACTLY!  Especially the rules of not trying to place
>> your name in a different place. It won't work, you'll lose out
>> on a lot of money!  In order for this program to work, you
>> must meet your goal of 20+ orders for REPORT #1, and
>> 100+ orders for REPORT #2 and you will make $50,000 or
>> more in 90 days. I AM LIVING PROOF THAT IT WORKS!
>>
>If you choose not to participate in this program, I am sorry. It
>> really is a great opportunity with little cost or risk to you. If
>> you choose to participate, follow the program and you will be
>> on your way to financial security.
>>
>> If you are a business owner and in financial trouble,
>> as I was, or you want to start your own business, consider
>> this a good luck sign. I DID!
>>
>> Sincerely,
>>
>> Ellie Gilbert
>>
>> P.S. Do you have any idea what $58,000 looks like
>> piled up on a kitchen table? IT'S AWESOME!
>>
>>
>> A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
>>
>> By the time you have read the enclosed program and reports
>> you should have concluded that such a program, one
>> that is legal, could not have been created by an amateur.
>>
>> Let me tell you a little about myself.  I had a profitable
>> business for 10 years. Then in 1979 my business began
>> falling off. I was doing the same things that were previously
>> successful for me, but it wasn't working. Finally, I figured it
>> out. It wasn't me, it was the economy. Inflation and
>> recession had replaced the stable economy that had been
>> with us since 1945. I don't have to tell you what happened
>> to the unemployment rate... because many of you know from
>> first hand experience.  There were more failures and
>> bankruptcies than ever before.
>>
>> The middle class was vanishing. Those who knew what
>> they were doing invested wisely and moved up. Those who
>> did not, including those who never had anything to save or
>> invest, were moving down into the ranks of the poor. As the
>> saying goes, "THE RICH GET RICHER AND THE POOR
>> GET POORER." The traditional methods of making money
>> will never allow you to "move up" or "get rich".
>>
>> You have just received information that can give you
>> financial freedom for the rest of your life, with "NO RISK" and
>> "JUST A LITTLE BIT OF EFFORT."  You can make more
>> money in the next few months than you have ever imagined.
>> I should also point out that I will not see a penny of this
>> money, nor anyone else who has provided a testimonial for
>> this program.  I have already made over 4 MILLION
>> DOLLARS!  I have retired from the program after sending out
>> over 16,000 programs.
>>
>> Follow the program EXACTLY AS INSTRUCTED.  Do not
>> change it in any way.  It works exceedingly well as it is now.
>> Remember to e-mail a copy of this exciting report to everyone
>> you can think of. One of the people you send this to may
>> send out 50,000...and your name will be on everyone of
>> them! Remember though, the more you send out the more
>> potential customers you will reach.
>>
>> So my friend, I have given you the ideas, information,
>> materials and opportunity to become financially independent,
>> IT IS NOW UP TO YOU!
>>
>> "THINK ABOUT IT"
>>
>> Before you delete this program from your mailbox, as I almost
>> did, take a little time to read it and REALLY THINK ABOUT
>> IT.  Get a pencil and figure out what could happen when
>> YOU participate. Figure out the worst possible response and
>> no matter how you calculate it, you will still make a lot of
>> money!  You will definitely get back what you invested.  Any
>> doubts you have will vanish when your first orders come in.
>> IT WORKS!
>> Jody Jacobs, Richmond, VA
>>
>>
>> HERE'S HOW THIS AMAZING PROGRAM WILL MAKE
>> YOU THOUSANDS OF DOLLARS
>>
>> INSTRUCTIONS:
>>
>> This method of raising capital  REALLY WORKS 100 %,
>> EVERY TIME.  I am sure that you could use up to $50,000 or
>> more in the next 90 days.  Before you say "BULL... ", please
>> read this program carefully.
>>
>> This is not a chain letter, but a perfectly legal money making
>> opportunity.  Basically, this is what you do:  As with all
>> multi-level businesses, we build our business by recruiting
>> new partners and selling our products. Every state in the
>> USA allows you to recruit new multi-level business partners,
>> and we offer a product for EVERY dollar sent. YOUR
>> ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so
>> you are not involved in personal selling. You do it privately in
>> your own home, store or office.  This is the GREATEST Multi-
>> Level Mail Order Marketing anywhere:
>>
>> This is what you MUST do:
>>
>> 1. Order all 4 reports shown on the list below (you can't sell
>> them if you don't order them).
>>
>> *  For each report, send $5.00 CASH, the NAME &
>> NUMBER OF THE REPORT YOU ARE ORDERING,
>> YOUR E-MAIL ADDRESS, and YOUR NAME &
>> RETURN ADDRESS (in case of a problem) to the
>> person whose name appears on the list next to the
>> report. MAKE SURE YOUR RETURN ADDRESS IS
>> ON YOUR ENVELOPE IN CASE OF ANY MAIL
>> PROBLEMS!
>>
>> *  When you place your order, make sure you order each
>> of the four reports.  You will need all four reports so
>> that you can save them on your computer and resell
>> them.
>>
>> *  Within a few days you will receive, via e-mail, each of
>> the four reports. Save them on your computer so they
>> will be accessible for you to send to the 1,000's of
>> people who will order them from you.
>>
>> 2.  IMPORTANT-- DO NOT alter the names of the people
>> who are listed next to each report, or their sequence on
>> the list, in any way other than is instructed below in steps
>> "a" through "f" or you will lose out on the majority of your
>> profits.  Once you understand the way this works, you'll
>> also see how it doesn't work if you change it. Remember,
>> this method has been tested, and if you alter it, it will not
>> work.
>>
>> a.  Look below for the listing of available reports.
>>
>> b.  After you've ordered the four reports, take this
>> letter and remove the name and address under
>> REPORT #4. This person has made it through the cycle
>> and is no doubt counting their $50,000!
>>
>> c.  Move the name and address under REPORT #3 down
>> to REPORT #4.
>>
>> d.  Move the name and address under REPORT #2 down
>> to REPORT #3.
>>
>> e.  Move the name and address under REPORT #1 down
>> to REPORT #2.
>>
>> f.  Insert your name/address in the REPORT #1 position.
>>
>> Please make sure you copy every name and address ACCURATELY!
>>
>> 3.  Take this entire letter, including the modified list of names,
>> and save it to your computer.  Make NO changes to the
>> instruction portion of this letter.
>>
>> 4.  Now you're ready to start an advertising campaign on the
>> WORLD WIDE WEB!  SEND OUT THIS LETTER (with your name added)
>> TO AS MANY PEOPLE AS YOU CAN, EVEN FRIENDS AND FAMILY.
>> Advertising on the WEB can be very, very inexpensive, and
>> there are HUNDREDS of FREE places to advertise.  Another
>> avenue which you could use for advertising is e-mail lists.
>> You can buy these lists for under $20/20,000 addresses or
>> you can pay someone to take care of it for you.  BE SURE
>> TO START YOUR AD CAMPAIGN IMMEDIATELY!
>>
>> 5.  For every $5.00 you receive, all you must do is e-mail
>> them the report they ordered.  THAT'S IT!  ALWAYS
>> PROVIDE SAME- DAY SERVICE ON ALL ORDERS!
>> This will help guarantee that the e-mail THEY send out,
>> with YOUR name and address on it, will be prompt
>> because they can't  advertise until they receive the report!
>> To grow fast be prompt and courteous.
>>
>> ------------------------------------------
>> AVAILABLE REPORTS
>> ------------------------------------------
>> ***Order Each REPORT by NUMBER and NAME***
>>
>> Notes:
>> -  ALWAYS SEND $5 CASH FOR EACH REPORT
>> -  ALWAYS SEND YOUR ORDER VIA THE QUICKEST
>> DELIVERY
>> -  Make sure the cash is concealed by wrapping it in at least
>> two sheets of paper
>> -  On one of those sheets of paper, include: (a) the number &
>> name of the report you are ordering, (b) your e-mail address,
>> and (c) your postal address.
>> ________________________________________________
>> REPORT #1 "THE INSIDER'S GUIDE TO ADVERTISING FOR FREE ON THE INTERNET">
>> ORDER REPORT #1 FROM:>
>
>> > Sandlin Sales
>      P.O. Box 414
>      Lawrenceburg, IN 47025
>___________________________________________________
>> REPORT #2 "THE INSIDERS GUIDE TO SENDING BULK E-MAIL ON THE INTERNET">
>> ORDER REPORT #2 FROM:>
>
>> Dominic Koklas
>> 27 Columbine Ct.
>> Middletown, NY  10940
>
>> ________________________________________________
>> REPORT #3 "THE SECRETS TO MULTI-LEVEL MARKETING ON THE INTERNET">
>> ORDER REPORT #3 From
>
>> > Mingo Bueno
>>    6814 Country Cross
>>    San Antonio, Texas  78240
________________________________________________
>> REPORT #4 "HOW TO BECOME A MILLIONAIRE UTILIZING THE POWER OF 
>>MULTI-LEVEL MARKETING AND THE INTERNET">
>> ORDER REPORT #4 FROM:>
>
>    Brian Pepe
>> 30 Shadey Pines
>> Fort Edward,NY  12828
>> > -----------------------------------------------------------------------
>> HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$
>> -----------------------------------------------------------------------
>>
>> Let's say you decide to start small just to see how well it
>> works. Assume your goal is to get 10 people to participate on
>> your first level.  (Placing a lot of FREE ads on the internet will
>> EASILY get a larger response.)  Also assume that everyone
>> else in YOUR ORGANIZATION gets ONLY 10 downline
>> members.  Follow this example to achieve the STAGGERING
>> results below.
>>
>> 1st level--your 10 members with $5.....................$50
>> 2nd level--10 members from those 10 ($5 x 100)........$500
>> 3rd level--10 members from those 100 ($5 x 1,000)...$5,000
>> 4th level--10 members from those 1,000 ($5x10,000).$50,000
>> THIS TOTALS  ------>   $55,550
>>
>> Remember, this assumes that the people who
>> participate only recruit 10 people each.  Think for a moment
>> what would happen if they got 20 people to participate!  Lots
>> of people get 100s of participants!  THINK ABOUT IT!
>>
>> Your cost to participate in this is practically nothing (surely
>> you can afford $20).  You obviously already have an internet
>> connection and e-mail is FREE! REPORT #3 shows you the
>> most productive methods for bulk e-mailing and purchasing
>> e-mail lists. Some list & bulk e-mail vendors even work on
>> trade!
>>
>> Over 50,000, new people, get on the internet EVERYDAY (CBS NEWS)!
>>
>> *******TIPS FOR SUCCESS*******
>>
>> *  TREAT THIS AS YOUR BUSINESS!  Be prompt,
>> professional, and follow the directions accurately.
>>
>> *  Send for the four reports IMMEDIATELY so you will have
>> them when the orders start coming in because:
>>
>> When you receive a $5 order, you MUST send out the
>> requested product (report) to comply with the U.S. Postal &
>> Lottery Laws, Title 18, Sections 1302 and 1341 or Title 18,
>> Section 3005 in the U.S. Code, also Code of Federal Regs.
>> vol. 16, Sections 255 and 436, which state that "a product
>> or service must be exchanged for money received."
>>
>> *  ALWAYS PROVIDE SAME-DAY SERVICE ON THE
>> ORDERS YOU RECEIVE.
>>
>> *  Be patient and persistent with this program. If you follow
>> the instructions exactly, the results WILL undoubtedly be
>> SUCCESSFUL!
>>
>> *  ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW
>> YOU WILL SUCCEED!
>>
>> *******YOUR SUCCESS GUIDELINE*******
>>
>> Follow these guidelines to help assure your success:
>>
>> If you don't receive 10 to 20 orders for REPORT #1 within
>> two weeks, continue advertising until you do.  Then, a
>> couple of weeks later you should receive at least 100 orders
>> for REPORT #2.  If you don't, continue advertising until you
>> do.  Once you have received 100 or more orders for
>> REPORT #2, YOU CAN RELAX, because the system is
>> already working for you, and the cash can continue to roll in!
>>
>> THIS IS IMPORTANT TO REMEMBER:
>>
>> Every time your name is moved down on the list, you are
>> placed in front of a DIFFERENT report.  You can KEEP
>> TRACK of your PROGRESS by watching which report
>> people are ordering from you.  If you want to generate more
>> income, send another batch of e-mails and start the whole
>> process again!  There is no limit to the income you will
>> generate from this business!
>>
>> PLEASE NOTE:  If you need help with starting a business,
>> registering a business name, learning how income tax is
>> handled, etc., contact your local office of the Small Business
>> Administration (a Federal agency) 1-(800)827-5722 for free
>> help and answers to questions.  Also, the Internal Revenue
>> Service offers free help via telephone and free seminars
>> about business tax requirements.  Your earnings and results
>> are highly dependant on your activities and advertising.  This
>> letter constitutes no guarantees stated nor implied.  In the
>> event that it is determined that this letter constitutes a
>> guarantee of any kind, that guarantee is now void.  Any
>> testimonials or amounts of earnings listed in this letter may be
>> factual or fictitious.  If you have any question of the legality of
>> this letter contact the Office of Associate Director for
>> Marketing Practices Federal Trade Commission Bureau of
>> Consumer Protection in Washington DC.
>>
>> *******T  E  S  T  I  M  O  N  I  A  L  S*******
>>
>> This program does work, but you must follow it EXACTLY!
>> Especially the rule of not trying to place your name in a
>> different position, it won't work and you'll lose a lot of
>> potential income.  I'm living proof that it works.  It really is a
>> great opportunity to make relatively easy money, with little
>> cost to you.  If you do choose to participate, follow the
>> program exactly, and you'll be on your way to financial
>> security.
>>
>> Sean McLaughlin, Jackson, MS
>>
>> My name is Frank.  My wife, Doris, and I live in Bel-Air, MD.  I
>> am a cost accountant with a major U.S. Corporation and I
>> make pretty good money.  When I received the program I
>> grumbled to Doris about receiving "junk mail." I made fun of
>> the whole thing, spouting my knowledge of the population
>> and percentages involved.  I "knew" it wouldn't work.  Doris
>> totally ignored my supposed intelligence and jumped in with
>> both feet.  I made merciless fun of her, and was ready to lay
>> the old "I told you so" on her when the thing didn't work...
>> well, the laugh was on me!  Within two weeks she had
>> received over 50 responses.  Within 45 days she had
>> received over $147,200 in $5 bills!  I was shocked!  I was
>> sure that I had it all figured and that it wouldn't work.  I AM a
>> believer now.  I have joined Doris in her "hobby."  I did have
>> seven more years until retirement, but I think of the "rat race"
>> and it's not for me.  We owe it all to MLM.
>>
>> Frank T., Bel-Air, MD
>>
>> I just want to pass along my best wishes and encouragement
>> to you.  Any doubts you have will vanish when your first
>> orders come in.  I even checked with the U.S. Post Office to
>> verify that the plan was legal.  It definitely is!  IT WORKS!
>>
>> Paul Johnson, Raleigh, NC
>>
>> The main reason for this letter is to convince you that this
>> system is honest, lawful, extremely profitable, and is a way to
>> get a large amount of money in a short time.  I was
>> approached several times before I checked this out.  I joined
>> just to see what one could expect in return for the minimal
>> effort and money required.  To my astonishment, I received
>> $36,470.00 in the first 14 weeks, with money still coming in.
>> Phillip A. Brown, Esq.
>>
>> Not being the gambling type, it took me several weeks to
>> make up my mind to participate in this plan.  But conservative
>> that I am, I decided that the initial investment was so little that
>> there was just no way that I wouldn't get enough orders to at
>> least get my money back.  Boy, was I surprised when I found
>> my medium-size post office box crammed with orders!  For a
>> while, it got so overloaded that I had to start picking up my
>> mail at the window.  I'll make more money this year than any
>> 10 years of my life before. The nice thing about this plan is
>> that it doesn't matter where in the U.S. people live. There
>> simply isn't a better investment with a faster return.
>>
>> Mary Rockland, Lansing, MI
>>
>> I had received this program before. I deleted it, but later I
>> wondered if I shouldn't have given it a try. Of course, I had
>> no idea who to contact to get another copy, so I had to wait
>> until I was e-mailed another program...11 months passed then
>> it came...I didn't delete this one!...I made more than $41,000
>> on the first try!!
>>
>> D. Wilburn, Muncie, IN
>>
>> This is my third time to participate in this plan. We have quit
>> our jobs, and will soon buy a home on the beach and live off
>> the interest on our money.  The only way on earth that this
>> plan will work for you is if you do it. For your sake, and for
>> your family's sake don't pass up this golden opportunity.
>> Good luck and happy spending!
>>
>> Charles Fairchild, Spokane, WA
>>
>>This program really works!! After just a few short weeks with
>>the program I was able to quit my job, and start my very own
>>wholesale business!! After sending out just one batch of e-mails
>>I was able to purchase enough merchandise to stock my entire 
>>warehouse. Although my company is doing great....I still send
>>out a batch of e-mails every month.....because this is still the 
>>easiest  way I know to make money!! Here's proof of my 
>>success....
>>VISIT ME ON THE WEB @ http://www.sandlinsales.com
>>
>>R. Sandlin, Lawrenceburg, IN
>>
>> ORDER YOUR REPORTS TODAY AND
>> GET STARTED ON YOUR ROAD TO
>> FINANCIAL FREEDOM!
>>
>> NOW IS THE TIME !
>>
>> DECISIVE ACTION YIELDS
>> POWERFUL RESULTS !
>> **************************************************************
>>> This message is sent in compliance of the new email bill HR 1910. Under
Bill
>HR 1910 passed by the 106th U.S. Congress on May 24, 1999, this message
cannot
>be Considered Spam as long as we include the way to be removed. Per Section
HR
>1910. Please type "Remove" in the subject line and reply to this email. All
removal
>requests are handled personally and immediately once received.




From list@netscape.com  Fri Jun 16 08:47:48 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10757
	for <ldapext-archive@odin.ietf.org>; Fri, 16 Jun 2000 08:47:47 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5GCcZW27548;
	Fri, 16 Jun 2000 05:38:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5GCkAU07069;
	Fri, 16 Jun 2000 05:46:10 -0700 (PDT)
Resent-Date: Fri, 16 Jun 2000 05:46:10 -0700 (PDT)
Message-Id: <200006161246.e5GCk6x09864@ywing.netscape.com>
From: "Charlie Shublum" <rany61t@ragingbull.com>
Subject: Last Quote #1B54
To: list38d@ywing.netscape.com
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Fri, 16 Jun 2000 06:41:48 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5GCk8107037
Resent-Message-ID: <"dYxUdD.A.DuB.QGiS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

FREE E-COMMERCE WHEN YOU HOST WITH US!!

Tired of expensive e-commerce software, set up fees and leasing
contracts?
Here is the deal: Sign up for our E-Commerce Package and get a free
merchant account + a $200 cash coupon.

WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS
LESS
DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS.
DON'T
MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE!

While others charge you hundreds of dollars to get a merchant account
or
put you on a 48 months non-cancelable lease agreement we charge you
NOTHING for your merchant account when you sign up for one of our e
-commerce hosting plans. If you wish to stay with your current
hosting company or have already a merchant account our offer is even
better. We have 7 different E-Commerce plans to suit your individual
needs. We have a solution for U.S. beased merchants and international
merchants. Wherever you are on this planet, we get your online store
up and running within a few days.

Check it out first and make an informed decision. You have never seen
a
package deal like this before:

* Your own merchant account with one of the lowest rates in the
industry
* Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS
,
DINERSCLUB/CARTE BLANCHE, JCB
* Direct deposit within 48 hrs into your checking account
* Shopping Cart store front software with an easy to use web based
interface
* Real-Time Credit Card Processing software
* Virtual terminal for phone/fax/mail orders
* Automated E-mail receipts to your clients
* Recurring billing feature with batch uploads
* Automatic batch closing
* Address verification system (AVS)
* Back office to 24/7 access account history
* 75 MB (megabytes) of disk space
* 30 GB (gigabyte) of data transfer per month
* 25 POP3 E-mail accounts
* Unlimited alias E-mail addresses
* Live web site statistics
* Unlimited FTP uploads
* Anonymous FTP
* CGI directory for your own scripts
* Site control panel
* Installation included
* Tech support included

All this and more when you sign up for our E-Commerce Hosting plan
for ONLY $69.95 per month and a one time set up fee of $199.00.  That
's right. NO ADDITIONAL SET UP FEES or application fees for your
merchant account,
real-time software or shopping cart storefront. A one-stop E-Commerce
solution. And the best is:

NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME.

In addition you get a FREE listing in our mall and FREE advertising
to
promote your store. We drive traffic to your site and help you to
become a
successful .com business.

REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS
SPECIAL
OFFER IS ONLY GOOD FOR 7 DAYS!

Please reply to:

mailto:mmdk@populus.net?subject=INFO-PLEASE to receive our FREE e
-mail
information package without obligations.

*********************************************************
Remove at mailto:twentytwo4424@netscape.net?subject=remove
*********************************************************





From list@netscape.com  Fri Jun 16 09:59:06 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11932
	for <ldapext-archive@odin.ietf.org>; Fri, 16 Jun 2000 09:59:05 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5GDqhH14532;
	Fri, 16 Jun 2000 06:52:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5GDuso28422;
	Fri, 16 Jun 2000 06:56:54 -0700 (PDT)
Resent-Date: Fri, 16 Jun 2000 06:56:54 -0700 (PDT)
Message-ID: <00a801bfd80e$0f7aa1a0$3029b0cb@w3l8s9>
From: "Mara Commercial" <maracom@pempe.net>
To: <mswfang@netscape.net>
Subject: A Program That is Simple, Profitable and Achievable!
Date: Fri, 16 Jun 2000 20:27:20 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A5_01BFD7D3.631BC9A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Resent-Message-ID: <"XMImo.A.i7G.kIjS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multi-part message in MIME format.

------=_NextPart_000_00A5_01BFD7D3.631BC9A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


 Turn Your Computer Into A Virtual Cash Machine.=20
You will only need a few minutes to do this.
=20
The programs below are all Simple, Profitable and most importantly, =
Profitable. We dare you to compare these programs to other programs in =
the net. And we are very confident that you will find them GREAT!
    a.. One time investment of $5. But the return is $10,000 - $40,000 =
plus in a few months. Mail to: mygift2u@pempe.net
    a.. DARE! Earn $708/month with only 39 members and $3,210/month with =
only 155 members. If you have 10 1st Level, 100 2nd Level and 1000 3rd =
Level, this will give you a $25, 320/month plus $25 fast-start check =
paid weekly. The investment is only $39 but the pay-out is $30. Wow, =
this a 76.92% commission pay-out. So, why build big a organization while =
you can be rich with small organization? Mail to: rags2riches@pempe.net
    a.. A Special Club That Pays! We all pay for our groceries, fuel, =
phone & cellphone bills, mortgages, car amortization, health insurance, =
right? Why pay while there's a club that will pay all of these for us? =
Plus a FREE Dell Computer every 12 months. All of these for only $10 =
investment. Plus the company support to ensure our growth. Mail to: =
lifestyle@pempe.net
    a.. Make Your Computer Your Own ATM Machines! You only need a few =
minutes to do this. You can easily earn $300 - $400 a day at home. Start =
Now! Mail to; starbiz@pempe.net=20
    a.. Boost Your Internet Speed By 200% And Your Computer by 50%. =
Avail of the 30 Days Risk Free Trial. Believe me, you will like it.  =
Mail to: fedson@pempe.net     =20

For a full details, simply reply to the specified address with "Send =
More Info" as the text.

Thank you very much and Good Luck!


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * =
* * * * * * * * * * * * We honor removal request. Simply reply to this =
with Remove as text.


------=_NextPart_000_00A5_01BFD7D3.631BC9A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV align=3Dcenter><FONT color=3D#000000 face=3D"" =
size=3D3><STRONG>&nbsp;Turn Your=20
Computer Into A Virtual Cash Machine. </FONT></STRONG></DIV>
<DIV align=3Dcenter><FONT color=3D#000000 face=3D"" =
size=3D3><STRONG></FONT>You will=20
only need a few minutes to do this.</STRONG></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D3>The programs below are all Simple, Profitable and =
most=20
importantly, Profitable. We dare you to compare these programs to other =
programs=20
in the net. And we are very confident that you will find them=20
GREAT!</FONT></DIV>
<UL>
    <LI><STRONG>One time investment of $5.</STRONG> But the return is =
$10,000 -=20
    $40,000 plus in a few months. Mail to: <A=20
    href=3D"mailto:mygift2u@pempe.net">mygift2u@pempe.net</A></LI></UL>
<UL>
    <LI><STRONG>DARE!</STRONG> Earn $708/month with only 39 members and=20
    $3,210/month with only 155 members. If you have 10 1st Level, 100 =
2nd Level=20
    and 1000 3rd Level, this will give you a $25, 320/month plus $25 =
fast-start=20
    check paid weekly. The investment is only $39 but the pay-out is =
$30. Wow,=20
    this a <U><STRONG>76.92% </STRONG></U>commission pay-out. So, why =
build big=20
    a organization while you can be rich with small organization? Mail =
to: <A=20
    =
href=3D"mailto:rags2riches@pempe.net">rags2riches@pempe.net</A></LI></UL>=

<UL>
    <LI><STRONG>A Special Club That Pays!</STRONG> We all pay for our =
groceries,=20
    fuel, phone &amp; cellphone bills, mortgages, car amortization, =
health=20
    insurance, right? Why pay while there's a club that will pay all of =
these=20
    for us? Plus a <STRONG>FREE</STRONG> Dell Computer every 12 months. =
All of=20
    these for only $10 investment. Plus the company support to ensure =
our=20
    growth. Mail to: <A=20
    =
href=3D"mailto:lifestyle@pempe.net">lifestyle@pempe.net</A></LI></UL>
<UL>
    <LI><STRONG>Make Your Computer Your Own ATM Machines!</STRONG> You =
only need=20
    a few minutes to do this. You can easily earn $300 - $400 a day at =
home.=20
    Start Now! Mail to; <A =
href=3D"mailto:starbiz@pempe.net">starbiz@pempe.net</A>=20
    </LI></UL>
<UL>
    <LI><FONT color=3D#000000><STRONG><FONT size=3D3>Boost Your Internet =
Speed By=20
    200% And Your Computer by 50%. Avail of the 30 Days Risk Free Trial. =
Believe=20
    me, you will like it.&nbsp;</FONT></FONT><FONT size=3D3> =
</STRONG>Mail to: <A=20
    href=3D"mailto:fedson@pempe.net">fedson@pempe.net</A><STRONG><FONT=20
    color=3D#000000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></STRONG></FONT></LI></UL>
<DIV>&nbsp;</DIV>
<DIV>For a full details, simply reply to the specified address with =
&quot;Send=20
More Info&quot; as the text.<BR><BR>Thank you very much and Good=20
Luck!<BR><BR></DIV>
<DIV><FONT face=3D"" size=3D3><STRONG>* * * * * * * * * * * * * * * * * =
* * * * * *=20
* * * * * * * * * * * * * * * * * * * * * * * * * </STRONG>We honor =
removal=20
request. Simply reply to this with Remove as=20
text.</FONT><BR></DIV></BODY></HTML>

------=_NextPart_000_00A5_01BFD7D3.631BC9A0--



From list@netscape.com  Fri Jun 16 12:26:11 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16027
	for <ldapext-archive@odin.ietf.org>; Fri, 16 Jun 2000 12:26:10 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5GGJpH02927;
	Fri, 16 Jun 2000 09:19:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5GGO2I21848;
	Fri, 16 Jun 2000 09:24:02 -0700 (PDT)
Resent-Date: Fri, 16 Jun 2000 09:24:02 -0700 (PDT)
Message-Id: <3.0.5.32.20000616092345.0094eb00@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 16 Jun 2000 09:23:45 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: compare result codes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"qnmaPB.A.STF.dSlS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I've been reviewing the BLITS compare tests and had a couple
of questions regarding the proper result code to return
upon certain conditions:

1) unknown attribute type
2) compare known attribute type without defined equality matching rule
3) not present attribute type with asserted value of invalid syntax
4) not present attribute type with asserted value of valid syntax
5) present attribute type with asserted value of invalid syntax
6) present attribute type with asserted value of valid syntax
   and attribute without asserted value
7) present attribute with asserted value of valid syntax
   and attribute with value


What result code is appropriate for each case?

Here are my initial thoughts:

1) undefinedAttributeType
2) inappropriateMatching
3) noSuchAttribute (syntax not relevant in this case)
4) noSuchAttribute
5) invalidAttributeSyntax
6) compareFalse
7) compareTrue

This usage is fairly consistent with X.511, 12.4.
  "An attributeError reports an attribute-related problem."

   a)	noSuchAttributeOrValue - The named entry lacks one of the
	attributes or attribute values specified as an argument
	of the operation.
   b)	invalidAttributeSyntax - A purported attribute value, specified
	as an argument of the operation, does not conform to the attribute
	syntax of the attribute type.
   c)	undefinedAttributeType - An undefined attribute type was provided
	as an argument to the operation. This error may occur only in
	relation to addEntry or modifyEntry operations.
   d)	inappropriateMatching - An attempt was made, e.g. in a filter,
	to use a matching rule not defined for the attribute type concerned. 

excepting that c) specifically says the error may only occur in
relation to addEntry or modifyEntry operations.  Now, one could
return noSuchAttribute(OrValue), but this seems inappropriate
as it implies able to determine the entry doesn't contain the
attribute type... which implies the attribute type is defined...
which it isn't.

Maybe a clarification to X.511 is in order to either:
	A) change c) above to allow return by compare
	B) clarifiy which result codes should be returned
	in the cases listed above.

Maybe this could be done for LDAP in the rescodes I-D.

Kurt





From list@netscape.com  Sat Jun 17 01:25:08 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06877
	for <ldapext-archive@odin.ietf.org>; Sat, 17 Jun 2000 01:25:08 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5H5JTX01261;
	Fri, 16 Jun 2000 22:19:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5H5Nfo04550;
	Fri, 16 Jun 2000 22:23:41 -0700 (PDT)
Resent-Date: Fri, 16 Jun 2000 22:23:41 -0700 (PDT)
Date: Fri, 16 Jun 2000 22:23:25 -0700 (PDT)
Message-Id: <200006170523.e5H5NOx02412@ywing.netscape.com>
From: wingrabeach@mail.com, mendota@mail.com
To: Internet.Business.Opportunity.Seekers.RNUR@netscape.com
Subject:  Join FREE !  Watch Your Business Grow BEFORE you Invest a Dime !
X-Reply-To:  mendota@mail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"NvAKtC.A.fGB.btwS5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

CHECK IT OUT! IT'S FREE!

An Internet Business Opportunity that Utilizes
the Power of Wholesale Discounted Online Shopping

750-1000 Members Each Month!

ALL new members that come into the club
COMPANY WIDE will go under YOU.

A true VERTICAL downline.
GUARANTEED minimum commissions every month!!

Watch your Business grow BEFORE you spend a Dime
FREE Membership gives you deep discounts at over
70 Brand Name Online stores and entry to our monthly
$100 shopping spree!

To join our FREE postlaunch program
Please Go To:
http://www.50megs.com/users/nkgroup

This is a one time mailing. You will not be contacted again.




From list@netscape.com  Sat Jun 17 18:33:09 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21777
	for <ldapext-archive@odin.ietf.org>; Sat, 17 Jun 2000 18:33:09 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5HMRTX08434;
	Sat, 17 Jun 2000 15:27:29 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5HMVe225365;
	Sat, 17 Jun 2000 15:31:40 -0700 (PDT)
Resent-Date: Sat, 17 Jun 2000 15:31:40 -0700 (PDT)
Message-Id: <s94ba4b1.066@prv-mail25.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 16 Jun 2000 16:09:29 -0600
From: "Dave Steck" <DSTECK@novell.com>
To: <ietf-ldapext@netscape.com>
Subject: UTF-8 / Unicode / Local conversions
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5HMVa125298
Resent-Message-ID: <"JcDEcC.A.iLG.Jx_S5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Applications need a way to display data obtained through the LDAP C API's.

To provide truly cross-directory and *cross-platform* API's, it seems there should be 
a standard set of C APIs to do UTF-8 <--> Unicode conversions.

There should also be a standard set of API's to convert between either UTF-8 or Unicode and local strings?
Does anyone know of such a standard or work underway?



From list@netscape.com  Sat Jun 17 18:33:41 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21788
	for <ldapext-archive@odin.ietf.org>; Sat, 17 Jun 2000 18:33:40 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5HMR6X08174;
	Sat, 17 Jun 2000 15:27:06 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5HMVIQ24924;
	Sat, 17 Jun 2000 15:31:18 -0700 (PDT)
Resent-Date: Sat, 17 Jun 2000 15:31:18 -0700 (PDT)
Message-Id: <s94ba4aa.064@prv-mail25.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 16 Jun 2000 15:54:28 -0600
From: "Dave Steck" <DSTECK@novell.com>
To: <ietf-ldapext@netscape.com>
Subject: ldap_err2string format
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5HMVG124893
Resent-Message-ID: <"mOSqiB.A.DFG.0w_S5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

According to <draft-ietf-ldapext-ldap-c-api-04.txt>, the output of ldap_err2string(err) is:
  "an informative zero-terminated character string message describing the error."

It doesn't specify whether the string is encoded in UTF-8 or may be local, such as DBCS.

The draft says:
  All DN and string attribute values passed into or produced by this C LDAP API are represented using the character set of the underlying LDAP protocol version in use.  When this API is used with LDAPv3, DN and string values are represented as UTF-8[6] characters.

But this is neither a DN or string attribute value.  I've heard arguments both ways.  
So what do you think?  Does the spec nail this down to UTF-8 (in LDAPv3)?

If so, the common coding practice of:
   printf(".... %s\n", ldap_err2string(err));
is ill advised since it's not internationalized.







From list@netscape.com  Sat Jun 17 19:40:33 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22062
	for <ldapext-archive@odin.ietf.org>; Sat, 17 Jun 2000 19:40:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5HNYpX11266;
	Sat, 17 Jun 2000 16:34:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5HNd3c06467;
	Sat, 17 Jun 2000 16:39:03 -0700 (PDT)
Resent-Date: Sat, 17 Jun 2000 16:39:03 -0700 (PDT)
From: <a1@bad-address.com>
Subject: DEC /SUN SURPLUS upto 80% off Digital equipment corp, sun mirosystems
Date: Sat, 11 Jan 1997 04:49:04
Message-Id: <375.566363.506835@server.com>
Resent-Message-ID: <"nXrk0.A.ukB.VwAT5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

       
For more information on these poduct call 514-744-9665
Email sent to the above account will not be answered 


SUN 20 trinitron $199 19 inch $149 16 inch $69 
exabyte 8505xl in sun ultrawide enclosure $290 8mm 14gb 
dec dec dec dec dec dec dec dec dec dec dec dec dec dec dec dec 

           Digital Equipment - All prices in U.S. $

New arrivals: vax 4105a
              rz27 disk
              128 meg
              cd rom

	      microvax 3100 90
Networking:   decnis 600
	      dex2r-z routeabout access ew
	      dex2r-m routeabout access ew
	      dez8r-p routeabout central ew
	      dsrvh-n decserver 90m
	      h7082-88
              decserver 700 $475   8 port dsrvw-aa
			    $690  16 port dsrvw-ca
              decserver 550 dsrvs-c2b03 with multiple cxy08 cards
              pmad-a   p/n 54-19874-01 
              pmaz    p/n 54-19876-01 
              rf-delni -aa (fibre optic output)   
              decrepeater 90T   detmr-m   $150 ea    
              decrepeater 90T+  detmr-n   $150 ea    
              decserver 90l+   dsrvg-ma   $225
              decbridge 90+    dewgb-m   
              dehub 90 ax               1
              dehua-nb
              DESPR-AA,PC100-B,DECROUTER 250,LANBRIDGE 
150,LANBRIDGE 100
              DEC200 NICS, pm37b-by, delni-ba, ab74100b7c, 
dsrva-aa,dempr-aa
              h7317,pm20b-ag, dsrvb-aa,lanbridge debet-ac
              70-19062-01, 70-31353-01, devp03, dvrvb-b, demsa-aa
              decserver 300
              vxt2000
              ba350 scsi enclosure
              dsrvb-a
              lxy12
              decserver 100,decserver 200dl, decserver 200md,
              decserver 300 dsrvf-ba
              dsrvf-b,rf-vx20a-m9, di-31cp1-a cpu ka41,lanbridge 
150
              P/N DEC 7876-AA  dehub ax power supply   
              DSRVB-B,DSRVB-A, DEC REPEATER 350 ,P/N DERFVS240A 
20  
              DESPR-AA THINWIRE REPEATER
              DECMUX 300 P/N DM308-a,MUX SERVER 310 P/N DSRZC-B  
                       
              MUXSERVER 300 P/N DSR2C-A            
     

TERMINALS: VT220,VT320,VT330,vt330+,vt340,vt340+,vt420 $99, 
vt510, vt520     
     VRM17-AA VRT19-DA VRT19-HA VR241-A VR299 VR290-DA have 200 
spare lk450

PRINTERS: LA50 
$50,LA70,la75$70,la75s-a2$110,la100$70,la210$99,la324 $300,
          la424 $550,lno3$50,lno3+$75,DECWRITER III $170, RFLAIDR 
$200,
          lp27 $300, lp37,LQP45,lgo1,lg02,lg31

DRIVES      : 
rd53,rd54,tz30,tk50,tk70,tu81,tu81+,tz85,tz86,ra60,ra90
              ese20-ba   - 120mb ram memory drives  4  

              ra650-xa   - 5 1.2 gig sdi drives 1 250 meg ra70
              ra600  2 1.2 gig ra70
              h7142 power supplies 6  
              micro technolory inc. stingray  has 4 rackmount
                 stingray hard drive controllers 1 2.1 gig 
seagate barracuda
                 10 hard drive enclosures
              hsc50  2    sdi disk drive controllers

SYSTEMS:
        vaxstation 4000 60
                vx46k-ad
                cpu ka46
                rz 25e
                video card 5020364-01 d3  5420366
                ram 2 pieces of 5419103  5019079-01

        vaxstation 4000 60
                vx46k-ad
                cpu ka46
                tzk10-aa tape drive 
                2 hard drives  rz 25e
                video card 5020364-01 d3  5420365
                ram 2 pieces of 5419145  5019144-01


        microvax 3100 80
                tz30
                board 54-20652-01
                rz26e hard drive

        microvax 3100 40
                tz30
                54-20654-01 h02
                rz 26e hard drive 
                on onboard ram no modules

        microvax 3100 30
                tz30
                board 54-20654-01
                on onboard ram no modules

        microvax 3100
                dj31esa-a-a01
                tz30
                54-18858-01
                50-18905-01
                54-18905-01
                501982901
                rz24-e

        microvax 4000 600
                tk70
                128 meg ram  ( 2 units l4002aa  ms690-ca)
                kfqsa
                kzqsa
                no hard drive
                
        microvax 4000
                6600r-b2
                m9047
                h7868-a
                desqa-sk
                ms650-bf
                tk70 sf
                tk70
                

        dec 3000 400
                pe401-cb
                rz26
                cpu kn15-ba
                cd rom
                vid 50-21142-01
                ram 8 pieces of 5421139cl 

              vaxstation 8 meg ram modules mso2  p/n 54-16812-01 
 120  
              vax 4000-100a
              vt1300 50
              decsystem 5500
                 2200h-b9 series ba400
                 ms220-ba
                 m7639
                 kn220 m7637
                 kn220 m7638
                 2 rf72, tlz04 (dat) ,
              vax 4000 300,vax 4000 200,microvax 3800,microvax 
3400
              microvax 3100
     VAXSTATION 4000/VLC 24 MEG 20 INCH TRINITRON RZ23L HARD 
DRIVE $    
     VAXSTATION 3100 M38 2 SCSI HARD DRIVES 20 INCH 
TRINITRON......$    
     VAXSTATION 2000
     decstation 2100 pm10a-ba
     DS5000-200 ,ds500--125,ds5000-240,MICROVAX II     

MISC
----
     TK50 MEDIA used $4                          
     DEC 16 BIT ETHERNET $5                     
     DEC 8 BIT PDA508 $3                         
     DEC DESTA                 

  Computer SUPERSTORE at 50 Stinson, Ville St. Laurent  A1 VENTE 
ORDINATEUR
        W E   B E A T   A L L   M O N T R E A L   P R I C E S !
20,000 SQ FT of stock item up to 80% off     514-744-9665 fax 
514-488-8829
         COMMERCIAL COMPUTER EQUIMENT SPECIALISTS  --- DEC WYSE 
IBM HP
 terminals  - dat - lasers +laser parts - line printers- 
networking

We will beat any ad price on  ibm equipment   prices u.s $

nics: 16/4 turbo
      lanstream 
      16/4 short card  
      olicom 3137
      smc 
      etc

SYSTEMS:
        powerstation 220  type 7011     
        2.5 gig seagate barracuda
        32 meg

        powerstation 220  type 7011       50 units in stock
        500 meg
        32 meg

        powerstation 340 type 7012
        2 scsi drives p/n 55f9915
        scsi bus extension fru 00g2721
        token ring 74f8653
        16 pieces of 4 meg 72 pin (on 2 cards 8 pieces each)
        color card fru 71f1223
               processor card fru 00g3149 cpu 37

        powerstation 370 type 7012
        2 scsi drives p/n 75g3628
        scsi bus extension fru 00g2721
        token ring 74f8653
        64 meg  
        processor card fru 51g9441

        powerstation 410 
        2 gig scsi drive
        scsi bus extension fru 00g2721
        token ring 74f8653
        64 meg 
        color video fru 88g2749 609
        token ring fru 7280422

        powerstation 320

        XSTATION 150 15 UNITS
        XSTATION 120 100 UNITS
3com 3c319 rj45 and db9 isa 16  130 units
ibm auto 16/4 fru 9873456 rj45       approximately 200 units   
isa 16
olicom 00055797-12671-73c-opin  fcc id an055h6800   rj45 and db9 
 isa 16
dca 014253 rev a 500 units rj45 and db9 mca and isa  
smc 8115t c d2 4996  400 units rj45 and db9 isa 16
madge smart at ringnode 152-034-04   152-028-14  100 units 
intel rj45 and db9 isa 16 200 units
card swiper 4717 3
ibm 16/4 short card 
ibm 5250 8 bit 
hp jetdirect j2555-60003  
hp jetdirect j2373-60001  db9  
hp jetdirect ex j2383  db9 rj45 external unit with power supply 
proteon 1392+  16 bit isa tokenring  

ibm powerstation 320h 32 meg 16 ports for terminals
ibm sierra xterminal model 120 8 megs ram p/n 950-000024-000
terminal ibm 3151, 3192,3196,3197,3471,3472
terminal ibm 3472 color (same tube /flyback) as 3477
terminal ibm 3477, 5085-1, 5272,3178c,
terminal ibm p/n 83x7944  color
controller ibm 
3174-1r,3174-1l,3174-11r,3174-51r,3174-61r,3174-91r
mau ibm 3299 2 8 port coax
ibm 5242,4224  $200,4230,4234,4324,3812 2,3287, 5210 go2
ibm 8228 10 port token ring p/n 6091014  50  
ibm irma2
ibm auto 16/4, ibm lanstreamer pci tokenring
lexmark 4109, 4029, 4039
proteon 
7202,33g4389,6091014,4459,4869-009,4869,3174-g2454,3274-41d
5362,3268 2,4869-002,4869,3299-2,7010,3044-d02,9404 as400
23-p2899,3820,2380,2381,33g4389
madge token ring cards
mca network cards  16/4 
mca adaptek scsi cards  also future domain $20
assorted other microchannel cards 
token ring cables 
proteon cnx 500 and cnx 600 routers dual ethernet token ring 
model


                  W E----- A C C E P T----------A M E X

 eg-HP laser $39      NEC 4 meg postscript laser  $59   20 INCH 
SVGA $139
   -OKI MICROLINE $49 Fujitsu dl1100 $29
   -WYSE ibm DEC qume HP terminals from $75 (over 5000 in stock)
   -color tektronix $290 ($3000 REG)  QMS color $290 8mm dat $59 
   -compaq pagemarq 20,20 ppm ,postscript 800x400 dpi, 3 trays 
11x17 $350
   -fujitsu dl2300 $39 dl3400 $69 dl3600 $79 dl5600 $149

        WE ARE QUEBEC'S LARGEST COMPUTER SURPLUS COMPANY
WE PROCESS 350 PALLETTES (SKIDS) OF COMPUTER EQUIPMENT PER MONTH

COMMERCIAL EQUIPMENT------------UP TO 80% off ---OVER 5000 
TERMINALS in STOCK
epson lq570 $69 reg $249  epson lq1170 $79 reg. $299  fujitsu 
dl3400 $69
epson dfx 5000 $349 genicom 3820 $300 APC UPS $40 STAR reciept 
printer $59
DEC HP GENICOM IBM FUJITSU EXABYTE PRINTRONICS LEXMARK WYSE 
COMTERM TELEX OKI

REPAIRS -----> laser, monitor, printer and system repairs.  HP 
Fusers $39
WE PAY CASH FOR COMPUTER EQUIPMENT DEAD OR ALIVE.  We buy 
computer scrap. 

LASERS ---> OVER 1000 LASERS IN STOCK - LOTS OF SPARE PARTS - 
TRAYS
            HP datasouth DEC oki LEXMARK ibm GENICOM qms APPLE

List is partial if you don't see it ask for it we can get it

NEW ARRIVALS:

40 st5150wd 7200 rpm 4.3 gig wide differential seagate barracuda 
$95
muylex cacheing raid level 5 pci card takes 72 pin ram 3 channel 
$225
2 meg matrox pci $12
500 3com 3c509
cisco 2502 20 units 
cisco ws-x3001 $500 u.s. (new in box)
cisco igs 
cisco lgs 
ascend mx-2t1    p/n 0700-0180-001 rev e   (options isdn nx 
rs-366)
    	max-2csu-tm  p/n 0700-0084-001 rev a
	max-6pmhp    p/n 0700-0085-001 rev a
	mx-sl-6pm-ptm  p/n 0800-0195-002 rev a
	max-sl-2pmhp    p/n 0700-0082-001 rev a
intel es500mfx $380 new in box  2 port 100base-fx module f/500 
series switch
here is the baynetworks/nortel products.
 

Model 5110 Supervisory Module  
Model 5001 950W AC Power Supply 
Model 5399
Part# AD1004004 Model 5308PS 24-Port 10BASE-T 
Part# CX1004019 48 Bay DSP Modem Upgrade Kit for North America 
(T1).
 
 We have 14 skids of current model cabletron networking
 equipment.  List price of about $10,000,000 75% off of list 
price.
 All is the MMAC line there is ethernet , tokenring fibreoptic ,
 rj45 and isdn. some part numbers are:
 
 irm, irm3 (over 500 units ),fdmmim, esxmim, emme, tprmim-22
 emm-e6, fdcmim-08, efdmim,
 sehi 34 24 port ten base t with lanview rs232 console input (125 
units)
 tpmim-22 (over 500 units), tpmim 34 (over 500 units)
 fot-f2 fibre optic tranceiver, tp-4 rj45 transceiver  (over 500 
units)
 tpt fj45 tranceiver     (over 500 units)
 
have dlt 15/30 $400 
        ms-283 bar code gun (200 units) fits termial or pc.
        cisco igs, ags lgs , 3640 , 2502, 2503
        3 inch ccd scanner + decoder 270 units  (time keeping 
system inc)_
        annex cm1009e47 
        at&t comsphere 3000
        bay networks cm1001070  mlb 360-084-901 option 1 
360-072-936 rev a5
                   36 port remote annex 4000
        bay networks cv1001018  advanced remote node 100 base fx 
 arn
        bay networks cv0011013  token ring expansion
        bay networks 450-1sr mda media dependent adapter module 
100 base sx
        bay networks ae1001005 p/n 111375
            bay networks an flash card corporate suite p/n 112639 
rev a
        bay networks ae1001010 p/n 113359
        bay networks db1501e16   (MARLIN) ISDN ROUTER two channel 
        bay networks model 800
        memotec da3214
        memotec netaccess 900
        motorola mp router 6520 voice, data , fax
        synoptics 3395a, 3308ba, 3313sa
        teleglobe dm1000, dm2200, MP 9000
        uds ddsmr64, ddsmrs,3266
        xylogics clam na/d
        xylogics 4002-pn1  (REMOTE ANNEX 4000)
	tec b-602-gs20-us label printer



hp hp hp hp hp hp hp hp hp hp hp hp hp hp hp hp hp hp hp hp 
hphewlett packard

                                   HP items - all prices U.S.

laser trays over 2000 in stock --- fusers hp ii, 
iiisi,4si,4,4mv-- all laser parts


hp differential drive towers 4 x 4.3 gig barracuda 
			     4 x 2.2 gig fujitsu 
			     4 x 1.2 gig $249

HP D4943A NETRAID PCI RAID LEVEL 5 ADAPTER NEW IN THE BOX

hp 9000 e35
hp9000 f20
hp 9000 800/140 857s
    (upgrade a2464a)
    a1703-60022
    28696-60001
    28640-60001
    gpib
    802.3
    scsi (se) parallel
    c1504b 4mm dat drive
    c2474s 2 units
    1150-1865


hp pentium ii 350 server lc3 (cti) d7018a

advancestack 27288a router 430

hp28673a bridge
hp4995a lanprobe II
hp2564b printer 
hp 2563c
hp 2563a
jetdirect j2550 j2552 j2371 j2555 jetdirect ex etc 
router 430, 440
all jetdirect cards $100 except j2555 $60
27286a router tr (cisco 4000 equivalent)
27289a router fr
28682A  FIBRE OPTIC HUB
28674A BRIDGE
28688B HUB
C2261A STORAGE ENC
27270A ROUTER
    CARDS : ENET 27271
   SYNC 27270
   SYSI/O

hp 9000 series 700 128 meg  a1421x a2278b
eisa card #1 (looks like a digiboard ) bit 3 computer corporation 
model 487-1-201
eisa card #2 fddi fibre optic transciever crescendo 
communications model
                                                             
es-9211-xf
eisa card #3 daughter board of above card
hp ux 4 cd set release 9.0 part #b2826-13681
$call     have 2   in stock

20 inch trinitron for the above (manufactured sept 1994) $400

hp 28682a fibreoptic hub plus
for hp dat drives and auotoloaders check our dat section

iiisi jetdirect for banyan rj45 and coax
rj45 jetdirect for hp III
coax jetdirect for hp III
jetdircet combo for iiisi/ivsi 

!!!!!!!  HP RUGGEDWRITER  $190
hp apollo 400 16 meg 425 hard drive $400
hp 20inch and 17 inch trinitrons   
500 NEW hp II and III trays
60 NEW boxed HP IV multitrays
200 NEW HP 3si/4si trays
hp under sheet feeder for hp IIP/IIIp
Terminals HP 700/92,700/22, 700/94,700/96es  
HP 98578
DOT MATRIX HP 2631G
DOT MATRIX HP2563A  
HP 7958
INKJET HP PAINTJET Xl
PLOTTER HP 7550A plotter , 7475a, draftmaster, draftmaster ii
PLOTTER PENS FOR HP (VACUUM SEALED SETS ) $5
SYSTEM HP 7936
SYSTEM HP MICRO X3 3000

TAPE DRIVE HP 9144
TERMINAL HP 35731A 
TERMINAL HPD1181E
HP LASERJET I   $40
HP LASERJET II  $80
HP LASERJET IID $130
HP LASERJET IIID $195
HP LASERJET IIISI $370
HP LASERJET 2000 40 PPM 11x17
98546a
draftmaster sx plotter
draftmaster I plotter 7595
draftmaster II plotter 7576a
9134
2345a dtc
2463a
laserjet 2000
hp 4955a logic analyser

                   DAT and tape drives  Prices in U.S. $
                  I WILL BEAT ALL AD PRICES ON DAT DRIVES !!!!

The following list is incomplete for items not listed please call 
514-744-9665

scsi ribbon cable $1
scsi centronics to db25 $5
scsi mini to mini $10
scsi centronics to centronics $5

 SUPER SPECIAL EXABYTE EXB8200 8MM DAT $59 $u.s.
 adaptek 1522 scsi controller $10
 adaptek 1542 scsi controller $15
 future domain scsi controller $10
exabyte exb210 autochanger 600 gig !!!!!!!  $1900 u.s.
dlt 20 gig               $350
dlt 30 gig $450
dlt loader 280 gig $4000
hp 35470 4 gig 4mm dat $99
150 meg archive, wangtek (5150) $25         case $5 extra
archive 150e, archive 2525s ,archive 4320nt,archive 
4324np,archive 4350xt
conner ctd8000e-s
hp c1553 dd3 4mm autoloader $299 96 gig 
emerald vas026 9000
exabyte ex4200c
exabyte exb8500 8mm $129, exabyte exb8205 8mm $149
exabyte exb8205xle 8mm $169
exabyte exb8505xls 8mm 14 gig $399 
exabyte exb10-chs 8mm 10 tape autochanger , exabyte exb10-chse 
hp 1300s       $99
hp model 35470 $99 2 gig 4 mm
hp model c1504 $299
legacy 500s $50, legacy 525s $50, legacy 2000s $99 2 gig 
legacy 2200d 4mm 2 gig $59, legacy 4000d 4mm 4 gig $99,
legacy 8000d 4mm 8 gig $199
sony sdt 500
seagate ctl 96gs 96 gig 4 tape autochanger
trimm da5
tecmar datavault 4000 
wangdat 3200, wangtek 6130 hs $99
external enclosure $8
qualstar 6250 9 track $480
dec tu81 $400
6250 tapes New $5 Used $1
8mm 5 gig tapes used $3
3480 tapes new $3 used $1 
6525 tapes new $3 used $1
tk50 tapes new $3 used $1

call 514-744-9665          we accept amex call 514-744-9665   
514-744-9665

inkjet
------
kodak diconix inkjet portable - runs on batteries 
oradapter....$19
hp 
thinkjet....................................................$19
hp 
deskjet.....................................................$29
hp paintjetcolor continous feed $39
hp paintjet xl  - takes wide paper...............$79
kodak 300w - takes wide paper-- epson sq2500 takes wide paper

dot matrix
----------
epson lq570  lq 570, fxl070 fx 1070 
epson lq2500 color - computerized 7 layer form 
(reg$1099)......$129
toshiba p341, p351 
...........................................$call
mannesmann tally mt330, mt390 ,mt86, mt691 , t6045 (646 646004)
nec p9 color dot matrix commercial................
printronics mvp, p300, p600, 9012 (1200 lines per minute - WOW)
genicom 1010, 1020 , 3210 3820 2840
genicom line printers 4410xt, genicom 4410, genicom 
4490.......$call
okidata 82,ml182,ml320,ml321,ml380,ml395,ml393+,ml591,ml2410
hp ruggedwriter high speed commercial dot matrix (reg 
$2000)...$199
fujitsu dl2400, 5600 and many genicom, datasouth, mannesmann 
tally, 

tektronix phaser iipx, phaser cp, pahser 220, phaser iii, 4694
qms colorscript 100 model 10    serial parallel scsi
qms colorscript 230 11x17, magicolorcx color toner csl 1000-1
qms ps 2210 black and white 11x17 serial parralel scsi
50 tektronix toners reordr no. 016-0898-00
qmd colorscript 100 color toners 4 color  $20 u.s
part number 1730451-013                      $20 u.s.2

we will beat any ad price   mac note the prices in u.s. $
                            ---
        mac laserwriter iint $59
        mac laserwriter      $29
        nec postscript laser , 4 meg ram $49
        hp paintjet 300  wide carriage color postscript inkjet 
$59
        mac mono monitor $   9 color 13 inch $19
        20 inch trinitron monitor for mac $199
        20 mono monitor for mac radius tpd/19 $49
        radius pivot $55
        scsi syquest 88 meg $25, scsi cd $10, scsi enclosure $8,
        scsi ribbon cables $1, external cabels $5, terminator $5
        old mac machines iicx etc $40  mac se $15

3com 3c509, 3c905
3480 TAPES NEW TENEX BRAND $3
QUALSTAR  6250 TAPE DRIVE (SCSI) $350
chipcom 5006c - 5000m-ctl
                5104m-f1b
lan/wan optimizer series 5000 model 5010l p/n acx067g110001l-r
gandalf premier lanline 5220 p/n 7707z1
gandalf mux 2000 8 port  40  
gandalf mux 2000 16 port  10  
gandalf mmux 2000 8 port 10  
gandalf swith mux   5  
proteon cnx 500 router  3  , cnx 600 router  1 unit
newbridge 1032 mainstreet p/n 90-0533-01 channel banks 32 port
newbridge 1082 8 port
gandalf starmaster
lots of gandalf ldm and lds series modems  lds120a, 
lds120e,ldm309a, ldm409a 
ibm 3174-11r, 3174-51r ibm 3174-61 ribm 3174-91r
intel satisfaction modems, satisfaction 200, 400, 400e , 
pcfm6401v, pccb6201a 
bicc datanetworks thin ethernet repeater model # 1121-0 20  
comterm c6274-201
dg 6351n (server?) 
dg 1348 as tape drive with wheels
dg mv4000 dc
digiboard 8 port isa bus  $150
digiboard digichannel c/com-16
digital rflaidr looks like genicom c1
disk mini digital  rl02 
docking station compaq 2684
docking station nec op-560-4701
docking station texas instruments 2581447-0041  c2
docking station toshiba deskstation ii 10 u
dot matrix color nec p9xl
dot matrix oki 321 d2
dot matrixa centronics 359 p351 p353
dot matrixa dg 6494 
dot matrixa dg 6594 c1
dotmatrixa dataproducts tcg 202   10u a2
dotmatrixa datasouth ds220, ds180
dotmatrixa dg 6594  c1
laser postscript, qms ps820 turbo , ps825 turbo 
modem gandalf lds 100, lds120a,lds120e, lds300, lds 309a, lds289
modem gandalf lds 125, mlds, ld140,pacx2000, lds300, lds 389
modem motorola cdm264 modem
lattisnet 2510
lattisnet 102
lattisnet 3000
telex 87
wang 75lis12en
harris l191-s1
dest pcsan200
texas instrument silent 700
allied telesis centrecom 3008
wang 4230ep-t
sytek 20/100
npi 521
tecmar qt60e
memorex 90-0308-001
gcc 50s
general datacom de-1
codex 2600
motorola uds model 201b rm16m m
adic 530/h
allied telesis centre com 470
local data interlynx 3287
fifth generation systems lc-01
penril 2332-01
r212a
ostrocom e299 squeezplexor
gandalf minimau
synoptics lattisnet 102 powersupply
                    408 fault status
ncr 3000
canstar fibre optic hub
otc 2160
cisco igs-r multiprotocal router
qms csc-100
castelle lanpress  95054
honeywell hds2
3com 3c1351
3com linkbuilder ecs10 type 1200-1 with 12 port utp cards and 
management card
motorola 6005
ods 296
telenet tp3/11-3025
delta data 8700t
at&t 6386e wgs
datawatch dwx86
wang vs5600
sun 3/160
datawatch x86
memorex telex 2062
data general mv/2000dc
at&t 1600
ncr 3400
alpha industries um3000
system industries csr176700, csr176300, csr176200
fibrecom 9600r
wang 01s70
chipcom 9314s-st fibre optic hub
sytek 2550
analogic 681
xerox 75b1
comterm dc8101-101
local data ld 3278
xerox 280
graftel x250
telebit t2sa
gandalf 3790z1
hetra 205
mitek 810t
kodak 636017220
baytech 24sII
baytech 24

net 3com multiconnect repeater 10u   p/n 3c588
net allied telisys centercom 810 (switch?) 
net david systems 6102-01 40 port  rck
net gandalf lds120, lds140, lds260, lds309, ldm309, ldm409, 9106, 
2200226
net gandalf mmux 2000 p/n 460hz1
net gandalf mux 2000
net gandalf mux 2000 b3
net gandalf 6808a rev d1
net gandalf 500540101 rev 1b
datability 500540101 rev 1b
net gandalf p/n 427421 mux?
net gandalf pacx 2000
net gandalf sm9600-d
net gandalf sm9600-oyr
net gandalf starmaster, access server xl
net gandalf swithmux 2000
net memotec mpac mp8002  60 port x25 switch multiprotocol
net memotec mpac sp8300
net memotek sp8000 18 port
net micom m2002
net newbridge mainstreet 1082 in box
net paradyne p9600
network memotek sp800  18 port
plotter calcomp plotmaster
plotter hp 7550a
protec bytelink plus  24 port peripheral sharing device 1 meg 
             p/n 24p/1m  50  
puredata 12 port hub + 12 network cards $195  
qms 4 color toner rolls 2 per box $80 per box p/n 1730451-013
ricoh 150 opc  20   $30
sony gdm-1962b $190 20 inch 1024x768
sony gdm-20d10 (sun) $250
tectronics hc02 video copy processor (mitsubishi p71u)
terminal datalynx 3274 100  
terminal datawatch dw240 20u c2
terminal dec vr150-aa 
terminal digital vr201a 5u c2
terminal hpd1181e
terminal memorex telex 1471 , 1472, 2391g 
terminal tecktronics 4205 14'
terminal volker craig 6220   
terminal wyse 30,50,60 75, 85,99gt,160, 185,285,325,350   
terminal linc mc3, mc5
terminal televideo 905, 955, 965
terminal qume ,qvt31, qvt51, qvt-101, qvt101+
toner color tektronic 016-0898-0050 40u
adacom cp150+
shiva lanrover/8t
newbridge p/n 1032-8706-0259 32 port channel bank 2u
timeplex microplex x25 pad 24 port 
motorola s8000 server 60 port 
genicom 1040
newbridge 1032 mainstreet    p/n 90-0533-31a
citoh ci4000, ci15000, c310
m3358a ,ibm 2381, 2391, 5202, 2178, 3192, 5202, 
facit b3100, 4509, 1513
epson lq570, lq1170, fx1170, fax 1050, lq2550, lq2500, sq2500, 
sq2550, etc
panasonic kxp1592, kxp1624,, raven pr248, pr9101
alps 324 printer for dec systems 50  
rf delni with fibre optic interface 50  
fibre optic tranciever (digital brand) 43  
gandalf 500540101
datability 500540101
gandalf 6808a  revd
intel netport 306515-004   token ring db9, 306514-003   ethernet 
rj45 ,306482-004   ethernet aui
xircom pocket ethernet adapter II pe3-10bt
seiko smart label printer plus slp1000p  slp1100
general datacom diz ai
general datacom dei 
human design systems hds2000
memotec isu5600 v.35 dte
synoptics lattisnet model 2500
dlink de220
dlink de200
raven lp510 laser
telebit netblazer st
emerald rap150-9000 tape drive
hp28681a 10:10 bridge lp
hp 28674b remote bridge rb
hp 28688b ethertwist hub plus
hemulex jetdirect netjet ethernet  pwb-er2010276-01
hp jetdirect j2550,j2552,j2555,j2382
pacifac data jetcard/mio 8 serial 1 parallel
banyan jetdirect 6034100 20322e rj45 coax
asp serverjet asp sj400 4 rj45 or 8 rj45
datability vcp200
datability vcp1000
valtek pst250f 250 meg external tape parralel/serial
mita ldc550
3com h46891 ethernet card 16 bit
3com etherlink ii 16tp
3com elii/16 tp
3com el2tp 8 bit
3com etherlink 3c509c parralel tasking 
adaptek mp401 autoswitch
hpiiisi i/o card 28644-60002
pacifac postscript  for laserjet ii,iii pd-016907   
ibm mca microchannel video xga-2 fru 8tf4774
adaptek mca microchannel aha1640 aha-1640 
adaptek isa 16 bit aha1542
adaptek eisa 32 bit aha 1742
adaptek eisa 32 bit aha 1742
puredate arcnet pdc508a
ascend mb4bri option nx56isdn 4 x 128k ----8x64k
memotek da3214
intel 8/16 16 bit ethernet card
intel etherexpress 16tp 16 bit ethernet card
smc 8216t d 16 bit ethernet card
smc 8013wc 16 bit ethernet card
dec de200 ethernet card
dec de205 ethernet card
dec lk201 keyboards
dec lk450 keyboards
pioneer drm-604x 6 cd changer scsi 
telenet to8010-16
seikosha sbp-10a1 
alps p2000
xyplex maxserver 4500
  (3) mxtservj8
  (1) mxtservj16
  (1) mxreptr e1
xyplex maxserver 6020
qume qvt 31,101,101+, 102, 203+
datawatch vm14
wyse 530
volker craig vc8325, vc6220
AT&T 705 MT
mai basic four 4313
memotec mc504
canon cj10
3com 3c509 ethernet network cards $22 U.S.

 
 
 
 
 
 
 
 
 
 
 
 



From list@netscape.com  Sat Jun 17 23:06:35 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24629
	for <ldapext-archive@odin.ietf.org>; Sat, 17 Jun 2000 23:06:34 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5I2vUg01863;
	Sat, 17 Jun 2000 19:57:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5I357k10919;
	Sat, 17 Jun 2000 20:05:07 -0700 (PDT)
Resent-Date: Sat, 17 Jun 2000 20:05:07 -0700 (PDT)
Message-Id: <3.0.5.32.20000617200449.009554f0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 17 Jun 2000 20:04:49 -0700
To: "Dave Steck" <DSTECK@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: ldap_err2string format
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s94ba4aa.064@prv-mail25.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"kuceEB.A.QqC.hxDT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 03:54 PM 6/16/00 -0600, Dave Steck wrote:
>According to <draft-ietf-ldapext-ldap-c-api-04.txt>, the output of ldap_err2string(err) is:
>  "an informative zero-terminated character string message describing the error."
>It doesn't specify whether the string is encoded in UTF-8 or may be local, such as DBCS.

I believe ldap_err2string(err) is intended to behave much
like strerror(err).  I would suggest using language similar
to that found in the Standard C Library specification.

Synopsis
   char *ldap_err2string(err);

Description
   The ldap_err2string function maps the LDAP result code in
   err to an message string.  The implementation behaves as if no
   library calls the ldap_err2string function.

Returns
   The ldap_err2string function returns a pointer to the string,
   the contents of which are implementation-defined.  The array
   pointed to shall not be modified by the program, but may be
   overwritten by a subsequent call to the ldap_err2string
   function.

Of course, like strerror(), ldap_err2string is not thread safe.
This may be cause to alter the last sentence,
  s/, but may/and must not/

>The draft says:
>So what do you think?

I believe the UTF-8/T.61 requirement should only apply to
strings which are to carried over LDAP.  Other strings,
such as host names and error texts, should be C strings.

> Does the spec nail this down to UTF-8 (in LDAPv3)?

No, and it shouldn't.

 char *s = ldap_err2string( ldap_get_option( NULL, -1, NULL ) );

Is the returned string UTF-8, T.61, or a C string?
It cannot depend on the protocol in use as a protocol version
has yet to specified.  The encoding should not be protocol
dependent, it should be language dependent.

>If [UTF-8], the common coding practice of:
>   printf(".... %s\n", ldap_err2string(err));
>is ill advised since it's not internationalized.

Exactly.  Note that this practice is assumed valid given
the I-D examples.

Kurt



From list@netscape.com  Sat Jun 17 23:15:24 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24666
	for <ldapext-archive@odin.ietf.org>; Sat, 17 Jun 2000 23:15:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5I39mX20895;
	Sat, 17 Jun 2000 20:09:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5I3E0613051;
	Sat, 17 Jun 2000 20:14:00 -0700 (PDT)
Resent-Date: Sat, 17 Jun 2000 20:14:00 -0700 (PDT)
Message-Id: <3.0.5.32.20000617201353.00951100@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 17 Jun 2000 20:13:53 -0700
To: "Dave Steck" <DSTECK@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: UTF-8 / Unicode / Local conversions
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s94ba4b1.066@prv-mail25.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"D3212B.A.mLD.15DT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 04:09 PM 6/16/00 -0600, Dave Steck wrote:
>Applications need a way to display data obtained through the LDAP C API's.
>
>To provide truly cross-directory and *cross-platform* API's, it seems there should be 
>a standard set of C APIs to do UTF-8 <--> Unicode conversions.
>
>There should also be a standard set of API's to convert between either UTF-8 or Unicode and local strings?
>Does anyone know of such a standard or work underway?
>

I believe it appropriate for the IETF LDAPext WG to specify an
an C API to converting between the local charset, T.61, and UTF-8.
	local <-> T.61
	local <-> UTF-8
	UTF-8 <-> T.61

However, as previously discussed, this can be specified as
a (Standard Track) extension.



From list@netscape.com  Sun Jun 18 13:33:38 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09204
	for <ldapext-archive@odin.ietf.org>; Sun, 18 Jun 2000 13:33:37 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5IHOSg02967;
	Sun, 18 Jun 2000 10:24:29 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5IHW7o26016;
	Sun, 18 Jun 2000 10:32:07 -0700 (PDT)
Resent-Date: Sun, 18 Jun 2000 10:32:07 -0700 (PDT)
Date: Sun, 18 Jun 2000 10:31:49 -0700 (PDT)
Message-Id: <200006181731.e5IHVmk16040@xwing.netscape.com>
From: pisespongv@excite.com
To: .UGKE@netscape.com
Subject:  TRY THIS FOR YOUR $$$ GIFT SURPRISE !!
X-Reply-To:  pisespongv@excite.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"gx1zAB.A.7VG.VeQT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

THIS IS THE FAST ONE
DO IT, WHILE YOU'RE WAITING FOR THE OTHERS TO WORK.

You will probably have $7,000.00 in two weeks, ONLY $14.00 to $25.00 Total cost 1 hour of work.

This is a gifting club

PLEASE READ TO FIND OUT HOW

You will not be contacted again.

If you want to make a few thousand dollars real quick, then please take a moment to read and understand 
the program I am sharing with you. No. It is NOT what you think! 

YOU DO NOT HAVE TO SEND $5.00 TO FIVE PEOPLE, to buy a report, get on their mailing list, buy a 
recipes or any other product. Nor will you have to invest more money LATER to get things going. 

THIS IS THE FASTEST, EASIEST PROGRAM you will ever be able to do. Complete it in ONE HOUR and you 
will never forget the day you first received it in the mail. If you are doing other programs, by all mean stay 
with them. The more the merrier!!! But PLEASE-READ ON.

First of all there are only THREE LEVELS, not four, five, or six like other programs. This three level program 
is more realistic and much, much faster. Because it is so easy, the response rate for this program is VERY 
HIGH and VERY FAST, and you receive your reward in about FOURTEEN DAYS. That's only TWO WEEKS-
not three months. Just in time for next month's bills.

TRUE STORY
Cindy Allen tells how she ran this gift summation four times last year. The first time she receives $3,000.00 
in cash in two weeks and the $7,000.00 in cash the next three times. When this letter is continued as it 
should be, EVERYONE PROFITS!! Don't be afraid to make gifts to strangers, they will come back to you ten 
fold. Many of us have pet programs that we support: food or medicine, or medical care for poor children is 
mine. Or maybe you just want to pay off some bills and get out debt. THIS CAN DO IT FOR YOU.

HERE ARE THE SIMPLE DETAILS:
You only mail out at least 200 copies (however you can send out as many as you like. The more you send, 
the more you make). You should send them to PEOPLE WHO SEND YOU THEIR PROGRAMS, because they 
are believers and your program is BETTER AND FASTER. Even if you are already in a program continue, 
stay with it, but do yourself a favor and DO THIS ONE TOO. RIGHT NOW!! It is simple and takes a very small 
investment, not hundreds of dollars AND IT WILL PAY you before the others even begin to trickle in.!!!

JUST GIVE ONE PERSON $ 5.00
That's it! That's all. Follow the simple instructions, and in TWO WEEKS you should have at least $7,000.00 
because most people will respond due to LOW INVESTMENT, SPEED and HIGH PROFIT POTENTIAL. We are 
now at 20% response rate! That's a $10,000.00 return. REALLY! So let's all help keep it going, and help 
each other in these tough times.

INSTRUCTION
1) On a blank sheet of transparent proof paper, write down YOUR NAME and E-MAIL address clearly and 
the word GIFT (this makes the entire program legal & legitimate). Completely wrap it around a FIVE-
DOLLAR BILL.. Send this to the FIRST name on the list below. ONLY THE FIRST PERSON ON THE LIST 
GETS YOUR NAME AND A FIVE DOLLAR GIFT AND THE RIGHT TO HAVE YOUR NAME ON THEIR 
MAILING LIST.

2) Retype the LIST, REMOVING THE FIRST (#1) name from the list. Move the SECOND (#2) name and 
address to the first (#1) position. Move the THIRD (#3) name and address to the (#2) position and place 
YOUR NAME AND ADDRESS in the THIRD (#3) position.

3) Send 200 (or more) copies of your retyped letter. An excellent source of names is the people who send 
you other programs. The most effective way to accelerate your hit rate is to buy opportunity seekers 
mailing list from providers. There are many of them offering this service on the net today. You may find 
them from search engines with keywords : opportunity seekers, mailing list, opt in list, etc. Do it right away. 
It's so easy. Don't mull it over. ONE HOUR THAT'S ALL IT TAKES.

THERE IS NO MORE TO DO. When your name reaches the first (#1) position in a few days it will be your 
turn to collect your gifts. The gifts will be sent to you by over 1,500 to 2,000 people like yourself who are 
willing to invest $ 5.00 and ONE HOUR to receive $ 7,000.00 in cash. That's all !!  There will be a total of 
$7,000.00 in $5.00 bills in your mailbox in about two weeks. CONSIDER THAT!

"NONSENSE.  I HEARD ABOUT IT BEFORE.  A FRIEND OF MINE TOLD ME IT DOESN'T WORK"
Donald Trump was once invited as a guest speaker in a TV talk show. He was asked if he would be 
bankrupted today what would he do next. He said he will join a good MLM business. He was booed by 
other program guests. "That's why you are sitting there and I am sitting here" was what he said to them. 
This program is even much better, easier to operate and yield result much faster than MLM. The only 
reason it doesn't work for somebody is they don't mail enough letters or mail to incorrect target group. 
There are many participants who continuously do it over and over again 3-4 times yearly. Many 
successful gifters even participate more than one program at a time. Why ? Because they know this kind 
of program works for them.  They pocketed 3-5 thousand dollars every time they did it. Most of them had 
joined other "MAKE MONEY ON THE NET" programs.  They know well that this gift program is easiest, 
fastest, lowest investment, not time consuming and offer most potential to make money from internet in a 
very short period of time.


CAN I DO IT AGAIN? OF COURSE...
You can do it again and again either with your regular group of gifters or fresh target mailing list. Why not? 
It beats working! Each time you receive a MLM offer in the your mail box, respond with THIS LETTER. Your 
name will climb to number 1 position at a DIZZYING geometric rate.

Some people may want to purchase a mailing list opportunity seekers ( if you don't know any providers, 
you can find many of them from search engines with keywords "mailing list", "opportunity seekers", etc. ) 
and send it out to 200 to 1,000 or more. That's fine; you can if you want to. You may even download a 
demo or unregistered version but fully functional mass email program to send email to thousands of 
addresses per hour. You may download a good one for free at http://www.fairlogic.com.  Before you use 
any bulk email program please make sure that your ISP is bulk email friendly otherwise you have a certain 
risk of being shutdown. 

THINK ABOUT THAT 20% RESPONSE! Not interested? Come on! Isn't the prospect of an easy $7,000.00 to 
$10,000.00 in two weeks worth a little experimentation? One hour of your time.

ACT FAST AND GET MONEY FAST!
Honesty and integrity make this plan work.  If you cheat you will never receive the full potential of this gift 
letter. Send FIVE DOLLARS to the first name NOW !!

SHORT INSTRUCTION

SEND $ 5 TO  NO. # 1, DELETE THE NAME AND ADDRESS OF # 1, ROLL THE REST UP ONE STEP (replace 
NAME & ADDRESS of # 1 with # 2,  # 2  with # 3), PUT YOUR NAME IN NO # 3, AND START RECEIVING 
PILE OF $ 5 BILL IN YOUR MAIL BOX DAILY !!

HERE IS THE LIST

# 1
CARM
Dept. 20
P.O. Box 2943
Concord, NH 03302-2943

# 2
Linda Hatch
1107 N Grove
Yates Center, KS 66783

# 3 
Vornsrinth  P.
129 / 263 Room No 263, 7th FL, Tower B, 
Ratchada Orchid Tower, 
Hussadi-Saewee Ln., Suthisarn Rd.
Bangkok 10320, Thailand

---------------------------------------------
Your address is supplied from an opportunity seekers target list provider. I do apologize if you are not in 
this target group as claimed by the provider. If you want to opt out from future mailing, please reply to 
giftremove@flashmail.com?subject=REMOVE




From list@netscape.com  Sun Jun 18 17:46:50 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10516
	for <ldapext-archive@odin.ietf.org>; Sun, 18 Jun 2000 17:46:50 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5ILevX00257;
	Sun, 18 Jun 2000 14:40:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5ILjBo14370;
	Sun, 18 Jun 2000 14:45:11 -0700 (PDT)
Resent-Date: Sun, 18 Jun 2000 14:45:11 -0700 (PDT)
Date: Sun, 18 Jun 2000 14:44:50 -0700 (PDT)
From: kelly@4qd.co.uk
Message-Id: <200006182144.e5ILink03171@xwing.netscape.com>
Resent-Message-ID: <"rsF9SD.A.NgD.mLUT5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
Subject: Unidentified subject!
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Dear Internet Users,

How would you like to find almost anything on the Internet? 

* Sometimes it's so frustrating to find anything from the search engines.
* Find places and things you never new existed!  
* Everything is in categories and in an easy to use index form.
* No pornography or casino is in this research guide.
* Specifically designed for all genders and ages.  
* Extensive and reliable sources of information.
* 5 years into the making.
* Down below is a small sample:

>adoption
>answering service
>free email
>free websites
>gaming
>goverment sites
>investigation
>isp list
>magazines (children-women-men)
>legal
>medical
>newspaper
>pets
>search engines
>telephone directories
>web sites design
>zoos
>and more

*  The " Internet Resource " regular price is $29.95. If you respond before 6-23-00 it's only $19.95. Shipping and handling is included.
*  Simply call 1-480-990-4463 to receive your copy today!  We offer 30-day money back guarantee. 
*  Please allow 1-2 weeks for shipping.



From list@netscape.com  Mon Jun 19 05:26:42 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28136
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 05:26:41 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5J9KsX01063;
	Mon, 19 Jun 2000 02:20:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5J9P8U26628;
	Mon, 19 Jun 2000 02:25:08 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 02:25:08 -0700 (PDT)
Message-Id: <s94d9289.079@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 19 Jun 2000 03:24:49 -0600
From: "Vithalprasad Gaitonde" <GVithalprasad@novell.com>
To: "<"<ietf-ldapext@netscape.com>
Subject: invalid Credentials v/s Inappropriate authentication
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5J9P4126562
Resent-Message-ID: <"cPDPzD.A.UfG.wbeT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Hi,
	My query pertains to the resultcode being returned by ldap server during user authentication.
In which cases should the ldap server return invalid credentials and when does it return Inappropriate authentication. 
For e.g If I create a user thru ldif w/o a password attribute, the password attribute of this user will be NULL. Now when I try to login as this user with a nonNULL password, should the server return invalid credentails or Inappropriate authentication. 
Where do we draw the line between these two result codes.

Thanks & Regards,
Prasad





From list@netscape.com  Mon Jun 19 07:08:57 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29132
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 07:08:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JAxlg18378;
	Mon, 19 Jun 2000 03:59:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JB7Rs20454;
	Mon, 19 Jun 2000 04:07:27 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 04:07:27 -0700 (PDT)
Message-Id: <s94daa73.009@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 19 Jun 2000 04:27:43 -0600
From: "Vithalprasad Gaitonde" <GVithalprasad@novell.com>
To: <ietf-ldapext@netscape.com>
Subject: Getting all attributes for a particular objectclass
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5JB7P120404
Resent-Message-ID: <"it9KT.A.N_E.u7fT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Hi,
	Is there any way in LDAP v3 by which I can get schema for a particular objectclass or for a particular attribyteType. The cn=schema search gets the entire schema. But how do I get it only for a particular objectclass and a particular attributeType.
Does anyone have ideas ?

Thanks & Regards
Prasad




From list@netscape.com  Mon Jun 19 09:40:43 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05077
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 09:40:42 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JDU8g27613;
	Mon, 19 Jun 2000 06:30:08 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JDbmw27083;
	Mon, 19 Jun 2000 06:37:48 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 06:37:48 -0700 (PDT)
Message-Id: <3.0.5.32.20000619063738.0096c820@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jun 2000 06:37:38 -0700
To: "Vithalprasad Gaitonde" <GVithalprasad@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: invalid Credentials v/s Inappropriate authentication
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s94d9289.079@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"QbqEoD.A.2mG.rIiT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 03:24 AM 6/19/00 -0600, Vithalprasad Gaitonde wrote:
>Hi,
>	My query pertains to the resultcode being returned by ldap server during user authentication.
>In which cases should the ldap server return invalid credentials and when does it return Inappropriate authentication. 

It should return invalid credentials when the provided credentials are unverifiable.

>For e.g If I create a user thru ldif w/o a password attribute, the password attribute of this user will be NULL. Now when I try to login as this user with a nonNULL password, should the server return invalid credentails or Inappropriate authentication. 

InvalidCredentials.

>Where do we draw the line between these two result codes.

RFC 2251, 4.2.2:
   - inappropriateAuthentication: the server requires the client
     which had attempted to bind anonymously or without supplying
     credentials to provide some form of credentials,

That is, inappropriateAuthentication should be returned with server requires
the client to provide credentials and doesn't, invalid credentials should
be returned when the provided credentials are invalid.

Kurt
   
                             



From list@netscape.com  Mon Jun 19 09:47:58 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05413
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 09:47:57 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JDcWg28588;
	Mon, 19 Jun 2000 06:38:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JDkDc00856;
	Mon, 19 Jun 2000 06:46:13 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 06:46:13 -0700 (PDT)
Message-Id: <3.0.5.32.20000619064604.009713a0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jun 2000 06:46:04 -0700
To: "Vithalprasad Gaitonde" <GVithalprasad@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: Getting all attributes for a particular objectclass
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s94daa73.009@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"_r6tx.A.DN.kQiT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 04:27 AM 6/19/00 -0600, Vithalprasad Gaitonde wrote:
>Hi,
>	Is there any way in LDAP v3 by which I can get schema for a particular objectclass or for a particular attribyteType.

You can use assert (using compare) that the particular attributeType
is defined (e.g. assert cn is a value of AttributeTypes).  Or, using
returned matched values only control, use a search (attributeTypes=cn).

>The cn=schema search gets the entire schema. But how do I get it only for a particular objectclass and a particular attributeType.
>Does anyone have ideas ?

You need a control to be able to read a subset of values of a
particular attribute type within a given entry (or subentry).

Kurt




From list@netscape.com  Mon Jun 19 10:02:38 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06197
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 10:02:38 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JDrAg00110;
	Mon, 19 Jun 2000 06:53:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JE0oA06141;
	Mon, 19 Jun 2000 07:00:50 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 07:00:50 -0700 (PDT)
Message-Id: <3.0.5.32.20000619070041.00954e60@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jun 2000 07:00:41 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: dupent and filters
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"WEylID.A.ofB.ReiT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

How does dupent interact with filters?  Are entries:
	1) dup'ed then matched
	2) matched then dup'ed

That is, given a entry within scope of the search:
	dn: cn=foo, o=bar
	cn: foo
	cn: bar
	...

The filter is (cn=foo) and critical dupent w/ attrs of cn.

Should their be one dup-entry or two dup-entries returned?
I would assume that the returned duplicate entries would
each match the filter.  Hence 1). above.  Of course,
implementors would likely want to match then dup
then match to avoid unnecessary dup'ing.

Anyways, whether 1 or 2, the behavior should be spelled out.

Kurt



From list@netscape.com  Mon Jun 19 10:50:02 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08437
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 10:50:01 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JEggX23253;
	Mon, 19 Jun 2000 07:42:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JEkvQ21500;
	Mon, 19 Jun 2000 07:46:57 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 07:46:57 -0700 (PDT)
Message-ID: <394E3278.E258C0D1@netscape.com>
Date: Mon, 19 Jun 2000 10:47:21 -0400
From: mcs@netscape.com (Mark C Smith)
Organization: iPlanet E-Commerce Solutions
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
CC: Dave Steck <DSTECK@novell.com>, ietf-ldapext@netscape.com
Subject: Re: UTF-8 / Unicode / Local conversions
References: <3.0.5.32.20000617201353.00951100@infidel.boolean.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"EfKx3C.A.nPF.gJjT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> 
> At 04:09 PM 6/16/00 -0600, Dave Steck wrote:
> >Applications need a way to display data obtained through the LDAP C API's.
> >
> >To provide truly cross-directory and *cross-platform* API's, it seems there should be
> >a standard set of C APIs to do UTF-8 <--> Unicode conversions.
> >
> >There should also be a standard set of API's to convert between either UTF-8 or Unicode and local strings?
> >Does anyone know of such a standard or work underway?
> >
> 
> I believe it appropriate for the IETF LDAPext WG to specify an
> an C API to converting between the local charset, T.61, and UTF-8.
>         local <-> T.61
>         local <-> UTF-8
>         UTF-8 <-> T.61
> 
> However, as previously discussed, this can be specified as
> a (Standard Track) extension.

In most environments, these functions are already provided.  I am not
convinced that the LDAPEXT group should duplicate the work being done by
OS and platform vendors.  T.61 may be a special case, but I for one
would like to let T.61 die.

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?



From list@netscape.com  Mon Jun 19 11:38:11 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11230
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 11:38:10 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JFRig11055;
	Mon, 19 Jun 2000 08:27:44 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JFZPY16349;
	Mon, 19 Jun 2000 08:35:25 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 08:35:25 -0700 (PDT)
Message-Id: <3.0.5.32.20000619083454.00956260@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jun 2000 08:34:54 -0700
To: mcs@netscape.com (Mark C Smith)
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: UTF-8 / Unicode / Local conversions
Cc: Dave Steck <DSTECK@novell.com>, ietf-ldapext@netscape.com
In-Reply-To: <394E3278.E258C0D1@netscape.com>
References: <3.0.5.32.20000617201353.00951100@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"-xCPH.A.o-D.52jT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 10:47 AM 6/19/00 -0400, Mark C Smith wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 04:09 PM 6/16/00 -0600, Dave Steck wrote:
>> >Applications need a way to display data obtained through the LDAP C API's.
>> >
>> >To provide truly cross-directory and *cross-platform* API's, it seems there should be
>> >a standard set of C APIs to do UTF-8 <--> Unicode conversions.
>> >
>> >There should also be a standard set of API's to convert between either UTF-8 or Unicode and local strings?
>> >Does anyone know of such a standard or work underway?
>> >
>> 
>> I believe it appropriate for the IETF LDAPext WG to specify an
>> an C API to converting between the local charset, T.61, and UTF-8.
>>         local <-> T.61
>>         local <-> UTF-8
>>         UTF-8 <-> T.61
>> 
>> However, as previously discussed, this can be specified as
>> a (Standard Track) extension.
>
>In most environments, these functions are already provided.  I am not
>convinced that the LDAPEXT group should duplicate the work being done by
>OS and platform vendors.

I have similiar concerns as well.  My comment was more to the point
that the working group had, IMO, reached some consensus previously
that such features would be best handled as extensions to the
API.

Note that I added T.61 to my statement because the C API
supports both LDAPv2 and LDAPv3.  If an extension provides UTF-8
conversions, it should provide T.61 (and vice versa).  It's not a
matter of letting T.61 die, it's a matter of letting LDAPv2 die.
I do believe that inconsistent LDAPv2 charset handling by various
vendors (including OpenLDAP) will eventually kill LDAPv2.

Kurt



From list@netscape.com  Mon Jun 19 11:59:58 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12223
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 11:59:58 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JFs2X05407;
	Mon, 19 Jun 2000 08:54:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JFwHk29204;
	Mon, 19 Jun 2000 08:58:17 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 08:58:17 -0700 (PDT)
Message-ID: <394E42ED.C5F781F7@moonvine.org>
Date: Mon, 19 Jun 2000 10:57:34 -0500
From: Chris Tomlinson <chris@moonvine.org>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark C Smith <mcs@netscape.com>
CC: "Kurt D. Zeilenga" <Kurt@openldap.org>, Dave Steck <DSTECK@novell.com>,
        ietf-ldapext@netscape.com
Subject: Re: UTF-8 / Unicode / Local conversions
References: <3.0.5.32.20000617201353.00951100@infidel.boolean.net> <394E3278.E258C0D1@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"dncXYC.A.0HH.YMkT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

But T.61 is the main requirement for supporting LDAP v2. Also I don't think there is a standard set of T.61
conversions in Java. In fact as far as I know you can represent characters in T.61 that have no correspondence in
UCS-2/UTF-8.

ciao,
Christine Tomlinson

Mark C Smith wrote:

> "Kurt D. Zeilenga" wrote:
> >
> > At 04:09 PM 6/16/00 -0600, Dave Steck wrote:
> > >Applications need a way to display data obtained through the LDAP C API's.
> > >
> > >To provide truly cross-directory and *cross-platform* API's, it seems there should be
> > >a standard set of C APIs to do UTF-8 <--> Unicode conversions.
> > >
> > >There should also be a standard set of API's to convert between either UTF-8 or Unicode and local strings?
> > >Does anyone know of such a standard or work underway?
> > >
> >
> > I believe it appropriate for the IETF LDAPext WG to specify an
> > an C API to converting between the local charset, T.61, and UTF-8.
> >         local <-> T.61
> >         local <-> UTF-8
> >         UTF-8 <-> T.61
> >
> > However, as previously discussed, this can be specified as
> > a (Standard Track) extension.
>
> In most environments, these functions are already provided.  I am not
> convinced that the LDAPEXT group should duplicate the work being done by
> OS and platform vendors.  T.61 may be a special case, but I for one
> would like to let T.61 die.
>
> --
> Mark Smith
> Directory Product Development / iPlanet E-Commerce Solutions
> My words are my own, not my employer's.            Got LDAP?



From list@netscape.com  Mon Jun 19 13:26:27 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17227
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 13:26:26 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JHKRX21254;
	Mon, 19 Jun 2000 10:20:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JHOgk19483;
	Mon, 19 Jun 2000 10:24:42 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 10:24:42 -0700 (PDT)
Sender: mcs@netscape.com (Mark C Smith)
Message-ID: <394E5753.E0F6D875@netscape.com>
Date: Mon, 19 Jun 2000 13:24:35 -0400
From: Mark Smith <mcs@netscape.com>
Organization: iPlanet E-Commerce Solutions
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en-US,en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
CC: Dave Steck <DSTECK@novell.com>, ietf-ldapext@netscape.com
Subject: Re: ldap_err2string format
References: <3.0.5.32.20000617200449.009554f0@infidel.boolean.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"gCPBB.A.EwE.YdlT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

I generally agree with your comments, and this should be clarified when
we revise the C API I-D.

But ldap_err2string() may or may not be thread safe, depending on how it
is implemented.  If an implementation returns a pointer to static,
readonly data or to thread specific data, ldap_err2string() should be
thread safe).

Also, I don't understand what this sentence from your suggested text is
intended to convey:

>    The implementation behaves as if no
>    library calls the ldap_err2string function.

?

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?


"Kurt D. Zeilenga" wrote:
> 
> At 03:54 PM 6/16/00 -0600, Dave Steck wrote:
> >According to <draft-ietf-ldapext-ldap-c-api-04.txt>, the output of ldap_err2string(err) is:
> >  "an informative zero-terminated character string message describing the error."
> >It doesn't specify whether the string is encoded in UTF-8 or may be local, such as DBCS.
> 
> I believe ldap_err2string(err) is intended to behave much
> like strerror(err).  I would suggest using language similar
> to that found in the Standard C Library specification.
> 
> Synopsis
>    char *ldap_err2string(err);
> 
> Description
>    The ldap_err2string function maps the LDAP result code in
>    err to an message string.  The implementation behaves as if no
>    library calls the ldap_err2string function.
> 
> Returns
>    The ldap_err2string function returns a pointer to the string,
>    the contents of which are implementation-defined.  The array
>    pointed to shall not be modified by the program, but may be
>    overwritten by a subsequent call to the ldap_err2string
>    function.
> 
> Of course, like strerror(), ldap_err2string is not thread safe.
> This may be cause to alter the last sentence,
>   s/, but may/and must not/
> 
> >The draft says:
> >So what do you think?
> 
> I believe the UTF-8/T.61 requirement should only apply to
> strings which are to carried over LDAP.  Other strings,
> such as host names and error texts, should be C strings.
> 
> > Does the spec nail this down to UTF-8 (in LDAPv3)?
> 
> No, and it shouldn't.
> 
>  char *s = ldap_err2string( ldap_get_option( NULL, -1, NULL ) );
> 
> Is the returned string UTF-8, T.61, or a C string?
> It cannot depend on the protocol in use as a protocol version
> has yet to specified.  The encoding should not be protocol
> dependent, it should be language dependent.
> 
> >If [UTF-8], the common coding practice of:
> >   printf(".... %s\n", ldap_err2string(err));
> >is ill advised since it's not internationalized.
> 
> Exactly.  Note that this practice is assumed valid given
> the I-D examples.
> 
> Kurt



From list@netscape.com  Mon Jun 19 13:48:34 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18365
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 13:48:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JHd7g00566;
	Mon, 19 Jun 2000 10:39:08 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5JHklk29441;
	Mon, 19 Jun 2000 10:46:47 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 10:46:47 -0700 (PDT)
Message-Id: <3.0.5.32.20000619104630.00970d70@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jun 2000 10:46:30 -0700
To: Mark Smith <mcs@netscape.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: ldap_err2string format
Cc: Dave Steck <DSTECK@novell.com>, ietf-ldapext@netscape.com
In-Reply-To: <394E5753.E0F6D875@netscape.com>
References: <3.0.5.32.20000617200449.009554f0@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"t3bUcD.A.PLH.FylT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 01:24 PM 6/19/00 -0400, Mark Smith wrote:
>I generally agree with your comments, and this should be clarified when
>we revise the C API I-D.
>
>But ldap_err2string() may or may not be thread safe, depending on how it
>is implemented.

Which means that applications must assume that it is not thread
safe unless they have specific knowledge regarding the current
implementation.

>If an implementation returns a pointer to static,
>readonly data or to thread specific data, ldap_err2string() should be
>thread safe).

strerror() is not thread safe because it allows the implementation
to dynamically create the string in the static, readonly (to caller)
space, e.g: "unknown error (666)".  Same would follow for
ldap_err2string().

>Also, I don't understand what this sentence from your suggested text is
>intended to convey:
>>    The implementation behaves as if no
>>    library calls the ldap_err2string function.

That's straight from Standard C Library spec for strerror().
It implies that if the caller makes a call to strerror() followed
by some other library call (such as printf or strcpy) that the
string will not change until the caller makes a subsequent
strerror() call.  Without this requirement:

	char *s = strerror(errno);
	printf("%s\n", s);

might not print the value of s at the time of the strerror
call.  That is, printf is not allowed to call strerror itself
and trash the string before printing the string.

Kurt




From list@netscape.com  Mon Jun 19 20:06:10 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25935
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 20:06:10 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5JNv1g25047;
	Mon, 19 Jun 2000 16:57:01 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5K04gU02099;
	Mon, 19 Jun 2000 17:04:42 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 17:04:42 -0700 (PDT)
Date: Mon, 19 Jun 2000 17:04:30 -0700 (PDT)
Message-Id: <200006200004.e5K04Ux03863@ywing.netscape.com>
From: newlifeforyou@angelfire.com
To: Friends@netscape.com
Subject:  It's time to get serious!
X-Reply-To:  newlifeforyou@angelfire.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"144hkD.A.cg.YUrT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

$10,000 per month GUARANTEED! We've all seen messages like this, and I hope that 
you too are doing well with your program. However, today I'd like to take a break 
from the usual money making matters for a moment if I may, and address something 
immensely more important to all of us. For what shall it profit a man if he gain the whole 
world, and lose his soul? ( Matthew 6:21 )
The biggest and most dramatic need of mankind is to become right with God. To become 
right with God is to become saved from God's wrath and be renewed by the Holy Spirit 
and be given eternal life (Matthew 25:46). This is called salvation. What is salvation, and 
how can one become saved?

The moment of salvation is the moment of truth, when we take off our rose-colored 
glasses through which we thought that somehow all would be well with us, and we stop 
kidding ourselves that we are really rather fine people. The moment of truth is when we 
take our heads out of the sand and face the truth about ourselves.

One truth that we learn from the Scriptures is that we are desperately wicked. The Bible 
declares in Jeremiah 17:9, "The heart is deceitful above all things, and desperately 
wicked: who can know it?"

The Bible says in Romans 3:10-18:

As it is written, There is none righteous, no, not one: There is none that understandeth, 
there is none that seeketh after God. They are all gone out of the way, they are together 
become unprofitable; there is none that doeth good, no, not one. Their throat is an open 
sepulchre; with their tongues they have used deceit; the poison of asps is under their lips: 
Whose mouth is full of cursing and bitterness: Their feet are swift to shed blood: 
Destruction and misery are in their ways: And the way of peace have they not known: 
There is no fear of God before their eyes.

These verses tell us of a horrible truth that we must honestly and frankly face. God is 
telling us that we are like poisonous snakes. God is telling us that we are altogether 
rebellious against Him in every fiber of our beings. All the good things that we have been 
doing are not at all pleasing to God; we do them for our own selfish reasons or because 
we think that through them, God will look with favor upon our spiritual corpses in which we 
have no life. Moreover, we are enslaved to Satan, who is our master if we are unsaved 
(Ephesians 2:1-3).

Another truth that we must face is that because of our sins, we are under the wrath of 
God. God's Word declares in Romans 6:23, "the wages of sin is death." The death that 
God has in view is not merely physical death but it is spiritual death. That is, God 
declares that because of our sins, we must be eternally in hell under the wrath of God, 
paying for our sins. God created us good and after His image; therefore, we are 
accountable to Him for our actions.

God says in Matthew 12:36, "But I say unto you, That every idle word that men shall 
speak, they shall give account thereof in the day of judgment." Our thoughts, words, and 
deeds, when viewed in the light of the perfection of the law of God, will prove beyond a 
doubt that we are sinners. To pay for these sins, we must be cast into hell and suffer 
eternal damnation. What a heartbreaking, impossible future there is for us if we are 
unsaved. We might have thought we were good people with the best still to come in our 
lives, and now we discover the awful fact that we are corrupt sinners subject to the eternal 
wrath of God. Can there be salvation? Can there be a way of escape from this horrible 
predicament?

Another truth that we must face is that God has provided a marvelous, glorious, wonderful 
way of escape from our sins and the wrath of God, and that way is through the Lord Jesus 
Christ. The Bible tells us to believe in the Lord Jesus Christ (John 3:16). God so loved the 
world that He not only provided for the redemption of the universe, but He also provided for 
the redemption of those who recognize their bankrupt spiritual condition and cast 
themselves on the mercy of God. For these people, Christ became sin (II Corinthians 
5:21), that is, Christ took all their sins upon Himself. As our substitute, He was judged by 
God as He stood before the Roman governor, Pilate. Christ was found guilty for these 
sins, and God poured out His wrath on Him as He, as our substitute, paid for these sins.

Wonderfully, we do not have to understand how all this happened. However, it is 
imperative that we recognize the truth that in Christ and only in Christ is there salvation. 
Somehow, through Christ, God's wrath has been satisfied, and we are no longer under 
condemnation before God. The Bible declares in Romans 8:1, "There is therefore now no 
condemnation to them which are in Christ Jesus, who walk not after the flesh, but after 
the Spirit."

Those who have placed their trust in Christ have realized their hopelessly sinful and lost 
condition. They realize that their sins were sending them to hell; they have begun to see 
the terrible nature of sin, and within their lives, there is a tremendous desire to turn from 
their sins. They know that Christ must be Lord of their lives. Because Christ is God who 
has given us His Word, the Bible, they begin to have an ongoing desire to know more and 
more about His Word. As they learn from God's Word, they want increasingly to be 
obedient to all that they find there.


The Bible declares in I John 1:9, "If we confess our sins, he is faithful and just to forgive 
us our sins, and to cleanse us from all unrighteousness." This verse teaches us that 
somehow through Christ, those who trust God will have their sins forgiven. This is what 
salvation is -- to be saved from the wrath of God, which we otherwise deserve because of 
our sins. Salvation is to abandon ourselves to Christ as our only Lord and Savior.

Before we are saved, both in body and soul, we are spiritually dead; we lust after sin. We 
are in rebellion against God and we are slaves of Satan. By God's mercy, He reaches 
down into our lives and begins to open our spiritual eyes and spiritual ears so that we see 
our utter sinfulness, and we begin to hear from God's Word the importance of turning to 
Christ as our only Savior, the only Way by which we can be reconciled to God the Father. 
As God works within our hearts, we begin to more and more sense our terrible 
predicament. We realize that we are only a breath away from eternity; and if we die 
without the Savior, we will eternally be in hell. In our uneasiness, we begin to cry to God 
for help. As the publican of old, we pray, "God be merciful to me a sinner" (Luke 18:13).

At some point, unknown to us, God gives us brand new souls. The soul is the spirit 
essence of man. The soul is the part of man that leaves the body at death. If we are 
saved, it is in our souls that we go to live and reign with Christ in heaven. It is in our souls 
that we experience eternal life. It is in our souls that we become born again. It is in our 
souls that we are new creatures. It is in our souls that we have been raised with Christ, 
that is, we have experienced the resurrection. It is in our souls that we never wish to sin 
again. It is in our saved souls that we have an ongoing, never-ending desire to be obedient 
to God's Word.

Because our souls are brand new after we are saved, our lives are quite different from 
what they were before salvation. It is true that in our bodies, we still lust after sin. Our 
bodies have not yet experienced the resurrection. But because we have received our new 
souls, we feel terrible when we sin. In our new souls, we feel violated by our sin. 
Therefore, we find true happiness only as we live obediently before God. Increasingly, 
then, we deny the lusts of the sin which our bodies crave, and we focus on the Lord Jesus 
Christ, whom we earnestly love and who has become the Lord of our lives.
Oh, it is my sincere desire that you will come to believe this truth, as time is getting very 
short for us all. May the Lord bless you and give you a heart to love Him and follow Him, 
so that you too, may glory in Him, and in the everlasting joys of heaven, for how shall we 
escape the great judgment day of God if we neglect His wonderful, merciful plan of 
salvation? TODAY is the day of salvation my friend. Please, don't put it off till tomorrow, 
for you may not have tomorrow! Many of us will not! Remember, all our days are 
numbered! Each and every day over 145,000 people die, and the majority of them had 
absolutely no idea that this would be their last day! God is here right now watching you as 
you read this message. What will you do with it? Will you turn to Him for forgiveness, or 
will you continue to stick your head in the sand and hope that all will turn out well? It's 
your soul that we are talking about dear friend, please believe this truth and act ont it 
today! Time is running out on us all. I want you to know that I am praying for you. 





From list@netscape.com  Mon Jun 19 20:34:51 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26223
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 20:34:50 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5K0T7X00528;
	Mon, 19 Jun 2000 17:29:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5K0XMY13188;
	Mon, 19 Jun 2000 17:33:22 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 17:33:22 -0700 (PDT)
Message-Id: <s94e6763.051@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 19 Jun 2000 18:33:03 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <ietf-ldapext@netscape.com>, <Kurt@openldap.org>
Subject: Re: dupent and filters
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5K0XJ113159
Resent-Message-ID: <"4_8AK.A.tND.PvrT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

From section 4.1: "If a specified attribute exists in an entry to be returned by search, one instance of that entry per attribute value is returned". This implies that the search has been completed and the dupent control is applied to the result set of the search. The idea of only returning entries that match the filter is good though, it's something that slipped by. I'd like to add language that specifies that each duplicate entry MUST match the search filter, server implementations may vary, but the end result should be the same.  

I'm also wondering if anyone will expect that each duplicate entry might not match the filter? Given your example, one might know that the entry is named cn=foo, o=bar and want to read it and get the result back as duplicate entries. If people will want this behavior, we'd have to add an option to the request control that allows the server to return duplicates don't match the filter. What do you think?

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/19/00 8:01:10 AM >>>
How does dupent interact with filters?  Are entries:
	1) dup'ed then matched
	2) matched then dup'ed

That is, given a entry within scope of the search:
	dn: cn=foo, o=bar
	cn: foo
	cn: bar
	...

The filter is (cn=foo) and critical dupent w/ attrs of cn.

Should their be one dup-entry or two dup-entries returned?
I would assume that the returned duplicate entries would
each match the filter.  Hence 1). above.  Of course,
implementors would likely want to match then dup
then match to avoid unnecessary dup'ing.

Anyways, whether 1 or 2, the behavior should be spelled out.

Kurt




From list@netscape.com  Mon Jun 19 20:41:16 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26288
	for <ldapext-archive@odin.ietf.org>; Mon, 19 Jun 2000 20:41:16 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5K0W8g00160;
	Mon, 19 Jun 2000 17:32:08 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5K0dnA16716;
	Mon, 19 Jun 2000 17:39:49 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 17:39:49 -0700 (PDT)
Message-Id: <3.0.5.32.20000619173938.00950600@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 19 Jun 2000 17:39:38 -0700
To: "Jim Sermersheim" <JIMSE@novell.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: dupent and filters
Cc: <ietf-ldapext@netscape.com>
In-Reply-To: <s94e6763.052@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"0dLu1B.A.KEE.S1rT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 06:33 PM 6/19/00 -0600, Jim Sermersheim wrote:
>>From section 4.1: "If a specified attribute exists in an entry to be returned by search, one instance of that entry per attribute value is returned". This implies that the search has been completed and the dupent control is applied to the result set of the search. The idea of only returning entries that match the filter is good though, it's something that slipped by. I'd like to add language that specifies that each duplicate entry MUST match the search filter, server implementations may vary, but the end result should be the same.  

I concur.

>I'm also wondering if anyone will expect that each duplicate entry might not match the filter? Given your example, one might know that the entry is named cn=foo, o=bar and want to read it and get the result back as duplicate entries. If people will want this behavior, we'd have to add an option to the request control that allows the server to return duplicates don't match the filter. What do you think?
>

I rather keep the control as simple as possible.



From list@netscape.com  Tue Jun 20 00:48:13 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01628
	for <ldapext-archive@odin.ietf.org>; Tue, 20 Jun 2000 00:48:13 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5K4cxg17697;
	Mon, 19 Jun 2000 21:39:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5K4kf223097;
	Mon, 19 Jun 2000 21:46:41 -0700 (PDT)
Resent-Date: Mon, 19 Jun 2000 21:46:41 -0700 (PDT)
Message-Id: <s94ea2cb.013@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 19 Jun 2000 22:46:23 -0600
From: "Vithalprasad Gaitonde" <GVithalprasad@novell.com>
To: <ietf-ldapext@netscape.com>
Subject: Re: Getting all attributes for a particular objectclass
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5K4kd123070
Resent-Message-ID: <"UfB5yB.A.koF.vcvT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Hi Kurt,
	Thanks for the reply. 
Just a thought.....matached values control is not being supported by many ldap servers ( does any ldap server support it yet ??)......this would severly contriant a user from knowing the schema for a particular objectclass or attributetype. Do you see a case for this feature being a part of the vanila LDAP v3 standard itself and not just a additional control. 
Any thoughts ??

Thanks & Regards,
Prasad

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 06/19/00 07:16PM >>>
At 04:27 AM 6/19/00 -0600, Vithalprasad Gaitonde wrote:
>Hi,
>	Is there any way in LDAP v3 by which I can get schema for a particular objectclass or for a particular attribyteType.

You can use assert (using compare) that the particular attributeType
is defined (e.g. assert cn is a value of AttributeTypes).  Or, using
returned matched values only control, use a search (attributeTypes=cn).

>The cn=schema search gets the entire schema. But how do I get it only for a particular objectclass and a particular attributeType.
>Does anyone have ideas ?

You need a control to be able to read a subset of values of a
particular attribute type within a given entry (or subentry).

Kurt





From list@netscape.com  Tue Jun 20 04:04:53 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15087
	for <ldapext-archive@odin.ietf.org>; Tue, 20 Jun 2000 04:04:52 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5K7tPg27838;
	Tue, 20 Jun 2000 00:55:26 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5K837Q05871;
	Tue, 20 Jun 2000 01:03:07 -0700 (PDT)
Resent-Date: Tue, 20 Jun 2000 01:03:07 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000620093033.0350a1e0@dokka.kvatro.no>
X-Sender: hta@dokka.maxware.no
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 20 Jun 2000 09:31:17 +0200
To: Chris Tomlinson <chris@moonvine.org>, Mark C Smith <mcs@netscape.com>
From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
Subject: Re: UTF-8 / Unicode / Local conversions
Cc: "Kurt D. Zeilenga" <Kurt@openldap.org>, Dave Steck <DSTECK@novell.com>,
        ietf-ldapext@netscape.com
In-Reply-To: <394E42ED.C5F781F7@moonvine.org>
References: <3.0.5.32.20000617201353.00951100@infidel.boolean.net>
 <394E3278.E258C0D1@netscape.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"fc66wC.A.SbB.5UyT5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 10:57 19.06.2000 -0500, Chris Tomlinson wrote:
>But T.61 is the main requirement for supporting LDAP v2. Also I don't 
>think there is a standard set of T.61
>conversions in Java. In fact as far as I know you can represent characters 
>in T.61 that have no correspondence in
>UCS-2/UTF-8.

I'd like to see an example; T.61 was on the list of charsets for which 
Unicode was supposed to provide round-trip compatibility (convert into 
Unicode and back with no loss of information).

                    Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no



From list@netscape.com  Tue Jun 20 20:21:02 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06683
	for <ldapext-archive@odin.ietf.org>; Tue, 20 Jun 2000 20:21:02 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5L0FKX09148;
	Tue, 20 Jun 2000 17:15:20 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5L0JbE23775;
	Tue, 20 Jun 2000 17:19:37 -0700 (PDT)
Resent-Date: Tue, 20 Jun 2000 17:19:37 -0700 (PDT)
Message-ID: <>
From: "a_z7882296@yahoo.com" <a_z7882296@yahoo.com>
Reply-To: email_svcs@yahoo.com
Subject: Direct Email Marketing (18990)
Date: Tue, 20 Jun 2000 13:38:35 -0400 (EDT)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Apparently-From: HHomeMtgs4UU@aol.com
Resent-Message-ID: <"f7WCRD.A.9yF.WoAU5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

TIRED OF ENDLESSLY POSTING YOUR ONLINE CLASSIFIED AD AND
GETTING NO RESULTS?

The fact is there are over 7000 such sites scattered about the web and
frankly none of them generate enough traffic to be worth your while. Even
when someone does find or visits one of these sites, your ad is hopelessly
lost in a myriad of similar offerings.

Another frustration is search engines. If you are not in the Top 10 forget
about high traffic visiting your web site. Not everyone can be in the Top 10
and stay there, when there are estimates of 4 million that have a web pages.

You ask, how do we know? That's exactly what we used to do.

The greatest way of marketing this century is undoubtedly direct e-mail. It's
similar to the postman delivering a letter to your mailbox. There is NO
stumbling on to it! The ability to promote your product, service, website, or
MLM/Network Marketing opportunity to millions instantly is what advertisers
have been dreaming of for over 100 years. We will e-mail your one page
promotion to a list of our general addresses. The greatest part is, it's
completely affordable.

NOTICE: No pornography, chain letters, get quick rich, pyramid scheme, or
any threatening or questionable materials. Don't even Ask!!

Fax (419) 735-5792  to inquire about direct e-mail pricing.


THIS FORM MUST BE COMPLETELY FILLED OUT!

Contact Name: _____________________________________________

Business Name:  ______________________________________

Business Type:  ______________________________________

# Years in Business:  _________________________

Address: _________________________________________________

City: ____________________  State: ______  Zip: ______________

Country: _______________

Email Address: _______________________________________________

Phone:  __________________________

Fax:  ____________________________

***********************************
10170



From list@netscape.com  Wed Jun 21 03:00:52 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24053
	for <ldapext-archive@odin.ietf.org>; Wed, 21 Jun 2000 03:00:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5L6pcg21351;
	Tue, 20 Jun 2000 23:51:39 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5L6xMg11949;
	Tue, 20 Jun 2000 23:59:22 -0700 (PDT)
Resent-Date: Tue, 20 Jun 2000 23:59:22 -0700 (PDT)
Message-ID: <B7EE5F06DEEBD3118EA000C04F01A360446ECD@www.aztec.soft.net>
From: Natarajan S K <sknatarajan@aztec.soft.net>
To: ietf-ldapext@netscape.com
Subject: DIT specific attribute
Date: Wed, 21 Jun 2000 12:30:16 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"mcZ6B.A.Y6C.IfGU5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi , 
 I wanted to know whether there exists any DIT specific attribute defined in
any of our standards or drafts which can be made use of. 
   The main intent of this attribute should be to return an identity of the
DIT that the server is holding a replica of.
 It seems so commonplace that I'm very sure something already exists but I'm
not able to find any such thing in our LDAP RFCs. 

Thanks,
Natarajan



From list@netscape.com  Wed Jun 21 07:28:33 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26570
	for <ldapext-archive@odin.ietf.org>; Wed, 21 Jun 2000 07:28:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5LBJMg11116;
	Wed, 21 Jun 2000 04:19:23 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5LBR6g13363;
	Wed, 21 Jun 2000 04:27:06 -0700 (PDT)
Resent-Date: Wed, 21 Jun 2000 04:27:06 -0700 (PDT)
Sender: jch@pwd.hp.com
Message-ID: <3950A674.B9354841@pwd.hp.com>
Date: Wed, 21 Jun 2000 12:26:44 +0100
From: John Haxby <jch@pwd.hp.com>
Organization: OpenMail R&D
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kurt@openldap.org
Cc: mcs@netscape.com, DSTECK@novell.com, ietf-ldapext@netscape.com
Subject: Re: ldap_err2string format
References: <3.0.5.32.20000617200449.009554f0@infidel.boolean.net> <H0000229088f8b7b.0961437203.hpopd.pwd.hp.com@MHS>
Content-Type: multipart/mixed;
 boundary="------------64982A42F4AE9150090CDE35"
Resent-Message-ID: <"xEBjcC.A.TQD.JaKU5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multi-part message in MIME format.
--------------64982A42F4AE9150090CDE35
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kurt@OpenLDAP.org wrote:

> >If an implementation returns a pointer to static,
> >readonly data or to thread specific data, ldap_err2string() should be
> >thread safe).
>
> strerror() is not thread safe because it allows the implementation
> to dynamically create the string in the static, readonly (to caller)
> space, e.g: "unknown error (666)".  Same would follow for
> ldap_err2string().

A thread-safe strerror() (or ldap_err2string()) would require that the
"static" string is store in thread-specific storage.

For strerror(), some platforms provide a strerror_r() that takes a buffer as
parameter, other platforms -- like HP/UX 11 -- use thread-specific storage.

I would have thought that the nature of the LDAP API would make using
thread-specific storage for ldap_err2string() somewhat attractive.  On the
other hand, I recently discovered that pthread_key_create() (which is what
is used to create this stuff) fails on AIX 4.2 and earlier... so perhaps
ldap_err2string() should simply take a buffer as an extra parameter.

jch

--------------64982A42F4AE9150090CDE35
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Haxby;John
tel;fax:+44 1344 763686
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:https://ecardfile.com/id/jch
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/00/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:john_haxby@hp.com
x-mozilla-cpt:;-11552
fn:John Haxby
end:vcard

--------------64982A42F4AE9150090CDE35--



From list@netscape.com  Wed Jun 21 11:04:29 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03595
	for <ldapext-archive@odin.ietf.org>; Wed, 21 Jun 2000 11:04:28 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5LEweX00027;
	Wed, 21 Jun 2000 07:58:40 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5LF2vI14205;
	Wed, 21 Jun 2000 08:02:57 -0700 (PDT)
Resent-Date: Wed, 21 Jun 2000 08:02:57 -0700 (PDT)
Message-ID: <979695BB8922D411A54000D0B74C60B50F1BC7@sottmxsdev.entrust.com>
From: Kristianne Leclair <kristianne.leclair@entrust.com>
To: "'Kurt D. Zeilenga'" <Kurt@openldap.org>, ietf-ldapext@netscape.com
Subject: RE: compare result codes
Date: Wed, 21 Jun 2000 11:02:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"ynpk4.A.odD.gkNU5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

comments below...

> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> I've been reviewing the BLITS compare tests and had a couple
> of questions regarding the proper result code to return
> upon certain conditions:

> 1) unknown attribute type
> 2) compare known attribute type without defined equality matching rule
> 3) not present attribute type with asserted value of invalid syntax
> 4) not present attribute type with asserted value of valid syntax
> 5) present attribute type with asserted value of invalid syntax
> 6) present attribute type with asserted value of valid syntax
>    and attribute without asserted value
> 7) present attribute with asserted value of valid syntax
>    and attribute with value

> What result code is appropriate for each case?

> Here are my initial thoughts:

> 1) undefinedAttributeType
> 2) inappropriateMatching
Agreed. Currently the rescodes doc doesn't have this listed as a possible
error for compare. This will have to be updated.

> 3) noSuchAttribute (syntax not relevant in this case)
> 4) noSuchAttribute
> 5) invalidAttributeSyntax
I'm not sure whether this would be invalidAttributeSyntax, I would have said
compareFalse.  It depends on exactly how you read the definition of
invalidAttributeSyntax; the key phrase is 'specified as an argument of the
operation'. The only operations where the attribute value is specifically an
argument of the operation are Add and Modify. Now this is really splitting
hairs here but we don't include this as an error for search either.

When a search filter is evaluated the attribute must be known and the value
must conform to the syntax for the attribute. If both conditions are not met
the filter is undefined and evaluates to false -- no error is returned if
the attribute syntax is incorrect. 

> 6) compareFalse
> 7) compareTrue

> This usage is fairly consistent with X.511, 12.4.
>   "An attributeError reports an attribute-related problem."

>    a)	noSuchAttributeOrValue - The named entry lacks one of the
> 	attributes or attribute values specified as an argument
> 	of the operation.
>    b)	invalidAttributeSyntax - A purported attribute value, specified
> 	as an argument of the operation, does not conform to the attribute
> 	syntax of the attribute type.
>    c)	undefinedAttributeType - An undefined attribute type was provided
> 	as an argument to the operation. This error may occur only in
> 	relation to addEntry or modifyEntry operations.
>    d)	inappropriateMatching - An attempt was made, e.g. in a filter,
> 	to use a matching rule not defined for the attribute type concerned.


> excepting that c) specifically says the error may only occur in
> relation to addEntry or modifyEntry operations.  Now, one could
> return noSuchAttribute(OrValue), but this seems inappropriate
> as it implies able to determine the entry doesn't contain the
> attribute type... which implies the attribute type is defined...
> which it isn't.
As I see it, the compare operation simply answers the question 'does the
entry contain an attribute with this name and this value?', I don't think it
matters whether the attribute is defined or not (I guess this really depends
on how the server goes about checking this though). 

It would be nice, though, to know if the attribute is even defined -- for
example if I have made a mistake typing the attribute name it would be nice
to get a more specific error than noSuchAttribute (especially since I could
also be using a common attribute alias that the server simply isn't aware
of). However, since X.511 is so very explicit in the case of
undefinedAttributeType I'm not sure we should change this behaviour. I think
we've restricted changes in our document to result codes where there are
ambiguities or conflicting uses (as in the case of operationsError). 

> Maybe a clarification to X.511 is in order to either:
> 	A) change c) above to allow return by compare
> 	B) clarifiy which result codes should be returned
> 	in the cases listed above.

> Maybe this could be done for LDAP in the rescodes I-D.
The LDAP rescodes doc already has some examples for compare but it is
missing some of the examples that you have provided above, I think these
should be added. 
-Kristianne

> Kurt




From list@netscape.com  Thu Jun 22 10:17:59 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06594
	for <ldapext-archive@odin.ietf.org>; Thu, 22 Jun 2000 10:17:58 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5ME8Zg16885;
	Thu, 22 Jun 2000 07:08:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5MEGKU03887;
	Thu, 22 Jun 2000 07:16:20 -0700 (PDT)
Resent-Date: Thu, 22 Jun 2000 07:16:20 -0700 (PDT)
Message-Id: <200006221416.e5MEG2k12047@xwing.netscape.com>
From: <ems601@mailcity.com>
Subject: Targeted Lists at the lowest prices!
Date: Thu, 22 Jun 2000 05:39:59
Resent-Message-ID: <"OTi3k.A.37.x-hU5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

  *******New List TODAY!!*********                                
      
The key to success in marketing online is reaching the people who 
are really interested in your ad! 

You need targeted e-mails of business opportunity seekers
who are ACTIVELY marketing online and trying to expand their
business TODAY!

These are going to be the lowest prices for deliverable, fresh,
opportunity seekers you are going to find anywhere! We strive to 
clean our lists on a DAILY basis!  

http://www.homepagez.com/key1

 10,000 opportunity seekers e-mails for only $15
**New List 6-22-00**
 25,000 opportunity seekers e-mails for only $20
 50,000 opportunity seekers e-mails for only $35
100,000 opportunity seekers e-mails for only $50
150,000 opportunity seekers e-mails for only $70

- Promotions!

**FREE with each order, demo of ListMan e-mail manager software to 
manage your e-mails list.  Easily splits large lists into smaller 
files.  

**Order 50,000 or more e-mails and receive Express Mail Server to 
send your e-mails FREE!  
-Send your e-mails safely bypassing your ISP's mail server!
-This is not a demo but a permanent license for the software!

**Order 100,000 or more e-mails and receive Credit Helper with 
FREE Links to Guaranteed Visa's and MC's, CheckMAN software to 
accept checks online, by phone, or fax, and InfoDisk  with 1000+ 
Money Making Reports. An $80 value yours FREE!
_______________________________________________________________
I received your e-mail as someone interested in Internet Business 
Opportunities. If I received your e-mail in error, or you are no 
longer interested, please reply with "remove" in the subject.
_________________________________________________________________
 
 
 
 
 
 
 



From list@netscape.com  Thu Jun 22 19:08:23 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17107
	for <ldapext-archive@odin.ietf.org>; Thu, 22 Jun 2000 19:08:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5MMwog04348;
	Thu, 22 Jun 2000 15:58:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5MN1jc28325;
	Thu, 22 Jun 2000 16:01:45 -0700 (PDT)
Resent-Date: Thu, 22 Jun 2000 16:01:45 -0700 (PDT)
Message-Id: <4.3.2.7.2.20000623005615.024457c8@dokka.kvatro.no>
X-Sender: hta@dokka.maxware.no
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 23 Jun 2000 00:57:53 +0200
To: ietf-ldapext@netscape.com
From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
Subject: Implementations of RFC 2829 LDAP security?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"VOloAB.A.T1G.JrpU5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi,
as part of an article i'm writing, it would be nice to know:

does anyone ship product, or has soon-to-ship product, that implements
all parts of RFC 2829 LDAP security - that is, both DIGEST and STARTTLS?

Client, server, API or other?

                            Harald (in the curious mood)

--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no



From list@netscape.com  Fri Jun 23 05:29:54 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05852
	for <ldapext-archive@odin.ietf.org>; Fri, 23 Jun 2000 05:29:53 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5N9OBX24979;
	Fri, 23 Jun 2000 02:24:12 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5N9SVs17624;
	Fri, 23 Jun 2000 02:28:31 -0700 (PDT)
Resent-Date: Fri, 23 Jun 2000 02:28:31 -0700 (PDT)
Date: Fri, 23 Jun 2000 02:28:18 -0700 (PDT)
Message-Id: <200006230928.e5N9SIx14262@ywing.netscape.com>
From: "Dr. Gary" <gary34@hotmail.com>
To: @netscape.com
Subject:  Buy HEALTH SUPPLEMENTS & supplies at  WHOLESALE COST!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"Msf3i.A.1SE.92yU5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

If you are not interest.... just delete this message NOW
You will never be sent another message from me... EVER
       
    THIS IS BEING SENT TO YOU SO YOU CAN AFFORD TO 
           IMPROVE YOUR HEALTH AND SAVE MONEY!

I'm currently saving about 50% over what I was paying for 
Items at the current health food stores and supermarkets 

Search out any health related questions with the links to the 
Mayo Clinic and the U.S. Library of Health sites in this 
      	HEALTH SHOPPERS MALL SITE

Over 50 different stores all at one web address

Also look for their FREE INTERNET SERVICE which will be added 
to the web site in a few weeks. 

Tell your friends and the people you know that are in need of 
saving money not only on their HEALTH NEEDS but who would 
also like to have FREE INTERNET SERVICE. 

	THE WEB SITE ADDRESS IS: 

	 www.garyp.bigsmart.com  

Check out the links to other shopping sites also. 





From list@netscape.com  Fri Jun 23 11:49:23 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13398
	for <ldapext-archive@odin.ietf.org>; Fri, 23 Jun 2000 11:49:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5NFe6g16803;
	Fri, 23 Jun 2000 08:40:06 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5NFlro22323;
	Fri, 23 Jun 2000 08:47:53 -0700 (PDT)
Resent-Date: Fri, 23 Jun 2000 08:47:53 -0700 (PDT)
Message-ID: <B7EE5F06DEEBD3118EA000C04F01A360447266@www.aztec.soft.net>
From: Natarajan S K <sknatarajan@aztec.soft.net>
To: ietf-ldapext@netscape.com
Subject: draft-ldapext-cachedresults-00.txt
Date: Fri, 23 Jun 2000 21:18:39 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BFDD2A.80D38918"
Resent-Message-ID: <"gIoudD.A.8bF.na4U5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFDD2A.80D38918
Content-Type: text/plain;
	charset="iso-8859-1"

Hi, 
      I am attaching a draft on "Caching model for LDAP". Appreciate if you
can review it and get back with possible comments. 

Thanks,
Natarajan




>  <<cache.txt.txt>> 

------_=_NextPart_000_01BFDD2A.80D38918
Content-Type: text/plain;
	name="cache.txt.txt"
Content-Disposition: attachment;
	filename="cache.txt.txt"
Content-Transfer-Encoding: quoted-printable

IETF LDAPEXT Working Group				S.K. Natarajan
Internet Draft						Aztec Software
Document: draft-ldapext-cachedresults-00.txt	  =20
Category: Informational					G. Vithalprasad
Date: June 2000 				    	Novell Inc.
Expires: December 2000
							 T. Kannan
							 Novell Inc.

			The LDAP Caching model


    Status of this Memo

    This document is an Internet-Draft and is in full conformance with =
all=20
    provisions of Section 10 of RFC2026 [ ].=20

    Internet-Drafts are working documents of the Internet Engineering =
Task=20
    Force (IETF), its areas, and its working groups. Note that other =
groups=20
    may also distribute working documents as Internet-Drafts. Internet-
    Drafts are draft documents valid for a maximum of six months and =
may be=20
    updated, replaced, or obsoleted by other documents at any time. It =
is
    inappropriate to use Internet- Drafts as reference material or to=20
    cite them other than as "work in progress."=20
    The list of current Internet-Drafts can be accessed at=20
    http://www.ietf.org/ietf/1id-abstracts.txt=20
    The list of Internet-Draft Shadow Directories can be accessed at=20
    http://www.ietf.org/shadow.html.



    1. Abstract

    Seeking entries from a directory is a process involving network=20
    resources. It is assumed that a directory is accessed for reading =
and=20
    searching data more than for modification purposes. Under such=20
    assumptions, for performance reasons, a mechanism for caching as a=20
    proxy  which caches all entries is desirable. This document =
describes
    a mechanism for caching directory entries.=20
    This document also defines one operational attribute and two =
controls
    required to be implemented for the caching model.

    2. Conventions used in this document


    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =

    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in =
this=20
    document are to be interpreted as described in RFC-2119 [ ].


    3. Introduction

    LDAP performance would receive a boost if a caching mechanism were=20
    available to cache entries so the network resources used for=20
    retrieving entries wouldn't be used as much as they will otherwise. =

    This goes well with the philosophy that LDAP directories are mostly =

    read and searched than modified. Entries can be cached with the =
safe=20
    assumption that they will not be modified very often which would =
lead=20
    to better performance. This draft shall confine itself to a =
discussion=20
    on caching ldap search results alone.

    4. Attribute definition
    This draft defines a rootDSE operational attribute which identifies =

    the DIT of which the server holds a replica.=20

    ditName : ( <OID_to_be decided> NAME 'ditName'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )

    5. Controls used for caching results
   =20
=09
    5.1 The originServerbind Control

   The originServerbind control defines a control using which a client=20
   which is routing its requests through a proxy can mention what =
origin
   server it needs to contact and the credentials to bind as.=20

    5.1.1 Request control

    This control is included in the bindRequest message as part of the=20
    controls field of the LDAPMessage, as defined in Section 4.1.12 of  =

    Lightweight Directory Access Protocol[LDAPv3]. The controlType is =
set
    to <OID to be assigned>. The criticality MAY be set to TRUE or =
FALSE=20
    in the absence of which  the criticality is defaulted to be FALSE.=20
    The ControlValue is an OCTET STRING whose value is the BER encoding =

    of the following SEQUENCE.

	OriginServerbindRequest ::=3D SEQUENCE {
     serverName    LDAPString -- server name or IP addr.
     serverPort    INTEGER -- the port number
     bindRequest   BindRequest OPTIONAL
	}
    The serverName is the name or the IP address of the origin LDAP =
server.
    If it is a name, it should include the domain name so that the =
server=20
    is uniquely identified by the serverName in the Internet space.
    The serverPort represents the port on which the origin LDAP server=20
    is running.The bindRequest contains the userDN and credentials =
using
    which bind can be performed on the origin server. It is as defined =
in
    4.2 of Lightweight Directory Access Protocol [LDAPV3].

    5.1.2 Response Control
	   The controlType is set to < To be decided >. The criticality is=20
        FALSE (MAY be absent). The controlValue is an OCTET STRING, =
whose=20
        value is the BER encoding of a value of the following SEQUENCE:

        originServerbindResponse :: =3D SEQUENCE {
        originServerbindResult ENUMERATED{
        success (0),
        operatonsError (1),
        strongAuthRequired(8),=20
        unwillingToPerform (53),
        insufficientAccessRights (50),
        busy (51),
        inappropriateMatching (18),
        timeLimitExceeded (3),
        offsetRangeError (61),
        other (80) },
        contextID OCTET STRING OPTIONAL }

    contextID is a server-defined octet string. If present, the =
contents=20
    of the contextID field  SHOULD be returned to the server by a =
client=20
    in a subsequent originServerbind control request.=20


    This control also determines the origin server to which the client=20
    wants to connect and the cache agent MUST make use of this=20
    information to connect to the origin server. In absence of the=20
    bindRequest entity, the information with which client sends across =
in=20
    its bind request to the caching agent SHOULD be used to connect to=20
    the origin server.

    The result of the control shall determine whether the origin server =

    can be contacted or not. If the origin server is not contactible, =
the=20
    proxy SHOULD  return operationsError. Based on that the client can=20
    make a decision as to whether the cached results be made use of or =
not.

    5.2 Cached Search control

     The document also defines the cachedResults control which =
specifies=20
    whether the searches can be retrieved from the cache or it must =
needs=20
    be retrieved directly from the target server.=20

    5.2.1 Request Control

   This control is included in the searchRequest message as part of the =
=20
    controls field of the LDAPMessage, as defined in Section 4.1.12 of=20
    Lightweight Directory Access Protocol [LDAPv3]. The controlType is=20
    set to <OID to be assigned>. The criticality MAY be set to TRUE or=20
    FALSE in the absence of which the criticality is defaulted to be=20
    FALSE. The ControlValue is NULL.=20
  =20
   5.2.2 Response Control :

   The controlType is set to <To be decided>. The criticality is
   FALSE (MAY be absent). The controlValue is an OCTET STRING, whose
   value is the BER encoding of a value of the following SEQUENCE:

   cacheResultResponse :: =3D SEQUENCE {
   cacheResult ENUMERATED{
   success (0),
   operatonsError (1),
   strongAuthRequired(8),=20
   unwillingToPerform (53),
   insufficientAccessRights (50),
   busy (51),
   inappropriateMatching (18),
   timeLimitExceeded (3),
   offsetRangeError (61),
   other (80) },
   targetServerResponse ENUMERATED
    {
	originNotresponding  (0), --origin server closed connection
	allFromCache	     (1), -- all info from cache
	allFromorigin	     (2), -- all info from origin=09
	partial		     (3), -- partially from either=09
	}  =20

        contextID OCTET STRING OPTIONAL }

    contextID is a server-defined octet string. If present, the =
contents=20
    of the contextID field  SHOULD be returned to the server by a =
client=20
    in a subsequent cacheResult control.=20

    targetServerResponse is used to determine whether the response is=20
    fully from the caching agent, fully from the origin server or =
partly=20
    from the cache and partly from the origin server. The=20
    originNotresponding entity functions to see that the client is=20
    informed if midway through the operation, the origin server goes =
down=20
    or is inaccessible.

      The caching agent will find whether the criticality of the =
control=20
    is TRUE or FALSE. If the criticality is FALSE, it will execute the=20
    operation as described above. If the criticality is TRUE, it will=20
    strip away the control and send across the request to the desired=20
    server.


    6. The LDAP caching model

    An LDAP search request consists primarily of sending a filter to a
    particular server and getting all the entries which match that =
filter=20
    along with some or all of their attributes.  The query can be on=20
    multiple servers holding the same DIT or multiple servers holding=20
    multiple DITs. The model assumes an active proxy agent or caching=20
    agent which shall intercept the client request and the server=20
    response and shall, based on configuration options, decide whether =
to=20
    cache the entries or not. The rest of the draft assumes that=20
    configuration options are such that the requests from the client =
are=20
    deemed cacheable unless explicitly mentioned otherwise. =
Configuration =20
    options are discussed later in this draft.

    The caching agent shall intercept the LDAP search request from the=20
    client and look up the server to which the request is being sent. =
It=20
    shall send the request to the server and simultaneously query the=20
    server for its ditName  operational attribute. The response from =
the=20
    server shall be accepted by the proxy agent and sent to the client. =

    The agent shall group all the entries under a container which shall =

    be identified by the ditName and shall conceptually represent that=20
    DIT. Under this DIT container the entry shall be created with all =
the=20
    hierarchy intact. Thus if a user entry which exists some levels =
down=20
    the DIT root is returned, the agent would create the entry after=20
    creating all the containers under which the entry exists in that =
order.
    Along with this request, the agent shall query for the =
modifyTimestamp=20
    operational attribute of all the objects retrieved and store them =
for
    caching reference. For the caching model to work, the =
modifyTimestamp=20
    attribute of the objects retrieved needs to be accessible to the=20
    caching agent. This can be provided either through binding as an=20
    entry which has access to the modifyTimestamp   attribute or by=20
    allowing anonymous access to the same.   The agent may make =
successive=20
    requests to the containers along with their which  contain the =
entry=20
    to get the data for the containers and store them for future =
reference.=20
    Subsequent searches shall involve a query of the modifyTimeStamp=20
    attribute of the objects returnable by the filter and the DNs =
returned=20
    shall be matched with the objects already available in the cache.=20
    There are three cases of what could happen and the corresponding=20
    actions to be taken.

    i)	If the objects are all available in the cache and the=20
        modifyTimestamp of all the objects are the same as the=20
        modifyTimestamp of the objects in the cache, then the cached=20
        objects are returned.

    ii)	If the objects are all available in the cache and the=20
        modifyTimestamp of some of the objects are greater then what=20
        exists in the cache, then a base search for those objects will =
be
        performed along with the filter specified and those entries =
shall=20
        be returned. Simultaneously the cache shall also be updated to=20
        reflect these changes. The modifyTimestamp of these objects =
shall
        also be modified in the cache accordingly.=20


    iii) If the objects are not all available in the cache, fresh       =
    =20
         base searches shall be made for the objects not available=20
         in the cache. These shall be cached along with their=20
         modifyTimestamp attributes.

    If the number of changed or non-present objects are more than the=20
    number of unchanged objects, the cache agent  MAY choose to execute =
a=20
    fresh search of the DIT using the filter.


    7. Access controls

    Depending on the configuration of the proxy, it MAY cache Access=20
    Control Information for the bindDN on the list of objects returned=20
    using the ldapGetEffectiveRights extension as defined in [ACL].=20
    Subsequent requests for the object data shall be returned depending =
on=20
    the access rights to the list of objects returned. If the ACL=20
    information for different subject DNs are not cached or access to=20
    the ACL information is denied, the agent MUST cache only anonymous=20
    bind results.
	If the search is a non-anonymous one having a pertinent bind=20
    entity, the ACLs corresponding to that subject should be cached. =20
    Subsequent searches by the same entity in further sessions MUST be=20
    authenticated either to the origin server or the cache before =
results=20
    are returned from either the cache or the origin server. Subsequent =

    drafts will define authentication mechanisms in a cache.

    8. Configuration options

    The configuration options can be:

    i) All the entries need to be cached.

   ii) None of the entries need to be cached.

  iii) Entries under a particular DN need to be cached. In this case, =
if=20
       the search request does not pertain to entries under the DN or=20
       pertains partly to entries under the DN, the request will become =
a
       regular search request.

   Other complex configuration options can also be provided.

    9. Diverse schema=20

    The basic LDAP Schema SHOULD be supported by the proxy server.=20
    Additional attributes and object classes may be supported. Schema=20
    changes to the parent directory may be "learnt" by the cache agent=20
    and implemented. If the request returns any entries the schema of=20
    which is not recognised by the cache, it may try to learn the =
schema=20
    using subschema search mechanisms. However if it does not learn the =

    schema, the non-recognised entries MUST NOT be cached.
=20

    10. Operation in disconnected mode

    The cached results can also help provide information when the =
origin=20
    server is not up. In this case, when the origin server is not =
running,=20
    i.e. when the caching agent cannot connect to the origin server, =
the=20
    client can use the cacheResult control to get the information from =
the
    cache and make use of it.=20

    11. Security Considerations

    Security would be a chief issue if Access Controls were retrieved =
and=20
    cached. The cache agent would have to adhere to access restrictions =

    placed on the objects and their attributes. In particular, if a=20
    subject binds as an entity granted more privileges, then the ACLs =
of=20
    that entity need to be cached and based on that ACI, the search =
results=20
    need to be serviced. Further drafts may expound the principle of=20
    retrieving and caching ACI probably based on ldapGetEffectiveRights =

    extension or using the getEffectiveRights control [ACLs].=20
    However a restricted access i.e. =
don=92t-allow-access-unless-absolutely-
    sure mechanism is to be followed if determinacy is not accurate as =
to=20
    whether a subject can be allowed or denied access to an entity.



    12. References

      [ACL]
       E. Stokes, D. Byrne, B. Blakley, "Access Control Model for LDAP"
     March, 2000.=20

      [LDAPv3]
      Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access=20
        Protocol (v3)", RFC 2251, December, 1997.=20

      [Bradner97]
      Bradner, Scott, "Key Words for use in RFCs to Indicate =
Requirement
      Levels", RFC 2119, March, 1997.=20

      [SyntaxDef]
      Wahl, M, Coulbeck A, S. Kille and T. Howes, "Lightweight =
Directory=20
        Access Protocol (v3): Attribute Syntax Definitions", RFC 2252,=20
        December, 1997.
=20




    13. Author's Addresses

    Natarajan SK
    Aztec Software
    23, 3rd A cross
    18th main, 6th block
    Koramangala
    Bangalore-95
    Phone:91-80-5537513
    Email:sknatarajan@aztec.soft.net


    Vithalprasad G.
    Novell Software
    7th mile, Hosur road
    Bangalore-68
    Phone:91-80-5537513
    Email : gvithalprasad@novell.com

    Kannan T
    Novell Software
    7th mile Hosur Road,
    Bangalore-68
    Email: tkannan@novell.com

    Comments can be sent to  any of the authors at their e-mail ids or =
to=20
    the ldapext mailing group.

    Expires:December 2000

------_=_NextPart_000_01BFDD2A.80D38918--



From list@netscape.com  Fri Jun 23 12:52:17 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14959
	for <ldapext-archive@odin.ietf.org>; Fri, 23 Jun 2000 12:52:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5NGgsg24615;
	Fri, 23 Jun 2000 09:42:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5NGogE28582;
	Fri, 23 Jun 2000 09:50:42 -0700 (PDT)
Resent-Date: Fri, 23 Jun 2000 09:50:42 -0700 (PDT)
Date: Fri, 23 Jun 2000 11:49:12 -0500
From: Mark Wahl <M.Wahl@innosoft.com>
Subject: Re: draft-ldapext-cachedresults-00.txt
In-reply-to: "Your message of Fri, 23 Jun 2000 21:18:39 +0530."
 <B7EE5F06DEEBD3118EA000C04F01A360447266@www.aztec.soft.net>
Sender: wahl@austin.innosoft.com
To: Natarajan S K <sknatarajan@aztec.soft.net>
Cc: ietf-ldapext@netscape.com
Message-id: <4790.961778952@threadgill.austin.innosoft.com>
Resent-Message-ID: <"_PZfPB.A.R-G.hV5U5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Natarajan,

If you have not already done so, could you submit your document to the 
Internet Drafts archive.

Thanks in advance,

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance



From list@netscape.com  Fri Jun 23 18:19:21 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21195
	for <ldapext-archive@odin.ietf.org>; Fri, 23 Jun 2000 18:19:21 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5NMA5g10813;
	Fri, 23 Jun 2000 15:10:05 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5NMHrw04139;
	Fri, 23 Jun 2000 15:17:53 -0700 (PDT)
Resent-Date: Fri, 23 Jun 2000 15:17:53 -0700 (PDT)
Message-Id: <3.0.5.32.20000623151734.00963600@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 23 Jun 2000 15:17:34 -0700
To: Kristianne Leclair <kristianne.leclair@entrust.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: RE: compare result codes
Cc: ietf-ldapext@netscape.com
In-Reply-To: <979695BB8922D411A54000D0B74C60B50F1BC7@sottmxsdev.entrust.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"FEfvy.A.WAB.PI-U5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:02 AM 6/21/00 -0400, Kristianne Leclair wrote:
>> 1) undefinedAttributeType
>> 2) inappropriateMatching
>Agreed. Currently the rescodes doc doesn't have this listed as a possible
>error for compare. This will have to be updated.

It's X.511 that actually needs updating.... or we need to
do something about that MUST X.511 in RFC 2251.

>> 3) noSuchAttribute (syntax not relevant in this case)
>> 4) noSuchAttribute
>> 5) invalidAttributeSyntax
>I'm not sure whether this would be invalidAttributeSyntax, I would have said
>compareFalse.  It depends on exactly how you read the definition of
>invalidAttributeSyntax; the key phrase is 'specified as an argument of the
>operation'. The only operations where the attribute value is specifically an
>argument of the operation are Add and Modify.

I feel it should apply to value of an attribute value assertion which
is an argument to a compare operation.  
>Now this is really splitting
>hairs here but we don't include this as an error for search either.

Guess you could split hairs over whether or not the value of an
attribute value assertion is an attribute value or not... but I
rather just clarify X.511 (and hence LDAPv3) that this result
code can (and should) be returned in this case.

>When a search filter is evaluated the attribute must be known and the value
>must conform to the syntax for the attribute. If both conditions are not met
>the filter is undefined and evaluates to false -- no error is returned if
>the attribute syntax is incorrect. 

Yes, but a compare, unlike search, should return an error instead
of applying three value logic to the assertion. 


>As I see it, the compare operation simply answers the question 'does the
>entry contain an attribute with this name and this value?', I don't think it
>matters whether the attribute is defined or not (I guess this really depends
>on how the server goes about checking this though). 

As I see it, compare provides key functional that cannot be
mimiced with search.  In particular, compare returns the reason
the assertion, if used in a search filter, would be undefined.

Kurt



From list@netscape.com  Fri Jun 23 23:35:16 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27125
	for <ldapext-archive@odin.ietf.org>; Fri, 23 Jun 2000 23:35:16 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5O3Png09951;
	Fri, 23 Jun 2000 20:25:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5O3XcE08725;
	Fri, 23 Jun 2000 20:33:38 -0700 (PDT)
Resent-Date: Fri, 23 Jun 2000 20:33:38 -0700 (PDT)
Message-Id: <3.0.5.32.20000623203238.009b24f0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 23 Jun 2000 20:32:38 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: draft-ietf-ldapext-locate-02 and UDP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"FGImkD.A.-HC.QwCV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Another last call comment...

Section 4 states that the protocol can be either "udp" or "tcp".
It is unclear to me whether this I-D is intended "udp" <Proto> 
is to be used to locate CLDAPv2 (RFC1798) services or to locate
CLDAPv3 (draft-ietf-ldapext-cldap-00) or was just an alias
for "tcp".

As LDAP (RFC1777/RFC2251) does not provide a specification for
LDAP over UDP, this proposal should not provide location of
services operating over UDP.  

I suggest that
	<Proto> is a protocol that can be either "udp" or "tcp"

be replaced with:
	<Proto> is "tcp" or other transfer protocol (RFC2251, 5.2)

and that location of CLDAP be left to future CLDAP specifications
(which, if appropriate, may update this specification).



From list@netscape.com  Sat Jun 24 01:17:49 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29825
	for <ldapext-archive@odin.ietf.org>; Sat, 24 Jun 2000 01:17:48 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5O58Og14556;
	Fri, 23 Jun 2000 22:08:24 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5O5GDQ00221;
	Fri, 23 Jun 2000 22:16:13 -0700 (PDT)
Resent-Date: Fri, 23 Jun 2000 22:16:13 -0700 (PDT)
Date: Fri, 23 Jun 2000 22:15:54 -0700 (PDT)
Message-Id: <200006240515.e5O5Frx26609@ywing.netscape.com>
From: abc1958670@KXQT.yahoo.com
To: Business@ywing.netscape.com, Opportunity@ywing.netscape.com,
        Seekers!!@netscape.com
Subject:  JOIN For FREE!!  Join An EXPLODING Internet Business!  $Email
X-Reply-To:  joe_hill961@yahoo.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"bBlMRC.A.4C.cQEV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Don't Let This Opportunity Pass You By

CHECK IT OUT! IT'S FREE! 

An Internet Business Opportunity that Utilizes 
the Power of Wholesale Discounted Online Shopping!!

750-1000 Members Each Month! 

ALL new members that come into the club 
COMPANY WIDE will go under YOU. 

A true VERTICAL downline. 
GUARANTEED minimum commissions every month!! 

Watch your Business grow BEFORE you spend a Dime!
FREE Membership gives you deep discounts at over 
80 Brand Name Online stores and entry to our monthly 
$100 shopping spree! 

To join our FREE postlaunch program 
Please sign up at:
http://www.50megs.com/users1/joehill960


___________________________________________________________________________________
This is a one Time Message.  If You wish to be removed from our list, please reply with a remove in the 
subject line of your message.




From list@netscape.com  Sat Jun 24 08:45:35 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12303
	for <ldapext-archive@odin.ietf.org>; Sat, 24 Jun 2000 08:45:34 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5OCdjX21758;
	Sat, 24 Jun 2000 05:39:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5OCi6211176;
	Sat, 24 Jun 2000 05:44:06 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 05:44:06 -0700 (PDT)
Message-ID: <000030111a53$00005966$00006bb0@>
To: <Undisclosed.Recipients@xwing.netscape.com>
From: qlhliq7nahs@aol.com
Subject: Looking for a Great Home Based Business?
Date: Fri, 23 Jun 2000 21:59:03 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: AOL 5.0 for Windows sub 105
Resent-Message-ID: <"uREn0B.A.IuC.V0KV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Tired of the 40 X 40 X 40 Plan? You know: 

Work 40 hours per week for someone else for 40 years, then receive a 40% reduction in pay! 

Is working for a "boss" too demeaning and unrewarding? 

Are you sick of depending on a job with too little pay and too many hours with no personal reward and even less future?

If you're determined to retire in the next 2 - 5 years with enough income to have REAL Financial Independence and Freedom, and are not afraid to work for it, I can help you.

I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home!

NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success!

This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life!

If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN!

THIS IS NOT A GET-RICH-QUICK SCHEME!

YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!

CALL ONLY IF YOU ARE SERIOUS!

1-800-533-9350 (Free, 24 hour, 2 minute recorded message)

DON'T GO TO SLEEP WITHOUT LISTENING TO THIS!

"All our dreams can come true - if we have the courage to pursue them" - Walt Disney



To be removed from future mailings, send an email to:  Take_me_off_2_day5@yahoo.com and type "Remove" in the subject line.









Tired of the 40 X 40 X 40 Plan? You know: 




From list@netscape.com  Sat Jun 24 12:56:43 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13994
	for <ldapext-archive@odin.ietf.org>; Sat, 24 Jun 2000 12:56:42 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5OGotX00771;
	Sat, 24 Jun 2000 09:50:55 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5OGtIk20051;
	Sat, 24 Jun 2000 09:55:18 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 09:55:18 -0700 (PDT)
X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs
Date: Sat, 24 Jun 2000 09:55:23 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-Sender: rlmorgan@perq.cac.washington.edu
Reply-To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: "Kurt D. Zeilenga" <Kurt@openldap.org>
cc: ietf-ldapext@netscape.com
Subject: Re: draft-ietf-ldapext-locate-02 and UDP
In-Reply-To: <3.0.5.32.20000623203238.009b24f0@infidel.boolean.net>
Message-ID: <Pine.LNX.4.21.0006240930470.23348-100000@perq.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"p6ZwyD.A.84E.0fOV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


> Section 4 states that the protocol can be either "udp" or "tcp".
> It is unclear to me whether this I-D is intended "udp" <Proto> 
> is to be used to locate CLDAPv2 (RFC1798) services or to locate
> CLDAPv3 (draft-ietf-ldapext-cldap-00) or was just an alias
> for "tcp".
> 
> As LDAP (RFC1777/RFC2251) does not provide a specification for
> LDAP over UDP, this proposal should not provide location of
> services operating over UDP.  

I agree that this needs to be more clear but I'm not sure I agree with the
conclusion.

RFC 1798 is a Proposed Standard.  It seems reasonable to specify a means
to discover services that implement it, and seems obvious to do so using
"_ldap._udp" as the -locate- draft implies.  There is enough compatibility
between LDAPv2-over-TCP and LDAPv3-over-TCP that servers can reasonably do
both, so we're not motivated to specify something like "_ldapv3._tcp" as a
separate name.  The only reason I can think of for removing references to
UDP from this document, that is, for deciding to have the DNS SRV method
*not* apply to services conforming to RFC 1798, is that we think that RFC
1798 is technically flawed enough that CLDAPv3 is likely to be
incompatible with it, hence we're inclined to reserve "_ldap._udp" to
apply to CLDAPv3 implementations only.  Is that what you're asserting,
Kurt?  (Obviously we can't refer to CLDAPv3 in this doc since CLDAPv3 is
not done yet; and I don't think publication of -locate- wants to wait on
it.)

Otherwise, I suggest that the text be modified to say:

  The name of this record has the following format:

      _<Service>._<Proto>.<Domain>

   where <Service> is always "ldap", and <Proto> is a protocol that can
   be either "udp" or "tcp".  "_ldap._tcp" applies to services compatible
   with LDAPv2 [RFC1777] or LDAPv3 [1].  "_ldap._udp" applies to services
   compatible with CLDAP [RFC1798].

 - RL "Bob"




From list@netscape.com  Sat Jun 24 13:30:33 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14156
	for <ldapext-archive@odin.ietf.org>; Sat, 24 Jun 2000 13:30:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5OHLHg11347;
	Sat, 24 Jun 2000 10:21:17 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5OHT7I25918;
	Sat, 24 Jun 2000 10:29:07 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 10:29:07 -0700 (PDT)
Message-Id: <3.0.5.32.20000624102846.0095fea0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 24 Jun 2000 10:28:46 -0700
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: draft-ietf-ldapext-locate-02 and UDP
Cc: ietf-ldapext@netscape.com
In-Reply-To: <Pine.LNX.4.21.0006240930470.23348-100000@perq.cac.washingt
 on.edu>
References: <3.0.5.32.20000623203238.009b24f0@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"DEZAHB.A.nUG.i_OV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 09:55 AM 6/24/00 -0700, RL 'Bob' Morgan wrote:
>Is that what you're asserting, Kurt?

I'm simply asserting that CLDAP is not LDAP and I would prefer
that each protocol have separate specifications for service location.
This would allow specifications for each protocol to be developed
and progressed independently from each other.  I would hate to see
LDAP location service eventual progression to Draft Standard or
Standard held up due to lack of CLDAP maturity.



From list@netscape.com  Sat Jun 24 17:33:11 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15526
	for <ldapext-archive@odin.ietf.org>; Sat, 24 Jun 2000 17:33:11 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5OLRKX12463;
	Sat, 24 Jun 2000 14:27:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5OLVh605269;
	Sat, 24 Jun 2000 14:31:43 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 14:31:43 -0700 (PDT)
Date: Sat, 24 Jun 2000 14:31:40 -0700 (PDT)
Message-Id: <200006242131.e5OLVek24751@xwing.netscape.com>
From: apw32@hotmail.com
To: ietf-ldapext@netscape.com
Subject:  request for information
X-Reply-To:  apw32@hotmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"0y8Lf.A.-RB.-iSV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Recently you have requested information on a home-based business.

Are you tired of working your heart out for someone else who 
doesn't appreciate your efforts; sick of depending on a job with 
too little pay, too many hours, no personal freedom, and no 
future?

If you are willing to work, and are determined to succeed, I will 
introduce you to an extraordinary opportunity; one which will 
enable you to achieve financial independence within a few years.

This is NOT MLM or a get-rich-quick scheme (which usually don't 
work anyway). This business requires dedication, persistence, and 
an investment; and you can start by working as little as 2-hours a 
day.

No special skills are required. All the education, training, and 
(most important!) support is provided.

I was very skeptical at first, but now my eyes have been opened: 
If you could see what I have seen, if you could hear what I have 
heard, if you knew what I now know, you would crawl over broken 
glass to get there, and thank me for the favor.

For more details, call my voice-mail box at 800 320-9895 extension 
6758, then leave the requested information (first name, phone, and 
the best time to reach you) after the 2-minute message.

To be removed from future mailings, reply to this message with 
"Remove" in the subject line.




From list@netscape.com  Sat Jun 24 20:58:42 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16339
	for <ldapext-archive@odin.ietf.org>; Sat, 24 Jun 2000 20:58:42 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5P0nDg28789;
	Sat, 24 Jun 2000 17:49:13 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5P0v3Q08436;
	Sat, 24 Jun 2000 17:57:03 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 17:57:03 -0700 (PDT)
Date: Sun, 25 Jun 2000 08:50:19 +0800
From: trafficseeker@talk21.com
To: trafficseeker@talk21.com
Subject: ** Urgent Notification Bulletin **
X-PMFLAGS: URGENT Message
Comments: Authenticated Sender is <>
Message-Id: <34274882_47772498>
Resent-Message-ID: <"unmH-D.A.fDC.ejVV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


                   DIRECT ACCESS
                      E-ZINE!


 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

(C) http://directaccessgroup.com  June 24, 2000


   In This Issue...

*  Marketing Tip Of The Week: "People Do Judge Web Sites
   By Their Front Pages" By Jim Daniels


--------------- IN THE SPOTLIGHT ---------------

Right now, as we speak, your competitors are taking your
best prospects right out from under you. "Discover How to
Take Back Your Lost Profits by Legally & Ethically Getting
TOP Rankings in MILLIONS of the Major Search Engines,
directories and FREE for all link sites." We'll show you
how to automatically generate a tidal wave of traffic to
your website - and boost your sales  like never before.

http://www.directaccessgroup.com/ 

------------- END SPOTLIGHT MESSAGE -------------


*** MARKETING TIP OF THE WEEK! ***

"People Do Judge Web Sites By Their Front Pages"

A successful Web site is an extremely effective sales tool
since it has the ability to gain the attention of a captive
audience. Like all direct response marketing processes, it
must first hook a reader's attention and then move them to
take some action. However, when the mechanics of that very
first page are ignored, it often causes visitors to click
out of a site from the moment they arrive. And such Web
sites, although some of which get a large number of hits,
never seem to produce the anticipated level of response let
alone deeper traffic.

With just a few changes, you can turn your Web site into a
more compelling and effective sales tool. Remember that,
every single day, your customers are bombarded with a
continuous flow of information and marketing messages, and
that competition for their attention is exceedingly fierce.
A Web site that captures their attention and stays active in
your customer's mind will not only have them visit deeper
into your site and generate sales but also have them visit
your site again and again as well as refer your site to
others.

Here are some basic rules to follow when designing a front
page:


Be Focused

Target your market! As the adage goes, "You can not be all
things to all people." You can, however, position your site
effectively to meet the needs of a specific group. It's a
paradox but you will indeed get more with less. This means
understanding who your customers/visitors are and what
motivates their buying decisions. Therefore, do your
homework. Know your customer. Appeal to their specific needs
and psyche. Focus like a laser on your niche, and your site
will burn into their minds.

Web sites centered on a very narrow theme or idea will
create visitors of greater interest, and especially leads
that are much more pre-qualified and apt to buy. Look at it
this way: When you narrow down your message and focus on a
niche, visitors will be 50% sold the minute they hit your
site's first page. Then, it is up to your content (copy,
offer, and call-to-action) to take them through the
remaining 50%.

Niche marketing on the Web is particularly important since
people do not have the time to sift through an entire site
-- let alone a search engine or even the Internet -- to find
exactly that for which they are looking. If your site is
unique, highly specialized, and focused however, people will
be inclined to surf deeper into your site once they hit the
first page.

If you cater to a particular audience, it will then be easier
for your first page to lead visitors to a successful outcome
because, once they hit your site, they are pre-qualified.


Be Specific

Answer this skill-testing question: "What exactly do you
want your visitors to do?" Simple, isn't it? But it doesn't
seem that way with the many sites I've visited. The KISS
principle (that's Keep It Simple and Straightforward) is
immensely important on online. An effective Web site starts
with smart planning and it must have a clear objective that
will lead to a specific action or outcome. If your site is
not meant to, say, sell a product, gain a customer, or
obtain an inquiry for more information, then what exactly
must it do? Work around the answer as specifically as
possible. In short, have a plan when you design your site's
front page.

Don't be vague and be specific. Is your Web site meant to be
like a resume or billboard that only advertises the fact
that you are "open for business"? It shouldn't, unless you
are intimately involved with that specific medium (i.e., you
are a Web designer or host, or in other words your site is
the product in itself). If not, is it to generate qualified
leads? Is it to sell a particular product? Are you trying to
persuade your visitors to switch from another company to
you? Do you want them to call you on the phone for more
information? Are you trying to have them subscribe to some
membership program? You get the picture.

The mind hates confusion. If you try to get your visitors to
do too many things, especially on the front page, they will
do nothing. However, if you want to offer a visitor a
variety of different options, then try to focus on one alone
and create a secondary page (or more) that are each
respective to a particular action, and then link them
together at the appropriate locations for flow. In essence,
keep your message focused. Do not try to communicate too
much -- you will overwhelm the reader. Use one major theme
and revolve your message around it.

Be Clear

When you are in the process of buying a book, for instance,
the one thing that has attracted you is the cover (if you're
not aware of the author beforehand, and even then the cover
plays a key role). If the proverb "Don't judge books by
their covers" exists, it is because we, as humans, have the
natural inclination to do so. Newspapers capitalize on that
intrinsic human behavior, which is why front-page headlines
and news articles are always carefully selected. In fact,
the most read part of a newspaper is not only the front page
but also the top section (or what is commonly referred as
"above the fold").

Therefore, the front page of your Web site is "the cover of
your book," so to speak. It should entice readers to surf
further into the site and not lead them to take action right
then and there (unless your web site is a single page). On
the front page, keep the written copy short (or its major
benefit "above the fold") and to the point, allowing the
reader to easily see what's in it for them. Use bold,
attention-grabbing headlines and subheadlines to emphasize
the major theme and the core benefit that your site offers.

In fact, list the benefits. Why should a visitor surf your
site? What's in it for him/her? In other words, focus on
communicating to the visitor the reasons why they should
browse further. A great technique for doing so is to use a
bulleted list of benefits (such as when it follows the words
"With this site, you get," "in this site, you will find," or
"here are the reasons why you should browse this site").

(this week's tip continued after this important message...)

------------- SPONSOR MESSAGE #1 -------------

Automatically promote your website to thousands 
of classified sites, link pages, search engines 
and directories...

Try the program the expert submitters are using.
Awarded 5 stars by ZDNET and 5 Cows by TUCOWS.
The highest award a shareware program can receive.

Try it for FREE right now.

http://www.directaccessgroup.com/software.html

------------- END SPONSOR MESSAGE -------------

(this week's tip continued...)

Bulleted benefit lists not only give a visual break for the
reader but are also effective since they are short,
to-the-point, and clustered for greater impact. Remember
that customers buy benefits not products. Therefore, your
first page should focus on the benefits of your web site and
not its features. It must give specific reasons for surfers
to venture further.

Present a problem and emphasize it. Focus on an existing gap
(the gap between a problem and its solution). And then show
what your web site brings to the table by telling your
visitors how, by surfing deeper, they will be able to fill
that gap. In other words, the first page must confirm that
there is a problem and how exactly you can solve it.


Be Simple

If your web site includes too much background, Javascript,
frames, plugins and dazzling but slow-loading graphics in an
effort to impress it'll be counterproductive. Many potential
sales are lost due to a slow-loading, unbrowsable site.

Your site should download fast. Research by an on-hold phone
message marketing company found that people start hanging up
when put on hold for more than 30 seconds. The Internet is
no different. If they have to wait for more than 30 seconds
for your page to load, visitors will leave.

In short, if they have to wait, they won't.

People often say our society has entered the "information
revolution." Not so. It's the "access to information"
revolution. The ability to retrieve information in
nanosecond speed is the underlying drive behind the
Internet. For instance, that same ability has caused entire
layers of middle managers to be wiped out. Therefore,
anything that slows that ability down (such as having a
front page over 30-40k), especially when compared to other,
quicker-loading competitor sites, will cost you.

Aside from load-time, you also have to deal with your
prospect's very short attention span. In other words, you
only have a few seconds to attract your visitors before they
leave. As such, you must communicate and distill your
message right down to the really important. Don't overwhelm
them with so much information or glitz that they miss your
central point. While your site may have entertainment value,
if they do not take action you are still losing.


Be Professional

They say that "you never get a second chance to make a good
first impression." First impressions are therefore important
to the degree to which visitors are positively impacted by
the first or index page. It is where the selling process
actually begins. Consistent color, well-balanced
information, appealing and quick-loading graphics, and, most
important, the right message targeted to the proper audience
are the most important elements of a professional-looking,
repeatedly revisited, and often referred Web site.

In fact, the site's front page message is the highest in
priority. Don't let careless mistakes weaken the impact of
your presentation, and always proofread -- and have others
proofread -- your copy for typographical and grammatical
errors. Use a language and project an image that your
specific target audience can easily understand. In other
words, are you trying to convey that you are informed,
serious, professional, credible, fun, helpful, resourceful,
or advanced technologically? The tone of your message should
appeal specifically to a targeted market and help put
visitors in a particular frame of mind.

A final caveat, though. The first page should not be the
only one that follows the above rules. Applying most of
these pointers to an entire site should be carefully
considered. Needless to say, however, that if you are able
to make them pass through that all-important first page
hurdle, then persuading them to take action later on should
be a cinch.

Today's tip by Jim Daniels: http://www.bizweb2000.com/

------------- SPONSOR MESSAGE #2 -------------

BLAST YOUR AD TO MILLIONS OF WEB SITES!

Now you can post your ad INSTANTLY to MILLIONS
of REAL classified sites!  And, you can REPOST it 
EVERY single day of the year!  DIRT CHEAP!

If you want to promote your product or service
on the Internet (and make money in the process), 
you must advertise HEAVILY!  Click below to learn
how:

http://www.directaccessgroup.com/page2.html


------------- SPONSOR MESSAGE #3 -------------

Let us submit your advertisement to 8,000 Major Engines 
& ffa sites and classified ad directories in a very short 
period of time. Our service FLOODS the net with your 
website/ad, giving you maximum exposure for minimal cost.

http://www.directaccessgroup.com/submityourad.html

------------- SPONSOR MESSAGE #4 -------------

HOW TO WRITE KILLER ADS - from the pros whose ads 
earn millions each year.  Learn to write GRABBER 
headlines and ads.  Guaranteed.  Reply with blank 
email to mailto:freereport@mindspring.com with 
"send free ad info" on subject line.

------------- END SPONSOR MESSAGES -------------

Your Ad to The Direct ACCESS Ezine 36,000+ 
recipients for as little as $74.95, or subcribe
to our service for only $69.95 and get a FREE
ad placed in this ezine.  Click for details: 
http://www.directaccessgroup.com/ezinemailings.html

---

To remove yourself from this ezine, send an email to:
mailto:trafficseeker@email.com?subject=remove

(C) 1996 - 2000 DIRECT ACCESS - ALL RIGHTS RESERVED



From list@netscape.com  Sun Jun 25 00:18:26 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19785
	for <ldapext-archive@odin.ietf.org>; Sun, 25 Jun 2000 00:18:26 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5P491g05601;
	Sat, 24 Jun 2000 21:09:02 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5P4GpA09621;
	Sat, 24 Jun 2000 21:16:52 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 21:16:52 -0700 (PDT)
Message-Id: <3.0.5.32.20000624211603.00937c70@pop.walltech.com>
X-Sender: bgreenblatt@pop.walltech.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 24 Jun 2000 21:16:03 -0700
To: "Kurt D. Zeilenga" <Kurt@openldap.org>,
        "RL 'Bob' Morgan" <rlmorgan@washington.edu>
From: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Subject: Re: draft-ietf-ldapext-locate-02 and UDP
Cc: ietf-ldapext@netscape.com
In-Reply-To: <3.0.5.32.20000624102846.0095fea0@infidel.boolean.net>
References: <Pine.LNX.4.21.0006240930470.23348-100000@perq.cac.washingt on.edu>
 <3.0.5.32.20000623203238.009b24f0@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"TRWYLD.A.-VC.yeYV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 10:28 AM 6/24/2000 -0700, Kurt D. Zeilenga wrote:
>At 09:55 AM 6/24/00 -0700, RL 'Bob' Morgan wrote:
>>Is that what you're asserting, Kurt?
>
>I'm simply asserting that CLDAP is not LDAP and I would prefer...

Huh.  CLDAP is supposed to be a subset of LDAP over UDP?

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi



From list@netscape.com  Sun Jun 25 01:53:21 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25533
	for <ldapext-archive@odin.ietf.org>; Sun, 25 Jun 2000 01:53:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5P5lFX00318;
	Sat, 24 Jun 2000 22:47:15 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5P5pdE24259;
	Sat, 24 Jun 2000 22:51:39 -0700 (PDT)
Resent-Date: Sat, 24 Jun 2000 22:51:39 -0700 (PDT)
Message-Id: <3.0.5.32.20000624225121.00966e00@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Sat, 24 Jun 2000 22:51:21 -0700
To: Bruce Greenblatt <bgreenblatt@directory-applications.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: draft-ietf-ldapext-locate-02 and UDP
Cc: "RL 'Bob' Morgan" <rlmorgan@washington.edu>, ietf-ldapext@netscape.com
In-Reply-To: <3.0.5.32.20000624211603.00937c70@pop.walltech.com>
References: <3.0.5.32.20000624102846.0095fea0@infidel.boolean.net>
 <Pine.LNX.4.21.0006240930470.23348-100000@perq.cac.washingt on.edu>
 <3.0.5.32.20000623203238.009b24f0@infidel.boolean.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"QcOsFD.A.b6F.p3ZV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 09:16 PM 6/24/00 -0700, Bruce Greenblatt wrote:
>At 10:28 AM 6/24/2000 -0700, Kurt D. Zeilenga wrote:
>>At 09:55 AM 6/24/00 -0700, RL 'Bob' Morgan wrote:
>>>Is that what you're asserting, Kurt?
>>
>>I'm simply asserting that CLDAP is not LDAP and I would prefer...
>
>Huh.  CLDAP is supposed to be a subset of LDAP over UDP?

I'll leave that for the authors to answer.

The issue here is quite simple.  Is it better to have one
document or two?  I argue two is better as one as they
could be developed and progressed independently of each
other.

Kurt




From list@netscape.com  Sun Jun 25 06:54:57 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06845
	for <ldapext-archive@odin.ietf.org>; Sun, 25 Jun 2000 06:54:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5PAjbg20118;
	Sun, 25 Jun 2000 03:45:37 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5PArSA27921;
	Sun, 25 Jun 2000 03:53:28 -0700 (PDT)
Resent-Date: Sun, 25 Jun 2000 03:53:28 -0700 (PDT)
Message-Id: <200006251053.e5PAr3x03729@ywing.netscape.com>
From: <prosperity@edmail.com>
Subject: 1st Years Income Guaranteed
Date: Sun, 25 Jun 2000 08:17:07
Resent-Message-ID: <"qpMNy.A.6zG.mSeV5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Is YOUR program Paying YOU? - MINE'S PAID OUT SINCE WEEK ONE!! 

I've found my UTOPIA, have you? 

The trouble I've found with most programs is not earning money for 
myself but making sure my DOWNLINE EARN so they don't drop out. 
I've solved that problem because:- 

ALL MY DOWNLINE ARE GUARANTEED A 1ST YEAR INCOME! 

In all my years of business I have never seen anything that comes 
close to matching this. 

100% legal in every way you can earn money today from just 2 people.
(personally sponsored or from SPILLOVER or from a combination of the two) 
***I'm PROMOTING ACTIVELY so you WILL get SPILLOVER from ME.*** 

ONE OF THE MOST EXCITING PARTS IS THAT YOU CAN GET PAID 
FOR THE NEXT TWENTY YEARS FOR WORK YOU DO TODAY. 

That's right earn money for the next twenty years or more for work you do 
today!

No other program offers you more! 

What does this company offer you - regardless of your credit history? 

Online banking 

Online payments 

Credit cards 

Loans and Mortgages 

Bank references 

Asset protection 

PLUS LOTS MORE! 

Earn money daily with a simple 2x2 forced matrix.... and there's more:- 

Check out the marketing and Guarantee pages. 

We're in Pre-Launch right now, so BE QUICK - it's moving FAST, VERY FAST! 

The only way to find out what we can do for YOU is:- 

Send an e-mail to Prosperity4all@lakmail.com 
Please put "Utopia" in the subject box 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Please Note: You're receiving this email because you're either a friend of 
mine, 
you answered an ad I ran or you sent an ad about your program, to one of my 
e-mail addresses. If at anytime you would like to be Removed from my e-mail 
list, 
just send a blank e-mail to remove.me@lakmail.com with "REMOVE Utopia" in the 
subject line and you'll be removed immediately. 
Thank you.

 
 
 
 
 
 
 
 
 
 
 



From list@netscape.com  Sun Jun 25 14:21:23 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09634
	for <ldapext-archive@odin.ietf.org>; Sun, 25 Jun 2000 14:21:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5PIBug05454;
	Sun, 25 Jun 2000 11:11:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5PIJms08000;
	Sun, 25 Jun 2000 11:19:48 -0700 (PDT)
Resent-Date: Sun, 25 Jun 2000 11:19:48 -0700 (PDT)
Message-Id: <200006251819.e5PIJak17578@xwing.netscape.com>
From: <prosperity4all@eudoramail.com>
Subject: I've been PAID since WEEK ONE - have YOU?
Date: Sun, 25 Jun 2000 15:37:14
Resent-Message-ID: <"8Z6qZ.A.l8B.C1kV5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Is YOUR program Paying YOU? - MINE'S PAID OUT SINCE WEEK ONE!! 

I've found my UTOPIA, have you? 

The trouble I've found with most programs is not earning money for 
myself but making sure my DOWNLINE EARN so they don't drop out. 
I've solved that problem because:- 

ALL MY DOWNLINE ARE GUARANTEED A 1ST YEAR INCOME! 

In all my years of business I have never seen anything that comes 
close to matching this. 

100% legal in every way you can earn money today from just 2 people.
(personally sponsored or from SPILLOVER or from a combination of the two) 
***I'm PROMOTING ACTIVELY so you WILL get SPILLOVER from ME.*** 

ONE OF THE MOST EXCITING PARTS IS THAT YOU CAN GET PAID 
FOR THE NEXT TWENTY YEARS FOR WORK YOU DO TODAY. 

That's right earn money for the next twenty years or more for work you do 
today!

No other program offers you more! 

What does this company offer you - regardless of your credit history? 

Online banking 

Online payments 

Credit cards 

Loans and Mortgages 

Bank references 

Asset protection 

PLUS LOTS MORE! 

Earn money daily with a simple 2x2 forced matrix.... and there's more:- 

Check out the marketing and Guarantee pages. 

We're in Pre-Launch right now, so BE QUICK - it's moving FAST, VERY FAST! 

The only way to find out what we can do for YOU is:- 

Send an e-mail to Prosperity4all@lakmail.com 
Please put "Utopia" in the subject box 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Please Note: You're receiving this email because you're either a friend of 
mine, 
you answered an ad I ran or you sent an ad about your program, to one of my 
e-mail addresses. If at anytime you would like to be Removed from my e-mail 
list, 
just send a blank e-mail to remove.me@lakmail.com with "REMOVE Utopia" in the 
subject line and you'll be removed immediately. 
Thank you.

 
 
 
 
 
 
 
 
 
 



From list@netscape.com  Sun Jun 25 22:31:27 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13026
	for <ldapext-archive@odin.ietf.org>; Sun, 25 Jun 2000 22:31:26 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5Q2PbX14126;
	Sun, 25 Jun 2000 19:25:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5Q2U1E03538;
	Sun, 25 Jun 2000 19:30:02 -0700 (PDT)
Resent-Date: Sun, 25 Jun 2000 19:30:02 -0700 (PDT)
Message-ID: <11981F9F5649D411BC92009027D0D18C11C96C@aspams01.cai.com>
From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
To: Natarajan S K <sknatarajan@aztec.soft.net>, ietf-ldapext@netscape.com
Subject: RE: draft-ldapext-cachedresults-00.txt
Date: Mon, 26 Jun 2000 12:34:35 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"ZAN9vC.A.92.oAsV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi,

I find it difficult to imagine a purpose for the proxy you describe. If you
are caching a particular subtree, and the requests generally cover the
subtree, presumably a replica of the subtree would be a better option. The
need to keep track of timestamps also argues for a replica: for every query
on the cache there must be a query on the original server to ascertain the
timestamps. I can't see an efficiency here.

When authentication is also taken into account, the difficulties multiply.
Whether the caching model would remain secure in this context, I believe
that it would be quite difficult to prove it secure. Replication assures
that the security infrastructure is in place whereas your apparently ad hoc
method gives me no confidence.

Ron.

-----Original Message-----
From: Natarajan S K [mailto:sknatarajan@aztec.soft.net]
Sent: Saturday, 24 June 2000 1:49
To: ietf-ldapext@netscape.com
Subject: draft-ldapext-cachedresults-00.txt


Hi, 
      I am attaching a draft on "Caching model for LDAP". Appreciate if you
can review it and get back with possible comments. 

Thanks,
Natarajan




>  <<cache.txt.txt>> 



From list@netscape.com  Mon Jun 26 03:10:21 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27718
	for <ldapext-archive@odin.ietf.org>; Mon, 26 Jun 2000 03:10:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5Q74PX27646;
	Mon, 26 Jun 2000 00:04:26 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5Q78og00107;
	Mon, 26 Jun 2000 00:08:50 -0700 (PDT)
Resent-Date: Mon, 26 Jun 2000 00:08:50 -0700 (PDT)
Message-Id: <200006260708.AAA17633@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
To: ietf-ldapext@netscape.com
cc: Jeff.Hodges@stanford.edu, RLBob Morgan <rlmorgan@cac.washington.edu>
From: Jeff.Hodges@stanford.edu
Reply-to: ietf-ldapext@netscape.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 26 Jun 2000 00:08:47 -0700
Sender: hodges@breakaway.Stanford.EDU
Resent-Message-ID: <"NERW5B.A.SB.BGwV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

RFCs 2829 and 2830 were recently published, nominally meeting the IESG's 
requirement for rescinding the "IESG Note" gracing the first pages of RFCs 
2251..2256. Patrick has indicated that we can address the "Note" by publishing 
an RFC that "updates" 2251..2256.

Additionally, we've spoken at various times of a "core" set of LDAPv3 RFCs, 
nominally represented by 2251..2256 (plus the two I-Ds that have become 2829 
and 2830) but this has never been formally defined.

The attached I-D is a draft for an "applicability statement" (see RFC 2026 
section 3.2) both rescinding the Note and defining the set of RFCs 
constituting LDAPv3.

We're suggesting that LDAPEXT work to refine this I-D and submit it for 
Standards Track. This will clarify what constitutes LDAPv3 as presently 
specified and help mitigate any issues that might have arisen due to the "IESG 
Note".

May we please add this item to the Pittsburgh LDAPEXT agenda?

thanks,

Jeff Hodges & RL "Bob" Morgan




From list@netscape.com  Mon Jun 26 03:34:37 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27812
	for <ldapext-archive@odin.ietf.org>; Mon, 26 Jun 2000 03:34:37 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5Q7SmX29218;
	Mon, 26 Jun 2000 00:28:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5Q7XDY06370;
	Mon, 26 Jun 2000 00:33:13 -0700 (PDT)
Resent-Date: Mon, 26 Jun 2000 00:33:13 -0700 (PDT)
Message-Id: <200006260732.AAA17729@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
To: ietf-ldapext@netscape.com
cc: Jeff.Hodges@stanford.edu, RLBob Morgan <rlmorgan@cac.washington.edu>
From: Jeff.Hodges@stanford.edu
Reply-to: ietf-ldapext@netscape.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 26 Jun 2000 00:32:55 -0700
Sender: hodges@breakaway.Stanford.EDU
Resent-Message-ID: <"Ur2Ll.A.NjB.3cwV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

[this time I actually attached the I-D, doh ]

RFCs 2829 and 2830 were recently published, nominally meeting the IESG's 
requirement for rescinding the "IESG Note" gracing the first pages of RFCs 
2251..2256. Patrick has indicated that we can address the "Note" by publishing 
an RFC that "updates" 2251..2256.

Additionally, we've spoken at various times of a "core" set of LDAPv3 RFCs, 
nominally represented by 2251..2256 (plus the two I-Ds that have become 2829 
and 2830) but this has never been formally defined.

The attached I-D (draft-hodges-ldapv3-as-00.txt) is a draft for an 
"applicability statement" (see RFC 2026 section 3.2) both rescinding the Note 
and defining the set of RFCs constituting LDAPv3.

We're suggesting that LDAPEXT work to refine this I-D and submit it for 
Standards Track. This will clarify what constitutes LDAPv3 as presently 
specified and help mitigate any issues that might have arisen due to the "IESG 
Note".

May we please add this item to the Pittsburgh LDAPEXT agenda?

thanks,

Jeff Hodges & RL "Bob" Morgan






                                               Jeff Hodges, Oblix Inc.
INTERNET-DRAFT                     RL "Bob" Morgan, Univ of Washington
Intended Category:                                          June, 2000
  Standards Track
Updates: 2251, 2252, 2253, 2254,
  2255, 2256, 2829, 2830


              Lightweight Directory Access Protocol (v3):
                        Applicability Statement
                    <draft-hodges-ldapv3-as-00.txt>



                        Status of this Document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Comments and suggestions on this document are encouraged.  Comments on
this document should be sent to the LDAPEXT working group discussion
list:
                       ietf-ldapext@netscape.com

This document expires in January 2001.

Abstract

The specification for the Lightweight Directory Access Protocol version
3 (LDAPv3) nominally comprises eight separte RFCs which were issued in
two distinct subsets at separate times (RFCs 2251..2256 first, then RFCs
2229 and 2830 following later), but this has never been formally stated.
Additionally, RFCs 2251..2256 each are embellished with an "IESG Note"



Hodges, Morgan                                                  [Page 1]

I-D     LDAPv3: Applicability Statement                        June 2000


warning implementors and deployers of potential interoperability prob-
lems due to the lack of a specification of mandatory-to-implement
authentication mechanism(s). This document corrects both situations by
explicitly specifying the set of RFCs comprising LDAPv3 and rescinding
the "IESG Note" due to the specification of mandatory-to-implement
authentication mechanisms in RFC 2829.

1.  Conventions Used in this Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [ReqsKeywords].

2.  Specification of LDAPv3

The Lightweight Directory Access Protocol version 3 (LDAPv3) is speci-
fied by this set of RFCs: 2251, 2252, 2253, 2254, 2255, 2256, 2829, 2830
[1..8]. The term "LDAPv3" MAY be used to informally refer to the proto-
col specified by this set of RFCs.

   [question: Should RFC 2849..

    <URL:ftp://ftp.isi.edu/in-notes/authors/rfc2849.txt>

    ..also be included in the "LDAPv3" definition?]

Other RFCs (and perhaps Internet-Drafts) MAY specify extensions to
LDAPv3.  Nomenclature denoting such combinations of LDAPv3-plus-
extension(s) is not defined at this time.


3.  Rescindment of the "IESG Note" from RFCs 2251..2256

The IESG approved publishing RFCs 2251..2256 with an attendant "IESG
Note" (Note).  The Note begins with..

   This document describes a directory access protocol that provides
   both read and update access.  Update access requires secure authenti-
   cation, but this document does not mandate implementation of any
   satisfactory authentication mechanisms.

The Note ends with this statement..

   Implementors are hereby discouraged from deploying LDAPv3 clients or
   servers which implement the update functionality, until a Proposed
   Standard for mandatory authentication in LDAPv3 has been approved and
   published as an RFC.




Hodges, Morgan                                                  [Page 2]

I-D     LDAPv3: Applicability Statement                        June 2000


RFC 2829 [7] is the "Proposed Standard for mandatory authentication in
LDAPv3" being called for in the Note. Therefore, the IESG Note on RFCs
2251, 2252, 2253, 2254, 2255, and 2256 is hereby rescinded.

4.  Security Considerations

This document does not directly discuss security, although the context
of the aforementioned "IESG Note" is security-related, as is the res-
cindment of the Note being recommended herein.

Please refer to the referenced documents, especially [7], for further
information concerning LDAPv3 security aspects.

5.  Acknowledgements

The authors thank ...  for their contributions to this document.

6.  References

[1]    M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access
       Protocol (v3)", RFC 2251, December 1997.

[2]    M. Wahl, A. Coulbeck, T. Howes, and S. Kille, "Lightweight Direc-
       tory Access Protocol (v3): Attribute Syntax Definitions", RFC
       2252, December 1997.

[3]    S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access
       Protocol (v3): UTF-8 String Representation of Distinguished
       Names", RFC 2253, December 1997.

[4]    T. Howes, "The String Representation of LDAP Search Filters", RFC
       2254, December 1997.

[5]    T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December
       1997.

[6]    M. Wahl, "A Summary of the X.500(96) User Schema for use with
       LDAPv3", RFC 2256, December 1997.

[7]    M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication
       Methods for LDAP", RFC 2829, May 2000.

[8]    J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Pro-
       tocol (v3): Extension for Transport Layer Security", RFC 2830,
       May 2000.

[ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate
               Requirement Levels". RFC 2119.



Hodges, Morgan                                                  [Page 3]

I-D     LDAPv3: Applicability Statement                        June 2000


7.  Authors' Addresses

   Jeff Hodges
   Oblix, Inc.
   18922 Forge Drive
   Cupertino, CA 95014
   USA

   Phone: +1-408-861-6656
   EMail: JHodges@oblix.com


   RL "Bob" Morgan
   Computing and Communications
   University of Washington
   Seattle, WA
   USA

   Phone: +1-206-221-3307
   EMail: rlmorgan@washington.edu


                  -----------------------------------

8.  Intellectual Property Rights Notices

The IETF takes no position regarding the validity or scope of any intel-
lectual property or other rights that might be claimed to  pertain to
the implementation or use of the technology described in this document
or the extent to which any license under such rights might or might not
be available; neither does it represent that it has made any effort to
identify any such rights.  Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11.  Copies of claims of rights made available for
publication and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan-
dard.  Please address the information to the IETF Executive Director.

9.  Copyright Notice and Disclaimer

   Copyright (C) The Internet Society (1998).  All Rights Reserved.




Hodges, Morgan                                                  [Page 4]

I-D     LDAPv3: Applicability Statement                        June 2000


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


                    -----------------------------------

   This document expires in January 2001.
























Hodges, Morgan                                                  [Page 5]





From list@netscape.com  Mon Jun 26 06:06:19 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28901
	for <ldapext-archive@odin.ietf.org>; Mon, 26 Jun 2000 06:06:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5Q9u4g17043;
	Mon, 26 Jun 2000 02:56:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5QA3uE08181;
	Mon, 26 Jun 2000 03:03:56 -0700 (PDT)
Resent-Date: Mon, 26 Jun 2000 03:03:56 -0700 (PDT)
Date: Mon, 26 Jun 2000 03:03:42 -0700 (PDT)
Message-Id: <200006261003.e5QA3fk03233@xwing.netscape.com>
From: "Mark" <loseweightfast@XICG.easemail.com>
To: WeightLoss.Friend.GGKX@netscape.com
Subject:  Kiss that BODY FAT goodbye forever, for FREE! -YLPL
X-Reply-To:  "Mark" <loseweightfast@easemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"KidHKB.A.S_B.KqyV5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hi,


How much weight do you want to lose?  10, 20 or even 50 lbs or more?

Throw away those fat clothes.  Picture yourself slim and trim and healthy. Do you want to 
make that picture a reality? Let me show you how you can.

Studies prove that too much weight contributes to numerous health problems such as 
high blood pressure, heart trouble, high cholesterol, and diabetes among a multitude of 
other serious problems. Furthermore, recent studies indicate that fit people, of normal 
weight, live longer.

We want to offer you a way to lower your risks of illness and to possibly even extend 
your life span. You'll get healthy again. You'll look great. And it won't take long!

If you're one of the millions of overweight people, I have terrific, very exciting news for you.  

I would like to introduce you to a new, very effective AND SAFE online weight loss 
program.  It is doctor approved and was created by A&M Personal Fitness, one of 
southern California's largest and most respected fitness and weight loss companies.

With our web-based program, The Interactive !Lipotrition Online! Diet System, there are 
no dangerous drugs; no hard-to-stick-to diets and no exercise unless that's something 
you want to do.  And best of all, it's totally free (for a limited time only)!
 
The plan is based on a very simple scientific method that is proven effective in weight 
loss and weight maintenance. Our website will give you full details on this exciting plan 
that can change your life.  

Excessive weight is dangerous to your health. It is very unattractive.  We can help.

Come to the site now and see for yourself.  It's FREE, so you're under NO obligation!
 
Know anyone who may be overweight and would like to know more about !Lipotrition 
Online!?  We will PAY YOU to tell your friends about us!  Simply become a FREE 
!Lipotrition Online! user and start getting paid today!

To receive our website address, simply hit “reply” (reply to this email) with the words, 
“website please”, in the subject field, and we'll immediately forward it to you.



Yours in Good Health,

The FitPeople Team




From list@netscape.com  Mon Jun 26 14:19:55 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12767
	for <ldapext-archive@odin.ietf.org>; Mon, 26 Jun 2000 14:19:54 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5QIDXX01079;
	Mon, 26 Jun 2000 11:13:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5QIHwY03446;
	Mon, 26 Jun 2000 11:17:58 -0700 (PDT)
Resent-Date: Mon, 26 Jun 2000 11:17:58 -0700 (PDT)
Message-ID: <979695BB8922D411A54000D0B74C60B50F1C05@sottmxsdev.entrust.com>
From: Kristianne Leclair <kristianne.leclair@entrust.com>
To: "'Kurt D. Zeilenga'" <Kurt@openldap.org>
Cc: ietf-ldapext@netscape.com, "Era. Als (E-mail)" <era.als@get2net.dk>
Subject: RE: compare result codes
Date: Mon, 26 Jun 2000 14:17:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"fX4gcC.A.U1.U55V5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, June 23, 2000 6:18 PM
To: Kristianne Leclair
Cc: ietf-ldapext@netscape.com
Subject: RE: compare result codes


At 11:02 AM 6/21/00 -0400, Kristianne Leclair wrote:
>>> 1) undefinedAttributeType
>>> 2) inappropriateMatching
>>Agreed. Currently the rescodes doc doesn't have this listed as a possible
>>error for compare. This will have to be updated.

>It's X.511 that actually needs updating.... or we need to
>do something about that MUST X.511 in RFC 2251.
I see nothing in X.511 that prevents inappropriateMatching as a possible
result code for the compare operation -- this was simply an oversight on our
part. 

The other two errors discussed below are, I believe, a different matter. If
there is a general consensus on the list that LDAP should return these
results under the circumstances described then we can add them to the
rescodes draft. If there is a suggestion to add something that differs from
X.511 though, it might be a good idea to raise a defect report against X.511
as well.


>>> 3) noSuchAttribute (syntax not relevant in this case)
>>> 4) noSuchAttribute
>>> 5) invalidAttributeSyntax
>>I'm not sure whether this would be invalidAttributeSyntax, I would have
said
>>compareFalse.  It depends on exactly how you read the definition of
>>invalidAttributeSyntax; the key phrase is 'specified as an argument of the
>>operation'. The only operations where the attribute value is specifically
an
>>argument of the operation are Add and Modify.

>I feel it should apply to value of an attribute value assertion which
>is an argument to a compare operation.  
>>Now this is really splitting
>>hairs here but we don't include this as an error for search either.

>Guess you could split hairs over whether or not the value of an
>attribute value assertion is an attribute value or not... but I
>rather just clarify X.511 (and hence LDAPv3) that this result
>code can (and should) be returned in this case.

>>When a search filter is evaluated the attribute must be known and the
value
>>must conform to the syntax for the attribute. If both conditions are not
met
>>the filter is undefined and evaluates to false -- no error is returned if
>>the attribute syntax is incorrect. 

>Yes, but a compare, unlike search, should return an error instead
>of applying three value logic to the assertion. 


>>As I see it, the compare operation simply answers the question 'does the
>>entry contain an attribute with this name and this value?', I don't think
it
>>matters whether the attribute is defined or not (I guess this really
depends
>>on how the server goes about checking this though). 

>As I see it, compare provides key functional that cannot be
>mimiced with search.  In particular, compare returns the reason
>the assertion, if used in a search filter, would be undefined.

>Kurt



From list@netscape.com  Mon Jun 26 21:24:45 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17927
	for <ldapext-archive@odin.ietf.org>; Mon, 26 Jun 2000 21:24:45 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5R1FFg02042;
	Mon, 26 Jun 2000 18:15:19 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5R1N9603234;
	Mon, 26 Jun 2000 18:23:09 -0700 (PDT)
Resent-Date: Mon, 26 Jun 2000 18:23:09 -0700 (PDT)
Message-ID: <3958725E.C611846D@showads.com.au>
Date: Tue, 27 Jun 2000 11:22:38 +0200
From: "Daryle Burnside" <daryle.burnside@showads.com.au>
Reply-To: daryle.burnside@showads.com.au
Organization: ShowAds
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ietf-ldapext@netscape.com" <ietf-ldapext@netscape.com>
Subject: REMOVE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"BEV-n.A.6x.7HAW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;</html>



From list@netscape.com  Tue Jun 27 06:46:17 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06416
	for <ldapext-archive@odin.ietf.org>; Tue, 27 Jun 2000 06:46:17 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5RAZug03446;
	Tue, 27 Jun 2000 03:35:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5RAhlQ03750;
	Tue, 27 Jun 2000 03:43:47 -0700 (PDT)
Resent-Date: Tue, 27 Jun 2000 03:43:47 -0700 (PDT)
Message-Id: <200006271043.GAA06204@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ietf-ldapext@netscape.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-natarajan-ldapext-cachedresults-00.txt
Date: Tue, 27 Jun 2000 06:43:34 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"VAXus.A.R6.iVIW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The LDAP Caching model
	Author(s)	: S. Natarajan, G. Vithalprasad, T. Kannan
	Filename	: draft-natarajan-ldapext-cachedresults-00.txt
	Pages		: 
	Date		: 23-Jun-00
	
Seeking entries from a directory is a process involving network 
resources. It is assumed that a directory is accessed for reading and 
searching data more than for modification purposes. Under such 
assumptions, for performance reasons, a mechanism for caching as a 
proxy  which caches all entries is desirable. This document describes
a mechanism for caching directory entries. 
This document also defines one operational attribute and two controls
required to be implemented for the caching model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-natarajan-ldapext-cachedresults-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-natarajan-ldapext-cachedresults-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-natarajan-ldapext-cachedresults-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000626091207.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-natarajan-ldapext-cachedresults-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-natarajan-ldapext-cachedresults-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000626091207.I-D@ietf.org>

--OtherAccess--

--NextPart--




From list@netscape.com  Tue Jun 27 11:24:16 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15293
	for <ldapext-archive@odin.ietf.org>; Tue, 27 Jun 2000 11:24:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5RFICe03541;
	Tue, 27 Jun 2000 08:18:13 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5RFMdg16437;
	Tue, 27 Jun 2000 08:22:39 -0700 (PDT)
Resent-Date: Tue, 27 Jun 2000 08:22:39 -0700 (PDT)
Message-Id: <s9587049.055@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 27 Jun 2000 09:13:33 -0600
From: "Vithalprasad Gaitonde" <gvithalprasad@novell.com>
To: <ietf-ldapext@netscape.com>
Subject: Approximate positioning in ldap server
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e5RFMb116410
Resent-Message-ID: <"QI6jbD.A.gAE.9aMW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Hi,
	In the ldap literature, I find references to "approximate positioning" in ldap server. What does this term exactly refer to ?  
Could anyone direct me to some literature on this.
Thanks & Regards
Prasad




From list@netscape.com  Wed Jun 28 00:46:52 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03149
	for <ldapext-archive@odin.ietf.org>; Wed, 28 Jun 2000 00:46:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5S4eue18263;
	Tue, 27 Jun 2000 21:40:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5S4jOY27738;
	Tue, 27 Jun 2000 21:45:24 -0700 (PDT)
Resent-Date: Tue, 27 Jun 2000 21:45:24 -0700 (PDT)
Message-ID: <B7EE5F06DEEBD3118EA000C04F01A36044763D@www.aztec.soft.net>
From: Natarajan S K <sknatarajan@aztec.soft.net>
To: ietf-ldapext@netscape.com
Subject: RE: draft-natarajan-ldapext-cachedresults-00.txt
Date: Wed, 28 Jun 2000 10:13:37 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"f7KU6C.A.BxG.iLYW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hi all,
           It seems there is some infringement of intellectual property
rights in the draft that I had written on cached results. Something on the
lines of "You can't use some intellectual property which you gained in the
company to write a draft on when you have left the company". 
           Most probably it will come out of Novell India in some other form
when a discussion would be appropriate. Until then can we stop any
discussion on this draft ? Inviting your cooperation on this.

I'm really really sorry for any trouble caused to you owing to this! It
never occurred to me that this would become an issue when I set about
writing the draft and submitted this. 

Thanks and Regards,
Natarajan

Natarajan SK
Sr. Software Engr.
Aztec Software
Bangalore-95
India


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, June 27, 2000 4:14 PM
Cc: ietf-ldapext@netscape.com
Subject: I-D ACTION:draft-natarajan-ldapext-cachedresults-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: The LDAP Caching model
	Author(s)	: S. Natarajan, G. Vithalprasad, T. Kannan
	Filename	: draft-natarajan-ldapext-cachedresults-00.txt
	Pages		: 
	Date		: 23-Jun-00
	
Seeking entries from a directory is a process involving network 
resources. It is assumed that a directory is accessed for reading and 
searching data more than for modification purposes. Under such 
assumptions, for performance reasons, a mechanism for caching as a 
proxy  which caches all entries is desirable. This document describes
a mechanism for caching directory entries. 
This document also defines one operational attribute and two controls
required to be implemented for the caching model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-natarajan-ldapext-cachedresults-00
.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-natarajan-ldapext-cachedresults-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-natarajan-ldapext-cachedresults-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



From list@netscape.com  Wed Jun 28 06:16:44 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17503
	for <ldapext-archive@odin.ietf.org>; Wed, 28 Jun 2000 06:16:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5SA9Ce06880;
	Wed, 28 Jun 2000 03:09:12 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5SADdc03232;
	Wed, 28 Jun 2000 03:13:39 -0700 (PDT)
Resent-Date: Wed, 28 Jun 2000 03:13:39 -0700 (PDT)
Date: Tue, 27 Jun 2000 14:09:01 -0500
Message-Id: <200006271909.OAA31727@finder-network.com>
Reply-To: nelcomkt@sginet.com
Subject: Sir/Madam Discover Email's MOST COVETED SECRET
From: hotbizopps5@infogeneratorpro.com
To: ietf-ldapext@netscape.com
Content-Type: text/plain
Resent-Message-ID: <"TKbhuC.A.Ly.S_cW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Discover THE MOST COVETED SECRETS of Email Marketing!
(Secret 1 of a 3 part series)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Copyright June 2000.  All Rights Reserved.
By Chad Deckard & Jamie Hall


Hello Sir/Madam,

Savvy entrepreneurs know that they can significantly increase
their profits by automating time consuming tasks such as
processing information requests.

This (1st of 3 instant messages) was sent as a result of you
subscribing to the "Opt-In Success Newsletter"!      
   
YOU will recieve one message every other day for the next 6
days and occasional updates over the coming months!

The best part about YOU sending for and receiving this message
series is its PROMPT DELIVERY and AUTOMATION! 

That's right, if YOU didn't notice, this email was delivered to
YOU within seconds after YOUR request with absolutely NO HASSLES
on YOUR END or OURS!

PLUS!!!  YOU will be recieving 2 more timely FOLLOW UP messages
from us containing valuable information on the "The MOST COVETED
SECRETS of Email Marketing" that you can learn from and apply in
YOUR online marketing efforts with absolutely NO HASSLES on YOUR
END or OURS!

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Now, let's turn the tables around for a moment... 

"How would YOU like to get YOUR message into people's hands this
FAST and HASSLE FREE"?... PLUS!!! Be able to FOLLOW UP with YOUR
prospects and customers "AUTOMATICALLY" with no effort over the
coming days, weeks, and months!

CLICK HERE TO SIGNUP NOW!: 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

WE HAVE A HUGE SECRET TO SHARE WITH YOU!!!

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
NOTE: Carefully "THINK" and "READ" through this information!
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *    

THE SECRET TO MAKING MONEY ON THE INTERNET IS...

Building "YOUR OWN ONLINE MAILING LIST" with "AUTOMATION"!!!  

This "TIDBIT" of information is the "1st COVETED SECRET"!

Most "Beginners" and "Established" businesses doing business on
the internet overlook building an ONLINE MAILING LIST with
AUTOMATION which is a HUGE MISTAKE!

"It is absolutely ESSENTIAL for YOU to build an ONLINE MAILING
LIST with AUTOMATION to maximize your sales, time, and money"! 

Did YOU know that if you are not building "YOUR OWN ONLINE
MAILING LIST" with AUTOMATION YOU are throwing away $100's to
$1,000's of current and future revenue from not doing so?...
 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

Are YOU neglecting YOUR online business and future by not
building a ONLINE MAILING LIST of YOUR own?  

If so, then CLICK HERE TO SIGNUP: 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

Are YOU going to continue letting each and everyday pass YOU by
not doing something about it?...  I hope NOT!  

If you choose "not to" it won't be long before you realize you
will "HAVE TO" if YOU intend to survive!

Do YOU know what will happen to YOU if YOU don't start building
YOUR own mailing list from now on?...

ANSWER: YOU will be CRUSHED by YOUR competition who is!!!  

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
Hire YOUR First Automated Virtual Employee!
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

YOUR future in the ONLINE MARKETING WORLD depends on whether
you take "OUR WORD" for it or not today and start building a
list of YOUR own!...

Please do YOURSELF a favor and "THINK" for a moment how great it
would be to just TURN ON an INSTANT CASH FLOW faucet everytime
you bulk email YOUR list of prospects and customers with a new
or established offer! 

Well... With "YOUR OWN ONLINE MAILING LIST" YOU can do just that
and so much more!

If YOU sell any product or service using the internet YOU
absolutely must use AUTOMATION technolgy to "Increase Sales,
Make More Money, and Save Time"!
 
Our "Revolutionary Email Marketing System" InfoGeneratorPRO.com
AUTORESPONDERS will virtually AUTOMATE YOUR selling, follow up,
and build "YOUR ONLINE MAILING LIST" for you.  

Just "THINK", every person who emails or opts-in to YOUR list
can be FOLLOWED UP again and again AUTOMATICALLY until they
opt-out or convert into a sale without YOU being accused of the
internet's most controversial subject... SPAM.

Let InfogeneratorPRO.com do all the work for YOU while YOUR away
or asleep, 24 hours, 7 days a week, 365 days a year!

CLICK HERE TO "HIRE YOUR FIRST AUTOMATED EMPLOYEE": 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Online Fortunes Are At Stake and Being Made Everyday With Us!  
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

From now on and in the future everyone selling online will
need to understand and utilize an AUTOMATED Email Marketing
System like InfoGeneratorPRO in order to compete or become dust
in the wind! 

Are YOU going to let YOURSELF get blown away? 

Or, are YOU going to TAKE ACTION RIGHT NOW and utilize this
POWERFUL AUTOMATED technology for YOURSELF? 

It's YOUR choice and future at stake!!! 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Here Is Our Offer...
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

Normally, our most popular service package, "Unlimited
Autoresponders" with "Unlimited Follow Ups and Emails",
is $19.95/month or $239.40 for the "Full Year".

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
NOTE: Additional pricing packages are also available. 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 
Our special price and offer for YOU is $179.40!        

That's right, pre-pay $179.40 for a "Full Year" of letting us
show YOU how to build "YOUR OWN ONLINE MAILING LIST" and much
more! 

Over 25% In Savings! 

Yes, that's $60.00 of user friendly technology we just put back
in YOUR pocket!

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
PLUS!!!  We will give you our NO RISK and NO QUESTIONS ASKED 
30 DAY MONEY BACK GAURANTEE!
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

YOU will not find another service like InfoGeneratorPRO on the
net that will give YOU so much value for YOUR money and a
GAURANTEE that YOU will love the system within 30 days!

Use the system for the first 30 days to see if you like it! If
you don't, just cancel YOUR account in a flash!  That's right...
Just "click" your "account cancel button" at anytime without
having to call us!  Your in complete control of your account!
This system is easy enough for any novice to use!

CLICK HERE TO SIGNUP NOW!: 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052
 
Do you know any other internet marketing company which would
give you FREE "Common Sense" knowledge that every online
marketer should "HAVE and KNOW" on "How To Build An Online
Mailing List" without charging first for it? Probably not!...

We have nothing to hide. Just plenty of quality information to
share with you and everyone who wants to recieve it! 

INFORMATION IS POWER! Let InfoGeneratorPRO give YOU the POWER
YOU need to succeed.
 
We only want YOU to know, what we know, this technology can do
for YOU! If YOU choose to harnessed it, let us show YOU the way!

Get into YOUR saddle and ride into the sunset!

There are no excuses why YOU shouldn't take advantage of this
"Opportunity" to "Increase Sales, Make More Money, and Save
Time".

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
YOU'VE Heard the Saying "OPPORTUNITY KNOCKS"!
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Well, the window of "OPPORTUNITY" is wide open RIGHT NOW to let
YOU in!  Use our affordable "Revolutionary Email Marketing
System" to get YOU started marketing online like the pros! 

Even if YOU are not sure, sign up, and start exploring our
FREE "Marketing Center" to learn more about how YOU too can make
a fortune in building "YOUR OWN ONLINE MAILING LIST"! 

YOU'LL instantly see tremendous results in YOUR sales and list
developement using InfoGeneratorPRO!  

We will be there for YOU when YOU are ready to get started!
SIGNUP NOW for the AUTOMATED "Revolutionary Email Marketing
System" that is taking the internet by STORM!

CLICK HERE TO SIGNUP NOW!: 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
NOTICE: 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

EARN 30%+ COMMISSIONS FOR REFERRING OUR SERVICE TO OTHERS!

Are YOU looking to get into a legitimate high tech internet
business that pays 30%+ lifetime residual income on customers
YOU refer to our service?

START TODAY selling the hottest AUTOMATED service on the net!

It's FREE to get started so be sure to sign up to get your own
"Associate Reseller" website and get paid for recommending this
powerful technology to others. 

If YOU refer our service to just 3 people YOU can literally pay
for YOUR own which makes it FREE!  Come on, everyone knows 3
people that could benefit from this technology.

Below is an actual ad we run that has had tremendous success for
this service. You too can use it to make money for yourself!

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
EXAMPLE:

AUTOMATE YOUR EMAIL FOLLOW UP RIGHT FROM YOUR PC! 
Discover a completely "Automated Email Marketing System" that...
Instantly sends personalized information to prospects, follows
up, closes sales, explodes profits, saves time and reduces
strees! Join our FREE 2 Tiered Affiliate Program right now!

CLICK HERE: 
http://www.InfoGeneratorPRO.com/index.cgi?affiliate_id=(your_id_number)
 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Take A FREE "Test Drive" at: 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Additionally, We will also provide YOU FREE of charge with
important tips on email marketing in our "Marketing Center" and
through our "Email Marketing Newsletter".

To Review Our FREE REPORTS & ARTICLES!

CLICK HERE NOW: 
http://www.infogeneratorpro.com/index.cgi?pageaff=marketing_info.html-_-1052

Don't let this "opportunity" and the "special price" of $179.40
pass YOU by! 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
NOTE: Additional pricing packages are also available. 
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CLICK HERE TO SIGNUP FOR YOUR 30 DAY FREE TRIAL!: 
https://www.finder-network.com/cgi-bin/infogenerator/signup.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Trust the "Market Leader" and "Innovator"! 

Trust InfogeneratorPRO!

** In 2 days you will recieve "Secret #2" as promised by our
AUTOMATED SYSTEM!

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Join our FREE Newsletter "Training Series" providing you with
the latest trends and information you need in order to compete
on
the "Internet" right now!  

mailto:Newsletter@InfoGeneratorPRO.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
FREE 2-Tier reseller program that pays you RESIDUAL income 
each month for referrals! -(Great Program For MLMer's!)
http://www.infogeneratorpro.com/index.cgi?pageaff=marketing_info.html-_-1052



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Discover A Revolutionary Email Marketing System!  http://www.infogeneratorpro.com/index.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Simple Removal Instructions:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
 
E-mail based removal:
mailto:hotbizopps5@infogeneratorpro.com?subject=unsubscribe 

Web based removal:
http://www.infogeneratorpro.com/cgi-bin/infogenerator/contact.cgi?unsubscribe=hotbizopps5:ietf-ldapext@netscape.com 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



From list@netscape.com  Wed Jun 28 15:26:16 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02345
	for <ldapext-archive@odin.ietf.org>; Wed, 28 Jun 2000 15:26:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5SJK6e04448;
	Wed, 28 Jun 2000 12:20:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5SJOYk06792;
	Wed, 28 Jun 2000 12:24:34 -0700 (PDT)
Resent-Date: Wed, 28 Jun 2000 12:24:34 -0700 (PDT)
Message-Id: <200006281741.MAA04808@nc1701.bie.ispi.net>
From: CashPromo<cashpromo@hotmail.com>
To: cashpromo@hotmail.com
X-Priority: 3
X-MSMail-Priority: Normal
Subject: Use Your FREE Cash to Make Thousands!
Sender: CashPromo<cashpromo@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 28 Jun 2000 13:19:19 -0500
Resent-Message-ID: <"ilOFs.A.xpB.wDlW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Dear Friends,

I recently discovered a unique money-making plan. If you need to make a few 
thousand dollars REALLY FAST, then please take a moment to read this simple 
program I am sharing with you.

This is a legitimate offer using FREE CASH given to you, with an opprotunity for
you to make THOUSANDS!!! Did you read that?  I said NO investmest!!
Read on...it's very simple...

ARE YOU IN NEED OF MONEY RIGHT NOW?
HOW DOES $20,000 IN TWO WEEKS SOUND?
Don't laugh! Try this for a change while you wait for the others to start
working. One hour of work to get started and no mailing lists!

The Newsletter and all Payments are made on the Internet By Email.

The very first thing you need to do is Go to PayPal and sign up. It takes two 
minutes and PayPal will deposit $5.00 in your account. 
That makes this program FREE!!!

Here's the link>>
 
https://secure.paypal.com/refer/pal=wildfire%40thecherrybomb.com

Then.....Email the $5.00 from your PayPal account to the FIRST name on
the list (#1) along with a note to "Please add me to your mailing list".
BE PREPARED TO GET EXCITED...YOU WON'T BE DISAPPOINTED!!!

******************************************************
Esquire Marketing Newsletter Gift Club
This service is 100% legal (Refer to US Postal and Lottery Laws, Title 18,
Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in
the code of federal regulations, Volume 16, Sections 255 and 436, which state a 
product or service must be exchanged for money received)
******************************************************
Here's How It Works:

Unlike many other programs, this three level program is more realistic and
much, much faster. Because it is so easy, the response rate for this
program is VERY HIGH AND VERY FAST, Internet E- Mail FAST and you will see
results in two weeks or less! Just in time for next month's bills!

You only mail out 20 copies (not 200 or more as in other programs). You
should also send them to people who send you their programs, because they
know these programs work and they are already believers in the system!
Besides, this program is MUCH, MUCH FASTER and has a HIGHER RESPONSE RATE!

Because of the ZERO INVESTMENT, SPEED, and HIGH PROFIT POTENTIAL, this 
program has a VERY HIGH RESPONSE RATE! Just one (1) US$5.00 bill that you 
get FREE at PayPal !!!!

***********************************************************************
Follow These Simple Instructions:

1) Email the $5.00 from your PayPal account to the FIRST name on the list
(#1) along with a note to "Please add me to your mailing list".
Only the first person on the list gets your name and a five dollar gift.

2) Edit only the list, removing the FIRST (#1) NAME FROM THE LIST.
Move the other two names UP and ADD YOUR NAME to the list in the THIRD
(#3) position. Note: do not forget to replace the PayPal referring URL in 
the body of the letter with your own PayPal referring URL. (Your email address at the end)

3) Send out 20 copies of this letter. NOTE: by sending this letter and the
payment via EMAIL, the response time is much faster INTERNET EMAIL FAST
Consider this, MILLIONS of people surf the Internet everyday, all day, all
over the world!

THERE'S NOTHING MORE TO DO. When your name reaches the first position in a
few days, it will be your turn to collect your gifts. The gifts will be
sent to you by 1,500 to 2,000 people like yourself, who are willing to 
invest one hour to receive US$20,000 in cash.

I think it's WORTH IT, don't you?

********** A TRUE STORY **************

Cindy Allen writes: I ran this gift summation four times last year. The
first time I received over $7,000 in cash in less than two weeks and over
$20,000 in cash in the next three times I ran it. I can't begin to tell
you how great it feels not to have to worry about money anymore!
I thank God for the day I received this letter! It has truly changed my
life! Don't be afraid to make gifts to strangers--they'll come back to you
in ten-fold. So, let's keep it going and help each other out in
these tough and uncertain times.

*********** CAN I DO IT AGAIN? *************

OF COURSE YOU CAN--this plan is structured for everyone to send only 20
letters each. However, you are certainly not limited to 20. Mail out as 
many as you can.

Every 20 letters you send has a return of $20,000 or more. If you can
Email forty, sixty, eighty, or whatever, GO FOR IT!

THE MORE YOU PUT INTO IT THE MORE YOU GET OUT OF IT.

**********  E- MAIL YOUR LETTERS OUT TODAY  ***********

Here are the Three People to start with. Sign up and send $5 (via Paypal) 
to the first person!

1. Eric Carel
wildfire@thecherrybomb.com
 
2. Sheila Simco
ssimco@prodigy.net

3. Don Mann
learn2berich@themail.com

You probably are skeptical of this especially with all the different
programs out there on the Web but if you don't try this you will never 
know. That's the way I felt. I've been watching this type of program for 
years and this is about as easy and fast as you can get it and it can even 
be free to try now with Paypal's help, no stamps, no envelopes, no copies 
to be made just a little effort and faith!

****************************************************
You have received this message in response to a classified ad
or you are on a list from cashfromhome.com.

To be removed from this list, please reply with "remove" in the subject line.

Thank you

DO NOT SPAM. IT HURTS ALL OF US



From list@netscape.com  Wed Jun 28 19:23:40 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06345
	for <ldapext-archive@odin.ietf.org>; Wed, 28 Jun 2000 19:23:36 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5SNEAg09877;
	Wed, 28 Jun 2000 16:14:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5SNM8c24443;
	Wed, 28 Jun 2000 16:22:08 -0700 (PDT)
Resent-Date: Wed, 28 Jun 2000 16:22:08 -0700 (PDT)
Message-ID: <11981F9F5649D411BC92009027D0D18C210C24@aspams01.cai.com>
From: "Lloyd, Alan" <Alan.Lloyd@ca.com>
To: Vithalprasad Gaitonde <gvithalprasad@novell.com>,
        ietf-ldapext@netscape.com
Subject: RE: Approximate positioning in ldap server
Date: Thu, 29 Jun 2000 09:26:52 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"i4mQPB.A.h9F.dioW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Beats me.. LDAP server positioning in my humble opinion are best for small,
limited capacity/scale systems where "internal" system approaches to
directories are applied.

Or the edge of a cliff might be another approximate position :-)

regards alan

-----Original Message-----
From: Vithalprasad Gaitonde [mailto:gvithalprasad@novell.com]
Sent: Wednesday, June 28, 2000 1:14 AM
To: ietf-ldapext@netscape.com
Subject: Approximate positioning in ldap server


Hi,
	In the ldap literature, I find references to "approximate
positioning" in ldap server. What does this term exactly refer to ?  
Could anyone direct me to some literature on this.
Thanks & Regards
Prasad



From list@netscape.com  Wed Jun 28 21:16:36 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07205
	for <ldapext-archive@odin.ietf.org>; Wed, 28 Jun 2000 21:16:32 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5T1ATe24947;
	Wed, 28 Jun 2000 18:10:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5T1Evc04433;
	Wed, 28 Jun 2000 18:14:57 -0700 (PDT)
Resent-Date: Wed, 28 Jun 2000 18:14:57 -0700 (PDT)
Date: Wed, 28 Jun 2000 06:28:38 -0500
Message-Id: <200006281128.GAA01073@finder-network.com>
Reply-To: optinsuccess@hotmail.com
Subject: Closing 1 out of 3 Sales ... Weekly Bonus Checks!
From: hotbizopps5@infogeneratorpro.com
To: ietf-ldapext@netscape.com
Content-Type: text/plain
Resent-Message-ID: <"s6OoYB.A.dEB.OMqW5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Closing 1 out of 3 Sales ... Weekly Bonus Checks!
=================================================

*Simple script presentation ... then 3-way our "heavy-hitters" 
who close the sale and sign them up for you!

*Training and support

*We brought in 30 people into our group TODAY using this SIMPLE
System!

*FREE LEADS from 300,000 person data base!

*Weekly BONUS checks of $126 or $40 for EACH person who signs
up!
(did you just do the math above?)

*Established 16-year-old International Company ... founded in
USA!

1-435-703-5266	(8-10 a.m. & 6-10 p.m. MST)

CALL ME NOW ... and get in on this EASY Scripted System!

In my 25 years looking for a networking program that works ... 
THIS IS IT!

1-435-703-5266	(8-10 a.m. & 6-10 p.m. MST)

Confucious says:

"The Window of Opportunity is BRIGHT and SHINY for YOU, today!"





* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Discover A Revolutionary Email Marketing System!  http://www.infogeneratorpro.com/index.cgi?affiliate_id=1052

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Simple Removal Instructions:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
 
E-mail based removal:
mailto:hotbizopps5@infogeneratorpro.com?subject=unsubscribe 

Web based removal:
http://www.infogeneratorpro.com/cgi-bin/infogenerator/contact.cgi?unsubscribe=hotbizopps5:ietf-ldapext@netscape.com 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



From list@netscape.com  Thu Jun 29 13:41:12 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15920
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 13:41:12 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5THYhe14568;
	Thu, 29 Jun 2000 10:34:44 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5THdBs13520;
	Thu, 29 Jun 2000 10:39:11 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 10:39:11 -0700 (PDT)
From: "David Chadwick" <d.w.chadwick@salford.ac.uk>
Organization: University of Salford
To: "Vithalprasad Gaitonde" <GVithalprasad@novell.com>,
        <ietf-ldapext@netscape.com>
Date: Thu, 29 Jun 2000 18:38:01 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Getting all attributes for a particular objectclass
Reply-to: d.w.chadwick@salford.ac.uk
Message-ID: <395B9789.5632.1B9E2AA@localhost>
Priority: normal
In-reply-to: <s94ea2cb.013@prv-mail20.provo.novell.com>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"9TclLC.A.LSD.9m4W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

Date forwarded: 	Mon, 19 Jun 2000 21:46:42 -0700 (PDT)
Date sent:      	Mon, 19 Jun 2000 22:46:23 -0600
From:           	"Vithalprasad Gaitonde" <GVithalprasad@novell.com>
To:             	<ietf-ldapext@netscape.com>
Subject:        	Re: Getting all attributes for a particular objectclass
Forwarded by:   	ietf-ldapext@netscape.com

> Hi Kurt,
>  Thanks for the reply. 
> Just a thought.....matached values control is not being supported by
> many ldap servers ( does any ldap server support it yet ??)

I would suggest that X.500 based LDAP servers are the only ones 
likely to support this feature at the moment. The LDAP control 
specified by Sean Mullan and myself in <draft-ldapext-matchedval-
01.txt> is not being progressed because the list found problems in it 
when it was discussed last year. I am currently working on a new 
ID that will provide a new control based on a second filter, as 
decided by the list last year. The id will be published in time for 
Pittsburgh

David


>......this
> would severly contriant a user from knowing the schema for a
> particular objectclass or attributetype. Do you see a case for this
> feature being a part of the vanila LDAP v3 standard itself and not
> just a additional control. Any thoughts ??
> 
> Thanks & Regards,
> Prasad
> 
> >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 06/19/00 07:16PM >>>
> At 04:27 AM 6/19/00 -0600, Vithalprasad Gaitonde wrote:
> >Hi,
> >	Is there any way in LDAP v3 by which I can get schema for a
> >particular objectclass or for a particular attribyteType.
> 
> You can use assert (using compare) that the particular attributeType
> is defined (e.g. assert cn is a value of AttributeTypes).  Or, using
> returned matched values only control, use a search
> (attributeTypes=cn).
> 
> >The cn=schema search gets the entire schema. But how do I get it only
> >for a particular objectclass and a particular attributeType. Does
> >anyone have ideas ?
> 
> You need a control to be able to read a subset of values of a
> particular attribute type within a given entry (or subentry).
> 
> Kurt
> 
> 
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************



From list@netscape.com  Thu Jun 29 13:42:45 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15969
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 13:42:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5THYve14686;
	Thu, 29 Jun 2000 10:34:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5THdQA13811;
	Thu, 29 Jun 2000 10:39:26 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 10:39:26 -0700 (PDT)
From: "David Chadwick" <d.w.chadwick@salford.ac.uk>
Organization: University of Salford
To: Jeff.Hodges@stanford.edu, ietf-ldapext@netscape.com
Date: Thu, 29 Jun 2000 18:37:59 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
Reply-to: d.w.chadwick@salford.ac.uk
CC: RLBob Morgan <rlmorgan@cac.washington.edu>
Message-ID: <395B9787.30084.1B9DC3C@localhost>
Priority: normal
In-reply-to: <200006260732.AAA17729@breakaway.Stanford.EDU>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by aka.mcom.com id e5THdL113709
Resent-Message-ID: <"88zAoB.A.nWD.Ln4W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Jeff

I would like to suggest that we do not have an applicability 
statement as you are suggesting but rather that we re-issue the 
base RFC with bug fixes and omissions that various people have 
pointed out over the years. I believe that Mark Wahl is keeping a 
note of these. For your convenience, I reproduce below text from 
my PKIX ID that is profiling the use of LDAPv3 for PKIs. YOu will 
see that there are various omissions in the base LDAPv3 
documents that need to be fixed, and I would like to see the RFCs 
re-issued with the extra text inserted into them, rather than 
publishing your ID that simply removes the notes. What do others 
think?

David

Schema    Issues (taken from <draft-pkix-ldap-v3-01.txt>)

RFC2587 [16] describes some of the subschema applicable to 
LDAPv2 servers, specifically the public key certificate 
related attribute types and object classes that MUST or MAY 
be supported. RFC2587 is equally applicable to LDAPv3 
servers and MUST be supported by them.

RFC2587 does not describe in detail the matching rules that 
should be supported by LDAP servers, nor does it describe 
how attribute value assertions for each matching rule 
should be encoded in filter items (in fact these AVA 
encodings are not currently described anywhere).

Finally RFC2587 does not mention attributeCertificates, 
since these are a relatively new development.

LDAPv3 allows the subschema supported by a server to be 
published in a subschema subentry. Clients following this 
profile which support the Search operation containing an 
extensible matching rule MAY use the subschemaSubentry 
attribute in the root DSE to find the subschemaSubentry, 
and MAY use the matchingRule and matchingRuleUse 
operational attributes in the subschema subentry in order 
to determine whether the server supports the various 
matching rules described below. Servers which support 
extensible matching SHOULD publish the matching rules they 
support in the matchingRule and matchingRuleUse operational 
attributes.

X.509(1997) [9] supports both equality and flexible 
certificate matching rules by the server, via the 
certificateExactMatch and certificateMatch MATCHING-RULEs 
respectively. (For example, a client may flexibly search 
for certificates with a particular validity time, key 
usage, policy or other field.) LDAPv3 servers MUST support 
the certificateExactMatch matching rule. Clients MAY 
support certificateExactMatch values for equalityMatch 
filters. LDAPv3 servers MAY support the certificateMatch 
matching rule. If the server does support flexible matching 
(either via certificateMatch or some other matching rule), 
then the extensibleMatch filter of the Search request MUST 
be supported. Clients MAY support the extensibleMatch 
filter and one or more of the optional elements of 
certificateMatch.

However, neither of the above matching rules are mentioned 
in the LDAPv3 standards [13 or 14], and only the equality 
matching rule is mentioned in [16], but nowhere is it 
defined for LDAP servers. It is expected that future 
revisions of the LDAPv3 documents will include these 
definitions, which are tentatively proposed below. 

( 2.5.13.34 NAME 'certificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'Certificate Serial 
Number and Issuer' )

Values in this syntax are encoded as an integer, a dollar 
($) separator and a string encoding of the distinguished 
name of the issuing CA.

The string description of the certificateMatch matching 
rule is proposed here as:

( 2.5.13.35 NAME 'certificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.55 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.55 DESC 'Certificate 
Assertion' )

The ASN.1 for certificateAssertion is defined in 12.7.2 of 
[9]. The LDAP string encoding of this is t.b.d. (but it 
will be similar to userCertificate syntax defined in RFC 
1778).

X.509(1997) [9] supports both equality and flexible 
matching rules of CRLs by the server, via the 
certificateListExactMatch and certificateListMatch MATCHING-
RULEs respectively. LDAPv3 servers MUST (or should it be 
MAY?) support the certificateListExactMatch matching rule. 
Clients MAY support certificateListExactMatch values for 
equalityMatch filters. LDAPv3 servers MAY support the 
certificateListMatch matching rule. If the server does 
support flexible matching (either via certificateListMatch 
or some other matching rule), then the extensibleMatch 
filter of the Search request MUST be supported. Clients MAY 
support the extensibleMatch filter and one or more of the 
optional elements of certificateListMatch.

Neither of the above matching rules are mentioned in the 
LDAPv3 standards [13 or 14], and only the 
certificateListExactMatch matching rule is mentioned in 
[16], but nowhere is it defined for LDAP servers. It is 
expected that future revisions of the LDAPv3 documents will 
include these definitions, which are tentatively proposed 
below. 

( 2.5.13.38 NAME 'certificateListExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.56 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'Issuer name, time and 
distribution point name' )

Values in this syntax are encoded as a string encoding of a 
distinguished name, a dollar ($) separator, a string 
representation of generalised time, a dollar separator and 
an optional string encoding of the distinguished name of 
the distribution point. (Note that the latter DN encoding 
for a distribution point name is a subset of the allowed 
variants, which can be a generalName or an RDN. Should this 
simplification be allowed?)

The string description of the certificateListMatch matching 
rule is proposed here as:

( 2.5.13.39 NAME 'certificateListMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.57 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'Certificate List 
Assertion' )

The ASN.1 for certificateListAssertion is defined in 12.7.6 
of [9]. The LDAP string encoding of this is t.b.d.

Editors Notes.
We        need to decide whether searching for cross 
          certificates should be supported by this LDAPv3 profile 
          or not. If we decide that this should be supported, then 
          we will need to define the matching rules to be 
          supported and the string encodings for the assertion 
          syntaxes (in fact this is not too difficult since they 
          are similar to certificate matching rules and AVAs).
We        need to decide if userSMIMECertificates should also 
          be supported as part of this profile or not.

LDAPv3 servers MAY store attributeCertificates, and clients 
MAY request then to be returned by adding them to the 
Search Request AttributeDescriptionList (either explicitly 
or implicity via requesting all attributes). LDAPv3 servers 
MAY support searching for entries containing specific 
attribute certificates, via either the 
attributeCertificateExactMatch or attributeCertificateMatch 
matching rules. For the convenience of the reader, some of 
the subchema definitions to support attribute certificates 
are produced below, but it is anticipated that these will 
be moved to a subsequent revision of the LDAPv3 standard.

attributeCertificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   AttributeCertificate
     EQUALITY MATCHING RULE   attributeCertificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) 
attributeCertificate(58) }



pmiUser OBJECT-CLASS ::= {  
-- a PMI user (i.e., a “claimant”)
   SUBCLASS OF  {top}
   KIND         auxiliary
   MAY CONTAIN  {attributeCertificate}
   ID 	joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser 
(24)}


attributeCertificateExactMatch MATCHING-RULE  ::= {
SYNTAX	AttributeCertificateExactAssertion
ID	joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateExactMatch (45) }

AttributeCertificateExactAssertion	::=	SEQUENCE {
serialNumber		CertificateSerialNumber,
issuer			IssuerSerial 	}


attributeCertificateMatch  MATCHING-RULE  ::=  {
	SYNTAX	AttributeCertificateAssertion
	ID		joint-iso-ccitt(2) ds(5) mr (13) 
attributeCertificateMatch (??) }


AttributeCertificateAssertion  ::=  SEQUENCE  {
subject		[0]	CHOICE {
			baseCertificateID	[0]  
IssuerSerial,
			subjectName		[1]  
GeneralNames} OPTIONAL,
	issuer		[1]	GeneralNames OPTIONAL,
	attCertValidity	[2]	GeneralizedTime OPTIONAL,
	attType		[3]	SET OF AttributeType 
OPTIONAL}
--At least one component of the sequence must be present


The LDAP definitions and syntaxes for the above matching 
rules are suggested to be:

( 2.5.13.45 NAME 'attributeCertificateExactMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Attribute certificate 
serial number and public key issuer and serial number' )

Values in this syntax are encoded as a string encoding of 
an integer (the serial number of the attribute 
certificate), a dollar ($) separator, a string 
representation of the distinguished name of the CA of the 
issuer (note this is a subset of the allowed GeneralName), 
a dollar separator and a string encoding of an integer (the 
serial number of the issuer’s public key certificate). 

The LDAP definition of the attributeCertificateMatch 
matching rule is proposed here as:

( 2.5.13.?? NAME 'attributeCertificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.59 )

The syntax definition is:

( 1.3.6.1.4.1.1466.115.121.1.59 DESC 'Attribute Certificate 
Assertion' )

The LDAP string encoding of this is t.b.d.



***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************



From list@netscape.com  Thu Jun 29 14:54:13 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17646
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 14:54:12 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5TIiQg20023;
	Thu, 29 Jun 2000 11:44:26 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5TIqPM26493;
	Thu, 29 Jun 2000 11:52:25 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 11:52:25 -0700 (PDT)
X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs
Date: Thu, 29 Jun 2000 11:52:35 -0700 (PDT)
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
X-Sender: rlmorgan@perq.cac.washington.edu
Reply-To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: David Chadwick <d.w.chadwick@salford.ac.uk>
cc: IETF ldapext WG <ietf-ldapext@netscape.com>
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining
 "LDAPv3"
In-Reply-To: <395B9787.30084.1B9DC3C@localhost>
Message-ID: <Pine.LNX.4.21.0006291143060.2760-100000@perq.cac.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"xQpxa.A.mdG.nr5W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


On Thu, 29 Jun 2000, David Chadwick wrote:

> I would like to suggest that we do not have an applicability statement
> as you are suggesting but rather that we re-issue the base RFC with
> bug fixes and omissions that various people have pointed out over the
> years. I believe that Mark Wahl is keeping a note of these. For your
> convenience, I reproduce below text from my PKIX ID that is profiling
> the use of LDAPv3 for PKIs.  You will see that there are various
> omissions in the base LDAPv3 documents that need to be fixed, and I
> would like to see the RFCs re-issued with the extra text inserted into
> them, rather than publishing your ID that simply removes the notes.
> What do others think?

Well, if the effort required to produce 2251-2256 is set at 10, I'd say
the effort to issue followups to them is a 5, and we're hoping the effort
required to get this applicability statement out the door and officially
remove the IESG warning is a 1.  I agree that doing revised versions of
the base docs is A Good Thing To Do, but even deciding whether to recycle
them at Proposed or move to Draft is likely to be contentious.  I believe
this was briefly discussed in Adelaide and the WG chair indicated that he
thought that doing revised versions should come after completing the
existing work items, including access control, which themselves will take
a while.

 - RL "Bob"




From list@netscape.com  Thu Jun 29 15:33:19 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18517
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 15:33:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5TJRMe04292;
	Thu, 29 Jun 2000 12:27:22 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5TJVpQ13200;
	Thu, 29 Jun 2000 12:31:51 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 12:31:51 -0700 (PDT)
Message-Id: <3.0.5.32.20000629123127.009b1e50@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 29 Jun 2000 12:31:27 -0700
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and
  defining "LDAPv3"
Cc: David Chadwick <d.w.chadwick@salford.ac.uk>,
        IETF ldapext WG <ietf-ldapext@netscape.com>
In-Reply-To: <Pine.LNX.4.21.0006291143060.2760-100000@perq.cac.washingto
 n.edu>
References: <395B9787.30084.1B9DC3C@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"iVQ4rC.A.7ND.lQ6W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I feel:
	a) an applicability statement is needed
	b) RFC2251-56,2829-30 need revision (some more than others)

These, in my opinion, are separate issues.

I believe an applicability statement should be published
and that it should rescind the IESG notice regarding
applicability of the technical specifications (RFC 2251-56).

I believe we need to identify necessary work items necessary to
produce specifications progressable to Draft Standard.  I believe
it will be necessary to reissue the complete set of LDAPv3 RFC
as Proposed Standard.

I propose that we schedule an session at IETF#48 to discuss
the issues regarding the LDAPv3bis documents.  A separate
session, I believe, to ensure this and other agenda items
get the attention they deserve.

At 11:52 AM 6/29/00 -0700, RL 'Bob' Morgan wrote:
>I believe this was briefly discussed in Adelaide and the WG chair
>indicated that he thought that doing revised versions should come
>after completing the existing work items, including access control,
>which themselves will take a while.

Though I agree that the chair as stated this, I do not agree with
this approach.  LDAPv3bis documents are critical to the success
of LDAP.  We should work LDAPv3bis issues without delay.  There
is no shortage of volunteers to undertake LDAPv3bis work.

Kurt





From list@netscape.com  Thu Jun 29 15:55:38 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18930
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 15:55:37 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5TJk4g28384;
	Thu, 29 Jun 2000 12:46:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5TJs3I24118;
	Thu, 29 Jun 2000 12:54:03 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 12:54:03 -0700 (PDT)
Message-Id: <200006291953.MAA11224@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining 
 "LDAPv3"
To: IETF ldapext WG <ietf-ldapext@netscape.com>
In-reply-to: Your message of Thu, 29 Jun 2000 11:52:35 -0700
Reply-to: IETF ldapext WG <ietf-ldapext@netscape.com>
From: Jeff.Hodges@stanford.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 Jun 2000 12:53:23 -0700
Sender: hodges@breakaway.Stanford.EDU
Resent-Message-ID: <"eOp07D.A.-1F.Ul6W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

rlmorgan@washington.edu said:
> if the effort required to produce 2251-2256 is set at 10, I'd say the
> effort to issue followups to them is a 5, and we're hoping the effort
> required to get this applicability statement out the door and
> officially remove the IESG warning is a 1. 

Yep.

> doing revised versions of the base docs is A Good Thing To Do, but
> even deciding whether to recycle them at Proposed or move to Draft is
> likely to be contentious.  

Yep.

There's quite a few substantial mods to the docs in the queue in terms of how 
the different facets of LDAP are addressed in which RFCs, plus there are 
various "bug fixes" and enhancements in the pipeline for the protocol itself 
that'd arguably call for bumping the version number (v3.x or v4 or whatever).

So we feel that, as Bob is essentially saying, it makes sense to tie-up the 
outstanding loose ends of explicitly defining LDAPv3 as we presently know it 
and rescind the IESG Note.

We can be moving ahead in parallel with deciding whether we take LDAPv3 (as 
defined by the AS) to Draft (and what that means in terms of what needs to be 
fixed and/or enhanced (or not)), or whether we want/need to begin sketching 
out LDAPv3bis (as Kurt put it) as the follow-on to LDAPv3, or we want/need to 
do something in between or a combination of the two.

But let's get these present two loose ends crisply resolved.

thanks,

JeffH




From list@netscape.com  Thu Jun 29 18:36:38 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21611
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 18:36:37 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5TMUae02482;
	Thu, 29 Jun 2000 15:30:37 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5TMZ6E09466;
	Thu, 29 Jun 2000 15:35:06 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 15:35:06 -0700 (PDT)
From: "David Chadwick" <d.w.chadwick@salford.ac.uk>
Organization: University of Salford
To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>,
        IETF ldapext WG <ietf-ldapext@netscape.com>
Date: Thu, 29 Jun 2000 23:33:46 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
Reply-to: d.w.chadwick@salford.ac.uk
Message-ID: <395BDCDA.25731.2C8B10E@localhost>
Priority: normal
References: <395B9787.30084.1B9DC3C@localhost>
In-reply-to: <Pine.LNX.4.21.0006291143060.2760-100000@perq.cac.washington.edu>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"aIcWJ.A.NTC.X88W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT


> Well, if the effort required to produce 2251-2256 is set at 10, I'd
> say the effort to issue followups to them is a 5, and we're hoping the
> effort required to get this applicability statement out the door and
> officially remove the IESG warning is a 1. 

But the value of revised RFCs is an order of magnitude more than a 
removed warning. Therefore we should concentrate on the higher 
goal if we can and not be deflected by relative trivia.

David


>I agree that doing revised
> versions of the base docs is A Good Thing To Do, but even deciding
> whether to recycle them at Proposed or move to Draft is likely to be
> contentious.  I believe this was briefly discussed in Adelaide and the
> WG chair indicated that he thought that doing revised versions should
> come after completing the existing work items, including access
> control, which themselves will take a while.
> 
>  - RL "Bob"
> 
> 
> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************



From list@netscape.com  Thu Jun 29 19:08:02 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22168
	for <ldapext-archive@odin.ietf.org>; Thu, 29 Jun 2000 19:08:02 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5TMwag26903;
	Thu, 29 Jun 2000 15:58:37 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5TN6aQ26105;
	Thu, 29 Jun 2000 16:06:36 -0700 (PDT)
Resent-Date: Thu, 29 Jun 2000 16:06:36 -0700 (PDT)
Message-Id: <3.0.5.32.20000629160631.009b3190@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 29 Jun 2000 16:06:31 -0700
To: IETF ldapext WG <ietf-ldapext@netscape.com>
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" and 
  defining "LDAPv3"
Cc: "RL 'Bob' Morgan" <rlmorgan@washington.edu>,
        David Chadwick <d.w.chadwick@salford.ac.uk>
In-Reply-To: <3.0.5.32.20000629123127.009b1e50@infidel.boolean.net>
References: <Pine.LNX.4.21.0006291143060.2760-100000@perq.cac.washingto n.edu>
 <395B9787.30084.1B9DC3C@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"zQePnD.A.kXG.7Z9W5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 12:31 PM 6/29/00 -0700, I wrote:
>I feel:
>	a) an applicability statement is needed
>	b) RFC2251-56,2829-30 need revision (some more than others)
>
>These, in my opinion, are separate issues.
>
>I believe an applicability statement should be published
>and that it should rescind the IESG notice regarding
>applicability of the technical specifications (RFC 2251-56).

On second thought, I guess I would have to object to
the progression of the AS if it included any changes
to the technical specification.

If one were to rescind the IESG notice, I would think
it appropriate to strength the Security Considerations
of the specifications.  Something like:
   Update functionality SHOULD be restricted to securely
   authenticated clients.

As such, I cannot support progressing the AS in its
current form as it would either result in inadequate
specification of Security Considerations or would
modify the technical specification.

Kurt



From list@netscape.com  Fri Jun 30 06:58:23 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12895
	for <ldapext-archive@odin.ietf.org>; Fri, 30 Jun 2000 06:58:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5UAmpg17806;
	Fri, 30 Jun 2000 03:48:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5UAupY25304;
	Fri, 30 Jun 2000 03:56:51 -0700 (PDT)
Resent-Date: Fri, 30 Jun 2000 03:56:51 -0700 (PDT)
Message-Id: <200006301056.GAA12862@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-ldapext@netscape.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: LDAP Control Extension for Server Side
	 Sorting of Search Results to Proposed Standard
Date: Fri, 30 Jun 2000 06:56:45 -0400
Sender: scoya@cnri.reston.va.us
Resent-Message-ID: <"fSkFBD.A.CLG.xzHX5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



The IESG has approved the Internet-Draft 'LDAP Control Extension for
Server Side Sorting of Search Results'
<draft-ietf-ldapext-sorting-03.txt> as a Proposed Standard.  This
document is the product of the LDAP Extension Working Group.  The IESG
contact persons are Ned Freed and Patrik Faltstrom.

Technical Summary
 
This  document  describes two LDAPv3 control extensions for  server side
sorting of search results. These controls allows a client to specify the
attribute types and  matching rules a  server should  use when returning
the results to an LDAP search request.

The sort controls allow a server to return a result code for the sorting
of the results  that is independent  of the result code returned for the
search operation.

Working Group Summary

There have been consensus in the working group about this way of
implementing the control extension. The extension very closely fits
together with the extension for pages result sets, which is published
as RFC 2696.

Protocol Quality

The document is reviewed by Patrik Faltstrom.

Note to RFC Editor:

Please change the following text in section 3.1:

From (Old):
  The MatchingRuleID SHOULD be one that is valid for the
  attribute type it applies to...
To (New):
  The MatchingRuleID, as defined in section 4.1.9 of [LDAPv3],
  SHOULD be one that is valid for the attribute type it applies to...

Also, please change the author information as follows:

Old:  T. Howes, Netscape
New:  T. Howes, Loudcloud

Old:  M. Wahl, Critical Angle Inc
New:  M. Wahl, Sun Microsystems



From list@netscape.com  Fri Jun 30 10:19:54 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18076
	for <ldapext-archive@odin.ietf.org>; Fri, 30 Jun 2000 10:19:54 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5UE9Cg00153;
	Fri, 30 Jun 2000 07:09:13 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5UEHDk19317;
	Fri, 30 Jun 2000 07:17:13 -0700 (PDT)
Resent-Date: Fri, 30 Jun 2000 07:17:13 -0700 (PDT)
From: john857@123india.com
Date: Fri, 30 Jun 2000 08:13:16 -0600
Message-Id: <200006301413.IAA09599@ www. lanka.com>
To: ietf-ldapext@netscape.com
Subject: Your Ad To 309,000 100% SAFE Recipients
Resent-Message-ID: <"48jx7.A.CtE.mvKX5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


100% RISK-FREE ADVERTISING TO 309,000
                OPPORTUNITY SEEKERS
                     
                   Guaranteed Results

FED UP WITH: 

     Being shut down by your ISP's 
     People screaming, 
     People sending you FLAMES 
     Being bombarded with COUNTER OFFERS 


     Then let us take over the hassles for you. 
     THERE ISN’T ANOTHER COMPANY IN THE WORLD THAT 
     CAN MAKE YOU A DEAL LIKE THIS!
 
     http://secure.fastweb.de/



     To be removed, reply with the word "REMOVE" in the subject
     heading, your name will be removed  within 24 hrs from the list.




From list@netscape.com  Fri Jun 30 12:48:21 2000
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22047
	for <ldapext-archive@odin.ietf.org>; Fri, 30 Jun 2000 12:48:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e5UGclg16996;
	Fri, 30 Jun 2000 09:38:47 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e5UGkmI10363;
	Fri, 30 Jun 2000 09:46:48 -0700 (PDT)
Resent-Date: Fri, 30 Jun 2000 09:46:48 -0700 (PDT)
Message-Id: <3.0.5.32.20000630094623.009226e0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 30 Jun 2000 09:46:23 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: rescodes last call comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"IkNTVB.A.LhC.17MX5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

It's my general opinion that this work is not progressable in
it's current form.  Below I will provide a number of comments
which demonstrate the need for additional work.  I also note,
due to time constrainsts, I was not able to fully review
all sections of the specifications.  It is likely that other
sections need work as well.

First, a couple of general comment:

I am also concerned that this document creates a third definition
of result codes.  We need one.  I believe this document should
not be progressed as a separate document.  It should be incorporated
into a yet to be drafted RFC2251bis document.  This document
would not only clarify rescode definitions and usage, but clarify
the relationship to X.500 rescodes.

As an update to RFC 2251, I find the language quite unclear as 
what sections it updates.  The document needs to more exacting
in its language (or better yet, incorporated directly into
a 2251bis document).

I would also like to include as part of my last call comments
resent discussions regarding compare results.  I believe this
draft should address issues outlined in that discussion.

some Section by section comments:

1.1:

The document refers to X.500 specifications, but like RFC 2251,
fails to state which X.500 specifications are MUSTs.  In also
doesn't clarify how implementators are to handle conflicts
between RFC 2251 and X.500 nor itself and RFC 2251 and X.500.
If this document does not change the MUST X.500 clause, then
X.500 requirements must be treated as overruling any MAY or
SHOULD.  That is, the MUST X.500 has higher precedence than
any MAY or SHOULD within this document (or 2251).

1.1 suggests that MUST X.500 means there are two types of
LDAP servers.  This, I feel, is a dangerous assertion.  There
should only be one type of LDAP server, one that implements the
LDAP protocol per the specification.  I believe the statement
more implies that LDAP servers may behave differently in many
respects, but must provide the same interface.  This document
clarifies the interface, it should alter or disallow any
behavior not allowed by RFC 2251.

1.1 states:
   Unless the server
   implements X.500 style access controls LDAP-only servers should only
   return noSuchObject when the target entry is not found until such
   time that similar access controls are defined for LDAP only servers.

I believe that an LDAP server may return noSuchObject even when
the server holds the object regardless of whether it implements
X.500 access controls.  That is, there is no difference of interface.

In general, I find the 1.1 fogs more issues than it is intended
to clarify.  I suggest axing most of this section.

Section 5.

This document states: "LDAP v3 [RFC2251] defines the following result
message for return from the server to the client...".  This leaves
the definitive version of LDAPResult in RFC 2251.  This means that
this document cannot "provide a central, unified source for these
definitions" as any specification needing to update LDAPResult
would likely have to update 2251 and this specification.  However,
I would object to moving the definitive version of LDAPResult out
of 2251 (or its successor).


Section 5.1.4:

s/set of URLs/sequence of URIs representing references/

5.2.1.1 other(80)

This result code should be used to indicate an implementation
specific error condition.  Clients are likely not able to
take corrective action when this result code is returned.

5.2.2.4.7 busy(51)
5.2.2.4.9 unwillingToPerform(53)

Should provide statement regarding difference between unwillingToPerform
and busy.  That difference being that busy indicates the server
is temporarily unwilling to perform the operation.


5.2.2.1.3 inappropriateMatching(18)

Under what circumstance can this resultCode be returned
by an LDAPv3 search operation?

This resultCode is generally returned compare and modify
where the operation requires an equality matching rule and
none is provided by the attribute type.

5.2.2.1.4 constraintViolation(19)

Can this be returned by compare when the asserted value
violates a constraint?

5.2.2.1.6 invalidAttributeSyntax(21)

compare should be allowed to return this result code when
the inserted value violates syntax.

5.2.2.2.1 noSuchObject(32)
   If the LDAP server is a front end for an X.500 DSA then noSuchObject
   may also be returned if discloseOnError is not granted for an entry
   and the client does not have permission to view or modify the entry.

This should be genericized... any LDAP server may do that.


5.2.2.3.6 invalidCredentials(49)
   This error code is returned if the DN or password used in a simple
   bind operation is incorrect, or if the DN or password is incorrect
   for some other reason, e.g. the password has expired.

typo.. or if the DN AND passward ARE CORRECT...

5.2.2.4.1 operationsError(1)

This result code should be used to indicate that request
cannot be processed due to improper sequencing with other
requests.  This may be returned by non-bind requests when
a multi-step bind is in progress.  The client should
complete the outstanding sequenced operation and then
may reissue the failed request.

5.2.2.4.2 protocolError(2)

Note that certain malformed requests result should result
in a notice of disconnect and not a protocolError response.
Note also that protocolError(2) may be returned as the
result of a bind when the server does not support the
requested protocol version.



From list@netscape.com  Fri Jun 30 21:11:04 2000
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29671
	for <ldapext-archive@odin.ietf.org>; Fri, 30 Jun 2000 21:11:03 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e6114le22239;
	Fri, 30 Jun 2000 18:04:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e6119Io01088;
	Fri, 30 Jun 2000 18:09:18 -0700 (PDT)
Resent-Date: Fri, 30 Jun 2000 18:09:18 -0700 (PDT)
Message-Id: <4.3.2.7.0.20000630175934.00af47c0@infidel.boolean.net>
X-Sender: guru@infidel.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 30 Jun 2000 18:09:11 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" <Kurt@openldap.org>
Subject: OID of caseExactIA5SubstringsMatch
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"Rex8tC.A.aQ.8SUX5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> 
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

What OID are others using for this rule?
Does there exist a formal specification for this rule?

Thanks, Kurt