From list@netscape.com Fri Sep 1 04:56: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 EAA07002 for ; Fri, 1 Sep 2000 04:56: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 e818mWu17561; Fri, 1 Sep 2000 01:48:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e818sPk10666; Fri, 1 Sep 2000 01:54:25 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 01:54:25 -0700 (PDT) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Fri, 1 Sep 2000 01:54:33 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: "Kurt D. Zeilenga" cc: IETF ldapext WG Subject: Re: I-D ACTION:draft-ietf-ldapext-locate-04.txt In-Reply-To: <4.3.2.7.0.20000830065524.00b48520@router.boolean.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8UwCk.A.YmC.A72r5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com On Wed, 30 Aug 2000, Kurt D. Zeilenga wrote: > This draft is pretty much ready to be progressed. However, > I believe the removal of CLDAP is incomplete. Aaaargh. We have been through this already. Discussion of this issue in June led to the inclusion of these clarifying sentences in version -03 of this document: "_ldap._tcp" applies to services compatible with LDAPv2 [7] or LDAPv3 [1]. "_ldap._udp" applies to services compatible with CLDAP [8]. I am at a loss for why this text was dropped from version -04. I can find no subsequent discussion on the list or among the co-authors about making this change. So, IMHO, this sentence, and the reference to CLDAP, needs to go back in, for precisely the reasons it went in in the first place. Kurt, I understand and appreciate your concern for designing documents that are able to move along the standards track. But removing useful and entirely correct information from a current document based on a prediction about the future status of other documents seems to me, pardon my frankness, to be the very essence of narrow-minded counter-productive bureaucratic thinking. If, following the enormous effort of moving the core LDAP specs to Draft Standard, there is an ounce of energy left in the universe for moving the dns-locate document to Draft Standard, *and*, if by that time there is no LDAPv3-over-UDP spec that is capable of moving to Draft, then I promise you we will take the reference to udp and CLDAP out of this doc. But for now it's useful, it clarifies the situation, and it should stay (or be put back) in. - RL "Bob" From list@netscape.com Fri Sep 1 10:32: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 KAA12776 for ; Fri, 1 Sep 2000 10:32:43 -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 e81EPNu19527; Fri, 1 Sep 2000 07:25:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e81EVIU11031; Fri, 1 Sep 2000 07:31:18 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 07:31:18 -0700 (PDT) Message-Id: <4.3.2.7.0.20000901071928.00b8dea0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Sep 2000 07:30:29 -0700 To: "RL 'Bob' Morgan" From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapext-locate-04.txt Cc: IETF ldapext WG In-Reply-To: References: <4.3.2.7.0.20000830065524.00b48520@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"yFeoN.A.5rC.027r5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:54 AM 9/1/00 -0700, RL 'Bob' Morgan wrote: >On Wed, 30 Aug 2000, Kurt D. Zeilenga wrote: > >> This draft is pretty much ready to be progressed. However, >> I believe the removal of CLDAP is incomplete. > >Aaaargh. We have been through this already. Discussion of this issue in >June led to the inclusion of these clarifying sentences in version -03 of >this document: > > "_ldap._tcp" applies to services > compatible with LDAPv2 [7] or LDAPv3 [1]. "_ldap._udp" > applies to services compatible with CLDAP [8]. > >I am at a loss for why this text was dropped from version -04. But it was dropped, hence my comment. >But for now it's useful, it clarifies the situation, and it >should stay (or be put back) in. If that's the consensus of the WG, do it (now!) and progress it (soon). It was not my intent to cause this I-D endlessly revision. I had a point for consideration, I made it, it was considered, let's move on. Kurt From list@netscape.com Fri Sep 1 15:52: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 PAA18992 for ; Fri, 1 Sep 2000 15:52: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 e81Jiuu13231; Fri, 1 Sep 2000 12:45:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e81JoqQ26756; Fri, 1 Sep 2000 12:50:52 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 12:50:52 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 01 Sep 2000 13:49:05 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" , "Steve Sonntag" Subject: LDAPSortKey - java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6830EC81.85E4896F" Resent-Message-ID: <"OuFHpB.A.yhG.biAs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_6830EC81.85E4896F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Somehow the text describing the object LDAPSortKey got lost between drafts 10 and 11. -Steve --=_6830EC81.85E4896F Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Somehow the text describing the object LDAPSortKey = got=20 lost
between drafts 10 and 11.
 
-Steve
--=_6830EC81.85E4896F-- From list@netscape.com Fri Sep 1 17:00: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 RAA19971 for ; Fri, 1 Sep 2000 17:00: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 e81KnPV05486; Fri, 1 Sep 2000 13:49:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e81KxQE03181; Fri, 1 Sep 2000 13:59:26 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 13:59:26 -0700 (PDT) Message-ID: <39B018C1.8341721A@netscape.com> Date: Fri, 01 Sep 2000 13:59:45 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,sv,ja MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com, Jim Sermersheim , Alan Clark , Steven Merrill Subject: Re: LDAPSortKey - java-api-11 References: Content-Type: multipart/alternative; boundary="------------680283EF24D873F9553EE5DE" Resent-Message-ID: <"EJANqC.A.Zx.tiBs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --------------680283EF24D873F9553EE5DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Someone pointed out that LDAPSortKey is not used/referenced, so I removed it from the draft. In the Netscape implementation, it is used by LDAPSortControl. The current API draft does not cover any particular controls. Rob Steve Sonntag wrote: > Somehow the text describing the object LDAPSortKey got lostbetween drafts 10 and 11. -Steve --------------680283EF24D873F9553EE5DE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit   Someone pointed out that LDAPSortKey is not used/referenced, so I removed it from the draft.

  In the Netscape implementation, it is used by LDAPSortControl. The current API draft does not cover any particular controls.

Rob

Steve Sonntag wrote:

 Somehow the text describing the object LDAPSortKey got lostbetween drafts 10 and 11. -Steve
--------------680283EF24D873F9553EE5DE-- From list@netscape.com Fri Sep 1 18:54: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 SAA22334 for ; Fri, 1 Sep 2000 18:54: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 e81MlOu18521; Fri, 1 Sep 2000 15:47:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e81MrJQ25589; Fri, 1 Sep 2000 15:53:19 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 15:53:19 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 01 Sep 2000 16:53:03 -0600 From: "Steve Sonntag" To: Cc: , "Alan Clark" , "Jim Sermersheim" , "Steven Merrill" Subject: Re: LDAPSortKey - java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_97CF1345.F796FB39" Resent-Message-ID: <"gTNUnC.A.jPG.eNDs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_97CF1345.F796FB39 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable It is still listed in section 2.2 >>> Rob Weltman 01-Sep-00 2:59:45 PM >>> Someone pointed out that LDAPSortKey is not used/referenced, so I = removed it from the draft.=20 In the Netscape implementation, it is used by LDAPSortControl. The = current API draft does not cover any particular controls.=20 Rob=20 Steve Sonntag wrote:=20 Somehow the text describing the object LDAPSortKey got lostbetween drafts = 10 and 11. -Steve --=_97CF1345.F796FB39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is still listed in section 2.2

>>> Rob = Weltman=20 <rweltman@netscape.com> 01-Sep-00 2:59:45 PM >>>
 = =20 Someone pointed out that LDAPSortKey is not used/referenced, so I removed = it=20 from the draft.=20

  In the Netscape implementation, it is used by LDAPSortControl. = The=20 current API draft does not cover any particular controls.=20

Rob=20

Steve Sonntag wrote:=20

 Somehow the text describing= the=20 object LDAPSortKey got lostbetween drafts 10 = and=20 11. -Steve
--=_97CF1345.F796FB39-- From list@netscape.com Fri Sep 1 18:59: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 SAA22393 for ; Fri, 1 Sep 2000 18:59: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 e81MqMu19596; Fri, 1 Sep 2000 15:52:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e81MwIo28235; Fri, 1 Sep 2000 15:58:18 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 15:58:18 -0700 (PDT) Message-ID: <39B0349E.27E51930@netscape.com> Date: Fri, 01 Sep 2000 15:58:38 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,sv,ja MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com, Alan Clark , Jim Sermersheim , Steven Merrill Subject: Re: LDAPSortKey - java-api-11 References: Content-Type: multipart/alternative; boundary="------------FF95E5BABF0D5BEDCF1DF2BE" Resent-Message-ID: <"RcRRf.A.54G.JSDs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --------------FF95E5BABF0D5BEDCF1DF2BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just a typo. Rob Steve Sonntag wrote: > It is still listed in section 2.2 > > >>> Rob Weltman 01-Sep-00 2:59:45 PM >>> > Someone pointed out that LDAPSortKey is not used/referenced, so I removed it from the draft. > > In the Netscape implementation, it is used by LDAPSortControl. The current API draft does not cover any particular controls. > > Rob > > Steve Sonntag wrote: > >> Somehow the text describing the object LDAPSortKey got lostbetween drafts 10 and 11. -Steve > --------------FF95E5BABF0D5BEDCF1DF2BE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit   Just a typo.

Rob

Steve Sonntag wrote:

It is still listed in section 2.2

>>> Rob Weltman <rweltman@netscape.com> 01-Sep-00 2:59:45 PM >>>
  Someone pointed out that LDAPSortKey is not used/referenced, so I removed it from the draft.

  In the Netscape implementation, it is used by LDAPSortControl. The current API draft does not cover any particular controls.

Rob

Steve Sonntag wrote:

 Somehow the text describing the object LDAPSortKey got lostbetween drafts 10 and 11. -Steve
--------------FF95E5BABF0D5BEDCF1DF2BE-- From list@netscape.com Fri Sep 1 21:24: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 VAA23842 for ; Fri, 1 Sep 2000 21:24: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 e821B3V25572; Fri, 1 Sep 2000 18:11:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8217MA15132; Fri, 1 Sep 2000 18:07:22 -0700 (PDT) Resent-Date: Fri, 1 Sep 2000 18:07:22 -0700 (PDT) Date: Fri, 1 Sep 2000 18:07:03 -0700 (PDT) Message-Id: <200009020107.e8216wf21037@ywing.netscape.com> From: laaiine@angelfire.com To: @netscape.com Subject: Could you use an extra $50 000???? X-Reply-To: laaiine@angelfire.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hV_wGB.A.KsD.JLFs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Looking for that extra something, to help your life have that little extra comfort? Do you work to cover the bills? Fed up with paying out and not receiving the rewards you wish for? Then have an open mind And read all of this, before you make a decision- it will be worth your while. _______________________________________________ Subject: Fw: MUST READ ! ! ! ... TV Advertized ! ! ! ... Fun-Lucrative Fellow Entrepreneur, If you wish to learn about an exceptional opportunity in the Home Business arena...Read On. "Your living is determined not so much by what life brings to you as by the attitude you bring to life; not so much by what happens to you as by the way your mind looks at what happens." This is going to be a great new Year for you! Please read all of this! EARN $100,000 PER YEAR SENDING E-MAIL!!! **************************************************************** You can earn $50,000 or more in the next 90 days sending e-mail, seem impossible? Read on for details (no, there is no 'catch')... ---------------------------------------------------------------- "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 (£5) 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(£5) 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(£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 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: E.Mills (will accept your currency) PO Box 2 Mowbray Heights Launceston,Tasmania Australia 7248 _______________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: Jim Wright 38 Pentyla Baglan Rd Port Talbot West Glamorgan SA12 8AA Wales UK ________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" Conrad Fry 1 Avon Gardens West Bridgford Nottingham England NG2 6BP ________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: Brian Pepe 30 Shady 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 dependent 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 ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE HOUR! DECISIVE ACTION YIELDS POWERFUL RESULTS ! ********************************************************* Your request to be removed will be processed within 24 hours. DISCLAIMER: Under Bill s.1618 TITLE III passed by the 105th US Congress this letter Cannot be considered Spam as long as the sender includes contact information & a method of removal.To be removed from future mailings just reply with REMOVE in the subject line.Thank you for your kind consideration. From list@netscape.com Sat Sep 2 04:12: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 EAA11237 for ; Sat, 2 Sep 2000 04:12:49 -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 e8284au08517; Sat, 2 Sep 2000 01:04:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e828AVc14197; Sat, 2 Sep 2000 01:10:31 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 01:10:31 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: In-Reply-To: References: Date: Sat, 2 Sep 2000 01:04:45 -0700 To: "Slone, Skip" , "'Erik Andersen'" , "'RL 'Bob' Morgan'" From: "Hoyt L. Kesterson II" Subject: RE: X.500 and LDAP alignment Cc: osidirectory@az05.bull.com, IETF ldapext WG , IETF ldapbis WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Resent-Message-ID: <"hF-6CB.A.jdD.2XLs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com let me add a further refinement on one of skip's points. if a digitally signed ldap request needs to be processed by one or more x.500 DSAs, we want to keep the request intact, i.e. no gateway modifications, to maintain the integrity and source authentication of the request through all those DSAs. let me add that this meeting is open to interested ietf participants. yours is a liaison organization to iso and itu. if any of you decide to participate, please let our host, skip, know. i also need to know so that i can arrange the agenda accordingly and so that i can get "official" cognizance of ietf participation. hoyt hoyt At 4:24 PM -0400 8/31/00, Slone, Skip wrote: >Bob, > >I would just like to add a few thoughts to what Erik has mentioned. First, I >would like to reiterate that the new work item is very broadly stated and to >emphasize that the express purpose as stated in the NWI is to "improve >alignment and thereby co-existence and interoperability with LDAP." > >Exactly where we will go is yet to be determined, but from my perspective >some of the most important work we can do is to break down barriers to >interoperability. One very important such barrier that is nearing >completion is the removal of X.500's dependency on OSI's upper layer >protocols. This is being done by providing a thin convergence layer (called >the Internet Directly Mapped protocol, or IDM) between the X.500 protocols >and TCP, thereby allowing implementers the choice of implementing X.500 on >an OSI stack or on TCP. (Note that this is different from RFC-1006 in that >1006 assumed that the OSI upper layers had already been implemented -- IDM >bypasses all that.) > >Additional barriers that can (and IMHO should) be removed are things like: > - allowing LDAP operations to be chained within DSP > - allowing an X.500 directory to return an LDAP referral > - allowing distributed name resolution to proceed through the X.500, LDAP, >and DNS (most notably SRV record) namespaces without the user having to care > - allowing subrequests resulting from the X.518 request decomposition >process to propagate to LDAP as well as X.500 > - allowing the X.500 results merging process to incorporate results from >LDAP as well as X.500 resident entries > - allowing search-with-join operations to be performed on related entries, >regardless which type of directory holds the entries in question > - allowing some form of interoperable X.500/LDAP replication > >Obviously this is quite a list, none of which is formalized as of yet, but >I'm hoping it gives you a better sense of where this activity may be headed. >I'm also hoping it helps achieve the ever-elusive goal of interoperability! > >I would also like to say that I was pleased to read in your note that those >involved in LDAP are pleased that this work is getting underway. I think >both camps will benefit if we can establish good communication and minimize >duplication of effort. > >Best regards, > > -- Skip Slone > Lockheed Martin > >-----Original Message----- >From: Erik Andersen [mailto:era.als@get2net.dk] >Sent: Wednesday, August 30, 2000 12:06 PM >To: 'RL 'Bob' Morgan' >Cc: osidirectory@az05.bull.com; IETF ldapext WG; IETF ldapbis WG >Subject: X.500 and LDAP alignment > > >Hi Bob, > >The new work item on LDAP is very loosely defined (to achieve maximum >alignment >with LDAP) not to constrain the work. As it is an X.500 work item, we can >only >specify alignment in one direction. We see several ideas in the LDAP work >that >could be useful to incorporate. However, we see alignment in both directions >as >very important. As the LDAP protocol is the most used X.500 access protocol, > >extension to LDAP to support most of the features below is very desirable. > >Within X.500, we have or are in the progress of adding a large number of new > >features. The following are completed and stable items: > >a) Facilities to control and constrain the service given to different user >groups using a concept called search-rules. > >b) Families of entries, for which David Chadwick has issue an Internet >draft. >We would be very interested in seeing that progressed. > >c) Hierarchical groups, which allow hierarchies to be established >independent >of the DIT hierarchy. > >d) Mapping-based matching with emphasis on geographical (zonal) matching >which >allows mapping between the real world as seen by users and the model of the >world as it is reflected in a directory. > >e) Matching rule substitution allowing a great flexibility in matching to >ensure more successful searches > >f) Much user related diagnostic information to be returned to users to >guide >in making a new, more successful search > >Of new items, the most important is probably "Related Entries in the >Directory". This is a way to access in one request information from >different >directories having different naming spaces (or disjoint naming spaces). This >is >a very significant work item that in many respects will align X.500 to the >real >world instead of trying the reverse. It will also bring X.500 closer to the >LDAP philosophy. Personally, I see it as a tool to provide interworking >between >LDAP and X.500 servers (and possibly other types of directories). > >Hope that helps. > >Erik Andersen >Mobile: +45 20 97 14 90 >E-mail; era.als@get2net.dk >Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm > > >-----Original Message----- >From: RL 'Bob' Morgan [SMTP:rlmorgan@washington.edu] >Sent: 30. august 2000 16:57 >To: Erik Andersen >Cc: David Chadwick; osidirectory@az05.bull.com; IETF ldapext WG; IETF >ldapbis >WG >Subject: RE: Matching Rules for Constructed Syntaxes > > >On Wed, 30 Aug 2000, Erik Andersen wrote: > >> I do not see why we should not include it in our first draft for the LDAP >> alignment works. David, hope to see you in Orlando. Your presence would be >> very useful. > >Can someone from the X.500 community describe and/or offer a pointer to >the "LDAP alignment" activity? I think everyone involved with LDAP is >pleased that this is happening, but especially in the context of the >ldapbis work, one of whose items will be (I think) clarifying LDAP's >dependencies on X.500, it does raise questions of who is aligning with >whom. > >Thanks, > > - RL "Bob" From list@netscape.com Sat Sep 2 04:42: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 EAA11360 for ; Sat, 2 Sep 2000 04:42: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 e828TwV18245; Sat, 2 Sep 2000 01:29:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e828e0619807; Sat, 2 Sep 2000 01:40:00 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 01:40:00 -0700 (PDT) Date: Sat, 2 Sep 2000 01:39:18 -0700 (PDT) Message-Id: <200009020839.e828d8f23445@ywing.netscape.com> From: laaiine@angelfire.com To: @netscape.com Subject: As Seen On TV! $50 000 within 90 days. X-Reply-To: laaiine@angelfire.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"wkpP5D.A.N1E.fzLs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Looking for that extra something, to help your life have that little extra comfort? Do you work to cover the bills? Fed up with paying out and not receiving the rewards you wish for? Then have an open mind And read all of this, before you make a decision- it will be worth your while. _______________________________________________ Subject: Fw: MUST READ ! ! ! ... TV Advertized ! ! ! ... Fun-Lucrative Fellow Entrepreneur, If you wish to learn about an exceptional opportunity in the Home Business arena...Read On. "Your living is determined not so much by what life brings to you as by the attitude you bring to life; not so much by what happens to you as by the way your mind looks at what happens." This is going to be a great new Year for you! Please read all of this! EARN $100,000 PER YEAR SENDING E-MAIL!!! **************************************************************** You can earn $50,000 or more in the next 90 days sending e-mail, seem impossible? Read on for details (no, there is no 'catch')... ---------------------------------------------------------------- "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 (£5) 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(£5) 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(£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 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: E.Mills (will accept your currency) PO Box 2 Mowbray Heights Launceston,Tasmania Australia 7248 _______________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: Jim Wright 38 Pentyla Baglan Rd Port Talbot West Glamorgan SA12 8AA Wales UK ________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" Conrad Fry 1 Avon Gardens West Bridgford Nottingham England NG2 6BP ________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: Brian Pepe 30 Shady 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 dependent 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 ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE HOUR! DECISIVE ACTION YIELDS POWERFUL RESULTS ! ********************************************************* Your request to be removed will be processed within 24 hours. DISCLAIMER: Under Bill s.1618 TITLE III passed by the 105th US Congress this letter Cannot be considered Spam as long as the sender includes contact information & a method of removal.To be removed from future mailings just reply with REMOVE in the subject line.Thank you for your kind consideration. From list@netscape.com Sat Sep 2 17:39:36 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 RAA16455 for ; Sat, 2 Sep 2000 17:39: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 e82LS9V13071; Sat, 2 Sep 2000 14:28:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e82LcCk06983; Sat, 2 Sep 2000 14:38:12 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 14:38:12 -0700 (PDT) Message-Id: <4.3.2.7.0.20000902143251.00afe6f0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Sep 2000 14:36:58 -0700 To: "Michael Armijo" , From: Bruce Greenblatt Subject: Re: draft-ietf-ldapext-locate-04.txt Cc: In-Reply-To: <96BABA22ECEAEA45B53D08D63E1B567801F5098F@DF-SPIKE.platinum .corp.microsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_94842836==_.ALT" Resent-Message-ID: <"knZde.A.1sB.DNXs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_94842836==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I have a question on Mapping Algorithm in Section 3. The second paragraph of this section has this sentence: "An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue". Is this restriction necessary. If an RDN is multi-valued, why should the mapping break? Shouldn't things work out OK if the RDN is something like: "dc = foo + ou = bar"? Thanks, Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html --=====================_94842836==_.ALT Content-Type: text/html; charset="us-ascii" I have a question on Mapping Algorithm in Section 3.  The second paragraph of this section has this sentence:

"An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue".

Is this restriction necessary.  If an RDN is multi-valued, why should the mapping break?  Shouldn't things work out OK if the RDN is something like:

"dc = foo + ou = bar"?

Thanks,

Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html --=====================_94842836==_.ALT-- From list@netscape.com Sat Sep 2 18:04: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 SAA16911 for ; Sat, 2 Sep 2000 18:04: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 e82LqlV14690; Sat, 2 Sep 2000 14:52:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e82M2pM12839; Sat, 2 Sep 2000 15:02:51 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 15:02:51 -0700 (PDT) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Sat, 2 Sep 2000 15:03:11 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: Bruce Greenblatt cc: IETF ldapext WG Subject: Re: draft-ietf-ldapext-locate-04.txt In-Reply-To: <4.3.2.7.0.20000902143251.00afe6f0@pop.walltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"xsqVnB.A.VID.KkXs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > I have a question on Mapping Algorithm in Section 3. The second paragraph > of this section has this sentence: > > "An RDN is able to be converted if it (1) consists of a single > AttributeTypeAndValue". > > Is this restriction necessary. If an RDN is multi-valued, why should the > mapping break? Shouldn't things work out OK if the RDN is something like: > > "dc = foo + ou = bar"? Well, we *could* permit this, of course. This would require deciding whether "dc=foo + dc=bar" is OK, and how to deal with ordering (since an RDN is a SET of AVAs, which means it's unordered, right?). So, more work, more potential confusion, presumably little constituency for actually using multi-AVA RDNs, especially multi-AVA RDNs one of whose components is DC=. Easier to say "don't do that", IMHO. Do you think this would actually be useful in practice? - RL "Bob" From list@netscape.com Sat Sep 2 19:10: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 TAA17246 for ; Sat, 2 Sep 2000 19:10: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 e82MxEV23172; Sat, 2 Sep 2000 15:59:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e82MZ9g18841; Sat, 2 Sep 2000 15:35:09 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 15:35:09 -0700 (PDT) Message-Id: <4.3.2.7.0.20000902152141.00b18bd0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Sep 2000 15:34:08 -0700 To: Bruce Greenblatt From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapext-locate-04.txt Cc: "Michael Armijo" , In-Reply-To: <4.3.2.7.0.20000902143251.00afe6f0@pop.walltech.com> References: <96BABA22ECEAEA45B53D08D63E1B567801F5098F@DF-SPIKE.platinum .corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"3y6fBB.A.BmE.bCYs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 02:36 PM 9/2/00 -0700, Bruce Greenblatt wrote: >I have a question on Mapping Algorithm in Section 3. The second paragraph of this section has this sentence: > >"An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue". This is consistent with the last paragraph of Section 2 and RFC 2247. The locate I-D should be (and I believe is) consistent with these statements in RFC 2247. 3. Mapping Domain Names into Distinguished Names This section defines a subset of the possible distinguished name structures for use in representing names allocated in the Internet Domain Name System. It is possible to algorithmically transform any Internet domain name into a distinguished name, and to convert these distinguished names back into the original domain names. [...] Distinguished names in which there are one or more RDNs, all containing only the attribute type DC, can be mapped back into domain names. Note that this document does not define a domain name equivalence for any other distinguished names. Note that these statements outline a 1-to-1 relationship between a domain and a DN of DC-only RDNs. I believe it important to preserve this 1-to-1 relationship between domains and DC-based DNs. Kurt From list@netscape.com Sat Sep 2 22:02: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 WAA19060 for ; Sat, 2 Sep 2000 22:02: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 e831odV10158; Sat, 2 Sep 2000 18:50:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8320fQ27722; Sat, 2 Sep 2000 19:00:41 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 19:00:41 -0700 (PDT) Message-Id: <4.3.2.7.0.20000902182744.00b03580@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Sep 2000 18:59:45 -0700 To: "Kurt D. Zeilenga" From: Bruce Greenblatt Subject: Re: draft-ietf-ldapext-locate-04.txt Cc: "Michael Armijo" , In-Reply-To: <4.3.2.7.0.20000902152141.00b18bd0@router.boolean.net> References: <4.3.2.7.0.20000902143251.00afe6f0@pop.walltech.com> <96BABA22ECEAEA45B53D08D63E1B567801F5098F@DF-SPIKE.platinum .corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"3zy-C.A.4wG.IDbs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:34 PM 9/2/2000 -0700, Kurt D. Zeilenga wrote: >At 02:36 PM 9/2/00 -0700, Bruce Greenblatt wrote: > >I have a question on Mapping Algorithm in Section 3. The second > paragraph of this section has this sentence: > > > >"An RDN is able to be converted if it (1) consists of a single > AttributeTypeAndValue". > >This is consistent with the last paragraph of Section 2 and RFC 2247. >The locate I-D should be (and I believe is) consistent with these >statements in RFC 2247. > > [...] > Distinguished names in which there are one or more RDNs, all > containing only the attribute type DC, can be mapped back into domain > names. Note that this document does not define a domain name > equivalence for any other distinguished names. My understanding of this sentence is that it says a DN which has only DC attributes can be mapped into a host name. It doesn't say that an RDN that contains a DC attribute as well as another attribute cannot be mapped into a domain name. >Note that these statements outline a 1-to-1 relationship between >a domain and a DN of DC-only RDNs. I believe it important to >preserve this 1-to-1 relationship between domains and DC-based DNs. OK. I'll go with that. How does allowing for an RDN that has DC attribute as well as something else not preserve this relationship... I think that the draft is just a little restrictive in this respect for no particular gain. Bruce >Kurt ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Sat Sep 2 22:27: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 WAA19168 for ; Sat, 2 Sep 2000 22:26: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 e831Onu26891; Sat, 2 Sep 2000 18:24:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e831Uks22103; Sat, 2 Sep 2000 18:30:46 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 18:30:46 -0700 (PDT) Message-Id: <4.3.2.7.0.20000902180149.00afecd0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Sep 2000 18:12:38 -0700 To: "RL 'Bob' Morgan" From: Bruce Greenblatt Subject: Re: draft-ietf-ldapext-locate-04.txt Cc: IETF ldapext WG In-Reply-To: References: <4.3.2.7.0.20000902143251.00afe6f0@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"M1M0EC.A.FZF.Gnas5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:03 PM 9/2/2000 -0700, RL 'Bob' Morgan wrote: > > I have a question on Mapping Algorithm in Section 3. The second paragraph > > of this section has this sentence: > > > > "An RDN is able to be converted if it (1) consists of a single > > AttributeTypeAndValue". > > > > Is this restriction necessary. If an RDN is multi-valued, why should the > > mapping break? Shouldn't things work out OK if the RDN is something like: > > > > "dc = foo + ou = bar"? > >Well, we *could* permit this, of course. This would require deciding >whether "dc=foo + dc=bar" is OK, and how to deal with ordering (since an >RDN is a SET of AVAs, which means it's unordered, right?). So, more work, >more potential confusion, presumably little constituency for actually >using multi-AVA RDNs, especially multi-AVA RDNs one of whose components is >DC=. Easier to say "don't do that", IMHO. Do you think this would >actually be useful in practice? I was thinking that this might be useful in various migration and coexistence scenarios. It seems to me that there is no added difficulty as long as there is only one dc attribute value in the RDN. In doing the mapping to a host name, the algorithm can just ignore the non-dc attribute-value pairs in the RDN. > - RL "Bob" ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Sat Sep 2 22:28: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 WAA19196 for ; Sat, 2 Sep 2000 22:28: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 e832GgV11628; Sat, 2 Sep 2000 19:16:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e832Qjc03050; Sat, 2 Sep 2000 19:26:45 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 19:26:45 -0700 (PDT) Date: Sat, 02 Sep 2000 21:25:17 -0500 From: Mark Wahl Subject: Re: draft-ietf-ldapext-locate-04.txt In-reply-to: "Your message of Sat, 02 Sep 2000 18:59:45 PDT." <4.3.2.7.0.20000902182744.00b03580@pop.walltech.com> Sender: wahl@austin.innosoft.com To: Bruce Greenblatt Cc: "Kurt D. Zeilenga" , Michael Armijo , ietf-ldapext@netscape.com Message-id: <7825.967947917@threadgill.austin.innosoft.com> Resent-Message-ID: <"99ooxD.A.Yv.lbbs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The ability for the mapping process to be bidirectional is important as it allows 2247 to indicate exactly where an object that is DNS-named is located in the directory. If one were to introduce the ability for the DNs to have additional components, there is no field currently defined in DNS for encoding the set of AVAs that would be needed to complete this mapping. There would be local tables, which seems to violate the spirit of DNS. > > Distinguished names in which there are one or more RDNs, all > > containing only the attribute type DC, can be mapped back into domain > > names. Note that this document does not define a domain name > > equivalence for any other distinguished names. > > My understanding of this sentence is that it says a DN which has only DC > attributes can be mapped into a host name. It doesn't say that an RDN that > contains a DC attribute as well as another attribute cannot be mapped into > a domain name. It can't be done by RFC 2247. Another RFC perhaps, but that other RFC would need to show how the other AVAs are represented in DNS. Mark Wahl, Directory Architect, Service Provider/Infrastructure Sun Microsystems, Inc. iPlanet Alliance From list@netscape.com Sat Sep 2 22:29: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 WAA19208 for ; Sat, 2 Sep 2000 22:29: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 e832LUu00245; Sat, 2 Sep 2000 19:21:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e832RRw03764; Sat, 2 Sep 2000 19:27:27 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 19:27:27 -0700 (PDT) Date: Sat, 2 Sep 2000 19:27:21 -0700 (PDT) Message-Id: <200009030227.e832RLf05559@ywing.netscape.com> From: signmeup@angelfire.com To: Friend@netscape.com Subject: BRAND NEW AND POWERFUL! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uJNGrB.A.g6.Ocbs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit The First of it's kind....Ever! A True FREE Downline Club that will work!! WHY?? Because we have been sanctioned to build a 10,000 member downline in the next 15 days for a POWERFUL REASON...... We have 1st Entry Rights to the hottest program ever developed Sorry, we cannot reveal the name or the company yet - but it is HOT! A one time $20 and a whopping $1,500,000 + possible payout! For more info and details on signing up, send an e-mail to: signmeup@angelfire.com and you must put " FREE " in the subject matter. Thank you From list@netscape.com Sat Sep 2 23:33: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 XAA20818 for ; Sat, 2 Sep 2000 23: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 e833Ppu03269; Sat, 2 Sep 2000 20:25:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e833Vng15786; Sat, 2 Sep 2000 20:31:49 -0700 (PDT) Resent-Date: Sat, 2 Sep 2000 20:31:49 -0700 (PDT) Message-Id: <4.3.2.7.0.20000902185202.00b99680@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Sep 2000 20:31:24 -0700 To: Bruce Greenblatt From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapext-locate-04.txt Cc: IETF ldapext WG In-Reply-To: <4.3.2.7.0.20000902180149.00afecd0@pop.walltech.com> References: <4.3.2.7.0.20000902143251.00afe6f0@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"311trB.A.Y2D.kYcs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:12 PM 9/2/00 -0700, Bruce Greenblatt wrote: >I was thinking that this might be useful in various migration and coexistence scenarios. Migration to/from what? coexistance with what? Traditional X.500 naming? Arbitrary (private) naming? DNS location issues aside, how would this work? Would there be a requirement that the two coexisting schemes produce the same number of components? If I understand what you're suggesting (which I admit I might not), let's say an organization was trying to migrate from o=OpenLDAP Project, c=US to a DN based upon their domain (which happens to have two components) dc=OpenLDAP,dc=Org You are apparently suggest that we, for migration and coexistance purposes, use the DN: o=OpenLDAP Project + dc=OpenLDAP, c=US + dc=Org I don't see how this helps us migrate to: dc=openldap,dc=org And what if the number of RDNs vs domain components aren't the same? o=openldap.org to dc=openldap,dc=org o=OpenLDAP,st=California,c=US to dc=openldap,dc=org You'd need to allow something like: o=openldap.org + dc=openldap.org nor o=OpenLDAP + dc=openldap, st=California, c=US + dc=org OR you could define some alternative naming scheme: o=openldap + d=openldap.org, st=california, c=us where d is the domain and the first (left to right) is used for location. Of course, you could just use associatedDomain (with or without using it for naming). >It seems to me that there is no added difficulty as long as there is only one dc attribute value in the RDN. In doing the mapping to a host name, the algorithm can just ignore the non-dc attribute-value pairs in the RDN. I really don't think the locate I-D should change the mappings defined by RFC 2247. The I-D should provide location services for DN derived from and based upon RFC 2247 defined one-to-one domain-DN mapping/naming scheme. The I-D should provide an algorithm of how to apply the RFC 2247 mapping and location services for all DC-based DNs and their children. I believe defining alternative mappings/naming/location schemes should be left to other documents. >I think that the draft is just a little restrictive in this respect >for no particular gain. Bijective domain-DN mapping makes sense for a number of reasons, but primarily because it provide name equivalence between two different naming systems. However, with this aside, please note that multi-valued RDNs is a solution to gain naming uniqueness, not migration/coexistance between alternative X.500 naming schemes. Migration from one naming scheme to another is better done via other means... such as aliases and/or references. Kurt From list@netscape.com Sun Sep 3 07:24:40 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 HAA07955 for ; Sun, 3 Sep 2000 07:24: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 e83BHJu22989; Sun, 3 Sep 2000 04:17:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e83BNHY03524; Sun, 3 Sep 2000 04:23:17 -0700 (PDT) Resent-Date: Sun, 3 Sep 2000 04:23:17 -0700 (PDT) Date: Sun, 3 Sep 2000 04:23:05 -0700 (PDT) Message-Id: <200009031123.e83BMsf26961@ywing.netscape.com> From: dayone@home.com To: Friend@netscape.com Subject: This Is For You Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cTlM7.A.w2.kSjs5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Please read this message, because it is for you....."Seek ye the Lord while He may be found, call upon Him while He is near, Let the wicked forsake his way and the unrighteous man his thoughts, and let him return unto the Lord for He will have mercy, and unto our God for He will abundantly pardon". Don't wait another day, do this today my friend and find forgiveness for all your sins, for how shall we escape if we neglect so great salvation? Get on your knees and ask God the Father, that Jesus Christ may be your Saviour ( for there is no other name under heaven given unto men whereby we MUST be saved ) and turn from your sins and turn your heart to Him today. Don't wait another day. Ask the Lord to give you a heart that loves Him and that wants to serve Him. Ask Him to give you a hatred for your sins, and that He will be your strength in turning from them, and He will do ALL the work in saving your soul. Start reading the Bible....the book of Proverbs, and the Psalms. Read the Gospels of Matthew,Mark, Luke and John. Oh, read it brothers and sisters, for the Lord will bless you when you read His book, and there is so much help and wisdom regarding how we are to live today. Also, we get our strength from God whenever we need it. The word of God say's " If you seek Him with all your heart you will surely find Him." Believe this my friend. You then will find peace with God, and that alone is true peace. We must find salvation today, for the day of the Lord is coming, and it just might be sooner than we realize! There will be eternal joy in heaven forever for the lovers of God and His word, and there will be eternal sorrow and no peace forever , for those who do not . Will you be ready to meet God? I am praying for you my friend that you will be. Amen From list@netscape.com Sun Sep 3 08:17: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 IAA08421 for ; Sun, 3 Sep 2000 08:17: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 e83CAQu25450; Sun, 3 Sep 2000 05:10:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e83CGNA12962; Sun, 3 Sep 2000 05:16:23 -0700 (PDT) Resent-Date: Sun, 3 Sep 2000 05:16:23 -0700 (PDT) Date: Sun, 3 Sep 2000 05:16:10 -0700 (PDT) Message-Id: <200009031216.e83CG4f03320@ywing.netscape.com> From: dayone@home.com To: Friend@netscape.com Subject: Titanic! -NMBJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0USNzB.A.OKD.WEks5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit It was a splendid ship! Everything a ship designer could imagine was built into it. It was beautiful, magnificent, TITANIC! Not only was it the biggest, it was sleek, fast.and absolutely unsinkable. Did not the designers guarantee it? Every proven safety feature and several new ones went into it's construction. It slid out of sea from Liverpool, England, on a serene April morning. Gleaming against the sky, it was majestic. The pride lf Britannia rode out to sea. New York was it's next harbor. The notables of society were it's passengers, and they basked in the splendor of it's luxury. Elegance was the word for Titanic's interior. Lavish in it's decor, menus, and entertainment, it surpassed the highest expectations of it's passengers.Three- quarters into it's maiden voyage, on the fringe of Newfoundland's frigid banks, the Titanic became a catastrophic nightmare. A deceptively large iceburg, detached from the polar ice fields, was drifting into the North Atlantic shipping lanes, destined to keep a predetermined encounter with the fabulous Titanic. Within two hours, before the dawn of April 15,1912, the unsinkable Titanic plunged to it's death, four miles beneath the icy surface taking it's 1500 passengers with it, and most of it's crew, and all it's treasure! Here's some awesome parallels:(1) " Not even God could sink the Titanic", was the designer's boast. We also have the deadly tendency to have excess pride in our resources. (2) Even when the Titanic struck the iceburg, the crew and passengers were confident that the "small iceburg could do little damage. We also are deceived into thinking that sin is minor, and of little importance. (3) This drama of the sea illustrates the uncertainty of life, and our need to be ready to stand before our Maker , and Judge! (4) It teaches us the lesson of obedient response. Those aboard the doomed Titanic who responded quickly, were saved! Those who flippantly ignored the warning, perished! My friend, what would your fate be in a similar situation? The Bible say's " Now is the day of salvation, behold now is the accepted time" it also ask's this question, " How shall we escape if we neglect so great salvation? Turn your heart to the Lord God of heaven and seek His forgiveness. Pray that He might save you from eternal damnation by giving you a heart that will trust the Lord Jesus Christ as your Savior, for there is NO OTHER WAY! The iceburg of eternity is fast approaching my friend, all hands on deck! From list@netscape.com Sun Sep 3 13:19: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 NAA10745 for ; Sun, 3 Sep 2000 13:19: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 e83H8AV20274; Sun, 3 Sep 2000 10:08:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e83HIF606013; Sun, 3 Sep 2000 10:18:15 -0700 (PDT) Resent-Date: Sun, 3 Sep 2000 10:18:15 -0700 (PDT) Message-Id: <200009031717.e83HHrL15798@xwing.netscape.com> From: " Subject: HISTORY STARTS TODAY!! Date: Sun, 3 Sep 2000 14:33:29 Resent-Message-ID: <"26vAXD.A.WdB.Wfos5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com 30,000 enrolled in less than 10 days! Pre Launch **This is THE BIG ONE** If you read this very carefully you'll understand this is something that you'll definitely want to join before the rest of the world hears about it and joins before you. This compnay is pre-launching what is destined to be the biggest and best Company in all of History. The very top Network marketers are in. The best software and software programmers are in. This is a combination of dot.com companies, plus many others. You'd better decide fast what you'd like to do! If you act now you'll be in the right place at the right time to position yourself for a great opportunity! I listened to the conference call and I was so impressed I joined up immediately. You'll be blown away!! HISTORY STARTS TODAY!! Would you take a few minutes of your busy schedule to listen to an individual who is giving up his earnings of $187,000 per week? He is NOW Pre-Launching a .com company with a pay plan that will revolutionize the entire Industry! How would you like to be with a company that has combined the best of SkyBiz, Km.net, BigSmart, Priceline.net, and long distance (International service as well) Listen to one of the conference calls. This will introduce you to the EXPLOSIVE business we are going into. I urge you to get on one or all of these calls and listen to an opportunity that you can finally agree with, and work because you know you will be rewarded exponentially for your efforts. After you listen to the call/calls you WILL want to sign up....and FAST! Then you'll have the opportunity to TELL THE WHOLE WORLD.!!!!! You have right now the opportunity to cash in on something VERY BIG. By being in the right place at the right time, if you ACT FAST, this is your WINDOW OF OPPORTUNITY before the rest or the world gets to know.... AND THEY WILL! YOU CAN BE ONE OF THE TOP MEMBERS!! You can join in at the very beginning and be part of HISTORY IN THE MAKING! Here are some major selling points combining major trends... 1. Low start up cost. 2. Unique marketing plan : A NEW HYBRID PLAN Straight-line Non Flushing Binary 3x10 Matrix with matching Bonus (When you cycle in the Straight-line you are entered into the Non Flushing Binary and then into the 3x10. 3. They're catching all the major huge trends. Web sites & education, "tools" for Internet marketers, International Long Distance "Flat Rate", and plan to be offering ISP and DSL service. (Free) and Lots more. 4. They're doing everything they can to come up with a formula to pay a matching bonus on the straight-line, as well as the Binary! Think about that. ..................Has it hit you yet? 5. THIS IS GLOBAL ! Get on the call TODAY or YOUR FRIENDS will be calling YOU TOMORROW. Get back to me QUICKLY for further information Click on the link below mailto:prosperity4allnow@lakmail.com?Subject=BIG_ONE Or send a blank e-mail to prosperity4allnow@lakmail.com with "BIG ONE" in the subject box. Have a GREAT day, Barb ********************************************************************** Please Note: You're receiving this email because you answered an advert I ran, you sent an ad about your program to one of my e-mail addresses, or you posted a link at my FFA links site. If at anytime you would like to be Removed from my address book, simply click on the link below mailto:remove.me@lakmail.com?Subject=REMOVE or send a blank e-mail to remove.me@lakmail.com with "REMOVE " in the subject line and you'll be removed immediately. Thank you. From list@netscape.com Sun Sep 3 17:44: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 RAA12380 for ; Sun, 3 Sep 2000 17:43: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 e83LWLV03089; Sun, 3 Sep 2000 14:32:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e83LgP624145; Sun, 3 Sep 2000 14:42:25 -0700 (PDT) Resent-Date: Sun, 3 Sep 2000 14:42:25 -0700 (PDT) From: felix323@123india.com Date: Sun, 3 Sep 2000 15:38:44 -0600 Message-Id: <200009032138.PAA18463@ www. lanka.com> To: ietf-ldapext@netscape.com Subject: 309,000 100% SAFE Recipients Resent-Message-ID: <"3Xwm2D.A._4F.AXss5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: 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 LOW response rate 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://thechnical.driveweb.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 Sun Sep 3 22:52: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 WAA15912 for ; Sun, 3 Sep 2000 22:52: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 e842ilu04895; Sun, 3 Sep 2000 19:44:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e842okI19594; Sun, 3 Sep 2000 19:50:46 -0700 (PDT) Resent-Date: Sun, 3 Sep 2000 19:50:46 -0700 (PDT) Message-Id: <200009040250.e842odf14794@ywing.netscape.com> From: Subject: Targeted e-mails starting at only $15! Date: Sun, 3 Sep 2000 18:17:37 Resent-Message-ID: <"NNFfNB.A.4xE.F4ws5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: 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/bluemail 10,000 opportunity seekers e-mails for only $15 **New List 9-01-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 190,000 opportunity seekers e-mails for only $75 - Promotions! **FREE with EVERY order, demo of ListMan e-mail manager software to manage your e-mails list and Credit Helper E-book with Links to Guaranteed Visa's and MC's! **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, CheckMAN software to accept checks online, by phone, or fax, and InfoDisk with 1000+ Money Making Reports and MORE! _______________________________________________________________ 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 Sun Sep 3 22:56: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 WAA15938 for ; Sun, 3 Sep 2000 22:56: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 e842irV17393; Sun, 3 Sep 2000 19:44:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e842sxM21151; Sun, 3 Sep 2000 19:54:59 -0700 (PDT) Resent-Date: Sun, 3 Sep 2000 19:54:59 -0700 (PDT) From: fgy2@aol.com Message-Id: <200009011200.FAA04066@octopus.azure.net> To: jbw3@aol.com Subject: INCREASE SALES WITH MAJOR CREDIT CARDS - ADV Date: Sun, 03 Sep 00 22:55:23 Eastern Daylight Time Reply-To: fgy2@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" Resent-Message-ID: <"0IThOD.A.1JF.B8ws5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: 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_018C_01BD9940.715D52A0 Content-Type: text/html; ACCEPT ALL MAJOR CREDIT CARDS
99% APPROVAL RATE - ALL BUSINESSES ACCEPTED
GOOD CREDIT, BAD CREDIT, NO CREDIT
FREE SHOPPING CART AND WEBSITE HOSTING INCLUDED
0 DOWN , LOWEST RATES,LOW MONTHLY PAYMENTS
WE WILL BEAT ANY COMPETITOR'S PRICE
CALL NOW 888-269-7960
ASK ABOUT OUR $200 REFERRAL FEE
 ------=_NextPart_000_018C_01BD9940.715D52A0-- From list@netscape.com Mon Sep 4 08:38: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 IAA03254 for ; Mon, 4 Sep 2000 08:38: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 e84CVLu08476; Mon, 4 Sep 2000 05:31:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e84CbJg15531; Mon, 4 Sep 2000 05:37:19 -0700 (PDT) Resent-Date: Mon, 4 Sep 2000 05:37:19 -0700 (PDT) Date: Mon, 4 Sep 2000 05:37:11 -0700 (PDT) Message-Id: <200009041237.e84CbAf24777@ywing.netscape.com> From: threetimesreturn@angelfire.com To: Investors@netscape.com Subject: 3-1 Return On Investment! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uoOy3D.A.SxD.-d5s5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hello, I have a program that pays 3-1 in just 3 months, plus 50% payments for referrals! I have already recieved $150 in referrals! This is a good one to get into, even if it's just for the referral payouts! Minimum to invest is $100. If you are interested in signing up please send me an e-mail to investments2000@angelfire.com and you MUST put " OK " in the subject matter or you will not get a response. Thank you! From list@netscape.com Mon Sep 4 09:44: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 JAA03858 for ; Mon, 4 Sep 2000 09:44:43 -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 e84DXAV22163; Mon, 4 Sep 2000 06:33:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e84DhHM28755; Mon, 4 Sep 2000 06:43:17 -0700 (PDT) Resent-Date: Mon, 4 Sep 2000 06:43:17 -0700 (PDT) From: Opt_In741116@gte.net Date: Mon, 4 Sep 2000 09:39:27 -0400 (EDT) Message-Id: <200009041339.e84DdQB18974@tot-wb.proxy.aol.com> To: opt_in403@2bmail.co.uk Subject: How you can make up to $1,500 a day Resent-Message-ID: <"LrUO4C.A.BBH.0b6s5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com From: Michelle Smith - publisher of the "Work From Home Opportunities" Newsletter Labor Day, 9 a.m. Hello, If you're interested in earning up to $1,500 a day Then I want to share something with you... Now you can make up to $1,500 a day! Imagine you come home from a hard day's work (exhausted..) You immediately go straight to bed. You get undressed, lay down, turn off the lights, and snuggle up face-down on the pillow. A few moments later, you feel uncomfortable and stressed out so you lie on your back. When you look up at the ceiling, it's as if the ceiling has been removed! You see exactly what you would see if outside stargazing! A stunning, accurate 3-dimensional re-creation of the starry night sky, including constellations such as the Big Dipper, Pegasus and the Milky Way galaxy, ...and even shooting stars! You can't see it during the day. The ceiling looks normal. But at night, when the lights are off, you see what looks like the sky outside! It's so relaxing and romantic. And educational! And talk about stress-relief! The moment you look at it, it'll melt your tension away faster than a great massage! Now how many people do you think would LOVE seeing this when they look up in their beds at night? "It's like you're sleeping under the stars!" Ok, I know you want to know How You Make Money. Here's how. You can put that awesome "convertible ceiling" in ANYONE'S bedroom with a product cost to you of.. Guess how much.. Only ONE to TWO Dollars! You offer this masterpiece for $100 - $1,500! Talk about *nice* profits! And it only takes you an hour or two! Here's an important point: These profits are similar to the profits of selling Information: the material costs next to nothing, but the customer really VALUES the END RESULT. So the market value is more (a LOT more). "Who'd want this?" Anyone with a bedroom ceiling (or any ceiling), as well as homes, hotels, etc. Who do you know that has a bedroom ceiling? Whew! The official money-making opportunity of the Millenium! (Well... we think it should be!) |;-) Anyway, I know you want more information to make a decision, so ... To receive more FREE information on How To Make Up To $1,500 A Day, Simply Click On The Email Link Below and Send Back The Following: Mailto:stargazing23@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:stargazing23@newmail.net And you'll be sent the full details on how to make up to $1,500 a day, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle Smith P.S. We'll also send you a free Opportunity E-zine with more interesting Money-Making Opportunities like this one, and important info. for the home-based entrepreneur! P.P.S. Also, even though 99% of people don't know about this opportunity, that won't be the case forever, so hurry up and reply to make sure you get to lock down YOUR city! To unsubscribe mailto:optout901@newmail.net From list@netscape.com Mon Sep 4 22:05:32 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 WAA10109 for ; Mon, 4 Sep 2000 22:05: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 e851rxV04553; Mon, 4 Sep 2000 18:53:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e85245616611; Mon, 4 Sep 2000 19:04:05 -0700 (PDT) Resent-Date: Mon, 4 Sep 2000 19:04:05 -0700 (PDT) Message-Id: <200009050204.e85241L29136@xwing.netscape.com> From: "Clay" To: Subject: .....I think you have a secret admirer......... Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 4 Sep 2000 22:15:00 Resent-Message-ID: <"7T2RNB.A.JDE.USFt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hello Dan, Thanks for coming to the party lastnight, everyone had so much fun. Kyles wife Clara told him that Denise was asking alot of questions about you. I think she is interested. Clara has her telephone number if you are interested in it. Next party we will have to make sure that only the people invited show up if you know what I mean. Well, got to get back to work, too much brass around today. The place where I got the viagra is http://www.limp.cc 50 mg. did not work for me but Rhonda and I both tried 100mg and all I can say is..... DYNOMITE!!!! I was embarrassed to ask a doctor face to face and Rhonda wanted to try some too so I got it online, WOW!!! Bob is coming over at 8:00 tonight to play cards. You are welcome to join us. If you are interested, give me a call I will be home about 5:45. See ya tonight, Clay From list@netscape.com Tue Sep 5 20:05: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 UAA15822 for ; Tue, 5 Sep 2000 20:05: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 e85Nviu02531; Tue, 5 Sep 2000 16:57:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8603jQ14603; Tue, 5 Sep 2000 17:03:45 -0700 (PDT) Resent-Date: Tue, 5 Sep 2000 17:03:45 -0700 (PDT) Message-ID: <39B58908.85965740@software.com> Date: Tue, 05 Sep 2000 17:00:08 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: david.a.cahlander@syntegra.com, ietf-ldapext@netscape.com Subject: Re: LDAP and DIGEST-MD5 SASL - rfc2829 References: <4.3.2.7.0.20000831164708.00b67e00@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FLMXsB.A.0jD.fnYt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > >I'm sure that I'm missing something very basic. > > The intent of DIGEST-MD5 is to offer relatively strong > authentication services between the client and the server > at low cost. Can somebody eavesdrop and extract response value (section 2.1.2.1) from the digest response and use the same response value to authenticate later ? From list@netscape.com Tue Sep 5 20:31: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 UAA16194 for ; Tue, 5 Sep 2000 20:31: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 e85MOKu15451; Tue, 5 Sep 2000 15:24:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e85MULo02153; Tue, 5 Sep 2000 15:30:21 -0700 (PDT) Resent-Date: Tue, 5 Sep 2000 15:30:21 -0700 (PDT) Date: Tue, 5 Sep 2000 15:30:05 -0700 (PDT) Message-Id: <200009052230.e85MTtL20249@xwing.netscape.com> From: "Millionaire Mentor " To: Want.Money?@netscape.com Subject: I CAN make you a millionaire in 12 months or less! X-Reply-To: Your Money Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"I6Lyr.A.jg.6PXt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit This e-email has been sent because you at one point requested information on financial oppurtunitys. However if you wish to be removed from this list please follow the removal instructions located at the bottom of this page. Thank you. May I have your permission to "MAKE YOU A MILLIONAIRE"? I CAN make you a millionaire in 12 months or less! If you are serious about earning this kind of money from the Internet, I can show you exactly how to do it -- without spending a dime of your money. Interested? Then answer this -- if I can show you how to make at least $10,000US per month in 8 weeks or less and make over $1,000,000 your first year, will you commit to working at your computer doing what I will teach you to do for 1 or 2 hours per day, 5 days per week for 8 weeks, and do all this without spending any money at all? This is not a scheme or gimmick. It is for real! If the answer is "no", please do not respond to this. If the answer is "yes", then email me at: your$$@consultant.com put "I want $1,000,000" in the subject line. Thanks for bearing with me. I do believe that this information is WORTH it! This mailing is done by an independent marketing co. We apologize if this message has reached you in error. SAVE THE PLANET, SAVE THE TREES! ADVERTISE VIA E-MAIL NO WASTED PAPER! LESS REFUSE IN OUR DUMPS! IF YOU RECEIVE UNREQUESTED OR UNWANTED MATERIAL IT CAN BE DELETED WITH ONE SIMPLE KEYSTROKE! THIS IS THE WAY OF THE NEW MILLENNIUM! This message is sent in compliance of the new e-mail bill: Senate bill 1618, Title 3, section 301. TO BE REMOVED FROM THE MAILING LIST And to ensure you do not recieve further transmissions to you by the sender of this email PRESS REPLY AND PUT the Subject REMOVE ALL REMOVES TO THIS ADDRESS WILL BE HONORED pleaseremove2@netscape.net ?subject=Remove Please do not send removes to the interested address as you may end up receiving the information. From list@netscape.com Tue Sep 5 20:42:18 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 UAA16283 for ; Tue, 5 Sep 2000 20:42: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 e860USV20692; Tue, 5 Sep 2000 17:30:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e860eb629800; Tue, 5 Sep 2000 17:40:37 -0700 (PDT) Resent-Date: Tue, 5 Sep 2000 17:40:37 -0700 (PDT) Message-Id: <4.3.2.7.0.20000905173623.00b2bb40@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Sep 2000 17:40:09 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: LDAP and DIGEST-MD5 SASL - rfc2829 Cc: david.a.cahlander@syntegra.com, ietf-ldapext@netscape.com In-Reply-To: <39B58908.85965740@software.com> References: <4.3.2.7.0.20000831164708.00b67e00@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"hfPm7C.A.PRH.DKZt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:00 PM 9/5/00 -0700, sanjay jain wrote: >"Kurt D. Zeilenga" wrote: >> >I'm sure that I'm missing something very basic. >> >> The intent of DIGEST-MD5 is to offer relatively strong >> authentication services between the client and the server >> at low cost. > >Can somebody eavesdrop and extract response value (section >2.1.2.1) from the digest response and use the same response >value to authenticate later ? No. See section 3.3. Kurt From list@netscape.com Wed Sep 6 03:06: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 DAA04908 for ; Wed, 6 Sep 2000 03:06: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 e866tAV04045; Tue, 5 Sep 2000 23:55:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8675Is01604; Wed, 6 Sep 2000 00:05:18 -0700 (PDT) Resent-Date: Wed, 6 Sep 2000 00:05:18 -0700 (PDT) Message-Id: <4.3.2.7.0.20000906000025.00b00970@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 00:03:47 -0700 To: Mark Wahl From: Bruce Greenblatt Subject: Re: draft-ietf-ldapext-locate-04.txt Cc: "Kurt D. Zeilenga" , Michael Armijo , ietf-ldapext@netscape.com In-Reply-To: <7825.967947917@threadgill.austin.innosoft.com> References: <"Your message of Sat, 02 Sep 2000 18:59:45 PDT." <4.3.2.7.0.20000902182744.00b03580@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"taSdaC.A.yY.tyet5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Well, whatever. It seems to me that the only reason for requiring this to be bidirectional is for the LDAP server to host a DNS server. I can think of many other uses for dc-naming. However, if dc-naming is to be restricted for use only for DNS host entries, I think that this draft, and the corresponding RFC need to explicitly say that, and to strongly warn implementors away from using the DC attribute for anything else. Bruce At 09:25 PM 9/2/2000 -0500, Mark Wahl wrote: >The ability for the mapping process to be bidirectional is important as it >allows 2247 to indicate exactly where an object that is DNS-named is >located in the directory. If one were to introduce the ability for the DNs >to have additional components, there is no field currently defined in DNS >for encoding the set of AVAs that would be needed to complete this mapping. >There would be local tables, which seems to violate the spirit of DNS. > > > > Distinguished names in which there are one or more RDNs, all > > > containing only the attribute type DC, can be mapped back into domain > > > names. Note that this document does not define a domain name > > > equivalence for any other distinguished names. > > > > My understanding of this sentence is that it says a DN which has only DC > > attributes can be mapped into a host name. It doesn't say that an RDN > that > > contains a DC attribute as well as another attribute cannot be mapped into > > a domain name. > >It can't be done by RFC 2247. Another RFC perhaps, but that other RFC would >need to show how the other AVAs are represented in DNS. > >Mark Wahl, Directory Architect, Service Provider/Infrastructure >Sun Microsystems, Inc. iPlanet Alliance ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From list@netscape.com Wed Sep 6 06:47: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 GAA07085 for ; Wed, 6 Sep 2000 06:47: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 e86AdAu20274; Wed, 6 Sep 2000 03:39:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e86AjBI22026; Wed, 6 Sep 2000 03:45:11 -0700 (PDT) Resent-Date: Wed, 6 Sep 2000 03:45:11 -0700 (PDT) Message-Id: <200009061044.GAA06925@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-matchedval-03.txt Date: Wed, 06 Sep 2000 06:44:50 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"zJdwM.A.uXF.1Ait5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: 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 : Returning Matched Values with LDAPv3 Author(s) : D. Chadwick, S. Mullan Filename : draft-ietf-ldapext-matchedval-03.txt Pages : 8 Date : 05-Sep-00 This document describes a control for the Lightweight Directory Access Protocol v3 that is used to return a subset of attribute values from an entry, specifically, only those values that match a 'values return' filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-matchedval-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-matchedval-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-matchedval-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: <20000905135300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-matchedval-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-matchedval-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135300.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Sep 6 09:38: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 JAA11915 for ; Wed, 6 Sep 2000 09:38: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 e86DUxu10086; Wed, 6 Sep 2000 06:31:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e86Daxg11596; Wed, 6 Sep 2000 06:36:59 -0700 (PDT) Resent-Date: Wed, 6 Sep 2000 06:36:59 -0700 (PDT) From: candbizgrowth@hotmail.com Date: Wed, 6 Sep 2000 09:35:38 -0400 (EDT) Message-Id: <200009061335.e86DZb804641@tot-te.proxy.aol.com> To: Millionaire@netscape.com Subject: Getting Rich!!! X-Reply-To: cybiz10@hotmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"59kVGB.A.gyC.1hkt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I CAN make you a millionaire in 12 months or less! If you are serious about earning this kind of money from the Internet, I can show you exactly how to do it -- without spending a dime of your money. Interested? Then answer this -- if I can show you how to make at least $10,000US per month in 8 weeks or less and make over $1,000,000 your first year, will you commit to working at your computer doing what I will teach you to do for 1 or 2 hours per day, 5 days per week for 8 weeks, and do all this without spending any money at all? If the answer is "no", please do not respond to this. If the answer is "yes", then email me at: candcbizgrowth@hotmail.com put "I want $1,000,000" in the subject line. From list@netscape.com Wed Sep 6 12:11: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 MAA16056 for ; Wed, 6 Sep 2000 12:11: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 e86Fstu04986; Wed, 6 Sep 2000 08:54:55 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e86G0uU08554; Wed, 6 Sep 2000 09:00:56 -0700 (PDT) Resent-Date: Wed, 6 Sep 2000 09:00:56 -0700 (PDT) Date: Wed, 6 Sep 2000 09:00:50 -0700 (PDT) Message-Id: <200009061600.e86G0TL29811@xwing.netscape.com> From: vpjfo@sinia.cl To: nsfgn@sinia.cl Reply-To: sinia.cl@xwing.netscape.com Subject: INTERNET GOLD E-COMMERCE SYSTEM nhnrw Resent-Message-ID: <"7Vp5ZB.A.8EC.2omt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com JOIN THE RETAIL EXPLOSION OCCURING ON THE INTERNET. INTERNET GOLD E-COMMERCE SYSTEM Learn How to become Financially Independent With Our Internet GOLD System! You now must know that the Internet is the fastest growing marketing medium with over 50 million users world-wide.This figure is increasing at over 250,000 every week and all are potential purchasers of a variety of products and services online. The FEDERAL GOVERNMENT ESTIMATES THAT RETAIL INTERNET SALES WILL REACH 20 BILLION DOLLARS THIS YEAR. DON'T LET THIS INCREDIBLE OPPORTUNITY PASS YOU BY. We will give you some of their best kept secrets of marketing successfully on the internet, plus some of our own! We will give you some of the best internet add-on programs that make it easier to earn Thousand's online, plus some products that will make your initial marketing exploits easier! You can get online with our E-COMMERCE SYSTEM and start making money without further investment! THE MOST COMPREHENSIVE PACKAGE AVAILABLE! As part of this amazing package we offer you a range of products and services that any experienced or inexperienced online marketer can use to full effect. These amazing products make up the Internet Gold E-Commerce System. What you will receive is: A FULLY OPERATIONAL ONLINE WEBSITE: E-Commerce ready to go. Hottest Selling Product on the Internet Today, Earn 50% of each sale AND YOU WILL BE FULLY OPERATIONAL IN 48hrs. BULK E-MAIL: We give you an exclusive working copy of one of the best e-mail address collectors which gathers e-mail addresses across the internet.This program can gather up to 60,000 e-mail addresses per hour - great for your promotional activities on the internet (a similar program is selling for over $50); PLUS we will also give you a working copy of one of the best bulk e-mail programs which allows you to send out thousands of e-mails at a time; THE DIRECT EMAIL CLUB: Will provide you with your first Email Blast to 25,000 Hungry Consumers,who are just waitnig to buy your product. ( $75 Value) REGISTER WITH SEARCH ENGINES: We also provide you with an exclusive report & software program which will show you how you can register your web site with over 1250 search engines, and get more chances to have your site listed in the top twenty. Each of these search engines gets thousands of hits everyday. Your web site could increase its hit rate by 200-600 every day. ($40 Value) MY MULTI-MILLION DOLLAR PUBLISHING COMPANY: You receive complete resale rights to this program. It is currently selling for $99. CYBER CASH SOFTWARE: Post your Ads to 8000 FFA sites and 5000+ Free Classified sites.(value $50) 850,000 OPT-IN SAFE TO MAIL ADDRESSES: Just follow the simple instruction,and with a few hours work you will be able to blast your ad once a day.(value $30) E-ZINE ADVERTISEMENT: Follow the links provided and your Website will be advertised on 500,000sites.(value $50) DIRECT EMAIL REPORT: Both the beginner and expert alike will find this comprehensive report extremely usefull. This report will guide you in setting up your successful Bulk Email Program. THE COMPLETE INTERNET MARKETING KIT: This comprehensive marketing kit will show you how to effectively coordinate all of the tools you will receive in the Internet Gold E-Commerce System, into an Internet Cash Machine. ORDER TODAY FOR ONLY $24.95 AND BE ONLINE MAKING MONEY IN 48hrs!! OUR GUARANTEE: If you are not completely satisfied we will refund your money. FOR ORDERING INFOMATION mailto:internetgold4u@email.com?subject="ECOMMERCE" ******************************************************** TO BE REMOVED: mailto:offplease2000@yahoo.com?subject="todd1" ******************************************************** From list@netscape.com Wed Sep 6 20:04:13 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 UAA25126 for ; Wed, 6 Sep 2000 20:04: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 e86NuWu10054; Wed, 6 Sep 2000 16:56:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e86NHNc29309; Wed, 6 Sep 2000 16:17:23 -0700 (PDT) Resent-Date: Wed, 6 Sep 2000 16:17:23 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 06 Sep 2000 17:17:02 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" , "Steve Sonntag" Subject: LDAPUrl class in java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_5D05DF6A.C6A7CF7E" Resent-Message-ID: <"ABLoe.A.fJH._Btt5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_5D05DF6A.C6A7CF7E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable An application doing its own referral handling may need to make decisions based on the scheme of URLs returned from search continuation references or referrals. Shouldn't the LDAPUrl object provide a method to retrieve the URL scheme, viz. ldap, http, & etc. -Steve --=_5D05DF6A.C6A7CF7E Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
An application doing its own referral handling may need to make
decisions based on the scheme of URLs returned from search
continuation references or referrals.
 
Shouldn't the LDAPUrl object provide a method to retrieve
the URL scheme, viz. ldap, http, & etc.
 
-Steve
--=_5D05DF6A.C6A7CF7E-- From list@netscape.com Wed Sep 6 20:06: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 UAA25141 for ; Wed, 6 Sep 2000 20: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 e86Nvbu10461; Wed, 6 Sep 2000 16:57:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e86N7wY26474; Wed, 6 Sep 2000 16:07:58 -0700 (PDT) Resent-Date: Wed, 6 Sep 2000 16:07:58 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 06 Sep 2000 17:07:02 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" , "Steve Sonntag" Subject: getReferrals() java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1A429833.2B4A2297" Resent-Message-ID: <"nWssj.A.GdG.L5st5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_1A429833.2B4A2297 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable In the java-api-11 I-D, an application doing asynchronous search operations is confronted with two different data formats when handling referrals and search continuation references. When the application gets a referral status on a search operation, referral URL information is retrieved by LDAPResponse.getReferrals() as an array of String objects. When the application gets search continuation references as part of the search data, the continuation references are retrieved by LDAPSearchResultReference.getURLs() as an array of LDAPUrl objects. To be consistent, shouldn't both return an array of LDAPUrl objects? -Steve =20 --=_1A429833.2B4A2297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
In the java-api-11 I-D, an application doing asynchronous search
=
operations is confronted with two different data formats when=20 handling
referrals and search continuation references.
 
When the application gets a referral status on a search operation,
referral URL information is retrieved by LDAPResponse.getReferrals()
as an array of String objects.
 
When the application gets search continuation references as part = of
the search data, the continuation references are retrieved by
LDAPSearchResultReference.getURLs() as an array of LDAPUrl objects.
 
To be consistent, shouldn't both return an array of LDAPUrl objects?
 
-Steve
 
 
--=_1A429833.2B4A2297-- From list@netscape.com Thu Sep 7 11:18:13 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 LAA18318 for ; Thu, 7 Sep 2000 11:18: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 e87FAcu07896; Thu, 7 Sep 2000 08:10:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87FGfk02740; Thu, 7 Sep 2000 08:16:41 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 08:16:41 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 09:16:06 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: Async operations and automatic referral following in java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7921FA2E.F899F5A0" Resent-Message-ID: <"s4o4ZD.A.iq.YF7t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_7921FA2E.F899F5A0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I am puzzled why the draft specifies that automatic referral following is done only for synchronous operations. While it is simple for an application using async to merge results from=20 multiple listeners or to specify the same listener for multiple requests, it is not so simple to determine when a request and all its child referral requests are complete. Why put this burden on the application? IMO there is no technical reason that automatic referral following mechanisms cannot be used across the board, for both synchronous and asynchronous operations. Could you fill me in on the reason for the current design. Thanks -Steve --=_7921FA2E.F899F5A0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
I am puzzled why the draft specifies that automatic referral
following is done only for synchronous operations.  While
it is simple for an application using async to merge results from =
multiple listeners or to specify the same listener for multiple
requests, it is not so simple to determine when a request
and all its child referral requests are complete.  Why put
this burden on the application?
 
IMO there is no technical reason that automatic referral
following mechanisms cannot be used across the board,
for both synchronous and asynchronous operations.
 
Could you fill me in on the reason for the current design.
 
Thanks
 
-Steve
--=_7921FA2E.F899F5A0-- From list@netscape.com Thu Sep 7 14:20: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 SMTP id OAA22741 for ; Thu, 7 Sep 2000 14:20: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 e87I7BV11067; Thu, 7 Sep 2000 11:07:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87IHNI03002; Thu, 7 Sep 2000 11:17:23 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 11:17:23 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 12:17:00 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: Can't automatically follow referrals - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_89D10AB4.DBBAD69B" Resent-Message-ID: <"g4LcmB.A.Ku.wu9t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_89D10AB4.DBBAD69B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Re: referrals as defined in draft-ietf-ldapext-ldap-java-api-11.txt The I-D seems silent on what happens if an application has automatic referral handling enabled, and for some reason one or more of the referrals or search continuation references cannot be followed. This could happen for at least three reasons: 1- The bind fails when explicitly binding using the LDAPBind object 2- The bind fails when implicitly binding using anonymous credentials, or when using the LDAPRebind object to obtain credentials 3- None of the servers in the referrals list have the scheme ldap:// specified and thus are ignored (per the draft) (4.7.10) I assume that if automatic referral following succeeds, the application doesn't see any referral URLs, i.e. no LDAPReferralException is thrown when doing LDAPSearchResults.next(), (4.35.4) and LDAPSearchResults.nextElement() (4.35.5) does not return an LDAPReferralException object.=20 The draft indicates that LDAPReferralException is only thrown if automatic referral handling has not been enabled. It doesn't indicate whether the LDAPReferralException object is returned on LDAPSearchResults.getElement(), I assume it is not returned. (4.26) So what happens if a referral cannot automatically be followed. I think the application needs to be notified of this error, and the logical way to do that is to return the referral information to=20 the application. IMO, LDAPReferralException should be returned / thrown on synchronous operations any time a referral is not followed, not just if automatic referral following is disabled. Thus, LDAPReferralException would always be returned / thrown if automatic referal following is not enabled. If enabled,=20 LDAPReferralException would be thrown / returned when none of the servers in a referral response list can be used to follow the referral and would be treated by the application as an error situation. Changing the draft to reflect this will clear up these issues. Thanks, -Steve --=_89D10AB4.DBBAD69B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Re: referrals as defined in draft-ietf-ldapext-ldap-java-api-11.txt
 
The I-D seems silent on what happens if an application has automatic
referral handling enabled, and for some reason one or more of=20 the
referrals or search continuation references cannot be followed.
 
This could happen for at least three reasons:
1- The bind fails when explicitly binding using the=20 LDAPBind object
2- The bind fails when implicitly binding using anonymous=20 credentials,
     or when using the LDAPRebind object to = obtain=20 credentials
3- None of the servers in the referrals list have the scheme = ldap://
   specified and thus are ignored (per the draft) (4.7.10)
 
I assume that if automatic referral following succeeds, the
application doesn't see any referral URLs, i.e. no=20 LDAPReferralException
is thrown when doing LDAPSearchResults.next(), (4.35.4) and
LDAPSearchResults.nextElement() (4.35.5) does not return an
LDAPReferralException object.
 
The draft indicates that LDAPReferralException is only thrown
if automatic referral handling has not been enabled.  It = doesn't
indicate whether the LDAPReferralException object is returned
on LDAPSearchResults.getElement(), I assume it is not returned.=20 (4.26)
 
So what happens if a referral cannot automatically be followed.
I think the application needs to be notified of this error, and = the
logical way to do that is to return the referral information to =
the application.
 
IMO, LDAPReferralException should be returned / thrown on
synchronous operations any time a referral is not followed, not = just
if automatic referral following is disabled.
 
Thus, LDAPReferralException would always be returned / thrown
if automatic referal following is not enabled.  If enabled, =
LDAPReferralException would be thrown / returned when none of
the servers in a referral response list can be used to follow = the=20 referral
and would be treated by the application as an error situation.
 
Changing the draft to reflect this will  clear up these = issues.
 
Thanks,
 
-Steve
 
 
 
--=_89D10AB4.DBBAD69B-- From list@netscape.com Thu Sep 7 14:28: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 SMTP id OAA22879 for ; Thu, 7 Sep 2000 14:28: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 e87IFZV13475; Thu, 7 Sep 2000 11:15:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87IPlI07862; Thu, 7 Sep 2000 11:25:47 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 11:25:47 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 12:25:34 -0600 From: "Steven Merrill" To: , , "Jim Sermersheim" , "Steve Sonntag" Cc: "Alan Clark" Subject: Re: Async operations and automatic referral following in java-api-11 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 e87IPjr07821 Resent-Message-ID: <"2XwGTD.A.c6B.p29t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit >>> "Steve Sonntag" (Steve Sonntag) 09/07/00 09:16AM >>> I am puzzled why the draft specifies that automatic referral following is done only for synchronous operations. While it is simple for an application using async to merge results from multiple listeners or to specify the same listener for multiple requests, it is not so simple to determine when a request and all its child referral requests are complete. Why put this burden on the application? IMO there is no technical reason that automatic referral following mechanisms cannot be used across the board, for both synchronous and asynchronous operations. Could you fill me in on the reason for the current design. Thanks -Steve From list@netscape.com Thu Sep 7 15:58: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 SMTP id PAA25523 for ; Thu, 7 Sep 2000 15:58: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 e87Jk9V01667; Thu, 7 Sep 2000 12:46:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87JuLY22688; Thu, 7 Sep 2000 12:56:21 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 12:56:21 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 13:56:11 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: LDAPBind needs - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D9815ACD.71107C5D" Resent-Message-ID: <"DLERxD.A.OiF.kL_t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_D9815ACD.71107C5D Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt It is unclear from the draft how the LDAPConnection object must be used by an application implementing the LDAPBind interface. I am guessing that the LDAPConnection object passed to the bind() method of the LDAPBind implementation is a new LDAPConnection object created by automatic referall following code in the original LDAPConnection= object. The object contains the AuthenticationDN and AuthenticationPassword from the LDAPConnection that the continuation reference was received on. The Host and Port are filled in from the referral/reference host & port. When passed to the bind() method, neither connect nor bind has been performed on this LDAPConnection object. In order to make this work, I believe the iimplementation of the LDAPBind.bind() method MUST use the LDAPConnection object, which was passed as a parameter, to perform its connect and bind calls. It then returns success if both operations succeed. The original LDAPConnection object referral handling code can then use the new LDAPConnection object when it resends the search request, updated with the new search base and possibly search filter. The above should be clarified in the draft. It seems that the LDAPRebind interface would be easier to implement if additional data were provided in the new LDAPConnection object. Such as: 1. A reference to the LDAPSocketFactory class from the original LDAPConnect= ion object. This allows it to connect in the same way as the original = connection. 2. An LDAPConstraints object containing a reference to the LDAPRebind = object from the original LDAPConnection object. The LDAPBind.bind() method = may want to get authentication information using and LDAPRebindAuth = object, and this gives it a way to do that. 3. The protocol version used in the connect/bind of the original object. = This allows The LDAPBind.bind function to bind with same protocol version used in = the original connection. 4. The mechanism used when binding. This could be the mechanism used on = the bind in the original LDAPConnection object, or perhaps LDAPRebindAuth = could be modified to provide the triplet - UserDN, Password, and Mechanism = for the specified host. IMO the above changes would give the application, using explicit bind, = greater flexibility=20 when dealing with referrals / continuation references during automatic = referral following: Comments? Thanks, Steve --=_D9815ACD.71107C5D Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt
 
It is unclear from the draft how the LDAPConnection object = must=20 be
used by an application implementing the LDAPBind interface.
 
I am guessing that the LDAPConnection object passed to the bind()
method of the LDAPBind implementation is a new LDAPConnection = object
created by automatic referall following code in the original=20 LDAPConnection
object. The object contains the  AuthenticationDN and
AuthenticationPassword from the LDAPConnection that the continuation
reference was received on. The Host and Port are filled in from = the
referral/reference host & port. When passed to the bind() = method,
neither connect nor bind has been performed on this LDAPConnection=20 object.
 
In order to make this work, I believe the iimplementation of = the
LDAPBind.bind() method MUST use the LDAPConnection object, which
=
was passed as a parameter, to perform its connect and bind calls.
It then returns success if both operations succeed.  The=20 original
LDAPConnection object referral handling code can then use the
new LDAPConnection object when it resends the search request,
updated with the new search base and possibly search filter.
 
The above should be clarified in the draft.
 
It seems that the LDAPRebind interface would be easier to implement=20= if
additional data were provided in the new LDAPConnection object.  = Such=20 as:
 
1. A reference to the LDAPSocketFactory class from the original=20 LDAPConnection
    object.  This allows it to connect in the = same way=20 as the original connection.
2. An LDAPConstraints object containing a reference to the LDAPRebind= =20 object
    from the original LDAPConnection object.  = The=20 LDAPBind.bind() method may
    want to get authentication information using = and=20 LDAPRebindAuth object, and
    this gives it a way to do that.
3. The protocol version used in the connect/bind of the original=20 object.  This allows
    The LDAPBind.bind function to bind with same = protocol=20 version used in the
    original connection.
4. The mechanism used when binding.  This could be the mechanism = used=20 on the
    bind in the original LDAPConnection object, = or=20 perhaps LDAPRebindAuth could
    be modified to provide the triplet - UserDN, = Password,=20 and Mechanism for the
    specified host.
 
IMO the above changes would give the application, using explicit = bind,=20 greater flexibility
when dealing with referrals / continuation references during = automatic=20 referral
following:
 
Comments?
 
Thanks,
 
Steve
--=_D9815ACD.71107C5D-- From list@netscape.com Thu Sep 7 16:06: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 SMTP id QAA25971 for ; Thu, 7 Sep 2000 16:06: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 e87Jwju14936; Thu, 7 Sep 2000 12:58:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87K4mI28066; Thu, 7 Sep 2000 13:04:48 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 13:04:48 -0700 (PDT) Message-ID: <39B7F4E4.D157122D@netscape.com> Date: Thu, 07 Sep 2000 13:04:52 -0700 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,sv,ja MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com, Jim Sermersheim , Alan Clark , Steven Merrill Subject: Java LDAP API comments References: 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 e87K4Tr27913 Resent-Message-ID: <"ULlB3C.A.y0G.dT_t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Steve, I haven't been able to respond immediately to the many messages of the past week with comments on the latest LDAP Java API draft, but I have been diligently collecting them and I plan to respond soon. My preliminary take is that there is enough substance to justify a new draft, and I'll submit one in a couple of weeks if that is the case. Thanks for all your (and Steven Merrill's) input! Rob Steve Sonntag wrote: > Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt It is unclear from the draft how the LDAPConnection object must beused by an application implementing the LDAPBind interface. I am guessing that the LDAPConnection object passed to the bind()method of the LDAPBind implementation is a new LDAPConnection objectcreated by automatic referall following code in the original LDAPConnectionobject. The object contains the AuthenticationDN andAuthenticationPassword from the LDAPConnection that the continuationreference was received on. The Host and Port are filled in from thereferral/reference host & port. When passed to the bind() method,neither connect nor bind has been performed on this LDAPConnection object. In order to make this work, I believe the iimplementation of theLDAPBind.bind() method MUST use the LDAPConnection object, whichwas passed as a parameter, to perform its connect and bind calls.It then returns success if both operations succeed. The origina! lLDAPConnection object referral handling code can then use thenew LDAPConnection object when it resends the search request,updated with the new search base and possibly search filter. The above should be clarified in the draft. It seems that the LDAPRebind interface would be easier to implement ifadditional data were provided in the new LDAPConnection object. Such as: 1. A reference to the LDAPSocketFactory class from the original LDAPConnection object. This allows it to connect in the same way as the original connection.2. An LDAPConstraints object containing a reference to the LDAPRebind object from the original LDAPConnection object. The LDAPBind.bind() method may want to get authentication information using and LDAPRebindAuth object, and this gives it a way to do that.3. The protocol version used in the connect/bind of the original object. This allows The LDAPBind.bind function to bind with same protocol version used in the original connection.4. Th! e mechanism used when binding. This could be the mechanism used on th indAuth could be modified to provide the triplet - UserDN, Password, and Mechanism for the specified host. IMO the above changes would give the application, using explicit bind, greater flexibilitywhen dealing with referrals / continuation references during automatic referralfollowing: Comments? Thanks, Steve From list@netscape.com Thu Sep 7 16:34: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 SMTP id QAA26575 for ; Thu, 7 Sep 2000 16:34: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 e87JDDu05563; Thu, 7 Sep 2000 12:13:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87IrOQ22090; Thu, 7 Sep 2000 11:53:24 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 11:53:24 -0700 (PDT) Message-Id: <4.3.2.7.0.20000907113733.00b49a30@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Sep 2000 11:52:36 -0700 To: "Steven Merrill" From: "Kurt D. Zeilenga" Subject: Re: Async operations and automatic referral following in java-api-11 Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"NvyjYD.A.eYF.hQ-t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:25 PM 9/7/00 -0600, Steven Merrill wrote: >IMO there is no technical reason that automatic referral >following mechanisms cannot be used across the board, >for both synchronous and asynchronous operations. There are security issues which taken into consideration. Many of the issues were discussed previously on this list (primarily in regard to the C API, but they apply here as well). IMO, chasing of referrals should not be done without some form of user authorization as chasing exposes information (even in the anonymous case) about the user. I also believe the low-level API (async) should have a direct relationship to protocol data units. One API call to send a PDU, one API call to receive a PDU. Higher level functionality should be layered, not embedded. Kurt From list@netscape.com Thu Sep 7 16:38: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 SMTP id QAA26644 for ; Thu, 7 Sep 2000 16:37: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 e87JAcu04623; Thu, 7 Sep 2000 12:10:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87IwiI25004; Thu, 7 Sep 2000 11:58:44 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 11:58:44 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 12:58:23 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: LDAPBind vs LDAPRebind objects - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4B13C848.63026E3F" Resent-Message-ID: <"HLdWSB.A.UGG.jV-t5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_4B13C848.63026E3F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I would like clarification on how LDAPBind vs LDAPRebind objects are used in the Java API. The I-D implies, but never quite says that the two objects don't=20 normally exist in the LDAPConstraints object at the same time. (Implied by Appendix G - LDAPConstraints - they should not be specified on the same constructor) They certainly can both be set by using the set methods, but are probably not both used at the same time. I surmise from the draft that these objects are used as follows: 1. Neither object is used unless Referrals are enabled in the LDAPConstraint object (automatic referral following enabled). 2. An LDAPRebind object is used only if present and if an LDAPBind object is not present in the LDAPConstraint object. 3. An LDAPBind object is used if present. If present, the LDAPRebind object is not needed by LDAPConnection as no implicit binding is done. Explicit binding is the responsibility of the LDAPBind object. = Therefore the LDAPRebind object is not used in this case. If my guesses are correct, maybe the draft should be clarified as to the usage of these objects. Thanks, -Steve --=_4B13C848.63026E3F Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
I would like clarification on how LDAPBind vs LDAPRebind objects
=
are used in the Java API.
 
The I-D implies, but never quite says that the two objects don't =
normally exist in the LDAPConstraints object at the same time.
(Implied by Appendix G - LDAPConstraints - they should
not be specified on the same constructor)
 
They certainly can both be set by using the set methods, but
are probably not both used at the same time.
 
I surmise from the draft that these objects are used as follows:
=
 
1. Neither object is used unless Referrals are enabled in = the
    LDAPConstraint object (automatic referral = following=20 enabled).
 
2. An LDAPRebind object is used only if present and if an=20 LDAPBind
    object is not present in the LDAPConstraint=20 object.
 
3. An LDAPBind object is used if present.  If present, = the=20 LDAPRebind
    object is not needed by LDAPConnection as no = implicit=20 binding is done.
    Explicit binding is the responsibility of the = LDAPBind=20 object.  Therefore
    the LDAPRebind object is not used in this = case.
 
If my guesses are correct, maybe the draft should be clarified as = to=20 the
usage of these objects.
 
Thanks,
 
-Steve
 
 
--=_4B13C848.63026E3F-- From list@netscape.com Thu Sep 7 18:16:05 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 SMTP id SAA28327 for ; Thu, 7 Sep 2000 18:16: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 e87M1pu06593; Thu, 7 Sep 2000 15:01:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87Lv9E12765; Thu, 7 Sep 2000 14:57:09 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 14:57:09 -0700 (PDT) Message-ID: <39B80F1C.D3AE1BFB@novell.com> Date: Thu, 07 Sep 2000 15:56:44 -0600 From: Steven Sonntag Organization: Novell, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com, rweltman@netscape.com, Jim Sermersheim , Alan Clark , Steven Merrill Subject: Re: LDAPBind needs - java-api-11 draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0g8m9C.A.uGD.z8Au5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Steve Sonntag wrote: > Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt It > is unclear from the draft how the LDAPConnection object must beused by > an application implementing the LDAPBind interface. I am guessing that > the LDAPConnection object passed to the bind()method of the LDAPBind > implementation is a new LDAPConnection objectcreated by automatic > referall following code in the original LDAPConnectionobject. The > object contains the AuthenticationDN andAuthenticationPassword from > the LDAPConnection that the continuationreference was received on. The > Host and Port are filled in from thereferral/reference host & port. > When passed to the bind() method,neither connect nor bind has been > performed on this LDAPConnection object. In order to make this work, I > believe the iimplementation of theLDAPBind.bind() method MUST use the > LDAPConnection object, whichwas passed as a parameter, to perform its > connect and bind calls.It then returns success if both operations > succeed. The originalLDAPConnection object referral handling code can > then use thenew LDAPConnection object when it resends the search > request,updated with the new search base and possibly search filter. > > It is also necessary that the application implementing the > LDAPBind.bind() > method use a synchronous bind do bind to the referred-to-server, or > if using an asyncronous bind, it must wait until the bind operation > has > completed before returnint status. > > -Steve > > > > > > > The above should be clarified in the draft. It seems that the > LDAPRebind interface would be easier to implement ifadditional data > were provided in the new LDAPConnection object. Such as: 1. A > reference to the LDAPSocketFactory class from the original > LDAPConnection object. This allows it to connect in the same way > as the original connection.2. An LDAPConstraints object containing a > reference to the LDAPRebind object from the original LDAPConnection > object. The LDAPBind.bind() method may want to get authentication > information using and LDAPRebindAuth object, and this gives it a > way to do that.3. The protocol version used in the connect/bind of the > original object. This allows The LDAPBind.bind function to bind > with same protocol version used in the original connection.4. The > mechanism used when binding. This could be the mechanism used on > the bind in the original LDAPConnection object, or perhaps > LDAPRebindAuth could be modified to provide the triplet - UserDN, > Password, and Mechanism for the specified host. IMO the above > changes would give the application, using explicit bind, greater > flexibilitywhen dealing with referrals / continuation references > during automatic referralfollowing: Comments? Thanks, Steve From list@netscape.com Thu Sep 7 19:01: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 SMTP id TAA28890 for ; Thu, 7 Sep 2000 19:01: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 e87MnaV05807; Thu, 7 Sep 2000 15:49:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87MtW610794; Thu, 7 Sep 2000 15:55:32 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 15:55:32 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 16:35:34 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: Reverral vs Continuation Reference - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9BC3176E.DFBED2E8" Resent-Message-ID: <"Cq_-J.A._lC.czBu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_9BC3176E.DFBED2E8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The I-D interchanges referrals and search continuation references. A referral happens only on an operation and no other results are returned. A search continuation reference happens only on a search and is mixed in = with returned search entries. The I-D refers to continuation references only in section 2.2 and 2.34.=20 It sometimes uses referrals where search continuation references should be used, and generally where both apply. Line 473 - referred to -> referred-to The following should probably refer to both referrals and continuation = references Section 1: line 459, 468 Section 2.2: LDAPRebind / LDAPBind=20 Section 2.3 - LDAPRebindAuth=20 Section 2.4 - LDAPReferralException Section 4.4 - LDAPBind=20 Section 4.7.x - doReferrals / binder /reauth / hop_limit Section 4.7.x - RebindProc, BindProc, Referrals as well as the methods to get and set the above Section 4.24 - LDAPRebindAuth Section 4.25 - LDAPRebind Section 4.26 - LDAPReferralException Section 4.27 - LDAPResponse The following refer to search references Section 4.31.1 - LDAPSearchConstraints - doReferrals, reauth binder, = hop_limit params Section 4.35.4 - LDAPSearchResults.next() Section 4.35.5 - LDAPSearchResults.nextElement() Section 4.39.13 - SetOption ( search options relating to referrals) -Steve --=_9BC3176E.DFBED2E8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The I-D interchanges referrals and search continuation references.
 
A referral happens only on an operation and no other results are=20 returned.
 
A search continuation reference happens only on a search and is mixed = in=20 with
returned search entries.
 
The I-D refers to continuation references only in section 2.2 and = 2.34.=20
 
It sometimes uses referrals where search continuation references=20 should
be used, and generally where both apply.
 
Line 473 - referred to -> referred-to
 
The following should probably refer to both referrals and continuation= =20 references
Section 1: line 459, 468
Section 2.2: LDAPRebind / LDAPBind
Section 2.3 - LDAPRebindAuth
Section 2.4 - LDAPReferralException
Section 4.4 - LDAPBind
Section 4.7.x - doReferrals / binder /reauth / hop_limit
Section 4.7.x - RebindProc, BindProc, Referrals
    as well as the methods to get and set the = above
Section 4.24 - LDAPRebindAuth
Section 4.25 - LDAPRebind
Section 4.26 - LDAPReferralException
Section 4.27 - LDAPResponse
 
The following refer to search references
 
Section 4.31.1 - LDAPSearchConstraints - doReferrals, reauth = binder,=20 hop_limit params
Section 4.35.4 - LDAPSearchResults.next()
Section 4.35.5 - LDAPSearchResults.nextElement()
Section 4.39.13 - SetOption ( search options relating to referrals)
 
-Steve
 
 
 
 
 
 
--=_9BC3176E.DFBED2E8-- From list@netscape.com Thu Sep 7 19:04: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 SMTP id TAA28945 for ; Thu, 7 Sep 2000 19:04: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 e87MowV06222; Thu, 7 Sep 2000 15:50:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87MtJ610512; Thu, 7 Sep 2000 15:55:19 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 15:55:19 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 16:38:29 -0600 From: "Steve Sonntag" To: , , "Alan Clark" , "Jim Sermersheim" , "Steven Merrill" Subject: Re: LDAPBind needs - java-api-11 draft - resend 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 e87Msdr10272 Resent-Message-ID: <"cgnI5B.A.liC.TzBu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Resend - properly indicating where comments are Steve Sonntag wrote: > Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt It > is unclear from the draft how the LDAPConnection object must beused by > an application implementing the LDAPBind interface. I am guessing that > the LDAPConnection object passed to the bind()method of the LDAPBind > implementation is a new LDAPConnection objectcreated by automatic > referall following code in the original LDAPConnectionobject. The > object contains the AuthenticationDN andAuthenticationPassword from > the LDAPConnection that the continuationreference was received on. The > Host and Port are filled in from thereferral/reference host & port. > When passed to the bind() method,neither connect nor bind has been > performed on this LDAPConnection object. In order to make this work, I > believe the iimplementation of theLDAPBind.bind() method MUST use the > LDAPConnection object, whichwas passed as a parameter, to perform its > connect and bind calls.It then returns success if both operations > succeed. The originalLDAPConnection object referral handling code can > then use thenew LDAPConnection object when it resends the search > request,updated with the new search base and possibly search filter. It is also necessary that the application implementing the LDAPBind.bind() method use a synchronous bind do bind to the referred-to-server, or if using an asyncronous bind, it must wait until the bind operation has completed before returning status. -Steve > > > > > > > The above should be clarified in the draft. It seems that the > LDAPRebind interface would be easier to implement ifadditional data > were provided in the new LDAPConnection object. Such as: 1. A > reference to the LDAPSocketFactory class from the original > LDAPConnection object. This allows it to connect in the same way > as the original connection.2. An LDAPConstraints object containing a > reference to the LDAPRebind object from the original LDAPConnection > object. The LDAPBind.bind() method may want to get authentication > information using and LDAPRebindAuth object, and this gives it a > way to do that.3. The protocol version used in the connect/bind of the > original object. This allows The LDAPBind.bind function to bind > with same protocol version used in the original connection.4. The > mechanism used when binding. This could be the mechanism used on > the bind in the original LDAPConnection object, or perhaps > LDAPRebindAuth could be modified to provide the triplet - UserDN, > Password, and Mechanism for the specified host. IMO the above > changes would give the application, using explicit bind, greater > flexibilitywhen dealing with referrals / continuation references > during automatic referralfollowing: Comments? Thanks, Steve From list@netscape.com Thu Sep 7 19:11: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 SMTP id TAA29128 for ; Thu, 7 Sep 2000 19:10: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 e87MxIV07582; Thu, 7 Sep 2000 15:59:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87N9Uw18433; Thu, 7 Sep 2000 16:09:30 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 16:09:30 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 16:56:57 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: LDAPBind needs - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_C69E4A0F.3A5B3730" Resent-Message-ID: <"nqE9M.A.gfE.oACu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_C69E4A0F.3A5B3730 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Re: Referrals on operations as defined in draft-ietf-ldapext-ldap-java-api-11.txt When a referral occurs on an asynchronous operation the referral is returned as an LDAPResponse object. The referral info is obtained using the getReferrals() method. When a referral occurs on a synchronous operation An LDAPException is thrown. The exception object is specialized as an LDAPReferralException object and the referral info can be obtained via the getURLs() method with appropriate casting on the object. Is this correct? Should the doc be clarified? -Steve --=_C69E4A0F.3A5B3730 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Re: Referrals on operations as defined
      in=20 draft-ietf-ldapext-ldap-java-api-11.txt
 
When a referral occurs on an asynchronous operation
   the referral is returned as an LDAPResponse object.
=
   The referral info is obtained using the getReferrals()=20= method.
 
When a referral occurs on a synchronous operation
    An LDAPException is thrown.  The exception = object=20 is
    specialized as an LDAPReferralException = object=20 and
    the referral info can be obtained via the = getURLs()=20 method
    with appropriate casting on the object.
 
Is this correct?
 
Should the doc be clarified?
 
-Steve
 
--=_C69E4A0F.3A5B3730-- From list@netscape.com Thu Sep 7 19:12: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 SMTP id TAA29165 for ; Thu, 7 Sep 2000 19:12: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 e87N4ou18208; Thu, 7 Sep 2000 16:04:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e87NAsM19413; Thu, 7 Sep 2000 16:10:54 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 16:10:54 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 07 Sep 2000 17:10:19 -0600 From: "Steven Merrill" To: , , "Jim Sermersheim" , "Steve Sonntag" Cc: "Alan Clark" Subject: LDAP_PARTIAL_RESULTS - java-api-11 draft 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 e87NApr19386 Resent-Message-ID: <"lkSGzC.A.DvE.8BCu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Re: LDAP_PARTIAL_RESULTS Result Code defined in section 4.16.6 of draft-ietf-ldapext-ldap-java-api-11.txt Section 4.16.6 instructs the reader to review RFC 2251 for a discussion of the meanings of the codes defined in that section. RFC 2251 does not discuss the meaning of the LDAP_PARTIAL_RESULTS result code. Should this be defined or referenced in this draft? -Steve From list@netscape.com Thu Sep 7 22:36:14 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 SMTP id WAA03427 for ; Thu, 7 Sep 2000 22:36: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 e882Sfu23134; Thu, 7 Sep 2000 19:28:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e882YjA20230; Thu, 7 Sep 2000 19:34:45 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 19:34:45 -0700 (PDT) Date: Thu, 7 Sep 2000 19:34:24 -0700 (PDT) Message-Id: <200009080234.e882YEf24939@ywing.netscape.com> From: freewebsites@NNRH.cyberteamusa.com To: customer.RRJW@netscape.com Subject: WEBSITE MANIA! -PVYQ X-Reply-To: freewebsites@cyberteamusa.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jo1AO.A.G7E.CBFu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit <<<<<< WEBSITE MANIA >>>>>>> FANTASTIC FREE GIVEAWAY! FREE WEB SITES WITH A TWIST - GET PAID TO GIVE THEM AWAY! 100% advertisement (banner free) and 100% yours to do with whatever you desire! (Personal or Business use). Comes with Exclusive Easy to USE Point & Click Technology Built Right In! Our Computer Gurus made it so easy Homer Simpson could do it! Here's your chance to get the word out to your friends, family, associates, everyone you can think of before someone else does and you miss the money. Pre-Launch --- TAKING RESERVATIONS NOW! STEP #1. Reserve yours RIGHT NOW and get more FREE information. Just click the link below and send to PLACE YOUR RESERVATION! mailto:freewebsites@cyberteamusa.com?subject="FREEWebSite" STEP #2. YES it is FREE. And YES, You GET PAID to give them away! We're not talking pennies here! Get my FREE REPORT "How to earn $95,705 in the next 3 to 6 months Giving Away FREE Websites. Click here --- www.tgray@getresponse.com I repeat - this NEW TO THE NET program can be done with NO cash outlay and NO monthly cost to participate ! * The Window of Opportunity is WIDE OPEN! *. We intend to have a million users by the end of the first year – your piece of that could translate into a lifetime income! And NOW is the time to position yourself in this global wave, before thousands of others jump in! (NO SPAM POLICY) You Are Receiving This Mail Because We Either Had Contact Before Or Your Name Appeared On A Safe E-Mail List That We Both Belong To, Or It Was On An Ad To Make Money And To Receive Money. If You Wish To Be Removed, Simply click the reply button and type REMOVE as text. If Offended You In Any Way Shape Or Form, Please Accept My Sincere Apology. From list@netscape.com Fri Sep 8 00:42: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 SMTP id AAA04993 for ; Fri, 8 Sep 2000 00:42: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 e884SkV16170; Thu, 7 Sep 2000 21:28:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e884cxA18979; Thu, 7 Sep 2000 21:38:59 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 21:38:59 -0700 (PDT) Date: Thu, 7 Sep 2000 21:38:31 -0700 (PDT) Message-Id: <200009080438.e884cKL13855@xwing.netscape.com> From: freewebsites@GBPA.cyberteamusa.com To: customer.PFIO@netscape.com Subject: WEBSITE MANIA! -HGPI X-Reply-To: freewebsites@cyberteamusa.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bc1z9C.A.FoE.h1Gu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit <<<<<< WEBSITE MANIA >>>>>>> FANTASTIC FREE GIVEAWAY! FREE WEB SITES WITH A TWIST - GET PAID TO GIVE THEM AWAY! 100% advertisement (banner free) and 100% yours to do with whatever you desire! (Personal or Business use). Comes with Exclusive Easy to USE Point & Click Technology Built Right In! Our Computer Gurus made it so easy Homer Simpson could do it! Here's your chance to get the word out to your friends, family, associates, everyone you can think of before someone else does and you miss the money. Pre-Launch --- TAKING RESERVATIONS NOW! STEP #1. Reserve yours RIGHT NOW and get more FREE information. Just click the link below and send to PLACE YOUR RESERVATION! mailto:freewebsites@cyberteamusa.com?subject="FREEWebSite" STEP #2. YES it is FREE. And YES, You GET PAID to give them away! We're not talking pennies here! Get my FREE REPORT "How to earn $95,705 in the next 3 to 6 months Giving Away FREE Websites. Click here --- www.tgray@getresponse.com I repeat - this NEW TO THE NET program can be done with NO cash outlay and NO monthly cost to participate ! * The Window of Opportunity is WIDE OPEN! *. We intend to have a million users by the end of the first year – your piece of that could translate into a lifetime income! And NOW is the time to position yourself in this global wave, before thousands of others jump in! (NO SPAM POLICY) You Are Receiving This Mail Because We Either Had Contact Before Or Your Name Appeared On A Safe E-Mail List That We Both Belong To, Or It Was On An Ad To Make Money And To Receive Money. If You Wish To Be Removed, Simply click the reply button and type REMOVE as text. If Offended You In Any Way Shape Or Form, Please Accept My Sincere Apology. From list@netscape.com Fri Sep 8 01:41: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 SMTP id BAA09343 for ; Fri, 8 Sep 2000 01:41:49 -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 e885YJu09410; Thu, 7 Sep 2000 22:34:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e885bOY07631; Thu, 7 Sep 2000 22:37:24 -0700 (PDT) Resent-Date: Thu, 7 Sep 2000 22:37:24 -0700 (PDT) Message-Id: <200009080537.e885bLf10884@ywing.netscape.com> From: "horizonsea,inc." To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Thu, 7 Sep 2000 22:31:18 Resent-Message-ID: <"ki0dVC.A.72B.TsHu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com

Re-ESTABLISH YOUR CREDIT
 

Your MASTER CARD and VISA Are GUARANTEED

  
 

There are Banks Looking for:

 
 

GOOD PEOPLE with BAD CREDIT

  
 

If you're like most Americans, you've had hard economic times at one time or another. Because of our country's current Economic Boom, there are Creditors with Surplus Money Supplies, and they're looking for good honest people, that want to turn their lives around. Even if you're currently on Welfare, or Disability, as long as you have the desire to become part of the American Mainstream, there are Lender's, who will take a chance. We, at HORIZON SEA, INC., will Guarantee your acceptance for a Master Card and/or Visa, with one of the many lending institutions that are looking for Credit Challenged People, Folks who are looking to change their Lives. Would a GOLD CARD change your life? For a mere $29.95, we offer a Money Back Guarantee if we are unable to secure a lender who will grant you a Line of Credit. We will refund your money, It's our confidence and success that allow us to do this… Let us change your life.

  
  Please print and return this page:
Make check or money order for 29.95 payable to :		  
  Horizon Sea Inc.
11954 N.E. Glisan
PMB 204
Portland, OR
97220-2143		      
  Name: ____________________________
Address: __________________________
Address 2:_________________________
State:_____________________________
Zip: ______________________________
e-mail: ____________________________
Phone: (optional) ____________________		  
  Upon receipt of your payment we will contact you via e-mail within 48 hours.  
  This message is sent in compliance of the new e-mail bill:SECTION 301.
Sender: Horizon Sea Inc.
email: advertising@horizonsea.com
"Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line." 		 
         
         
         

 

 

 

From list@netscape.com Fri Sep 8 10:22: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 SMTP id KAA23332 for ; Fri, 8 Sep 2000 10:22: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 e88E9wV07070; Fri, 8 Sep 2000 07:09:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88EKCQ03520; Fri, 8 Sep 2000 07:20:12 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 07:20:12 -0700 (PDT) Message-ID: <057f01c019ef$6f1b1d60$3029b0cb@x3y0t8> From: "FEDERICO B. ISON, JR." To: Subject: Amazingly Great Opportunity - 95% Pay-Out! Date: Fri, 8 Sep 2000 16:24:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057C_01C019B4.C2BC4560" 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: <"0BSDo.A.t2.aWPu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: 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_057C_01C019B4.C2BC4560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable INCREDIBLE BUT TRUE! INVESTIGATE! The Only Company That Pays 95% Commission! A must to do; The Potential is Incredible; Highly Recommended! ---------------------------------------------------------- =20 Do your own math here;=20 a.. $50 Fast-Start on all referrals=20 b.. $20 Fast-Start on all 2nd level referrals=20 c.. $25 to the 2 x 25 matrix up to the 25 levels deep.=20 For full details, simply reply with "please forward 95% pay-out" as = text. =20 = *************************************************************************= ************************* $10. Investment =3D FREE Groceries, Fuels, Health Maintenance, Phone & = Cellphone Bills, Car Amortization, Mortgages & Computers plus a Monthly = Residual Income for Retirement. No Hidden Cost and No Other Cost To Pay! = Two minutes is all you need to start.=20 =20 For full details, just reply with "forward info on $10 investment".as = text.=20 = *************************************************************************= ************************* =20 MAKE $100 - $300 DAILY PART-TIME WORK AT HOME! Huge Potential - A Must To Do! = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ranking=3D 10 ; Risk=3D 0 ; Returns=3D INCREDIBLE; HIGHLY RECOMMENDED ----------------------------------------------------- =20 =20 We are looking for an individual who wants to earn $100 - $300 daily = part-time doing a simple computer work at home. We will train and guide = them along the way and we will help them get started immediately.=20 =20 QUALIFICATIONS: Must be willing to learn, willing to work atleast one = hour a day online, ambitious and with a desire to be successful. =20 If you believe you are qualified and wants to get started immediately, = simply reply to this e-mail with "HELP ME GET STARTED" as text. =20 = *************************************************************************= ************************* =20 "PROJECT 21 - NO START COST - HUGE POTENTIAL -=20 A MUST TO READ" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ranking=3D 10 ; Risk=3D 0 ; Returns=3D INCREDIBLE; HIGHLY RECOMMENDED=20 -------------------------------------------------------------- This is huge. You can earn $2,000 per week part-time or $5,000 per week = full-time using your computer at home. You only need 1 hour a day of = easy and simple work. And the best part of it is... it's FREE to join!=20 HERE IS WHAT I GOT: a.. FREE TO JOIN - you don't have to pay anything to join=20 b.. EASY TO PROMOTE - 40 pages of information to get you started (pre written ads etc.), Also it's easy to promote=20 because it's FREE to JOIN.=20 c.. HUGE POTENTIAL - Earn the money you so desire for a long time at = your own pace, your own time, while you enjoy the things you loved with = your family. This is proven. You will be overwhelmed by the result that = you will get.=20 d.. YOU PAY ONLY WHEN YOU ARE SURE YOU"LL EARN - Like I told you = it's FREE to join but after 30 days you have to decide if you would like = to continue your membership. At that point if you have enough clients = I'm sure you'll be very happy to pay your monthly fee of $90, remain in = the program and .... MAKE MONEY...... I've been promoting this program for a very short period of time and so far I have 47 clients which means that I have=20 residual monthly income of $4300. And all this after 20-30=20 hours of promotion with 0 (ZERO) dollars investment. This is the type of program that you want to scream about. Let the whole = world know about it. For more information, simply reply to this email with "PROJECT 21=20 INFO" as text. Regards, Federico B. Ison, Jr. PS. I am willing to show you how to send your business or ads to=20 "ONE MILLION" safe, opt-in, 100% spam-free e-mails daily using=20 100% legal mailing system or your money back. =20 = -------------------------------------------------------------------------= ----------------------------------------------------- (NO SPAM POLICY) You Are Receiving This Mail Because We Either Had = Contact Before Or Your Name Appeared On A Safe E-Mail List That We Both = Belong To, Or It Was On An Ad To Make Money And To Receive Money. If = You Wish To Be Removed, Simply click the reply button and type REMOVE as = text. If Offended You In Any Way Shape Or Form, Please Accept My Sincere = Apology. ------=_NextPart_000_057C_01C019B4.C2BC4560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
INCREDIBLE BUT=20 TRUE! INVESTIGATE!
 The Only Company That Pays 95%=20 Commission!
A must to do; The Potential is Incredible; Highly=20 Recommended!
----------------------------------------------------------
 
Do your own math here;
  • $50 Fast-Start on all referrals=20
  • $20 Fast-Start on all 2nd level referrals=20
  • $25 to the 2 x 25 matrix up to the 25 levels = deep.=20
For full details, simply reply with "please forward 95% = pay-out"=20 as text.
 
 =20 *************************************************************************= *************************
$10. = Investment =3D=20 FREE Groceries, Fuels, Health Maintenance, Phone &=20 Cellphone Bills, Car Amortization, Mortgages & Computers plus a = Monthly=20 Residual Income for Retirement. No Hidden Cost and No Other Cost To Pay! = Two=20 minutes is all you need to start.
 
For full details, just reply with "forward info on $10=20 investment".as text.
 =20 *************************************************************************= *************************
 
MAKE $100 - $300 = DAILY PART-TIME=20 WORK AT HOME!
Huge Potential - A Must To Do!
   =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ranking=3D 10 ; Risk=3D 0 ; Returns=3D INCREDIBLE; = HIGHLY=20 RECOMMENDED
----------------------------------------------------- = ;        =
 
We are looking for an individual who wants to earn = $100 - $300=20 daily part-time doing a simple computer work at home. We will train and = guide=20 them along the way and we will help them get started=20 immediately. 
 
QUALIFICATIONS: Must be willing to = learn,=20 willing to work atleast one hour a day online, ambitious and with a = desire to be=20 successful.
 
If you believe you are qualified and wants = to get=20 started immediately, simply reply to this e-mail with "HELP ME GET=20 STARTED" as text.  
 
 =20 *************************************************************************= *************************
 
   "PROJECT 21 - = NO=20 START COST - HUGE POTENTIAL -
A MUST TO=20 READ"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ranking=3D=20 10 ; Risk=3D 0 ; Returns=3D INCREDIBLE; HIGHLY RECOMMENDED=20
--------------------------------------------------------------
 
This is huge. You can earn = $2,000 per=20 week part-time or $5,000 per week full-time using your computer at home. = You=20 only need 1 hour a day of easy and simple work. And the best part of it = is...=20 it's FREE to join!

HERE IS WHAT I GOT:

  • FREE TO JOIN - you don't have to pay anything to join=20
  • EASY TO PROMOTE - 40 pages of information to get you
    started = (pre=20 written ads etc.), Also it's easy to promote
    because it's FREE = to JOIN.=20
  • HUGE POTENTIAL - Earn the money you so desire for a long time at = your=20 own pace, your own time, while you enjoy the things you loved with = your=20 family. This is proven. You will be overwhelmed by the result that = you will=20 get.=20
  • YOU PAY ONLY WHEN YOU ARE SURE YOU"LL EARN - Like I told = you it's=20 FREE to join but after 30 days you have to decide if you would like = to=20 continue your membership. At that point if you have enough clients = I'm sure=20 you'll be very happy to pay your monthly fee of $90, remain in the = program=20 and .... MAKE MONEY......
I've been promoting this program for a very short period of
time = and so=20 far I have 47 clients which means that I have
residual monthly = income of=20 $4300. And all this after 20-30
hours of promotion with 0 (ZERO) = dollars=20 investment.

This is the type of program that you want to scream = about.=20 Let the whole world know about it.

For more information, simply = reply to=20 this email with "PROJECT 21
INFO" as text.
 
 
Regards,
 
 
Federico B. Ison, Jr.
 
PS. I am willing to show you how to send your business or ads to =
       "ONE MILLION" safe, = opt-in,=20 100% spam-free e-mails daily using
       100% legal mailing system or = your=20 money back.        
 
 ----------------------------------------------------------------= --------------------------------------------------------------
 
(NO SPAM POLICY)  You = Are Receiving=20 This Mail Because We Either Had Contact Before Or Your Name Appeared On = A Safe=20 E-Mail List That We Both Belong To, Or It Was On An Ad To Make Money And = To=20 Receive Money.  If You Wish To Be Removed, Simply click the reply = button=20 and type REMOVE as text. If Offended You In Any Way Shape Or Form, = Please Accept=20 My Sincere Apology.
------=_NextPart_000_057C_01C019B4.C2BC4560-- From list@netscape.com Fri Sep 8 11:12: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 SMTP id LAA24256 for ; Fri, 8 Sep 2000 11:12: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 e88ExdV12322; Fri, 8 Sep 2000 07:59:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88F9r219351; Fri, 8 Sep 2000 08:09:53 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 08:09:53 -0700 (PDT) From: james897@msn.com Date: Fri, 08 Sep 2000 08:07:15 -0800 Message-Id: <5v3q8s5b6s0dvu.34ty1x6l5i3r3t3o8w3@2s8wdj.localhost> Subject: 3.95% Debt Consolidation! -fnhlreqei To: @netscape.com Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Resent-Message-ID: <"M-6o6D.A.1tE.9EQu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8BIT
The Lender's Network
Mortgage Specialists

We Shop The Best Loan For You!
Rates as low as 3.95%!

The Lenders Network is a 100% free service which lets you shop for a mortgage conveniently and securely from the comfort of your home. Using our vast network of lenders across the U.S., we will search our database of loan programs for the best loans that fit your needs.  Even if you're currently working with another lender or have been turned down before, we can still help.

Choose from these types of loans:
Debt Consolidation, 2nd Mortgage, Refinance, Credit Repair, or Home Improvment.  We also specialize in self employed and (fair to poor credit) borrowers. Competitive rates as low as 3.95%!

Ready to get started? Simply fill out the form below, and we'll begin shopping for your loan.  It's that easy!

Free Mortgage Quote
Contact Information
(* required info)

Name: *
Address: *
City: *
State(US Only): *
Zip/Postal Code: *
Home Phone:  *
Work Phone: *
Email Address:
Best Time to Call:
Do You Own Your Home? Mobile Homes DO NOT Qualify
Current Property Value: * See Below For Qualifications
1st Mortgage Owed: * 
2nd Mortgage Owed: *
Amount You Wish To Borrow: *
Interest Rate on Current Mortgage: *
Monthly Gross Household Income *
Monthly Debt (excluding current mortgage(s)) *
Credit Rating: *
Loan Interested In: *

Email List Removal
Click Here
From list@netscape.com Fri Sep 8 14:06:18 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 SMTP id OAA27221 for ; Fri, 8 Sep 2000 14:06:18 -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 e88Hvmu05343; Fri, 8 Sep 2000 10:57:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88I3rE16388; Fri, 8 Sep 2000 11:03:53 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 11:03:53 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Fri, 08 Sep 2000 12:03:15 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" , "Steve Sonntag" Subject: extendedOperation - I-D java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3B63B6FA.8EEF83F6" Resent-Message-ID: <"mXOYqB.A.V_D.GoSu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_3B63B6FA.8EEF83F6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Section 4.40.3: - LDAPv3.extendedOperation=20 Shouldn't this method have a method that includes LDAPConstraints as an argument. The protocol allows extended operations to support controls. Section 4.40.2 - LDAPV3.connect This special version of connect is really a connect and a bind combinded. Should this also have a method with an LDAPConstraints object? - or if the application needs that should they just do the two separate operations and put the LDAPConstraints on the bind? -Steve --=_3B63B6FA.8EEF83F6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
Section 4.40.3: - LDAPv3.extendedOperation 
   Shouldn't this method have a method that
   includes LDAPConstraints as an argument.
  The protocol allows extended operations to
  support controls.
 
Section 4.40.2 - LDAPV3.connect
  This special version of connect is=20 really
  a connect and a bind combinded. =20 Should
  this also have a method with an=20 LDAPConstraints
  object? - or if the application needs that
  should they just do the two separate=20 operations
  and put the LDAPConstraints on the=20 bind?
 
-Steve
--=_3B63B6FA.8EEF83F6-- From list@netscape.com Fri Sep 8 14: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 SMTP id OAA27849 for ; Fri, 8 Sep 2000 14:46: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 e88IYOV14686; Fri, 8 Sep 2000 11:34:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88Iic205294; Fri, 8 Sep 2000 11:44:38 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 11:44:38 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Fri, 08 Sep 2000 12:23:01 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: implicit bind - I-D java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4018CD9B.6E0F6304" Resent-Message-ID: <"-9mj_B.A.cSB.VOTu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_4018CD9B.6E0F6304 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I think the draft should describe more fully the semantics of the implicit bind w/r automatic referral following: I will describe what the I-D describes and where I have questions: 1. Authentication - uses anonomyous credentials unless LDAPRebind specified in LDAPConstraints. 2. Protocol Version ?? - Does it use the same protocol version as the LDAPConnection receiving the referral or is it always V2?? I vote for the having it the same as the originating connection. 3. AuthenticationMethod: Is it the same as the originating connection, or is it "simple" - I assume simple is used. 4. Does it use the LDAPSocketFactory if specified on the originating connection. I am not sure what to do here. It seems better to use it if available, then an encrypted connection can be established and thus prevent clear text password transmittion on the wire. I just talked myself into it - it should be used. -Steve =20 --=_4018CD9B.6E0F6304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
I think the draft should describe more fully the
semantics of the implicit bind w/r automatic referral following:
=
 
I will describe what the I-D describes and where
I have questions:
 
1. Authentication - uses anonomyous credentials unless
   LDAPRebind specified in LDAPConstraints.
 
2. Protocol Version ?? - Does it use the same protocol
    version as the LDAPConnection receiving = the=20 referral or is it
    always V2??  I vote for the having it the = same as=20 the originating
    connection.
 
3. AuthenticationMethod: Is it the same as the originating=20 connection,
    or is it "simple" - I assume simple is used.
 
4. Does it use the LDAPSocketFactory if specified on the
    originating connection.  I am not = sure=20 what to do here.
    It seems better to use it if available, then an=20 encrypted
    connection can be established and thus prevent
    clear text password transmittion on the wire. = I=20 just
    talked myself into it - it should be used.
 
-Steve
  
--=_4018CD9B.6E0F6304-- From list@netscape.com Fri Sep 8 14:55: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 SMTP id OAA28039 for ; Fri, 8 Sep 2000 14:55: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 e88Im4u16183; Fri, 8 Sep 2000 11:48:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88Is8609662; Fri, 8 Sep 2000 11:54:08 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 11:54:08 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Fri, 08 Sep 2000 12:53:42 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: throwing LDAPReferralException - I-D java-api-11 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7028FDAD.48294524" Resent-Message-ID: <"Y-bR8.A.sWC.PXTu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_7028FDAD.48294524 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable When performing a search it is possible for the server to return multiple search continuation references, each with a different search base. The I-D states that when retrieving results from a search using LDAPSearchResults.next() that all the results are returned to the application after which on the last call to next() an LDAPReferralException is thrown. My question is: how does the application get the rest of the continuation references, as a ReferralException object encapsulates the reference list from one search continuation reply. If the application did another next() call would another LDAPReferralException be thrown? How would the application know when to stop? Does it check the enumeration count to see if more items exist in the enumeration, and thus continue to call next() and get an LDAPReferralException each time. As an alternative, the application could switch to calling nextElement() to get the rest of the search references as LDAPReferralException objects. How do you envision the application doing this? The I-D should make it clear that the application can get more than one search continuation reference, and indicate a mechanism to deal with the situation. -Steve --=_7028FDAD.48294524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
When performing a search it is possible for the server
to return multiple search continuation references, each
with a different search base.
 
The I-D states that when retrieving results from a
search using LDAPSearchResults.next() that all the
results are returned to the application after which
on the last call to next() an LDAPReferralException
is thrown.
 
My question is: how does the application get the
rest of the continuation references, as a
ReferralException object encapsulates the
reference list from one search continuation reply.
 
If the application did another next() call would
another LDAPReferralException be thrown?
How would the application know when to stop?
Does it check the enumeration count to see if
more items exist in the enumeration, and thus
continue to call next() and get an LDAPReferralException
each time.  As an alternative, the application
could switch to calling nextElement() to get the
rest of the search references as LDAPReferralException
objects.  How do you envision the application doing this?
 
The I-D should make it clear that the application
can get more than one search continuation
reference, and indicate a mechanism to deal
with the situation.
 
-Steve
--=_7028FDAD.48294524-- From list@netscape.com Fri Sep 8 15:20: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 SMTP id PAA28584 for ; Fri, 8 Sep 2000 15:20: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 e88JCsu20502; Fri, 8 Sep 2000 12:12:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88JIwc21284; Fri, 8 Sep 2000 12:18:58 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 12:18:58 -0700 (PDT) Message-Id: <4.3.2.7.0.20000908121524.00b38800@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Sep 2000 12:16:05 -0700 To: "Steve Sonntag" From: "Kurt D. Zeilenga" Subject: Re: implicit bind - I-D java-api-11 Cc: , , "Jim Sermersheim" , "Alan Clark" , "Steven Merrill" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"_9Cx-D.A.mKF.duTu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:23 PM 9/8/00 -0600, Steve Sonntag wrote: > >I think the draft should describe more fully the >semantics of the implicit bind w/r automatic referral following: > >I will describe what the I-D describes and where >I have questions: > >1. Authentication - uses anonomyous credentials unless > LDAPRebind specified in LDAPConstraints. > >2. Protocol Version ?? - Does it use the same protocol > version as the LDAPConnection receiving the referral or is it > always V2?? I vote for the having it the same as the originating > connection. > >3. AuthenticationMethod: Is it the same as the originating connection, > or is it "simple" - I assume simple is used. > >4. Does it use the LDAPSocketFactory if specified on the > originating connection. I am not sure what to do here. > It seems better to use it if available, then an encrypted > connection can be established and thus prevent > clear text password transmittion on the wire. I just > talked myself into it - it should be used. 5. StartTLS ? From list@netscape.com Fri Sep 8 15:52: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 SMTP id PAA29116 for ; Fri, 8 Sep 2000 15:52: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 e88Jibu25594; Fri, 8 Sep 2000 12:44:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88JogU03449; Fri, 8 Sep 2000 12:50:42 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 12:50:42 -0700 (PDT) Message-Id: <4.3.2.7.0.20000908122450.00b301b0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Sep 2000 12:50:06 -0700 To: "Steve Sonntag" From: "Kurt D. Zeilenga" Subject: Re: implicit bind - I-D java-api-11 Cc: , , "Jim Sermersheim" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"HZUrOC.A.n1.RMUu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:23 PM 9/8/00 -0600, Steve Sonntag wrote: > >I think the draft should describe more fully the >semantics of the implicit bind w/r automatic referral following: > >I will describe what the I-D describes and where >I have questions: > >1. Authentication - uses anonomyous credentials unless > LDAPRebind specified in LDAPConstraints. Don't chase would be the most secure default. >2. Protocol Version ?? - Does it use the same protocol > version as the LDAPConnection receiving the referral or is it > always V2?? I vote for the having it the same as the originating > connection. If you got a referral/continuation, the originating server should be LDAPv3 (unless this API supports LDAPv2+). The referral/continuation should be chased using LDAPv3 to avoid incompatible results issues. Else the API need to provide either a) a mechanism to allow application to determine the protocol used to obtain each result (which apps are not likely to use) or b) convert to a common result format (which requires schema knowledge). In my opinion, mixing LDAPv2 and LDAPv3 just doesn't make sense. The charset issues alone kill any chance of interoperability / compatibility. I suggest all mention/support for LDAPv2 be axed. >3. AuthenticationMethod: Is it the same as the originating connection, > or is it "simple" - I assume simple is used. Yikes! Simple authentication should not be used automatically. I suggest that no automatic chasing be allowed if the originating connection used simple authentication. I suggest that new session MUST use same or better authentication method/mechanism. >4. Does it use the LDAPSocketFactory if specified on the > originating connection. I am not sure what to do here. > It seems better to use it if available, then an encrypted > connection can be established and thus prevent > clear text password transmittion on the wire. I just > talked myself into it - it should be used. Use of non-TCP socket factories (e.g: ldaps://) should be out of scope of this document. No assumptions to the services (other than a reliable byte stream) provided by the socket factory should be assumed. The 4.6.24 example should not mention TLS. It should state that socketFactory can be used to support other transport services as allowed by RFC2251, 5.2, but make no specific meantion of what these might be (as there is no such Standard Track mapping defined). Also, on the subject of TLS (in regards to Start TLS), some discussion regarding behavior upon handling of TLS alerts should be detailed. It is also likely the application may need accessor methods to obtain information from the TLS layer. Kurt From list@netscape.com Fri Sep 8 19: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 SMTP id TAA02106 for ; Fri, 8 Sep 2000 19: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 e88Muqu00447; Fri, 8 Sep 2000 15:56:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e88N2v222911; Fri, 8 Sep 2000 16:02:57 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 16:02:57 -0700 (PDT) Date: Fri, 8 Sep 2000 16:02:51 -0700 (PDT) Message-Id: <200009082302.e88N2nL19108@xwing.netscape.com> From: gazzas@themail.com To: ietf-ldapext@netscape.com Subject: The magic EMS program now special price! Bypasses your ISP !! X-Reply-To: gazzas@themail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JYkcq.A.YlF.eAXu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Fantastic "EMS" the full version only $20 !! Save over $120 on this very special offer! EMS ("EXPRESS Mail Server") BYPASSES YOUR ISP. SEND YOUR ADVERTS TO THOUSANDS !! THE NO FLAME WAY !! Do whatever you want while EMS sends out your adverts to thousands for you ! You read about it ! Heard about it ! Wanted it but its been to expensive for you ! OK !OK ! we heard you ! Special for the this month only, We have now lowered the price to a magic \\$20 US// dollars instead of the advertised normal selling price of $149 US dollars. Now every one can afford to buy and use this fantastic program. Price for the EMS program is based on CASH only to help keep down the price AND to safe gard your Credit card security on the Web. We guarantee that the EMS program will be fowarded to you once payment is received at this office. Not sure,then email us for your full version DEMO copy first, you'll be so glad you did ! Mail cash or money order and include your email address to, G.Tomlin 45 Emperor Avenue Maroochydore Qld Australia 4558 From list@netscape.com Fri Sep 8 21:24: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 SMTP id VAA03454 for ; Fri, 8 Sep 2000 21:24: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 e891HNu24836; Fri, 8 Sep 2000 18:17:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e891NTc27406; Fri, 8 Sep 2000 18:23:29 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 18:23:29 -0700 (PDT) Date: Fri, 8 Sep 2000 18:23:20 -0700 (PDT) Message-Id: <200009090123.e891N9f28093@ywing.netscape.com> From: "Ican Showyou" To: yourmoney.QOIA@netscape.com Subject: I CAN make you a millionaire in 12 months or less! -GHHF X-Reply-To: Your Money Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"f6bNHD.A.rrG.PEZu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit This e-email has been sent because you at one point requested information on financial oppurtunitys. However if you wish to be removed from this list please follow the removal instructions located at the bottom of this page. Thank you. May I have your permission to "MAKE YOU A MILLIONAIRE"? I CAN make you a millionaire in 12 months or less! If you are serious about earning this kind of money from the Internet, I can show you exactly how to do it -- without spending a dime of your money. Interested? Then answer this -- if I can show you how to make at least $10,000US per month in 8 weeks or less and make over $1,000,000 your first year, will you commit to working at your computer doing what I will teach you to do for 1 or 2 hours per day, 5 days per week for 8 weeks, and do all this without spending any money at all? This is not a scheme or gimmick. It is for real! If the answer is "no", please do not respond to this. If the answer is "yes", then email me at: imamllnair@financier.com put "I want $1,000,000" in the subject line. This message is sent in compliance of the new e-mail bill: Senate bill 1618, Title 3, section 301. TO BE REMOVED FROM THE MAILING LIST And to ensure you do not recieve further transmissions to you by the sender of this email PRESS REPLY AND PUT the Subject REMOVE ALL REMOVES TO THIS ADDRESS WILL BE HONORED takemeoff@mailpanda.com?subject=Remove Please do not send removes to the interested address as you may end up receiving the information. From list@netscape.com Fri Sep 8 21:59:18 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 SMTP id VAA04762 for ; Fri, 8 Sep 2000 21:59:18 -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 e891l5V19900; Fri, 8 Sep 2000 18:47:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e891vKs08937; Fri, 8 Sep 2000 18:57:20 -0700 (PDT) Resent-Date: Fri, 8 Sep 2000 18:57:20 -0700 (PDT) Date: Fri, 8 Sep 2000 18:57:12 -0700 (PDT) Message-Id: <200009090157.e891vCL11638@xwing.netscape.com> From: your_opportunity@home.com To: Opportunity@xwing.netscape.com, Seekers@netscape.com Subject: It's True-$20 will get you Thousands $$ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"t6pRUB.A.VLC._jZu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit The First of it's kind....Ever! A True FREE Downline Club that will work!! WHY?? Because we have been sanctioned to build a 10,000 member downline in the next 15 days for a POWERFUL REASON...... We have 1st Entry Rights to the hottest program ever developed Sorry, we cannot reveal the name or the company yet - but it is HOT! A one time $20 and a whopping $1,500,000 + possible payout! For more info and details on signing up, send an e-mail to: ds5487@angelfire.com and you must put " MORE " in the subject matter. Thank you From list@netscape.com Sat Sep 9 18:13: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 SMTP id SAA23526 for ; Sat, 9 Sep 2000 18:13: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 e89M6Ou02600; Sat, 9 Sep 2000 15:06:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e89MCUY16522; Sat, 9 Sep 2000 15:12:30 -0700 (PDT) Resent-Date: Sat, 9 Sep 2000 15:12:30 -0700 (PDT) DATE: 09 Sep 00 12:49:06 AM FROM: S5y8a5fKu@etna.int-evry.fr Message-ID: <1762Z43tAt67aN6e> SUBJECT: Re:) Planes, Trains, & Automobiles! What do they all have in common? << fdzhmm7t Resent-Message-ID: <"Ed5QED.A.vBE.NXru5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com They all need SUPERIOR LUBRICATION!! Get the Technology and Protection that others don't have!! "We won't promise you that you'll save lots of $$$ or that your car will have more horsepower.... WE'LL PROVE IT." Yes, that's right. You get a RISK FREE opportunity to evaluate incredible new engine technology. The Kinetic Energy Formula and the Kinetic Octane/Cetane Charge will save you a GREAT deal of $$$ * You get more horsepower. * Better gas mileage and * Peace of mind! You also get this FREE report ... * EVERYTHING YOU WANTED TO KNOW ABOUT AUTOMOTIVE REPAIR CENTERS BUT WERE AFRAID TO ASK This FREE report and new automotive technology is a real threat to car dealerships and mechanic shops! Here's why... Are you sick and tired of losing money? If you are, this will definitely be of interest to you!!! + You get up to 30% Increase In MPG!!! + Restored Horsepower & Compression + Completely cleans and optimizes the fuel system. + Increased Engine Life + Reduced Costly Repairs Listen to what the professionals say... "I build and operate competitive drag racing engines. These engines normally last six races. We treated an engine with your products, and it ran for two complete years (over 50 races!) without tear-down or engine failure. When we finally took this motor apart, the engine bearings still had part of the original protective coating. The cam and lifters showed virtually no wear. For years, I have searched for a superior lubrication that could withstand the extreme demands of a racing engine. That search ended with your incredible technology. I use it in both my racing and personal cars. You can't argue with success. The products work!" -- Andy Callahan Engine builder & race car driver. World Record Holder "I bid a job drilling 74,880 .052 diameter holes in aluminum plate. When we started this job we had broke off 4 drill bits in the plate in less than 400 holes drilled. We thought for sure that we were going to lose a lot of money. At this time, we tried using your products in a spray mist on the drill bit as it was drilling. We successfully drilled over 74,000 holes without breaking any more bits and ended up finishing the job ahead of schedule. When we figured out our cost, we made about 10% over rate." "I drive a 1993 Lincoln Town car with a big V-8 engine. I have your products in it and get between 26-30 miles per gallon on the highway and 23-24 miles per gallon back and forth to work. I have four snowmobiles, three motorcycles, four cars, two trucks and 15 machines at my place of business that use your products." "I recently purchased a 1994 boat with a 454 V-8 engine, I have already started to use your products in it as well." "Your products don't cost us money, they save us BIG money!" Lewis Bingham President BIMCO, INC. - Bingham Machine Co "A customer of ours has an old Toyota pickup that leaked oil. When the oil level got low, the engine would begin to make a loud tapping noise. This was due to the lack of oil supply to the valves. After treating his truck with your product, he had traveled quite some time without checking the oil level. He had not heard the usual noise telling him the oil level was low. When he finally did check the engine's oil level, it was three quarts low! In addition, he had also noticed an increase in horsepower. Needless to say, your products quickly made a believer out of him." -- Glenn Mitchell - Business Owner SAV-MOR AUTO CLINIC How Will My Vehicle Benefit From Your Products? It's been proven that 70-80% of the total wear in a car's engine occurs during the start-up. The oil pump can take as long as 3 minutes to completely circulate the engines vital fluids throughout the system. When you turn the car off, the oil drains to the bottom of the engine. This leaves very little protection from metal to metal wear when you start the engine again. Regular and synthetic motor oils will not stop this damaging wear from ruining your car's engine. Our technology protects any engine by creating an impenetrable barrier on the internal metal parts of the engine. With this technology, THERE IS VIRTUALLY NO WEAR!!! You benefit by getting extra power, better gas mileage and reduced emissions. You benefit by putting more of YOUR money back into YOUR pocket! Product Features:-) + Petroleum-based kinetic energy formula. + No Teflon or PTFE. + Completely cleans and optimizes the fuel system. + Rejuvenates - seals and gaskets. + Catalytic Converter Safe. + Maintain a "like new" engine in your Car, Truck, RV, ATV, Boat, Snowmobile, Jet Ski, Lawn Mower, Motorcycle... + Less worry when you're alone on the road and away from home. + Reduce the risk of costly breakdowns. + Substantially lower operating cost. + Increase gas mileage and horsepower. + Environmentally Friendly Products. + 100% Satisfaction Guaranteed. + Independent laboratory test verification. * UP TO 30% MORE HORSEPOWER!!! * UP TO 30% MORE MILES PER GALLON!!! You get a RISK FREE opportunity to evaluate this incredible breakthrough in engine technology. The Ultimate Car-Care package will give your car or truck protection to last up to triple its normal life. The Ultimate Car-Care package gives you peace of mind when your away on road trips that mechanically, your drivetrain is protected! The Ultimate Car-Care package saves you money at the gas pump by giving your car or truck up to 30% better fuel economy. Order Ultimate Car-Care Package today and: * increase the value of your vehicle. * pay yourself with fuel savings with every fillup. 30 Day Satisfaction Guarantee The Ultimate Car-Care package contains: 1 - Kinetic Energy Formula (A special blend designed for the engine, transmission, differential & power steering. Greatly reduces operating temperature. Power that was used fighting friction is now turned into kinetic energy providing UP TO 30% MORE HORSEPOWER!) 2 - Kinetic Octane/Cetane Charge (You'll make money with every fill-up using the least expensive fuel and this product. Get better gas mileage and performance. Experience more horsepower for climbing hills and passing cars! It's like nitrous oxide for your fuel system!) 3 - Waterless Ultra Shine (A specialize treatment removes oxidized paint and protects surface from the harsh road elements without the use of water.) 4 - Leather, Vinyl, Rubber Rejuvenator (A specialize treatment that provides long-lasting protection from sun, dirt and other elements that take the life out of your valuable possessions. Will not attract dust or crack dashboard. 5 - New Battery Technology (Get faster more reliable starts. Prevents corrosion and makes battery and cables last longer.) You won't find these products on any retail shelves. List Price $86.28 - Now on Sale for just $43.95 + S/H You save over $42.00 with this offer. Order by September 17th, 2000 and you get these Special Reports... FREE Report #1 THERE'S A SUCKER BORN EVERY MINUTE FREE Report #2 HOW TO GET 500,000 MILES OR MORE FROM YOUR CAR OR TRUCK FREE Report #3 EVERYTHING YOU WANTED TO KNOW ABOUT AUTOMOTIVE REPAIR CENTERS BUT WERE AFRAID TO ASK These reports are sold normally for $40 each. You get them FREE when you order the Ultimate Car-Care package by September 17th. These FREE reports will help you put even MORE money back into YOUR pockets!! Should you not be completely satisfied with your purchase of the Ultimate Car-Care package, keep these reports as our way of saying thank you for giving us the opportunity to serve you, and we will refund your $43.95. Order the Ultimate Car-Care package by September 17th and get all three reports, a $120 value, for FREE! DON'T WAIT TO GET STARTED... here's what to do: TO ORDER your Ultimate Car-Care package, simply print out the ORDER FORM below and fax it to our order center. We accept Visa, MasterCard, American Express, Discover & Checks by Fax. NO!! P.O. Boxes please we can not ship to a P.O. Box We will get an incredible response to this offer and our fax line may be busy, please, keep trying...you'll be glad you did!!! *** For your security, the billing information MUST MATCH that on your credit card or we cannot process your order. For Orders Outside the Continental United States there will be additional shipping charges. You will be notified of those charges before your credit card is billed. ---CUT HERE--- -THE ULTIMATE CAR CARE PACKAGE - Send me one Ultimate Car-Care package today for a total amount of $49.90 (price includes S/H) Put your initials next to the statement below. _____Yes! I would like to get better gas mileage, more horsepower and up to triple the life of my vehicle. I am ordering by September 17th, also include the three FREE Reports: Fax Order Center: ===> 559-991-8166 <=== **DATE / / / (DD/MM/YYYY) **AUTH CODE** XR3 **NAME OR COMPANY **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 ** ___Discover ___CHECK-BY-FAX **CREDIT CARD# **EXPIRATION DATE / (MM/YYYY) **NAME ON CARD **AMOUNT $ **AUTHORIZATION SIGNATURE:______________________ (Required) 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 our order center. 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. All checks will be held for bank clearance. (7-14 days) Make payable to: EMG =-=-REMOVE INSTRUCTIONS-=-= If you no longer wish to receive these Special Internet Offers, please send us a blank e-mail to postmasteremoves@eastmail.com with "remove" in the subject field. Or you may Click Here mailto:postmasteremoves@eastmail.com?subject=remove From list@netscape.com Sun Sep 10 03:35: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 SMTP id DAA03795 for ; Sun, 10 Sep 2000 03:35: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 e8A7QQu05452; Sun, 10 Sep 2000 00:26:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8A7WWw28959; Sun, 10 Sep 2000 00:32:32 -0700 (PDT) Resent-Date: Sun, 10 Sep 2000 00:32:32 -0700 (PDT) From: linda@web-2links.com Date: Mon, 31 Jul 00 23:08:59 EST To: suzzie@suzzie2.com Subject: ** SNORING- IS IT AFFECTING YOUR LIFE ? ** Message-ID: Reply-To: linda@web-2links.com Comments: Authenticated sender is Resent-Message-ID: <"TtXsIB.A.NEH.Pkzu5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com SNORING- IS IT AFFECTING YOUR LIFE ? Tired of waking up at all hours? Tired of not getting a good nights sleep? Tired of waking up every morning to hear how you snored the night before? Tired of sleeping in separate rooms? Just TIRED of being TIRED? It is not your fault, there is a solution! SNOR-GON IS HERE ! ! SNOR-GON is a safe, natural solution to your snoring problem * Works first time, every time * All natural * No side effects * Guaranteed results For more information on your special introductory internet offer: CALL TOLL FREE (888) 806-0517 NOW Solve your problem, make the call & change your life for the better. ******************************************************** This message is sent in compliance of the proposed bill:SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident or otherwise wish to be removed from this list, further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to striepe@zlgppql4twqgz.net with the word remove in the subject line. ********************************************************* zzz-7s From list@netscape.com Sun Sep 10 17:23: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 SMTP id RAA10241 for ; Sun, 10 Sep 2000 17:23: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 e8ALFxu13540; Sun, 10 Sep 2000 14:15:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8ALM7c09238; Sun, 10 Sep 2000 14:22:07 -0700 (PDT) Resent-Date: Sun, 10 Sep 2000 14:22:07 -0700 (PDT) To: opt_in7@alloymail.com From: Subject: How to earn $100 - $1,500 per hour or two X-MIMETrack: Itemize by SMTP Server on ZL_ELP/Zillo Lorenzetti/BR(Release 5.0.2c (Intl)|2 February 2000) at 10/09/2000 17:29:49, Serialize by Router on ZL_ELP/Zillo Lorenzetti/BR(Release 5.0.2c (Intl)|2 February 2000) at 10/09/2000 18:22:00, Serialize complete at 10/09/2000 18:22:00 Date: Sun, 10 Sep 2000 17:29:49 -0300 Message-ID: MIME-Version: 1.0 Resent-Message-ID: <"xi7WjC.A.EQC.-t_u5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com From: Michelle Smith - publisher of the "Work From Home Opportunities" Newsletter Sunday, 3 p.m. Hello, If you're interested in earning $100 - $1,500 per hour or two Then I want to share something with you... Now you can make $100 - $1,500 per hour or two! Imagine you come home from a hard day's work (exhausted..) You immediately go straight to bed. You get undressed, lay down, turn off the lights, and snuggle up face-down on the pillow. A few moments later, you feel uncomfortable and stressed out so you lie on your back. When you look up at the ceiling, it's as if the ceiling has been removed! You see exactly what you would see if outside stargazing! A stunning, accurate 3-dimensional re-creation of the starry night sky, including constellations such as the Big Dipper, Pegasus and the Milky Way galaxy, ...and even shooting stars! You can't see it during the day. The ceiling looks normal. But at night, when the lights are off, you see what looks like the sky outside! It's so relaxing and romantic. And educational! And talk about stress-relief! The moment you look at it, it'll melt your tension away faster than a great massage! Now how many people do you think would LOVE seeing this when they look up in their beds at night? "It's like you're sleeping under the stars!" Ok, I know you want to know How You Make Money. Here's how. You can put that awesome "convertible ceiling" in ANYONE'S bedroom with a product cost to you of.. Guess how much.. Only ONE to TWO Dollars! You offer this masterpiece for $100 - $1,500! Talk about *nice* profits! And it only takes you an hour or two! Here's an important point: These profits are similar to the profits of selling Information: the material costs next to nothing, but the customer really VALUES the END RESULT. So the market value is more (a LOT more). "Who'd want this?" Anyone with a bedroom ceiling (or any ceiling), as well as homes, hotels, etc. Who do you know that has a bedroom ceiling? Whew! The official money-making opportunity of the Millenium! (Well... we think it should be!) |;-) Anyway, I know you want more information to make a decision, so ... To receive more FREE information on How To Make $100 - $1,500 per hour or two, Simply Click On The Email Link Below and Send Back The Following: Mailto:stargazing24@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:stargazing24@newmail.net And you'll be sent the full details on how to make $100 - $1,500 per hour or two, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle Smith P.S. We'll also send you a free Opportunity E-zine with more interesting Money-Making Opportunities like this one, and important info. for the home-based entrepreneur! P.P.S. Also, even though 99% of people don't know about this opportunity, that won't be the case forever, so hurry up and reply to make sure you get to lock down YOUR city! To unsubscribe mailto:optout910@newmail.net From list@netscape.com Sun Sep 10 19:51: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 SMTP id TAA10755 for ; Sun, 10 Sep 2000 19:51: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 e8ANhTu25456; Sun, 10 Sep 2000 16:43:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8ANnbE05778; Sun, 10 Sep 2000 16:49:37 -0700 (PDT) Resent-Date: Sun, 10 Sep 2000 16:49:37 -0700 (PDT) To: getmotivated@aol.com From: Subject: Unlimited Business Opportunity / NOT MLM Message-ID: <048994045230a90CPIMSSMTPU08@email.msn.com> Date: 10 Sep 2000 16:45:46 -0700 Resent-Message-ID: <"xkNDZC.A._ZB.Q4Bv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com We are sorry if you received this email in error. To be removed from this list please send an email to the address below. mailto:removeme@listremove.com Look, we don't want to waste your time.......or ours If you're serious about retiring in the next 2 years with enough income to live the "good life" and not afraid to work for it, we can help you. REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! Please don't bother to call unless you are totally serious. Call today - TOLL FREE NUMBER 1-888-206-4506 Recorded Message From list@netscape.com Mon Sep 11 01:06: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 SMTP id BAA14774 for ; Mon, 11 Sep 2000 01: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 e8B4wwu14145; Sun, 10 Sep 2000 21:58:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8B556Q01097; Sun, 10 Sep 2000 22:05:06 -0700 (PDT) Resent-Date: Sun, 10 Sep 2000 22:05:06 -0700 (PDT) From: Michelle402513@worldnet.att.net Date: Mon, 11 Sep 2000 01:02:46 -0400 (EDT) Message-Id: <200009110502.e8B52jH22398@tot-tf.proxy.aol.com> To: members2@chek.com Subject: STOP SNORING Resent-Message-ID: <"JICMKD.A.3Q.CgGv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Order new: STOP SNORING product today! Receive 10% discount. 30-day money-back guarantee! For complete toll free number Mailto:stopsnoring1@newmail.net For unsubscribing, mailto:unsubscribe371@newmail.net From list@netscape.com Mon Sep 11 05:23: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 SMTP id FAA27990 for ; Mon, 11 Sep 2000 05:23: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 e8B9BTV16619; Mon, 11 Sep 2000 02:11:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8B9LmY22223; Mon, 11 Sep 2000 02:21:48 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 02:21:48 -0700 (PDT) Date: Mon, 11 Sep 2000 02:21:21 -0700 (PDT) Message-Id: <200009110921.e8B9LGf21777@ywing.netscape.com> From: laaiine@VCEB.angelfire.com To: @netscape.com Subject: As Seen On Tv! $50 000 within 90 days! X-Reply-To: laaiine@angelfire.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Z3RJV.A.9aF.rQKv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Looking for that extra something, to help your life have that little extra comfort? Do you work to cover the bills? Fed up with paying out and not receiving the rewards you wish for? Then have an open mind And read all of this, before you make a decision- it will be worth your while. _______________________________________________ Subject: Fw: MUST READ ! ! ! ... TV Advertized ! ! ! ... Fun-Lucrative Fellow Entrepreneur, If you wish to learn about an exceptional opportunity in the Home Business arena...Read On. "Your living is determined not so much by what life brings to you as by the attitude you bring to life; not so much by what happens to you as by the way your mind looks at what happens." This is going to be a great new Year for you! Please read all of this! EARN $100,000 PER YEAR SENDING E-MAIL!!! **************************************************************** You can earn $50,000 or more in the next 90 days sending e-mail, seem impossible? Read on for details (no, there is no 'catch')... ---------------------------------------------------------------- "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 (£5) 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(£5) 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(£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 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: E.Mills (will accept your currency) PO Box 2 Mowbray Heights Launceston,Tasmania Australia 7248 _______________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: Jim Wright 38 Pentyla Baglan Rd Port Talbot West Glamorgan SA12 8AA Wales UK ________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" Conrad Fry 1 Avon Gardens West Bridgford Nottingham England NG2 6BP ________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: Brian Pepe 30 Shady 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 dependent 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 ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE HOUR! DECISIVE ACTION YIELDS POWERFUL RESULTS ! ********************************************************* Your request to be removed will be processed within 24 hours. DISCLAIMER: Under Bill s.1618 TITLE III passed by the 105th US Congress this letter Cannot be considered Spam as long as the sender includes contact information & a method of removal.To be removed from future mailings just reply with REMOVE in the subject line.Thank you for your kind consideration. From list@netscape.com Mon Sep 11 06:51: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 SMTP id GAA28459 for ; Mon, 11 Sep 2000 06:51: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 e8BAi5u08790; Mon, 11 Sep 2000 03:44:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8BAoCQ09095; Mon, 11 Sep 2000 03:50:12 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 03:50:12 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 11 Sep 2000 04:49:05 -0600 From: "Vijay Kn" To: Subject: new draft: the LDAP client caching proxy model ... Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_F7AF7FA2.A1C18C27" Resent-Message-ID: <"pJwcQ.A.1NC.jjLv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_F7AF7FA2.A1C18C27 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, I have submitted an internet draft titled "The LDAP client caching proxy = model". Here is the URL for this draft: =20 http://www.ietf.org/internet-drafts/draft-knvijay-ldapext-clientcachingprox= y-00.txt I would appreciate if you can go through this draft and provide your = inputs, comments and suggestions. Thanks, Vijay --=_F7AF7FA2.A1C18C27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
I have submitted an internet draft titled "The LDAP = client=20 caching proxy model".  Here is the URL for this draft: =20
http://www.ietf.org/internet-drafts/draft-knvijay-ldapext-clientca= chingproxy-00.txt
 
I would appreciate if you can go through this = draft and=20 provide your inputs, comments and suggestions.
 
Thanks,
Vijay
 
--=_F7AF7FA2.A1C18C27-- From list@netscape.com Mon Sep 11 07:14: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 SMTP id HAA28871 for ; Mon, 11 Sep 2000 07:14: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 e8BB6ru10345; Mon, 11 Sep 2000 04:06:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8BBD0M13789; Mon, 11 Sep 2000 04:13:00 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 04:13:00 -0700 (PDT) Date: Mon, 11 Sep 2000 08:55:32 -0500 From: satellite4freea13@indiatimes.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Subject: Get a FREE $1000 Satellite T.V. System. To: satellites321@yahoo.com Reply-To: yourfreetv13@indiatimes.com Message-Id: Resent-Message-ID: <"TFaLzD.A.9WD.74Lv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT FREE SATELLITE T.V. SYSTEM Watch over 500 channels of Digital Broadcast quality television on your own FREE satellite television system. These new Digital satellite systems use the new 18 inch satellite dish antenna. For a limited time we'll give you this top of the line Digital Satellite System for FREE! We'll even include Free installation and 3 FREE months of all the movie channels! This is the New Dishplayer 500. It has a built Digital 12 hour recording system so you can throw that old VCR away, built in WEB T.V. and interactive T.V and game systems, on screen graphics, 2 dual LNB's, stereo receiver and infrared remote. Normal cost for all these items is over $900 but we're giving it away for FREE! All you have to do is call us to arrange delivery and order the channels you want to receive. The monthly cost of satellite television is usually much less than cable T.V and satellite television offers over 500 channels of all digital broadcast video quality and CD audio sound. You even get local channels now. Don't miss this offer it's only available while supplies last. For your Free Satellite System call 888-514-6881 24 hours a day. To be removed send email to wasteboxus@yahoo.com From list@netscape.com Mon Sep 11 18:37: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 SMTP id SAA09657 for ; Mon, 11 Sep 2000 18:37: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 e8BMTTu03363; Mon, 11 Sep 2000 15:29:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8BMVcA25425; Mon, 11 Sep 2000 15:31:38 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 15:31:38 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Mon, 11 Sep 2000 16:31:18 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: Listener objects - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9DC5142C.5D3C50E4" Resent-Message-ID: <"UHazn.A.FNG.J1Vv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_9DC5142C.5D3C50E4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since LDAPResponseListener and LDAPSearchListener objects implement exactly the same set of methods, does it seem reasonable that an interface be created named something like LDAPListener that specifies those four methods, and that LDAPSearchListener and LDAPResponseListener implement this interface. This forces those methods to stay the same in both classes. -Steve --=_9DC5142C.5D3C50E4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Since LDAPResponseListener and LDAPSearchListener
objects implement exactly the same set of methods,
does it seem reasonable that an interface be created
named something like LDAPListener that specifies
those four methods, and that LDAPSearchListener
and LDAPResponseListener implement this interface.
This forces those methods to stay the same in both classes.
 
-Steve
 
 
--=_9DC5142C.5D3C50E4-- From list@netscape.com Mon Sep 11 19:59: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 SMTP id TAA10121 for ; Mon, 11 Sep 2000 19:59: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 e8BNicV27237; Mon, 11 Sep 2000 16:44:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8BNsw609305; Mon, 11 Sep 2000 16:54:58 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 16:54:58 -0700 (PDT) Date: Mon, 11 Sep 2000 16:54:48 -0700 (PDT) Message-Id: <200009112354.e8BNslf26630@ywing.netscape.com> From: Bestyetonthe_net@mail.com To: Friends@netscape.com Subject: Hurry&Secure your SPot While They Last! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"4d1a8C.A.FRC.RDXv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit The First of it's kind....Ever! A True FREE Downline Club that will work!! WHY?? Because we have been sanctioned to build a 10,000 member downline in the next 15 days for a POWERFUL REASON...... We have 1st Entry Rights to the hottest program ever developed Sorry, we cannot reveal the name or the company yet - but it is HOT! A one time $20 and a whopping $1,500,000 + possible payout! WOW! This is really exciting! For more info and details on signing up, send an e-mail to: ds5487@angelfire.com and you must put " FREE " in the subject matter. Thank you From list@netscape.com Mon Sep 11 20:36: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 SMTP id UAA10322 for ; Mon, 11 Sep 2000 20:36: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 e8C0SVu26335; Mon, 11 Sep 2000 17:28:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8C0Yew11459; Mon, 11 Sep 2000 17:34:40 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 17:34:40 -0700 (PDT) From: "Nico Nelson" Subject: Your Web #569C To: on29d@xwing.netscape.com X-Mailer: Mozilla 4.70 [en] (Win95; I) Mime-Version: 1.0 Date: Mon, 11 Sep 2000 18:34:58 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200009120812437.SM00233@aaksjk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e8C0Ycr11432 Resent-Message-ID: <"WPS8AB.A.wyC.foXv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: 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:p29dx@popmail.com?subject=remove ************************************************************ From list@netscape.com Mon Sep 11 22:44: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 SMTP id WAA12942 for ; Mon, 11 Sep 2000 22: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 e8C2WKV21739; Mon, 11 Sep 2000 19:32:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8C2geg02006; Mon, 11 Sep 2000 19:42:40 -0700 (PDT) Resent-Date: Mon, 11 Sep 2000 19:42:40 -0700 (PDT) From: Michelle40258@worldnet.att.net Date: Mon, 11 Sep 2000 22:38:07 -0400 (EDT) Message-Id: <200009120238.e8C2c6Z23756@tot-tl.proxy.aol.com> To: opt_in@alloymail.com Subject: Awesome Online Marketing System - Complete Details Below Resent-Message-ID: <"im8MtB.A.pe.dgZv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Most successful Internet Marketers will agree - You MUST have three important ingredients to succeed on the Internet! Ingredient # 1 -- A great PRODUCT. Ingredient # 2 -- A personalized WEBSITE that is user-friendly. Ingredient # 3 -- A Marketing SYSTEM in Place to drive traffic to you. We have all THREE of these ingredients with our program. We would love to tell you all about it. For more information and toll free number Mailto:all-3@newmail.net To opt out mailto:34982@newmail.net From list@netscape.com Tue Sep 12 12:18: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 SMTP id MAA08167 for ; Tue, 12 Sep 2000 12:18: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 e8CG6oV02750; Tue, 12 Sep 2000 09:06:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8CGHBc26319; Tue, 12 Sep 2000 09:17:11 -0700 (PDT) Resent-Date: Tue, 12 Sep 2000 09:17:11 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Tue, 12 Sep 2000 10:16:47 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: LDAPConstraints - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_520AD8EB.35543869" Resent-Message-ID: <"vhy5AC.A.9aG.Gclv5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_520AD8EB.35543869 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 4.6.19 setConstraints Sets the constraints that apply to all operations performed through this connection Wouldn't it be more clear to state: Sets the constraints that apply to all non search operations performed through this connection. - - - - - - - - - - - - - - - - - - - - 4.39.13 setOption Seems to set only the search constraints options, but the first paragraph has a confusing sentence that talks about LDAPConstraints. Was it your intention that the LDAPConstraints be the same object as LDAPSearchConstraints or that they be different objects? "These options represent the default search constraints for the current connection. Some of these options are also propagated through the LDAPConstraints, which can be obtained from the connection object with the getSearchConstraints method." The above two sections 4.39.13 & 4.6.19 could be construed to indicate that the LDAPConstraints and the LDAPSearchConstraints objects for a connection are=20 in fact the the same object, however, that fact that each has a separate set & get method seems to indicate they are different objects. Could you please clarify this? -Steve --=_520AD8EB.35543869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

4.6.19 setConstraints
 
Sets the constraints that apply to all operations performed
through this connection
 
Wouldn't it be more clear to state:
 
Sets the constraints that apply to all non search operations
performed through this connection.
- - - - - - - - - - - - - - - - - - - -
 
4.39.13 setOption
 
Seems to set only the search constraints options, but
the first paragraph has a confusing sentence that
talks about LDAPConstraints.
 
Was it your intention that the LDAPConstraints be
the same object as LDAPSearchConstraints or
that they be different objects?
 
   "These options represent the default search constraints = for=20 the
   current connection. Some of these options are also=20 propagated through
   the LDAPConstraints, which can be = obtained=20 from the connection object
   with the getSearchConstraints=20= method."
The above two sections 4.39.13 & 4.6.19 could be
construed to indicate that the LDAPConstraints and the
LDAPSearchConstraints objects for a connection are
in fact the the same object, however, that fact that
each has a separate set & get method seems to indicate
they are different objects.
 
Could you please clarify this?
 
-Steve
--=_520AD8EB.35543869-- From list@netscape.com Wed Sep 13 11:12:14 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 SMTP id LAA10063 for ; Wed, 13 Sep 2000 11:12: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 e8DF3hu19126; Wed, 13 Sep 2000 08:03:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DF9sc03577; Wed, 13 Sep 2000 08:09:54 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 08:09:54 -0700 (PDT) From: <000ymao@china.com> Subject: Do You Accept Credit Cards??? Date: Wed, 13 Sep 2000 11:04:59 Message-Id: <285.650087.878087@china.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"9Q0oeC.A.h3.Bj5v5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com
Accept All Major Credit Cards!!! With Zero Down!
 
We have no application or setup fees!We even pay your first months leasing payment (for a limited time). So getting started is easy and affordable.
 
 
If you own your own business, you're starting a new business or know someone who is... Being able to accept Major Credit
Cards can make all the difference in the world! It's a known fact, accepting credit cards can increase your sales dramatically.
 
Just the fact that you accept credit cards adds credibility to your business. Especially if you are a New, Small or Home
Based Business.
 
Approval is quick and our set up times range from 3-5 days. Guaranteed approval on all leases for equipment or software. Bad credit, no credit, no problem!  
 
Our technology is the latest! We have state of the art wireless terminals so that your business can go where ever you go..
 
=====================================
Here's what our customers say...
 
Testimonial # 1 - I knew having a merchant account would increase my sales, But never thought it would be so great.
In addition in being able to take major credit cards, I can also do real time credit card processing on the internet and
receive orders while I am Sleeping. It's awesome! I encourage every serious business owner to get one. Thanks. M.B./MI
 
Testimonial # 2 - " Being a homebased business owner, no one would approve me, until this came my way. I am more
than grateful. Within 4 days I had my merchant account set up. I am more than pleased with the 24 hr. customer
service. My business has sky rocketed because I now can accept credit card orders. " Oscar/FL
------------------------------------------------------------------
 
so you too can receive the same benefits....
From list@netscape.com Wed Sep 13 11:42:56 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 SMTP id LAA10603 for ; Wed, 13 Sep 2000 11:42: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 e8DFZIu24213; Wed, 13 Sep 2000 08:35:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DFfSY15052; Wed, 13 Sep 2000 08:41:28 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 08:41:28 -0700 (PDT) Message-Id: <200009131541.e8DFf8N15141@xwing.netscape.com> From: Subject: Targeted Lists at the lowest prices! Date: Wed, 13 Sep 2000 07:10:01 Resent-Message-ID: <"kHQzOC.A.nqD.nA6v5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com *******New List 9-12-00!!******** 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.virtue.nu/913emc 10,000 opportunity seekers e-mails for only $15 **New List 9-01-00** 25,000 opportunity seekers e-mails for only $25 50,000 opportunity seekers e-mails for only $35 100,000 opportunity seekers e-mails for only $50 200,000 opportunity seekers e-mails for only $75 - Promotions! **FREE with EVERY order, demo of ListMan e-mail manager software to manage your e-mails list and Credit Helper E-book with Links to Guaranteed Visa's and MC's! **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, 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 Wed Sep 13 13:28: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 SMTP id NAA13425 for ; Wed, 13 Sep 2000 13:28: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 e8DHGnV15707; Wed, 13 Sep 2000 10:16:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DHRBM17304; Wed, 13 Sep 2000 10:27:11 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 10:27:11 -0700 (PDT) Message-ID: <39BFB8D1.9184D901@novell.com> Date: Wed, 13 Sep 2000 11:26:41 -0600 From: Steven Sonntag Organization: Novell, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com, rweltman@netscape.com, Jim Sermersheim , Alan Clark , Steven Merrill Subject: Re: Listener objects - java-api-11 draft References: <00017444@prv-mail21.provo.novell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"HQbML.A.jNE.sj7v5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit If an LDAPListener interface were created, then the two methods in LDAPv2.abandon public void abandon(LDAPSearchListener listener) public void abandon(LDAPResponseListener listener) Could be combined into one public void abandon(LDAPListener listener) -Steve Steve Sonntag wrote: > > Since LDAPResponseListener and LDAPSearchListenerobjects implement > exactly the same set of methods,does it seem reasonable that an > interface be creatednamed something like LDAPListener that > specifiesthose four methods, and that LDAPSearchListenerand > LDAPResponseListener implement this interface.This forces those > methods to stay the same in both classes. -Steve From list@netscape.com Wed Sep 13 13:34: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 SMTP id NAA13711 for ; Wed, 13 Sep 2000 13:34: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 e8DHR8u22538; Wed, 13 Sep 2000 10:27:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DHXKA23194; Wed, 13 Sep 2000 10:33:20 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 10:33:20 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 13 Sep 2000 11:32:57 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: abandon & controls - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1F47944B.C8A9C45A" Resent-Message-ID: <"jRpLdC.A.IqF.fp7v5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_1F47944B.C8A9C45A Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 4.39.1 LDAPv2.abandon The RFC 2251 and the C api draft allow controls to be specified on an abandon operation. In java it is allowed only using the default constraints object or search constraints object. Should methods be defined that allow constraints to be specified on abandon? When calling abandon( int id), it is unclear whether LDAPConstraints or LDAPSearchConstraints should be used for the default constraints. -Steve --=_1F47944B.C8A9C45A Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
4.39.1 LDAPv2.abandon
 
The RFC 2251 and the C api draft allow controls to be specified
on an abandon operation.  In java it is allowed only using = the=20 default
constraints object or search constraints object.  Should = methods
be defined that allow constraints to be specified on abandon?
 
When calling abandon( int id), it is unclear whether LDAPConstraints
or LDAPSearchConstraints should be used for the default
constraints.
 
-Steve

 
--=_1F47944B.C8A9C45A-- From list@netscape.com Wed Sep 13 13:37: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 SMTP id NAA13829 for ; Wed, 13 Sep 2000 13:37: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 e8DHSTu23299; Wed, 13 Sep 2000 10:28:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DHYe224247; Wed, 13 Sep 2000 10:34:40 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 10:34:40 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 13 Sep 2000 11:34:27 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: Filter RFC - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_EDB566B9.3A5B36A8" Resent-Message-ID: <"5tUg8C.A.l6F.vq7v5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_EDB566B9.3A5B36A8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable In the Bibliography, [3] refers to RFC 1960. Shouldn't it refer to RFC 2254 instead? -Steve --=_EDB566B9.3A5B36A8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the Bibliography, [3] refers to RFC 1960.
 
Shouldn't it refer to RFC 2254 instead?
 
-Steve
--=_EDB566B9.3A5B36A8-- From list@netscape.com Wed Sep 13 13:49: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 SMTP id NAA14184 for ; Wed, 13 Sep 2000 13:49: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 e8DHfNu27437; Wed, 13 Sep 2000 10:41:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DHlYg02151; Wed, 13 Sep 2000 10:47:34 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 10:47:34 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 13 Sep 2000 11:47:20 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: SASL bind - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_EFB764BC.4B2A47DD" Resent-Message-ID: <"_meNCD.A.Vh.127v5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_EFB764BC.4B2A47DD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 4.40.1 In the explaination of bind operations that use mechanisms should the = first Paragraph be changed from=20 Authenticates to the LDAP server (that the object is currently connected to) using the specified name and of a specified set of mechanisms. If none of the requested SASL mechanisms is available, an Authenticates to the LDAP server (that the object is currently connected to) using the specified name and ONE of a specified set of = <---- mechanisms. If none of the requested SASL mechanisms is available, an =20 What does it mean - if the first version of the method (i.e. the one that specifies no = mechanism) is called, the LDAP server will be interrogated for its supportedSaslMechanisms attribute of its root DSE. What does it do after the LDAP server is interrogated? Does it use one of them, and if so how does the application know which one is used and how does it know what kind of credentials to supply? -Steve --=_EFB764BC.4B2A47DD Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
4.40.1
 
In the explaination of bind operations that use mechanisms should = the=20 first
Paragraph be changed from
 
   Authenticates to the LDAP server (that the object is=20 currently
   connected to) using the specified name and of = a=20 specified set of
   mechanisms. If none of the requested = SASL=20 mechanisms is available, an

    Authenticates to the LDAP server (that the = object is=20 currently
   connected to) using the specified name and ONE = of a=20 specified set of  <----
   mechanisms. If none = of the=20 requested SASL mechanisms is available, an
 
What does it mean -
 
   if the first version of the method (i.e. the one that=20 specifies no mechanism)
   is called, the LDAP server = will be=20 interrogated for its
   supportedSaslMechanisms attribute of = its=20 root DSE.
 
What does it do after the LDAP server is interrogated?  Does it = use=20 one
of them, and if so how does the application know which one is = used
and how does it know what kind of credentials to supply?
 
-Steve
--=_EFB764BC.4B2A47DD-- From list@netscape.com Wed Sep 13 15:41: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 SMTP id PAA16715 for ; Wed, 13 Sep 2000 15:41: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 e8DJTDV21719; Wed, 13 Sep 2000 12:29:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DJdag19644; Wed, 13 Sep 2000 12:39:36 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 12:39:36 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 13 Sep 2000 13:37:01 -0600 From: "Steve Sonntag" To: , , "Jim Sermersheim" Cc: "Alan Clark" , "Steven Merrill" Subject: SASL bind (props) - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4810C371.C6A7C9FF" Resent-Message-ID: <"QnX7lD.A.NyE.2f9v5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_4810C371.C6A7C9FF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 4.40.1 bind specifying a mechanism It would seem that if the mechanism is "simple" that the API should specify how the password is to be specified in the Hashtable object props so that it is consistent across implementations. Other mechanisms and associated Hashtable values are the subject of other I-Ds. My suggestions: props.put("password", new String("user-password-value");) -Steve --=_4810C371.C6A7C9FF Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
4.40.1 bind specifying a mechanism
 
It would seem that if the mechanism is "simple"
that the API should specify how the password
is to be specified in the Hashtable object props
so that it is consistent across implementations.
Other mechanisms and associated Hashtable
values are the subject of other I-Ds.
 
 
My suggestions:
 
      props.put("password", new=20 String("user-password-value");)
 
-Steve
 
--=_4810C371.C6A7C9FF-- From list@netscape.com Wed Sep 13 15:56: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 SMTP id PAA16851 for ; Wed, 13 Sep 2000 15:56: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 e8DJiQV24601; Wed, 13 Sep 2000 12:44:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8DJsnU25315; Wed, 13 Sep 2000 12:54:49 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 12:54:49 -0700 (PDT) Message-ID: <39BFDB67.D2F9DDC5@novell.com> Date: Wed, 13 Sep 2000 13:54:15 -0600 From: Steven Sonntag Organization: Novell, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com, rweltman@netscape.com, Jim Sermersheim , Alan Clark , Steven Merrill Subject: Re: SASL bind - java-api-11 draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Wvq_SC.A.OLG.Iu9v5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Shouldn't the SASL bind mechanisms also support the ability for the application to specify an LDAPConstraints object so that call specific controls can be specified? -Steve Steve Sonntag wrote: > 4.40.1 In the explaination of bind operations that use mechanisms > should the firstParagraph be changed from Authenticates to the LDAP > server (that the object is currently > connected to) using the specified name and of a specified set of > mechanisms. If none of the requested SASL mechanisms is available, > an > Authenticates to the LDAP server (that the object is currently > connected to) using the specified name and ONE of a specified set > of <---- > mechanisms. If none of the requested SASL mechanisms is available, > anWhat does it mean - if the first version of the method (i.e. the > one that specifies no mechanism) > is called, the LDAP server will be interrogated for its > supportedSaslMechanisms attribute of its root DSE. What does it do > after the LDAP server is interrogated? Does it use oneof them, and if > so how does the application know which one is usedand how does it know > what kind of credentials to supply? -Steve From list@netscape.com Wed Sep 13 20:13: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 SMTP id UAA19382 for ; Wed, 13 Sep 2000 20:13: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 e8E06Bu29333; Wed, 13 Sep 2000 17:06:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8E0CNM27738; Wed, 13 Sep 2000 17:12:23 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 17:12:23 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 13 Sep 2000 18:12:15 -0600 From: "Jim Sermersheim" To: Cc: Subject: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_742C80F2.A4C5AB66" Resent-Message-ID: <"z2NnTB.A.9wG.mfBw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_742C80F2.A4C5AB66 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have a few questions about RFC 2596 (Language Codes in LDAP). Section 3.1 says "Multiple language options may be present on a particular = value.". To me, this says the following is allowable: cn;lang-en-US;lang-ja: JoeBob Is that correct? If so, I believe the following assumption is also = correct: Any value held in an attribute with more than one language option (i.e. = the example above) does NOT exist in the attribute with a subset of those = language options. In other words, the example above does NOT imply that = there are values like: cn;lang-en-US: JoeBob cn;lang-ja: JoeBob Right? I don't want to believe part of Section 3.3. It says that given the filter = (name;lang-en-US"=3DBilly Ray), that the following is a match: CN;lang-EN-US;dynamic: Billy Ray To me, this is a different, distinct subtype. In other words: cn;foo is a subtype of cn cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn. Am I off in my thinking? RFC 2251 says that "An AttributeDescription with = one or more options is treated as a subtype of the attribute type without = any options". Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic = examples in 2596 are invalid. RFC 2251 states that the options must appear = in ascending order. At the end of section 3.3, it says: "Thus in general, clients SHOULD NOT = use the language code option in AttributeDescription fields in search = filters". Is this because they might get more matches than they bargained = for? It would be nice if the "Thus in general" part was spelled out a bit = more. Jim --=_742C80F2.A4C5AB66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have a few questions about RFC 2596 (Language Codes = in=20 LDAP).
 
Section 3.1 says "Multiple language options may be = present on=20 a particular value.".
To me, this says the following is allowable:
cn;lang-en-US;lang-ja: JoeBob
Is that correct? If so, I believe the following=20 assumption is also correct:
Any value held in an attribute with more than one = language=20 option (i.e. the example above) does NOT exist in the attribute with a = subset of=20 those language options. In other words, the example above does NOT = imply=20 that there are values like:
cn;lang-en-US: JoeBob
cn;lang-ja: JoeBob
Right?
 
I don't want to believe part of Section 3.3. It says = that=20 given the filter (name;lang-en-US"=3DBilly Ray), that the following = is a=20 match:
CN;lang-EN-US;dynamic: Billy Ray
To me, this is a different, distinct subtype. In other words:
cn;foo is a subtype of cn
cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype = of=20 cn.
Am I off in my thinking? RFC 2251 says that "An AttributeDescription = with=20 one or more options is treated as a subtype of the attribute type without = any=20 options".
 
Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic = examples=20 in 2596 are invalid. RFC 2251 states that the options must appear in = ascending=20 order.
 
At the end of section 3.3, it says: "Thus in general, clients SHOULD = NOT=20 use the language code option in AttributeDescription fields in search = filters".=20 Is this because they might get more matches than they bargained for? It = would be=20 nice if the "Thus in general" part was spelled out a bit more.
 
Jim
--=_742C80F2.A4C5AB66-- From list@netscape.com Wed Sep 13 21:35: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 SMTP id VAA21038 for ; Wed, 13 Sep 2000 21:35: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 e8E1RUu10682; Wed, 13 Sep 2000 18:27:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8E1Xg229003; Wed, 13 Sep 2000 18:33:42 -0700 (PDT) Resent-Date: Wed, 13 Sep 2000 18:33:42 -0700 (PDT) Message-Id: <5.0.0.25.0.20000913174608.00a80010@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 13 Sep 2000 18:31:27 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: RFC 2596 questions Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"rMmnd.A.EDH.xrCw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:12 PM 9/13/00 -0600, Jim Sermersheim wrote: >I have a few questions about RFC 2596 (Language Codes in LDAP). Timely post... I've been meaning to post my comments regarding this TS based upon my recent implementation of it. >Section 3.1 says "Multiple language options may be present on a particular value.". >To me, this says the following is allowable: >cn;lang-en-US;lang-ja: JoeBob >Is that correct? Yes. But I believe this should be changed to: "An attribute description SHALL NOT contain more than one language option." with that said, the statement above might have actually meant: An entry MAY contain any number of attributes with or without language options. That is, the statement may just refer to the fact that you can have: cn: x cn;lang-en: x cn;lang-en-us: x and not, how you and I read it. That is, as allowing: cn;lang-en;lang-en-us: x >If so, I believe the following assumption is also correct: >Any value held in an attribute with more than one language option (i.e. the example above) does NOT exist in the attribute with a subset of those language options. In other words, the example above does NOT imply that there are values like: >cn;lang-en-US: JoeBob >cn;lang-ja: JoeBob >Right? That's my read as well. "cn;lang-en-US;lang-ja" has super types "cn", "name;lang-en-US;lang-ja", and "name". >I don't want to believe part of Section 3.3. It says that given the filter (name;lang-en-US"=Billy Ray), that the following is a match: >CN;lang-EN-US;dynamic: Billy Ray >To me, this is a different, distinct subtype. In other words: >cn;foo is a subtype of cn >cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn. >Am I off in my thinking? RFC 2251 says that "An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options". What about "cn;binary;lang-en"? Should not this have the same super types of "cn;lang-en" but be transferred using ";binary"? Is ";dynamic" like ";binary"? Why aren't multiple language tags, if allowed, like this? I concur that this is counter to RFC2251. However, if the server holds for in an entry: cn: foo cn;lang-x-rot13: sbb and request cn;binary the server should only return the first value (using binary transfer) and not the second. This seems odd to me. Then, again, ;binary is odd. >Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic examples in 2596 are invalid. RFC 2251 states that the options must appear in ascending order. Correct. > >At the end of section 3.3, it says: "Thus in general, clients SHOULD NOT use the language code option in AttributeDescription fields in search filters". Is this because they might get more matches than they bargained for? It would be nice if the "Thus in general" part was spelled out a bit more. This seems odd. I would think the opposite to be true. That is, if I search for "cn=foo" I will match more than just cn values, I'll match cn;lang-en, cn;lang-x-rot13, etc.. In our implementation, we don't allow multiple language tags (as you and I read the RFC) as they don't behave like other content (e.g MIME) tags with multiple language tags. And, unlike some implements, we adhere to the following: Implementations MUST NOT otherwise interpret the structure of the code when comparing two codes, and MUST treat them as simply strings of characters. So, if you want to tag some content for multiple languages, you have to provide it as separate attribute descriptions: cn: foo cn;lang-EN: foo cn;lang-EN-US: foo cn;lang-EN-GB: foo cn;lang-x-rot13: sbb and request search to return "cn" would return all and "cn;lang-X" would return the particular "cn;lang-X" value. As far as ";binary" is concerned, we'd strip it from the option list before doing subtyping. So, asking for "cn;binary" would return all them using binary transfer. BTW, we don't actually support binary transfer of directoryString (yet), but we do this for syntaxes we do support binary transfer of. From list@netscape.com Thu Sep 14 09:43:47 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 SMTP id JAA11816 for ; Thu, 14 Sep 2000 09:43: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 e8EDVwV27676; Thu, 14 Sep 2000 06:31:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8EDgLU15038; Thu, 14 Sep 2000 06:42:21 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 06:42:21 -0700 (PDT) From: To: Date: Thu, 14 Sep 2000 05:20:24 Message-Id: <603.237191.756401@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nFbUzC.A.sqD.8WNw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 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 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! FRONT PAGE EXTENSIONS are 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 Webhosting International From list@netscape.com Thu Sep 14 17:28: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 SMTP id RAA25422 for ; Thu, 14 Sep 2000 17:28: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 e8ELL9u03800; Thu, 14 Sep 2000 14:21:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8ELRMU29524; Thu, 14 Sep 2000 14:27:22 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 14:27:22 -0700 (PDT) Date: Thu, 14 Sep 2000 14:27:16 -0700 (PDT) Message-Id: <200009142127.e8ELR6u17704@ywing.netscape.com> From: investments@netcom.net To: Investors@ywing.netscape.com, Only@netscape.com Subject: 3-! Return on Investment Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"i5K56D.A.2MH.4KUw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hello, I have a program that pays 3-1 in just 3 months, plus 50% payments for referrals! I have already recieved $200 in referrals! This is a good one to get into, even if it's just for the referral payouts! Minimum to invest is $100. If you are interested in signing up please send me an e-mail to investments2000@angelfire.com and you MUST put " YES " in the subject matter or you will not get a response. Thank you! From list@netscape.com Thu Sep 14 18:17: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 SMTP id SAA26846 for ; Thu, 14 Sep 2000 18:17: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 e8EM9wu17800; Thu, 14 Sep 2000 15:09:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8EMGBE23305; Thu, 14 Sep 2000 15:16:11 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 15:16:11 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Thu, 14 Sep 2000 15:58:12 -0600 From: "Steve Sonntag" To: , , "Alan Clark" , "Jim Sermersheim" , "Steven Merrill" , "Steve Sonntag" Subject: Re: SASL bind - java-api-11 draft Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D9812C07.36573B58" Resent-Message-ID: <"oD7Vt.A.3rF.q4Uw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_D9812C07.36573B58 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable When using an explicit bind for referrals where sasl mechanisms=20 were used on the original LDAPConnection, the LDAPBind.bind() method will need access to the Hashtable parameter passed on the bind to get the credentials used. A method needs to be supplied in LDAPConnection to get the Hashtable object with semantics similar to what is now used for getAuthenticationPassword() -Steve >>> Steven Sonntag 13-Sep-00 1:55:06 PM >>> Shouldn't the SASL bind mechanisms also support the ability for the application to specify an LDAPConstraints object so that call specific controls can be specified? -Steve Steve Sonntag wrote: > 4.40.1 In the explaination of bind operations that use mechanisms > should the firstParagraph be changed from Authenticates to the LDAP > server (that the object is currently > connected to) using the specified name and of a specified set of > mechanisms. If none of the requested SASL mechanisms is available, > an > Authenticates to the LDAP server (that the object is currently > connected to) using the specified name and ONE of a specified set > of <---- > mechanisms. If none of the requested SASL mechanisms is available, > anWhat does it mean - if the first version of the method (i.e. the > one that specifies no mechanism) > is called, the LDAP server will be interrogated for its > supportedSaslMechanisms attribute of its root DSE. What does it do > after the LDAP server is interrogated? Does it use oneof them, and if > so how does the application know which one is usedand how does it know > what kind of credentials to supply? -Steve --=_D9812C07.36573B58-- From list@netscape.com Thu Sep 14 18:34: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 SMTP id SAA26970 for ; Thu, 14 Sep 2000 18:34: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 e8EMQTu21649; Thu, 14 Sep 2000 15:26:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8EMWgM00920; Thu, 14 Sep 2000 15:32:42 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 15:32:42 -0700 (PDT) Date: Thu, 14 Sep 2000 15:32:32 -0700 (PDT) Message-Id: <200009142232.e8EMWMu11707@ywing.netscape.com> From: lookingup@skywardnet.net To: You@ywing.netscape.com, &@ywing.netscape.com, Yours@netscape.com Subject: IMPORTANT! -KBXB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JpFY6D.A.EO.JIVw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Let's say that you're doing very nicely in your on line business, and things are going quite well....that's great! Now, let's suppose that you get into an accident tomorrow and then you die. WOW! The only question that is important now is this.....Where are you going to go? You see, what is really important is that you must have your sins forgiven now, in this life , if you're to enter heaven's door. And my friend, there is a way, and only one way to get there, and that is to believe on the Lord Jesus Christ as your Savior! Ask the Almighty God to forgive you through His Son Jesus' dying on the cross for those who would believe on Him and trust Him to be their Redeemer. Ask Him to change your heart to want to do the things and love the things that He wants you to do, and love. Seek Him with all your heart and you will find Him. Call upon Him while He is near. Today is the day of salvation, the Bible say's. You might not have tomorrow! Anyone who dies unsaved, will suffer forever in a place called Hell, and it is a place of no escape! Please come to the truth of this matter and consider your ways......Are you right with God? Is His word in your heart through the day? Do you love Him and desire to be with Him? If not, once again, ask Him to give you this desire for Him and His ways, and to turn your heart from the passions and lusts of this wicked world, and towards Him that you might be one of His children, forgiven of every sin that you would ever commit in your entire life! Forgiven! Do you now see the most important thing in life? Get on your knees tonight my friend, and pray like you've never done before. Time is short for everyone! From list@netscape.com Thu Sep 14 19:56: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 SMTP id TAA27553 for ; Thu, 14 Sep 2000 19:56: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 e8ENn4u20276; Thu, 14 Sep 2000 16:49:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8ENO3A24049; Thu, 14 Sep 2000 16:24:03 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 16:24:03 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Thu, 14 Sep 2000 17:23:40 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_227AD7EF.D5B4D88B" Resent-Message-ID: <"FNbk4D.A.f3F.S4Vw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_227AD7EF.D5B4D88B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kurt, I agree with everything you say here except I don't get one point: >However, if the >server holds for in an entry: > cn: foo > cn;lang-x-rot13: sbb > >and request cn;binary the server should only return the >first value (using binary transfer) and not the second. >This seems odd to me. Then, again, ;binary is odd. Explain why you wouldn't return both? Are you saying that the lang-x-rot13 = is defined to be a transfer-only attribute type option? The only other = case I can think of is where the server doesn't know how to return a = binary version of the rot13 value. Then I just wanted to idly bitch for a bit... The way attribute type = options are overloaded to sometimes be treated as subtypes and other times = only affect transfer format is a nasty thing. I really hope we can = document the difference well in 2251bis, and state that in fact, attribute = type options that only affect wire transfer are NOT subtypes. It'd be even = better if we had a different nomenclature for those. Jim >>> "Kurt D. Zeilenga" 9/13/00 7:31:27 PM >>> At 06:12 PM 9/13/00 -0600, Jim Sermersheim wrote: >I have a few questions about RFC 2596 (Language Codes in LDAP). Timely post... I've been meaning to post my comments regarding this TS based upon my recent implementation of it. >Section 3.1 says "Multiple language options may be present on a particular= value.". >To me, this says the following is allowable: >cn;lang-en-US;lang-ja: JoeBob >Is that correct? Yes. But I believe this should be changed to: "An attribute description SHALL NOT contain more than one language option." with that said, the statement above might have actually meant: An entry MAY contain any number of attributes with or without language options. That is, the statement may just refer to the fact that you can have: cn: x cn;lang-en: x cn;lang-en-us: x and not, how you and I read it. That is, as allowing: cn;lang-en;lang-en-us: x >If so, I believe the following assumption is also correct: >Any value held in an attribute with more than one language option (i.e. = the example above) does NOT exist in the attribute with a subset of those = language options. In other words, the example above does NOT imply that = there are values like: >cn;lang-en-US: JoeBob >cn;lang-ja: JoeBob >Right? That's my read as well. "cn;lang-en-US;lang-ja" has super types "cn", "name;lang-en-US;lang-ja", and "name". >I don't want to believe part of Section 3.3. It says that given the = filter (name;lang-en-US"=3DBilly Ray), that the following is a match: >CN;lang-EN-US;dynamic: Billy Ray >To me, this is a different, distinct subtype. In other words: >cn;foo is a subtype of cn >cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn. >Am I off in my thinking? RFC 2251 says that "An AttributeDescription with = one or more options is treated as a subtype of the attribute type without = any options". What about "cn;binary;lang-en"? Should not this have the same super types of "cn;lang-en" but be transferred using ";binary"? Is ";dynamic" like ";binary"? Why aren't multiple language tags, if allowed, like this? I concur that this is counter to RFC2251. However, if the server holds for in an entry: cn: foo cn;lang-x-rot13: sbb and request cn;binary the server should only return the first value (using binary transfer) and not the second. This seems odd to me. Then, again, ;binary is odd. >Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic = examples in 2596 are invalid. RFC 2251 states that the options must appear = in ascending order. Correct. >=20 >At the end of section 3.3, it says: "Thus in general, clients SHOULD NOT = use the language code option in AttributeDescription fields in search = filters". Is this because they might get more matches than they bargained = for? It would be nice if the "Thus in general" part was spelled out a bit = more. This seems odd. I would think the opposite to be true. That is, if I search for "cn=3Dfoo" I will match more than just cn values, I'll match cn;lang-en, cn;lang-x-rot13, etc.. In our implementation, we don't allow multiple language tags (as you and I read the RFC) as they don't behave like other content (e.g MIME) tags with multiple language tags. And, unlike some implements, we adhere to the following: Implementations MUST NOT otherwise interpret the structure of the code when comparing two codes, and MUST treat them as simply strings of characters. So, if you want to tag some content for multiple languages, you have to provide it as separate attribute descriptions: cn: foo cn;lang-EN: foo cn;lang-EN-US: foo cn;lang-EN-GB: foo cn;lang-x-rot13: sbb and request search to return "cn" would return all and "cn;lang-X" would return the particular "cn;lang-X" value. As far as ";binary" is concerned, we'd strip it from the option list before doing subtyping. So, asking for "cn;binary" would return all them using binary transfer. BTW, we don't actually support binary transfer of directoryString (yet), but we do this for syntaxes we do support binary transfer of. --=_227AD7EF.D5B4D88B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kurt, I agree with everything you say here except I = don't get=20 one point:
 
>However, if the
>server holds for in an=20 entry:
>        cn:=20 foo
>        cn;lang-x-rot13:=20 sbb
>
>and request cn;binary the server should only return=20 the
>first value (using binary transfer) and not the second.
>T= his=20 seems odd to me.  Then, again, ;binary is odd.
 
Explain why you wouldn't return both? Are you saying that the = lang-x-rot13=20 is defined to be a transfer-only attribute type option? The only other = case I=20 can think of is where the server doesn't know how to return a binary = version of=20 the rot13 value.
 
Then I just wanted to idly bitch for a bit... The way attribute = type=20 options are overloaded to sometimes be treated as subtypes and other times = only=20 affect transfer format is a nasty thing. I really hope we can document = the=20 difference well in 2251bis, and state that in fact, attribute type options = that=20 only affect wire transfer are NOT subtypes. It'd be even better if we had = a=20 different nomenclature for those.
 
Jim


>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org&g= t;=20 9/13/00 7:31:27 PM >>>
At 06:12 PM 9/13/00 -0600, Jim = Sermersheim=20 wrote:
>I have a few questions about RFC 2596 (Language Codes in=20 LDAP).

Timely post... I've been meaning to post my comments=20 regarding
this TS based upon my recent implementation of=20 it.

>Section 3.1 says "Multiple language options may be present = on a=20 particular value.".
>To me, this says the following is=20 allowable:
>cn;lang-en-US;lang-ja: JoeBob
>Is that=20 correct?

Yes.  But I believe this should be changed=20 to:
        "An attribute description= =20 SHALL NOT contain more than
        = one=20 language option."

with that said, the statement above might have = actually=20 meant:
  An entry MAY contain any number of attributes with = or
 =20 without language options.

That is, the statement may just refer to = the=20 fact that you
can have:
        = cn:=20 x
        cn;lang-en:=20 x
        cn;lang-en-us: x

and= not,=20 how you and I read it.  That is, as=20 allowing:
        cn;lang-en;lang-en-= us:=20 x


>If so, I believe the following assumption is also=20 correct:
>Any value held in an attribute with more than one = language=20 option (i.e. the example above) does NOT exist in the attribute with a = subset of=20 those language options. In other words, the example above does NOT imply = that=20 there are values like:
>cn;lang-en-US: JoeBob
>cn;lang-ja:=20 JoeBob
>Right?

That's my read as well. =20 "cn;lang-en-US;lang-ja" has super types
"cn", "name;lang-en-US;lang-ja",= and=20 "name".

>I don't want to believe part of Section 3.3. It says = that=20 given the filter (name;lang-en-US"=3DBilly Ray), that the following is = a=20 match:
>CN;lang-EN-US;dynamic: Billy Ray
>To me, this is a=20 different, distinct subtype. In other words:
>cn;foo is a subtype = of=20 cn
>cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype = of=20 cn.
>Am I off in my thinking? RFC 2251 says that "An AttributeDescrip= tion=20 with one or more options is treated as a subtype of the attribute type = without=20 any options".

What about "cn;binary;lang-en"?  Should not this = have=20 the same
super types of "cn;lang-en" but be transferred using=20 ";binary"?
Is ";dynamic" like ";binary"?
Why aren't multiple = language=20 tags, if allowed, like this?

I concur that this is counter to=20 RFC2251.  However, if the
server holds for in an=20 entry:
        cn:=20 foo
        cn;lang-x-rot13:=20 sbb

and request cn;binary the server should only return the
first= =20 value (using binary transfer) and not the second.
This seems odd to = me. =20 Then, again, ;binary is odd.


>Also, both my cn;foo;bar = example and=20 all the CN;lang-EN-US;dynamic examples in 2596 are invalid. RFC 2251 = states that=20 the options must appear in ascending order.

Correct.

>=20
>At the end of section 3.3, it says: "Thus in general, clients = SHOULD NOT=20 use the language code option in AttributeDescription fields in search = filters".=20 Is this because they might get more matches than they bargained for? It = would be=20 nice if the "Thus in general" part was spelled out a bit more.

This = seems=20 odd.  I would think the opposite to be true.  That
is, if I = search=20 for "cn=3Dfoo" I will match more than just cn values,
I'll match = cn;lang-en,=20 cn;lang-x-rot13, etc..

In our implementation, we don't allow = multiple=20 language tags
(as you and I read the RFC) as they don't behave like=20 other
content (e.g MIME) tags with multiple language tags. =20 And,
unlike some implements, we adhere to the following:
  = =20 Implementations MUST NOT otherwise interpret the structure of=20 the
   code when comparing two codes, and MUST treat them as = simply=20 strings
   of characters.

So, if you want to tag = some=20 content for multiple languages, you
have to provide it as separate = attribute=20 descriptions:
        cn:=20 foo
        cn;lang-EN:=20 foo
        cn;lang-EN-US:=20 foo
        cn;lang-EN-GB:=20 foo
        cn;lang-x-rot13:=20 sbb

and request search to return "cn" would return all and=20 "cn;lang-X"
would return the particular "cn;lang-X" value.

As = far as=20 ";binary" is concerned, we'd strip it from the option
list before = doing=20 subtyping.  So, asking for "cn;binary" would
return all them = using=20 binary transfer.

BTW, we don't actually support binary transfer = of=20 directoryString
(yet), but we do this for syntaxes we do support = binary=20 transfer
of.





--=_227AD7EF.D5B4D88B-- From list@netscape.com Thu Sep 14 20:06: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 SMTP id UAA27636 for ; Thu, 14 Sep 2000 20:06: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 e8ENwhu23941; Thu, 14 Sep 2000 16:58:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8F04vo13120; Thu, 14 Sep 2000 17:04:57 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 17:04:57 -0700 (PDT) Message-Id: <5.0.0.25.0.20000914163728.00a582e0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 14 Sep 2000 17:04:16 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: RFC 2596 questions Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"nNYr6.A.uMD.oeWw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:23 PM 9/14/00 -0600, Jim Sermersheim wrote: >Kurt, I agree with everything you say here except I don't get one point: > >>However, if the >>server holds for in an entry: >> cn: foo >> cn;lang-x-rot13: sbb >> >>and request cn;binary the server should only return the >>first value (using binary transfer) and not the second. >>This seems odd to me. Then, again, ;binary is odd. > >Explain why you wouldn't return both? For the same reasons "cn;lang-en" shouldn't return "cn;lang-en;lang-en-us" nor "cn;lang-en-us;dynamic". An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. That is, cn;binary is a subtype of cn cn;lang-x-rot13 is a subtype of cn cn;binary;lang-x-rot13 is a subtype of cn but cn;binary;lang-x-rot13 is NOT a subtype of cn;binary So, when requesting cn;binary you only get cn;binary. However, I think most servers (if they returned binary transfer for the attributes syntax) would return cn;binary and cn;binary;lang-x-rot13. Maybe we read what we want into this statement: The presence or absence of the "binary" option only affects the transfer of attribute values in protocol; ... That is, taking it out of context of the rest of the sentence: servers store any particular attribute in a single format. >Are you saying that the lang-x-rot13 is defined to be a transfer-only attribute type option? no. I'm saying that it appears that everyone is treating ";binary" as a flag to indicate a different transfer mode, not as subtyping option. >The only other case I can think of is where the server doesn't know how to return a binary version of the rot13 value. They are all directoryStrings so if ;binary is support for one, likely supported for all. >Then I just wanted to idly bitch for a bit... The way attribute type options are overloaded to sometimes be treated as subtypes and other times only affect transfer format is a nasty thing. I concur... I have an idle bitch of my own: For x of syntax binary and I ask for "x". Are folks expecting to get "x;binary" or just "x" when they ask for all attributes? inetOrgPerson defines some attributes of binary syntax and says they should be transferred using ";binary". Are there counter examples? What do implementations do? OpenLDAP currently always transfer a binary syntax attribute using ;binary. This is legal, but is it expected? >I really hope we can document the difference well in 2251bis, and state that in fact, attribute type options that only affect wire transfer are NOT subtypes. I concur. >It'd be even better if we had a different nomenclature for those. Too late for that, I think. >Jim > > >>>> "Kurt D. Zeilenga" 9/13/00 7:31:27 PM >>> >At 06:12 PM 9/13/00 -0600, Jim Sermersheim wrote: >>I have a few questions about RFC 2596 (Language Codes in LDAP). > >Timely post... I've been meaning to post my comments regarding >this TS based upon my recent implementation of it. > >>Section 3.1 says "Multiple language options may be present on a particular value.". >>To me, this says the following is allowable: >>cn;lang-en-US;lang-ja: JoeBob >>Is that correct? > >Yes. But I believe this should be changed to: > "An attribute description SHALL NOT contain more than > one language option." > >with that said, the statement above might have actually meant: > An entry MAY contain any number of attributes with or > without language options. > >That is, the statement may just refer to the fact that you >can have: > cn: x > cn;lang-en: x > cn;lang-en-us: x > >and not, how you and I read it. That is, as allowing: > cn;lang-en;lang-en-us: x > > >>If so, I believe the following assumption is also correct: >>Any value held in an attribute with more than one language option (i.e. the example above) does NOT exist in the attribute with a subset of those language options. In other words, the example above does NOT imply that there are values like: >>cn;lang-en-US: JoeBob >>cn;lang-ja: JoeBob >>Right? > >That's my read as well. "cn;lang-en-US;lang-ja" has super types >"cn", "name;lang-en-US;lang-ja", and "name". > >>I don't want to believe part of Section 3.3. It says that given the filter (name;lang-en-US"=Billy Ray), that the following is a match: >>CN;lang-EN-US;dynamic: Billy Ray >>To me, this is a different, distinct subtype. In other words: >>cn;foo is a subtype of cn >>cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn. >>Am I off in my thinking? RFC 2251 says that "An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options". > >What about "cn;binary;lang-en"? Should not this have the same >super types of "cn;lang-en" but be transferred using ";binary"? >Is ";dynamic" like ";binary"? >Why aren't multiple language tags, if allowed, like this? > >I concur that this is counter to RFC2251. However, if the >server holds for in an entry: > cn: foo > cn;lang-x-rot13: sbb > >and request cn;binary the server should only return the >first value (using binary transfer) and not the second. >This seems odd to me. Then, again, ;binary is odd. > > >>Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic examples in 2596 are invalid. RFC 2251 states that the options must appear in ascending order. > >Correct. > >> >>At the end of section 3.3, it says: "Thus in general, clients SHOULD NOT use the language code option in AttributeDescription fields in search filters". Is this because they might get more matches than they bargained for? It would be nice if the "Thus in general" part was spelled out a bit more. > >This seems odd. I would think the opposite to be true. That >is, if I search for "cn=foo" I will match more than just cn values, >I'll match cn;lang-en, cn;lang-x-rot13, etc.. > >In our implementation, we don't allow multiple language tags >(as you and I read the RFC) as they don't behave like other >content (e.g MIME) tags with multiple language tags. And, >unlike some implements, we adhere to the following: > Implementations MUST NOT otherwise interpret the structure of the > code when comparing two codes, and MUST treat them as simply strings > of characters. > >So, if you want to tag some content for multiple languages, you >have to provide it as separate attribute descriptions: > cn: foo > cn;lang-EN: foo > cn;lang-EN-US: foo > cn;lang-EN-GB: foo > cn;lang-x-rot13: sbb > >and request search to return "cn" would return all and "cn;lang-X" >would return the particular "cn;lang-X" value. > >As far as ";binary" is concerned, we'd strip it from the option >list before doing subtyping. So, asking for "cn;binary" would >return all them using binary transfer. > >BTW, we don't actually support binary transfer of directoryString >(yet), but we do this for syntaxes we do support binary transfer >of. > > > > From list@netscape.com Thu Sep 14 21:48:06 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 SMTP id VAA29571 for ; Thu, 14 Sep 2000 21:48: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 e8F1ZTV19951; Thu, 14 Sep 2000 18:35:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8F1jsY25390; Thu, 14 Sep 2000 18:45:54 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 18:45:54 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Thu, 14 Sep 2000 19:45:26 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_CB933E24.32533FED" Resent-Message-ID: <"6ppcLB.A.cMG.R9Xw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_CB933E24.32533FED Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >no. I'm saying that it appears that everyone is treating ";binary" >as a flag to indicate a different transfer mode, not as subtyping >option. That's the way I'd like to treat it, and I'd like it called out that way = in the bis doc. This disparity explains my earlier confusion. Jim >>> "Kurt D. Zeilenga" 9/14/00 6:04:16 PM >>> At 05:23 PM 9/14/00 -0600, Jim Sermersheim wrote: >Kurt, I agree with everything you say here except I don't get one point: >=20 >>However, if the >>server holds for in an entry: >> cn: foo >> cn;lang-x-rot13: sbb >> >>and request cn;binary the server should only return the >>first value (using binary transfer) and not the second. >>This seems odd to me. Then, again, ;binary is odd. >=20 >Explain why you wouldn't return both? For the same reasons "cn;lang-en" shouldn't return "cn;lang-en;lang-en-us" nor "cn;lang-en-us;dynamic". An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options.=20 That is, cn;binary is a subtype of cn cn;lang-x-rot13 is a subtype of cn cn;binary;lang-x-rot13 is a subtype of cn but cn;binary;lang-x-rot13 is NOT a subtype of cn;binary So, when requesting cn;binary you only get cn;binary. However, I think most servers (if they returned binary transfer for the attributes syntax) would return cn;binary and cn;binary;lang-x-rot13. Maybe we read what we want into this statement: The presence or absence of the "binary" option only affects the transfer of attribute values in protocol; ... That is, taking it out of context of the rest of the sentence: servers store any particular attribute in a single format. =20 >Are you saying that the lang-x-rot13 is defined to be a transfer-only = attribute type option? no. I'm saying that it appears that everyone is treating ";binary" as a flag to indicate a different transfer mode, not as subtyping option. >The only other case I can think of is where the server doesn't know how = to return a binary version of the rot13 value. They are all directoryStrings so if ;binary is support for one, likely supported for all. >Then I just wanted to idly bitch for a bit... The way attribute type = options are overloaded to sometimes be treated as subtypes and other times = only affect transfer format is a nasty thing. I concur... =20 I have an idle bitch of my own: For x of syntax binary and I ask for "x". Are folks expecting to get "x;binary" or just "x" when they ask for all attributes? inetOrgPerson defines some attributes of binary syntax and says they should be transferred using ";binary". Are there counter examples? What do implementations do?=20 OpenLDAP currently always transfer a binary syntax attribute using ;binary. This is legal, but is it expected? >I really hope we can document the difference well in 2251bis, and state = that in fact, attribute type options that only affect wire transfer are = NOT subtypes. I concur. >It'd be even better if we had a different nomenclature for those. Too late for that, I think. >Jim > > >>>> "Kurt D. Zeilenga" 9/13/00 7:31:27 PM >>> >At 06:12 PM 9/13/00 -0600, Jim Sermersheim wrote: >>I have a few questions about RFC 2596 (Language Codes in LDAP). > >Timely post... I've been meaning to post my comments regarding >this TS based upon my recent implementation of it. > >>Section 3.1 says "Multiple language options may be present on a = particular value.". >>To me, this says the following is allowable: >>cn;lang-en-US;lang-ja: JoeBob >>Is that correct? > >Yes. But I believe this should be changed to: > "An attribute description SHALL NOT contain more than > one language option." > >with that said, the statement above might have actually meant: > An entry MAY contain any number of attributes with or > without language options. > >That is, the statement may just refer to the fact that you >can have: > cn: x > cn;lang-en: x > cn;lang-en-us: x > >and not, how you and I read it. That is, as allowing: > cn;lang-en;lang-en-us: x > > >>If so, I believe the following assumption is also correct: >>Any value held in an attribute with more than one language option (i.e. = the example above) does NOT exist in the attribute with a subset of those = language options. In other words, the example above does NOT imply that = there are values like: >>cn;lang-en-US: JoeBob >>cn;lang-ja: JoeBob >>Right? > >That's my read as well. "cn;lang-en-US;lang-ja" has super types >"cn", "name;lang-en-US;lang-ja", and "name". > >>I don't want to believe part of Section 3.3. It says that given the = filter (name;lang-en-US"=3DBilly Ray), that the following is a match: >>CN;lang-EN-US;dynamic: Billy Ray >>To me, this is a different, distinct subtype. In other words: >>cn;foo is a subtype of cn >>cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn. >>Am I off in my thinking? RFC 2251 says that "An AttributeDescription = with one or more options is treated as a subtype of the attribute type = without any options". > >What about "cn;binary;lang-en"? Should not this have the same >super types of "cn;lang-en" but be transferred using ";binary"? >Is ";dynamic" like ";binary"? >Why aren't multiple language tags, if allowed, like this? > >I concur that this is counter to RFC2251. However, if the >server holds for in an entry: > cn: foo > cn;lang-x-rot13: sbb > >and request cn;binary the server should only return the >first value (using binary transfer) and not the second. >This seems odd to me. Then, again, ;binary is odd. > > >>Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic = examples in 2596 are invalid. RFC 2251 states that the options must appear = in ascending order. > >Correct. > >>=20 >>At the end of section 3.3, it says: "Thus in general, clients SHOULD NOT = use the language code option in AttributeDescription fields in search = filters". Is this because they might get more matches than they bargained = for? It would be nice if the "Thus in general" part was spelled out a bit = more. > >This seems odd. I would think the opposite to be true. That >is, if I search for "cn=3Dfoo" I will match more than just cn values, >I'll match cn;lang-en, cn;lang-x-rot13, etc.. > >In our implementation, we don't allow multiple language tags >(as you and I read the RFC) as they don't behave like other >content (e.g MIME) tags with multiple language tags. And, >unlike some implements, we adhere to the following: > Implementations MUST NOT otherwise interpret the structure of the > code when comparing two codes, and MUST treat them as simply strings > of characters. > >So, if you want to tag some content for multiple languages, you >have to provide it as separate attribute descriptions: > cn: foo > cn;lang-EN: foo > cn;lang-EN-US: foo > cn;lang-EN-GB: foo > cn;lang-x-rot13: sbb > >and request search to return "cn" would return all and "cn;lang-X" >would return the particular "cn;lang-X" value. > >As far as ";binary" is concerned, we'd strip it from the option >list before doing subtyping. So, asking for "cn;binary" would >return all them using binary transfer. > >BTW, we don't actually support binary transfer of directoryString >(yet), but we do this for syntaxes we do support binary transfer >of. > > > > --=_CB933E24.32533FED Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>no.  I'm saying that it appears that = everyone=20 is treating ";binary"
>as a flag to indicate a different transfer = mode,=20 not as subtyping
>option.
 
That's the way I'd like to treat it, and I'd like it called out that = way in=20 the bis doc. This disparity explains my earlier confusion.

Jim
=

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 9/14/00=20 6:04:16 PM >>>
At 05:23 PM 9/14/00 -0600, Jim Sermersheim=20 wrote:
>Kurt, I agree with everything you say here except I don't = get one=20 point:
>
>>However, if the
>>server holds for in = an=20 entry:
>>        cn:=20 foo
>>        cn;lang-x-rot13:= =20 sbb
>>
>>and request cn;binary the server should only = return=20 the
>>first value (using binary transfer) and not the=20 second.
>>This seems odd to me.  Then, again, ;binary is=20 odd.
>
>Explain why you wouldn't return both?

For the = same=20 reasons "cn;lang-en" shouldn't return
"cn;lang-en;lang-en-us" nor=20 "cn;lang-en-us;dynamic".
   An AttributeDescription with one = or=20 more options is treated as a
   subtype of the attribute = type=20 without any options.

That=20 is,
        cn;binary is a subtype = of=20 cn
        cn;lang-x-rot13 is a = subtype of=20 cn
        cn;binary;lang-x-rot13 is = a=20 subtype of cn

but
       =20 cn;binary;lang-x-rot13 is NOT a subtype of cn;binary

So, when = requesting=20 cn;binary you only get cn;binary.  However,
I think most servers = (if=20 they returned binary transfer for the
attributes syntax) would = return=20 cn;binary and cn;binary;lang-x-rot13.

Maybe we read what we want = into=20 this statement:
   The presence or absence of the "binary" = option=20 only affects the
   transfer of attribute values in = protocol;=20 ...
That is, taking it out of context of the rest of the=20 sentence:
   servers store any particular attribute in a = single=20 format. 

>Are you saying that the lang-x-rot13 is defined = to be=20 a transfer-only attribute type option?

no.  I'm saying that = it=20 appears that everyone is treating ";binary"
as a flag to indicate a = different=20 transfer mode, not as subtyping
option.

>The only other case = I can=20 think of is where the server doesn't know how to return a binary version = of the=20 rot13 value.

They are all directoryStrings so if ;binary is support = for=20 one,
likely supported for all.

>Then I just wanted to idly = bitch=20 for a bit... The way attribute type options are overloaded to sometimes = be=20 treated as subtypes and other times only affect transfer format is a = nasty=20 thing.

I concur... 

I have an idle bitch of my = own: =20 For x of syntax binary and
I ask for "x".  Are folks expecting to = get=20 "x;binary" or just "x"
when they ask for all attributes?  = inetOrgPerson=20 defines some
attributes of binary syntax and says they should be=20 transferred
using ";binary".  Are there counter examples?  = What do=20 implementations
do?

OpenLDAP currently always transfer a = binary=20 syntax attribute using
;binary.  This is legal, but is it=20 expected?


>I really hope we can document the difference well = in=20 2251bis, and state that in fact, attribute type options that only affect = wire=20 transfer are NOT subtypes.

I concur.

>It'd be even better = if we=20 had a different nomenclature for those.

Too late for that, I=20 think.


>Jim
>
>
>>>> "Kurt D. = Zeilenga"=20 <Kurt@OpenLDAP.org> 9/13/00 7:31:27 PM >>>
>At 06:12 = PM=20 9/13/00 -0600, Jim Sermersheim wrote:
>>I have a few questions = about=20 RFC 2596 (Language Codes in LDAP).
>
>Timely post... I've = been=20 meaning to post my comments regarding
>this TS based upon my = recent=20 implementation of it.
>
>>Section 3.1 says "Multiple = language=20 options may be present on a particular value.".
>>To me, this = says the=20 following is allowable:
>>cn;lang-en-US;lang-ja: JoeBob
>>= ;Is=20 that correct?
>
>Yes.  But I believe this should be = changed=20 to:
>        "An attribute = description=20 SHALL NOT contain more than
>      &nbs= p;=20 one language option."
>
>with that said, the statement above = might=20 have actually meant:
>  An entry MAY contain any number of = attributes=20 with or
>  without language options.
>
>That is, = the=20 statement may just refer to the fact that you
>can=20 have:
>        cn:=20 x
>        cn;lang-en:=20 x
>        cn;lang-en-us:=20 x
>
>and not, how you and I read it.  That is, as=20 allowing:
>       =20 cn;lang-en;lang-en-us: x
>
>
>>If so, I believe = the=20 following assumption is also correct:
>>Any value held in an = attribute=20 with more than one language option (i.e. the example above) does NOT exist = in=20 the attribute with a subset of those language options. In other words, = the=20 example above does NOT imply that there are values=20 like:
>>cn;lang-en-US: JoeBob
>>cn;lang-ja:=20 JoeBob
>>Right?
>
>That's my read as well. =20 "cn;lang-en-US;lang-ja" has super types
>"cn", "name;lang-en-US;lang-= ja",=20 and "name".
>
>>I don't want to believe part of Section = 3.3. It=20 says that given the filter (name;lang-en-US"=3DBilly Ray), that the = following is a=20 match:
>>CN;lang-EN-US;dynamic: Billy Ray
>>To me, this = is a=20 different, distinct subtype. In other words:
>>cn;foo is a = subtype of=20 cn
>>cn;foo;bar is NOT a subtype of cn;foo, it is a direct = subtype of=20 cn.
>>Am I off in my thinking? RFC 2251 says that "An=20 AttributeDescription with one or more options is treated as a subtype of = the=20 attribute type without any options".
>
>What about=20 "cn;binary;lang-en"?  Should not this have the same
>super = types of=20 "cn;lang-en" but be transferred using ";binary"?
>Is ";dynamic" = like=20 ";binary"?
>Why aren't multiple language tags, if allowed, like=20 this?
>
>I concur that this is counter to RFC2251.  = However, if=20 the
>server holds for in an=20 entry:
>        cn:=20 foo
>        cn;lang-x-rot13:=20 sbb
>
>and request cn;binary the server should only return=20 the
>first value (using binary transfer) and not the second.
>T= his=20 seems odd to me.  Then, again, ;binary is=20 odd.
>
>
>>Also, both my cn;foo;bar example and all = the=20 CN;lang-EN-US;dynamic examples in 2596 are invalid. RFC 2251 states that = the=20 options must appear in ascending=20 order.
>
>Correct.
>
>>
>>At the end = of=20 section 3.3, it says: "Thus in general, clients SHOULD NOT use the = language code=20 option in AttributeDescription fields in search filters". Is this because = they=20 might get more matches than they bargained for? It would be nice if the = "Thus in=20 general" part was spelled out a bit more.
>
>This seems = odd.  I=20 would think the opposite to be true.  That
>is, if I search = for=20 "cn=3Dfoo" I will match more than just cn values,
>I'll match = cn;lang-en,=20 cn;lang-x-rot13, etc..
>
>In our implementation, we don't = allow=20 multiple language tags
>(as you and I read the RFC) as they don't = behave=20 like other
>content (e.g MIME) tags with multiple language tags. = ;=20 And,
>unlike some implements, we adhere to the=20 following:
>   Implementations MUST NOT otherwise = interpret the=20 structure of the
>   code when comparing two codes, and = MUST=20 treat them as simply strings
>   of=20 characters.
>
>So, if you want to tag some content for = multiple=20 languages, you
>have to provide it as separate attribute=20 descriptions:
>        cn:=20 foo
>        cn;lang-EN:=20 foo
>        cn;lang-EN-US:=20 foo
>        cn;lang-EN-GB:=20 foo
>        cn;lang-x-rot13:=20 sbb
>
>and request search to return "cn" would return all = and=20 "cn;lang-X"
>would return the particular "cn;lang-X"=20 value.
>
>As far as ";binary" is concerned, we'd strip it from = the=20 option
>list before doing subtyping.  So, asking for "cn;binary"= =20 would
>return all them using binary transfer.
>
>BTW, we = don't=20 actually support binary transfer of directoryString
>(yet), but we = do this=20 for syntaxes we do support binary=20 transfer
>of.
>
>
>
>

--=_CB933E24.32533FED-- From list@netscape.com Thu Sep 14 22:22: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 SMTP id WAA29883 for ; Thu, 14 Sep 2000 22:22: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 e8F2A7V26841; Thu, 14 Sep 2000 19:10:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8F2KXc06011; Thu, 14 Sep 2000 19:20:33 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 19:20:33 -0700 (PDT) X-Sender: free_marketing@yahoo.com From: "free_marketing@yahoo.com" To: "Free Marketing Club" Date: Fri, 15 Sep 2000 03:19:57 +0100 Subject: A FREE MARKETING CLUB? MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Resent-Message-ID: <"E77QOB.A.pdB.wdYw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Are you tired of paying hard earned money for information which should come free? Well now there is a solution. A marketing club which is 100% FREE!! There are no extra costs or hidden costs.....EVER!!! This is what you get when you register for FREE : - Submissions to THOUSANDS of classifieds - Send to hundreds of Opt-In Lists FREE - Download up to 5 million Targeted Emails totally FREE - The latest software and e-reports downloadable in seconds. - Tutorials, links and software to help you design professional level webpages - And much much MORE!!! Why are we giving all of this away for free?........Well why the hell not!! I have been an internet marketer for quite a while and I have had to pay hundreds of dollars in order to be successfull. Well now I want to change this so that ANYBODY can attain their goal, even if they have nothing to start off with. You wanna join yet? http://members.netscapeonline.co.uk/hilalkan/ ------------------------------------------------------------------------ This is not SPAM. You are receiving this because we have exchanged ads in the past. If you wish to be removed from this list then please reply to this message with remove as the subject. ----------------------------------------------------------------------- From list@netscape.com Fri Sep 15 02:55: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 SMTP id CAA15610 for ; Fri, 15 Sep 2000 02:55: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 e8F6mAu11772; Thu, 14 Sep 2000 23:48:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8F6sPs07022; Thu, 14 Sep 2000 23:54:25 -0700 (PDT) Resent-Date: Thu, 14 Sep 2000 23:54:25 -0700 (PDT) Message-Id: <200009150515.HAA21447@ametyst.zsb.tarnow.pl> From: "Francis Yuri" Subject: The Guild #1770 To: in39d@ametyst.zsb.tarnow.pl X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Thu, 14 Sep 2000 23:47:41 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Resent-Message-ID: <"ZTPyO.A.ctB.fecw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Professional,

You have been selected as a potential candidate for biographical
inclusion in the 2000 - 2001 Edition of the International Executive
Guild Registry=2E

Please accept our congratulations for this coveted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be published in two
different formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
= and professionalism, each candidate is evaluated in keeping with high
= standards of individual achievement=2E In light of this, the Internationa= l
Executive Guild thinks that you may make an interesting biographical
subject=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best wishes for your continued success=2E
International Executive Guild
Listing Dept=2E

P=2ES=2E There is no cost or obligation to be included in the Internation= al
Executive Guild Registry=2E For accuracy and publication purposes, we ask=
you to fill in the brief bit of information in the registration form
below=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From list@netscape.com Fri Sep 15 07:20:01 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 SMTP id HAA17524 for ; Fri, 15 Sep 2000 07:20: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 e8FB87X05567; Fri, 15 Sep 2000 04:08:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FBIX209294; Fri, 15 Sep 2000 04:18:33 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 04:18:33 -0700 (PDT) From: hahnt@us.ibm.com X-Priority: 3 (Normal) Importance: Normal To: ietf-ldapext@netscape.com Subject: Re: RFC 2596 questions X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 15 Sep 2000 07:18:14 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 09/15/2000 07:18:29 AM, Serialize complete at 09/15/2000 07:18:29 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003CFA678525695B_=" Resent-Message-ID: <"F5V_OC.A.8QC.IWgw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multipart message in MIME format. --=_alternative 003CFA678525695B_= Content-Type: text/plain; charset="us-ascii" Greetings, The discussion on this list regarding attribute descriptions has been quite useful to me - thanks for continuing it. I also hope that 2251 bis is much better about spelling out how these are to be handled. From the discussions so far on this list, it appears that attribute descriptions might be used in various ways. The trouble with this is that it implies that there is no "generic method" for handling attribute descriptions since each one might imply some special code in the server you are contacting. Unlike controls and extended operations, there is nothing in the rootDSE that gives any indication as to what attribute descriptions are supported or not. Thus, the use of them will, at least for the moment, result in applications that don't work, in general, across different server implementations. Should we investigate some additional rootDSE attribute to indicate the set of attribute descriptions that are supported? Further, when a new attribute description is defined, should we be assigning OIDs and keeping these as an additional part of the subschemasubentry data? I know of the following attribute descriptions that have been discussed: ;binary ;lang- from the discussions on the list and the I-Ds and RFCs that have been published we have a sense of what each means. Are there other attribute descriptions now proposed/defined? One more observation: there is currently a thread on the mailing list regarding "crosstalk issues" between multiple controls specified on LDAP operations. It seems that we run the same risk with multiple attribute descriptions if we are not careful. I think that the discussions over the past day have clarified alot of the intended handling of at least ;binary and ;land-. Thanks! I hope that we get the same level of detail into 2251 bis and the definition of future attribute descriptions. 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 --=_alternative 003CFA678525695B_= Content-Type: text/html; charset="us-ascii"
Greetings,

The discussion on this list regarding attribute descriptions has been quite useful to me - thanks for continuing it.  I also hope that 2251 bis is much better about spelling out how these are to be handled.

From the discussions so far on this list, it appears that attribute descriptions might be used in various ways.  The trouble with this is that it implies that there is no "generic method" for handling attribute descriptions since each one might imply some special code in the server you are contacting.  Unlike controls and extended operations, there is nothing in the rootDSE that gives any indication as to what attribute descriptions are supported or not.  Thus, the use of them will, at least for the moment, result in applications that don't work, in general, across different server implementations.

Should we investigate some additional rootDSE attribute to indicate the set of attribute descriptions that are supported?  Further, when a new attribute description is defined, should we be assigning OIDs and keeping these as an additional part of the subschemasubentry data?

I know of the following attribute descriptions that have been discussed:

;binary
;lang-<some code>

from the discussions on the list and the I-Ds and RFCs that have been published we have a sense of what each means.  Are there other attribute descriptions now proposed/defined?

One more observation:  there is currently a thread on the mailing list regarding "crosstalk issues" between multiple controls specified on LDAP operations.  It seems that we run the same risk with multiple attribute descriptions if we are not careful.

I think that the discussions over the past day have clarified alot of the intended handling of at least ;binary and ;land-<some code>.  Thanks!

I hope that we get the same level of detail into 2251 bis and the definition of future attribute descriptions.

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 --=_alternative 003CFA678525695B_=-- From list@netscape.com Fri Sep 15 09:46:29 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 SMTP id JAA19591 for ; Fri, 15 Sep 2000 09:46: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 e8FDYVX28275; Fri, 15 Sep 2000 06:34:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FDivI16748; Fri, 15 Sep 2000 06:44:58 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 06:44:58 -0700 (PDT) From: "Ryan Moats" To: Cc: Subject: New draft: draft-ietf-ldapext-ldap-taxonomy-03 Date: Fri, 15 Sep 2000 08:46:23 -0500 Message-ID: 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 In-Reply-To: Importance: Normal Resent-Message-ID: <"Qg4eWB.A.aFE.Yfiw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I-D editor: Please relace draft-ietf-ldapext-ldap-taxonomy-02 with the following draft. LDAPEXT folks: The following draft is a refresh of -02 done for 2 reasons: (1) -02 will expire any day now (2) Roland and my contact information were out of date Since this draft has already cleared working group last call and there are no technical changes, I don't believe that another last call is necessary. Rather, this document can continue in its current state of waiting for a dependent document to clear the working group. Ryan ===== Internet-Draft Ryan Moats draft-ietf-ldapext-ldap-taxonomy-03 Coreon, Inc. Expires in six months Roland Hedberg Track: Informational Catalogix September 2000 A Taxonomy of Methods for LDAP Clients Finding Servers Filename: draft-ietf-ldapext-ldap-taxonomy-03.txt Status of this Memo 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. Abstract There are several different methods for a LDAP client to find a LDAP server. This draft discusses these methods and provides pointers for interested parties to learn more about implementing a particular method. 1. Introduction The Lightweight Directory Access Protocol (LDAP) [1] can be used to build "islands" of servers that are not a priori tied into a single Directory Information Tree (DIT.) Here, it is necessary to determine how a client can discover LDAP servers. This documents discusses the currently available methods and provides pointers for interested parties to learn more about implementing a particular method. This draft documents only those methods that are currently being pursued in the IETF. Other methods have been considered for this Expires 3/31/2001 [Page 1] INTERNET DRAFT LDAP Taxonomy September 2000 problem and the history of these other methods are presented in the Appendix. 2. Methods 2.1 Client Configuration The simplest method of enabling a LDAP client to discover LDAP servers is for the client administrator to configure the client with a list of known LDAP servers (and associated base objects) to send queries to. While this method has the advantage of being correct (initially), it adds the requirement that the list of initial servers be kept small and constant. Otherwise, the required client update process won't scale. 2.2 Well known DNS aliases If the DIT uses a naming scheme similar to that in RFC 2377 [2], then it is possible to build the DNS names of potential servers using well known DNS aliases, like those documented in RFC 2219 [3]. When a different naming scheme is used, it is also possible to build potential server names based on the client's fully qualified domain name or local (within the organization or country) environment. One shortcoming of this method are that it is not exact. Multiple DNS lookups and LDAP protocol operations may be necessary to find the proper LDAP server to serve the client requests. To support client roaming, it is necessary that either the RFC 2377 (or similar) naming scheme be used or that roaming be implemented through tunnels. Because this method uses DNS, it inherits all the security considerations of using DNS to discover LDAP servers: see the security consideration in [3] for more details. 2.3 Service Location Protocol If a client supports the service location protocol [4], it could use a SLP query for LDAP servers. The SLP template that is used to describe LDAP servers is presented in [5], and requires that the servers announce themselves using SLP and this template. Using this method inherits the scaling and security considerations for the service location protocol, which are documented further in [4]. Expires 3/31/2001 [Page 2] INTERNET DRAFT LDAP Taxonomy September 2000 2.4 Referrals In LDAPv3, servers can return referrals to the client if the server has knowledge of where a query might be satisfiable. Two ways of deploying referral information are deploying a LDAP knowledge server or exchanging CIP index objects [6] between servers. A LDAP knowledge server would hold cross references to possibly hundreds of other LDAP servers, so that a client would only need to know about its local LDAP server and the knowledge server. As an optimization, the local LDAP server could also act as a knowledge server. If CIP index objects are exchanged between LDAP servers, then those objects can also carry URL information for providing referrals to clients. Here, the client would only need to know about the local server. Using CIP index objects inherits the security considerations of CIP: see [6, 7, 8] for more details. In either of these cases, the local LDAP server could be determined using another of the methods discussed. 2.5 Using SRV records RFC 2052 [12] defined SRV records for DNS, which bound a host name and port to a label in the DNS. This makes it possible for a client to look up information about a supported protocol for a domain and get back a weighted list of fully qualified domain names and ports for where that protocol is supported. For more information, see [13]. 3. Implementation The Norwegian Directory Forum plans to start a service based on a central LDAP service containing contact information for every organization within Norway [10]. If an organization has more information about its sub-units, employees or functions that it wants to publish it can do so by placing this information in a publicly available LDAP server and providing the management of the central service with a pointer (URL) to this server. The TISDAG project is running a test service based on the TISDAG specification [11]. This service gathers indices from connected White Pages Service Providers using CIP Tagged Index Objects [9]. The rationale for this service is that by supplying the name of a person or a function/role to the service it will return pointers to where more information can be found about persons/functions with that name. Expires 3/31/2001 [Page 3] INTERNET DRAFT LDAP Taxonomy September 2000 The European cofunded project DESIRE (www.desire.org) is designing a system to use a LDAP server that communicates with a referral index that in turn, uses CIP Tagged Index Objects [9] and is fed by LDAP crawlers. DANTE plans to set up a European infrastructure of such referral index servers. 4. References Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites. [1] M. Wahl, T. Howes, S. Kille, Lightweight Directory Access Protocol (v3), RFC 2251, December 1997. [2] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, Naming Plan for Internet Directory-Enabled Applications, RFC 2377, September 1998. [3] M. Hamilton, R. Wright, "Use of DNS Aliases for Network Ser- vices," RFC 2219 (Also BCP 17), October 1997. [4] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Loca- tion Protocol, Version 2," RFC 2608, June 1999. [5] J. Wood, R. Tam, "The LDAP Service Type," Internet Draft (work in progress), July 1999. [6] J. Allen, M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)," RFC 2651, August 1999. [7] J. Allen, M. Mealling, "MIME Object Definitions for the Com- mon Indexing Protocol (CIP)," RFC 2652, August 1999. [8] J. Allen, P. Leach, R. Hedberg, "CIP Transport Protocols," RFC 2653, August 1999. [9] R. Hedberg, B. Greenblatt, R. Moats, M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol," RFC 2654, August 1999. [10] R. Hedberg, H. Alverstrand, "Technical Specification, The Norwegian Directory of Directories (NDD)," Internet Draft (work in progress), May 1999. [11] R. Hedberg, L. Daigle, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," Internet Draft (work in progress), February 2000. Expires 8/31/2000 [Page 4] INTERNET DRAFT LDAP Taxonomy September 2000 [12] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the loca- tion of services (DNS SRV)," RFC 2052, October 1996. [13] M. Armijo, L. Esibov, P. Leach, "Discovering LDAP Services with DNS," Internet Draft (work in progress), July 1999. 5. Author's Addresses Ryan Moats Roland Hedberg Coreon, Inc. Catalogix 15621 Drexel Circle Dalsveien 53 Omaha, NE 68135 0775 Oslo USA Norway Email: rmoats@coreon.net Email: roland@catalogix.se Appendix A. Historical Methods A.1 Discovery The discovery approach was to use a combination of other methods pre- sented in this taxonomy along with storing either the search DN or a related URL in the DNS in some way. Using both TXT or NAPTR records in the DNS were considered. This approach requires an administrator to configure the DNS with necessary information. Further, the idea of storing standards based information (either a DN or an URL) in a DNS RR has been an extremely controversial one in the IETF. A.2 DHCP extensions Another proposed method was to use DHCP to deliver information about LDAP server to a DHCP client. This would require that such informa- tion be configured into the DHCP server and that the client use DHCP to load host configuration information. While there has been some nascent interest in this method, there has been no interest in imple- mentation of this approach. Expires 3/31/2001 [Page 5] From list@netscape.com Fri Sep 15 16:03: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 SMTP id QAA24476 for ; Fri, 15 Sep 2000 16:03: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 e8FJteS20375; Fri, 15 Sep 2000 12:55:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FK1sY17256; Fri, 15 Sep 2000 13:01:54 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 13:01:54 -0700 (PDT) Message-Id: <5.0.0.25.0.20000915123423.00a4d360@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 15 Sep 2000 13:01:22 -0700 To: hahnt@us.ibm.com From: "Kurt D. Zeilenga" Subject: Feature discovery (Was: RFC 2596 questions) Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"2lcC.A.WNE.xAow5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com wrote: >Should we investigate some additional rootDSE attribute to indicate the set of attribute descriptions that are supported? Further, when a new attribute description is defined, should we be assigning OIDs and keeping these as an additional part of the subschemasubentry data? I wouldn't mind too much having one attribute type "supportedFeatures" of syntax OID which listed "supported" features. This could include MAYs and SHOULDs from the "core" specification as well as any MAY, SHOULD, MUST of any extension. This would provide a discovery mechanism for any feature you might want to publish support for. However, I wonder the value of providing additional discovery mechanisms when the discovery mechanisms we already provide are rarely used and, in some cases, not needed or inappropriate to use. [Discovery of StartTLS is not needed, discovery of SASL mechanisms is inappropriate without appropriate consideration of security risks]. Kurt From list@netscape.com Fri Sep 15 16:35:13 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 SMTP id QAA24736 for ; Fri, 15 Sep 2000 16:35: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 e8FKRPS26151; Fri, 15 Sep 2000 13:27:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FKXds29609; Fri, 15 Sep 2000 13:33:39 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 13:33:39 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Fri, 15 Sep 2000 14:33:17 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: Feature discovery (Was: RFC 2596 questions) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_94CC6280.75147A0C" Resent-Message-ID: <"OqxSyD.A.XOH.ieow5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_94CC6280.75147A0C Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Whatever the discovery mech is, I'd rather we have it and be rarely used = than not have it at all. Also, some things (like attr type options) need = more than just an OID in a list. We need to specify where they can be used = (which attrs or syntaxes support them). Jim >>> "Kurt D. Zeilenga" 9/15/00 2:01:22 PM >>> At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com wrote: >Should we investigate some additional rootDSE attribute to indicate the = set of attribute descriptions that are supported? Further, when a new = attribute description is defined, should we be assigning OIDs and keeping = these as an additional part of the subschemasubentry data? I wouldn't mind too much having one attribute type "supportedFeatures" of syntax OID which listed "supported" features. This could include MAYs and SHOULDs from the "core" specification as well as any MAY, SHOULD, MUST of any extension. This would provide a discovery mechanism for any feature you might want to publish support for. However, I wonder the value of providing additional discovery mechanisms when the discovery mechanisms we already provide are rarely used and, in some cases, not needed or inappropriate to use. [Discovery of StartTLS is not needed, discovery of SASL mechanisms is inappropriate without appropriate consideration of security risks]. Kurt --=_94CC6280.75147A0C Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Whatever the discovery mech is, I'd rather we have it = and be=20 rarely used than not have it at all. Also, some things (like attr type = options)=20 need more than just an OID in a list. We need to specify where they can be = used=20 (which attrs or syntaxes support them).
 
Jim


>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 9/15/00=20 2:01:22 PM >>>
At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com=20 wrote:
>Should we investigate some additional rootDSE attribute = to=20 indicate the set of attribute descriptions that are supported?  = Further,=20 when a new attribute description is defined, should we be assigning OIDs = and=20 keeping these as an additional part of the subschemasubentry data?

I= =20 wouldn't mind too much having one attribute type "supportedFeatures"=20 of
syntax OID which listed "supported" features.  This could = include=20 MAYs and
SHOULDs from the "core" specification as well as any MAY, = SHOULD,=20 MUST of
any extension.  This would provide a discovery mechanism = for any=20 feature
you might want to publish support for.

However, I wonder = the=20 value of providing additional discovery mechanisms
when the discovery=20= mechanisms we already provide are rarely used and,
in some cases, not = needed=20 or inappropriate to use.  [Discovery of StartTLS
is not needed,=20 discovery of SASL mechanisms is inappropriate without
appropriate=20 consideration of security risks].

Kurt

--=_94CC6280.75147A0C-- From list@netscape.com Fri Sep 15 17:00:13 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 SMTP id RAA24963 for ; Fri, 15 Sep 2000 17:00: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 e8FKqDS01182; Fri, 15 Sep 2000 13:52:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FKwRY10397; Fri, 15 Sep 2000 13:58:27 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 13:58:27 -0700 (PDT) From: kgdaniec@us.ibm.com Importance: Normal Subject: Re: Feature discovery (Was: RFC 2596 questions) To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Fri, 15 Sep 2000 16:58:18 -0400 X-MIMETrack: Serialize by Router on D01MLC83/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 09/15/2000 04:58:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e8FKwPr10362 Resent-Message-ID: <"3IhHzD.A.JiC.y1ow5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e8FKqDS01182 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA24963 Jim wrote: Whatever the discovery mech is, I'd rather we have it and be rarely used than not have it at all. Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them). Doesn't this imply then that support of the attribute tags should be discovered as part of schema discovery? Karen Internet: kgdaniec@us.ibm.com Internal: Karen Gdaniec/Endicott/IBM@IBMUS or IBMUSM10(KGDANIEC) phone: 607.752.1075 tie-line: 8/852-1075 fax: 607.752.3681 ---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on 09/15/2000 04:57 PM --------------------------- "Jim Sermersheim" on 09/15/2000 04:33:17 PM To: , Timothy Hahn/Endicott/IBM@IBMUS cc: Subject: Re: Feature discovery (Was: RFC 2596 questions) Whatever the discovery mech is, I'd rather we have it and be rarely used than not have it at all. Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them). Jim >>> "Kurt D. Zeilenga" 9/15/00 2:01:22 PM >>> At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com wrote: >Should we investigate some additional rootDSE attribute to indicate the set of attribute descriptions that are supported?  Further, when a new attribute description is defined, should we be assigning OIDs and keeping these as an additional part of the subschemasubentry data? I wouldn't mind too much having one attribute type "supportedFeatures" of syntax OID which listed "supported" features.  This could include MAYs and SHOULDs from the "core" specification as well as any MAY, SHOULD, MUST of any extension.  This would provide a discovery mechanism for any feature you might want to publish support for. However, I wonder the value of providing additional discovery mechanisms when the discovery mechanisms we already provide are rarely used and, in some cases, not needed or inappropriate to use.  [Discovery of StartTLS is not needed, discovery of SASL mechanisms is inappropriate without appropriate consideration of security risks]. Kurt From list@netscape.com Fri Sep 15 17: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 SMTP id RAA25175 for ; Fri, 15 Sep 2000 17: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 e8FLJnX12537; Fri, 15 Sep 2000 14:19:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FLUGg25568; Fri, 15 Sep 2000 14:30:16 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 14:30:16 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Fri, 15 Sep 2000 15:28:50 -0600 From: "Jim Sermersheim" To: , Subject: Re: Feature discovery (Was: RFC 2596 questions) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_84DC7283.24452B6B" Resent-Message-ID: <"UwnoPC.A.0OG.lTpw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_84DC7283.24452B6B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable You mean advertised in the schema, right? I would say yes, I think there = should be another schema element called something like attributeTypeOptions= , the syntax would look something like this (ala 2252 nomenclature): AttributeTypeOptionDescription =3D "( numericoid whsp ; Attribute Type Option Identifier [ "NAME" qdescrs ] [ "DESC" qdescrs ] [ "OBSOLETE" whsp ] "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") oids) ; list of = syntaxes or attributes that this ATO applies to. whsp ")" Jim >>> 9/15/00 2:58:18 PM >>> Jim wrote: Whatever the discovery mech is, I'd rather we have it and be rarely used than not have it at all. Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them). Doesn't this imply then that support of the attribute tags should be discovered as part of schema discovery? Karen Internet: kgdaniec@us.ibm.com Internal: Karen Gdaniec/Endicott/IBM@IBMUS or IBMUSM10(KGDANIEC) phone: 607.752.1075 tie-line: 8/852-1075 fax: 607.752.3681 ---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on 09/15/2000 04:57 PM --------------------------- "Jim Sermersheim" on 09/15/2000 04:33:17 PM To: , Timothy Hahn/Endicott/IBM@IBMUS cc: Subject: Re: Feature discovery (Was: RFC 2596 questions) Whatever the discovery mech is, I'd rather we have it and be rarely used than not have it at all. Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them). Jim >>> "Kurt D. Zeilenga" 9/15/00 2:01:22 PM >>> At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com wrote: >Should we investigate some additional rootDSE attribute to indicate the set of attribute descriptions that are supported? Further, when a new attribute description is defined, should we be assigning OIDs and keeping these as an additional part of the subschemasubentry data? I wouldn't mind too much having one attribute type "supportedFeatures" = of syntax OID which listed "supported" features. This could include MAYs = and SHOULDs from the "core" specification as well as any MAY, SHOULD, MUST of any extension. This would provide a discovery mechanism for any feature you might want to publish support for. However, I wonder the value of providing additional discovery mechanisms when the discovery mechanisms we already provide are rarely used and, in some cases, not needed or inappropriate to use. [Discovery of = StartTLS is not needed, discovery of SASL mechanisms is inappropriate without appropriate consideration of security risks]. Kurt --=_84DC7283.24452B6B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You mean advertised in the schema, right? I would say = yes, I=20 think there should be another schema element called something like=20 attributeTypeOptions, the syntax would look something like this (ala = 2252=20 nomenclature):
 
AttributeTypeOptionDescription =3D "(
   = numericoid=20 whsp ; Attribute Type Option Identifier
   [ "NAME" = qdescrs=20 ]
   [ "DESC" qdescrs ]
   [ "OBSOLETE" whsp=20 ]
   "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") = oids) ;=20 list of syntaxes or attributes that this ATO applies to.
   = whsp=20 ")"
 
Jim
 

>>> <kgdaniec@us.ibm.com> = 9/15/00=20 2:58:18 PM >>>
Jim wrote:
Whatever the discovery mech is, = I'd=20 rather we have it and be  rarely used
than not have it at all. = Also,=20 some things (like attr type options)  need
more than just an OID = in a=20 list. We need to specify where they can be used
(which attrs or = syntaxes=20 support them).

Doesn't this imply then that support of the = attribute tags=20 should be
discovered as part of schema=20 discovery?

Karen

Internet: kgdaniec@us.ibm.com
Internal: = Karen=20 Gdaniec/Endicott/IBM@IBMUS=20 or
           &nb= sp;    =20 IBMUSM10(KGDANIEC)
phone: 607.752.1075   tie-line:=20 8/852-1075
fax: 607.752.3681
---------------------- Forwarded by = Karen=20 Gdaniec/Endicott/IBM on
09/15/2000 04:57 PM=20 ---------------------------

"Jim Sermersheim" <JIMSE@novell.com&g= t; on=20 09/15/2000 04:33:17 PM

To:   <Kurt@OpenLDAP.org>, = Timothy=20 Hahn/Endicott/IBM@IBMUS
cc:  =20 <ietf-ldapext@netscape.com>
Subject:  Re: Feature discovery = (Was:=20 RFC 2596 questions)




Whatever the discovery mech is, = I'd=20 rather we have it and be  rarely used
than not have it at all. = Also,=20 some things (like attr type options)  need
more than just an OID = in a=20 list. We need to specify where they can be used
(which attrs or = syntaxes=20 support them).

Jim


>>> "Kurt D. Zeilenga"=20 <Kurt@OpenLDAP.org> 9/15/00  2:01:22 PM >>>
At = 07:18 AM=20 9/15/00 -0400, hahnt@us.ibm.com  wrote:
>Should we investigate = some=20 additional rootDSE attribute to  indicate the
set of attribute=20 descriptions that are supported?  Further,  when a new
attribu= te=20 description is defined, should we be assigning OIDs and  keeping
th= ese=20 as an additional part of the subschemasubentry data?

I  = wouldn't=20 mind too much having one attribute type "supportedFeatures"  = of
syntax=20 OID which listed "supported" features.  This could include  = MAYs=20 and
SHOULDs from the "core" specification as well as any MAY, SHOULD,&nb= sp;=20 MUST of
any extension.  This would provide a discovery mechanism = for=20 any  feature
you might want to publish support for.

However,= I=20 wonder the  value of providing additional discovery mechanisms
when= the=20 discovery  mechanisms we already provide are rarely used and,
in = some=20 cases, not needed  or inappropriate to use.  [Discovery of=20 StartTLS
is not needed,  discovery of SASL mechanisms is inappropri= ate=20 without
appropriate  consideration of security=20 risks].

Kurt



--=_84DC7283.24452B6B-- From list@netscape.com Fri Sep 15 17:39: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 SMTP id RAA25199 for ; Fri, 15 Sep 2000 17:39: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 e8FLVHS10812; Fri, 15 Sep 2000 14:31:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FLbWU29250; Fri, 15 Sep 2000 14:37:32 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 14:37:32 -0700 (PDT) Message-Id: <5.0.0.25.0.20000915143050.00a51dd0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 15 Sep 2000 14:37:00 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Feature discovery (Was: RFC 2596 questions) Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"k22Y4.A.qIH.bapw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them). Likely best to extend the attributeTypes and LDAPsyntaxes to include additional fields... like X-FEATURES ( 1.2.3 $ 2.3.4 ) where 1.2.3 might indicate language tags support and 2.3.4 might indicate binary transfer support. Kurt From list@netscape.com Fri Sep 15 19:35: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 SMTP id TAA26000 for ; Fri, 15 Sep 2000 19:35:18 -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 e8FNRWS01903; Fri, 15 Sep 2000 16:27:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8FNXlk18024; Fri, 15 Sep 2000 16:33:47 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 16:33:47 -0700 (PDT) Message-Id: <200009152333.e8FNXb921064@xwing.netscape.com> From: "Barry regie" Subject: Our List #52E6 To: join29dd@xwing.netscape.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Fri, 15 Sep 2000 18:41:07 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Resent-Message-ID: <"8Byl3D.A.WZE.aHrw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Professional,

You have been selected as a potential candidate for biographical
inclusion in the 2000 - 2001 Edition of the International Executive
Guild Registry=2E

Please accept our congratulations for this coveted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be published in two
different formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
= and professionalism, each candidate is evaluated in keeping with high
= standards of individual achievement=2E In light of this, the Internationa= l
Executive Guild thinks that you may make an interesting biographical
subject=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best wishes for your continued success=2E
International Executive Guild
Listing Dept=2E

P=2ES=2E There is no cost or obligation to be included in the Internation= al
Executive Guild Registry=2E For accuracy and publication purposes, we ask=
you to fill in the brief bit of information in the registration form
below=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From list@netscape.com Fri Sep 15 22:16: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 SMTP id WAA27867 for ; Fri, 15 Sep 2000 22:16: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 e8G28PS20223; Fri, 15 Sep 2000 19:08:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8G2Eeg09694; Fri, 15 Sep 2000 19:14:40 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 19:14:40 -0700 (PDT) Date: Fri, 15 Sep 2000 19:14:07 -0700 (PDT) Message-Id: <200009160214.e8G2E7905264@xwing.netscape.com> From: capnet12cn@TQYW.netscape.net To: ietf-ldapext@MQSP.netscape.com Subject: How To Pay Off Loans Faster! -IQTD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"bjx_BC.A.MXC.Petw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Friends, If you have received this message in error, please excuse the intrusion and reply remove. How To Pay Off Loans Faster, While Saving Thousands In Interest! * Mortgages * Equity Loans * Boat Loans * RV Loans * Student Loans ANY LOAN! http://www.anyloan.bigstep.com *************************************************************************************** Join Affiliate Programs and Earn Cash - Its's Easy! CompuBank.com Garden.com AOL.com Mercata.com IBM.com Amazon.com PriceLine.com Ebay.com Drugstore.com FreeShop.com Pets.com Motorola.com E-Stamps.com Staples.com Compaq.com PayPal.com TigerDirect.com MapQuest.com Search our directory to shop or locate the right programs for you and start earning money from your website today! It's easy as: 1) Search for the right programs, 2) Select the ones you want to join, and 3) Use our Banners to apply with one click! http://www.anyloan.bigstep.com ANY LOAN! From list@netscape.com Sat Sep 16 00:51: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 SMTP id AAA00128 for ; Sat, 16 Sep 2000 00:51: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 e8G4dhX28743; Fri, 15 Sep 2000 21:39:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8G4o9A18572; Fri, 15 Sep 2000 21:50:09 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 21:50:09 -0700 (PDT) Date: Fri, 15 Sep 2000 21:50:02 -0700 (PDT) Message-Id: <200009160450.e8G4np328814@ywing.netscape.com> From: Unlimited DVD Rental! To: @netscape.com Subject: * * * FREE Unlimited DVD Rentals! * * * X-Reply-To: the_info@mailcity.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kRsWwC.A.4hE.Awvw5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit If you love movies this offer is for YOU! The largest and most popular rental site in the world gives you: * Unlimited monthly DVD Rentals! * NO Due Dates or Late Fees! * Over 8500 Titles to Choose From! * All DVD's delivered right to your door! * Postage paid return envelopes! * Try your first month FREE! Send a blank email here for more details: mailto:usefulfreebies@myworldmail.com?subject=DVD_Rentals From list@netscape.com Sat Sep 16 01:21: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 SMTP id BAA02455 for ; Sat, 16 Sep 2000 01:21: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 e8G5DrS02157; Fri, 15 Sep 2000 22:13:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8G5K8g24547; Fri, 15 Sep 2000 22:20:08 -0700 (PDT) Resent-Date: Fri, 15 Sep 2000 22:20:08 -0700 (PDT) Date: Fri, 15 Sep 2000 22:19:55 -0700 (PDT) Message-Id: <200009160519.e8G5Jt304238@ywing.netscape.com> From: Free Ad Submitter To: @netscape.com Subject: * ** * FREE AD SUBMITTER * * * X-Reply-To: the_info@mailcity.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"oQNcm.A.N_F.HMww5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit FREE Full Featured Classified Ad Submitter! Subscribe to one of our FREE minimags and it's yours....click this link and we'll send you the details: mailto:usefulfreebies@myworldmail.com?subject=AD_Submitter From list@netscape.com Sat Sep 16 07:02: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 SMTP id HAA14034 for ; Sat, 16 Sep 2000 07:02: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 e8GAsHS16859; Sat, 16 Sep 2000 03:54:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8GB0VA21144; Sat, 16 Sep 2000 04:00:31 -0700 (PDT) Resent-Date: Sat, 16 Sep 2000 04:00:31 -0700 (PDT) From: hahnt@us.ibm.com Importance: Normal To: Subject: Re: Feature discovery (Was: RFC 2596 questions) X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Endicott/IBM(Release 5.0.3 (Intl)|21 March 2000) at 09/16/2000 06:21:29 AM, Serialize by Notes Client on Timothy Hahn/Endicott/IBM(Release 5.0.3 (Intl)|21 March 2000) at 09/16/2000 06:21:29 AM, Serialize complete at 09/16/2000 06:21:29 AM, S/MIME Sign failed at 09/16/2000 06:21:30 AM: The cryptographic key was not found, Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 09/16/2000 07:00:21 AM, Serialize complete at 09/16/2000 07:00:21 AM Message-ID: Date: Sat, 16 Sep 2000 06:59:16 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0038E5E08525695C_=" Resent-Message-ID: <"V8S_AD.A.EKF.OL1w5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multipart message in MIME format. --=_alternative 0038E5E08525695C_= Content-Type: text/plain; charset="us-ascii" Hi all, I like the idea of extending the schema information with the set of attribute descriptions that are known to the server. Both approaches described so far: 1) extend the attributeTypes value to allow for additional fields to be specified within each value, add a new value that defines the OIDs used in the field 2) add a new attribute to the subschemasubentry and contain all the information here are in the right direction. Approach 1) has the benefit that just by looking at the attributeType value, you can get an indication if any attribute descriptions might have been used in creating/modifying entries that contain this attribute. However, there would be the issue of whether or not the server supported the additional data in the attributeTypes value. Approach 2) doesn't change the attributeType value definition (nice for upward compatibility). On the downside, though, in order to see what attribute description a given attribute type can have attached to it, a not-so-easy-search of the new schema attribute would have to be performed. After writing up this short discussion of the approaches, I think I prefer Approach 1) where the "DESCRIPTORS ( "$" ... )" clause of the attributeTypes value is an optional piece in the format of the value. Is there agreement here? 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 To: "Jim Sermersheim" cc: Timothy Hahn/Endicott/IBM@IBMUS, Subject: Re: Feature discovery (Was: RFC 2596 questions) >Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them). Likely best to extend the attributeTypes and LDAPsyntaxes to include additional fields... like X-FEATURES ( 1.2.3 $ 2.3.4 ) where 1.2.3 might indicate language tags support and 2.3.4 might indicate binary transfer support. Kurt --=_alternative 0038E5E08525695C_= Content-Type: text/html; charset="us-ascii"
Hi all,

I like the idea of extending the schema information with the set of attribute descriptions that are known to the server.

Both approaches described so far:

1) extend the attributeTypes value to allow for additional fields to be specified within each value, add a new value that defines the OIDs used in the field
2) add a new attribute to the subschemasubentry and contain all the information here

are in the right direction.

Approach 1) has the benefit that just by looking at the attributeType value, you can get an indication if any attribute descriptions might have been used in creating/modifying entries that contain this attribute.  However, there would be the issue of whether or not the server supported the additional data in the attributeTypes value.

Approach 2) doesn't change the attributeType value definition (nice for upward compatibility).  On the downside, though, in order to see what attribute description a given attribute type can have attached to it, a not-so-easy-search of the new schema attribute would have to be performed.

After writing up this short discussion of the approaches, I think I prefer Approach 1) where the "DESCRIPTORS ( <OID> "$" ... )" clause of the attributeTypes value is an optional piece in the format of the value.

Is there agreement here?
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

To:        "Jim Sermersheim" <JIMSE@novell.com>
cc:        Timothy Hahn/Endicott/IBM@IBMUS, <ietf-ldapext@netscape.com>
Subject:        Re: Feature discovery (Was: RFC 2596 questions)




>Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them).
Likely best to extend the attributeTypes and LDAPsyntaxes to include
additional fields... like X-FEATURES ( 1.2.3 $ 2.3.4 )  where 1.2.3
might indicate language tags support and 2.3.4 might indicate binary
transfer support.
Kurt


--=_alternative 0038E5E08525695C_=-- From list@netscape.com Sat Sep 16 07:30: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 SMTP id HAA14176 for ; Sat, 16 Sep 2000 07:30: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 e8GBIsX16509; Sat, 16 Sep 2000 04:18:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8GBTMQ25828; Sat, 16 Sep 2000 04:29:22 -0700 (PDT) Resent-Date: Sat, 16 Sep 2000 04:29:22 -0700 (PDT) Message-Id: <200009161104.HAA27818@LE0-1.webtst1.sprint.ca> X-Sender: theworldisyouroyster@hotmail.com From: Scott To: "Another tired Employee?" Date: Sat, 16 Sep 2000 05:06:19 -0700 Subject: $2,000, $4,000 WEEKLY INCOME Reply-To: theworldisyouroyster@hotmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"R0QBm.A.ETG.Rm1w5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit My name is Scott Klarenbach and I'm responding to your recent request for a business opportunity that you can grow from home. How would you like to market a $15,000 Vacation package that includes 6 FREE Cruises, 23 vacations worldwide, and over $4,000 in FREE airfare for the unbelievable price of only $1,295? - OF WHICH YOU WILL EARN $1,000 COMMISSION PER SALE! The companies in this vacation package are 15 Year Old Companies, members of the Better Business Bureau, and some of the most respected, LARGEST Multi-Billion Dollar Companies in the travel industry. All of the selling is done for you. We have weekly national conference calls, and a great website that you can use to sell the package. If you didn't make $3,000 last week, and you haven't been on at least 2 Cruises so far this year, then you have to call right now! This is the most AMAZING package you will ever see, and it literally sells itself. We have directors that are earning over $8,000 per week. If this sounds interesting, call my toll free number for some recorded information. The number is 1-800-701-7654. If you don't do something about your financial situation now, when will you? 1-800-701-7654 Your own FREE ISP is waiting for you at netzero. Just visit www.netzero.net From list@netscape.com Sat Sep 16 10:37: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 SMTP id KAA15194 for ; Sat, 16 Sep 2000 10:37: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 e8GETRS25972; Sat, 16 Sep 2000 07:29:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8GEZfg25581; Sat, 16 Sep 2000 07:35:41 -0700 (PDT) Resent-Date: Sat, 16 Sep 2000 07:35:41 -0700 (PDT) Message-Id: <200009161428.WAA25548@smtp13.singnet.com.sg> X-Sender: skip2k@themail.com From: Webmaster To: "webi8b" Date: Sat, 16 Sep 2000 22:34:34 +0800 Subject: Just Launched - Free To Join! MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"L-HAhC.A.TPG.7U4w5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi, Just Launched - FREE Downline Club With First Entry Rights into the New 1.5 million dollar program. Secure your spot NOW!! You HAVE TO SEE This to believe it!! Request for info, mailto:koolid@bigfoot.com?subject=FDinfo! We are # 9 in the list - Great Position! ................................................................... To be removed from this mailing list please send reply to this with remove in the subject box. Sorry for any Inconvience. From list@netscape.com Sat Sep 16 20:55: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 SMTP id UAA18279 for ; Sat, 16 Sep 2000 20:55: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 e8H0lpS24927; Sat, 16 Sep 2000 17:47:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8H0s7g00940; Sat, 16 Sep 2000 17:54:07 -0700 (PDT) Resent-Date: Sat, 16 Sep 2000 17:54:07 -0700 (PDT) Message-Id: <200009170054.e8H0rx919054@xwing.netscape.com> From: " Subject: This is THE BIG ONE! Date: Sun, 17 Sep 2000 01:58:06 Resent-Message-ID: <"FvjyjD.A.EO.uYBx5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com A BOMB has dropped on MLM! 68,000 joined in 4 WEEKS! This is THE BIG ONE! IT HAS NOW BEATEN EVERY PROGRAM LAUNCH ON THE INTERNET!!! Yes, an amazing 68,000 members ENROLLED in just 4 WEEKS! This is proof that people see the GREAT POTENTIAL of this SENSATIONAL OPPORTUNITY! Everybody will benefit tremendously from this UNIQUE PAYMENT CONCEPT! IT HAS DROPPED A BOMB ON MLM! Have you ever heard about a system that pays your first check after you've enrolled just TWO people? WELL, THIS COMPANY DOES!!!! And after that you receive commissions on ALL SALES the company makes! Not only on YOUR sales, but ALL SALES! This company is rapidly becoming bigger than Skybiz and you can join at the top! YOU WILL BE BLOWN AWAY when you hear about the AWSOME PRODUCTS and COMPENSATION PLAN! No stock - no meetings - no borders......GLOBAL! You can make $10,000 per week in 30 - 45 days from now with very little effort! OUTSTANDING company backup and promotion. They have a server 100 times stronger than Ebay! BUT LET'S FORGET ABOUT THE HYPE FOR A MOMENT..........and be realistic... Would an extra $200 per week pay some bills? An extra $500 per week could pay the mortgage! And would an extra $1,000 per week change your lifestyle? It is all possible. If you introduce only 2 members, (your sister and your brother in law perhaps? ;o)) you will then qualify already for your first paycheck! Get back to me QUICKLY for further information Click on the link below mailto:prosperity4allnow@lakmail.com?Subject=THE_BIG_ONE_Please Or send a blank e-mail to prosperity4allnow@lakmail.com with "THE BIG ONE Please" in the subject box. Please DO put "THE BIG ONE Please" in the subject box or I may not see your e-mail straight off. Please DON'T just hit reply! Have a GREAT day, Barb PS If you don't take a look you'll NEVER know what you are missing out on. Sending this email will take you 10 seconds. It will be your best 10 seconds spent on the internet YOU CAN FINALLY BE INVOLVED IN SOMETHING THAT WORKS! GET READY TO BE EXCITED!!!!! YOU WILL BE AT THE TOP!!! ********************************************************************** Please Note: You're receiving this email because you answered an advert I ran, you sent an ad about your program to one of my e-mail addresses, or you posted a link at my FFA links site. If at anytime you would like to be Removed from my address book, simply click on the link below mailto:nomail@alloymail.com?Subject=REMOVE or reply to this e-mail with "REMOVE " in the subject line and you'll be removed immediately. Thank you. From list@netscape.com Sun Sep 17 05:00:50 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 SMTP id FAA07115 for ; Sun, 17 Sep 2000 05:00: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 e8H8moX16821; Sun, 17 Sep 2000 01:48:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8H8xLk18826; Sun, 17 Sep 2000 01:59:21 -0700 (PDT) Resent-Date: Sun, 17 Sep 2000 01:59:21 -0700 (PDT) From: jojimmy@themail.com Subject: Make money with the BANK'S money Reply-To: jojimmy@themail.com Date: 17 Sep 2000 05:04:29 -0400 Mime-Version: 1.0 Content-Type: text/html Message-Id: <20000917084617.IKR4427@mailhost.attcanada.net> Resent-Message-ID: <"BrZSVD.A.wlE.nfIx5"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e8H8moX16821 Content-Transfer-Encoding: quoted-printable

Remove ins= truction at the bottom

QUICK CASH SECRET BA= NKING SYSTEM, THE SECRETS OF THE RICH & FAMOUS REVEALED AT LAST!!! Make money with the abundance of the bank=92s money=A0

=A0 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$= $$

LUCKY YOU= ! GET FREE "$1,500/WEEK CASH" INFORMATION NOW !!!

$$$$$$$$$= $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$=

"Quick Cash Secret Banking System", is now = being released to the general public again, to benefit anyone who is interested= in generating a guaranteed $1,500+/week cash, without any HARD work or large investment!

Quick Cash Secret Banking System is the = fastest and the easiest money making system today in the world, used by all multi-millionaires to pile up cash, without any huffing and puffing! =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

It is 100% legal, easy,= fast and fun! There is no scam or shady transaction= ! Approved by all government agencies, including the US Treasury Dept., Ame= rican and International Banking Associations, The Fed, and US Post Office! It WORKS in any country in the world that has bank(s) and provides the facil= ity to open checking account(s).

<<><><><><>= ;<><><><><><<><><><= ><>

I guarantee that from this moment on your life will never be the same = again. You will be amazed at how much money you will be capable of having in jus= t a few days, right from your Federal Reserve Board.

Please, leave the skepticism in the past. If you are skeptical, this w= ill not work or anything else in life for that matter, because you will not believe.=A0=A0 If you were promi= sed $5,000,000 to jump out of an airplane without a parachute, would you do i= t? If you answered "No" you answered Wrong! Like the ma= jority of the people, you made a decision before you had all the facts. Had you investigated further, you would have found out that the plane was on the ground. Do not let the greatest opportunity of your life pass you by beca= use you were so eager to jump into conclusions that you did not get all the f= acts. Please, read on and try to get the concept of what I can give you here an= d now, before you form any opinions.

Ok, I think that you are ready to begin now.=A0 I want you to follow exactly the instructions that you ar= e about to read. Let me be your guide throughout the entire booklet.=A0 It is financial health you are loo= king for and I sure know how you can get it. So, follow my instructions.=A0

MAKE MONEY WITH T= HE BANK=92S MONEY

During a 6-month period you will be able to deposit 50,000 dollars in = your personal bank accounts, without doing anything at all!=A0 Let me elaborate just a little.=A0 =93You do not do anything physi= cal to bring in this kind of money!=94=A0 The bank does all the work for you at your convenience, and as long as you keep yo= ur account =93open=94 they almost have no choice!=A0 I will show you how to make a minimum of $5,000 a mont= h by just opening a bank account. =A0But that is just the tip of the iceberg!=A0= By opening a bank account, I will teach you how to have that kind of money deposited into your bank account Automatically, though a built-in automatic process that I will personally show you.=A0 That is the beauty of the $ecret Banking $ystem!=A0 Imagine making $5,000 a month for = each bank account you =93open=94.=A0 And a= side from opening the account, it does not cost you anything!=A0 Just one bank account can make you financially independen= t for life!

Now Think Big.=A0 Think of th= e same idea on a slight larger scale, like two or three bank accounts working at the = same time each producing a guaranteed monthly income of $5,000 each.=A0 As of today, I have 13 active acco= unt @$5,000 =3D $65,000 per month, every month, 12 months a year.=A0 I assure you, there is no print er= ror.=A0 I said 65 thousand dollars per mon= th!

In summary this is how the formula works:=A0 YOU walk into a bank, open a bank account, follow the instructions= like a recipe in a cookbook, and 30 days later you will make $5,000. =A0And one of the most amazing realiti= es of the $ecret Banking $ystem is that you can begin with literally $0, zero money= .=A0 In the $ecret Banking $ystem manua= l, in an easy to duplicate as a set of =93blueprints=94, you will find out for you= rself where all the money comes from and how it is added up for you.=

I realize what I am originating to you may sound impossible, but I promise you, it = is possible, doable and simple.=A0 = There is not shortage of money, the Federal Reserve Board creates money daily but = most of it must pass through and circulate in the banks over and over again. <= span style=3D"mso-spacerun: yes">=A0That is how banks run.=A0 That is where this Ingenious $ecre= t Banking $ystem comes in.=A0 All you need= is the $ecret Banking $ystem manual to start making big money.=A0 IF YOU ORDER TODAY WE SHALL ADD AT NOT EXTRA COST TO Y= OU, THE FAMOUS= "101 High Profit Businesses You Can Start Online For Litt= le Or No Money", PLUS 1,000,000 ONE MILLION OPT-IN ADDRESSES- FREE!!

That you obtain your very own copy of the $ecret Banking $ystem and th= e above mentioned, take the first step and invest only $49US for something = that is worth its weight in gold.=A0 = Copy and mail-send a cheque, (we accept cash) or money order to:

All Moreir .=

15 Pape Avenue Suite 409

To= ronto, Ontario, Canada

M4M 2V5

___________<= /span>

ORDER FORM

 

Name=A0=A0=A0=A0=A0=A0=A0=A0=A0 ___________________________________= _____________

Address=A0=A0=A0=A0=A0=A0 _____________________= _________________________

City=A0=A0 _____________________=A0= =A0=A0=A0=A0=A0=A0 State_________=A0=A0 Zip_____-________

Fax=A0=A0=A0 (_____) _____-______

E-mail address=A0=A0=A0=A0=A0 ________________________= _________________

Send me the $ecret Banking $yst= em right now, please.=A0 Here is the $49U= S.

Write legible please=

________and check here = for fastest service if you would like to receive this information by e-mail a= s an attachment and save the $5.00 shipping and handling fee.=

IF YOU ORDER TODAY

WE SHALL ADD AT NOT = EXTRA COST TO YOU, THE FAMOUS "101 H= igh Profit Businesses You Can Start Online For Little Or No Money", PLUS= ONE MILLION OPT-IN ADDRESSES- FREE!!

If you realize that you are on= this list in error or have changed your mind or if you do not want this type of information, please reply to this e-mail with "REMOVE" in the s= ubject field and you will be removed immediately! I apologize for any mistake, intrusion or inconvenience, if any.=A0 Under Bill 1618 Title 111 passed by the 105th U.S. Congress, this message can not be considered SPAM as long as we include a way for it to = be removed from future mailings

 <= span style=3D'color:green;background:white'>Foundations of Wealth

If you wish to learn more=85=85please read on

A few years ago I believed that I really had to work hard to make mone= y. I thought that the more I worked, the more money I was going to make. But a= fter a while I realized that I was not getting anywhere. I was working like a sl= ave and I was not seeing any satisfactory results. I wondered why I wasn't be= cause I sure was applying the time and the effort.

I realized that I needed to make a change. For months I tried to find = that special answer that I needed. I tried different things, but none of them worked. I was lost. Finally, I was ready to give up my dreams and continu= e living that ordinary life that I was used to living. You know, that wake = up, go to work, come home, have dinner, and go to bed sort of life. That kind of= life that I am very sure you are used to living. But no! I had to give it one = more chance. I could not quit that easily. So, an idea came to my mind and I d= ecided: "If I want to be become extremely wealthy, why don't I study people = who already are extremely wealthy and interpret what they are doing?" So= that is what I did. After a few months, I realized that the majority of the extremely wealthy people did not work that hard. Also, the majority of th= em not only had enough money to buy another planet, but they also had the time a= nd the freedom to enjoy it. That is what I consider true wealth, and that is exa= ctly what $ecret Banking $ystem is all about. The ability to have free time an= d be able to do what you choose, when you choose it. I think that is where the majority of the people get confused on the definition of wealth. Wealth i= s not just money. Wealth is also the ability to spend it the way you choose to = do, when you want to do so.

Having accomplished my goals, my purpose now is to help those that are= in the situation I was in; my purpose is to turn you into a "true" wealthy person; I want you to have great amounts of money, and great amou= nts of free time to enjoy it. Now, the first step to accomplish this is the one = that a lot of people do not pay that much attention to, yet it is one of the mos= t important aspects of true wealth. I am talking about the mental aspect of= true wealth. Hang on! =A0I know you a= re tired of listening the same psychology song over and over. Do not worry! =A0The mental aspect of true wealth is= actually very simple and easy to apply. It is actually like a list of steps that y= ou have to "get into your mind" before we really get into the "secrets" of making money with the bank=92s money that I have b= een talking about so much. Once you know all these steps and are ready to app= ly them, then you will really be ready to start the journey.

Please! Do not jump this section thinking that you do not need any men= tal preparation. It is very important! Remember, follow my instructions and y= ou could be sitting on gold in just days.

Do you remember the three "keys" to success that I explained= on the web site? If you forgot, the three "keys" to success are:

  1. Timing: Being at the right p= lace at the right time.
  2. Having Vision: Seeing potent= ial in what is being presented. Having the ability to see success.
  3. Taking Action: Going one ste= p further than the rest. Doing instead of saying.

These three "keys" are essential to recognize success, and to make it= a part of your life. Now, once you have made the decision to "Take Action," your next task is to follow what I call "The Ten Steps= To Success." As I said before, they are very simple, but extremely impo= rtant if your purpose is to achieve true wealth. I would happily give them to y= ou as part of the Training I provide when you obtain the $ecret Banking $ystem.= =A0 Get your copy today!

---- From list@netscape.com Sun Sep 17 06:32:05 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 SMTP id GAA07481 for ; Sun, 17 Sep 2000 06:32: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 e8HAOLS00076; Sun, 17 Sep 2000 03:24:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8HAUaI04909; Sun, 17 Sep 2000 03:30:36 -0700 (PDT) Resent-Date: Sun, 17 Sep 2000 03:30:36 -0700 (PDT) Message-Id: <200009171030.GAA06997@ns1.nt.net> X-Sender: elliemay22@cheerful.com From: "elliemay22@cheerful.com" To: ietf-ldapext@netscape.com Date: Sun, 17 Sep 2000 06:29:19 -0500 Subject: Need A QUICK $100? MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Pi9K.A.bMB.L1Jx5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit We were informed that you were possibly interested in learning more about internet work at home opportunities. If this email has reached you in error I apologize. Removal instructions are at the end of this email ------------------------------------------------ Forget all the chain letters, matrixes, MLM's and other mathematically impossible stuff! Find out how NORMAL people make $5,000 a month or MORE from their home computers with NO COMPANY in between! Make $100 TODAY! See the PROOF that it WORKS! Send a blank email to moreinfopleese@getresponse.com -------------------------------------------------- To be removed send an email to rem_nowca@yahoo.com with REMOVE in the subject line. From list@netscape.com Sun Sep 17 10:10: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 SMTP id KAA09143 for ; Sun, 17 Sep 2000 10:10: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 e8HE2wS25675; Sun, 17 Sep 2000 07:02:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e8HE9EM07484; Sun, 17 Sep 2000 07:09:14 -0700 (PDT) Resent-Date: Sun, 17 Sep 2000 07:09:14 -0700 (PDT) From: 59165429@08606.com Date: Sun, 17 Sep 00 21:30:43 EST To: mambership@consultant.com Subject: Hello (SMT 10-75) Message-ID: <199702170025.GAA08056@mambership@consultant.com> Reply-To: mambership@consultant.com X-PMFLAGS: 34078848 0 X-UIDL: 2610431020a78aeb1b128fda426c9a5e Comments: Authenticated sender is Resent-Message-ID: <"4h9C3C.A.q0B.JCNx5"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com 

Hello,

I would like to share with you a FREE, Genuine, NO RISK Opportunity Exploding 
on the Internet

> FREE MEMBERSHIP!
> Incredible MINIMUM COMMISSION GUARANTEE!
> Create a LARGE Growing MONTHLY INCOME for the REST OF YOUR LIFE!
> Fantastic DISOUNTS and REBATES!
> HUGE Shopping Mall with Popular NATIONAL NAME STORES!
> FREE Membership Position with a GUARANTEED WORLDWIDE DOWNLINE!
> FREE Entry in our $100 monthly PRIZE DRAWING!

Join the ULTIMATE Shopping Club now for FREE, with No Risk or Obligation.   
This is the First and Foremost FREE Consumer Opportunity Exploding on the 
Internet!!

The Sooner you sign up as a Free Member, the higher your position!   The 
Thousands of new members joining monthly will all be in Your Downline!  You 
will be able to view your position and watch your Downline Grow after you 
have joined as a FREE Member.....No Obligation!! 

Email us and Lock-In your FREE Membership Position.  Your FREE Membership Is 
Ready and Waiting!  JOIN TODAY!!!

Send email to: membership@singapore.com
Write in Subject Line:  'Sign Me Up'
Write in Message Body: 'Your First and Last Name and email address'

You will receive your FREE Membership and Position Confirmation shortly, 
Congratulations!


This message is sent in compliance of the new email bill section 301. Under 
Bill S.1618 TITLE III passed
by the 105th U.S. Congress, paragraph (a)(c) of S.1618, further transmissions 
to you by the sender of this email may be stopped by sending a request to be 
removed.  Please type "Remove" in the subject line click on 'Send'.  We honor 
all remove requests.






From list@netscape.com  Sun Sep 17 17:34: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 SMTP id RAA11802
	for ; Sun, 17 Sep 2000 17:34: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 e8HLR2S09211;
	Sun, 17 Sep 2000 14:27:02 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8HLXIo03062;
	Sun, 17 Sep 2000 14:33:18 -0700 (PDT)
Resent-Date: Sun, 17 Sep 2000 14:33:18 -0700 (PDT)
Message-Id: <200009172133.e8HLWs316465@ywing.netscape.com>
From: "Darren Harris" 
Subject: Easy Start #6B96
To: join39w@ywing.netscape.com
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Sun, 17 Sep 2000 16:12:08 -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 e8HLXHr03038
Resent-Message-ID: <"QXaXjC.A.kv.diTx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

              
Accepting credit cards for your business 

has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!

NO PROGRAMMING FEE!

$9.95 PROCESSING FEE

Call today and apply:

(888) 264-9272

Now you can design your web site with our

complete software package, which includes:

     Domain Registration 
     Web Hosting 
     Web Design Tools 
     Shopping Cart 
     Credit Card Processing Integration

Quick, Easy and Affordable at just $99.00!

Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:ylkp2@netscape.net?subject=remove
************************************************************





From list@netscape.com  Sun Sep 17 23:25: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 SMTP id XAA15553
	for ; Sun, 17 Sep 2000 23:25: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 e8I3HcS28353;
	Sun, 17 Sep 2000 20:17:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8I3Nu609201;
	Sun, 17 Sep 2000 20:23:56 -0700 (PDT)
Resent-Date: Sun, 17 Sep 2000 20:23:56 -0700 (PDT)
Message-Id: <200009180323.e8I3Nr904164@xwing.netscape.com>
From: "Steve Klein" 
Date: Sun, 17 Sep 2000 23:29:28
Subject: Virus Spreading Across the Internet!  Please read
Resent-Message-ID: <"h7CFPD.A.fPC.LrYx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

 . . the virus is wealth!  Have you caught it yet?  If not, YOU can be 
a part of it.  Don't believe me?  Okay.  Keep your eyes closed and keep 
making your employer rich!  You do enjoy the commute, long hours, and paycheck 
which is just enough to get by, right?  Look, I know you are interested 
in making extra money – that's why you are receiving this email.  I also 
know that this is not the first (or last) money making email you have received.

So why is my offer different?  I am an associate of a company which has 
been in business for 28 years.  It is on the New York Stock Exchange and 
is a top portfolio pick.  The funny part is you probably haven't heard 
of it yet.  To be frank, its service is sweeping North America.  The best 
part is while the service they provide is low cost, the commissions I receive 
(and you will receive) are very high!

I can hear you saying, right . . . Sure . . . Whatever!  How much can you 
really make, Steve?  Well, the friend who recruited me made over $100,000 
her 2nd year.  I haven't done that well yet, but I have been working 65+ 
hours in a 2nd shift position.  That said, I WILL be quitting shortly and 
working this business FULL TIME.  Yes, there is that much money to be made 
in this business!  If you don't believe me, my feelings aren't hurt.  I'm 
going to be making money.  Personally, I think it is incredible that we 
receive such high commissions on such a low cost service that so many people 
need.

So what will you be doing?  Working hard for someone else and just getting 
by?  I WILL help you.  I will give you online training, talk to you on 
the phone, even help you make sales.  Find out more by visiting http://www.explodingopportunity.cc 
if you are serious, and want to find out more about this AMAZING service. 
 Or just email me back at thekleins@core.com with TELL ME MORE as the subject. 
 If you are curious about whether a home business is right for you, check 
out http://www.homebusiness.to/thekleins 

You can even Will this business to other members of your family, like your 
children.  Will future generations  be better by your efforts today? 

Its all FREE, what are you afraid of – SUCCE$$?

Sincerely

Steve Klein

P.S.  If you would be interested a FREE Satellite TV System, let me know. 
 No hitches, no catches . . . a FREE Satellite TV System.  Just put FREE 
SATELLITE in the subject line and include your name and mailing address. 
 Your address WILL NOT BE SOLD OR RENTED to anyone and you will never be 
mailed anything else by me.



***THIS IS A ONE TIME MAILING - YOU ARE NOT ON ANY LIST, THERE IS NO NEED 
TO ASK TO BE REMOVED FROM ANY LIST**





From list@netscape.com  Sun Sep 17 23:44: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 SMTP id XAA16006
	for ; Sun, 17 Sep 2000 23:44: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 e8I3ViX28198;
	Sun, 17 Sep 2000 20:31:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8I3gGo12993;
	Sun, 17 Sep 2000 20:42:16 -0700 (PDT)
Resent-Date: Sun, 17 Sep 2000 20:42:16 -0700 (PDT)
Date: Sun, 17 Sep 2000 20:42:13 -0700 (PDT)
Message-ID: 
To: database@ausi.com
From: 
Subject: If you're interested in earning $100 - $1,500 per hour or two          .
Resent-Message-ID: <"1C-a0D.A.vKD.X8Yx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



 From: Michelle Smith - publisher of the "Work From Home Opportunities" Newsletter
 Friday, 3 p.m.

 Hello,

  	If you're interested in earning $100 - $1,500 per hour or two
 	Then I want to share something with you...

 Now you can make $100 - $1,500 per hour or two!

 Imagine you come home from a hard day's work (exhausted..)

 You immediately go straight to bed.  You get undressed,
 lay down, turn off the lights, and snuggle up face-down on
 the pillow.  A few moments later, you feel uncomfortable and
 stressed out so you lie on your back.

 When you look up at the ceiling, it's as if the ceiling has been removed!

 You see exactly what you would see if outside stargazing!
 A stunning, accurate 3-dimensional re-creation of the starry 
 night sky, including constellations such as the Big Dipper, 
 Pegasus and the Milky Way galaxy,

         ...and even shooting stars!

 You can't see it during the day.  The ceiling looks normal.
 But at night, when the lights are off, you see what looks
 like the sky outside!

 It's so relaxing and romantic.  And educational!

 And talk about stress-relief!  The moment you look at it,
 it'll melt your tension away faster than a great massage!

 Now how many people do you think would LOVE seeing this when
 they look up in their beds at night?

 "It's like you're sleeping under the stars!"

 Ok, I know you want to know How You Make Money.

 Here's how.

 You can put that awesome "convertible ceiling" in ANYONE'S 
 bedroom with a product cost to you of..

 Guess how much..

 Only ONE to TWO Dollars!  

 You offer this masterpiece for $100 - $1,500!
 Talk about *nice* profits!
 And it only takes you an hour or two!

 Here's an important point:

 These profits are similar to the profits of selling Information:
 the material costs next to nothing, but the customer really VALUES
 the END RESULT.  So the market value is more (a LOT more).

 "Who'd want this?"

 Anyone with a bedroom ceiling (or any ceiling),
 as well as homes, hotels, etc.

 Who do you know that has a bedroom ceiling?

 Whew!  The official money-making opportunity of the Millenium!
 (Well... we think it should be!)  |;-)

 Anyway, I know you want more information to make a decision, so ...

 To receive more FREE information on How To Make $100 - $1,500 per hour or two,
 Simply Click On The Email Link Below and Send Back The Following:

 Mailto:stargazing26@newmail.net

 Name:
 E-Mail:
 Phone:
 Street:
 City:
 State:
 ZIP or Postal Code:
 Country (available INTERNATIONALLY):

 Mailto:stargazing26@newmail.net


 And you'll be sent the full details on how to 
 make $100 - $1,500 per hour or two, as well 
 as pictures of these murals so you can see 
 for yourself how breathtaking they are!

 Best regards,

 Michelle Smith

 P.S. We'll also send you a free Opportunity E-zine with 
 more interesting Money-Making Opportunities like this one, 
 and important info. for the home-based entrepreneur!

 P.P.S. Also, even though 99% of people don't know about this 
 opportunity, that won't be the case forever, so hurry up and 
 reply to make sure you get to lock down YOUR city!


 To unsubscribe mailto:optout916@newmail.net














From list@netscape.com  Mon Sep 18 04:16: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 SMTP id EAA29698
	for ; Mon, 18 Sep 2000 04: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 e8I88jS17539;
	Mon, 18 Sep 2000 01:08:45 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8I8F3E12833;
	Mon, 18 Sep 2000 01:15:03 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 01:15:03 -0700 (PDT)
Date: Mon, 18 Sep 2000 01:14:30 -0700 (PDT)
Message-Id: <200009180814.e8I8EJ323058@ywing.netscape.com>
From: joshua.sharp@angelfire.com
To: @netscape.com
Subject:  A New Direction.
X-Reply-To:  joshua.sharp@angelfire.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"3JFdl.A.NID.G8cx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


 

_______________________________________________ 
Subject: Fw: MUST READ ! ! ! ... TV Advertized ! ! ! ... Fun-Lucrative
 
 Fellow Entrepreneur,
 If you wish to learn about an exceptional
 opportunity in the Home Business arena...Read On. 
 
 "Your living is determined not so much by what life brings to
 you as by the attitude you bring to life; not so much by what
 happens to you as by the way your mind looks at what happens."
 
 This is going to be a great new Year for you!
 
 Please read all of this!
 
 EARN $100,000 PER YEAR SENDING E-MAIL!!!
 
 ****************************************************************
 
 You can earn $50,000 or more in the next 90 days sending e-mail,
 seem impossible? Read on for details (no, there is no
 'catch')...
 
 ----------------------------------------------------------------
 
 "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 (£5) 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(£5) 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(£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 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES"
  
 ORDER REPORT #1 FROM:
 
 R.Carpenter(will accept all currency's)
 PO Box 491
 LittleHampton
 SA
 Australia 5250   

 _______________________________________________________
 REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES"
 ORDER REPORT #2 FROM:
 
 E.Mills (will accept your currency)
 PO Box 2
 Mowbray Heights
 Launceston,Tasmania
 Australia 7248

 ________________________________________________
REPORT #3 "SOURCES FOR THE BEST MAILING LISTS"

Jim Wright
38 Pentyla Baglan Rd
Port Talbot
West Glamorgan SA12 8AA
Wales UK 


 
 ________________________________________________
 REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS"
 Conrad Fry
 1 Avon Gardens
 West Bridgford
 Nottingham England
 NG2 6BP 
 
 
 
 ----------------------------------------------------------------
 -----
 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 dependent
 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
 
 ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO
 FINANCIAL FREEDOM!
 
 NOW IS THE HOUR!
 
 DECISIVE ACTION YIELDS
 POWERFUL RESULTS !
 *********************************************************
Your request to be removed will be processed within 24 hours. DISCLAIMER: Under Bill s.1618 TITLE III 
passed by the 105th US Congress this letter Cannot be considered Spam as long as the sender includes 
contact information & a method of removal.To be removed from future mailings just reply with REMOVE in 
the subject line.Thank you for your kind consideration.




From list@netscape.com  Mon Sep 18 06:46:05 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 SMTP id GAA01656
	for ; Mon, 18 Sep 2000 06:46: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 e8IAc6S28744;
	Mon, 18 Sep 2000 03:38:06 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IAiN214328;
	Mon, 18 Sep 2000 03:44:23 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 03:44:23 -0700 (PDT)
Message-Id: <200009181043.GAA01526@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-ldap-taxonomy-03.txt
Date: Mon, 18 Sep 2000 06:43:56 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"laHMD.A.mfD.GIfx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
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		: A Taxonomoy of Methods for LDAP Clients Finding 
                          Servers
	Author(s)	: R. Moats, R. Hedberg
	Filename	: draft-ietf-ldapext-ldap-taxonomy-03.txt
	Pages		: 5
	Date		: 15-Sep-00
	
There are several different methods for a LDAP client to find a LDAP
server. This draft discusses these methods and provides pointers for
interested parties to learn more about implementing a particular
method.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-taxonomy-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-ldap-taxonomy-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-ldap-taxonomy-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:	<20000915135938.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From list@netscape.com  Mon Sep 18 12:56:47 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 SMTP id MAA14635
	for ; Mon, 18 Sep 2000 12:56: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 e8IGgBX28597;
	Mon, 18 Sep 2000 09:42:11 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IGqgc18527;
	Mon, 18 Sep 2000 09:52:42 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 09:52:42 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Mon, 18 Sep 2000 10:51:48 -0600
From: "Jim Sermersheim" 
To: , 
Subject: Re: Feature discovery (Was: RFC 2596 questions)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_EBB31934.6A0B64A3"
Resent-Message-ID: <"buMWqB.A.hgE.Vhkx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_EBB31934.6A0B64A3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

A couple other considerations dealing with approach 2 are:

- It allows an ATO (attribute type option) to be tied to any attribute =
that is of a given syntax.
- This type of not-so-easy-searching already has to be done for name =
forms, content rules, and structure rules. This follows the existing =
paradigm. I will say however, that I don't much like the existing paradigm =
as far as name forms and structure rules are concerned, I'd rather see =
that info in the object class. Oh well, side issue...

An issue with approach 1:
- Whether a server supports ATOs will largely be due to built-in support =
(unless a plug-in architecture is provided by the vendor). If the =
advertisement of the support is on the attributetype, who will populate =
it? In other words, If I extend the schema to include a new attributetype, =
Am I expected to supply the supported ATOs? What if I do, and the server =
can't handle them? Does the server auto-fill attributetypes with unspecifie=
d ATOs that it can support?

Jim

>>>  9/16/00 5:00:50 AM >>>

Hi all,=20

I like the idea of extending the schema information with the set of =
attribute descriptions that are known to the server.=20

Both approaches described so far:=20

1) extend the attributeTypes value to allow for additional fields to be =
specified within each value, add a new value that defines the OIDs used in =
the field=20
2) add a new attribute to the subschemasubentry and contain all the =
information here=20

are in the right direction.=20

Approach 1) has the benefit that just by looking at the attributeType =
value, you can get an indication if any attribute descriptions might have =
been used in creating/modifying entries that contain this attribute.  =
However, there would be the issue of whether or not the server supported =
the additional data in the attributeTypes value.=20

Approach 2) doesn't change the attributeType value definition (nice for =
upward compatibility).  On the downside, though, in order to see what =
attribute description a given attribute type can have attached to it, a =
not-so-easy-search of the new schema attribute would have to be performed.=
=20

After writing up this short discussion of the approaches, I think I prefer =
Approach 1) where the "DESCRIPTORS (  "$" ... )" clause of the =
attributeTypes value is an optional piece in the format of the value.=20

Is there agreement here?

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

To:        "Jim Sermersheim" =20
cc:        Timothy Hahn/Endicott/IBM@IBMUS, =20
Subject:        Re: Feature discovery (Was: RFC 2596 questions)=20




>Also, some things (like attr type options) need more than just an OID in =
a list. We need to specify where they can be used (which attrs or syntaxes =
support them).

Likely best to extend the attributeTypes and LDAPsyntaxes to include
additional fields... like X-FEATURES ( 1.2.3 $ 2.3.4 )  where 1.2.3
might indicate language tags support and 2.3.4 might indicate binary
transfer support.

Kurt=20

--=_EBB31934.6A0B64A3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







A couple other considerations dealing with approach =
2=20
are:


 


- It allows an ATO (attribute type option) to be tied =
to any=20
attribute that is of a given syntax.


- This type of not-so-easy-searching already has to be =
done=20
for name forms, content rules, and structure rules. This follows the =
existing=20
paradigm. I will say however, that I don't much like the existing paradigm =
as=20
far as name forms and structure rules are concerned, I'd rather see that =
info in=20
the object class. Oh well, side issue...



An issue with approach 1:


- Whether a server supports ATOs will largely be =
due to=20
built-in support (unless a plug-in architecture is provided by the =
vendor). If=20
the advertisement of the support is on the attributetype, who will =
populate it?=20
In other words, If I extend the schema to include a new attributetype, Am =
I=20
expected to supply the supported ATOs? What if I do, and the server can't =
handle=20
them? Does the server auto-fill attributetypes with unspecified ATOs that =
it can=20
support?


 


Jim



>>> <hahnt@us.ibm.com> 9/16/00 5:00:50 AM=20
>>>

Hi all, =


I like the idea of extending the schema =
information with=20
the set of attribute descriptions that are known to the server.=20


Both approaches described so =
far:=20


1) extend the attributeTypes =
value to allow=20
for additional fields to be specified within each value, add a new value =
that=20
defines the OIDs used in the field 
2)=20
add a new attribute to the subschemasubentry and contain all the informatio=
n=20
here 

are in the right=20
direction. 

Approach 1) has =
the=20
benefit that just by looking at the attributeType value, you can get an=20
indication if any attribute descriptions might have been used in=20
creating/modifying entries that contain this attribute.  However, =
there=20
would be the issue of whether or not the server supported the additional =
data in=20
the attributeTypes value. 

A=
pproach=20
2) doesn't change the attributeType value definition (nice for upward=20
compatibility).  On the downside, though, in order to see what =
attribute=20
description a given attribute type can have attached to it, a not-so-easy-s=
earch=20
of the new schema attribute would have to be performed. 

After writing up this short discussion of the =
approaches,=20
I think I prefer Approach 1) where the "DESCRIPTORS ( <OID> "$" ... =
)"=20
clause of the attributeTypes value is an optional piece in the format of =
the=20
value. 

Is there =
agreement=20
here?

Regards,
Tim=20
Hahn

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


To:     =
 =20
 "Jim Sermersheim"=20
<JIMSE@novell.com> 
cc:        Timothy Hahn/Endicott/IBM@IBMUS,=20
<ietf-ldapext@netscape.com> 
Subje=
ct:  =20
     Re: Feature =
discovery=20
(Was: RFC 2596 questions) 




>=
;Also,=20
some things (like attr type options) need more than just an OID in a list. =
We=20
need to specify where they can be used (which attrs or syntaxes support=20
them).

Likely best to extend the=20
attributeTypes and LDAPsyntaxes to include
additional fields... like=20
X-FEATURES ( 1.2.3 $ 2.3.4 )  where 1.2.3
might indicate language =
tags=20
support and 2.3.4 might indicate binary
transfer=20
support.

Kurt=20





--=_EBB31934.6A0B64A3--



From list@netscape.com  Mon Sep 18 15:04: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 SMTP id PAA17637
	for ; Mon, 18 Sep 2000 15:04: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 e8IIuXS04759;
	Mon, 18 Sep 2000 11:56:34 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IIwFo17366;
	Mon, 18 Sep 2000 11:58:15 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 11:58:15 -0700 (PDT)
From: kgdaniec@us.ibm.com
Importance: Normal
Subject: Re: Feature discovery (Was: RFC 2596 questions)
To: , hahnt@us.ibm.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: 
Date: Mon, 18 Sep 2000 14:56:48 -0400
X-MIMETrack: Serialize by Router on D01MLC83/01/M/IBM(Build V505_08212000.dev00 |August
 28, 2000) at 09/18/2000 02:56:53 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e8IIuur16686
Resent-Message-ID: <"mw1WUC.A.bKE.-Wmx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e8IIuXS04759
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17637

Jim,
Perhaps a combination of the approaches mentioned already really is needed,
then.  Servers could publish in their rootDSE the attributetype
options/extensions that they support.  This would allow anyone adding to or
modifying the schema to know what the server supports.  However, the server
could also publish as part of the schema what the "currently active" set of
attributetype "descriptors" (to use Tim's term) is.

Would these be specified by syntax or by attributetype, though, or both?
Setting these by syntax allows defaults to be in effect for each
attributetype.  I suppose this is no more confusing than  "default"
matching rules based upon syntax.

Karen

Internet: kgdaniec@us.ibm.com
Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
                 IBMUSM10(KGDANIEC)
phone: 607.752.1075   tie-line: 8/852-1075
fax: 607.752.3681
---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on
09/18/2000 02:51 PM ---------------------------

"Jim Sermersheim"  on 09/18/2000 12:51:48 PM

To:   , Timothy Hahn/Endicott/IBM@IBMUS
cc:
Subject:  Re: Feature discovery (Was: RFC 2596 questions)




A couple other considerations dealing with approach 2  are:

- It allows an ATO (attribute type option) to be tied to any  attribute
that is of a given syntax.
- This type of not-so-easy-searching already has to be done  for name
forms, content rules, and structure rules. This follows the existing
paradigm. I will say however, that I don't much like the existing paradigm
as  far as name forms and structure rules are concerned, I'd rather see
that info in  the object class. Oh well, side issue...

An issue with approach 1:
- Whether a server supports ATOs will largely be due to  built-in support
(unless a plug-in architecture is provided by the vendor). If  the
advertisement of the support is on the attributetype, who will populate it?
In other words, If I extend the schema to include a new attributetype, Am I
expected to supply the supported ATOs? What if I do, and the server can't
handle  them? Does the server auto-fill attributetypes with unspecified
ATOs that it can  support?

Jim

>>>  9/16/00 5:00:50 AM  >>>

Hi all,

I like the idea of extending the schema information with  the set of
attribute descriptions that are known to the server.

Both approaches described so far:

1) extend the attributeTypes value to allow  for additional fields to be
specified within each value, add a new value that  defines the OIDs used in
the field
2)  add a new attribute to the subschemasubentry and contain all the
information  here

are in the right  direction.

Approach 1) has the  benefit that just by looking at the attributeType
value, you can get an  indication if any attribute descriptions might have
been used in  creating/modifying entries that contain this attribute.
However, there  would be the issue of whether or not the server supported
the additional data in  the attributeTypes value.

Approach  2) doesn't change the attributeType value definition (nice for
upward  compatibility).  On the downside, though, in order to see what
attribute  description a given attribute type can have attached to it, a
not-so-easy-search  of the new schema attribute would have to be performed.

After writing up this short discussion of the approaches,  I think I prefer
Approach 1) where the "DESCRIPTORS (  "$" ... )"  clause of the
attributeTypes value is an optional piece in the format of the  value.

Is there agreement  here?

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


To:         "Jim Sermersheim"  
cc:        Timothy Hahn/Endicott/IBM@IBMUS,  
Subject:         Re: Feature discovery  (Was: RFC 2596 questions)




>Also,  some things (like attr type options) need more than just an OID in
a list. We  need to specify where they can be used (which attrs or syntaxes
support  them).

Likely best to extend the  attributeTypes and LDAPsyntaxes to include
additional fields... like  X-FEATURES ( 1.2.3 $ 2.3.4 )  where 1.2.3
might indicate language tags  support and 2.3.4 might indicate binary
transfer  support.

Kurt








From list@netscape.com  Mon Sep 18 15:05: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 SMTP id PAA17672
	for ; Mon, 18 Sep 2000 15:05: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 e8IIqQX22609;
	Mon, 18 Sep 2000 11:52:26 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IIwKY17517;
	Mon, 18 Sep 2000 11:58:20 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 11:58:20 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Mon, 18 Sep 2000 12:57:44 -0600
From: "Steve Sonntag" 
To: , "Jim Sermersheim" ,
        "Steve Sonntag" , 
Cc: "Alan Clark" , "Steven Merrill" 
Subject: Re: LDAPSetoption java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_560EA4A4.2B4A24B3"
Resent-Message-ID: <"qCPADD.A.VPE.GXmx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_560EA4A4.2B4A24B3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

I discovered I was incorrect about setOption not supporting controls.
Section 4.41 describes this funtionality.  However the keys that
control the operation of setOption are not defined in a consistent way.

The LDAPv2 keys are defined in LDAPConnection:, i.e.
  LDAPConnection.DEREF =3D 2
  LDAPConnection.SIZELIMIT =3D 3
     and so forth.

The function setOption is defined in LDAPv2.

The LDAPv3 keys are defined in LDAPv3
   SERVERCONTROLS (no value)
   CLIENTCONTROLS (no value)

The LDAPv2 keys for setOption() should be moved to
the LDAPv2 interface and out of LDAPConnection.

Are the LDAPv3 keys names consistent with LDAPv2 key names?

The LDAPv3 keys need a value defined so as to=20
guarantee there is no value collision with LDAPv2 keys values.

Section 4.41 would be better if moved to 4.40 and defined
as setOption / getOption keys as part of the LDAPv3 interface.

I still think though that the setOption method is not needed, but
if kept IMO the above needs to be fixed as well as that previously
discussed.

-Steve

>>> "Steve Sonntag"  31-Aug-00 11:55:40 AM >>>

Section 4.39.13 LDAPV2.setOption

This method of the LDAPV2 interface seems a little strange.

 1) It probably does not belong under the interface LDAPV2,
    but instead under LDAPConnection. This would allow it
    to support setting client & server controls which it
    cannot do under LDAPV2.  This functionality is currently
    missing in the method.
   =20
    Setting STRING_FORMAT is also an LDAPV3 setting, as UTF-8
    is only meaningful under LDAPV3.

 2) STRING_FORMAT is set only by the setOption method.
    There should be a way to set or get STRING_FORMAT with
    LDAPSearchConstraints methods.

 3) setOption operates only on the LDAPSearchConstraints object
    that is associated with an LDAPConnection object.  Yet
    there may also be an LDAPConstraints object associated
    with the LDAPConnection object.  It may or may not be
    the same as the LDAPSearchConstraints object.  Should
    there be a setOption kind of method that operates on
    the LDAPConstraints object associated with a connection?

 4) All functionality of SetOption can be performed by code
    that references the LDAPSearchConstraints object of a
    connection - i.e. LDAPConnection.getSearchConstraints.method().

This method is superfluous and problematic.=20
IMO, it is not needed and should be eliminated from the API.

-Steve

--=_560EA4A4.2B4A24B3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







I discovered I was incorrect about setOption not =
supporting=20
controls.


Section 4.41 describes this funtionality.  However the keys =
that


control the operation of setOption are not defined in a consistent=20
way.


 


The LDAPv2 keys are defined in LDAPConnection:, i.e.


  LDAPConnection.DEREF =3D 2


  LDAPConnection.SIZELIMIT =3D 3


     and so forth.


 


The function setOption is defined in LDAPv2.


 


The LDAPv3 keys are defined in LDAPv3


   SERVERCONTROLS (no value)


   CLIENTCONTROLS (no value)


 


The LDAPv2 keys for setOption() should be moved to


the LDAPv2 interface and out of LDAPConnection.


 


Are the LDAPv3 keys names consistent with LDAPv2 key names?


 


The LDAPv3 keys need a value defined so as to 


guarantee there is no value collision with LDAPv2 keys values.


 


Section 4.41 would be better if moved to 4.40 and defined


as setOption / getOption keys as part of the LDAPv3 interface.


 


I still think though that the setOption method is not needed, =
but


if kept IMO the above needs to be fixed as well as that previously

discussed.


 


-Steve


 


>>> "Steve Sonntag" <VTAG@novell.com> 31-Aug-00 =
11:55:40 AM=20
>>>


Section 4.39.13 LDAPV2.setOption


 


This method of the LDAPV2 interface seems a little strange.
=


 


 1) It probably does not belong under the interface=20
LDAPV2,
    but instead under LDAPConnection. This would =
allow=20
it
    to support setting client & server controls =
which=20
it
    cannot do under LDAPV2.  This functionality =
is=20
currently
    missing in the=20
method.
    
    Setting =
STRING_FORMAT=20
is also an LDAPV3 setting, as UTF-8


    is only meaningful under LDAPV3.


 


 2) STRING_FORMAT is set only by the setOption=20
method.
    There should be a way to set or get =
STRING_FORMAT=20
with
    LDAPSearchConstraints methods.


 


 3) setOption operates only on the LDAPSearchConstraints=20
object
    that is associated with an LDAPConnection=20
object.  Yet
    there may also be an LDAPConstraint=
s=20
object associated
    with the LDAPConnection object.&nbs=
p; It=20
may or may not be
    the same as the LDAPSearchConstrain=
ts=20
object.  Should
    there be a setOption kind of =
method=20
that operates on
    the LDAPConstraints object =
associated=20
with a connection?


 


 4) All functionality of SetOption can be performed by=20
code
    that references the LDAPSearchConstraints =
object of=20
a
    connection - i.e.=20
LDAPConnection.getSearchConstraints.method().


 


This method is superfluous and problematic. 
IMO, it is not needed =
and=20
should be eliminated from the API.


 


-Steve


--=_560EA4A4.2B4A24B3--



From list@netscape.com  Mon Sep 18 15:42: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 SMTP id PAA18304
	for ; Mon, 18 Sep 2000 15:42: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 e8IJTlX29273;
	Mon, 18 Sep 2000 12:29:47 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IJeKc08477;
	Mon, 18 Sep 2000 12:40:20 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 12:40:20 -0700 (PDT)
Date: Mon, 18 Sep 2000 14:39:35 -0500
From: Mark Wahl 
Subject: Re: RFC 2596 questions
In-reply-to: "Your message of Fri, 15 Sep 2000 07:18:14 EDT."
 
Sender: wahl@austin.innosoft.com
To: hahnt@us.ibm.com
Cc: ietf-ldapext@netscape.com
Message-id: <10250.969305975@threadgill.austin.innosoft.com>
Resent-Message-ID: <"L_2-kB.A.6DC.i-mx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


FYI the option "dynamic" was used by a draft which did not become an RFC.



Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance



From list@netscape.com  Mon Sep 18 16:06: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 SMTP id QAA18775
	for ; Mon, 18 Sep 2000 16:06: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 e8IJvXS16103;
	Mon, 18 Sep 2000 12:57:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IK3pY21120;
	Mon, 18 Sep 2000 13:03:51 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 13:03:51 -0700 (PDT)
Date: Mon, 18 Sep 2000 13:03:42 -0700 (PDT)
Message-Id: <200009182003.e8IK3f911953@xwing.netscape.com>
From: payoffs20002mymail.com@xwing.netscape.com
To: Investors@xwing.netscape.com, Only@netscape.com
Subject:  300% Reteurn on Investment inJust 90 Days!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"wurZkC.A.fJF.lUnx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hello, I have a program that pays 3-1 in just 3 months, plus 50% payments for referrals! I 
have already recieved $200 in referrals! This is a good one to get into, even if it's just for 
the referral payouts, ( they will be going down to 35% and then to 20% in about 1 month 
from now)! Minimum to invest is $100. If you are interested in signing up please send  an 
e-mail to : deals4u@mail.com 
and you MUST put " YES " in the subject matter or you will not get a response. Thank 
you!




From list@netscape.com  Mon Sep 18 16:17: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 SMTP id QAA18999
	for ; Mon, 18 Sep 2000 16: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 e8IK9wS18403;
	Mon, 18 Sep 2000 13:09:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8IKGG627045;
	Mon, 18 Sep 2000 13:16:16 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 13:16:16 -0700 (PDT)
Message-ID: <31EF955E0A3BD411AE7F004F4E01F08423A691@mailut2.vpnx.com>
From: Brian Jarvis 
To: "'Jim Sermersheim'" , ietf-ldapext@netscape.com
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Date: Mon, 18 Sep 2000 14:13:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"rmkauB.A.TmG.Ognx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I am hesitant to put language elements into the schema for two (so far)
reasons.
1.  If a particular language is not advertised in the schema, it would imply
that I cannot add an element with that language.
2.  It would greatly expand the number of schema elements.

--the walrus

bjarvis@internap.com

-----Original Message-----
From: Jim Sermersheim [mailto:JIMSE@novell.com]
Sent: Friday, September 15, 2000 3:29 PM
To: ietf-ldapext@netscape.com; kgdaniec@us.ibm.com
Subject: Re: Feature discovery (Was: RFC 2596 questions)


You mean advertised in the schema, right? I would say yes, I think there
should be another schema element called something like attributeTypeOptions,
the syntax would look something like this (ala 2252 nomenclature):
 
AttributeTypeOptionDescription = "(
   numericoid whsp ; Attribute Type Option Identifier
   [ "NAME" qdescrs ]
   [ "DESC" qdescrs ]
   [ "OBSOLETE" whsp ]
   "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") oids) ; list of
syntaxes or attributes that this ATO applies to.
   whsp ")"

 
Jim



From list@netscape.com  Mon Sep 18 19:21: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 SMTP id TAA21415
	for ; Mon, 18 Sep 2000 19:21: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 e8IN9RX08605;
	Mon, 18 Sep 2000 16:09:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8INK0Q06670;
	Mon, 18 Sep 2000 16:20:00 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 16:20:00 -0700 (PDT)
Sender: Mark.Wahl@Central.Sun.COM
Message-ID: <39C6A335.8DDED5C@sun.com>
Date: Mon, 18 Sep 2000 18:20:21 -0500
From: Mark Wahl 
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Sermersheim 
CC: ietf-ldapext@netscape.com, Mark.Wahl@Sun.COM, Mark.Wahl@innosoft.com
Subject: Re: RFC 2596 questions
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"P5dWYC.A.HnB.dMqx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


> I have a few questions about RFC 2596 (Language Codes in LDAP).
  
> Section 3.1 says "Multiple language options may be present on a particular 
> value.".
> To me, this says the following is allowable:
> cn;lang-en-US;lang-ja: JoeBob

Yes.

> Is that correct? If so, I believe the following assumption is also correct:
> Any value held in an attribute with more than one language option (i.e. the 
> example above) does NOT exist in the attribute with a subset of those 
> language options. In other words, the example above does NOT imply that 
> there are values like:
> cn;lang-en-US: JoeBob
> cn;lang-ja: JoeBob
> Right?
  
Those are different values.  You could have them there as well, if you wished.

For example, 'cn' and 'sn' are subtypes of 'name'.  You can have an entry with
the three attributes:

name: joe
cn: joe
sn: joe

> I don't want to believe part of Section 3.3. It says that given the filter
> (name;lang-en-US"=Billy Ray), that the following is a match:
> CN;lang-EN-US;dynamic: Billy Ray
> To me, this is a different, distinct subtype. In other words:
> cn;foo is a subtype of cn
> cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn.

> Am I off in my thinking? RFC 2251 says that "An AttributeDescription with one
> or more options is treated as a subtype of the attribute type without any
> options".
  
I agree it needs to be clarified. There are two ways of interpreting this
sentence.  I parse subtyping as 
 If A is a subtype of B and B is a subtype of C, A is a subtype of C, just 
 not an 'immediate' subtype.  

> Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic examples 
> in 2596 are invalid. RFC 2251 states that the options must appear in 
> ascending order.

You're right, that's a typo in 2596.  We'll fix that when it is time to reissue.

  
> At the end of section 3.3, it says: "Thus in general, clients SHOULD NOT 
> use the language code option in AttributeDescription fields in search
> filters". Is this because they might get more matches than they bargained for?
> It would be nice if the "Thus in general" part was spelled out a bit more.
  
It was earlier in this section.  This is just a reminder.

   Client implementors should however note that providing a language
   code in a search filter AttributeDescription will often filter out
   desirable values where the language code does not match exactly.  

Mark Wahl
Sun Microsystems, Inc.



From list@netscape.com  Mon Sep 18 19:53: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 SMTP id TAA21689
	for ; Mon, 18 Sep 2000 19:53: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 e8INjYS04573;
	Mon, 18 Sep 2000 16:45:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8INprU26046;
	Mon, 18 Sep 2000 16:51:53 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 16:51:53 -0700 (PDT)
Message-ID: <31EF955E0A3BD411AE7F004F4E01F08423A698@mailut2.vpnx.com>
From: Brian Jarvis 
To: "'ietf-ldapext@netscape.com'" 
Cc: "'KNVIJAY@novell.com'" 
Subject: re: the LDAP client caching proxy model ...
Date: Mon, 18 Sep 2000 17:49:52 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"61bGLC.A.rWG.Yqqx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

A general comment about the approach:

The method described using special purpose controls and responses means that
every ldap enabled program will need to be "cache enabled".  IOW, they will
not be to able to make use of the cache unless programmed to do so.  Would
it not be better to use some sort of flow through model where an ldap
enabled program that is *not* "cache enabled" would attempt to bind to the
local cache which would either use its cache or flow through to the "real"
server?  Then mobile users would only need one "cache enabled" program to
easily add/remove things from the cache.


3.1 proxyServierBind Controls:
  disconnectedMode

    Why ignore the serverPort field when in disconnected mode?  This makes
it impossible to differentiate between the LDAP servers when there are
multiple servers running on the same serverName.

4.1 Caching logic...
  base search
    "Results returned to the client, however, will be based on the search
filter specified."

        The filter only is used to determine which objects qualify.  The
attributes and typesOnly fields determine the results sent to the client.

    "The entire object shall be fetched and cached."

        What is the reason behind caching the whole object?  The search
request shows that the only the attributes named in the filter and
attributes fields are of interest...  If this is intended, then put * in the
attributes field.  If the object is large over a slow (dialup?) link this
could be painful.

5.  Authentication and access control...

  Access control and authentication in a discretionary access control system
such as LDAP (in the current ID) only control how the information is
released or modified in the system.  It does not control what can be done
with it.  IOW, once you have read information, LDAP does not control or
dictate how you will use it or where you will store it.  If the
administrator does not trust you to treat the information appropriately (as
he defines it), he should not give you access.

  Having said that, I agree that the cached objects should be protected (if
possible).  I am very concerned that you seem to be storing the identity and
keys to access the directories in the proxy server (so that the user can be
authenticated in disconnected operations).  If the mobile system falls into
the wrong hands, all objects accessible by those identities/keys are
vulnerable.  If you don't store the identities and keys, then only the
objects in the cache are exposed.  I would rather deal with the later and
restrict what I cache, than deal with the former.

--the walrus



From list@netscape.com  Mon Sep 18 20:18:53 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 SMTP id UAA21903
	for ; Mon, 18 Sep 2000 20:18: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 e8J0B4S09234;
	Mon, 18 Sep 2000 17:11:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8J0HME08266;
	Mon, 18 Sep 2000 17:17:22 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 17:17:22 -0700 (PDT)
Message-Id: <200009190038.AAA18725@mailgw.rossberg-holding.de>
From: "Oscar Jinsin" 
Subject: Your Chance #4B6E
To: cards29s@mailgw.rossberg-holding.de.netscape.com
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date: Mon, 18 Sep 2000 19:12:13 -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 e8J0HLr08233
Resent-Message-ID: <"rjzRoC.A.vAC.RCrx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

              
Accepting credit cards for your business 

has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!

NO PROGRAMMING FEE!

$9.95 PROCESSING FEE

Call today and apply:

(888) 264-9272

Now you can design your web site with our

complete software package, which includes:

     Domain Registration 
     Web Hosting 
     Web Design Tools 
     Shopping Cart 
     Credit Card Processing Integration

Quick, Easy and Affordable at just $99.00!

Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:bknp@doramail.com?subject=remove
************************************************************





From list@netscape.com  Mon Sep 18 23:09: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 SMTP id XAA25386
	for ; Mon, 18 Sep 2000 23:09: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 e8J31iS01315;
	Mon, 18 Sep 2000 20:01:44 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8J383M08008;
	Mon, 18 Sep 2000 20:08:03 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 20:08:03 -0700 (PDT)
From: jojimmy@themail.com
Subject: Make money with the BANK'S money
Reply-To: jojimmy@themail.com
Date: 18 Sep 2000 23:13:22 -0400
Mime-Version: 1.0
Content-Type: text/html
Message-Id: <20000919025455.IEG12631@mailhost.attcanada.net>
Resent-Message-ID: <"sJ-uP.A.Q8B.Sitx5"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e8J31iS01315
Content-Transfer-Encoding: quoted-printable












 















Remove ins=
truction
at the bottom



QUICK CASH SECRET BA=
NKING
SYSTEM, THE SECRETS OF THE RICH & FAMOUS REVEALED AT LAST!!! Make money with the abundance of the bank=92s money=A0 


=A0 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$=
$$



LUCKY YOU=
! GET
FREE "$1,500/WEEK CASH" INFORMATION NOW !!!



$$$$$$$$$=
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$=




"Quick Cash Secret Banking System", is now =
being
released to the general public again, to benefit anyone who is interested=
 in
generating a guaranteed $1,500+/week cash, without
any HARD work or large investment!



Quick Cash Secret Banking System is the =
fastest
and the easiest money making system today in the world, used by all
multi-millionaires to pile up cash, without any huffing and puffing! =




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D



It is 100% legal, easy,=
 fast
and fun! There is no scam or shady transaction=
!
Approved by all government agencies, including the US Treasury Dept., Ame=
rican
and International Banking Associations, The Fed, and US Post Office! It
WORKS in any country in the world that has bank(s) and provides the facil=
ity to
open checking account(s). 



<<><><><><>=
;<><><><><><<><><><=
><>



I guarantee that from this moment on your life will never be the same =
again.
You will be amazed at how much money you will be capable of having in jus=
t a
few days, right from your Federal Reserve Board.



Please, leave the skepticism in the past. If you are skeptical, this w=
ill
not work or anything else in life for that matter, because you will not
believe.=A0=A0 If you were promi=
sed
$5,000,000 to jump out of an airplane without a parachute, would you do i=
t? If
you answered "No" you answered Wrong! Like the ma=
jority
of the people, you made a decision before you had all the facts. Had you
investigated further, you would have found out that the plane was on the
ground. Do not let the greatest opportunity of your life pass you by beca=
use
you were so eager to jump into conclusions that you did not get all the f=
acts.
Please, read on and try to get the concept of what I can give you here an=
d now,
before you form any opinions.



Ok, I think that you are ready to begin now.=A0 I want you to follow exactly the instructions that you ar=
e about
to read. Let me be your guide throughout the entire booklet.=A0 It is financial health you are loo=
king for
and I sure know how you can get it. So, follow my instructions.=A0 



MAKE MONEY WITH T=
HE
BANK=92S MONEY


During a 6-month period you will be able to deposit 50,000 dollars in =
your
personal bank accounts, without doing anything at all!=A0 Let me elaborate just a little.=A0 =93You do not do anything physi=
cal to bring
in this kind of money!=94=A0 The bank
does all the work for you at your convenience, and as long as you keep yo=
ur
account =93open=94 they almost have no choice!=A0 I will show you how to make a minimum of $5,000 a mont=
h by
just opening a bank account. =A0But
that is just the tip of the iceberg!=A0=
 By
opening a bank account, I will teach you how to have that kind of money
deposited into your bank account Automatically, though a built-in
automatic process that I will personally show you.=A0 That is the beauty of the $ecret Banking $ystem!=A0 Imagine making $5,000 a month for =
each bank
account you =93open=94.=A0 And a=
side from
opening the account, it does not cost you anything!=A0 Just one bank account can make you financially independen=
t for
life! 



Now Think Big.=A0 Think of th=
e same idea
on a slight larger scale, like two or three bank accounts working at the =
same
time each producing a guaranteed monthly income of $5,000 each.=A0 As of today, I have 13 active acco=
unt
@$5,000 =3D $65,000 per month, every month, 12 months a year.=A0 I assure you, there is no print er=
ror.=A0 I said 65 thousand dollars per mon=
th! 



In summary this is how the formula works:=A0
YOU walk into a bank, open a bank account, follow the instructions=
 like
a recipe in a cookbook, and 30 days later you will make $5,000. =A0And one of the most amazing realiti=
es of the
$ecret Banking $ystem is that you can begin with literally $0, zero money=
.=A0 In the $ecret Banking $ystem manua=
l, in an
easy to duplicate as a set of =93blueprints=94, you will find out for you=
rself
where all the money comes from and how it is added up for you.=




I realize
what I am originating to you may sound impossible, but I promise you, it =
is
possible, doable and simple.=A0 =
There is
not shortage of money, the Federal Reserve Board creates money daily but =
most
of it must pass through and circulate in the banks over and over again. <=
span
style=3D"mso-spacerun: yes">=A0That is how banks run.=A0 That is where this Ingenious $ecre=
t Banking
$ystem comes in.=A0 All you need=
 is the $ecret
Banking $ystem manual to start making big money.=A0 IF YOU ORDER TODAY WE SHALL ADD AT NO EXTRA COST TO YO=
U, THE FAMOUS=
 "101 High Profit Businesses You Can Start Online For Litt=
le Or
No Money", PLUS 1,000,000 ONE MILLION OPT-IN ADDRESSES- FREE!!


That you obtain your very own copy of the $ecret Banking $ystem and th=
e
above mentioned, take the first step and invest only $49US for something =
that
is worth its weight in gold.=A0 =
Copy and
mail-send a cheque, (we accept cash) or money order to: 



All Moreir .=




15 Pape
Avenue Suite 409



To=
ronto,
Ontario, Canada



M4M 2V5



___________<=
/span>



ORDER FORM



 



Name=A0=A0=A0=A0=A0=A0=A0=A0=A0 ___________________________________=
_____________



Address=A0=A0=A0=A0=A0=A0 _____________________=
_________________________



City=A0=A0 _____________________=A0=
=A0=A0=A0=A0=A0=A0 State_________=A0=A0 Zip_____-________



Fax=A0=A0=A0 (_____) _____-______



E-mail address=A0=A0=A0=A0=A0 ________________________=
_________________



Send me the $ecret Banking $yst=
em right
now, please.=A0 Here is the $49U=
S.



Write legible please=




________and check here =
for
fastest service if you would like to receive this information by e-mail a=
s an
attachment and save the $5.00 shipping and handling fee.=
 



IF YOU ORDER TODAY



WE SHALL ADD AT NO E=
XTRA
COST TO YOU, THE FAMOUS "101 H=
igh
Profit Businesses You Can Start Online For Little Or No Money", PLUS=
 ONE
MILLION OPT-IN ADDRESSES- FREE!!



If you realize that you are on=
 this list
in error or have changed your mind or if you do not want this type of
information, please reply to this e-mail with "REMOVE" in the s=
ubject
field and you will be removed immediately! I apologize for any mistake,
intrusion or inconvenience, if any. =A0Under Bill 1618 Title 111 passed by the 105th U.S. Congres=
s, this
message can not be considered SPAM as long as we include a way for it to =
be
removed from future mailings



 <=
span
style=3D'color:green;background:white'>Foundations of Wealth



If you wish to learn more=85=85please read on



A few years ago I believed that I really had to work hard to make mone=
y. I
thought that the more I worked, the more money I was going to make. But a=
fter a
while I realized that I was not getting anywhere. I was working like a sl=
ave
and I was not seeing any satisfactory results. I wondered why I wasn't be=
cause
I sure was applying the time and the effort. 



I realized that I needed to make a change. For months I tried to find =
that
special answer that I needed. I tried different things, but none of them
worked. I was lost. Finally, I was ready to give up my dreams and continu=
e
living that ordinary life that I was used to living. You know, that wake =
up, go
to work, come home, have dinner, and go to bed sort of life. That kind of=
 life
that I am very sure you are used to living. But no! I had to give it one =
more
chance. I could not quit that easily. So, an idea came to my mind and I d=
ecided:
"If I want to be become extremely wealthy, why don't I study people =
who
already are extremely wealthy and interpret what they are doing?" So=
 that
is what I did. After a few months, I realized that the majority of the
extremely wealthy people did not work that hard. Also, the majority of th=
em not
only had enough money to buy another planet, but they also had the time a=
nd the
freedom to enjoy it. That is what I consider true wealth, and that is exa=
ctly
what $ecret Banking $ystem is all about. The ability to have free time an=
d be
able to do what you choose, when you choose it. I think that is where the
majority of the people get confused on the definition of wealth. Wealth i=
s not
just money. Wealth is also the ability to spend it the way you choose to =
do,
when you want to do so.



Having accomplished my goals, my purpose now is to help those that are=
 in
the situation I was in; my purpose is to turn you into a "true"
wealthy person; I want you to have great amounts of money, and great amou=
nts of
free time to enjoy it. Now, the first step to accomplish this is the one =
that a
lot of people do not pay that much attention to, yet it is one of the mos=
t
important aspects of true wealth. I am talking about the mental aspect of=
 true
wealth. Hang on! =A0I know you a=
re tired
of listening the same psychology song over and over. Do not worry! =A0The mental aspect of true wealth is=
 actually
very simple and easy to apply. It is actually like a list of steps that y=
ou
have to "get into your mind" before we really get into the
"secrets" of making money with the bank=92s money that I have b=
een
talking about so much. Once you know all these steps and are ready to app=
ly
them, then you will really be ready to start the journey.



Please! Do not jump this section thinking that you do not need any men=
tal
preparation. It is very important! Remember, follow my instructions and y=
ou
could be sitting on gold in just days.



Do you remember the three "keys" to success that I explained=
 on
the web site? If you forgot, the three "keys" to success are:



    
 
  1. Timing: Being at the right p=
lace at
     the right time. 
    2. 
 
  2. Having Vision: Seeing potent=
ial in
     what is being presented. Having the ability to see success. 
    3. 
 
  3. Taking Action: Going one ste=
p
     further than the rest. Doing instead of saying.




These
three "keys" are essential to recognize success, and to make it=
 a
part of your life. Now, once you have made the decision to "Take
Action," your next task is to follow what I call "The Ten Steps=
 To
Success." As I said before, they are very simple, but extremely impo=
rtant
if your purpose is to achieve true wealth. I would happily give them to y=
ou as
part of the Training I provide when you obtain the $ecret Banking $ystem.=
=A0 Get your copy today!










----



From list@netscape.com  Mon Sep 18 23:12: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 SMTP id XAA25467
	for ; Mon, 18 Sep 2000 23:12: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 e8J30cX08651;
	Mon, 18 Sep 2000 20:00:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8J3BB209570;
	Mon, 18 Sep 2000 20:11:11 -0700 (PDT)
Resent-Date: Mon, 18 Sep 2000 20:11:11 -0700 (PDT)
Date: Tue, 19 Sep 2000 11:58:54 +0900 (KST)
From: pennychua@yahoo.com
Message-Id: <200009190258.LAA18878@kice3.kice.re.kr>
Reply-To: pennychua@yahoo.com
To: pennychua@yahoo.com
Subject: searching for cyber pals
Resent-Message-ID: <"bF6G7.A.zUC.Oltx5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Dear friend,

I am Penny Chua from KL. I hope to make some friends, male or
female, age 25-30. You can register and write to me at:
http://friend.asiadragons.com/cgi-bin/refsign.pl?refuid=pennychua
or find me at:
http://friend.asiadragons.com/cgi-bin/mdets.pl?uid=pennychua

Ok, seeya.

hope,
Penny



From list@netscape.com  Tue Sep 19 13:31:18 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 SMTP id NAA20972
	for ; Tue, 19 Sep 2000 13:31: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 e8JHIiX15244;
	Tue, 19 Sep 2000 10:18:44 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8JHTIc01409;
	Tue, 19 Sep 2000 10:29:18 -0700 (PDT)
Resent-Date: Tue, 19 Sep 2000 10:29:18 -0700 (PDT)
Message-ID: 
From: Dror Bar-Lev 
To: ietf-ldup@imc.org, ietf-ldapext@netscape.com, Kurt@openldap.org
Cc: Eli Afuta 
Subject: LDAP API library for VxWorks environment
Date: Tue, 19 Sep 2000 20:27:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-8-i"
Resent-Message-ID: <"bksJyC.A.xU.rJ6x5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Hello,

I would like to modify our network element to work with LDAP server, and I
would appreciate to receive an open source package of LDAP client that could
be implemented at VxWorks operating system.

Thanks in advance,
Dror Barlev
Project Manager - NMS
Orckit Communications Ltd. 
38 Nahalat Yitzhak St. Tel Aviv 67448, Israel 
Tel: +972-3-6945343    Fax: +972 3 6094754
Web Site: http://www.orckit.com
E-mail: drorbl@orckit.com



From list@netscape.com  Tue Sep 19 17:48: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 SMTP id RAA25452
	for ; Tue, 19 Sep 2000 17:48: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 e8JLenS04879;
	Tue, 19 Sep 2000 14:40:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8JLl8Q04433;
	Tue, 19 Sep 2000 14:47:08 -0700 (PDT)
Resent-Date: Tue, 19 Sep 2000 14:47:08 -0700 (PDT)
Message-Id: <5.0.0.25.0.20000919144248.00a9f040@router.boolean.net>
X-Sender: guru@router.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 19 Sep 2000 14:46:43 -0700
To: Dror Bar-Lev 
From: "Kurt D. Zeilenga" 
Subject: Re: LDAP API library for VxWorks environment
Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com, Eli Afuta 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"YN5HgD.A._EB.b79x5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Please note that our post is a bit off-topic for IETF Working
Group mailing lists.  IETF mailing lists are for discussion
work items of the group.  I suggest you go to your favorite
web search engine and do a search for "open source LDAP"
  http://search.yahoo.com/bin/search?p=open+source+LDAP

Kurt



From list@netscape.com  Tue Sep 19 19:40: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 SMTP id TAA26511
	for ; Tue, 19 Sep 2000 19:40: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 e8JNS8X11442;
	Tue, 19 Sep 2000 16:28:08 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8JNcgc03223;
	Tue, 19 Sep 2000 16:38:42 -0700 (PDT)
Resent-Date: Tue, 19 Sep 2000 16:38:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "$8,241.87 in just one month !!"
To: ietf-ldapext@netscape.com
Subject: "you may never see this again"
Date: Tue, 19 Sep 2000 19:48:11
X-Mailer: Prospect Mailer 2000
Message-Id: Prospect Mailer 20007:48:11 PM
Resent-Message-ID: <"ihrdBB.A.Cy.Ak_x5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Welcome to the most exciting opportunity club you may ever see!  Boy oh boy, have we got news for you!  Can you or someone you know use 100., 200., 300. or even 1,000. or more weekly/monthly?  This will "BLOW YOU AWAY" when you see over 75 exclusive sources that pay someone for working from the comfort of their home in their spare time.  These sources have been weeded out from the "FRAUDS," having stood the test of time (10 years), many being members of their local Better Business Bureaus and Business Associations.  We will rush the details to you.  All we ask is you cover the postage and handling ($4.), and if you're not 100% satisified with the details of this opportunity club program don't worry, not only will we refund the postage and handling ($4.), but we'll "cut you a check" for DOUBLE the postage and handling!  No one offers that!  We're so confident that this proven  program could change your life, we'll include a copy of our own bank statement proving an INCREDIBLE!
 8,241.87 was earned in just one month!  We'll even drop ship this amazing program risk free.  No inventory is necessary; all you do is advertise!  This is a complete turn-key opportunity, and you'll be SHOCKED and AMAZED at how you can be up and running the same day!  
SPECIAL BONUS:  Marketing "The Home Employment Opportunity Manual."  If you never sold anything before don't worry, this explosive section will show you how to market using classified ads, internet, direct sales, telemarketing, etc.  See how the pro's do it!  LISTEN TO THIS:  The first fifty (50) members only (no exceptions) will receive a bonus "The #1 Wealth-Building System in America."  HURRY, and your details will be shipped immediately.

OPTION: we highly  recommend that you order this explosive money makeing manual for $38.99(reg.59.99).this way you  have it in your hands and can make more of an educated decision+s&h is FREE$5.saveings. were  so confident you have a full 60 days GUARANTEE....%100 satifaction to look this over,ORDER NOW,,$8,241.87 in just one month!         
        Write to:  C. S. C.
                       266 Elmwood Avenue, Unit 172 - (Dept. H. E.M.)
                       Buffalo, New York 14222
                                (Incl. $4. S & H)

                    " IT,S  JUST  INCREDIABLE "
                                                                                   
                                                                                                                                                     
***this e-mail was sent to a priviledged list of people who have authorized it by submitting a request or filling out a registration, which you provided your e-mail address.thanks!!!!







From list@netscape.com  Tue Sep 19 21:18: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 SMTP id VAA27527
	for ; Tue, 19 Sep 2000 21:18: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 e8K16fX26723;
	Tue, 19 Sep 2000 18:06:41 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8K1HFc18052;
	Tue, 19 Sep 2000 18:17:15 -0700 (PDT)
Resent-Date: Tue, 19 Sep 2000 18:17:15 -0700 (PDT)
From: "Sales Department" 
To: 
Subject: Your Order!
Sender: "Sales Department" 
Mime-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Date: Wed, 20 Sep 2000 02:05:45 +0100
Content-Transfer-Encoding: 8bit
Message-Id: <200009192010203.SM00710@fraudbase.net>
Resent-Message-ID: <"4lQE7C.A.bZE.aABy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

<--	AbleCommerce 2.91 (tm) the award winning electronic commerce software
from Able Solutions.

http://www.ablecommerce.com/
The flexible solution for selling on the Internet.

Copyright Able Solutions Corporation, 1995-2000 ALL RIGHTS RESERVED

This Copyright notice may not be removed or altered in any way and must
be included in
all works derived from AbleCommerce.


-->

















































































Welcome to .net News Update












Welcome
to Ads by Email





Dear
Sir/Madam.


Your Email
Address
was purchased from postmasterdirect.com. If you wish to unsubscribe
please
send an email to unsubscribe@adsbyemailforever.com.


Please
take a
look at the following products for further information:



Commission Junction
- Get Paid!


 If
you have
a web site then sign up above and earn some money and visitors to your
website.


hotel

Banner 10000056

Try&Buy

468x60comp.hardware

FSPromo10/234x060
 








From list@netscape.com  Tue Sep 19 23:36:40 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 SMTP id XAA01256
	for ; Tue, 19 Sep 2000 23:36: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 e8K3SnS28423;
	Tue, 19 Sep 2000 20:28:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8K3Z9224445;
	Tue, 19 Sep 2000 20:35:09 -0700 (PDT)
Resent-Date: Tue, 19 Sep 2000 20:35:09 -0700 (PDT)
Date: Tue, 19 Sep 2000 20:34:40 -0700 (PDT)
Message-Id: <200009200334.e8K3Yd929510@xwing.netscape.com>
From: Free Ad Submitter 
To: @netscape.com
Subject:  * * * FREE Ad Submitter! * * *
X-Reply-To:  go_cycle@myworldmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"L20h-B.A.p9F.sBDy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

We will give you a FREE FULL FEATURED CLASSIFIED AD SUBMITTER when you subscribe to one of our 
COOL FREE e-minimags!!

Click here and send a blank email:
mailto:usefulfreebies@myworldmail.com?subject=AD_SUBMITTER

_________________________________________________
«¤+¥«¤+§«¤+¥«¤+§«¤+¥«¤+«¤+¥«¤+§«¤+¥«¤+§«¤+¥«¤+§«
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

be removed:
mailto:go_cycle@myworldmail.com?subject=Remove




From list@netscape.com  Wed Sep 20 09:07:56 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 SMTP id JAA21677
	for ; Wed, 20 Sep 2000 09: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 e8KCxnS06859;
	Wed, 20 Sep 2000 05:59:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8KD68601026;
	Wed, 20 Sep 2000 06:06:08 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 06:06:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "$8,241.87 in just one month !!"
To: ietf-ldapext@netscape.com
Subject: YOU MAY NEVER SEE THIS AGAIN !!!
Date: Wed, 20 Sep 2000 09:15:30
X-Mailer: Prospect Mailer 2000
Message-Id: Prospect Mailer 20009:15:30 AM
Resent-Message-ID: <"Zi5RIB.A.rP._YLy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Welcome to the most exciting opportunity club you may ever see!  Boy oh boy, have we got news for you!  Can you or someone you know use 100., 200., 300. or even 1,000. or more weekly/monthly?  This will "BLOW YOU AWAY" when you see over 75 exclusive sources that pay someone for working from the comfort of their home in their spare time.  These sources have been weeded out from the "FRAUDS," having stood the test of time (10 years), many being members of their local Better Business Bureaus and Business Associations.  We will rush the details to you.  All we ask is you cover the postage and handling ($4.), and if you're not 100% satisified with the details of this opportunity club program don't worry, not only will we refund the postage and handling ($4.), but we'll "cut you a check" for DOUBLE the postage and handling!  No one offers that!  We're so confident that this proven  program could change your life, we'll include a copy of our own bank statement proving an INCREDIBLE!
 8,241.87 was earned in just one month!  We'll even drop ship this amazing program risk free.  No inventory is necessary; all you do is advertise!  This is a complete turn-key opportunity, and you'll be SHOCKED and AMAZED at how you can be up and running the same day!  
SPECIAL BONUS:  Marketing "The Home Employment Opportunity Manual."  If you never sold anything before don't worry, this explosive section will show you how to market using classified ads, internet, direct sales, telemarketing, etc.  See how the pro's do it!  LISTEN TO THIS:  The first fifty (50) members only (no exceptions) will receive a bonus "The #1 Wealth-Building System in America."  HURRY, and your details will be shipped immediately.

OPTION: we highly  recommend that you order this explosive money makeing manual for $38.99(reg.59.99).this way you  have it in your hands and can make more of an educated decision+s&h is FREE$5.saveings. were  so confident you have a full 60 days GUARANTEE....%100 satifaction to look this over,ORDER NOW,,$8,241.87 in just one month!         
        Write to:  C. S. C.
                       266 Elmwood Avenue, Unit 172 - (Dept. H. E.M.)
                       Buffalo, New York 14222
                                (Incl. $4. S & H)

                    " IT,S  JUST  INCREDIABLE "
                                                                                   
                                                                                                                                                     
***this e-mail was sent to a priviledged list of people who have authorized it by submitting a request or filling out a registration, which you provided your e-mail address.thanks!!!!







From list@netscape.com  Wed Sep 20 12:15: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 SMTP id MAA26033
	for ; Wed, 20 Sep 2000 12:15: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 e8KG3UX02806;
	Wed, 20 Sep 2000 09:03:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8KGE7Q20785;
	Wed, 20 Sep 2000 09:14:07 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 09:14:07 -0700 (PDT)
Mime-Version: 1.0
X-Sender: webwide@box.clubnet.tin.it (Unverified)
Message-Id: 
Date: Wed, 20 Sep 2000 18:03:49 +0200
To: giovsozz@tin.it
From: WebWide 
Subject: Notice to Rolex owners only
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Resent-Message-ID: <"AiU2Z.A.-DF.NJOy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Sir/Madam
We apologize for the intrusion, but please mind that's a one time e-mail.

Do you know where in internet find out exhaustive tecnical info and
beautiful photos about your precious Submarine,
Paul Newman Daytona, Prince Brancard, Milgauss even GMT Master?
(All the Rolex models and references from the early times to the
present series)

We do
and if you confirm us your interest simply replaying to this e-mail,
we can tell you where in the web.

No hidden targets - only a internet address.

Thanks for your time
Regards

Webwide one time news



From list@netscape.com  Wed Sep 20 13:09: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 SMTP id NAA27832
	for ; Wed, 20 Sep 2000 13:09: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 e8KH1fS10167;
	Wed, 20 Sep 2000 10:01:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8KH80g12218;
	Wed, 20 Sep 2000 10:08:00 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 10:08:00 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Wed, 20 Sep 2000 10:38:43 -0600
From: "Jim Sermersheim" 
To: 
Subject: zero-len RDNs
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_752D8904.54355D9B"
Resent-Message-ID: <"9E_Mt.A.v7C.o7Oy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_752D8904.54355D9B
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hey all.

Recently I've encountered a problem where someone was able to add an entry =
with a zero length RDN, and then was not able to read the entry back. For =
example, this entry was created:

dn: cn=3D,o=3Dbar

I'm trying to resolve which half of the problem is the real problem =
(allowing such an addition, or not being able to resolve the name) and =
have concluded that both X.501 and RFC 2253 allow you to create an entry =
with a zero length RDN.

Can anyone verify or dismiss this? It doesn't feel right, but I can't find =
anywhere in the spec's that disallow it.

Thanks.=20

Jim

--=_752D8904.54355D9B
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







Hey all.


 


Recently I've encountered a problem where someone was able to add an =
entry=20
with a zero length RDN, and then was not able to read the entry back. =
For=20
example, this entry was created:


 


dn: cn=3D,o=3Dbar


 


I'm trying to resolve which half of the problem is the real problem=20=

(allowing such an addition, or not being able to resolve the name) and =
have=20
concluded that both X.501 and RFC 2253 allow you to create an entry with a =
zero=20
length RDN.


 


Can anyone verify or dismiss this? It doesn't feel right, but I can't =
find=20
anywhere in the spec's that disallow it.


 


Thanks. 


 


Jim


--=_752D8904.54355D9B--



From list@netscape.com  Wed Sep 20 13:32: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 SMTP id NAA28491
	for ; Wed, 20 Sep 2000 13:32: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 e8KHKWX15804;
	Wed, 20 Sep 2000 10:20:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8KHV7Y26449;
	Wed, 20 Sep 2000 10:31:07 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 10:31:07 -0700 (PDT)
Sender: mwahl@netscape.com
Message-ID: <39C8F458.BA2275D4@sun.com>
Date: Wed, 20 Sep 2000 10:31:04 -0700
From: Mark Wahl 
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Sermersheim 
CC: ietf-ldapext@netscape.com
Subject: Re: zero-len RDNs
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"VcGKZD.A.2cG.aRPy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


If an attribute's syntax definition allows the representation which 
consists of zero bytes, then an empty string is a legal value for that 
attribute.

I don't think X.520 has a lower bound on the number of characters in 'name'
and the Directory String syntax.  

Mark



From list@netscape.com  Wed Sep 20 15:01: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 SMTP id PAA02172
	for ; Wed, 20 Sep 2000 15:01: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 e8KImYX01980;
	Wed, 20 Sep 2000 11:48:34 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8KIx9Y14551;
	Wed, 20 Sep 2000 11:59:09 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 11:59:09 -0700 (PDT)
Message-Id: <000f01c02334$b2c99200$2f56b381@udev.cdc.com>
From: "David Cahlander" 
To: "Mark Wahl" , "Jim Sermersheim" 
Cc: 
References:  <39C8F458.BA2275D4@sun.com>
Subject: Re: zero-len RDNs
Date: Wed, 20 Sep 2000 13:58:00 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"fBPgt.A.EjD.8jQy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Actually Directory String syntax is specified in X.520 Section 2:

5 Definition of selected attribute types

DirectoryString { INTEGER : maxSize } ::= CHOICE {
    teletexString        TeletexString (SIZE(1..maxSize)),
    printableString      PrintableString (SIZE(1..maxSize)),
    universalString      UniversalString (SIZE(1..maxSize)) }

which indicates that the attribute has a minimum length of 1 character.
---
David Cahlander David.A.Cahlander@syntegra.com 651-415-3171


----- Original Message -----
From: Mark Wahl 
Sent: Wednesday, September 20, 2000 12:31 PM
Subject: Re: zero-len RDNs
|
| I don't think X.520 has a lower bound on the number of characters in
'name'
| and the Directory String syntax.




From list@netscape.com  Wed Sep 20 20:00: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 SMTP id UAA11477
	for ; Wed, 20 Sep 2000 20:00: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 e8KNpvo02704;
	Wed, 20 Sep 2000 16:51:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8KNwJg13492;
	Wed, 20 Sep 2000 16:58:19 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 16:58:19 -0700 (PDT)
Message-ID: <11981F9F5649D411BC92009027D0D18C01319647@aspams01.cai.com>
From: "Ramsay, Ron" 
To: Jim Sermersheim , ietf-ldapext@netscape.com
Subject: RE: zero-len RDNs
Date: Thu, 21 Sep 2000 10:57:21 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"UxDlRC.A.iSD.Y8Uy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Jim,
 
Considering only cn=, X.520(1993) defines DirectoryString as
 
DirectoryString { INTEGER:maxSize } ::= CHOICE {
    teletexString         TeletexString (SIZE(1..maxSize)),
    printableString      PrintableString (SIZE(1..maxSize)),
    universalString     UniversalString (SIZE(1..maxSize)) }
 
The definition has changed over time but I doubt that the constraints have
been dropped. Therefore, a commonName value must have at least one character
(of the character set).
 
Ron.

-----Original Message-----
From: Jim Sermersheim [mailto:JIMSE@novell.com]
Sent: Thursday, 21 September 2000 3:39
To: ietf-ldapext@netscape.com
Subject: zero-len RDNs


Hey all.
 
Recently I've encountered a problem where someone was able to add an entry
with a zero length RDN, and then was not able to read the entry back. For
example, this entry was created:
 
dn: cn=,o=bar
 
I'm trying to resolve which half of the problem is the real problem
(allowing such an addition, or not being able to resolve the name) and have
concluded that both X.501 and RFC 2253 allow you to create an entry with a
zero length RDN.
 
Can anyone verify or dismiss this? It doesn't feel right, but I can't find
anywhere in the spec's that disallow it.
 
Thanks. 
 
Jim



From list@netscape.com  Wed Sep 20 21:35: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 SMTP id VAA13554
	for ; Wed, 20 Sep 2000 21:35: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 e8L1NHi03078;
	Wed, 20 Sep 2000 18:23:17 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8L1Xso25720;
	Wed, 20 Sep 2000 18:33:54 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 18:33:54 -0700 (PDT)
Message-Id: <200009210133.e8L1Xf305986@ywing.netscape.com>
From: "princess28677@yahoo.com" 
To: 
Subject: phone rates
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 20 Sep 2000 21:33:09
Resent-Message-ID: <"ZA_FYB.A.QRG.-VWy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

I am looking for new customers who would like to save money on long distance phone calls?
Heres the deal Excel Communications is the fastest growing Long Distance Company in the United States.
We offer some of the most competitive Rates in the industry. Our state to state rates are  priced as low as three ceants per minute.
for complete details, Go to                       
                                                   www.excelir.com\mrexcel

Need a pager? Excel offers free pagers and no activation fees for new or existing long distance customers. Mounthly fees are 9.95


                                                   www.excelir.com\mrexcel


IF  THIS EMAIL IS AN ERROR AND UR NOT ON OUR LIST JUST EMAIL US BACK AND WE WILL TAKE U OFF. SORRY FOR THE 
INCOVIENCE.




                 SINCERELY
                    B.J MOOSE



From list@netscape.com  Wed Sep 20 21:40: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 SMTP id VAA13627
	for ; Wed, 20 Sep 2000 21:40: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 e8L1Rpi03812;
	Wed, 20 Sep 2000 18:27:52 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8L1cTc27437;
	Wed, 20 Sep 2000 18:38:29 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 18:38:29 -0700 (PDT)
Message-ID: <11981F9F5649D411BC92009027D0D18C01319D12@aspams01.cai.com>
From: "Ramsay, Ron" 
To: Mark Wahl , Jim Sermersheim 
Cc: ietf-ldapext@netscape.com
Subject: RE: zero-len RDNs
Date: Thu, 21 Sep 2000 12:38:21 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"EEsvLC.A.bsG.UaWy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

The lower bound for directoryString is 1.

-----Original Message-----
From: Mark Wahl [mailto:Mark.Wahl@sun.com]
Sent: Thursday, 21 September 2000 4:31
To: Jim Sermersheim
Cc: ietf-ldapext@netscape.com
Subject: Re: zero-len RDNs



If an attribute's syntax definition allows the representation which 
consists of zero bytes, then an empty string is a legal value for that 
attribute.

I don't think X.520 has a lower bound on the number of characters in 'name'
and the Directory String syntax.  

Mark



From list@netscape.com  Thu Sep 21 00:19: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 SMTP id AAA16782
	for ; Thu, 21 Sep 2000 00:19: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 e8L47ni15715;
	Wed, 20 Sep 2000 21:07:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8L4IPo05474;
	Wed, 20 Sep 2000 21:18:25 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 21:18:25 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Wed, 20 Sep 2000 14:23:27 -0600
From: "Steve Sonntag" 
To: , ,
        "Jim Sermersheim" ,
        "Steve Sonntag" 
Cc: "Alan Clark" , "Steven Merrill" 
Subject: Re: LDAPUrl class in java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_5E06A3DA.80E18901"
Resent-Message-ID: <"H4fnsD.A.OVB.QwYy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_5E06A3DA.80E18901
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Greetings,

With respect to the LDAPUrl object:

It occurred to me that the intent in the draft is to throw
the exception MalformedURLException for a non LDAP scheme,
when constructing this object from a full URL string,
thus, an LDAPUrl object MUST contain only URLs with scheme ldap://

Some implementations allow such things as ldaps:// for ssl, etc.  It
seems useful to allow the application to get the scheme to allow for such
extensions to the implementation, or was the intent that a different =
object
represent other schemes even though the syntax is identical except
for the scheme name?

This also brings up another question.  Since the only kind of URL allowed
in the LDAPUrl object is a correctly formatted LDAP URL as defined
by RFC2255, then an application doing asynchronous search operations =
cannot
receive the complete URL list for or search continuation reference if the
URL list contains a non LDAP URL.  This is because the only way to get
the list is via the getURLs() method of the LDAPSearchResultReference.
Perhaps it should return the URLs as a string array, and let the applicatio=
n
turn them into LDAPUrl objects if desired. Then it would be the same as
the getReferrals() method of the LDAPResponse object, which does return =
the
URL list a string array.  (This is backwards to what I said in an earlier =
e-mail, but
now I see the need for Strings instead of LDAPUrls)


------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software



>>> "Steve Sonntag"  06-Sep-00 5:17:57 PM >>>


An application doing its own referral handling may need to make
decisions based on the scheme of URLs returned from search
continuation references or referrals.

Shouldn't the LDAPUrl object provide a method to retrieve
the URL scheme, viz. ldap, http, & etc.

-Steve

--=_5E06A3DA.80E18901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







Greetings,


 


With respect to the LDAPUrl object:


 


It occurred to me that the intent in the draft is =
to=20
throw


the exception MalformedURLException for a non LDAP scheme,


when constructing this object from a full URL string,


thus, an LDAPUrl object MUST contain only URLs with scheme ldap://

 


Some implementations allow such things as ldaps:// for ssl, etc. =
=20
It


seems useful to allow the application to get the scheme to allow =
for=20
such


extensions to the implementation, or was the intent that a =
different=20
object


represent other schemes even though the syntax is identical except

for the scheme name?


 


This also brings up another question.  Since the only kind of =
URL=20
allowed


in the LDAPUrl object is a correctly formatted LDAP URL as defined

by RFC2255, then an application doing asynchronous search operations=
=20
cannot


receive the complete URL list for or search continuation reference =
if=20
the


URL list contains a non LDAP URL.  This is because the only way =
to=20
get


the list is via the getURLs() method of the=20
LDAPSearchResultReference.


Perhaps it should return the URLs as a string array, and let the=20
application


turn them into LDAPUrl objects if desired. Then it would be the =
same=20
as


the getReferrals() method of the LDAPResponse object, which does =
return=20
the


URL list a string array.  (This is backwards to what I said in =
an=20
earlier e-mail, but


now I see the need for Strings instead of LDAPUrls)


 


 


------------------------
Steve Sonntag
Novell, Inc., the =
leading=20
provider of Net services software


 


 


 


>>> "Steve Sonntag" <VTAG@novell.com> 06-Sep-00 =
5:17:57 PM=20
>>>


 


An application doing its own referral handling may need to make


decisions based on the scheme of URLs returned from search


continuation references or referrals.


 


Shouldn't the LDAPUrl object provide a method to retrieve


the URL scheme, viz. ldap, http, & etc.


 


-Steve


--=_5E06A3DA.80E18901--



From list@netscape.com  Thu Sep 21 01:05: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 SMTP id BAA17443
	for ; Thu, 21 Sep 2000 01: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 e8L4uSo04111;
	Wed, 20 Sep 2000 21:56:28 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8L52o214085;
	Wed, 20 Sep 2000 22:02:50 -0700 (PDT)
Resent-Date: Wed, 20 Sep 2000 22:02:50 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Wed, 20 Sep 2000 14:50:29 -0600
From: "Steve Sonntag" 
To: , ,
        "Jim Sermersheim" 
Cc: "Alan Clark" , "Steven Merrill" 
Subject: LDAPUrl encode/decode in java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_F8A00543.67066EFE"
Resent-Message-ID: <"pWLuRD.A.hbD.4ZZy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_F8A00543.67066EFE
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable

I am trying to understand the encode/decode functions
in the LDAPUrl class.

I assume that the encode method turns unsafe characters
(as defined by RFC1738, RFC 2255, & etc.) into characters
of the form %HH and that decode turns those characters
back into the raw unencoded characters.

Question 1: The reference to decoding "+" into " "
and encoding " " into "+" .  I could not find any reference
to the need for doing this in the RFCs.  Could someone
please tell me why someone might expect that this behavior?

Question 2:  What kind of strings do the constructors of the
LDAPUrl class expect.  Do the constructors expect the=20
strings to be already encoded?

Question 3:  Does the encode method take into account the field
in the URL when doing the encoding (e.g. filters vs. base DN) which
may have different reserved characters and thus slightly different
encoding rules =AF which boils down to the real question - does=20
the encode function expect a full correctly formatted URL
or can one hand it just the base-DN, or just the filter and
expect it to be correctly encoded?

i.e., does the LDAPUrl constructor with individual parts expect=20
encoded strings and will the encode function do it?




------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software

--=_F8A00543.67066EFE
Content-Type: text/html; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable







I am trying to understand the encode/decode functions


in the LDAPUrl class.


 


I assume that the encode method turns unsafe characters


(as defined by RFC1738, RFC 2255, & etc.) into characters


of the form %HH and that decode turns those characters


back into the raw unencoded characters.


 


Question 1: The reference to decoding "+" into " "


and encoding " " into "+" .  I could not find any reference
=


to the need for doing this in the RFCs.  Could someone


please tell me why someone might expect that this behavior?


 


Question 2:  What kind of strings do the constructors of =
the


LDAPUrl class expect.  Do the constructors expect the 


strings to be already encoded?


 


Question 3:  Does the encode method take into account =
the=20
field


in the URL when doing the encoding (e.g. filters vs. base DN) =
which


may have different reserved characters and thus slightly different

encoding rules — which boils down to the real question - does =



the encode function expect a full correctly formatted URL


or can one hand it just the base-DN, or just the filter and


expect it to be correctly encoded?


 


i.e., does the LDAPUrl constructor with individual parts expect =



encoded strings and will the encode function do it?


 


 


 


 


------------------------
Steve Sonntag
Novell, Inc., the =
leading=20
provider of Net services software


 


 


--=_F8A00543.67066EFE--



From list@netscape.com  Thu Sep 21 04:14: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 SMTP id EAA01243
	for ; Thu, 21 Sep 2000 04:14: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 e8L86uo06092;
	Thu, 21 Sep 2000 01:06:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8L8DI229699;
	Thu, 21 Sep 2000 01:13:18 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 01:13:18 -0700 (PDT)
Date: Thu, 21 Sep 2000 01:13:05 -0700 (PDT)
Message-Id: <200009210813.e8L8D4108186@xwing.netscape.com>
To: gdfdgf@fdngfl.it.netscape.com
From: 
Subject: RETIRE IN 2-3 YEARS!!!
Resent-Message-ID: <"FhFyND.A.xPH.dMcy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Work Smarter ....Not Harder!!

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

I am searching for only 10 elite individuals with the work
 ethic necessary to generate a cash-flow for themselves of
 $2,000 - $5,000per 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, I 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 my 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-800-320-9895 Ext. 6131

We market a real product, that pays real commissions to you,
$1,000.00 per sale, just for making the initial contacts. 
With our turn-key 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-800-320-9895 Ext. 6131

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!

Please, serious inquiries only.




**********************************************************************
All REMOVE requests AUTOMATICALLY honored upon receipt.

PLEASE understand that any effort to disrupt, close or block this
 REMOVE account can only result in difficulties for others wanting
 to be removed from our mailing list as it will be impossible to take
 anyone off the list if the remove instruction can not be received.

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



From list@netscape.com  Thu Sep 21 04:37:18 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 SMTP id EAA01446
	for ; Thu, 21 Sep 2000 04:37:18 -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 e8L8PEi27044;
	Thu, 21 Sep 2000 01:25:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8L8Zps05058;
	Thu, 21 Sep 2000 01:35:51 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 01:35:51 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Thu, 21 Sep 2000 01:37:29 -0600
From: "Vijay Kn" 
To: , 
Subject: re: the LDAP client caching proxy model ...
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_F5AD08D7.73127EF8"
Resent-Message-ID: <"5FhO6.A.wOB.mhcy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_F5AD08D7.73127EF8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

> A general comment about the approach:

> The method described using special purpose controls and responses=20
> means that every ldap enabled program will need to be "cache=20
> enabled". IOW, they will not be to able to make use of the cache =
unless=20
> programmed to do so. Would it not be better to use some sort of flow=20
> through model where an ldap enabled program that is *not* "cache=20
> enabled" would attempt to bind to the local cache which would either =
use=20
> its cache or flow through to the "real" server? Then mobile users =
would=20
> only need one "cache enabled" program to easily add/remove things=20
> from the cache.

Good point. Support for a flow-through model is indeed desirable to =
transparently  support non "cache enabled" programs.  However, LDAP apps =
that bind to the local cache must at a minimum specify the real/remote =
server and port no. to the caching proxy.  LDAP apps can choose to support =
the proxyServerBindControl alone. This could even be integrated in the =
LDAP SDK so that it is transparent to apps using the LDAP SDK. The LDAP =
library/DLL could add the proxy control before sending it to the caching =
proxy.  Another option is to pass the remote server and port info. as part =
of the Bind DN when binding to the local cache but this makes it a =
non-standard solution.=20

> 3.1 proxyServierBind Controls:
> disconnectedMode

> Why ignore the serverPort field when in disconnected mode? This makes
> it impossible to differentiate between the LDAP servers when there are
> multiple servers running on the same serverName.

Agreed.=20

> 4.1 Caching logic...
> base search
> "Results returned to the client, however, will be based on the search
> filter specified."

> The filter only is used to determine which objects qualify. The
> attributes and typesOnly fields determine the results sent to the =
client.

Yes. It will be based on the attributes and typesOnly field.

> "The entire object shall be fetched and cached."

> What is the reason behind caching the whole object? The search
> request shows that the only the attributes named in the filter and
> attributes fields are of interest... If this is intended, then put * in =
the
> attributes field. If the object is large over a slow (dialup?) link this
> could be painful.

If we attempt caching a partial object, it may violate schema rules wrt =
mandatory attributes, since the caching proxy itself would include an LDAP =
server and enforce schema.=20

The caching proxy aims at working transparently with existing applications =
and use base searches as a hint to cache objects. We could say that the =
caching proxy will use the attribute filter to access the object from the =
remote server and cache the object only if all mandatory attributes are =
requested. However, while this would address the slow link scenario, we =
lose the caching benefit.=20

> 5. Authentication and access control...

> Access control and authentication in a discretionary access control=20
> system such as LDAP (in the current ID) only control how the information =
is
> released or modified in the system. It does not control what can be done
> with it. IOW, once you have read information, LDAP does not control or
> dictate how you will use it or where you will store it. If the
> administrator does not trust you to treat the information appropriately =
(as
> he defines it), he should not give you access.

RFC 2251 does recommend how you should store the retrieved information. =
Please take a look at this last paragraph from the Security Considerations =
section of RFC 2251. =20

  "Implementations which cache attributes and entries obtained via LDAP
   MUST ensure that access controls are maintained if that information
   is to be provided to multiple clients, since servers may have access
   control policies which prevent the return of entries or attributes in
   search results except to particular authenticated clients.  For
   example, caches could serve result information only to the client
   whose request caused it to be cache."

> Having said that, I agree that the cached objects should be protected =
(if
> possible). I am very concerned that you seem to be storing the =
identity=20
> and keys to access the directories in the proxy server (so that the =
user=20
> can be authenticated in disconnected operations). If the mobile =
system=20
> falls into the wrong hands, all objects accessible by those identities/ke=
ys=20
> are vulnerable. If you don't store the identities and keys, then only =
the
> objects in the cache are exposed. I would rather deal with the later and
> restrict what I cache, than deal with the former.

Again, it is important to authenticate the user in offline mode before =
allowing access to cached content. With secure authentication methods like =
Message Digest and Certificate authentication, the stored info. pose =
little risk since they cannot be used to authenticate to the remote =
directory. For  simple,  password based authentication, the caching proxy =
will store a one-way hash to verify the password - but not store the =
actual password itself (as discussed in ) .

Vijay

--=_F5AD08D7.73127EF8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







> A general comment about the approach:
=


 


> The method described using special purpose =
controls and=20
responses 


> means that every ldap enabled program will =
need to=20
be "cache 


> enabled". IOW, they will not be to able to =
make use=20
of the cache unless 


> programmed to do so. Would it not be better =
to use=20
some sort of flow 


> through model where an ldap enabled program =
that is=20
*not* "cache 


> enabled" would attempt to bind to the local =
cache=20
which would either use 


> its cache or flow through to the "real" serve=
r? Then=20
mobile users would 


> only need one "cache enabled" program to easi=
ly=20
add/remove things 


> from the cache.


 


Good point. Support for a flow-through model is =
indeed=20
desirable to transparently  support non "cache enabled"=20
programs.  However, LDAP apps that bind to the local cache =
must=20
at a minimum specify the real/remote server and port no. to =
the=20
caching proxy.  LDAP apps can choose to support the=20
proxyServerBindControl alone. This could even be integrated in the =
LDAP SDK=20
so that it is transparent to apps using the LDAP SDK. The LDAP library/DLL =
could=20
add the proxy control before sending it to the caching proxy.  =
Another=20
option is to pass the remote server and port info. as part of the =
Bind DN=20
when binding to the local cache but this makes it a non-standard =
solution.=20




> 3.1 proxyServierBind Controls:
>=20
disconnectedMode


 


> Why ignore the serverPort field when in disconnect=
ed=20
mode? This makes
> it impossible to differentiate between the LDAP =
servers=20
when there are
> multiple servers running on the same=20
serverName.


 


Agreed. 


 


> 4.1 Caching logic...
> base search
> =
"Results=20
returned to the client, however, will be based on the search
> =
filter=20
specified."


 


> The filter only is used to determine which =
objects=20
qualify. The
> attributes and typesOnly fields determine the results =
sent=20
to the client.


 


Yes. It will be based on the attributes and =
typesOnly=20
field.


 


> "The entire object shall be fetched and=20
cached."


 


> What is the reason behind caching the whole =
object? The=20
search
> request shows that the only the attributes named in the =
filter=20
and
> attributes fields are of interest... If this is intended, then =
put *=20
in the
> attributes field. If the object is large over a slow =
(dialup?)=20
link this
> could be painful.


 


If we attempt caching a partial object, it may violate =
schema=20
rules wrt mandatory attributes, since the caching proxy itself would=20
include an LDAP server and enforce schema. 


 


The caching proxy aims at working transparently with =
existing=20
applications and use base searches as a hint to cache objects. We could =
say that=20
the caching proxy will use the attribute filter to access the object from =
the=20
remote server and cache the object only if all mandatory attributes are=20
requested. However, while this would address the slow link scenario, we =
lose the=20
caching benefit. 


 


> 5. Authentication and access control...

 


> Access control and authentication in a discretiona=
ry=20
access control 


> system such as LDAP (in the current ID) only =
control=20
how the information is


> released or modified in the system. It does not =
control=20
what can be done
> with it. IOW, once you have read information, =
LDAP does=20
not control or
> dictate how you will use it or where you will store =
it.=20
If the
> administrator does not trust you to treat the information=20=

appropriately (as
> he defines it), he should not give you=20
access.


 


RFC 2251 does recommend how you should store =
the=20
retrieved information. Please take a look at this last paragraph from =
the=20
Security Considerations section of RFC 2251.  


 


  "Implementations which cache attributes =
and=20
entries obtained via LDAP
   MUST ensure that access controls =
are=20
maintained if that information
   is to be provided to =
multiple=20
clients, since servers may have access
   control policies =
which=20
prevent the return of entries or attributes in
   search =
results=20
except to particular authenticated clients.  For
   =
example,=20
caches could serve result information only to the client
   =
whose=20
request caused it to be cache."


 


> Having said that, I agree that the cached =
objects=20
should be protected (if
> possible). I am very concerned that you =
seem to=20
be storing the identity 


> and keys to access the directories in the =
proxy=20
server (so that the user 


> can be authenticated in disconnected operations). =
If the=20
mobile system 


> falls into the wrong hands, all objects =
accessible=20
by those identities/keys 


> are vulnerable. If you don't store the =
identities=20
and keys, then only the


> objects in the cache are exposed. I would =
rather=20
deal with the later and
> restrict what I cache, than deal with =
the=20
former.


Again, it is important to authenticate the user in =
offline=20
mode before allowing access to cached content. With secure authentication=
=20
methods like Message Digest and Certificate authentication, the stored =
info.=20
pose little risk since they cannot be used to authenticate to the =
remote=20
directory. For  simple,  password based authentication, =
the=20
caching proxy will store a one-way hash to verify the password - but not =
store=20
the actual password itself (as discussed=20
in <draft-zeilenga-ldap-authpasswd-03.txt>) .


 


Vijay


--=_F5AD08D7.73127EF8--



From list@netscape.com  Thu Sep 21 10:38:55 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 SMTP id KAA06541
	for ; Thu, 21 Sep 2000 10:38: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 e8LEQ0i28936;
	Thu, 21 Sep 2000 07:26:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LEab208389;
	Thu, 21 Sep 2000 07:36:37 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 07:36:37 -0700 (PDT)
Date: Thu, 21 Sep 2000 07:34:11 -0700 (PDT)
Message-Id: <200009211434.HAA03013@www.ectrade.com>
From: ectrade@email.com.cn
To: ietf-ldapext@netscape.com
Subject: ECTrade.com BBS Has 200 Trade Leads Updated Everyday!
Resent-Message-ID: <"ymHtFB.A.zCC.zzhy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Dear Sir/Madamn,

     
     ********************************************
     This is not spam. You have at one point 
     requested information on Internet business 
     opportunities. However if you do wish to be 
     removed permanently from this list simply 
     click the link at the bottom of the email. 
     ********************************************



ECTrade.com--200 Trade Leads Updated Everyday!
             
You will find 100,000 trade leads here in 
ECTrade that are posted by business men all 
over the world especially from China; Company
and product databank; Effective web promoting
tools etc....

All is free !  

http://www.ectrade.com


1.Post an Offer(BBS)
  ~~~~~~~~~~~~~~~~~~~
  advertise your offer to buy, sell, ...
  http://bbs.ectrade.com
  
2.Cross-posting Robot
  ~~~~~~~~~~~~~~~~~~~~
  posts your ads to more than 50 most famous
  BBS in the   world;

3.Add your site
  ~~~~~~~~~~~~~
  drives traffic to your website; 

4.Showroom
  ~~~~~~~~
  set up your own product homepage;
  http://product.ectrade.com
  
5.Global Search 
  ~~~~~~~~~~~~~~
  search among millions of trade leads from
  the world''s largest eight BBSs.

6.Biz Logbook
  ~~~~~~~~~~~
  A list of all your promotion job done in 
  ECTrade and your visitor''s clicks and references;

7.Mailing list
  ~~~~~~~~~~~~
  helps you to sent emails to your own email list;

8.Online Address book and Bookmarks;
  ~~~~~~~~~~~~~~~~~~~     ~~~~~~~~~   

9.Biz Weekly, 
  ~~~~~~~~~~~
  after subscribing, you will receive the trade 
  leads of your line every week in you email box;

10.Information on international Exhibitions and Fairs
   to be held in China.

11.China Business News
   ~~~~~~~~~~~~~~~~~~~

12."EC-Life",
   ~~~~~~~~~~
   Welcome to post your ideas about the business life 
   and Hope we can meet here someday;  

...

COME AND JOIN US!!!!     http://www.ectrade.com

   
Best Regards,
   

Lulia


~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
ECTrade.com
http://www.ectrade.com
ectrade@email.com.cn
~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~

=====================================================
We apologize if this letter causes your inconvenience. 
If you do not want to receive emails again from us, please simply click or go to the following Url: 
http://www.ectrade.com/bin/admin/maillist/add_del.pl?language=en&email=ietf-ldapext@netscape.com
to remove your email from our list.



From list@netscape.com  Thu Sep 21 11:37: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 SMTP id LAA08072
	for ; Thu, 21 Sep 2000 11:37: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 e8LFULo25159;
	Thu, 21 Sep 2000 08:30:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LFagY03672;
	Thu, 21 Sep 2000 08:36:42 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 08:36:42 -0700 (PDT)
From: hahnt@us.ibm.com
X-Priority: 3 (Normal)
Importance: Normal
To: ietf-ldapext@netscape.com
Subject: comments on draft-ietf-ldapext-ldap-java-api-11.txt
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: 
Date: Thu, 21 Sep 2000 11:36:36 -0400
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August
 28, 2000) at 09/21/2000 11:36:37 AM,
	Serialize complete at 09/21/2000 11:36:37 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00559B6E85256961_="
Resent-Message-ID: <"7DCga.A.G5.Jsiy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multipart message in MIME format.
--=_alternative 00559B6E85256961_=
Content-Type: text/plain; charset="us-ascii"

Greetings,


I finally got around to reading this draft.  It looks great so far.  I've 
summarized my comments here:

Section 4.3.5:
--------------
"cn;lang-ja-JP-kanji" may be a subtype of "cn;lang-ja" - based on recent 
discussions on this list, I don't think that this is true.  It seems to me 
that "cn;lang-ja-JP-kanji" is really treated as a subtype of "cn".

similarly, I think the example in this section need fixing as well:

getAttribute( "cn", "lang-en-us" ); does NOT return "cn;lang-en"

getAttribute( "sn", "lang-en" ); does NOT return "sn"

formating for description of "attrName" should be fixed.

Section 4.3.8:
--------------
Are attribute descriptions and attribute subtypes accounted for in this? 
For example, will a:

attrSet.remove("name");

call result in all "cn", "sn", "cn;lang-us" attributes being removed from 
the LDAPAttributeSet?

Section 4.5.1:
--------------
Are alternative attribute type names, attribute subtypes, and attribute 
descriptions accounted for in this comparison implemenatation?

Section 4.5.4:
--------------
If an entry does not contain an attribute, is it considered greater than 
or less than an entry that does contain the attribute?

Section 4.6.4:
--------------
If the authentication method does not have an associated distinguished 
name, does this method return null?  An exception?

Section 4.6.17, 4.6.18:
-----------------------
Is a bind() done as well?  If so, what method is used?  Is this controlled 
by the LDAPSearchConstraints object that is passed in?

Section 4.7.1:
--------------
Maybe this was covered in previous discussions on this list.  It is not 
clear from the draft, however, what the subtle differences are between a 
LDAPBind and LDAPRebind class and where these differences are used.

Section 4.7.8:
--------------
A clarification: If the bind proc is null (the default), then no 
authentication is done on the initial connection.

Section 4.11.1:
---------------
"after appropriate normalization".  Doesn't this imply that the CLIENT 
have full knowledge of the "active" schema?  More clarification as to the 
extent of normalization that will be done is needed here.  Full DN 
handling is actually quite complex.  If that is what is intended here, 
then it needs to be made clear.  Further, this could require some form of 
communication with an LDAP server to get a set of "schema" with which to 
work with.

Section 4.11.4, 4.11.5:
-----------------------
Will the values returned be appropriately escaped or un-escaped based on 
the escaping rules in RFC 2253?

Section 4.12.4 (and many others, including all of 4.29, 4.38, 4.39, 4.40):
--------------------------------------------------------------------------
Why is a "String dn" returned/passed in and not a LDAPDN when a 
distinguished name is to be used?

Section 4.16.5:
---------------
Are the constants referred to here for result codes defined as static 
constants anywhere?  I did not see them defined as such anywhere in this 
draft.  This could possibly be done in LDAPException as:

class LDAPException {
...
public static final int NO_SUCH_OBJECT = 1;
...
}

Section 4.21:
-------------
Since this set of modifications is ordered, should it be called 
LDAPModificationList instead?

Section 4.21.2:
---------------
A clarification.  Since the list is ordered, add() should clarify that it 
adds at the END of the list.

Section 4.21.4:
---------------
This is similar to the comment above on Section 4.3.8, are subtypes, 
attribute descriptions, and alternate attribute type names accounted for 
here?

Section 4.24 and 4.25:
----------------------
The setup of LDAPRebindAuth and LDAPRebind seem only to support the notion 
of "simple" authentication.  How are other authentication methods to be 
setup and used when following referrals?

Section 4.26.1:
---------------
Clarification: the full response is received prior to throwing the 
referral exception, correct?

Section 4.29.11:
----------------
"of attribute definitions" should be "of LDAPAttributeSchema definitions".

Section 4.29.12:
----------------
"of attribute definitions" should be "of LDAPObjectClassSchema 
definitions".

Section 4.29.13:
----------------
"of attribute definitions" should be "of LDAPMatchingRuleSchema 
definitions".

Section 4.29.20-25:
-------------------
clarification: the returned Enumeration is an Enumeration of Strings, 
correct?

Section 4.30.1-3:
-----------------
I would prefer that these methods NOT be defined in the abstract base 
class.  They don't make sense for some derived classes.  This was alluded 
to later in the document (Section 4.37).

Section 4.30.6:
---------------
clarification: the returned Enumeration is an Enumeration of Strings, 
correct?

Section 4.30.10,11,12:
----------------------
These should clarify what LDAP operations are being performed.  I think 
that 4.30.10 is an LDAP MODIFY where a new attribute value is added to the 
existing attributetypes, objectclasses, ldapsyntaxes, or matchingrules 
attribute in the subschemasubentry, 4.30.11 is a LDAP MODIFY operation to 
delete a specific attribute value, and 4.30.12 is an LDAP MODIFY with a 
"delete value" + "add value" in the ModificationSet/List.  This should be 
described in these sections.

Section 4.30.12:
----------------
Also in this section, the value from "this.getValue()" is used as the 
"attribute value to delete", correct?

Section 4.31.1:
---------------
Why is doReferrals set to "false" by default?

non-SIMPLE re-bind authentication seems to need more thought, in general. 
Is anybody working on this?

Is hop_limit set to zero by default?  Does zero imply no limit?

Section 4.31.3:
---------------
LDAP_DEREF_NEVER  should be LDAPConnection.DEREF_NEVER
LDAP_DEREF_FINDING should be LDAPConnection.DEREF_FINDING
LDAP_DEREF_SEARCHING should be LDAPConnection.DEREF_SEARCHING
LDAP_DEREF_ALWAYS should be LDAPConnection.DEREF_ALWAYS

Section 4.32.1:
---------------
What is meant by "outstanding requests"?  Is this the set of responses 
that have not yet been completely received from the remote server?  Or the 
set of responses that have not been "received" by the application?  Or 
both?

Section 4.32.3:
---------------
Would it be useful to have a "isReponseReceived( int msgid )" method as 
well?

How about an "isComplete( int msgid )"?

Section 4.35.5:
---------------
"This the" should be "This is the"

"or an LDAPReferralException." should be "or an LDAPReferralException is 
thrown."

Should there be a way to get the referrals FIRST (i.e. not at the end as 
an exception), so that other searches can be started in the background? 
This would allow multiple outstanding searches to multiple servers to run 
in parallel instead of serializing referrals chasing.

Section 4.38.1:
---------------
attrNames description, "null for all attributes".  Should this be "null or 
a single value of "*" for all attributes".

Section 4.39.13:
----------------
Description of LDAPConnection.REFERRALS_HOP_LIMIT.  Change "no more than 5 
referrals in a row" to "no more than 5 nested referrals."

Section 4.40.1:
---------------
Will the client send off abandon requests for all outstanding (but 
incomplete) operations if a bind() is invoked?

Thanks,
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
--=_alternative 00559B6E85256961_=
Content-Type: text/html; charset="us-ascii"



Greetings,





I finally got around to reading this draft.  It looks great so far.  I've summarized my comments here:



Section 4.3.5:

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

"cn;lang-ja-JP-kanji" may be a subtype of "cn;lang-ja" - based on recent discussions on this list, I don't think that this is true.  It seems to me that "cn;lang-ja-JP-kanji" is really treated as a subtype of "cn".



similarly, I think the example in this section need fixing as well:



getAttribute( "cn", "lang-en-us" ); does NOT return "cn;lang-en"



getAttribute( "sn", "lang-en" ); does NOT return "sn"



formating for description of "attrName" should be fixed.



Section 4.3.8:

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

Are attribute descriptions and attribute subtypes accounted for in this?  For example, will a:



attrSet.remove("name");



call result in all "cn", "sn", "cn;lang-us" attributes being removed from the LDAPAttributeSet?



Section 4.5.1:

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

Are alternative attribute type names, attribute subtypes, and attribute descriptions accounted for in this comparison implemenatation?



Section 4.5.4:

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

If an entry does not contain an attribute, is it considered greater than or less than an entry that does contain the attribute?



Section 4.6.4:

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

If the authentication method does not have an associated distinguished name, does this method return null?  An exception?



Section 4.6.17, 4.6.18:

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

Is a bind() done as well?  If so, what method is used?  Is this controlled by the LDAPSearchConstraints object that is passed in?



Section 4.7.1:

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

Maybe this was covered in previous discussions on this list.  It is not clear from the draft, however, what the subtle differences are between a LDAPBind and LDAPRebind class and where these differences are used.



Section 4.7.8:

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

A clarification: If the bind proc is null (the default), then no authentication is done on the initial connection.



Section 4.11.1:

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

"after appropriate normalization".  Doesn't this imply that the CLIENT have full knowledge of the "active" schema?  More clarification as to the extent of normalization that will be done is needed here.  Full DN handling is actually quite complex.  If that is what is intended here, then it needs to be made clear.  Further, this could require some form of communication with an LDAP server to get a set of "schema" with which to work with.



Section 4.11.4, 4.11.5:

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

Will the values returned be appropriately escaped or un-escaped based on the escaping rules in RFC 2253?



Section 4.12.4 (and many others, including all of 4.29, 4.38, 4.39, 4.40):

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

Why is a "String dn" returned/passed in and not a LDAPDN when a distinguished name is to be used?



Section 4.16.5:

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

Are the constants referred to here for result codes defined as static constants anywhere?  I did not see them defined as such anywhere in this draft.  This could possibly be done in LDAPException as:



class LDAPException {

...

public static final int NO_SUCH_OBJECT = 1;

...

}



Section 4.21:

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

Since this set of modifications is ordered, should it be called LDAPModificationList instead?



Section 4.21.2:

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

A clarification.  Since the list is ordered, add() should clarify that it adds at the END of the list.



Section 4.21.4:

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

This is similar to the comment above on Section 4.3.8, are subtypes, attribute descriptions, and alternate attribute type names accounted for here?



Section 4.24 and 4.25:

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

The setup of LDAPRebindAuth and LDAPRebind seem only to support the notion of "simple" authentication.  How are other authentication methods to be setup and used when following referrals?



Section 4.26.1:

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

Clarification: the full response is received prior to throwing the referral exception, correct?



Section 4.29.11:

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

"of attribute definitions" should be "of LDAPAttributeSchema definitions".



Section 4.29.12:

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

"of attribute definitions" should be "of LDAPObjectClassSchema definitions".



Section 4.29.13:

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

"of attribute definitions" should be "of LDAPMatchingRuleSchema definitions".



Section 4.29.20-25:

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

clarification: the returned Enumeration is an Enumeration of Strings, correct?



Section 4.30.1-3:

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

I would prefer that these methods NOT be defined in the abstract base class.  They don't make sense for some derived classes.  This was alluded to later in the document (Section 4.37).



Section 4.30.6:

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

clarification: the returned Enumeration is an Enumeration of Strings, correct?



Section 4.30.10,11,12:

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

These should clarify what LDAP operations are being performed.  I think that 4.30.10 is an LDAP MODIFY where a new attribute value is added to the existing attributetypes, objectclasses, ldapsyntaxes, or matchingrules attribute in the subschemasubentry, 4.30.11 is a LDAP MODIFY operation to delete a specific attribute value, and 4.30.12 is an LDAP MODIFY with a "delete value" + "add value" in the ModificationSet/List.  This should be described in these sections.



Section 4.30.12:

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

Also in this section, the value from "this.getValue()" is used as the "attribute value to delete", correct?



Section 4.31.1:

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

Why is doReferrals set to "false" by default?



non-SIMPLE re-bind authentication seems to need more thought, in general.  Is anybody working on this?



Is hop_limit set to zero by default?  Does zero imply no limit?



Section 4.31.3:

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

LDAP_DEREF_NEVER  should be LDAPConnection.DEREF_NEVER

LDAP_DEREF_FINDING should be LDAPConnection.DEREF_FINDING

LDAP_DEREF_SEARCHING should be LDAPConnection.DEREF_SEARCHING

LDAP_DEREF_ALWAYS should be LDAPConnection.DEREF_ALWAYS



Section 4.32.1:

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

What is meant by "outstanding requests"?  Is this the set of responses that have not yet been completely received from the remote server?  Or the set of responses that have not been "received" by the application?  Or both?



Section 4.32.3:

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

Would it be useful to have a "isReponseReceived( int msgid )" method as well?



How about an "isComplete( int msgid )"?



Section 4.35.5:

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

"This the" should be "This is the"



"or an LDAPReferralException." should be "or an LDAPReferralException is thrown."



Should there be a way to get the referrals FIRST (i.e. not at the end as an exception), so that other searches can be started in the background?  This would allow multiple outstanding searches to multiple servers to run in parallel instead of serializing referrals chasing.



Section 4.38.1:

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

attrNames description, "null for all attributes".  Should this be "null or a single value of "*" for all attributes".



Section 4.39.13:

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

Description of LDAPConnection.REFERRALS_HOP_LIMIT.  Change "no more than 5 referrals in a row" to "no more than 5 nested referrals."



Section 4.40.1:

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

Will the client send off abandon requests for all outstanding (but incomplete) operations if a bind() is invoked?



Thanks,

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
--=_alternative 00559B6E85256961_=--



From list@netscape.com  Thu Sep 21 12: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 SMTP id MAA08906
	for ; Thu, 21 Sep 2000 12:06:18 -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 e8LFsHi10158;
	Thu, 21 Sep 2000 08:54:17 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LG4sM19497;
	Thu, 21 Sep 2000 09:04:54 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 09:04:54 -0700 (PDT)
Message-Id: <5.0.0.25.0.20000921085608.00a5dc10@router.boolean.net>
X-Sender: guru@router.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 21 Sep 2000 09:03:32 -0700
To: hahnt@us.ibm.com
From: "Kurt D. Zeilenga" 
Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt
Cc: ietf-ldapext@netscape.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"5vsTFD.A.juE.iGjy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:36 AM 9/21/00 -0400, hahnt@us.ibm.com wrote:
>Section 4.3.5: 
>-------------- 
>"cn;lang-ja-JP-kanji" may be a subtype of "cn;lang-ja" - based on recent discussions on this list,

Language tags have no structure, "cn;lang-ja" and "cn;lang-ja-JP-kanji"
are siblings of "cn" attribute type.

> I don't think that this is true.  It seems to me that "cn;lang-ja-JP-kanji" is really treated as a subtype of "cn". 

Correct.  I think the latest lang tag discussion is more whether
"cn;lang-ja;lang-ja-JP-kanji" is treated as a direct subtype of "cn"
or is treaded as subtypes of both "cn;lang-ja" and "cn;lang-ja-JP-kanji"
(which are subtypes of "cn").



From list@netscape.com  Thu Sep 21 12:53: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 SMTP id MAA09897
	for ; Thu, 21 Sep 2000 12: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 e8LGeXi17243;
	Thu, 21 Sep 2000 09:40:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LGpAM18850;
	Thu, 21 Sep 2000 09:51:10 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 09:51:10 -0700 (PDT)
From: "David Chadwick" 
Organization: University of Salford
To: "Jim Sermersheim" , ,
        
Date: Thu, 21 Sep 2000 17:50:41 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Feature discovery (Was: RFC 2596 questions)
Reply-to: d.w.chadwick@salford.ac.uk
Message-ID: <39CA4A71.32621.662AB2D@localhost>
Priority: normal
In-reply-to: 
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"4VcsSC.A.0lE.9xjy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

Date forwarded: 	Fri, 15 Sep 2000 14:30:17 -0700 (PDT)
Date sent:      	Fri, 15 Sep 2000 15:28:50 -0600
From:           	"Jim Sermersheim" 
To:             	, 
Subject:        	Re: Feature discovery (Was: RFC 2596 questions)
Forwarded by:   	ietf-ldapext@netscape.com

> You mean advertised in the schema, right? I would say yes, I think
> there should be another schema element called something like
> attributeTypeOptions, the syntax would look something like this (ala
> 2252 nomenclature):

Jim

The only problem with your approach below is that you are 
effectively defining a whole new set of attribute subtypes, without 
assigning OIDs to the subtypes. Although it is more longwinded, I 
would prefer an approach where every subtype was specified in its 
own right as an attribute type, and had its own OID allocated to it.

By way of example, taking cn;lang-fr as a subtype of common name 
 we should be able to define 

( x.y.z NAME 'frenchname' SUP cn )
-- all values to be in French

or (x.y.z NAME 'cn;lang-fr' EQUALITY caseIgnoreMatch
      SUBSTR caseIgnoreSubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

or even (x.y.z NAME 'cn;lang-fr' SUP cn)

These should all be equivalent and allowed. This would necessitate 
a change to the BNF to allow ;options to be included in attribute 
types.

A user can then request French common names by either asking for 
the frenchname attribute or the cn;lang-fr attribute values.

David


> 
> AttributeTypeOptionDescription = "(
>    numericoid whsp ; Attribute Type Option Identifier
>    [ "NAME" qdescrs ]
>    [ "DESC" qdescrs ]
>    [ "OBSOLETE" whsp ]
>    "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") oids) ; list of
>    syntaxes or attributes that this ATO applies to. whsp ")"
> 
> 
> Jim
> 
> 
> >>>  9/15/00 2:58:18 PM >>>
> Jim wrote:
> Whatever the discovery mech is, I'd rather we have it and be  rarely
> used than not have it at all. Also, some things (like attr type
> options)  need more than just an OID in a list. We need to specify
> where they can be used (which attrs or syntaxes support them).
> 
> Doesn't this imply then that support of the attribute tags should be
> discovered as part of schema discovery?
> 
> Karen
> 
> Internet: kgdaniec@us.ibm.com
> Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
>                  IBMUSM10(KGDANIEC)
> phone: 607.752.1075   tie-line: 8/852-1075
> fax: 607.752.3681
> ---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on
> 09/15/2000 04:57 PM ---------------------------
> 
> "Jim Sermersheim"  on 09/15/2000 04:33:17 PM
> 
> To:   , Timothy Hahn/Endicott/IBM@IBMUS
> cc:   
> Subject:  Re: Feature discovery (Was: RFC 2596 questions)
> 
> 
> 
> 
> Whatever the discovery mech is, I'd rather we have it and be  rarely
> used than not have it at all. Also, some things (like attr type
> options)  need more than just an OID in a list. We need to specify
> where they can be used (which attrs or syntaxes support them).
> 
> Jim
> 
> 
> >>> "Kurt D. Zeilenga"  9/15/00  2:01:22 PM >>>
> At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com  wrote:
> >Should we investigate some additional rootDSE attribute to  indicate
> >the
> set of attribute descriptions that are supported?  Further,  when a
> new attribute description is defined, should we be assigning OIDs and 
> keeping these as an additional part of the subschemasubentry data?
> 
> I  wouldn't mind too much having one attribute type
> "supportedFeatures"  of syntax OID which listed "supported" features. 
> This could include  MAYs and SHOULDs from the "core" specification as
> well as any MAY, SHOULD,  MUST of any extension.  This would provide a
> discovery mechanism for any  feature you might want to publish support
> for.
> 
> However, I wonder the  value of providing additional discovery
> mechanisms when the discovery  mechanisms we already provide are
> rarely used and, in some cases, not needed  or inappropriate to use. 
> [Discovery of StartTLS is not needed,  discovery of SASL mechanisms is
> inappropriate without appropriate  consideration of security risks].
> 
> 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 Sep 21 12:53: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 SMTP id MAA09918
	for ; Thu, 21 Sep 2000 12:53: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 e8LGfci17744;
	Thu, 21 Sep 2000 09:41:39 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LGqG219748;
	Thu, 21 Sep 2000 09:52:16 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 09:52:16 -0700 (PDT)
From: "David Chadwick" 
Organization: University of Salford
To: Jim Sermersheim , Mark Wahl 
Date: Thu, 21 Sep 2000 17:50:40 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: RFC 2596 questions
Reply-to: d.w.chadwick@salford.ac.uk
CC: ietf-ldapext@netscape.com
Message-ID: <39CA4A70.22215.662A83F@localhost>
Priority: normal
In-reply-to: <39C6A335.8DDED5C@sun.com>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"Wy1dmD.A.S0E._yjy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT


> > I don't want to believe part of Section 3.3. It says that given the
> > filter (name;lang-en-US"=Billy Ray), that the following is a match:
> > CN;lang-EN-US;dynamic: Billy Ray To me, this is a different,
> > distinct subtype. In other words: cn;foo is a subtype of cn
> > cn;foo;bar is NOT a subtype of cn;foo, it is a direct subtype of cn.
> 

I would take the opposite stance and say that bar should be a 
subtype of foo, which is a subtype of cn.

> > Am I off in my thinking? RFC 2251 says that "An AttributeDescription
> > with one or more options is treated as a subtype of the attribute
> > type without any options".
> 

I would not agree with the above sentence. So my opinion would be 
that the examples are correct and the text is wrong. The text as it 
stands implies that it can only support one level of subtyping, rather 
than multiple levels which is needed.

Try to draw a Venn diagram for an attribute type with multiple 
options, where the options intersect is surely a multiple level 
subtypes of the attribute, is it not.

For example, a home phone number is a subtype of a phone 
number, and a private home phone number is a subtype of a home 
phone number. We should be able to cater for this in the LDAP data 
model with multiple options e.g. phone;home;private.

David



> I agree it needs to be clarified. There are two ways of interpreting
> this sentence.  I parse subtyping as 
>  If A is a subtype of B and B is a subtype of C, A is a subtype of C,
>  just not an 'immediate' subtype.  
> 
> > Also, both my cn;foo;bar example and all the CN;lang-EN-US;dynamic
> > examples in 2596 are invalid. RFC 2251 states that the options must
> > appear in ascending order.
> 
> You're right, that's a typo in 2596.  We'll fix that when it is time
> to reissue.
> 
> 
> > At the end of section 3.3, it says: "Thus in general, clients SHOULD
> > NOT use the language code option in AttributeDescription fields in
> > search filters". Is this because they might get more matches than
> > they bargained for? It would be nice if the "Thus in general" part
> > was spelled out a bit more.
> 
> It was earlier in this section.  This is just a reminder.
> 
>    Client implementors should however note that providing a language
>    code in a search filter AttributeDescription will often filter out
>    desirable values where the language code does not match exactly.  
> 
> Mark Wahl
> Sun Microsystems, Inc.
> 
> 


***************************************************

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 Sep 21 12:56: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 SMTP id MAA09942
	for ; Thu, 21 Sep 2000 12:56: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 e8LGhui18496;
	Thu, 21 Sep 2000 09:43:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LGsXI21037;
	Thu, 21 Sep 2000 09:54:33 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 09:54:33 -0700 (PDT)
Sender: robw@wigwamlab.com
Message-ID: <39CA3D24.508BB209@wigwamlab.com>
Date: Thu, 21 Sep 2000 09:53:56 -0700
From: Rob Weltman 
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.15-4mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: hahnt@us.ibm.com
CC: ietf-ldapext@netscape.com
Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"0et5GC.A.bIF.I1jy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Tim,

  I'll comment on the other things along with all the messages from
Steve soon, but here just a comment on the language subtype APIs.

  They were designed after a study of application usage of localized
attribute values, with the intent of best supporting such applications,
not of reflecting the LDAP protocol representation of language subtypes.
There is no need for the latter, since a client can request "cn" or
"cn;lang-ja" or "cn;lang-ja-JP-kanji" and will receive the results
dictated by LDAPv3.

  The usage model found in applications was that they wanted to access
the attribute value that was most specific to the requesting client, if
available, and to fall back to more general values if not. For a given
user entry, there might be a dozen attributes with a single value (no
language subtype), and five or less with different representations for
different locales. The application wants to pass in all locale
information that is available for the requesting client to the SDK, and
to receive from the SDK the most appropriate values for each of the
attributes of the entry. For example, the application might request
";lang-ja-JP-kanji" for all attributes of the entry; those attributes
that have that subtype will return them, while those that do not contain
that subtype but do contain ";lang-ja" will return ";lang-ja" values,
and those that contain no subtypes will return the base values.

  The alternative to this hierarchical model is that applications are
forced to either create duplicate attribute values (i.e. create subtyped
attributes even where the values are identical to those of the base
attributes) or to do the subtype analysis themselves.

Rob


hahnt@us.ibm.com wrote:
> 
> Greetings,
> 
> I finally got around to reading this draft.  It looks great so far.
>  I've summarized my comments here:
> 
> Section 4.3.5:
> --------------
> "cn;lang-ja-JP-kanji" may be a subtype of "cn;lang-ja" - based on
> recent discussions on this list, I don't think that this is true.  It
> seems to me that "cn;lang-ja-JP-kanji" is really treated as a subtype
> of "cn".
> 
> similarly, I think the example in this section need fixing as well:
> 
> getAttribute( "cn", "lang-en-us" ); does NOT return "cn;lang-en"
> 
> getAttribute( "sn", "lang-en" ); does NOT return "sn"
> 
> formating for description of "attrName" should be fixed.
> 
> Section 4.3.8:
> --------------
> Are attribute descriptions and attribute subtypes accounted for in
> this?  For example, will a:
> 
> attrSet.remove("name");
> 
> call result in all "cn", "sn", "cn;lang-us" attributes being removed
> from the LDAPAttributeSet?
> 
> Section 4.5.1:
> --------------
> Are alternative attribute type names, attribute subtypes, and
> attribute descriptions accounted for in this comparison
> implemenatation?
> 
> Section 4.5.4:
> --------------
> If an entry does not contain an attribute, is it considered greater
> than or less than an entry that does contain the attribute?
> 
> Section 4.6.4:
> --------------
> If the authentication method does not have an associated distinguished
> name, does this method return null?  An exception?
> 
> Section 4.6.17, 4.6.18:
> -----------------------
> Is a bind() done as well?  If so, what method is used?  Is this
> controlled by the LDAPSearchConstraints object that is passed in?
> 
> Section 4.7.1:
> --------------
> Maybe this was covered in previous discussions on this list.  It is
> not clear from the draft, however, what the subtle differences are
> between a LDAPBind and LDAPRebind class and where these differences
> are used.
> 
> Section 4.7.8:
> --------------
> A clarification: If the bind proc is null (the default), then no
> authentication is done on the initial connection.
> 
> Section 4.11.1:
> ---------------
> "after appropriate normalization".  Doesn't this imply that the CLIENT
> have full knowledge of the "active" schema?  More clarification as to
> the extent of normalization that will be done is needed here.  Full DN
> handling is actually quite complex.  If that is what is intended here,
> then it needs to be made clear.  Further, this could require some form
> of communication with an LDAP server to get a set of "schema" with
> which to work with.
> 
> Section 4.11.4, 4.11.5:
> -----------------------
> Will the values returned be appropriately escaped or un-escaped based
> on the escaping rules in RFC 2253?
> 
> Section 4.12.4 (and many others, including all of 4.29, 4.38, 4.39,
> 4.40):
> --------------------------------------------------------------------------
> 
> Why is a "String dn" returned/passed in and not a LDAPDN when a
> distinguished name is to be used?
> 
> Section 4.16.5:
> ---------------
> Are the constants referred to here for result codes defined as static
> constants anywhere?  I did not see them defined as such anywhere in
> this draft.  This could possibly be done in LDAPException as:
> 
> class LDAPException {
> ...
> public static final int NO_SUCH_OBJECT = 1;
> ...
> }
> 
> Section 4.21:
> -------------
> Since this set of modifications is ordered, should it be called
> LDAPModificationList instead?
> 
> Section 4.21.2:
> ---------------
> A clarification.  Since the list is ordered, add() should clarify that
> it adds at the END of the list.
> 
> Section 4.21.4:
> ---------------
> This is similar to the comment above on Section 4.3.8, are subtypes,
> attribute descriptions, and alternate attribute type names accounted
> for here?
> 
> Section 4.24 and 4.25:
> ----------------------
> The setup of LDAPRebindAuth and LDAPRebind seem only to support the
> notion of "simple" authentication.  How are other authentication
> methods to be setup and used when following referrals?
> 
> Section 4.26.1:
> ---------------
> Clarification: the full response is received prior to throwing the
> referral exception, correct?
> 
> Section 4.29.11:
> ----------------
> "of attribute definitions" should be "of LDAPAttributeSchema
> definitions".
> 
> Section 4.29.12:
> ----------------
> "of attribute definitions" should be "of LDAPObjectClassSchema
> definitions".
> 
> Section 4.29.13:
> ----------------
> "of attribute definitions" should be "of LDAPMatchingRuleSchema
> definitions".
> 
> Section 4.29.20-25:
> -------------------
> clarification: the returned Enumeration is an Enumeration of Strings,
> correct?
> 
> Section 4.30.1-3:
> -----------------
> I would prefer that these methods NOT be defined in the abstract base
> class.  They don't make sense for some derived classes.  This was
> alluded to later in the document (Section 4.37).
> 
> Section 4.30.6:
> ---------------
> clarification: the returned Enumeration is an Enumeration of Strings,
> correct?
> 
> Section 4.30.10,11,12:
> ----------------------
> These should clarify what LDAP operations are being performed.  I
> think that 4.30.10 is an LDAP MODIFY where a new attribute value is
> added to the existing attributetypes, objectclasses, ldapsyntaxes, or
> matchingrules attribute in the subschemasubentry, 4.30.11 is a LDAP
> MODIFY operation to delete a specific attribute value, and 4.30.12 is
> an LDAP MODIFY with a "delete value" + "add value" in the
> ModificationSet/List.  This should be described in these sections.
> 
> Section 4.30.12:
> ----------------
> Also in this section, the value from "this.getValue()" is used as the
> "attribute value to delete", correct?
> 
> Section 4.31.1:
> ---------------
> Why is doReferrals set to "false" by default?
> 
> non-SIMPLE re-bind authentication seems to need more thought, in
> general.  Is anybody working on this?
> 
> Is hop_limit set to zero by default?  Does zero imply no limit?
> 
> Section 4.31.3:
> ---------------
> LDAP_DEREF_NEVER  should be LDAPConnection.DEREF_NEVER
> LDAP_DEREF_FINDING should be LDAPConnection.DEREF_FINDING
> LDAP_DEREF_SEARCHING should be LDAPConnection.DEREF_SEARCHING
> LDAP_DEREF_ALWAYS should be LDAPConnection.DEREF_ALWAYS
> 
> Section 4.32.1:
> ---------------
> What is meant by "outstanding requests"?  Is this the set of responses
> that have not yet been completely received from the remote server?  Or
> the set of responses that have not been "received" by the application?
>  Or both?
> 
> Section 4.32.3:
> ---------------
> Would it be useful to have a "isReponseReceived( int msgid )" method
> as well?
> 
> How about an "isComplete( int msgid )"?
> 
> Section 4.35.5:
> ---------------
> "This the" should be "This is the"
> 
> "or an LDAPReferralException." should be "or an LDAPReferralException
> is thrown."
> 
> Should there be a way to get the referrals FIRST (i.e. not at the end
> as an exception), so that other searches can be started in the
> background?  This would allow multiple outstanding searches to
> multiple servers to run in parallel instead of serializing referrals
> chasing.
> 
> Section 4.38.1:
> ---------------
> attrNames description, "null for all attributes".  Should this be
> "null or a single value of "*" for all attributes".
> 
> Section 4.39.13:
> ----------------
> Description of LDAPConnection.REFERRALS_HOP_LIMIT.  Change "no more
> than 5 referrals in a row" to "no more than 5 nested referrals."
> 
> Section 4.40.1:
> ---------------
> Will the client send off abandon requests for all outstanding (but
> incomplete) operations if a bind() is invoked?
> 
> Thanks,
> 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  Thu Sep 21 15:20:24 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 SMTP id PAA12797
	for ; Thu, 21 Sep 2000 15:20: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 e8LJ71i18224;
	Thu, 21 Sep 2000 12:07:05 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LJCxI09972;
	Thu, 21 Sep 2000 12:12:59 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 12:12:59 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Thu, 21 Sep 2000 12:19:32 -0600
From: "Steve Sonntag" 
To: 
Cc: , "Alan Clark" ,
        "Steven Merrill" 
Subject: LDAPException in java-api-11.txt
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_E6BE182C.13721B35"
Resent-Message-ID: <"dFNqVD.A.2aC.z2ly5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_E6BE182C.13721B35
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

4.16 LDAPException

The LDAPException class has a method getMatchedDN() but has no way to set
the matched DN in the object.  Shouldn't there be a constructor with =
MatchedDN
as a parameter?

-Steve

------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software

--=_E6BE182C.13721B35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







4.16 LDAPException


 


The LDAPException class has a method getMatchedDN() but has no way =
to=20
set


the matched DN in the object.  Shouldn't there be a constructor =
with=20
MatchedDN


as a parameter?


 


-Steve


 


------------------------
Steve Sonntag
Novell, Inc., the =
leading=20
provider of Net services software


 


 


--=_E6BE182C.13721B35--



From list@netscape.com  Thu Sep 21 16:25: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 SMTP id QAA13982
	for ; Thu, 21 Sep 2000 16:25: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 e8LKCli28040;
	Thu, 21 Sep 2000 13:12:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LKHxM10185;
	Thu, 21 Sep 2000 13:17:59 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 13:17:59 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Thu, 21 Sep 2000 12:33:35 -0600
From: "Jim Sermersheim" 
To: 
Cc: , 
Subject: Re: RFC 2596 questions
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_5F07A190.AFCEA78F"
Resent-Message-ID: <"8jQS6D.A.veC.2zmy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_5F07A190.AFCEA78F
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

>>>> Mark Wahl  9/18/00 5:20:21 PM >>>

>> Is that correct? If so, I believe the following assumption is also =
correct:
>> Any value held in an attribute with more than one language option (i.e. =
the=20
>> example above) does NOT exist in the attribute with a subset of =
those=20
>> language options. In other words, the example above does NOT imply =
that=20
>> there are values like:
>> cn;lang-en-US: JoeBob
>> cn;lang-ja: JoeBob
>> Right?
>
>Those are different values.  You could have them there as well, if you =
wished.

I worded that poorly. What I meant to say, is that given the entry:

dn: cn=3DJoeBob,o=3Dmyorg
cn:lang-en-US: Joe
cn;lang-ja: Bob

cn;lang-en-US;lang-ja: JoeBob

The search filter (cn;lang-en =3D JoeBob) will NOT match. This is due to =
the fact that as stated in RFC 2251, "An AttributeDescription with one or =
more options is treated as a subtype of the attribute type without any =
options".

This statement tells me that=20
cn:lang-en-US is a direct subtype of cn
cn;lang-ja is a direct subtype of cn
cn;lang-en-US;lang-ja is a direct subtype of cn.

Yes, I'm reading "direct" into the 2251 statement. David has argued that:
cn;lang-en-US;lang-ja is a direct subtype of cn;lang-en-US, which in turn =
is a direct subtype of cn. Does this also mean that it's also a subtype of =
cn;lang-ja, or is it strictly a right to left thing? If r to l, then the =
attribute type option ordering restriction will get in people's way.

Jim

--=_5F07A190.AFCEA78F
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







>>>> Mark Wahl <Mark.Wahl@sun.com> 9/18/00 5:20:21 =
PM=20
>>>

>> Is that correct? If so, I believe the =
following=20
assumption is also correct:
>> Any value held in an attribute =
with more=20
than one language option (i.e. the 
>> example above) does NOT =
exist in=20
the attribute with a subset of those 
>> language options. In =
other=20
words, the example above does NOT imply that 
>> there are =
values=20
like:
>> cn;lang-en-US: JoeBob
>> cn;lang-ja:=20
JoeBob
>> Right?
>
>Those are different values.  =
You=20
could have them there as well, if you wished.


 


I worded that poorly. What I meant to say, is that given the=20
entry:


 


dn: cn=3DJoeBob,o=3Dmyorg


cn:lang-en-US: Joe


cn;lang-ja: Bob


cn;lang-en-US;lang-ja: JoeBob


 


The search filter (cn;lang-en =3D JoeBob) will NOT match. This is due =
to the=20
fact that as stated in RFC 2251, "An AttributeDescription with one or =
more=20
options is treated as a subtype of the attribute type without any=20
options".


 


This statement tells me that 




cn:lang-en-US is a direct subtype of cn


cn;lang-ja is a direct subtype of cn


cn;lang-en-US;lang-ja is a direct subtype of cn.


 


Yes, I'm reading "direct" into the 2251 statement. David has =
argued=20
that:




cn;lang-en-US;lang-ja is a direct subtype of cn;lang-en-US, which in =
turn=20
is a direct subtype of cn. Does this also mean that it's also a subtype =
of=20
cn;lang-ja, or is it strictly a right to left thing? If r to l, then =
the=20
attribute type option ordering restriction will get in people's=20
way.

Jim


--=_5F07A190.AFCEA78F--



From list@netscape.com  Thu Sep 21 16:50:06 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 SMTP id QAA14253
	for ; Thu, 21 Sep 2000 16:50: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 e8LKbei02745;
	Thu, 21 Sep 2000 13:37:40 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8LKhoo24003;
	Thu, 21 Sep 2000 13:43:50 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 13:43:50 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Thu, 21 Sep 2000 12:39:21 -0600
From: "Steve Sonntag" 
To: , 
Cc: 
Subject: serverMessage parameter in ID java-api-11.txt
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_3D65C3F3.9FFE97BC"
Resent-Message-ID: <"P8gP5D.A.-1F._Lny5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_3D65C3F3.9FFE97BC
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Greetings,

4.26 LDAPException

I am trying to understand where the information in the
constructor serverMessage comes from.  I am not
aware of any message that is returned by the server with a
referral result, except for the actual referral URLs.

Do you intend that the class gets primed with the=20
referral URLs using the serverMessage parameter
and if so how are the referrals delimited - otherwise
can you elaborate on the meaning of this parameter
and explain how the referral URLs are placed into the
class.

Thanks

------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software

--=_3D65C3F3.9FFE97BC
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







Greetings,


 


4.26 LDAPException


 


I am trying to understand where the information in the


constructor serverMessage comes from.  I am not


aware of any message that is returned by the server with a


referral result, except for the actual referral URLs.


 


Do you intend that the class gets primed with the 


referral URLs using the serverMessage parameter


and if so how are the referrals delimited - otherwise


can you elaborate on the meaning of this parameter


and explain how the referral URLs are placed into the


class.


 


Thanks


 


------------------------
Steve Sonntag
Novell, Inc., the =
leading=20
provider of Net services software


 


 


--=_3D65C3F3.9FFE97BC--



From list@netscape.com  Thu Sep 21 20:39:29 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 SMTP id UAA16424
	for ; Thu, 21 Sep 2000 20:39: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 e8M0RPi05504;
	Thu, 21 Sep 2000 17:27:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8M0c3o07142;
	Thu, 21 Sep 2000 17:38:03 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 17:38:03 -0700 (PDT)
Reply-To: 
From: "Steven Legg" 
To: 
Cc: 
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Date: Fri, 22 Sep 2000 11:37:14 +1100
Message-ID: <001401c0242d$417f6490$b05508cb@osmium.adacel.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 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <39CA4A71.32621.662AB2D@localhost>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Resent-Message-ID: <"WkjHR.A.KvB.pnqy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


David,

> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
> Sent: Friday, 22 September 2000 3:51
> To: Jim Sermersheim; ietf-ldapext@netscape.com; kgdaniec@us.ibm.com
> Subject: Re: Feature discovery (Was: RFC 2596 questions)
> 
> 
> Date forwarded: 	Fri, 15 Sep 2000 14:30:17 -0700 (PDT)
> Date sent:      	Fri, 15 Sep 2000 15:28:50 -0600
> From:           	"Jim Sermersheim" 
> To:             	, 
> 
> Subject:        	Re: Feature discovery (Was: RFC 2596 questions)
> Forwarded by:   	ietf-ldapext@netscape.com
> 
> > You mean advertised in the schema, right? I would say yes, I think
> > there should be another schema element called something like
> > attributeTypeOptions, the syntax would look something like this (ala
> > 2252 nomenclature):
> 
> Jim
> 
> The only problem with your approach below is that you are 
> effectively defining a whole new set of attribute subtypes, without 
> assigning OIDs to the subtypes. Although it is more longwinded, I 
> would prefer an approach where every subtype was specified in its 
> own right as an attribute type, and had its own OID allocated to it.

I agree with the sentiment since I have to translate LDAP attribute
descriptions into OIDs to pass around in the DSP and DISP protocols.
I can define the OIDs for the implied subtypes from an OID arc I have
authority over but that doesn't help interoperability any. It would be
very helpful to me to have the OIDs for subtypes predefined, but there
are some definitional problems in practice.

If we have N attribute types, and M options we want to use with those
attribute types, then we have to define NxM OIDs. It isn't clear who
should be responsible for defining those OIDs. If I define a new
attribute type should I also define the OIDs for the subtypes
corresponding to the options I know about ? What happens when
new options are defined by someone else later ? If I define a
new option am I required to define the OIDs for all the potential
attribute types the option could applied to ? Then what happens
when new attributes are defined ?

Two of the possible strategies for a solution are:

1) Try to get the X.500 standard extended to allow attribute options
to be conveyed along side the attribute type OIDs in the protocols.

2) Invent an algorithmic way to derive OIDs for an arbitrary
attribute type and option combination.

By way of a solution for 2) we could require that each option have
an OID defined for it. Then the OID for the subtype implied by the
option  applied to the attribute type 
is the concatenation . . For example,
if I define a new option "foo" with the OID 1.2.36.79672281.1.30.1
and I want to apply it to the commonName attribute I end up with a
subtype cn;foo having the OID 1.2.36.79672281.1.30.1.2.5.4.3 .

The concatenation . would actually make
more sense but we have no authority to extend the vast majority of
existing attribute OID arcs. Attribute options don't currently have
OIDs so we can require that the arcs below the option OID are left open
for any legitimate OID to be appended. The scheme also works if
two or more option OIDs are concatenated, with the attribute type OID
appended to the end.

Regards,
Steven 

> 
> By way of example, taking cn;lang-fr as a subtype of common name 
>  we should be able to define 
> 
> ( x.y.z NAME 'frenchname' SUP cn )
> -- all values to be in French
> 
> or (x.y.z NAME 'cn;lang-fr' EQUALITY caseIgnoreMatch
>       SUBSTR caseIgnoreSubstringsMatch
>       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
> 
> or even (x.y.z NAME 'cn;lang-fr' SUP cn)
> 
> These should all be equivalent and allowed. This would necessitate 
> a change to the BNF to allow ;options to be included in attribute 
> types.
> 
> A user can then request French common names by either asking for 
> the frenchname attribute or the cn;lang-fr attribute values.
> 
> David
> 
> 
> > 
> > AttributeTypeOptionDescription = "(
> >    numericoid whsp ; Attribute Type Option Identifier
> >    [ "NAME" qdescrs ]
> >    [ "DESC" qdescrs ]
> >    [ "OBSOLETE" whsp ]
> >    "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") 
> oids) ; list of
> >    syntaxes or attributes that this ATO applies to. whsp ")"
> > 
> > 
> > Jim
> > 
> > 
> > >>>  9/15/00 2:58:18 PM >>>
> > Jim wrote:
> > Whatever the discovery mech is, I'd rather we have it and be  rarely
> > used than not have it at all. Also, some things (like attr type
> > options)  need more than just an OID in a list. We need to specify
> > where they can be used (which attrs or syntaxes support them).
> > 
> > Doesn't this imply then that support of the attribute tags should be
> > discovered as part of schema discovery?
> > 
> > Karen
> > 
> > Internet: kgdaniec@us.ibm.com
> > Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
> >                  IBMUSM10(KGDANIEC)
> > phone: 607.752.1075   tie-line: 8/852-1075
> > fax: 607.752.3681
> > ---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on
> > 09/15/2000 04:57 PM ---------------------------
> > 
> > "Jim Sermersheim"  on 09/15/2000 04:33:17 PM
> > 
> > To:   , Timothy Hahn/Endicott/IBM@IBMUS
> > cc:   
> > Subject:  Re: Feature discovery (Was: RFC 2596 questions)
> > 
> > 
> > 
> > 
> > Whatever the discovery mech is, I'd rather we have it and be  rarely
> > used than not have it at all. Also, some things (like attr type
> > options)  need more than just an OID in a list. We need to specify
> > where they can be used (which attrs or syntaxes support them).
> > 
> > Jim
> > 
> > 
> > >>> "Kurt D. Zeilenga"  9/15/00  2:01:22 PM >>>
> > At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com  wrote:
> > >Should we investigate some additional rootDSE attribute to 
>  indicate
> > >the
> > set of attribute descriptions that are supported?  Further,  when a
> > new attribute description is defined, should we be 
> assigning OIDs and 
> > keeping these as an additional part of the subschemasubentry data?
> > 
> > I  wouldn't mind too much having one attribute type
> > "supportedFeatures"  of syntax OID which listed "supported" 
> features. 
> > This could include  MAYs and SHOULDs from the "core" 
> specification as
> > well as any MAY, SHOULD,  MUST of any extension.  This 
> would provide a
> > discovery mechanism for any  feature you might want to 
> publish support
> > for.
> > 
> > However, I wonder the  value of providing additional discovery
> > mechanisms when the discovery  mechanisms we already provide are
> > rarely used and, in some cases, not needed  or 
> inappropriate to use. 
> > [Discovery of StartTLS is not needed,  discovery of SASL 
> mechanisms is
> > inappropriate without appropriate  consideration of security risks].
> > 
> > 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 Sep 21 21:49: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 SMTP id VAA17891
	for ; Thu, 21 Sep 2000 21:49: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 e8M1fmo23750;
	Thu, 21 Sep 2000 18:41:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8M1mBw13793;
	Thu, 21 Sep 2000 18:48:11 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 18:48:11 -0700 (PDT)
Reply-To: 
From: "Steven Legg" 
To: 
Cc: 
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Date: Fri, 22 Sep 2000 12:48:05 +1100
Message-ID: <001801c02437$27328f40$b05508cb@osmium.adacel.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 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Resent-Message-ID: <"rfAKXB.A.HXD.apry5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


Tim,

> -----Original Message-----
> From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com]
> Sent: Saturday, 16 September 2000 21:59
> To: ietf-ldapext@netscape.com
> Subject: Re: Feature discovery (Was: RFC 2596 questions)
>
>
>
> Hi all,
>
> I like the idea of extending the schema information with the set of
attribute descriptions that are known to the server.
>
> Both approaches described so far:
>
> 1) extend the attributeTypes value to allow for additional fields to be
specified within each value, add a new value that defines the OIDs used in
the field
> 2) add a new attribute to the subschemasubentry and contain all the
information here
>
> are in the right direction.
>
> Approach 1) has the benefit that just by looking at the attributeType
value,
> you can get an indication if any attribute descriptions might have been
used
> in creating/modifying entries that contain this attribute.  However, there
> would be the issue of whether or not the server supported the additional
> data in the attributeTypes value.
>
> Approach 2) doesn't change the attributeType value definition (nice for
> upward compatibility).  On the downside, though, in order to see what
> attribute description a given attribute type can have attached to it, a
> not-so-easy-search of the new schema attribute would have to be performed.
>
> After writing up this short discussion of the approaches, I think I prefer
> Approach 1) where the "DESCRIPTORS (  "$" ... )" clause of the
> attributeTypes value is an optional piece in the format of the value.
>
> Is there agreement here?

No, unless you can convince the X.500 committee to also extend the
definition of the syntax of the attributeTypes operational attribute.
If further fields are added to the LDAP string encoding of values of
the attributeTypes attribute then it will be out of sync with its X.500
ASN.1 syntax definition and BER encoding. That will be painful for
those of us with servers supporting both LDAP and X.500. The ldapSyntaxes
attribute is fair game though.

Regards,
Steven

>
> 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  Thu Sep 21 23:14: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 SMTP id XAA19497
	for ; Thu, 21 Sep 2000 23:14: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 e8M367o04688;
	Thu, 21 Sep 2000 20:06:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8M1f3Y09601;
	Thu, 21 Sep 2000 18:41:03 -0700 (PDT)
Resent-Date: Thu, 21 Sep 2000 18:41:03 -0700 (PDT)
Reply-To: 
From: "Steven Legg" 
To: 
Cc: 
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Date: Fri, 22 Sep 2000 12:40:28 +1100
Message-ID: <001701c02436$1740f1e0$b05508cb@osmium.adacel.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 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Resent-Message-ID: <"mYOsg.A.-UC.piry5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


Karen,

> -----Original Message-----
> From: kgdaniec@us.ibm.com [mailto:kgdaniec@us.ibm.com]
> Sent: Tuesday, 19 September 2000 5:57
> To: ietf-ldapext@netscape.com; hahnt@us.ibm.com
> Subject: Re: Feature discovery (Was: RFC 2596 questions)
> 
> 
> Jim,
> Perhaps a combination of the approaches mentioned already 
> really is needed,
> then.  Servers could publish in their rootDSE the attributetype
> options/extensions that they support.  This would allow 
> anyone adding to or
> modifying the schema to know what the server supports.  
> However, the server
> could also publish as part of the schema what the "currently 
> active" set of
> attributetype "descriptors" (to use Tim's term) is.

I like this approach, especially when viewed from the perspective
of replication and the X.500 schema administrative model. The
information about what attribute type options a server is *capable*
of supporting is specific to that server. It is not appropriate
for that information to be replicated or held in the schema definition
for a DIT subtree that is distributed across multiple servers
(as allowed by X.500). The root DSE is a reasonable place to hold this
kind of information. The information about what attribute type
options are *permitted* to be used with what attribute types is
part of the schema configuration and it seems entirely appropriate
to me to allow this to be in the subschema subentry (where it can
be replicated).

The separation also deals with the variant uses of the attribute type
options. The options that don't imply attribute subtyping
(e.g. ;binary) have no business being described in the schema subentry
as far as I'm concerned.

Regards,
Steven

> 
> Would these be specified by syntax or by attributetype, 
> though, or both?
> Setting these by syntax allows defaults to be in effect for each
> attributetype.  I suppose this is no more confusing than  "default"
> matching rules based upon syntax.
> 
> Karen
> 
> Internet: kgdaniec@us.ibm.com
> Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
>                  IBMUSM10(KGDANIEC)
> phone: 607.752.1075   tie-line: 8/852-1075
> fax: 607.752.3681



From list@netscape.com  Fri Sep 22 04:14: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 SMTP id EAA03958
	for ; Fri, 22 Sep 2000 04:14: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 e8M81vi24347;
	Fri, 22 Sep 2000 01:01:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8M8CZQ08425;
	Fri, 22 Sep 2000 01:12:35 -0700 (PDT)
Resent-Date: Fri, 22 Sep 2000 01:12:35 -0700 (PDT)
Date: Fri, 22 Sep 2000 01:10:09 -0700 (PDT)
Message-Id: <200009220810.e8M8A1H21181@ywing.netscape.com>
From: profitablemoney@yahoo.com
To: customer@netscape.com
Subject:  Check This Out!
X-Reply-To:  profitmone@prontomail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"dACCfC.A.VDC.yRxy5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Dear Friend,

I have some information that will be of interest to 
you. It could change your life. 

Would you like to earn US$50,000 or more in the 
next 90 days with VERY LITTLE investment? This will 
unlock the doors to success and money. It is really 
works. EARN UNLIMITED INCOME! All customers pay you 
CASH! 

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 will get that 
big break that you've been waiting for, THIS IS IT!

The longer you wait, the more people will be doing 
business using email. Get your piece of this 
action!!!
There are 5 million fresh email addresses every 
week and they are waiting for home based business 
everyday. So my friend, don't waste your time. It's 
all up to you and you won't be sorry. For more 
information, please hit reply with the subject line 
: INFO, and I will send a free booklet for you.

If this message has reached you in error, please 
accept our apologies. To remove your address from 
future mailings, please just leave it, and you will 
not receive this message anymore.


All the best,
Profit Money




From list@netscape.com  Sat Sep 23 03:30: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 SMTP id DAA19201
	for ; Sat, 23 Sep 2000 03:30: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 e8N7IWi19657;
	Sat, 23 Sep 2000 00:18:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8N7TCI12691;
	Sat, 23 Sep 2000 00:29:12 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 00:29:12 -0700 (PDT)
Date: Sat, 23 Sep 2000 00:28:59 -0700 (PDT)
Message-Id: <200009230728.e8N7SxI26992@xwing.netscape.com>
To: gdfdgf@fdngfl.it.netscape.com
From: 
Subject: RETIRE IN 2-3 YEARS!!!
Resent-Message-ID: <"fMgJuC.A.BGD.HvFz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Work Smarter ....Not Harder!!

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

I am searching for only 10 elite individuals with the work
 ethic necessary to generate a cash-flow for themselves of
 $2,000 - $5,000per 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, I 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 my 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-800-320-9895 Ext. 6131

We market a real product, that pays real commissions to you,
$1,000.00 per sale, just for making the initial contacts. 
With our turn-key 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-800-320-9895 Ext. 6131

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!

Please, serious inquiries only.




**********************************************************************
All REMOVE requests AUTOMATICALLY honored upon receipt.

PLEASE understand that any effort to disrupt, close or block this
 REMOVE account can only result in difficulties for others wanting
 to be removed from our mailing list as it will be impossible to take
 anyone off the list if the remove instruction can not be received.

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



From list@netscape.com  Sat Sep 23 07:13:38 2000
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20177
	for ; Sat, 23 Sep 2000 07:13: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 e8NB1Ui16841;
	Sat, 23 Sep 2000 04:01:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8NBCB217627;
	Sat, 23 Sep 2000 04:12:11 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 04:12:11 -0700 (PDT)
From: "David Chadwick" 
Organization: University of Salford
To: "Jim Sermersheim" , ,
        
Date: Sat, 23 Sep 2000 12:11:55 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: RFC 2596 questions
Reply-to: d.w.chadwick@salford.ac.uk
CC: , 
Message-ID: <39CC9E0B.12827.5AB37C@localhost>
Priority: normal
In-reply-to: 
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"pSRBVC.A.JTE.KAJz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT


> Yes, I'm reading "direct" into the 2251 statement. David has argued
> that: cn;lang-en-US;lang-ja is a direct subtype of cn;lang-en-US,
> which in turn is a direct subtype of cn. Does this also mean that it's
> also a subtype of cn;lang-ja, 

Yes, I would say so. The new dual language subtype is a subtype 
of both single language subtypes. The order does not matter. We 
have

               supertype
             /                  \
subtype 1                    subtype 2
              \                 /
              subtype1-2

David

>or is it strictly a right to left thing?
> If r to l, then the attribute type option ordering restriction will
> get in people's way.
> 
> Jim
> 


***************************************************

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  Sat Sep 23 07:13:48 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20191
	for ; Sat, 23 Sep 2000 07:13: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 e8NB5qV20087;
	Sat, 23 Sep 2000 04:05:53 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8NBCGk17738;
	Sat, 23 Sep 2000 04:12:16 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 04:12:16 -0700 (PDT)
From: "David Chadwick" 
Organization: University of Salford
To: "Steven Legg" , ,
        
Date: Sat, 23 Sep 2000 12:11:54 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Reply-to: d.w.chadwick@salford.ac.uk
CC: osidirectory@az05.bull.com
Message-ID: <39CC9E0A.11579.5AAFC3@localhost>
Priority: normal
In-reply-to: <001401c0242d$417f6490$b05508cb@osmium.adacel.com.au>
References: <39CA4A71.32621.662AB2D@localhost>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"Gh5Es.A.SUE.PAJz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

Send reply to:  	
From:           	"Steven Legg" 
To:             	
Copies to:      	
Subject:        	RE: Feature discovery (Was: RFC 2596 questions)
Date sent:      	Fri, 22 Sep 2000 11:37:14 +1100


Steven

You raise a number of interesting questions below. I think that there 
are two different issues to be addressed, namely

i) whether to have dynamic attribute subtyping with schema 
definitions that link subtypes to attributes at runtime, and individual 
implementations decide dynamically which ones they can support 
(this is similar to the matchingRuleUse system schema definition 
currently defined in X.501) or

ii) having static definitions with fixed OIDs (which is what my 
previous message was suggesting)

The second issue is how to unambiguously represent an attribute 
subtype in protocol. We could use either or both of OIDs and ldap 
strings. We currently have neither of these as ldap strings are only 
locally defined and there is no current way of automatically 
generating an OID representation. YOur message below gave one 
suggestion for the latter. The Internet 2 folks were suggesting 
globally unique strings for ldap attribute types as a solution to the 
former.

Of course if we only have static definitions with fixed OIDs then 
both problems are solved, but as you point out there could be an 
explosion of new static definitions.

I suggest that this work should be defined in conjunction with the 
X.500 group, since they now have an LDAP alignment work item, 
and the work seems to me to be of a fundamental basis.

We could for example suggest a change to the ASN.1 of an 
attribute type by making it a sequence of OIDs with an optional 
subtype qualifier OID after the mandatory attribute type OID.

However we proceed, this is not a particularly easy problem to 
solve,

David

> 
> David,
> 
> > -----Original Message-----
> > From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
> > Sent: Friday, 22 September 2000 3:51
> > To: Jim Sermersheim; ietf-ldapext@netscape.com; kgdaniec@us.ibm.com
> > Subject: Re: Feature discovery (Was: RFC 2596 questions)
> > 
> > 
> > Date forwarded: 	Fri, 15 Sep 2000 14:30:17 -0700 (PDT)
> > Date sent:      	Fri, 15 Sep 2000 15:28:50 -0600
> > From:           	"Jim Sermersheim" 
> > To:             	, 
> > 
> > Subject:        	Re: Feature discovery (Was: RFC 2596 questions)
> > Forwarded by:   	ietf-ldapext@netscape.com
> > 
> > > You mean advertised in the schema, right? I would say yes, I think
> > > there should be another schema element called something like
> > > attributeTypeOptions, the syntax would look something like this
> > > (ala 2252 nomenclature):
> > 
> > Jim
> > 
> > The only problem with your approach below is that you are 
> > effectively defining a whole new set of attribute subtypes, without
> > assigning OIDs to the subtypes. Although it is more longwinded, I
> > would prefer an approach where every subtype was specified in its
> > own right as an attribute type, and had its own OID allocated to it.
> 
> I agree with the sentiment since I have to translate LDAP attribute
> descriptions into OIDs to pass around in the DSP and DISP protocols. I
> can define the OIDs for the implied subtypes from an OID arc I have
> authority over but that doesn't help interoperability any. It would be
> very helpful to me to have the OIDs for subtypes predefined, but there
> are some definitional problems in practice.
> 
> If we have N attribute types, and M options we want to use with those
> attribute types, then we have to define NxM OIDs. It isn't clear who
> should be responsible for defining those OIDs. If I define a new
> attribute type should I also define the OIDs for the subtypes
> corresponding to the options I know about ? What happens when new
> options are defined by someone else later ? If I define a new option
> am I required to define the OIDs for all the potential attribute types
> the option could applied to ? Then what happens when new attributes
> are defined ?
> 
> Two of the possible strategies for a solution are:
> 
> 1) Try to get the X.500 standard extended to allow attribute options
> to be conveyed along side the attribute type OIDs in the protocols.
> 
> 2) Invent an algorithmic way to derive OIDs for an arbitrary
> attribute type and option combination.
> 
> By way of a solution for 2) we could require that each option have an
> OID defined for it. Then the OID for the subtype implied by the option
>  applied to the attribute type  is the
> concatenation . . For example, if I define
> a new option "foo" with the OID 1.2.36.79672281.1.30.1 and I want to
> apply it to the commonName attribute I end up with a subtype cn;foo
> having the OID 1.2.36.79672281.1.30.1.2.5.4.3 .
> 
> The concatenation . would actually make
> more sense but we have no authority to extend the vast majority of
> existing attribute OID arcs. Attribute options don't currently have
> OIDs so we can require that the arcs below the option OID are left
> open for any legitimate OID to be appended. The scheme also works if
> two or more option OIDs are concatenated, with the attribute type OID
> appended to the end.
> 
> Regards,
> Steven 
> 
> > 
> > By way of example, taking cn;lang-fr as a subtype of common name 
> >  we should be able to define 
> > 
> > ( x.y.z NAME 'frenchname' SUP cn )
> > -- all values to be in French
> > 
> > or (x.y.z NAME 'cn;lang-fr' EQUALITY caseIgnoreMatch
> >       SUBSTR caseIgnoreSubstringsMatch
> >       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
> > 
> > or even (x.y.z NAME 'cn;lang-fr' SUP cn)
> > 
> > These should all be equivalent and allowed. This would necessitate a
> > change to the BNF to allow ;options to be included in attribute
> > types.
> > 
> > A user can then request French common names by either asking for the
> > frenchname attribute or the cn;lang-fr attribute values.
> > 
> > David
> > 
> > 
> > > 
> > > AttributeTypeOptionDescription = "(
> > >    numericoid whsp ; Attribute Type Option Identifier
> > >    [ "NAME" qdescrs ]
> > >    [ "DESC" qdescrs ]
> > >    [ "OBSOLETE" whsp ]
> > >    "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") 
> > oids) ; list of
> > >    syntaxes or attributes that this ATO applies to. whsp ")"
> > > 
> > > 
> > > Jim
> > > 
> > > 
> > > >>>  9/15/00 2:58:18 PM >>>
> > > Jim wrote:
> > > Whatever the discovery mech is, I'd rather we have it and be 
> > > rarely used than not have it at all. Also, some things (like attr
> > > type options)  need more than just an OID in a list. We need to
> > > specify where they can be used (which attrs or syntaxes support
> > > them).
> > > 
> > > Doesn't this imply then that support of the attribute tags should
> > > be discovered as part of schema discovery?
> > > 
> > > Karen
> > > 
> > > Internet: kgdaniec@us.ibm.com
> > > Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
> > >                  IBMUSM10(KGDANIEC)
> > > phone: 607.752.1075   tie-line: 8/852-1075
> > > fax: 607.752.3681
> > > ---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on
> > > 09/15/2000 04:57 PM ---------------------------
> > > 
> > > "Jim Sermersheim"  on 09/15/2000 04:33:17 PM
> > > 
> > > To:   , Timothy Hahn/Endicott/IBM@IBMUS
> > > cc:   
> > > Subject:  Re: Feature discovery (Was: RFC 2596 questions)
> > > 
> > > 
> > > 
> > > 
> > > Whatever the discovery mech is, I'd rather we have it and be 
> > > rarely used than not have it at all. Also, some things (like attr
> > > type options)  need more than just an OID in a list. We need to
> > > specify where they can be used (which attrs or syntaxes support
> > > them).
> > > 
> > > Jim
> > > 
> > > 
> > > >>> "Kurt D. Zeilenga"  9/15/00  2:01:22 PM >>>
> > > At 07:18 AM 9/15/00 -0400, hahnt@us.ibm.com  wrote:
> > > >Should we investigate some additional rootDSE attribute to 
> >  indicate
> > > >the
> > > set of attribute descriptions that are supported?  Further,  when
> > > a new attribute description is defined, should we be 
> > assigning OIDs and 
> > > keeping these as an additional part of the subschemasubentry data?
> > > 
> > > I  wouldn't mind too much having one attribute type
> > > "supportedFeatures"  of syntax OID which listed "supported" 
> > features. 
> > > This could include  MAYs and SHOULDs from the "core" 
> > specification as
> > > well as any MAY, SHOULD,  MUST of any extension.  This 
> > would provide a
> > > discovery mechanism for any  feature you might want to 
> > publish support
> > > for.
> > > 
> > > However, I wonder the  value of providing additional discovery
> > > mechanisms when the discovery  mechanisms we already provide are
> > > rarely used and, in some cases, not needed  or 
> > inappropriate to use. 
> > > [Discovery of StartTLS is not needed,  discovery of SASL 
> > mechanisms is
> > > inappropriate without appropriate  consideration of security
> > > risks].
> > > 
> > > 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
> > 
> > ***************************************************
> > 
> > 
> 


***************************************************

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  Sat Sep 23 07:13:57 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20201
	for ; Sat, 23 Sep 2000 07: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 e8NB5wV20152;
	Sat, 23 Sep 2000 04:05:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8NBCN217886;
	Sat, 23 Sep 2000 04:12:23 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 04:12:23 -0700 (PDT)
From: "David Chadwick" 
Organization: University of Salford
To: "Steven Legg" , ,
        
Date: Sat, 23 Sep 2000 12:11:56 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: Feature discovery (Was: RFC 2596 questions)
Reply-to: d.w.chadwick@salford.ac.uk
CC: 
Message-ID: <39CC9E0C.11223.5AB64C@localhost>
Priority: normal
In-reply-to: <001701c02436$1740f1e0$b05508cb@osmium.adacel.com.au>
References: 
X-mailer: Pegasus Mail for Win32 (v3.12c)
Resent-Message-ID: <"miCJPD.A.pWE.TAJz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

Steven wrote

> I like this approach, especially when viewed from the perspective of
> replication and the X.500 schema administrative model. The information
> about what attribute type options a server is *capable* of supporting
> is specific to that server. It is not appropriate for that information
> to be replicated or held in the schema definition for a DIT subtree
> that is distributed across multiple servers (as allowed by X.500). The
> root DSE is a reasonable place to hold this kind of information. The
> information about what attribute type options are *permitted* to be
> used with what attribute types is part of the schema configuration and
> it seems entirely appropriate to me to allow this to be in the
> subschema subentry (where it can be replicated).

I agree with this

David


***************************************************

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  Sat Sep 23 15:27:38 2000
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24268
	for ; Sat, 23 Sep 2000 15: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 e8NJFEC12996;
	Sat, 23 Sep 2000 12:15:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8NJPtU05962;
	Sat, 23 Sep 2000 12:25:55 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 12:25:55 -0700 (PDT)
Message-Id: <5.0.0.25.0.20000923114823.00a5fa50@router.boolean.net>
X-Sender: guru@router.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sat, 23 Sep 2000 12:24:51 -0700
To: d.w.chadwick@salford.ac.uk
From: "Kurt D. Zeilenga" 
Subject: Re: RFC 2596 questions
Cc: "Jim Sermersheim" , ,
        , ,
        
In-Reply-To: <39CC9E0B.12827.5AB37C@localhost>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"gYoSj.A.4cB.CPQz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 12:11 PM 9/23/00 +0100, David Chadwick wrote:
>> Yes, I'm reading "direct" into the 2251 statement.

So did I.  I did this also because of the specification of Attribute
Type Description in RFC 2252.  RFC2252 says that the NAME can
be an attribute description but only one SUPer type can be listed.
This implies that each attribute description has only one direct
super type (the attribute type without any options).

However, it seems that this is never used and conflicts with
common (and RFC2596) usage:  requesting "name;option" returns not
only name;option but also all subtypes (direct or indirect) of name
which have (or support) this option.  That is  "name;binary" requests
"name;binary" as well as "cn;binary", "sn;binary", etc.

>David has argued
>> that: cn;lang-en-US;lang-ja is a direct subtype of cn;lang-en-US,
>> which in turn is a direct subtype of cn. Does this also mean that it's
>> also a subtype of cn;lang-ja, 
>
>Yes, I would say so. The new dual language subtype is a subtype 
>of both single language subtypes. The order does not matter. We 
>have
>
>               supertype
>             /                  \
>subtype 1                    subtype 2
>              \                 /
>              subtype1-2

So (to clarify):

attr;a;b;c is a subtype of attr;a;b, attr;a;c, attr;b;c.
attr;a;b is a subtype of attr;a and attr;b
attr;a;c is a subtype of attr;a and attr;c
attr;b;c is a subtype of attr;b and attr;c
attr;a is a subtype of attr
attr;b is a subtype of attr
attr;c is a subtype of attr

And if:

attr is a subtype of super, then

attr;a;b;c is a subtype of super;a;b;c
...

If we had a entry containing attr and super with all combinations
of options a, b, and c; a request for super;a would return:
        super;a super;a;b super;a;b;c
        attr;a; attr;a;b attr;a;b;c

I would agree that RFC 2251 and RFC 2252 needs clarification in
this area.  I've cc'ed LDAPbis mailing list.

Kurt



From list@netscape.com  Sat Sep 23 15:30:00 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24279
	for ; Sat, 23 Sep 2000 15:29: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 e8NJMAX19632;
	Sat, 23 Sep 2000 12:22:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8NJSYc06956;
	Sat, 23 Sep 2000 12:28:34 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 12:28:34 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Thu, 21 Sep 2000 14:37:11 -0600
From: "Steven Merrill" 
To: "Steve Sonntag" , 
Cc: , "Alan Clark" 
Subject: ldap-java-api-11 search filter
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 e8NJSXr06932
Resent-Message-ID: <"0sfRCC.A.asB.hRQz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

In draft-ietf-ldapext-ldap-c-api-04.txt section 11.6 Searching, it states:

filter       A character string as described in [13], representing the
             search filter.  The value NULL can be passed to indicate
             that the filter "(objectclass=*)" which matches all entries
             is to be used.

It might be helpful to note this behavior in sections 4.38.1 and 4.39.12 of
draft-ietf-ldapext-ldap-java-api-11.txt. (Which would make those sections
consistent with 4.38.8 of the same draft which states that (objectclass=*)
is the default filter.)

Also, in the Bibliograpy, [7] should be updated. (To draft-ietf-ldapext-ldap-c-api-04.txt)

-Steve



From list@netscape.com  Sat Sep 23 15:31:12 2000
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24303
	for ; Sat, 23 Sep 2000 15:31: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 e8NJNMX19986;
	Sat, 23 Sep 2000 12:23:22 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8NJTlU07736;
	Sat, 23 Sep 2000 12:29:47 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 12:29:47 -0700 (PDT)
Message-Id: <5.0.0.25.0.20000923122747.00a6db70@router.boolean.net>
X-Sender: guru@router.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sat, 23 Sep 2000 12:29:39 -0700
To: 
From: "Kurt D. Zeilenga" 
Subject: Re: RFC 2596 questions
Cc: d.w.chadwick@salford.ac.uk, "Jim Sermersheim" ,
        , ,
        
In-Reply-To: <5.0.0.25.0.20000923114823.00a5fa50@router.boolean.net>
References: <39CC9E0B.12827.5AB37C@localhost>
 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"zJZo0D.A.m4B.pSQz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 12:24 PM 9/23/00 -0700, Kurt D. Zeilenga wrote:
>If we had a entry containing attr and super with all combinations
>of options a, b, and c; a request for super;a would return:
>        super;a super;a;b super;a;b;c

                and super;a,c

>        attr;a attr;a;b attr;a;b;c

                and attr;a;c




From list@netscape.com  Sun Sep 24 00:42:39 2000
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28932
	for ; Sun, 24 Sep 2000 00:42: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 e8O4ULC11213;
	Sat, 23 Sep 2000 21:30:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8O4f3g05078;
	Sat, 23 Sep 2000 21:41:03 -0700 (PDT)
Resent-Date: Sat, 23 Sep 2000 21:41:03 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hoytkesterson@mail.earthlink.net
Message-Id: 
Date: Sat, 23 Sep 2000 21:40:44 -0700
To: IETF LDAP 
From: "Hoyt L. Kesterson II" 
Subject: Fwd: Announcement of X.500 (including X.509) meeting
Cc: OSI Directory List 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Resent-Message-ID: <"9AmHfD.A.APB.dXYz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

hello to you in ldap land

david chadwick's recent email on feature discovery made me realize 
that although i had sent information about the upcoming x.500 meeting 
to the pkix list, i neglected to send it to you

An editing and rapporteur meeting will be held 13 through 17 November 
in Orlando, Florida.

Details can be found at

ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000/Meeting/6n1706Announcement.pdf

and

ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000/Meeting/6N1706AnnouncementAddendum.pdf

david's  email mentioned some new work we are beginning. the new work 
item (nwi) proposal on ldap alignment was recently approved and can 
be found at

ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000/NWIs/6n1538NWIforAlignmentToLDAP.pdf

other approved  NWIs can be found at

ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000/NWIs/

the agenda in the announcement shows that ldap alignment will be 
discussed on wednesday, 15 november. we welcome any representatives 
from the ietf ldap group.

   hoyt



From list@netscape.com  Sun Sep 24 12:28:05 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 SMTP id MAA09393
	for ; Sun, 24 Sep 2000 12:28: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 e8OGKBM25775;
	Sun, 24 Sep 2000 09:20:11 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8OGQaA25146;
	Sun, 24 Sep 2000 09:26:36 -0700 (PDT)
Resent-Date: Sun, 24 Sep 2000 09:26:36 -0700 (PDT)
X-Sender: real_money_4u@yahoo.com
From: "real_money_4u@yahoo.com" 
To: "Opt-in list" 
Date: Sun, 24 Sep 2000 17:25:08 +0100
Subject: How would you like to make $$$$$??
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: 
Resent-Message-ID: <"PKxlp.A.oIG.7siz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

This is it, the one program that counts out of the millions
of programs scattered around the net.

This is an opportunity you DO NOT want to miss! This company
is growing VERY fast and if you don't get in on this
early you will be kicking yourself in the future. This 
could be the next AllAdvantage or even the next Yahoo.

All you need is $69 and to refer 3 people. Once you refer the
3 people you get your money BACK. That's right.....you get
$23 per referal so if you refer 3 people you get $69! Now it is
very easy to refer 3 people so if your eager and you refer 10
people you make $230. It's as easy as that.

Oh and this goes 8 LEVELS DEEP so with 3 referals at level one you
can make $70,000 by the time you reach level 8. Imagine how much
you would make if you got 10 or even 20 referals at level 1!?!?

If you would like to pass on the one program that could actually
make you a substantial amount of money then please delete this. If
on the other hand you want to make the right choice and join a club
that will make you rich then please reply to this email with 
"THE RIGHT CHOICE" as the subject and I will send you more detailed
info about this once in a lifetime opportunity!

Thankyou for your time.

----------------------------------------------------------------------------
This message is sent in compliance of the new e-mail bill: 
SECTION 301. Per Section 301, paragraph (a)(2)(C) of S. 1618. 
This message is NOT Spam as long as you are provided with a way 
to remove your name from this mailing list. All further 
transmissions to you from me may be stopped at no cost to you 
by sending a reply to this email address with the word "REMOVE ME" 
in the subject line.
--------------------------------------------------------------------




From list@netscape.com  Sun Sep 24 16:20:03 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 SMTP id QAA10451
	for ; Sun, 24 Sep 2000 16:20: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 e8OK7rC03042;
	Sun, 24 Sep 2000 13:07:53 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8OKIc603884;
	Sun, 24 Sep 2000 13:18:38 -0700 (PDT)
Resent-Date: Sun, 24 Sep 2000 13:18:38 -0700 (PDT)
Date: Sun, 24 Sep 2000 22:18:15 +0200
Message-ID: 
To: opt-in703@020.co.uk
From: 
Subject: How you can make up to $1,500 a day
Resent-Message-ID: <"CePypD.A.a8.dGmz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



 From: Michelle Smith - publisher of the "Work From Home Opportunities" Newsletter
 Sunday, 3 p.m.

 Hello,

  	If you're interested in earning up to $1,500 a day
 	Then I want to share something with you...

 Now you can make up to $1,500 a day!

 Imagine you come home from a hard day's work (exhausted..)

 You immediately go straight to bed.  You get undressed,
 lay down, turn off the lights, and snuggle up face-down on
 the pillow.  A few moments later, you feel uncomfortable and
 stressed out so you lie on your back.

 When you look up at the ceiling, it's as if the ceiling has been removed!

 You see exactly what you would see if outside stargazing!
 A stunning, accurate 3-dimensional re-creation of the starry 
 night sky, including constellations such as the Big Dipper, 
 Pegasus and the Milky Way galaxy,

         ...and even shooting stars!

 You can't see it during the day.  The ceiling looks normal.
 But at night, when the lights are off, you see what looks
 like the sky outside!

 It's so relaxing and romantic.  And educational!

 And talk about stress-relief!  The moment you look at it,
 it'll melt your tension away faster than a great massage!

 Now how many people do you think would LOVE seeing this when
 they look up in their beds at night?

 "It's like you're sleeping under the stars!"

 Ok, I know you want to know How You Make Money.

 Here's how.

 You can put that awesome "convertible ceiling" in ANYONE'S 
 bedroom with a product cost to you of..

 Guess how much..

 Only ONE to TWO Dollars!  

 You offer this masterpiece for $100 - $1,500!
 Talk about *nice* profits!
 And it only takes you an hour or two!

 Here's an important point:

 These profits are similar to the profits of selling Information:
 the material costs next to nothing, but the customer really VALUES
 the END RESULT.  So the market value is more (a LOT more).

 "Who'd want this?"

 Anyone with a bedroom ceiling (or any ceiling),
 as well as homes, hotels, etc.

 Who do you know that has a bedroom ceiling?

 Whew!  The official money-making opportunity of the Millenium!
 (Well... we think it should be!)  |;-)

 Anyway, I know you want more information to make a decision, so ...

 To receive more FREE information on How To Make Up To $1,500 A Day,
 Simply Click On The Email Link Below and Send Back The Following:

 Mailto:stargazing28@newmail.net

 Name:
 E-Mail:
 Phone:
 Street:
 City:
 State:
 ZIP or Postal Code:
 Country (available INTERNATIONALLY):

 Mailto:stargazing28@newmail.net


 And you'll be sent the full details on
 how to make up to $1,500 a day, as well as 
 pictures of these murals so you can see 
 for yourself how breathtaking they are!

 Best regards,

 Michelle Smith

 P.S. We'll also send you a free Opportunity E-zine with 
 more interesting Money-Making Opportunities like this one, 
 and important info. for the home-based entrepreneur!

 P.P.S. Also, even though 99% of people don't know about this 
 opportunity, that won't be the case forever, so hurry up and 
 reply to make sure you get to lock down YOUR city!


 To unsubscribe mailto:optout924@newmail.net














From list@netscape.com  Sun Sep 24 22:40: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 SMTP id WAA13982
	for ; Sun, 24 Sep 2000 22:40: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 e8P2SVC28106;
	Sun, 24 Sep 2000 19:28:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8P2dGc10500;
	Sun, 24 Sep 2000 19:39:16 -0700 (PDT)
Resent-Date: Sun, 24 Sep 2000 19:39:16 -0700 (PDT)
Message-Id: 
Date: Sun, 24 Sep 2000 19:40:02 -0700
Reply-To: real-estate-center15@excite.com
To: yourmail@kagmca.comc.co.com
Subject: RE:Buying or Selling Your Home? -ightqwttq
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
From: real-estate-center10@jffr.excite.com
Resent-Message-ID: <"p4WOED.A.yjC.Trrz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

Dear Friend,

Being a 25yr practicing Real Estate Broker I discovered after retiring a 
closely guarded secret so phenomenal that I must share it with you! 

This Real Estate loophole allows the average person to start and operate 
a Real Estate business without a license. The best part of this program is
that you get to keep all of the money. You don’t have to split your profits 
with another Real Estate Agent or Broker.

Learn what real estate agents don't want you to know!

Here is some of what you will learn in this program "HOW TO SELL AND 
CONTROL REAL ESTATE WITHOUT A LICENSE OR MONEY".

YOU WILL: 

Learn how to control your deals from start to finish!

Learn how to sell your properties for full price every time by using 
Sub-Prime Lenders and make more money than you ever thought 
possible just by filling out one little piece of paper!

Learn how to access Mortgage Lenders who loan money to 
almost anyone who has a job regardless of past credit problems!

Learn how to access a mortgage with 3% interest without 
a credit check or closing fees! 

Learn how to create ownership rights in Real Estate without 
having to make Mortgage tax or insurance payments!

TO ORDER "HOW TO SELL AND CONTROL REAL ESTATEWITHOUT A LICENSE OR MONEY" 

Call Now! 1-480-990-4463

The book's retail value is $99.00. Order Today and receive for only 
$19.95 plus $4.95 for Priority Shipping.

---------------------------------------------------------
unsubscribers: Reply to this message with "unsubscribe" in subject line.
---------------------------------------------------------



From list@netscape.com  Mon Sep 25 00:36:34 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 SMTP id AAA15015
	for ; Mon, 25 Sep 2000 00:36: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 e8P4SfM11102;
	Sun, 24 Sep 2000 21:28:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8P4Z9Q03819;
	Sun, 24 Sep 2000 21:35:09 -0700 (PDT)
Resent-Date: Sun, 24 Sep 2000 21:35:09 -0700 (PDT)
To: opt-in@alloymail.com
From: 
Subject: Closing 1 out of 3 Sales ... Weekly Bonus Checks!
Message-Id: <200009250633140.SM00245@network>
Date: Mon, 25 Sep 2000 06:34:36 +0200
Resent-Message-ID: <"xE8pd.A.Z7.8Xtz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
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 
 * Training and support
 * Heavy-hitters close the sale and sign them up for you!
 * Hundreds signing up each day 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!
 * Established 16-year-old International Company 

 For more information please email your:

 NAME:
 Phone number:
 Best time to return your call:
  
 To Mailto:weeklychecks1@newmail.net


 To unsubscribe mailto:unsubscribe-1@newmail.net




From list@netscape.com  Mon Sep 25 02:09: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 SMTP id CAA27772
	for ; Mon, 25 Sep 2000 02:09: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 e8P614M16682;
	Sun, 24 Sep 2000 23:01:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8P67VQ20714;
	Sun, 24 Sep 2000 23:07:31 -0700 (PDT)
Resent-Date: Sun, 24 Sep 2000 23:07:31 -0700 (PDT)
Message-ID: <39CEEC62.F793684C@worldspot.com>
Date: Sun, 24 Sep 2000 23:10:43 -0700
From: Rob Weltman 
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,sv,ja
MIME-Version: 1.0
To: Steve Sonntag , Steven Merrill 
CC: ietf-ldapext@netscape.com, aclark@novell.com,
        Miodrag Kekic 
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com>
Content-Type: multipart/alternative;
 boundary="------------480A17C14EE6A0A3B94F7B2C"
Resent-Message-ID: <"rCwXD.A.YDF.iuuz5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


--------------480A17C14EE6A0A3B94F7B2C
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e8P614M16682
Content-Transfer-Encoding: quoted-printable

  I've collected all the issues raised (hope I didn't miss any) and respo=
nded in short to each one. Many thanks to Miodrag for helping me evaluate=
 the issues. And to Steve and Steven for raising them :-)

Rob


1.
> Section 4.39.13 LDAPV2.setOption
>
>  This method of the LDAPV2 interface seems a little strange.
>
>   1) It probably does not belong under the interface LDAPV2,
>      but instead under LDAPConnection. This would allow it
>      to support setting client & server controls which it
>      cannot do under LDAPV2.  This functionality is currently
>      missing in the method.
>
>      Setting STRING_FORMAT is also an LDAPV3 setting, as UTF-8
>      is only meaningful under LDAPV3.

  OK, but see 4 below (which renders this issue mute)


>   2) STRING_FORMAT is set only by the setOption method.
>      There should be a way to set or get STRING_FORMAT with
>      LDAPSearchConstraints methods.

  OK, but see 4 below (which renders this issue mute)


>   3) setOption operates only on the LDAPSearchConstraints object
>      that is associated with an LDAPConnection object.  Yet
>      there may also be an LDAPConstraints object associated
>      with the LDAPConnection object.  It may or may not be
>      the same as the LDAPSearchConstraints object.  Should
>      there be a setOption kind of method that operates on
>      the LDAPConstraints object associated with a connection?

  LDAPSearchConstraints extends LDAPConstraints. There is only one such o=
bject per connection, and it is an LDAPSearchConstraints. If there was an=
 LDAPConstraints object as well, there would be ambiguity as to which obj=
ect controlled operations other than search.   Also, see 4 below (which r=
enders this issue mute)


>   4) All functionality of SetOption can be performed by code
>      that references the LDAPSearchConstraints object of a
>      connection - i.e. LDAPConnection.getSearchConstraints.method().
>

  Yes, let's eliminate it.


2.
> If references to LDAPv2 are not removed from the draft,
> then the methods that were previously in LDAPAsynchronous
> Connection which are now in LDAPConnection - these methods
> should also be in one of the LDAPV2 or LDAPV3 interfaces
> to identify where they can be used.

  Let's eliminate the references to LDAPv2; the API will assume LDAPv3.


3.
>
>  In the java-api-11 I-D, an application doing asynchronous search
>  operations is confronted with two different data formats when handling
>  referrals and search continuation references.
>
>  When the application gets a referral status on a search operation,
>  referral URL information is retrieved by LDAPResponse.getReferrals()
>  as an array of String objects.
>
>  When the application gets search continuation references as part of
>  the search data, the continuation references are retrieved by
>  LDAPSearchResultReference.getURLs() as an array of LDAPUrl objects.
>
>  To be consistent, shouldn't both return an array of LDAPUrl objects?

Returning String[] seems more flexible. Steve has recognized that in one =
of his comments following this one. "...This is because the only way to g=
et the list is via the getURLs() method of the LDAPSearchResultReference.=
Perhaps it should return the  URLs as a string array, and let the applica=
tionturn them into LDAPUrl objects if desired.  This is backwards to what=
 I said in an earlier e-mail, butnow I see the need for Strings instead o=
f LDAPUrls".

So let's return String[] in both cases.


4.
> An application doing its own referral handling may need to make
>  decisions based on the scheme of URLs returned from search
>  continuation references or referrals.
>
>  Shouldn't the LDAPUrl object provide a method to retrieve
>  the URL scheme, viz. ldap, http, & etc.

This is an LDAP only URL and not a generic URL, so there is no reason to =
report a URL scheme. However, there is a need to support ldaps with some =
LDAP servers. To accomodate them, we propose a boolean method isSecure().


5.
> I am puzzled why the draft specifies that automatic referral
>  following is done only for synchronous operations.  While
>  it is simple for an application using async to merge results from
>  multiple listeners or to specify the same listener for multiple
>  requests, it is not so simple to determine when a request
>  and all its child referral requests are complete.  Why put
>  this burden on the application?
>
>  IMO there is no technical reason that automatic referral
>  following mechanisms cannot be used across the board,
>  for both synchronous and asynchronous operations.
>
>  Could you fill me in on the reason for the current design.

When originally implementing the asynchronous interfaces, we looked at th=
is option, but we concluded that implementation would be difficult, and t=
he asynchronous interfaces are intended to allow the client to interact w=
ith the protocol at a low level anyway, so it was not unreasonable for th=
e client to manage the interactions. SASL authentication is another featu=
re which is not handled automatically by the API for the asynchronous int=
erfaces, for the same reason.


6.
> Re: referrals as defined in draft-ietf-ldapext-ldap-java-api-11.txt
>
>  The I-D seems silent on what happens if an application has automatic
>  referral handling enabled, and for some reason one or more of the
>  referrals or search continuation references cannot be followed.
>
>  This could happen for at least three reasons:
>  1- The bind fails when explicitly binding using the LDAPBind object
>  2- The bind fails when implicitly binding using anonymous credentials,
>       or when using the LDAPRebind object to obtain credentials
>  3- None of the servers in the referrals list have the scheme ldap://
>     specified and thus are ignored (per the draft) (4.7.10)
>
>  I assume that if automatic referral following succeeds, the
>  application doesn't see any referral URLs, i.e. no LDAPReferralExcepti=
on
>  is thrown when doing LDAPSearchResults.next(), (4.35.4) and
>  LDAPSearchResults.nextElement() (4.35.5) does not return an
>  LDAPReferralException object.
>
>  The draft indicates that LDAPReferralException is only thrown
>  if automatic referral handling has not been enabled.  It doesn't
>  indicate whether the LDAPReferralException object is returned
>  on LDAPSearchResults.getElement(), I assume it is not returned. (4.26)
>
>  So what happens if a referral cannot automatically be followed.
>  I think the application needs to be notified of this error, and the
>  logical way to do that is to return the referral information to
>  the application.
>
>  IMO, LDAPReferralException should be returned / thrown on
>  synchronous operations any time a referral is not followed, not just
>  if automatic referral following is disabled.
>
>  Thus, LDAPReferralException would always be returned / thrown
>  if automatic referal following is not enabled.  If enabled,
>  LDAPReferralException would be thrown / returned when none of
>  the servers in a referral response list can be used to follow the refe=
rral
>  and would be treated by the application as an error situation.
>
>  Changing the draft to reflect this will  clear up these issues.

A good point, however there should be more info in the exception, so that=
 the application can clearly differentiate between a referral not being f=
ollowed and errors during automatic referral following. The actual LDAPEx=
ception that caused the referral following to fail (cannot connect, auth =
failed, no such object) could be stored in the LDAPReferralException. The=
 app can then simply check

catch (LDAPReferralException ex) {
    if (ex.getReferralFailureException() =3D=3D null) {
        // I am supposed to follow referrals
        LDAPUrls[] =3D ex.getURLs();
        ...
    } else {
        // The SDK could not follow the referral
        System.err.println("Failed to follow referral " + getUrls()[0] + =
" " +
            ex.getReferralFailureException());
    }


7.
>
>  I would like clarification on how LDAPBind vs LDAPRebind objects
>  are used in the Java API.
>
>  The I-D implies, but never quite says that the two objects don't
>  normally exist in the LDAPConstraints object at the same time.
>  (Implied by Appendix G - LDAPConstraints - they should
>  not be specified on the same constructor)
>
>  They certainly can both be set by using the set methods, but
>  are probably not both used at the same time.
>
>  I surmise from the draft that these objects are used as follows:
>
>  1. Neither object is used unless Referrals are enabled in the
>      LDAPConstraint object (automatic referral following enabled).
>
>  2. An LDAPRebind object is used only if present and if an LDAPBind
>      object is not present in the LDAPConstraint object.
>
>  3. An LDAPBind object is used if present.  If present, the LDAPRebind
>      object is not needed by LDAPConnection as no implicit binding is d=
one.
>      Explicit binding is the responsibility of the LDAPBind object.  Th=
erefore
>      the LDAPRebind object is not used in this case.
>
>  If my guesses are correct, maybe the draft should be clarified as to t=
he
>  usage of these objects.

This is a correct interpretation. An improvement to the I-D would be be t=
o specify a single field in LDAPConstraints - rebindHandler - which would=
 accept either LDAPBind or LDAPRebind. An additional tag interface would =
need to be declared, somthing like this:

public interface LDAPReferralHandler {  // the tag interface
}

public class LDAPConstraints {
     private LDAPReferralHandler rebindProc;
     ...
}

public interface LDAPBind extends LDAPReferralHandler {
...
}

public interface LDAPRebind extends LDAPReferralHandler {
...
}


8.
> Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt
>
>  It is unclear from the draft how the LDAPConnection object must be
>  used by an application implementing the LDAPBind interface.
>
>  I am guessing that the LDAPConnection object passed to the bind()
>  method of the LDAPBind implementation is a new LDAPConnection object
>  created by automatic referall following code in the original LDAPConne=
ction
>  object. The object contains the  AuthenticationDN and
>  AuthenticationPassword from the LDAPConnection that the continuation
>  reference was received on. The Host and Port are filled in from the
>  referral/reference host & port. When passed to the bind() method,
>  neither connect nor bind has been performed on this LDAPConnection obj=
ect.
>
>  In order to make this work, I believe the iimplementation of the
>  LDAPBind.bind() method MUST use the LDAPConnection object, which
>  was passed as a parameter, to perform its connect and bind calls.
>  It then returns success if both operations succeed.  The original
>  LDAPConnection object referral handling code can then use the
>  new LDAPConnection object when it resends the search request,
>  updated with the new search base and possibly search filter.
>
>  The above should be clarified in the draft.

  OK


>  It seems that the LDAPRebind interface would be easier to implement if
>  additional data were provided in the new LDAPConnection object.  Such =
as:
>
>  1. A reference to the LDAPSocketFactory class from the original LDAPCo=
nnection
>      object.  This allows it to connect in the same way as the original=
 connection.
>  2. An LDAPConstraints object containing a reference to the LDAPRebind =
object
>      from the original LDAPConnection object.  The LDAPBind.bind() meth=
od may
>      want to get authentication information using and LDAPRebindAuth ob=
ject, and
>      this gives it a way to do that.
>  3. The protocol version used in the connect/bind of the original objec=
t.  This allows
>      The LDAPBind.bind function to bind with same protocol version used=
 in the
>      original connection.
>  4. The mechanism used when binding.  This could be the mechanism used =
on the
>      bind in the original LDAPConnection object, or perhaps LDAPRebindA=
uth could
>      be modified to provide the triplet - UserDN, Password, and Mechani=
sm for the
>      specified host.
>
>  IMO the above changes would give the application, using explicit bind,=
 greater flexibility
>  when dealing with referrals / continuation references during automatic=
 referral
>  following:
>

  It's questionable that this is necessary. Can't you do all that with LD=
APBind (rather than LDAPRebind)?

  If it really is required (which duplicates what you can do with LDAPBin=
d), how about the following instead (let the implementation pull whatever=
 it needs from the original connection, as LDAPBind does)?

LDAPConnection bind(String ldapurl, LDAPConnection origConn);


9.  (from Kurt)
> You might consider renaming getSubTypes to getOptions as
> not all options (e.g. ;binary) are subtypes.

  Not worth changing, I don't think.


10.
> The I-D interchanges referrals and search continuation references.
>
>  A referral happens only on an operation and no other results are retur=
ned.
>
>  A search continuation reference happens only on a search and is mixed =
in with
>  returned search entries.
>
>  The I-D refers to continuation references only in section 2.2 and 2.34.
>
>  It sometimes uses referrals where search continuation references shoul=
d
>  be used, and generally where both apply.
>
>  Line 473 - referred to -> referred-to
>
>  The following should probably refer to both referrals and continuation=
 references
>  Section 1: line 459, 468
>  Section 2.2: LDAPRebind / LDAPBind
>  Section 2.3 - LDAPRebindAuth
>  Section 2.4 - LDAPReferralException
>  Section 4.4 - LDAPBind
>  Section 4.7.x - doReferrals / binder /reauth / hop_limit
>  Section 4.7.x - RebindProc, BindProc, Referrals
>      as well as the methods to get and set the above
>  Section 4.24 - LDAPRebindAuth
>  Section 4.25 - LDAPRebind
>  Section 4.26 - LDAPReferralException
>  Section 4.27 - LDAPResponse
>
>  The following refer to search references
>
>  Section 4.31.1 - LDAPSearchConstraints - doReferrals, reauth binder, h=
op_limit params
>  Section 4.35.4 - LDAPSearchResults.next()
>  Section 4.35.5 - LDAPSearchResults.nextElement()
>  Section 4.39.13 - SetOption ( search options relating to referrals)
>

Yes. The API makes the distinction transparent to the user of the API. Th=
e I-D could state that more explicitly.


11.
> Resend - properly indicating where comments are
>
> Steve Sonntag wrote:
>
> >  Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt I=
t
> > is unclear from the draft how the LDAPConnection object must beused b=
y
> > an application implementing the LDAPBind interface. I am guessing tha=
t
> > the LDAPConnection object passed to the bind()method of the LDAPBind
> > implementation is a new LDAPConnection objectcreated by automatic
> > referall following code in the original LDAPConnectionobject. The
> > object contains the  AuthenticationDN andAuthenticationPassword from
> > the LDAPConnection that the continuationreference was received on. Th=
e
> > Host and Port are filled in from thereferral/reference host & port.
> > When passed to the bind() method,neither connect nor bind has been
> > performed on this LDAPConnection object. In order to make this work, =
I
> > believe the iimplementation of theLDAPBind.bind() method MUST use the
> > LDAPConnection object, whichwas passed as a parameter, to perform its
> > connect and bind calls.It then returns success if both operations
> > succeed.  The originalLDAPConnection object referral handling code ca=
n
> > then use thenew LDAPConnection object when it resends the search
> > request,updated with the new search base and possibly search filter.
>
> It is also necessary that the application implementing the
> LDAPBind.bind()
> method use a synchronous bind do bind to the referred-to-server, or
> if using an asyncronous bind, it must wait until the bind operation has
> completed before returning status.

This is the same as #8.


12.
> Re: Referrals on operations as defined
>        in draft-ietf-ldapext-ldap-java-api-11.txt
>
>  When a referral occurs on an asynchronous operation
>     the referral is returned as an LDAPResponse object.
>     The referral info is obtained using the getReferrals() method.
>
>  When a referral occurs on a synchronous operation
>      An LDAPException is thrown.  The exception object is
>      specialized as an LDAPReferralException object and
>      the referral info can be obtained via the getURLs() method
>      with appropriate casting on the object.
>
>  Is this correct?
>
>  Should the doc be clarified?

Yes this is correct. For asynch interfaces exceptions are raised only for=
 connection errors. LDAP result messages are converted into LDAPResponse =
objects which are to be checked by the app for errors and referrals. Agai=
n, asynch interfaces operate at a low level, close to the protocol.


13.
>
>  Section 4.40.3: - LDAPv3.extendedOperation
>     Shouldn't this method have a method that
>     includes LDAPConstraints as an argument.
>    The protocol allows extended operations to
>    support controls.

OK.


>  Section 4.40.2 - LDAPV3.connect
>    This special version of connect is really
>    a connect and a bind combinded.  Should
>    this also have a method with an LDAPConstraints
>    object? - or if the application needs that
>    should they just do the two separate operations
>    and put the LDAPConstraints on the bind?

Let's remove the method from the I-D. It's just a convenience.


14.
>
>  I think the draft should describe more fully the
>  semantics of the implicit bind w/r automatic referral following:
>
>  I will describe what the I-D describes and where
>  I have questions:
>
>  1. Authentication - uses anonomyous credentials unless
>     LDAPRebind specified in LDAPConstraints.

Yes


>  2. Protocol Version ?? - Does it use the same protocol
>      version as the LDAPConnection receiving the referral or is it
>      always V2??  I vote for the having it the same as the originating
>      connection.

Yes.


>  3. AuthenticationMethod: Is it the same as the originating connection,
>      or is it "simple" - I assume simple is used.

Yes. LDAPBind must be used if SASL is desired for the referral connection.


>  4. Does it use the LDAPSocketFactory if specified on the
>      originating connection.  I am not sure what to do here.
>      It seems better to use it if available, then an encrypted
>      connection can be established and thus prevent
>      clear text password transmittion on the wire.  I just
>      talked myself into it - it should be used.

If the referral ldap url specifies ldaps, the referral connection should =
use ldaps (regardless of the original connection). At least in our implem=
entation :-) - since ldaps is being deprecated in favor of startTLS, we m=
ay not want to mention it in this I-D (I just remembered that I owe LDAPE=
XT an informational RFC draft on ldaps). For startTLS, I guess the referr=
al connection should attempt to use startTLS if the original connection w=
as in startTLS mode. Is there any other way to determine whether or not t=
o use startTLS?


15.
>  When performing a search it is possible for the server
>  to return multiple search continuation references, each
>  with a different search base.
>
>  The I-D states that when retrieving results from a
>  search using LDAPSearchResults.next() that all the
>  results are returned to the application after which
>  on the last call to next() an LDAPReferralException
>  is thrown.
>
>  My question is: how does the application get the
>  rest of the continuation references, as a
>  ReferralException object encapsulates the
>  reference list from one search continuation reply.
>
>  If the application did another next() call would
>  another LDAPReferralException be thrown?
>  How would the application know when to stop?
>  Does it check the enumeration count to see if
>  more items exist in the enumeration, and thus
>  continue to call next() and get an LDAPReferralException
>  each time.  As an alternative, the application
>  could switch to calling nextElement() to get the
>  rest of the search references as LDAPReferralException
>  objects.  How do you envision the application doing this?
>
>  The I-D should make it clear that the application
>  can get more than one search continuation
>  reference, and indicate a mechanism to deal
>  with the situation.
>

The app should continue as long as hasMoreElements() returns true. Callin=
g nextElement() is not a good idea. The following example from the Mozill=
a implemenation javadocs demonstrates proper handling. Note the "continue=
" after the exception has been processed.

LDAPSearchResults res =3D ld.search( MY_SEARCHBASE,
                              LDAPConnection.SCOPE_BASE, MY_FILTER,
                              null, false );
      while ( res.hasMoreElements() ) {
        try {
          LDAPEntry findEntry =3D res.next();
        } catch ( LDAPReferralException e ) {
          LDAPUrl refUrls[] =3D e.getURLs();
          for ( int i =3D 0; i < refUrls.length; i++ ) {
          // Your code for handling referrals
          }
          continue;
        } catch ( LDAPException e ) {
          // Your code for handling errors on limits exceeded
          continue;
        }
        ...
      }


16.
>
>  Since LDAPResponseListener and LDAPSearchListener
>  objects implement exactly the same set of methods,
>  does it seem reasonable that an interface be created
>  named something like LDAPListener that specifies
>  those four methods, and that LDAPSearchListener
>  and LDAPResponseListener implement this interface.
>  This forces those methods to stay the same in both classes.
>

> If an LDAPListener interface were created, then
> the two methods in LDAPv2.abandon
>
>    public void abandon(LDAPSearchListener listener)
>    public void abandon(LDAPResponseListener listener)
>
> Could be combined into one
>
>    public void abandon(LDAPListener listener)

We have responded to this earlier, but here is a brief recap. In the very=
 first asynch draft, LDAPSearchListener extended LDAPResponseListener. La=
ter when we adding abandon(int) method, we investigated removing LDAPSear=
chListener and leaving only LDAPResponseListener because there were imple=
mentation issues (multiplexing, and raising exceptions as a result of a l=
ost connection). Then, in order not to change the draft considerably, we =
decided to make only minor changes and just resolve the implementation pr=
oblems. We kept LDAPSearchListener, but it does not extend LDAPResponseLi=
stener any more.


17.
>
>  4.6.19 setConstraints
>
>  Sets the constraints that apply to all operations performed
>  through this connection
>
>  Wouldn't it be more clear to state:
>
>  Sets the constraints that apply to all non search operations
>  performed through this connection.
>  - - - - - - - - - - - - - - - - - - - -

The constraints (hop limit, bind handler, referrals, timeout, controls) a=
pply to all operations (including search operations).


>  4.39.13 setOption
>
>  Seems to set only the search constraints options, but
>  the first paragraph has a confusing sentence that
>  talks about LDAPConstraints.
>
>  Was it your intention that the LDAPConstraints be
>  the same object as LDAPSearchConstraints or
>  that they be different objects?
>
>     "These options represent the default search constraints for the
>     current connection. Some of these options are also propagated throu=
gh
>     the LDAPConstraints, which can be obtained from the connection obje=
ct
>     with the getSearchConstraints method."
>  The above two sections 4.39.13 & 4.6.19 could be
>  construed to indicate that the LDAPConstraints and the
>  LDAPSearchConstraints objects for a connection are
>  in fact the the same object, however, that fact that
>  each has a separate set & get method seems to indicate
>  they are different objects.
>
>  Could you please clarify this?
>

Yes this is intentional. Originally we had only LDAPSearchConstraints but=
 it did not make a lot of sense to use  "search" constraints for non-sear=
ch operations. We separated the interfaces such that LDAPSearchConstraint=
s extends LDAPConstraints and all properties set on LDAPConstraints are a=
lso visible in LDAPSearchConstraints.

But see 1.4 above.


18.
>
>  4.39.1 LDAPv2.abandon
>
>  The RFC 2251 and the C api draft allow controls to be specified
>  on an abandon operation.  In java it is allowed only using the default
>  constraints object or search constraints object.  Should methods
>  be defined that allow constraints to be specified on abandon?

Strictly speaking this is true, but if we look at the properties in LDAPC=
onstraints, none of them are applicable to abandon(). This change is not =
required.


>  When calling abandon( int id), it is unclear whether LDAPConstraints
>  or LDAPSearchConstraints should be used for the default
>  constraints.

LDAPSearchConstraints is only for search.


19.

> The JAVA LDAP API (draft-ietf-ldapext-ldap-java-api-11.txt) defines the=
 following method for
> extended operations:
>
>
> "public LDAPExtendedOperation extendedOperation(LDAPExtendedOperation o=
p) throws
> LDAPException"
>
> I would think that you would return an LDAPExtendedResponse object rath=
er than an
> LDAPExtendedOperation object. I agree that one could reuse the LDAPExte=
ndedOperation object
> (as it has the same set of fields) but then why bother defining a LDAPE=
xtendedResponse object
> in the draft?
>

OK.


20.

>  Section 4.7.11 LDAPConstraints.setTimeLimit
>
>  LDAP Constraints applies to all operations, not just search operations.
>
>  The first sentence should probably be changed from:
>
>       Sets the maximum number of milliseconds to wait for any operation
>       under these search constraints.
>  To something like:
>
>       Sets the maximum number of milliseconds the client waits for any =
operation
>       under these constraints.
>
>  Section 4.7.5 LDAPConstraints.getReferrals
>
>      Change nor to or
>
>      Specifies whether nor not ...
>
>  -Steve
>

OK.


21
LDAPSortKey.

> It is still listed in section 2.2
>
>  >>> Rob Weltman  01-Sep-00 2:59:45 PM >>>
>    Someone pointed out that LDAPSortKey is not used/referenced, so I re=
moved it from the draft.
>
>    In the Netscape implementation, it is used by LDAPSortControl. The c=
urrent API draft does not cover any particular controls.
>

OK


22.

> Re: LDAP_PARTIAL_RESULTS Result Code defined in
> section 4.16.6 of draft-ietf-ldapext-ldap-java-api-11.txt
>
> Section 4.16.6 instructs the reader to review RFC 2251 for
> a discussion of the meanings of the codes defined in that
> section.
>
> RFC 2251 does not discuss the meaning of the LDAP_PARTIAL_RESULTS
> result code. Should this be defined or referenced in this draft?
>
OK.


23.

> In the Bibliography, [3] refers to RFC 1960.
>
>  Shouldn't it refer to RFC 2254 instead?
>

OK.


24.


>  4.40.1
>
>  In the explaination of bind operations that use mechanisms should the =
first
>  Paragraph be changed from
>
>     Authenticates to the LDAP server (that the object is currently
>     connected to) using the specified name and of a specified set of
>     mechanisms. If none of the requested SASL mechanisms is available, =
an
>
>      Authenticates to the LDAP server (that the object is currently
>     connected to) using the specified name and ONE of a specified set o=
f  <----
>     mechanisms. If none of the requested SASL mechanisms is available, =
an
>

OK.


>  What does it mean -
>
>     if the first version of the method (i.e. the one that specifies no =
mechanism)
>     is called, the LDAP server will be interrogated for its
>     supportedSaslMechanisms attribute of its root DSE.
>
>  What does it do after the LDAP server is interrogated?  Does it use on=
e
>  of them, and if so how does the application know which one is used
>  and how does it know what kind of credentials to supply?
>

Yes, if no mechanisms are specified, the mechanisms supported by the serv=
er are processed until one is mutually agreed on. The callback handler is=
 called to obtain credentials. Are you thinking that the credentials to b=
e returned depend on the mechanism being negotiated? Let me think about t=
hat a little...


25.

>  4.40.1 bind specifying a mechanism
>
>  It would seem that if the mechanism is "simple"
>  that the API should specify how the password
>  is to be specified in the Hashtable object props
>  so that it is consistent across implementations.
>  Other mechanisms and associated Hashtable
>  values are the subject of other I-Ds.
>
>
>  My suggestions:
>
>        props.put("password", new String("user-password-value");)
>

  Credentials are obtained from the callback handler.


26.


> Shouldn't the SASL bind mechanisms also support the ability
> for the application to specify an LDAPConstraints
> object so that call specific controls can be specified?
>

OK.


27.

> When using an explicit bind for referrals where sasl mechanisms
> were used on the original LDAPConnection, the LDAPBind.bind()
> method will need access to the Hashtable parameter passed on the
> bind to get the credentials used.  A method needs to be
> supplied in LDAPConnection to get the Hashtable object with
> semantics similar to what is now used for getAuthenticationPassword()
>

  Does it need to be a public method? Can't it be a package scope (implem=
entation-defined) method?


28.

> I am trying to understand the encode/decode functions
>  in the LDAPUrl class.
>
>  I assume that the encode method turns unsafe characters
>  (as defined by RFC1738, RFC 2255, & etc.) into characters
>  of the form %HH and that decode turns those characters
>  back into the raw unencoded characters.
>
>  Question 1: The reference to decoding "+" into " "
>  and encoding " " into "+" .  I could not find any reference
>  to the need for doing this in the RFCs.  Could someone
>  please tell me why someone might expect that this behavior?
>
  " " does not need to be encoded in LDAP URLs.


>  Question 2:  What kind of strings do the constructors of the
>  LDAPUrl class expect.  Do the constructors expect the
>  strings to be already encoded?
>

  Yes.


>  Question 3:  Does the encode method take into account the field
>  in the URL when doing the encoding (e.g. filters vs. base DN) which
>  may have different reserved characters and thus slightly different
>  encoding rules =97 which boils down to the real question - does
>  the encode function expect a full correctly formatted URL
>  or can one hand it just the base-DN, or just the filter and
>  expect it to be correctly encoded?
>
>  i.e., does the LDAPUrl constructor with individual parts expect
>  encoded strings and will the encode function do it?
>

  LDAPUrl.encode() expects to receive a string to be encoded. For all pra=
ctical purposes, it should be a DN or a filter string (and not a full LDA=
P URL). After encoding, the DN and filter can be passed to the LDAPUrl co=
nstructor.


29.

> 4.16 LDAPException
>
>  The LDAPException class has a method getMatchedDN() but has no way to =
set
>  the matched DN in the object.  Shouldn't there be a constructor with M=
atchedDN
>  as a parameter?
>
> Steve,
>
>  I wouldn't think so.  This is really meant to provide access to what a=
 SERVER responds with, and thus I wouldn't know why a CLIENT would want t=
o
>  "setMatchedDN()".
>
>  Regards,
>  Tim Hahn
>
> I was thinking from the API perspective.  An implementation of the API =
would need to
>  take the ber encoded packet and extract from it the matched DN, and th=
en
>  generate the exception.  My point is that the API needs to be
>  able to set the matchedDN data in the exception.  Are you suggesting t=
hat it
>  should use a package method?  The only problem with a package method
>  is that an extension written in a different package may also need to s=
et
>  matchedDN when generating an exception, but wouldn't have any way
>  to set the value.
>

  Is that realistic - that a class in some other package would create an =
exception and put in its own matchedDN?


30.

> 4.26 LDAPException
>
>  I am trying to understand where the information in the
>  constructor serverMessage comes from.  I am not
>  aware of any message that is returned by the server with a
>  referral result, except for the actual referral URLs.
>
>  Do you intend that the class gets primed with the
>  referral URLs using the serverMessage parameter
>  and if so how are the referrals delimited - otherwise
>  can you elaborate on the meaning of this parameter
>  and explain how the referral URLs are placed into the
>  class.
>

  That is correct. The server returns the referral URLs in the message fi=
eld. I don't know if it is necessary to define the representation there (=
it is a contract between the upper layer of an implementation and the BER=
 decoding layer - which is not defined in the I-D); clients query getURLs=
() to get the URLs.


31.

> In draft-ietf-ldapext-ldap-c-api-04.txt section 11.6 Searching, it stat=
es:
>
> filter       A character string as described in [13], representing the
>              search filter.  The value NULL can be passed to indicate
>              that the filter "(objectclass=3D*)" which matches all entr=
ies
>              is to be used.
>
> It might be helpful to note this behavior in sections 4.38.1 and 4.39.1=
2 of
> draft-ietf-ldapext-ldap-java-api-11.txt. (Which would make those sectio=
ns
> consistent with 4.38.8 of the same draft which states that (objectclass=
=3D*)
> is the default filter.)
>
  OK.


32.

> Also, in the Bibliograpy, [7] should be updated. (To draft-ietf-ldapext=
-ldap-c-api-04.txt)
>
  OK.



--------------480A17C14EE6A0A3B94F7B2C
Content-Type: text/html; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e8P614M16682
Content-Transfer-Encoding: quoted-printable



  I've collected all the issues raised (hope I didn't miss any) and
responded in short to each one. Many thanks to Miodrag for helping me eva=
luate
the issues. And to Steve and Steven for raising them :-)

Rob

 

1.

> Section 4.39.13 LDAPV2.setOption

>

>  This method of the LDAPV2 interface seems a little strange.

>

>   1) It probably does not belong under the interface LDAP=
V2,

>      but instead under LDAPConnection. Thi=
s
would allow it

>      to support setting client & serve=
r
controls which it

>      cannot do under LDAPV2.  This
functionality is currently

>      missing in the method.

>

>      Setting STRING_FORMAT is also an LDAP=
V3
setting, as UTF-8

>      is only meaningful under LDAPV3.

  OK, but see 4 below (which renders this issue mute)

 

>   2) STRING_FORMAT is set only by the setOption method.

>      There should be a way to set or get
STRING_FORMAT with

>      LDAPSearchConstraints methods.

  OK, but see 4 below (which renders this issue mute)

 

>   3) setOption operates only on the LDAPSearchConstraints
object

>      that is associated with an LDAPConnec=
tion
object.  Yet

>      there may also be an LDAPConstraints
object associated

>      with the LDAPConnection object. 
It may or may not be

>      the same as the LDAPSearchConstraints
object.  Should

>      there be a setOption kind of method
that operates on

>      the LDAPConstraints object associated
with a connection?

  LDAPSearchConstraints extends LDAPConstraints. There is only
one such object per connection, and it is an LDAPSearchConstraints. If
there was an LDAPConstraints object as well, there would be ambiguity as
to which object controlled operations other than search.   Also=
,
see 4 below (which renders this issue mute)

 

>   4) All functionality of SetOption can be performed by
code

>      that references the LDAPSearchConstra=
ints
object of a

>      connection - i.e. LDAPConnection.getS=
earchConstraints.method().

>

  Yes, let's eliminate it.

 

2.

> If references to LDAPv2 are not removed from the draft,

> then the methods that were previously in LDAPAsynchronous

> Connection which are now in LDAPConnection - these methods

> should also be in one of the LDAPV2 or LDAPV3 interfaces

> to identify where they can be used.

  Let's eliminate the references to LDAPv2; the API will assume
LDAPv3.

 

3.

>

>  In the java-api-11 I-D, an application doing asynchronous sea=
rch

>  operations is confronted with two different data formats when
handling

>  referrals and search continuation references.

>

>  When the application gets a referral status on a search opera=
tion,

>  referral URL information is retrieved by LDAPResponse.getRefe=
rrals()

>  as an array of String objects.

>

>  When the application gets search continuation references as
part of

>  the search data, the continuation references are retrieved
by

>  LDAPSearchResultReference.getURLs() as an array of LDAPUrl
objects.

>

>  To be consistent, shouldn't both return an array of LDAPUrl
objects?

Returning String[] seems more flexible. Steve has recognized that in
one of his comments following this one. "...This is because the only
way to get the list is via the getURLs() method of the LDAPSearchResultRe=
ference.Perhaps
it should return the  URLs as a string array, and let the applicatio=
nturn
them into LDAPUrl objects if desired.  This is backwards to what I
said in an earlier e-mail, butnow I see the need for Strings instead of
LDAPUrls".

So let's return String[] in both cases.

 

4.

> An application doing its own referral handling may need to make

>  decisions based on the scheme of URLs returned from search

>  continuation references or referrals.

>

>  Shouldn't the LDAPUrl object provide a method to retrieve

>  the URL scheme, viz. ldap, http, & etc.

This is an LDAP only URL and not a generic URL, so there is no reason
to report a URL scheme. However, there is a need to support ldaps with
some LDAP servers. To accomodate them, we propose a boolean method isSecu=
re().

 

5.

> I am puzzled why the draft specifies that automatic referral

>  following is done only for synchronous operations.  Whil=
e

>  it is simple for an application using async to merge results
from

>  multiple listeners or to specify the same listener for multip=
le

>  requests, it is not so simple to determine when a request

>  and all its child referral requests are complete.  Why
put

>  this burden on the application?

>

>  IMO there is no technical reason that automatic referral

>  following mechanisms cannot be used across the board,

>  for both synchronous and asynchronous operations.

>

>  Could you fill me in on the reason for the current design.

When originally implementing the asynchronous interfaces, we looked
at this option, but we concluded that implementation would be difficult,
and the asynchronous interfaces are intended to allow the client to inter=
act
with the protocol at a low level anyway, so it was not unreasonable for
the client to manage the interactions. SASL authentication is another fea=
ture
which is not handled automatically by the API for the asynchronous interf=
aces,
for the same reason.

 

6.

> Re: referrals as defined in draft-ietf-ldapext-ldap-java-api-11.txt

>

>  The I-D seems silent on what happens if an application has
automatic

>  referral handling enabled, and for some reason one or more
of the

>  referrals or search continuation references cannot be followe=
d.

>

>  This could happen for at least three reasons:

>  1- The bind fails when explicitly binding using the LDAPBind
object

>  2- The bind fails when implicitly binding using anonymous cre=
dentials,

>       or when using the LDAPRebind
object to obtain credentials

>  3- None of the servers in the referrals list have the scheme
ldap://

>     specified and thus are ignored (per the dra=
ft)
(4.7.10)

>

>  I assume that if automatic referral following succeeds, the

>  application doesn't see any referral URLs, i.e. no LDAPReferr=
alException

>  is thrown when doing LDAPSearchResults.next(), (4.35.4) and

>  LDAPSearchResults.nextElement() (4.35.5) does not return an

>  LDAPReferralException object.

>

>  The draft indicates that LDAPReferralException is only thrown

>  if automatic referral handling has not been enabled. 
It doesn't

>  indicate whether the LDAPReferralException object is returned

>  on LDAPSearchResults.getElement(), I assume it is not returne=
d.
(4.26)

>

>  So what happens if a referral cannot automatically be followe=
d.

>  I think the application needs to be notified of this error,
and the

>  logical way to do that is to return the referral information
to

>  the application.

>

>  IMO, LDAPReferralException should be returned / thrown on

>  synchronous operations any time a referral is not followed,
not just

>  if automatic referral following is disabled.

>

>  Thus, LDAPReferralException would always be returned / thrown

>  if automatic referal following is not enabled.  If enabl=
ed,

>  LDAPReferralException would be thrown / returned when none
of

>  the servers in a referral response list can be used to follow
the referral

>  and would be treated by the application as an error situation.

>

>  Changing the draft to reflect this will  clear up these
issues.

A good point, however there should be more info in the exception, so
that the application can clearly differentiate between a referral not bei=
ng
followed and errors during automatic referral following. The actual LDAPE=
xception
that caused the referral following to fail (cannot connect, auth failed,
no such object) could be stored in the LDAPReferralException. The app can
then simply check

catch (LDAPReferralException ex) {

    if (ex.getReferralFailureException() =3D=3D nu=
ll)
{

        // I am supposed to
follow referrals

        LDAPUrls[] =3D ex.getU=
RLs();

        ...

    } else {

        // The SDK could not
follow the referral

        System.err.println("Fa=
iled
to follow referral " + getUrls()[0] + " " +

           =
;
ex.getReferralFailureException());

    }

 

7.

>

>  I would like clarification on how LDAPBind vs LDAPRebind obje=
cts

>  are used in the Java API.

>

>  The I-D implies, but never quite says that the two objects
don't

>  normally exist in the LDAPConstraints object at the same time.

>  (Implied by Appendix G - LDAPConstraints - they should

>  not be specified on the same constructor)

>

>  They certainly can both be set by using the set methods, but

>  are probably not both used at the same time.

>

>  I surmise from the draft that these objects are used as follo=
ws:

>

>  1. Neither object is used unless Referrals are enabled in the

>      LDAPConstraint object (automatic refe=
rral
following enabled).

>

>  2. An LDAPRebind object is used only if present and if an LDA=
PBind

>      object is not present in the LDAPCons=
traint
object.

>

>  3. An LDAPBind object is used if present.  If present,
the LDAPRebind

>      object is not needed by LDAPConnectio=
n
as no implicit binding is done.

>      Explicit binding is the responsibilit=
y
of the LDAPBind object.  Therefore

>      the LDAPRebind object is not used in
this case.

>

>  If my guesses are correct, maybe the draft should be clarifie=
d
as to the

>  usage of these objects.

This is a correct interpretation. An improvement to the I-D would be
be to specify a single field in LDAPConstraints - rebindHandler
- which would accept either LDAPBind or LDAPRebind. An additional tag int=
erface
would need to be declared, somthing like this:

public interface LDAPReferralHandler {  // the tag interface

}

public class LDAPConstraints {

     private LDAPReferralHandler rebindProc;

     ...

}

public interface LDAPBind extends LDAPReferralHandler {

...

}

public interface LDAPRebind extends LDAPReferralHandler {

...

}

 

8.

> Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt

>

>  It is unclear from the draft how the LDAPConnection object
must be

>  used by an application implementing the LDAPBind interface.

>

>  I am guessing that the LDAPConnection object passed to the
bind()

>  method of the LDAPBind implementation is a new LDAPConnection
object

>  created by automatic referall following code in the original
LDAPConnection

>  object. The object contains the  AuthenticationDN and

>  AuthenticationPassword from the LDAPConnection that the conti=
nuation

>  reference was received on. The Host and Port are filled in
from the

>  referral/reference host & port. When passed to the bind()
method,

>  neither connect nor bind has been performed on this LDAPConne=
ction
object.

>

>  In order to make this work, I believe the iimplementation of
the

>  LDAPBind.bind() method MUST use the LDAPConnection object,
which

>  was passed as a parameter, to perform its connect and bind
calls.

>  It then returns success if both operations succeed.  The
original

>  LDAPConnection object referral handling code can then use the

>  new LDAPConnection object when it resends the search request,

>  updated with the new search base and possibly search filter.

>

>  The above should be clarified in the draft.

  OK

 

>  It seems that the LDAPRebind interface would be easier to impl=
ement
if

>  additional data were provided in the new LDAPConnection objec=
t. 
Such as:

>

>  1. A reference to the LDAPSocketFactory class from the origin=
al
LDAPConnection

>      object.  This allows it to conne=
ct
in the same way as the original connection.

>  2. An LDAPConstraints object containing a reference to the
LDAPRebind object

>      from the original LDAPConnection obje=
ct. 
The LDAPBind.bind() method may

>      want to get authentication informatio=
n
using and LDAPRebindAuth object, and

>      this gives it a way to do that.

>  3. The protocol version used in the connect/bind of the origi=
nal
object.  This allows

>      The LDAPBind.bind function to bind
with same protocol version used in the

>      original connection.

>  4. The mechanism used when binding.  This could be the
mechanism used on the

>      bind in the original LDAPConnection
object, or perhaps LDAPRebindAuth could

>      be modified to provide the triplet
- UserDN, Password, and Mechanism for the

>      specified host.

>

>  IMO the above changes would give the application, using expli=
cit
bind, greater flexibility

>  when dealing with referrals / continuation references during
automatic referral

>  following:

>

  It's questionable that this is necessary. Can't you do all that
with LDAPBind (rather than LDAPRebind)?

  If it really is required (which duplicates what you can do with
LDAPBind), how about the following instead (let the implementation pull
whatever it needs from the original connection, as LDAPBind does)?

LDAPConnection bind(String ldapurl, LDAPConnection origConn);

 

9.  (from Kurt)

> You might consider renaming getSubTypes to getOptions as

> not all options (e.g. ;binary) are subtypes.

  Not worth changing, I don't think.

 

10.

> The I-D interchanges referrals and search continuation references.

>

>  A referral happens only on an operation and no other results
are returned.

>

>  A search continuation reference happens only on a search and
is mixed in with

>  returned search entries.

>

>  The I-D refers to continuation references only in section 2.2
and 2.34.

>

>  It sometimes uses referrals where search continuation referen=
ces
should

>  be used, and generally where both apply.

>

>  Line 473 - referred to -> referred-to

>

>  The following should probably refer to both referrals and con=
tinuation
references

>  Section 1: line 459, 468

>  Section 2.2: LDAPRebind / LDAPBind

>  Section 2.3 - LDAPRebindAuth

>  Section 2.4 - LDAPReferralException

>  Section 4.4 - LDAPBind

>  Section 4.7.x - doReferrals / binder /reauth / hop_limit

>  Section 4.7.x - RebindProc, BindProc, Referrals

>      as well as the methods to get and set
the above

>  Section 4.24 - LDAPRebindAuth

>  Section 4.25 - LDAPRebind

>  Section 4.26 - LDAPReferralException

>  Section 4.27 - LDAPResponse

>

>  The following refer to search references

>

>  Section 4.31.1 - LDAPSearchConstraints - doReferrals, reauth
binder, hop_limit params

>  Section 4.35.4 - LDAPSearchResults.next()

>  Section 4.35.5 - LDAPSearchResults.nextElement()

>  Section 4.39.13 - SetOption ( search options relating to refe=
rrals)

>

Yes. The API makes the distinction transparent to the user of the API.
The I-D could state that more explicitly.

 

11.

> Resend - properly indicating where comments are

>

> Steve Sonntag wrote:

>

> >  Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api=
-11.txt
It

> > is unclear from the draft how the LDAPConnection object must beus=
ed
by

> > an application implementing the LDAPBind interface. I am guessing
that

> > the LDAPConnection object passed to the bind()method of the LDAPB=
ind

> > implementation is a new LDAPConnection objectcreated by automatic

> > referall following code in the original LDAPConnectionobject. The

> > object contains the  AuthenticationDN andAuthenticationPassw=
ord
from

> > the LDAPConnection that the continuationreference was received
on. The

> > Host and Port are filled in from thereferral/reference host &
port.

> > When passed to the bind() method,neither connect nor bind has bee=
n

> > performed on this LDAPConnection object. In order to make this
work, I

> > believe the iimplementation of theLDAPBind.bind() method MUST use
the

> > LDAPConnection object, whichwas passed as a parameter, to perform
its

> > connect and bind calls.It then returns success if both operations

> > succeed.  The originalLDAPConnection object referral handlin=
g
code can

> > then use thenew LDAPConnection object when it resends the search

> > request,updated with the new search base and possibly search filt=
er.

>

> It is also necessary that the application implementing the

> LDAPBind.bind()

> method use a synchronous bind do bind to the referred-to-server,
or

> if using an asyncronous bind, it must wait until the bind operation
has

> completed before returning status.

This is the same as #8.

 

12.

> Re: Referrals on operations as defined

>        in draft-ietf-ldapext-lda=
p-java-api-11.txt

>

>  When a referral occurs on an asynchronous operation

>     the referral is returned as an LDAPResponse
object.

>     The referral info is obtained using the get=
Referrals()
method.

>

>  When a referral occurs on a synchronous operation

>      An LDAPException is thrown.  The
exception object is

>      specialized as an LDAPReferralExcepti=
on
object and

>      the referral info can be obtained via
the getURLs() method

>      with appropriate casting on the objec=
t.

>

>  Is this correct?

>

>  Should the doc be clarified?

Yes this is correct. For asynch interfaces exceptions are raised only
for connection errors. LDAP result messages are converted into LDAPRespon=
se
objects which are to be checked by the app for errors and referrals. Agai=
n,
asynch interfaces operate at a low level, close to the protocol.

 

13.

>

>  Section 4.40.3: - LDAPv3.extendedOperation

>     Shouldn't this method have a method that

>     includes LDAPConstraints as an argument.

>    The protocol allows extended operations to

>    support controls.

OK.

 

>  Section 4.40.2 - LDAPV3.connect

>    This special version of connect is really

>    a connect and a bind combinded.  Should

>    this also have a method with an LDAPConstraints

>    object? - or if the application needs that

>    should they just do the two separate operations

>    and put the LDAPConstraints on the bind?

Let's remove the method from the I-D. It's just a convenience.

 

14.

>

>  I think the draft should describe more fully the

>  semantics of the implicit bind w/r automatic referral followi=
ng:

>

>  I will describe what the I-D describes and where

>  I have questions:

>

>  1. Authentication - uses anonomyous credentials unless

>     LDAPRebind specified in LDAPConstraints.

Yes

 

>  2. Protocol Version ?? - Does it use the same protocol

>      version as the LDAPConnection receivi=
ng
the referral or is it

>      always V2??  I vote for the havi=
ng
it the same as the originating

>      connection.

Yes.

 

>  3. AuthenticationMethod: Is it the same as the originating con=
nection,

>      or is it "simple" - I assume simple
is used.

Yes. LDAPBind must be used if SASL is desired for the referral connect=
ion.

 

>  4. Does it use the LDAPSocketFactory if specified on the

>      originating connection.  I am
not sure what to do here.

>      It seems better to use it if availabl=
e,
then an encrypted

>      connection can be established and thu=
s
prevent

>      clear text password transmittion on
the wire.  I just

>      talked myself into it - it should be
used.

If the referral ldap url specifies ldaps, the referral connection shou=
ld
use ldaps (regardless of the original connection). At least in our implem=
entation
:-) - since ldaps is being deprecated in favor of startTLS, we may not
want to mention it in this I-D (I just remembered that I owe LDAPEXT an
informational RFC draft on ldaps). For startTLS, I guess the referral con=
nection
should attempt to use startTLS if the original connection was in startTLS
mode. Is there any other way to determine whether or not to use startTLS?

 

15.

>  When performing a search it is possible for the server

>  to return multiple search continuation references, each

>  with a different search base.

>

>  The I-D states that when retrieving results from a

>  search using LDAPSearchResults.next() that all the

>  results are returned to the application after which

>  on the last call to next() an LDAPReferralException

>  is thrown.

>

>  My question is: how does the application get the

>  rest of the continuation references, as a

>  ReferralException object encapsulates the

>  reference list from one search continuation reply.

>

>  If the application did another next() call would

>  another LDAPReferralException be thrown?

>  How would the application know when to stop?

>  Does it check the enumeration count to see if

>  more items exist in the enumeration, and thus

>  continue to call next() and get an LDAPReferralException

>  each time.  As an alternative, the application

>  could switch to calling nextElement() to get the

>  rest of the search references as LDAPReferralException

>  objects.  How do you envision the application doing this=
?

>

>  The I-D should make it clear that the application

>  can get more than one search continuation

>  reference, and indicate a mechanism to deal

>  with the situation.

>

The app should continue as long as hasMoreElements() returns true. Cal=
ling
nextElement() is not a good idea. The following example from the Mozilla
implemenation javadocs demonstrates proper handling. Note the "continue"
after the exception has been processed.

LDAPSearchResults res =3D ld.search( MY_SEARCHBASE,

           =
;            =
      
LDAPConnection.SCOPE_BASE, MY_FILTER,

           =
;            =
      
null, false );

      while ( res.hasMoreElements() )
{

        try {

          LDAPEntry
findEntry =3D res.next();

        } catch ( LDAPReferral=
Exception
e ) {

          LDAPUrl
refUrls[] =3D e.getURLs();

          for ( int
i =3D 0; i < refUrls.length; i++ ) {

          // Your
code for handling referrals

          }

          continue;<=
/tt>

        } catch ( LDAPExceptio=
n
e ) {

          // Your
code for handling errors on limits exceeded

          continue;<=
/tt>

        }

        ...

      }

 

16.

>

>  Since LDAPResponseListener and LDAPSearchListener

>  objects implement exactly the same set of methods,

>  does it seem reasonable that an interface be created

>  named something like LDAPListener that specifies

>  those four methods, and that LDAPSearchListener

>  and LDAPResponseListener implement this interface.

>  This forces those methods to stay the same in both classes.

>

> If an LDAPListener interface were created, then

> the two methods in LDAPv2.abandon

>

>    public void abandon(LDAPSearchListener listener)

>    public void abandon(LDAPResponseListener listener=
)

>

> Could be combined into one

>

>    public void abandon(LDAPListener listener)

We have responded to this earlier, but here is a brief recap. In the
very first asynch draft, LDAPSearchListener extended LDAPResponseListener.
Later when we adding abandon(int) method, we investigated removing LDAPSe=
archListener
and leaving only LDAPResponseListener because there were implementation
issues (multiplexing, and raising exceptions as a result of a lost connec=
tion).
Then, in order not to change the draft considerably, we decided to make
only minor changes and just resolve the implementation problems. We kept
LDAPSearchListener, but it does not extend LDAPResponseListener any more.

 

17.

>

>  4.6.19 setConstraints

>

>  Sets the constraints that apply to all operations performed

>  through this connection

>

>  Wouldn't it be more clear to state:

>

>  Sets the constraints that apply to all non search operations

>  performed through this connection.

>  - - - - - - - - - - - - - - - - - - - -

The constraints (hop limit, bind handler, referrals, timeout, controls=
)
apply to all operations (including search operations).

 

>  4.39.13 setOption

>

>  Seems to set only the search constraints options, but

>  the first paragraph has a confusing sentence that

>  talks about LDAPConstraints.

>

>  Was it your intention that the LDAPConstraints be

>  the same object as LDAPSearchConstraints or

>  that they be different objects?

>

>     "These options represent the default search
constraints for the

>     current connection. Some of these options
are also propagated through

>     the LDAPConstraints, which can be obtained
from the connection object

>     with the getSearchConstraints method."

>  The above two sections 4.39.13 & 4.6.19 could be

>  construed to indicate that the LDAPConstraints and the

>  LDAPSearchConstraints objects for a connection are

>  in fact the the same object, however, that fact that

>  each has a separate set & get method seems to indicate

>  they are different objects.

>

>  Could you please clarify this?

>

Yes this is intentional. Originally we had only LDAPSearchConstraints
but it did not make a lot of sense to use  "search" constraints for
non-search operations. We separated the interfaces such that LDAPSearchCo=
nstraints
extends LDAPConstraints and all properties set on LDAPConstraints are als=
o
visible in LDAPSearchConstraints.

But see 1.4 above.

 

18.

>

>  4.39.1 LDAPv2.abandon

>

>  The RFC 2251 and the C api draft allow controls to be specifi=
ed

>  on an abandon operation.  In java it is allowed only usi=
ng
the default

>  constraints object or search constraints object.  Should
methods

>  be defined that allow constraints to be specified on abandon?

Strictly speaking this is true, but if we look at the properties in
LDAPConstraints, none of them are applicable to abandon(). This change
is not required.

 

>  When calling abandon( int id), it is unclear whether LDAPConst=
raints

>  or LDAPSearchConstraints should be used for the default

>  constraints.

LDAPSearchConstraints is only for search.

 

19.



The JAVA LDAP API (draft-ietf-ldapext-ldap-java-api-11.txt) defines =
the following method for
extended operations:


"public LDAPExtendedOperation extendedOperation(LDAPExtendedOperation op)=
 throws
LDAPException"

I would think that you would return an LDAPExtendedResponse object rather=
 than an
LDAPExtendedOperation object. I agree that one could reuse the LDAPExtend=
edOperation object
(as it has the same set of fields) but then why bother defining a LDAPExt=
endedResponse object
in the draft?






OK.

 

20.



 Section 4.7.11 LDAPConstraints.setTimeLimit
  
 LDAP Constraints applies to all operations, not just search operati=
ons.
  
 The first sentence should probably be changed from:
  
      Sets the maximum number of milliseconds to=
 wait for any operation
      under these search constraints.
 To something like:
  
      Sets the maximum number of milliseconds th=
e client waits for any operation
      under these constraints.
  
 Section 4.7.5 LDAPConstraints.getReferrals
  
     Change nor to or
  
     Specifies whether nor not ...
  
 -Steve






OK.

 

21

LDAPSortKey.



It is still listed in section 2.2

 >>> Rob Weltman  01-Sep-00 2:59:45 PM >>>
   Someone pointed out that LDAPSortKey is not used/referenced,=
 so I removed it from the draft. 

   In the Netscape implementation, it is used by LDAPSortContro=
l. The current API draft does not cover any particular controls.






OK

 

22.



Re: LDAP_PARTIAL_RESULTS Result Code defined in
section 4.16.6 of draft-ietf-ldapext-ldap-java-api-11.txt

Section 4.16.6 instructs the reader to review RFC 2251 for
a discussion of the meanings of the codes defined in that
section.

RFC 2251 does not discuss the meaning of the LDAP_PARTIAL_RESULTS
result code. Should this be defined or referenced in this draft?



OK.

 

23.



In the Bibliography, [3] refers to RFC 1960.
  
 Shouldn't it refer to RFC 2254 instead?






OK.

 

24.

 



 4.40.1
  
 In the explaination of bind operations that use mechanisms should t=
he first
 Paragraph be changed from 
  
    Authenticates to the LDAP server (that the object is c=
urrently
    connected to) using the specified name and of a specif=
ied set of
    mechanisms. If none of the requested SASL mechanisms i=
s available, an

     Authenticates to the LDAP server (that the objec=
t is currently
    connected to) using the specified name and ONE of a sp=
ecified set of  <----
    mechanisms. If none of the requested SASL mechanisms i=
s available, an






OK.

 



 What does it mean -
  
    if the first version of the method (i.e. the one that =
specifies no mechanism)
    is called, the LDAP server will be interrogated for it=
s
    supportedSaslMechanisms attribute of its root DSE.
  
 What does it do after the LDAP server is interrogated?  Does i=
t use one
 of them, and if so how does the application know which one is used
 and how does it know what kind of credentials to supply?






Yes, if no mechanisms are specified, the mechanisms supported by
the server are processed until one is mutually agreed on. The callback
handler is called to obtain credentials. Are you thinking that the creden=
tials
to be returned depend on the mechanism being negotiated? Let me think abo=
ut
that a little...

 

25.



 4.40.1 bind specifying a mechanism
  
 It would seem that if the mechanism is "simple"
 that the API should specify how the password
 is to be specified in the Hashtable object props
 so that it is consistent across implementations.
 Other mechanisms and associated Hashtable
 values are the subject of other I-Ds.
  
  
 My suggestions:
  
       props.put("password", new String("us=
er-password-value");)






  Credentials are obtained from the callback handler.

 

26.

 



Shouldn't the SASL bind mechanisms also support the ability
for the application to specify an LDAPConstraints
object so that call specific controls can be specified?






OK.

 

27.



When using an explicit bind for referrals where sasl mechanisms =
;
were used on the original LDAPConnection, the LDAPBind.bind()
method will need access to the Hashtable parameter passed on the
bind to get the credentials used.  A method needs to be
supplied in LDAPConnection to get the Hashtable object with
semantics similar to what is now used for getAuthenticationPassword()





  Does it need to be a public method? Can't it be a package
scope (implementation-defined) method?

 

28.



I am trying to understand the encode/decode functions
 in the LDAPUrl class.
  
 I assume that the encode method turns unsafe characters
 (as defined by RFC1738, RFC 2255, & etc.) into characters
 of the form %HH and that decode turns those characters
 back into the raw unencoded characters.
  
 Question 1: The reference to decoding "+" into " "
 and encoding " " into "+" .  I could not find any reference
 to the need for doing this in the RFCs.  Could someone
 please tell me why someone might expect that this behavior?



  " " does not need to be encoded in LDAP URLs.

 



 Question 2:  What kind of strings do the constructors of =
the
 LDAPUrl class expect.  Do the constructors expect the 
 strings to be already encoded?






  Yes.

 



 Question 3:  Does the encode method take into account the=
 field
 in the URL when doing the encoding (e.g. filters vs. base DN) which
 may have different reserved characters and thus slightly different
 encoding rules =97 which boils down to the real question - does&nbs=
p;
 the encode function expect a full correctly formatted URL
 or can one hand it just the base-DN, or just the filter and
 expect it to be correctly encoded?
  
 i.e., does the LDAPUrl constructor with individual parts expect&nbs=
p;
 encoded strings and will the encode function do it?






  LDAPUrl.encode() expects to receive a string to be encoded.
For all practical purposes, it should be a DN or a filter string (and not
a full LDAP URL). After encoding, the DN and filter can be passed to the
LDAPUrl constructor.

 

29.



4.16 LDAPException
  
 The LDAPException class has a method getMatchedDN() but has no way =
to set
 the matched DN in the object.  Shouldn't there be a constructo=
r with MatchedDN
 as a parameter?







Steve, 

 I wouldn't think so.  This is really meant to provide access t=
o what a SERVER responds with, and thus I wouldn't know why a CLIENT woul=
d want to
 "setMatchedDN()".

 Regards,
 Tim Hahn







I was thinking from the API perspective.  An implementation of =
the API would need to
 take the ber encoded packet and extract from it the matched DN, and=
 then 
 generate the exception.  My point is that the API needs to be
 able to set the matchedDN data in the exception.  Are you sugg=
esting that it
 should use a package method?  The only problem with a package =
method
 is that an extension written in a different package may also need t=
o set 
 matchedDN when generating an exception, but wouldn't have any way
 to set the value.






  Is that realistic - that a class in some other package woul=
d
create an exception and put in its own matchedDN?

 

30.



4.26 LDAPException
  
 I am trying to understand where the information in the
 constructor serverMessage comes from.  I am not
 aware of any message that is returned by the server with a
 referral result, except for the actual referral URLs.
  
 Do you intend that the class gets primed with the 
 referral URLs using the serverMessage parameter
 and if so how are the referrals delimited - otherwise
 can you elaborate on the meaning of this parameter
 and explain how the referral URLs are placed into the
 class.






  That is correct. The server returns the referral URLs in
the message field. I don't know if it is necessary to define the represen=
tation
there (it is a contract between the upper layer of an implementation and
the BER decoding layer - which is not defined in the I-D); clients query
getURLs() to get the URLs.

 

31.



In draft-ietf-ldapext-ldap-c-api-04.txt section 11.6 Searching, it s=
tates:

filter       A character string as describe=
d in [13], representing the
             =
search filter.  The value NULL can be passed to indicate
             =
that the filter "(objectclass=3D*)" which matches all entries
             =
is to be used.

It might be helpful to note this behavior in sections 4.38.1 and 4.39.12 =
of
draft-ietf-ldapext-ldap-java-api-11.txt. (Which would make those sections
consistent with 4.38.8 of the same draft which states that (objectclass=3D=
*)
is the default filter.)




  OK.

 

32.



Also, in the Bibliograpy, [7] should be updated. (To draft-ietf-ldap=
ext-ldap-c-api-04.txt)



  OK.

 

 

--------------480A17C14EE6A0A3B94F7B2C--



From list@netscape.com  Mon Sep 25 12:04: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 SMTP id MAA07041
	for ; Mon, 25 Sep 2000 12:04: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 e8PFsaM11597;
	Mon, 25 Sep 2000 08:54:37 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8PG12216596;
	Mon, 25 Sep 2000 09:01:02 -0700 (PDT)
Resent-Date: Mon, 25 Sep 2000 09:01:02 -0700 (PDT)
Date: Mon, 25 Sep 2000 09:00:48 -0700 (PDT)
Message-Id: <200009251600.e8PG0bH13812@ywing.netscape.com>
From: yvqvk@skiinfo.no
Reply-To: skiinfo.no@ywing.netscape.com
To: nphck@skiinfo.no
Subject: $46,000 in next the 90 days                                                   vvded
Resent-Message-ID: <"-vqrPC.A.VBE.6a3z5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hello ,
You can earn $46,000 or more in next the 90 days sending e-mail.

Seem impossible? Read on for details (no, there is no "catch")...

"AS SEEN ON NATIONAL TV"

Thank you for your time and Interest.
This is the letter you've been reading 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 has been truly remarkable. So many people are participating that those involved are doing, much better than ever before.
Since everyone makes more as more people try it out,its been very exciting to be a part of lately. 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 REMENDOUS!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $46,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 intocontact 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 multi-level e-mail order marketing program works perfectly...100% EVERY TIME. Email 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 action!!!

MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and 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 mid to late 1990's.

This is a Multi-Billion Dollar industry and of the 3,500,000 millionaires in the WORLD, 20%( 700,000) made their fortune in the last several years in MLM. Moreover, statistics show that over 100 people become millionaires everyday through Multi-Level Marketing.

You may have heard this story before, but over the summer Donald Trump (A MULTI-MILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) 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.

This program is currently being utilized in more than 50 different countries across the world.

The enclosed INF0RMATION 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 Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After 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
$35,000. The economy was taking a toll on my business and 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 FOREVER FINANCIALLY!!!

In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for INF0RMATION 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 book to make it!
But like 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 US 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 100,000 e-mails. It cost me about $15 for my time on-line. 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 am telling you like 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 $46,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 $46,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 100,000, I received $42,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 $46,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 fellow business owner and are if financial trouble like I was, or you want to start your own business, consider this a sign. I DID!

Sincerely,
Johnathon Rourke
---------------------------------------------------------
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, and 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",inflation will see to that.

You have just received INF0RMATION 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 1,600,000 programs. Now I have several offices that make this and several other programs
here and over seas.

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 100,000 or more...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, INF0RMATION, materials and opportunity to become financially independent, IT IS UP TO YOU NOW!

"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 DOLLAR$
INSTRUCTIONS:
This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $46,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. Because of the global nature of the internet, you will be able to recruit new multi-level business partners from all over the world, 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 5 reports shown on the list below(you can't sell them if you don't order them).

a. 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!

b. When you place your order, make sure you order each of the five reports.
You will need all five reports so that you can save them on your computer and resell them.

c. Within a few days you will receive, via e-mail, each of the five 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 "g" 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 five reports, take this advertisement and REM0VE the name and
address under REPORT #5. This person has made it through the
cycle and is no doubt counting their $46,000! Also, change the name of the company,the address, and the REM0VE e-mail address on the top of this document to your own.

c. Move the name and address under REPORT #4 down to REPORT #5.

d. Move the name and address under REPORT #3 down to REPORT #4.

e. Move the name and address under REPORT #2 down to REPORT #3.

f. Move the name and address under REPORT #1 down to REPORT #2.

g.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.

Your cost to participate in this is practically nothing (surely you can afford $25).You obviously already have an Internet connection and e-mail is FREE!

To assist you with marketing your business on the internet, the 5 reports you purchase will
provide you with invaluable marketing INF0RMATION which
includes how to send bulk e-mails, where to find thousands of free classified ads and much,much more.

In addition you will be provided with INF0RMATION on Internet Marketing Clubs such as INTERNET MARKETING RESOURCES(IMR): This is one the premiere internet marketing clubs on the INTERNET. This club provides a forum where internet marketers from all over the world can exchange ideas and secrets on Internet Marketing. In addition, members of this club are provided free internet marketing tools and services for the Do-Yourself-Internet-Marketer.

They will provide you with free bulk e-mail software and up to 1,000,000 fresh e-mail addresses each week. This club will provide you with hundreds of free resources which include: How to obtain free web sites,how to obtain top rankings in search engines for your web-site, how to send bulk e-mail into AOL and CompuServe, how to market your products on newsgroups, free classified ads, electronic malls, bulletin boards, banner ads and much
more.

There are two primary methods of building your downline:

METHOD #1: SENDING BULK E-MAIL

Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.3% response. Using a good list the response could be much better.Also, many
people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example,
you send out only 2,000 programs. With a 0.3% response, that is only 6 orders for REPORT #1. Those 6 people respond by sending out 2,000 programs each for a total of 12,000. Out of those 0.3%, 36 people respond and order
REPORT #2. Those 36 mail out 2,000 programs each for a total of 72,000. The 0.3% response to that is 216 orders for REPORT #3. Those 216 send out 2,000 programs each for a 432,000 total. The 0.3% response to that is 1,296 orders for REPORT #4. Those 1,296 send out 2,000 programs each for a 2,592,000 total.The 0.3% response to that is 7,776 orders for REPORT #5.

That's 7,776 $5 bills for you, CASH!!! Your total income in this example is$30 + $180 + $1,080+ $6,480 + $38,880 for a total of $46,650!!!

REMEMBER, THIS IS ASSUMING 1,994 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is
practically nothing. You obviously already have an internet connection and e-mail is FREE!!!

REPORT #2 and #5 will show you the best methods for bulk emailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists and show you how to send out 1,000,000 e-mails for free.

METHOD #2 - PLACING FREE ADS ON THE INTERNET

1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see
how well it works. Assume your goal is to get ONLY 6 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 6 downline members. Follow this example to achieve the STAGGERING results below.

1st level--your 6 members with $5 ($5 x 6).......................$30
2nd level--6 members from those 6 ($5 x 36)...................$180
3rd level--6 members from those 36 ($5 x 216)............ $1,080
4th level--6 members from those 216 ($5 x 1,296)........ $6,480
5th level-6 members from those 1,296 ($5 x 7,776)... .$38,880
........$46,650
_________________________________________________________________________

Remember, this assumes that the people who participate only recruit 6 people each.Think for a moment what would happen if they got 20 people to participate! Many people will get 100's of participants! THINK ABOUT IT!

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 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!
_________________________________________________________AVAILABLE REPORTS
_________________________________________________________
*** Order Each REPORT by NUMBER and NAME ***

Notes:
ALWAYS SEND $5 CASH (US CURRENCY) FOR EACH REPORT CHECKS NOT ACCEPTED ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL 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 name & postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW:
______________________________________________________

REPORT #1 "Writing Powerful Classified Ads"

ORDER REPORT #1 FROM:

Martha Matlock
10052 E 470 Rd.
Claremore, Ok 74017
---------------------------------------------------------
REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet"
ORDER REPORT #2 FROM:

Dr.Rik Rodriguez
Po.Bx 269
Shiocton Wi.54170
---------------------------------------------------------
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"

ORDER REPORT #3 FROM:

John Rosanbalm
10624 La Vernia Rd.
Adkins, TX 98101

__________________________________________________
REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet"

ORDER REPORT #4 FROM
Ken Thiesse
3001 Searsdale Ave
Cleveland, Ohio 44109
______________________________________________________

:REPORT #5 "How to SEND 1,000,000 e-mails for FREE"

ORDER REPORT #5 FROM:

Angelo Tirico
5015 River Road
New Port Richey, Fl 34652

______________________________________________________

There currently more than 175,000,000 people on-line worldwide!

******* TIPS FOR SUCCESS *******

* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions
accurately.

* Send for the five 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.

* ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.

* Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL!

* ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

******* YOUR SUCCESS GUIDELINES *******

Follow these guidelines to guarantee your success:

If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails 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 or sending e-mails 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 will 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 or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business!

Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program:

1.YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE!

2.YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP!

3.YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE!

4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO
DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD!

5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $25 INVESTMENT IS YOUR TIME!

6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT!

******* 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. Fred Dellaca, Westport, New Zealand

My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major US Corporation and I make pretty good money.When I received the program I grumbled to Jody 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. Jody 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 Jody 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. Mitchell Wolf MD., Chicago, IL

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.
Sincerely yours, Pam Hedland Halmstad,
Sweden

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. I surprised when I found my medium-size post office
box crammed with orders! For awhile,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 deal is that it doesn't matter where people live.There simply isn't a better investment with a faster return.
Dan Sondstrom, Alberta, Canada

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!!
Mohamed, Cairo, Egypt

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! Sam Lee Suva, Fiji Islands

ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!

NOW IS THE TIME FOR YOUR TURN

DECISIVE ACTION YIELDS POWERFUL RESULTS
______________________________________________________________

Remove nothankyou56@mrearl.com
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 dependent 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 non-verifiable.
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.

Remove nothankyou56@mrearl.com



From list@netscape.com  Mon Sep 25 16:22: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 SMTP id QAA12792
	for ; Mon, 25 Sep 2000 16:22: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 e8PKDcM02950;
	Mon, 25 Sep 2000 13:13:39 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8PJwto02527;
	Mon, 25 Sep 2000 12:58:55 -0700 (PDT)
Resent-Date: Mon, 25 Sep 2000 12:58:55 -0700 (PDT)
Date: Mon, 25 Sep 2000 12:58:44 -0700 (PDT)
Message-Id: <200009251958.e8PJwXH20930@ywing.netscape.com>
From: sunsetbeach@myhomenet.net
To: Everyone@netscape.com
Subject:  Totally Automated Money machine For you!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"-Ss90.A.Nn.-56z5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hello, This may be the most COMMON SENSE email you've ever read because 
I'm going show you EXACTLY how I got SICK AND TIRED of all the 
stupid chain letters, MLM's and mathematically impossible matrix deals, 
and started making all the money I needed, right from my home computer. 
I'm going show you EXACTLY how I get money deposited RIGHT to MY bank 
account (no company to hold my money while they "work things out"), 
and EXACTLY what I do every single day. This is for normal, 
hardworking people who want to make a steady, substantial and growing 
income from their computers, and to start making money today. 
You DON'T need a website. 
You DON'T need to "recruit" anyone. 
You DON'T need to talk to anyone. And... 
you DON'T even need to pay 
until YOU see that it works for YOU! 
I'm not kidding when I tell you that you can have a perfectly legal 
and legitimate home based business that starts earning you money RIGHT AWAY, 
and that provides a STEADY and GROWING income - as much as you want to make! 
I'm gonna give you the tools to make this an automated thing, so you can 
be earning money whether you're at your computer or not! Believe me, when 
I tell you that this very simple system took me from worrying about bills to 
having fun shopping in less than a week! 
Are YOU sick of it all yet? 
Do YOU need a QUICK income? 
Do YOU want control of your OWN money? 
Simply send me an email to: aim_high200@mail.com and type the word " Q1 " in the 
subject matter and I will send you back the very simple and 
straightforward explanation of how YOU can do what I've done. 
Then you can decide if it's something you can do. 




From list@netscape.com  Mon Sep 25 17:20: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 SMTP id RAA14558
	for ; Mon, 25 Sep 2000 17:20: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 e8PL8TC21340;
	Mon, 25 Sep 2000 14:08:29 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8PLJEg10643;
	Mon, 25 Sep 2000 14:19:15 -0700 (PDT)
Resent-Date: Mon, 25 Sep 2000 14:19:15 -0700 (PDT)
Message-ID: <39CFC123.BBF75AE6@novell.com>
Date: Mon, 25 Sep 2000 15:18:27 -0600
From: Steven Sonntag 
Organization: Novell, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rob Weltman 
CC: Steven Merrill , ietf-ldapext@netscape.com,
        aclark@novell.com, Miodrag Kekic 
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"WxRsw.A.-lC.RF8z5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit



Rob Weltman wrote:

>
> >   3) setOption operates only on the LDAPSearchConstraints object
> >      that is associated with an LDAPConnection object.  Yet
> >      there may also be an LDAPConstraints object associated
> >      with the LDAPConnection object.  It may or may not be
> >      the same as the LDAPSearchConstraints object.  Should
> >      there be a setOption kind of method that operates on
> >      the LDAPConstraints object associated with a connection?
>
>   LDAPSearchConstraints extends LDAPConstraints. There is only one
> such object per connection, and it is an LDAPSearchConstraints. If
> there was an LDAPConstraints object as well, there would be ambiguity
> as to which object controlled operations other than search.   Also,
> see 4 below (which renders this issue mute)

The thing that is confusing to me is that in the LDAPConnection object
there are the following methods:

getConstraints()
getSearchConstraints()
setConstraints()
setSearchConstraints()

Since, as you say, there is only one object per connection, there is
still confusion.  If the
application calls the setConstraints() method with an LDAPConstraints
object, then
there are no search constraints at all, since the added functionality of
the LDAPSearchConstraints
specialization is not present.  Having the four methods make it seem
like there are two separate objects,
or at least that is the way I read it.  Maybe all that is needed is the
set|getConstraints which takes
an LDAPSearchConstraints object and eliminate the other two methods.

-Steve



From list@netscape.com  Mon Sep 25 18:10: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 SMTP id SAA15840
	for ; Mon, 25 Sep 2000 18:10: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 e8PM1oM25940;
	Mon, 25 Sep 2000 15:01:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8PM8IM04447;
	Mon, 25 Sep 2000 15:08:18 -0700 (PDT)
Resent-Date: Mon, 25 Sep 2000 15:08:18 -0700 (PDT)
Message-ID: <39CFCC98.FE7D6282@novell.com>
Date: Mon, 25 Sep 2000 16:07:20 -0600
From: Steven Sonntag 
Organization: Novell, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rob Weltman 
CC: Steven Merrill , ietf-ldapext@netscape.com,
        aclark@novell.com, Miodrag Kekic 
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"D4b1mC.A.MFB.Qz8z5"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit




> 8.
> >  It seems that the LDAPRebind interface would be easier to implement if
> >  additional data were provided in the new LDAPConnection object.  Such as:
> >
> >  1. A reference to the LDAPSocketFactory class from the original LDAPConnection
> >      object.  This allows it to connect in the same way as the original connection.
> >  2. An LDAPConstraints object containing a reference to the LDAPRebind object
> >      from the original LDAPConnection object.  The LDAPBind.bind() method may
> >      want to get authentication information using and LDAPRebindAuth object, and
> >      this gives it a way to do that.
> >  3. The protocol version used in the connect/bind of the original object.  This allows
> >      The LDAPBind.bind function to bind with same protocol version used in the
> >      original connection.
> >  4. The mechanism used when binding.  This could be the mechanism used on the
> >      bind in the original LDAPConnection object, or perhaps LDAPRebindAuth could
> >      be modified to provide the triplet - UserDN, Password, and Mechanism for the
> >      specified host.
> >
> >  IMO the above changes would give the application, using explicit bind, greater flexibility
> >  when dealing with referrals / continuation references during automatic referral
> >  following:
> >
>
>   It's questionable that this is necessary. Can't you do all that with LDAPBind (rather than LDAPRebind)?
>
>   If it really is required (which duplicates what you can do with LDAPBind), how about the following instead (let the implementation pull whatever it needs from the original connection, as LDAPBind does)?
>
> LDAPConnection bind(String ldapurl, LDAPConnection origConn);

Sorry, I was saying Rebind, but meaning LDAPBind.  Your solution is a
good one and resolves my concerns.
Does there need to be a way to get protocol version from the
LDAPConnection for the use of LDAPBind?

-Steve



From list@netscape.com  Tue Sep 26 00:13: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 SMTP id AAA23006
	for ; Tue, 26 Sep 2000 00:13: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 e8Q42aM18267;
	Mon, 25 Sep 2000 21:02:36 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8Q495w17619;
	Mon, 25 Sep 2000 21:09:05 -0700 (PDT)
Resent-Date: Mon, 25 Sep 2000 21:09:05 -0700 (PDT)
Message-ID: <39D021C5.2D3B69C1@worldspot.com>
Date: Mon, 25 Sep 2000 21:10:46 -0700
From: Rob Weltman 
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,sv,ja
MIME-Version: 1.0
To: Steven Sonntag 
CC: Rob Weltman , Steven Merrill ,
        ietf-ldapext@netscape.com, aclark@novell.com,
        Miodrag Kekic 
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFC123.BBF75AE6@novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"wTHNyB.A.BTE.gFC05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Steven Sonntag wrote:
> 
> Rob Weltman wrote:
> 
> >
> > >   3) setOption operates only on the LDAPSearchConstraints object
> > >      that is associated with an LDAPConnection object.  Yet
> > >      there may also be an LDAPConstraints object associated
> > >      with the LDAPConnection object.  It may or may not be
> > >      the same as the LDAPSearchConstraints object.  Should
> > >      there be a setOption kind of method that operates on
> > >      the LDAPConstraints object associated with a connection?
> >
> >   LDAPSearchConstraints extends LDAPConstraints. There is only one
> > such object per connection, and it is an LDAPSearchConstraints. If
> > there was an LDAPConstraints object as well, there would be ambiguity
> > as to which object controlled operations other than search.   Also,
> > see 4 below (which renders this issue mute)
> 
> The thing that is confusing to me is that in the LDAPConnection object
> there are the following methods:
> 
> getConstraints()
> getSearchConstraints()
> setConstraints()
> setSearchConstraints()
> 
> Since, as you say, there is only one object per connection, there is
> still confusion.  If the
> application calls the setConstraints() method with an LDAPConstraints
> object, then
> there are no search constraints at all, since the added functionality of
> the LDAPSearchConstraints
> specialization is not present.  Having the four methods make it seem
> like there are two separate objects,
> or at least that is the way I read it.  Maybe all that is needed is the
> set|getConstraints which takes
> an LDAPSearchConstraints object and eliminate the other two methods.
> 
> -Steve

  In our implementation, setConstraints() just sets the properties of LDAPConstraints, leaving the search-specific properties untouched. setSearchConstraints() replaces all properties. I haven't heard any reports of confusion from the field.

Rob



From list@netscape.com  Tue Sep 26 00: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 SMTP id AAA23021
	for ; Tue, 26 Sep 2000 00:16:43 -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 e8Q48oM19137;
	Mon, 25 Sep 2000 21:08:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8Q4FJI19663;
	Mon, 25 Sep 2000 21:15:19 -0700 (PDT)
Resent-Date: Mon, 25 Sep 2000 21:15:19 -0700 (PDT)
Message-ID: <39D023AE.6D038D1D@worldspot.com>
Date: Mon, 25 Sep 2000 21:18:54 -0700
From: Rob Weltman 
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en-US,sv,ja
MIME-Version: 1.0
To: Steven Sonntag 
CC: Steven Merrill , ietf-ldapext@netscape.com,
        aclark@novell.com, Miodrag Kekic 
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"VAhGVC.A.9yE.WLC05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Steven Sonntag wrote:
> 
> > 8.
> > >  It seems that the LDAPRebind interface would be easier to implement if
> > >  additional data were provided in the new LDAPConnection object.  Such as:
> > >
> > >  1. A reference to the LDAPSocketFactory class from the original LDAPConnection
> > >      object.  This allows it to connect in the same way as the original connection.
> > >  2. An LDAPConstraints object containing a reference to the LDAPRebind object
> > >      from the original LDAPConnection object.  The LDAPBind.bind() method may
> > >      want to get authentication information using and LDAPRebindAuth object, and
> > >      this gives it a way to do that.
> > >  3. The protocol version used in the connect/bind of the original object.  This allows
> > >      The LDAPBind.bind function to bind with same protocol version used in the
> > >      original connection.
> > >  4. The mechanism used when binding.  This could be the mechanism used on the
> > >      bind in the original LDAPConnection object, or perhaps LDAPRebindAuth could
> > >      be modified to provide the triplet - UserDN, Password, and Mechanism for the
> > >      specified host.
> > >
> > >  IMO the above changes would give the application, using explicit bind, greater flexibility
> > >  when dealing with referrals / continuation references during automatic referral
> > >  following:
> > >
> >
> >   It's questionable that this is necessary. Can't you do all that with LDAPBind (rather than LDAPRebind)?
> >
> >   If it really is required (which duplicates what you can do with LDAPBind), how about the following instead (let the implementation pull whatever it needs from the original connection, as LDAPBind does)?
> >
> > LDAPConnection bind(String ldapurl, LDAPConnection origConn);
> 
> Sorry, I was saying Rebind, but meaning LDAPBind.  Your solution is a
> good one and resolves my concerns.
> Does there need to be a way to get protocol version from the
> LDAPConnection for the use of LDAPBind?
> 
> -Steve

  In our implementation, you can get the bind protocol version with
       LDAPConnection.getOption( LDAPv2.PROTOCOL_VERSION)

  If we eliminate get/setOption, I guess we'll need to move that property to LDAPConstraints.

Rob



From list@netscape.com  Tue Sep 26 20:44: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 SMTP id UAA18417
	for ; Tue, 26 Sep 2000 20:44: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 e8R0VjC02681;
	Tue, 26 Sep 2000 17:31:45 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8R0gWU12968;
	Tue, 26 Sep 2000 17:42:32 -0700 (PDT)
Resent-Date: Tue, 26 Sep 2000 17:42:32 -0700 (PDT)
Message-Id: <200009270042.e8R0g7H15457@ywing.netscape.com>
From: 
Subject: 50K e-mails + FREE EMS
Date: Tue, 26 Sep 2000 16:00:47
Resent-Message-ID: <"j7dZxB.A.xJD.2JU05"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
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.virtue.nu/meg925

 10,000 opportunity seekers e-mails for only $15
**New List 9-25-00**
 25,000 opportunity seekers e-mails for only $25
 50,000 opportunity seekers e-mails for only $35
100,000 opportunity seekers e-mails for only $50
200,000 opportunity seekers e-mails for only $75

- Promotions!

**FREE with EVERY order, demo of ListMan e-mail manager software 
to manage your e-mails list and Credit Helper E-book with Links 
to Guaranteed Visa's and MC's!

**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, 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  Wed Sep 27 01:33:31 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 SMTP id BAA26598
	for ; Wed, 27 Sep 2000 01:33: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 e8R5PYM26903;
	Tue, 26 Sep 2000 22:25:34 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8R5W4c24821;
	Tue, 26 Sep 2000 22:32:04 -0700 (PDT)
Resent-Date: Tue, 26 Sep 2000 22:32:04 -0700 (PDT)
Message-Id: <200009270532.e8R5W0H09735@ywing.netscape.com>
From: "Peter Johnson" 
To: 
Subject: Immediate Downline - 1000 Members Per Month - It's FREE!!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 27 Sep 2000 07:30:29
Resent-Message-ID: <"0y9xfD.A.jDG.TZY05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

CHECK IT OUT! IT'S FREE! 
1000 MEMBERS A MONTH!! 
Get yourself an IMMEDIATE DOWNLINE ! 
ALL new members that come into the club 
COMPANY WIDE will go under YOU. 
A true VERTICAL downline. 
YOU can easily get 1000 members 
or MORE under YOU in a month! 
How would you like a GUARANTEED 
minimum commission every month? 
JOIN FREE!!!!!!! JOIN FREE!!!!!!! 
Join our FREE postlaunch program- 
You'll be then forwarded on to our 
main website where you can watch 
your downline grow right before your eyes ! 
Get started today and watch what happens ! 
http://www.angelfire.com/ab4/cuervo1
----------------------------------------------------------------------------------
You are receiving this message because my records indicate you are open to receiving 
information on how to make money on the internet. If you 
would like to be removed from future mailings please reply with "remove" in the subject line. 
Thanks and many prosperous blessings to you!
----------------------------------------------------------------------------------









From list@netscape.com  Wed Sep 27 04:14:31 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 SMTP id EAA06513
	for ; Wed, 27 Sep 2000 04:14: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 e8R86bM10085;
	Wed, 27 Sep 2000 01:06:37 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8R8D8Y28963;
	Wed, 27 Sep 2000 01:13:08 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 01:13:08 -0700 (PDT)
Date: Wed, 27 Sep 2000 16:11:56 +0800
From: hewent@kornet.net
Message-Id: <200009270811.QAA11922@ns1.cc163.net.>
Reply-To: hewent@kornet.net
To: hewent@kornet.net
Subject: Exploit your computer!
Resent-Message-ID: <"pnj3vD.A.PEH.Twa05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Dear Computer Owner,

We are a national ecommerce marketing company conducting
a survey for an International enterprise. They are currently in 
need of individuals to train who own a computer and wish to
work either part or full time online from home.

Based on key demographics, you have been selected to
receive this notification to be part of this International
e-survey. Our two step process will enable you to determine
if this opportunity is right for you. Your training begins
by simply taking the e-survey and deciding to continue. Once
you make the decision to start you will be taught how to...

   * Own & Operate your own business from home
      via the Internet
   * Plug into the fastest growing industry in the world
   * Market just under 200 top quality products
   * Receive an unlimited source of consumers/customers
   * Repeat this same system with others
   * Samples of our products
   * Product training video
   * Business Plan video

Your training will also incorporate how to process orders for
these high quality products in a way that is very unique to 
this industry. All this and much much more will be available 
to you so you can start making money right away.

Please note that you will need to truly work a minimum of
5 to 10 hours per week in order to get paid.

If you wish to participate in our e-survey then phone us at
877-385-5031** and tell us...
     * Your name
     * Phone number
     * Email Address
     * Best time to call
     * State
     * Country
and then say the following: " I OPT-IN TO SURVEY ". 

We will then contact you with additional information 
regarding this unique opportunity.

If you act now and you are one of the first 1000
respondents to our survey you will receive a two page web
site FREE! These pages are valued at $19.95 per month
and will be made available for your use the very first day.
So Act NOW!

In closing, if this is not something you are interested in
pursuing but believe someone you care about might be then
please forward this email to them.

** If you are outside of the United States and can't reach our
    877 number then join one of the free Internet phone services
    like dialpad.com to make the call.

Thank you for your attention!
________________________________________________
THIS IS A ONE TIME MAILING SO YOU DO NOT NEED TO
CONTACT THE PHONE NUMBER STATED ABOVE TO BE
REMOVED FROM OUR MAILING LIST.




From list@netscape.com  Wed Sep 27 05:21: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 SMTP id FAA06845
	for ; Wed, 27 Sep 2000 05:21: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 e8R99aC18171;
	Wed, 27 Sep 2000 02:09:36 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8R9KOo13588;
	Wed, 27 Sep 2000 02:20:24 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 02:20:24 -0700 (PDT)
Reply-To: getfreetvb10@indiatimes.com
From: nopaycablea10@indiatimes.com
Subject: Get a FREE $1000 Satellite T.V. System
Message-Id: 
To: getfreetva@yahoo.com
Date: Wed, 27 Sep 2000 05:21:58 -0500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
Resent-Message-ID: <"NifNnD.A.3TD.Xvb05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

FREE SATELLITE T.V. SYSTEM

For a limited time we'll give you this top of the line Digital
Satellite System for FREE! We'll even include Free installation
and 3 FREE months of all the Movie Channels!

Enjoy over 500 Channels of Quality Digital Television on your
FREE Satellite TV System.  Why pay over $900 retail for these
items, when we're giving you this satellite package for free.


Call 888-514-6881 to be Guaranteed Your FREE Satellite Today


This is the New Dishplayer 500.  This Innovative 18" Satellite
has a digital 12 hour recording system so you can throw away
that old VCR. It also has WEB T.V., interactive T.V and a
gameing system.  PLUS on screen graphics, stereo receiver
and infrared remote.

All you have to do is call us to arrange delivery.

For less than the monthly cost of cable tv, Satellite television
offers over 500 channels of all digital video and cd audio sound,
while not missing out on local channels.  


Call 888-514-6881 to Begin Surfing through 500 Channels Today!




To be removed send email to gsnapple@yahoo.com



From list@netscape.com  Wed Sep 27 07:43: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 SMTP id HAA09057
	for ; Wed, 27 Sep 2000 07:43: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 e8RBZ7M25832;
	Wed, 27 Sep 2000 04:35:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8RBfcY14258;
	Wed, 27 Sep 2000 04:41:38 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 04:41:38 -0700 (PDT)
Date: Wed, 27 Sep 2000 20:41:24 +0900 (KST)
From: mike144@asean-mail.com
Message-Id: <200009271141.UAA03471@puyo.puyo.chungnam.kr>
To: 
Subject: ADV: Search Engine Registration
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Resent-Message-ID: <"ZHJ3NC.A.geD.xzd05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


Removal instructions below

I saw your listing on the internet.

I work for a company that specializes
in getting clients web sites listed
as close to the top of the major 
search engines as possible.

Our fee is only $29.95 per month to
submit your site at least twice a
month to over 350 search engines 
and directories.

To get started and put your web site
in the fast lane, call our toll free
number below.


Mike Bender
888-532-8842

To be removed call: 888-800-6339 X1377





From list@netscape.com  Wed Sep 27 10:50: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 SMTP id KAA13222
	for ; Wed, 27 Sep 2000 10:50: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 e8REcEC13114;
	Wed, 27 Sep 2000 07:38:15 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8REn4M05934;
	Wed, 27 Sep 2000 07:49:04 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 07:49:04 -0700 (PDT)
Date: Wed, 27 Sep 2000 07:48:57 -0700 (PDT)
Message-Id: <200009271448.e8REmvI26488@xwing.netscape.com>
From: sunny_side22@mail.com
To: @netscape.com
Subject:  EVERYONE GET'S PAID!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"a81Hn.A.acB.fjg05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hello, how would you like to turn $10 into $40,000 in less than 180 days. Here's an 
investment with a safety catch!
EVERYONE Gets Paid ! Our unique work from home system is one of the most
successful, easily operated Internet Programs with a Safety Catch?
You Can't Lose! An Accountability List ensures everyone wins, Huge
Returns. FREE DETAILS , send to: fail_safe1@angelfire.com Subject="phase.1"
=============================================================







From list@netscape.com  Wed Sep 27 16:00: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 SMTP id QAA21591
	for ; Wed, 27 Sep 2000 16:00: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 e8RJmEC06568;
	Wed, 27 Sep 2000 12:48:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8RJx3s18405;
	Wed, 27 Sep 2000 12:59:03 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 12:59:03 -0700 (PDT)
Message-ID: <39D25161.651E106@novell.com>
Date: Wed, 27 Sep 2000 13:58:25 -0600
From: Steven Sonntag 
Organization: Novell, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rob Weltman , smerrill@novell.com,
        ietf-ldapext@netscape.com
CC: aclark@novell.com, moidrag@netscape.com
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFC123.BBF75AE6@novell.com> <39D021C5.2D3B69C1@worldspot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"648kND.A.qeE.EGl05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit



Rob Weltman wrote:

> Steven Sonntag wrote:
> >
> > Rob Weltman wrote:
> >
> > >
> > > >   3) setOption operates only on the LDAPSearchConstraints object
> > > >      that is associated with an LDAPConnection object.  Yet
> > > >      there may also be an LDAPConstraints object associated
> > > >      with the LDAPConnection object.  It may or may not be
> > > >      the same as the LDAPSearchConstraints object.  Should
> > > >      there be a setOption kind of method that operates on
> > > >      the LDAPConstraints object associated with a connection?
> > >
> > >   LDAPSearchConstraints extends LDAPConstraints. There is only one
> > > such object per connection, and it is an LDAPSearchConstraints. If
> > > there was an LDAPConstraints object as well, there would be ambiguity
> > > as to which object controlled operations other than search.   Also,
> > > see 4 below (which renders this issue mute)
> >
> > The thing that is confusing to me is that in the LDAPConnection object
> > there are the following methods:
> >
> > getConstraints()
> > getSearchConstraints()
> > setConstraints()
> > setSearchConstraints()
> >
> > Since, as you say, there is only one object per connection, there is
> > still confusion.  If the
> > application calls the setConstraints() method with an LDAPConstraints
> > object, then
> > there are no search constraints at all, since the added functionality of
> > the LDAPSearchConstraints
> > specialization is not present.  Having the four methods make it seem
> > like there are two separate objects,
> > or at least that is the way I read it.  Maybe all that is needed is the
> > set|getConstraints which takes
> > an LDAPSearchConstraints object and eliminate the other two methods.
> >
> > -Steve
>
>   In our implementation, setConstraints() just sets the properties of LDAPConstraints, leaving the search-specific properties untouched. setSearchConstraints() replaces all properties. I haven't heard any reports of confusion from the field.
>
> Rob

Just to clarify if I understand it correctly

I am/was confused because I was seeing in my minds eye setConstraints implemented
as storing the object somewhere internal to the class, and the same for setSearchConstraints.

You must be seeing an implementation where a single LDAPSearchConstraints objecct
exists internally, and the search constraints fields are copied on setConstraints() to the
internal object, and the search constraints fields are copied on setSearchConstraints().

However getConstraints and getSearchConstraints return a reference to the single internal object.

--
------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software




From list@netscape.com  Wed Sep 27 16:05: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 SMTP id QAA21700
	for ; Wed, 27 Sep 2000 16:05: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 e8RJqwC07766;
	Wed, 27 Sep 2000 12:52:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8RK3l221909;
	Wed, 27 Sep 2000 13:03:47 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 13:03:47 -0700 (PDT)
Message-ID: <39D25275.DD9616DD@novell.com>
Date: Wed, 27 Sep 2000 14:03:01 -0600
From: Steven Sonntag 
Organization: Novell, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rob Weltman , ietf-ldapext@netscape.com,
        aclark@novell.com, miodrag@netscape.com, smerrill@novell.com
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"IQRbyD.A.DWF.hKl05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Rob,

Here are my responses to all of the issues except two.  Those I will
address in a separate e-mail.
In the responses below, I have elimated the text except the number and
first sentence of the topic for most
of my "OK" responses.  Those where I had more than an OK comment, are
quoted more fully.

Thanks for your time.

-Steve

Rob Weltman wrote:

>   I've collected all the issues raised (hope I didn't miss any) and
> responded in short to each one. Many thanks to Miodrag for helping me
> evaluate the issues. And to Steve and Steven for raising them :-)
>
> Rob
>
>
> 1.
> > Section 4.39.13 LDAPV2.setOption ...

OK

>
> >   2) STRING_FORMAT is set only by the setOption method. ...

OK

>
> >   3) setOption operates only on the LDAPSearchConstraints object ...

See separate e-mail

>
> >   4) All functionality of SetOption can be performed by code ...

OK

>
> 2.
> > If references to LDAPv2 are not removed from the draft, ...

OK

> 3.
> >
> >  In the java-api-11 I-D, an application doing asynchronous search
> >  operations is confronted with two different data formats when
> handling
> >  referrals and search continuation references.
> >
> >  When the application gets a referral status on a search operation,
> >  referral URL information is retrieved by
> LDAPResponse.getReferrals()
> >  as an array of String objects.
> >
> >  When the application gets search continuation references as part of
>
> >  the search data, the continuation references are retrieved by
> >  LDAPSearchResultReference.getURLs() as an array of LDAPUrl objects.
>
> >
> >  To be consistent, shouldn't both return an array of LDAPUrl
> objects?
>
> Returning String[] seems more flexible. Steve has recognized that in
> one of his comments following this one. "...This is because the only
> way to get the list is via the getURLs() method of the
> LDAPSearchResultReference.Perhaps it should return the  URLs as a
> string array, and let the applicationturn them into LDAPUrl objects if
> desired.  This is backwards to what I said in an earlier e-mail,
> butnow I see the need for Strings instead of LDAPUrls".
>
> So let's return String[] in both cases.

Should the method names be unified, i.e. use getReferrals() instead of
getUrls() ??

> 4.
> > An application doing its own referral handling may need to make
> >  decisions based on the scheme of URLs returned from search
> >  continuation references or referrals.
> >
> >  Shouldn't the LDAPUrl object provide a method to retrieve
> >  the URL scheme, viz. ldap, http, & etc.
>
> This is an LDAP only URL and not a generic URL, so there is no reason
> to report a URL scheme. However, there is a need to support ldaps with
> some LDAP servers. To accomodate them, we propose a boolean method
> isSecure().

OK - Don't forget toadd this field to the constructors.

> 5.
> > I am puzzled why the draft specifies that automatic referral ...

OK

> 6.
> > Re: referrals as defined in draft-ietf-ldapext-ldap-java-api-11.txt
> >
> >  The I-D seems silent on what happens if an application has
> automatic
> >  referral handling enabled, and for some reason one or more of the
> >  referrals or search continuation references cannot be followed.

OK

> 7.
> >
> >  I would like clarification on how LDAPBind vs LDAPRebind objects
> >  are used in the Java API.
> >
> >  The I-D implies, but never quite says that the two objects don't
> >  normally exist in the LDAPConstraints object at the same time.
> >  (Implied by Appendix G - LDAPConstraints - they should
> >  not be specified on the same constructor)
> >
> >  They certainly can both be set by using the set methods, but
> >  are probably not both used at the same time.
> >
> >  I surmise from the draft that these objects are used as follows:
> >
> >  1. Neither object is used unless Referrals are enabled in the
> >      LDAPConstraint object (automatic referral following enabled).
> >
> >  2. An LDAPRebind object is used only if present and if an LDAPBind
> >      object is not present in the LDAPConstraint object.
> >
> >  3. An LDAPBind object is used if present.  If present, the
> LDAPRebind
> >      object is not needed by LDAPConnection as no implicit binding
> is done.
> >      Explicit binding is the responsibility of the LDAPBind object.
> Therefore
> >      the LDAPRebind object is not used in this case.
> >
> >  If my guesses are correct, maybe the draft should be clarified as
> to the
> >  usage of these objects.
>
> This is a correct interpretation. An improvement to the I-D would be
> be to specify a single field in LDAPConstraints - rebindHandler -
> which would accept either LDAPBind or LDAPRebind. An additional tag
> interface would need to be declared, somthing like this:
>
> public interface LDAPReferralHandler {  // the tag interface
> }
>
> public class LDAPConstraints {
>      private LDAPReferralHandler rebindProc;
>      ...
> }
>
> public interface LDAPBind extends LDAPReferralHandler {
> ...
> }
>
> public interface LDAPRebind extends LDAPReferralHandler {
> ...
> }

My only objection to this is that I had it in mind that the application
may want to use
the LDAPRebindProc to provide credentials for the LDAPBind.bind()
method.
It is reasonable to think an application might do this??  Having one
object certainly
makes it simpler for the application writer to understand the behavior.

So, OK, I agree.

> 8.
> > Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt

OK

> >  It seems that the LDAPRebind interface would be easier to implement
> if
> >  additional data were provided in the new LDAPConnection object.
> Such as:

( ... )

>   If it really is required (which duplicates what you can do with
> LDAPBind), how about the following instead (let the implementation
> pull whatever it needs from the original connection, as LDAPBind
> does)?
>
> LDAPConnection bind(String ldapurl, LDAPConnection origConn);

But LDAPBind doesn't - it returns a void.  If you change it to the
above,
i.e. returns LDAPConnection (the new connection) then - OK.

>
> 9.  (from Kurt)
> > You might consider renaming getSubTypes to getOptions as
> > not all options (e.g. ;binary) are subtypes.
>
>   Not worth changing, I don't think.

OK

> 10.
> > The I-D interchanges referrals and search continuation references.

OK

> 11.
> > Resend - properly indicating where comments are

OK

> 12.
> > Re: Referrals on operations as defined
> >        in draft-ietf-ldapext-ldap-java-api-11.txt

OK

> 13.

OK

> Let's remove the method from the I-D. It's just a convenience.

OK

> 14.
> >
> >  I think the draft should describe more fully the
> >  semantics of the implicit bind w/r automatic referral following:
> >
> >  I will describe what the I-D describes and where
> >  I have questions:
> >
> >  1. Authentication - uses anonomyous credentials unless
> >     LDAPRebind specified in LDAPConstraints.

OK

>
> >  2. Protocol Version ?? - Does it use the same protocol

As long as it is added to the constraints so it can be retrieved.


> >  3. AuthenticationMethod: Is it the same as the originating
> connection,
> >      or is it "simple" - I assume simple is used.

OK

> >  4. Does it use the LDAPSocketFactory if specified on the
> >      originating connection.  I am not sure what to do here.
> >      It seems better to use it if available, then an encrypted
> >      connection can be established and thus prevent
> >      clear text password transmittion on the wire.  I just
> >      talked myself into it - it should be used.
>
> If the referral ldap url specifies ldaps, the referral connection
> should use ldaps (regardless of the original connection). At least in
> our implementation :-) - since ldaps is being deprecated in favor of
> startTLS, we may not want to mention it in this I-D (I just remembered
> that I owe LDAPEXT an informational RFC draft on ldaps). For startTLS,
> I guess the referral connection should attempt to use startTLS if the
> original connection was in startTLS mode. Is there any other way to
> determine whether or not to use startTLS?

IMO the application if the connection is in startTLS mode, the new
connections should also be startTLS.  Likewise,
LDAPBind.bind() needs to be able to determine if the connection is in
startTLS mode so it can also do startTLS, thus
the app needs to be able to query if the connection is in startTLS mode.

> 15.
> >  When performing a search it is possible for the server ...

OK - Just fix the wording a little to reflect this.  4.35.4
. the last time it is called ..
seems pretty final, when it really means all referral
exceptions are the last elements of the enumeration.

> 16.
> >
> >  Since LDAPResponseListener and LDAPSearchListener
> >  objects implement exactly the same set of methods,
> >  does it seem reasonable that an interface be created
> >  named something like LDAPListener that specifies
> >  those four methods, and that LDAPSearchListener
> >  and LDAPResponseListener implement this interface.
> >  This forces those methods to stay the same in both classes.
> >
>
> > If an LDAPListener interface were created, then
> > the two methods in LDAPv2.abandon
> >
> >    public void abandon(LDAPSearchListener listener)
> >    public void abandon(LDAPResponseListener listener)
> >
> > Could be combined into one
> >
> >    public void abandon(LDAPListener listener)
>
> We have responded to this earlier, but here is a brief recap. In the
> very first asynch draft, LDAPSearchListener extended
> LDAPResponseListener. Later when we adding abandon(int) method, we
> investigated removing LDAPSearchListener and leaving only
> LDAPResponseListener because there were implementation issues
> (multiplexing, and raising exceptions as a result of a lost
> connection). Then, in order not to change the draft considerably, we
> decided to make only minor changes and just resolve the implementation
> problems. We kept LDAPSearchListener, but it does not extend
> LDAPResponseListener any more.

I get the feeling we are talking about different things.
I wasn't describing LDAPSearchListener extending LDAPResponseListener,
but both
implementing a common interface, viz. LDAPListener, with methods
getMessageIDs(), getResponse(), isResponseReceived(),
and merge().  All four of  the methods of each class have identical
signatures.  Doing this reduces abandon to one call, which
can easily do exactly what it is doing now by using the instanceof
operator.

> 17.
> >
> >  4.6.19 setConstraints

See separate e-mail, same as 1.3

> 18.
> >
> >  4.39.1 LDAPv2.abandon
> >
> >  The RFC 2251 and the C api draft allow controls to be specified
> >  on an abandon operation.  In java it is allowed only using the
> default
> >  constraints object or search constraints object.  Should methods
> >  be defined that allow constraints to be specified on abandon?
>
> Strictly speaking this is true, but if we look at the properties in
> LDAPConstraints, none of them are applicable to abandon(). This change
> is not required.

Suppose an application needed to put a control on an abandon operation.
What then?

> 19.
>
>> The JAVA LDAP API (draft-ietf-ldapext-ldap-java-api-11.txt) defines
>> the following method for
>> extended operations:
>
OK

> 20.
>
>>  Section 4.7.11 LDAPConstraints.setTimeLimit
>
OK

> 21
> LDAPSortKey.

OK

> 22.
>
>> Re: LDAP_PARTIAL_RESULTS Result Code defined in
>
OK

>> 23.
>
>> In the Bibliography, [3] refers to RFC 1960.
>
OK

> 24.
>
>
>>  4.40.1
>
OK

>>  What does it mean -
>>
>>     if the first version of the method (i.e. the one that specifies no mechanism)
>>     is called, the LDAP server will be interrogated for its
>>     supportedSaslMechanisms attribute of its root DSE.
>>
>>  What does it do after the LDAP server is interrogated?  Does it use one
>>  of them, and if so how does the application know which one is used
>>  and how does it know what kind of credentials to supply?
>>
>
> Yes, if no mechanisms are specified, the mechanisms supported by the
> server are processed until one is mutually agreed on. The callback
> handler is called to obtain credentials. Are you thinking that the
> credentials to be returned depend on the mechanism being negotiated?
> Let me think about that a little...

That is what I am thinking.  Is perhaps the ChoiceCallback used in some
way to communicate the negogiated choice, or to
influence the negotiation possibilities the app will accept?  This area
is pretty new to me.

> 25.
>
>>  4.40.1 bind specifying a mechanism
>>
>>  It would seem that if the mechanism is "simple"
>>  that the API should specify how the password
>>  is to be specified in the Hashtable object props
>>  so that it is consistent across implementations.
>>  Other mechanisms and associated Hashtable
>>  values are the subject of other I-Ds.
>>
>>
>>  My suggestions:
>>
>>        props.put("password", new String("user-password-value");)
>>
>
>   Credentials are obtained from the callback handler.

I was thinking of the same semantics as getPasswd() where the original
credentials were
contained in the HashTable.  But as you say, the credentials should be
obtained
from the callbackHandler. If the application is handling multiple
connections each with different characteristics and possibly different
users, it would need
a different callback handler for each connection.  The callback handler
needs to be
available for implicit bind and explicit bind, and needs to be set in
the new connection by
the explicit bind method.  Do we need a mechanism them to get the
callbackHandler?

What is contained in HashTable if not the credentials??

> 26.
>
>
>> Shouldn't the SASL bind mechanisms also support the ability
>> for the application to specify an LDAPConstraints
>> object so that call specific controls can be specified?
>>

OK

> 27.
>
>> When using an explicit bind for referrals where sasl mechanisms
>> were used on the original LDAPConnection, the LDAPBind.bind()
>> method will need access to the Hashtable parameter passed on the
>> bind to get the credentials used.  A method needs to be
>> supplied in LDAPConnection to get the Hashtable object with
>> semantics similar to what is now used for getAuthenticationPassword()
>>
>
>   Does it need to be a public method? Can't it be a package scope
> (implementation-defined) method?

I was thinking it does need to be a public method as the explicit Bind
method may need access to it.

>
>
> 28.
>
>> I am trying to understand the encode/decode functions
>>  in the LDAPUrl class.
>
OK

> 29.
>
>> 4.16 LDAPException
>>
>>  The LDAPException class has a method getMatchedDN() but has no way to set
>>  the matched DN in the object.  Shouldn't there be a constructor with MatchedDN
>>  as a parameter?
>>
> (...)
>   Is that realistic - that a class in some other package would create
> an exception and put in its own matchedDN?

You are right, I was not thinking straight on this one.

>
>
> 30.
>
>> 4.26 LDAPException
>>
>>  I am trying to understand where the information in the
>>  constructor serverMessage comes from.  I am not
>>  aware of any message that is returned by the server with a
>>  referral result, except for the actual referral URLs.
>>
>>  Do you intend that the class gets primed with the
>>  referral URLs using the serverMessage parameter
>>  and if so how are the referrals delimited - otherwise
>>  can you elaborate on the meaning of this parameter
>>  and explain how the referral URLs are placed into the
>>  class.
>>
>
>   That is correct. The server returns the referral URLs in the message
> field. I don't know if it is necessary to define the representation
> there (it is a contract between the upper layer of an implementation
> and the BER decoding layer - which is not defined in the I-D); clients
> query getURLs() to get the URLs.
>

A ldap_result  is made up of errmsg, referral, result, matched-dn.  Were
you thinking of the error message field for ServerMessage?

>
>
> 31.
>
>> In draft-ietf-ldapext-ldap-c-api-04.txt section 11.6 Searching, it
>> states:
>
OK

>
> 32.
>
>> Also, in the Bibliograpy, [7] should be updated. (To draft-ietf-ldapext-ldap-c-api-04.txt)
>>
>   OK.

OK




From list@netscape.com  Wed Sep 27 16:53:24 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 SMTP id QAA22357
	for ; Wed, 27 Sep 2000 16: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 e8RKeuC15428;
	Wed, 27 Sep 2000 13:40:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8RKpjE14761;
	Wed, 27 Sep 2000 13:51:45 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 13:51:45 -0700 (PDT)
Message-ID: <04ea01c02920$2e3213e0$3029b0cb@x3y0t8>
From: "LIFESTYLE" 
To: 
Subject: INCREDIBLE OPPORTUNITY. DON'T MISS IT!
Date: Thu, 28 Sep 2000 00:01:59 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_04E7_01C028E5.81C27300"
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: <"uhnU8D.A.ylD.e3l05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
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_04E7_01C028E5.81C27300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi,
=20
Please allow me to share to you a program which I believe is one of the =
BIGGEST and the most GENEROUS program in the net today. If you're busy =
now, please don't delete this message. Instead, just save it so you can =
read it back when you have the time.
=20
This is about a "CLUB THAT PAYS".The investment is only $10 but the =
monthly "REWARDS and BENEFITS" are so great. When you join, you will be =
entitled to the following benefits;
=20
FREE Website, FREE online support services, Infinite Residual Income, =
FREE groceries, fuels, unlimited phone and cellphone service, car =
amortization, mortgages, health insurance, computers and CASH rewards. =
Please take note of the term that I used - INFINITE RESIDUAL INCOME". I =
am so proud to emphasize this because we believe this is the first =
opportunity to introduce this type of plan in the market.=20
=20
The plan is an ordinary 3 x 7 matrix but with a very unique features. =
The club will give you a FREE paid re-entry into the matrix. What does =
re-entry mean? Re-entry is a new Business Center given to you by the =
club as a privilege. Meaning, you will have several re-entries with no =
cost to you. The more re-entries you have, the more money you will earn. =
Not only this. Each re-entry is entitled to the same "Benefits and =
Rewards". And you know what? There will be 28 re-entries in one full =
organization.  And each re-entries are entitled to the same number of =
re-entries. This means that as you are entitled for a 28 FREE =
re-entries, each of these re-entry is also entitled for 28 re-entries =
and 28 re-entries again and again and again. Can you imagine the power? =
This is the TRUE INFINITE RESIDUALS. What else can you ask for?=20
=20

SUMMARY:
=20
Your TOTAL REWARDS & BENEFITS with 1 FULL Organization:
    a.. A monthly Residual reward of $4,000.=20
    b.. Up to $55,000. per month in Benefit Residual Income.=20
    c.. Up to $50,000. per year for Automobile purchase.=20
    d.. Up to $100,000. per year for Mortgage reductioin or purchase.=20
    e.. Up to $30,000. monthly for Medical benefits.=20
    f.. Up to $5,000. monthly for Telephone charges.=20
    g.. Up to $5,000. monthly for Cellular charges.=20
    h.. Up to $500. monthly in Grocery rebates.=20
    i.. Up to $500. monthly in Fuel rebates.=20
Again, I just want to emphasize that each re-entry is entitled to all of =
these rewards and benefits. On top of all of these is the Monthly and =
Annual Membership Drive. The club's goal is to give away US$ 6,000,000  =
to be rewarded to deserving members in the monthly and annual awardings. =

=20
Now, get your calculator and do your own math. This is more than a =
Global or a World or a Universal Pool. If you know of something big now, =
I will believe you. But you will agree with me that this is the BIGGEST =
so far in the industry worldwide. And this is now your chance to be a =
part of these fast growing online club. So join now! It cost only $10.
=20
For more details, simply reply to this e-mail with more info as text.
=20

Regards,

BONG  ISON

 =
-------------------------------------------------------------------------=
-----------------------------------------------------
This is just to give you an information about the program that I've been =
doing. It is not my intention to offend you or to cause you any trouble. =
I am just so excited to share this to people because I believe this =
program can enhance people's lives. If you don't want to receive any =
e-mails from me in the future, simply reply to this with "REMOVE" as =
text. If this e-mail has offended you, please accept my apology and you =
will not receive any e-mails from me again.=20
               =20
=20
=20
=20

=20

------=_NextPart_000_04E7_01C028E5.81C27300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










 


Hi,


 


Please allow me to share to =
you a program=20
which I believe is one of the BIGGEST and the most GENEROUS program in =
the net=20
today. If you're busy now, please don't delete this message. Instead, =
just save=20
it so you can read it back when you have the time.


 


This is about a "CLUB =
THAT=20
PAYS".The investment is only $10 but the monthly "REWARDS and=20
BENEFITS" are so great. When=20
you join, you will be entitled to the following =
benefits;


 


FREE Website, FREE online =
support=20
services, Infinite Residual Income, FREE groceries, fuels, unlimited =
phone and=20
cellphone service, car amortization, mortgages, health insurance, =
computers and=20
CASH rewards. Please take note of the term that I used - INFINITE =
RESIDUAL=20
INCOME". I am so proud to emphasize this because we believe this is =
the=20
first opportunity to introduce this type of plan in the=20
market. 


 


The plan is an ordinary 3 =
x 7 matrix but=20
with a very unique features. The club will give you a FREE paid re-entry =
into=20
the matrix. What does re-entry mean? Re-entry is a new Business Center =
given to=20
you by the club as a privilege. Meaning, you will have several =
re-entries with=20
no cost to you. The more re-entries you have, the more money you will =
earn. Not=20
only this. Each re-entry is entitled to the same "Benefits and=20
Rewards". And you know what? There will be 28 re-entries in one =
full=20
organization.  And each re-entries are entitled to the same number =
of=20
re-entries. This means that as you are entitled for a 28 FREE =
re-entries, each=20
of these re-entry is also entitled for 28 re-entries and 28 re-entries =
again and=20
again and again. Can you imagine the power? This is the TRUE INFINITE =
RESIDUALS.=20
What else can you ask for? 


 




 


SUMMARY:


 


Your TOTAL REWARDS & =
BENEFITS with 1=20
FULL Organization:


    
    
  • A monthly Residual reward =
of=20
    $4,000.=20
    
  • Up to=20
    $55,000. per month in Benefit Residual Income.=20
    
  • Up to $50,000. per year for Automobile =
purchase.=20
    
  • Up to $100,000. per year for Mortgage reductioin =
or=20
    purchase.=20
    
  • Up to $30,000. monthly for Medical =
benefits.=20
    
  • Up to $5,000. monthly for Telephone =
charges.=20
    
  • Up to $5,000. monthly for Cellular =
charges.=20
    
  • Up to $500. monthly in Grocery rebates.=20
    
  • Up to $500. monthly in Fuel=20
    rebates. 


Again, I just want to =
emphasize=20
that each re-entry is entitled to all of these rewards and =
benefits.=20
On top of all of these is the Monthly and Annual =
Membership=20
Drive. The club's goal is to give away US$=20
6,000,000  to be rewarded to deserving members in the =
monthly=20
and annual awardings. 


 


Now, get your calculator and do your own math. This is more than a =
Global=20
or a World or a Universal Pool. If you know of something =
big now, I=20
will believe you. But you will agree with me that this is the BIGGEST so =
far in=20
the industry worldwide. And this is now your chance to be a part of =
these fast=20
growing online club. So join now! It cost only $10.


 


For more details, simply reply to this e-mail with more info as =
text.


 


 


Regards,


 


BONG  =
ISON




 


 ----------------------------------------------------------------=
--------------------------------------------------------------





This is just to give you =
an information=20
about the program that I've been doing. It is not my intention to offend =
you or=20
to cause you any trouble. I am just so excited to share this to people =
because I=20
believe this program can enhance people's lives. If you don't want to =
receive=20
any e-mails from me in the future, simply reply to this with =
"REMOVE"=20
as text. If this e-mail has offended you, please accept my apology and =
you will=20
not receive any e-mails from me again. 


           &nbs=
p;   =20



 


 


 


 


 


------=_NextPart_000_04E7_01C028E5.81C27300--



From list@netscape.com  Wed Sep 27 21:26: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 SMTP id VAA26058
	for ; Wed, 27 Sep 2000 21:26: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 e8S1IgM00150;
	Wed, 27 Sep 2000 18:18:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8S1PDA26701;
	Wed, 27 Sep 2000 18:25:13 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 18:25:13 -0700 (PDT)
Message-ID: <39D29B75.843FD5E4@worldspot.com>
Date: Wed, 27 Sep 2000 18:14:29 -0700
From: Rob Weltman 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steven Sonntag 
CC: Rob Weltman , smerrill@novell.com,
        ietf-ldapext@netscape.com, aclark@novell.com, moidrag@netscape.com
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFC123.BBF75AE6@novell.com> <39D021C5.2D3B69C1@worldspot.com> <39D25161.651E106@novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"hHl9SB.A.7gG.43p05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Steven Sonntag wrote:

> Rob Weltman wrote:
>
> > Steven Sonntag wrote:
> > >
> > > Rob Weltman wrote:
> > >
> > > >
> > > > >   3) setOption operates only on the LDAPSearchConstraints object
> > > > >      that is associated with an LDAPConnection object.  Yet
> > > > >      there may also be an LDAPConstraints object associated
> > > > >      with the LDAPConnection object.  It may or may not be
> > > > >      the same as the LDAPSearchConstraints object.  Should
> > > > >      there be a setOption kind of method that operates on
> > > > >      the LDAPConstraints object associated with a connection?
> > > >
> > > >   LDAPSearchConstraints extends LDAPConstraints. There is only one
> > > > such object per connection, and it is an LDAPSearchConstraints. If
> > > > there was an LDAPConstraints object as well, there would be ambiguity
> > > > as to which object controlled operations other than search.   Also,
> > > > see 4 below (which renders this issue mute)
> > >
> > > The thing that is confusing to me is that in the LDAPConnection object
> > > there are the following methods:
> > >
> > > getConstraints()
> > > getSearchConstraints()
> > > setConstraints()
> > > setSearchConstraints()
> > >
> > > Since, as you say, there is only one object per connection, there is
> > > still confusion.  If the
> > > application calls the setConstraints() method with an LDAPConstraints
> > > object, then
> > > there are no search constraints at all, since the added functionality of
> > > the LDAPSearchConstraints
> > > specialization is not present.  Having the four methods make it seem
> > > like there are two separate objects,
> > > or at least that is the way I read it.  Maybe all that is needed is the
> > > set|getConstraints which takes
> > > an LDAPSearchConstraints object and eliminate the other two methods.
> > >
> > > -Steve
> >
> >   In our implementation, setConstraints() just sets the properties of LDAPConstraints, leaving the search-specific properties untouched. setSearchConstraints() replaces all properties. I haven't heard any reports of confusion from the field.
> >
> > Rob
>
> Just to clarify if I understand it correctly
>
> I am/was confused because I was seeing in my minds eye setConstraints implemented
> as storing the object somewhere internal to the class, and the same for setSearchConstraints.
>
> You must be seeing an implementation where a single LDAPSearchConstraints objecct
> exists internally, and the search constraints fields are copied on setConstraints() to the
> internal object, and the search constraints fields are copied on setSearchConstraints().
>
> However getConstraints and getSearchConstraints return a reference to the single internal object.
>

  That is absolutely correct!

Rob

>
> --
> ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software



From list@netscape.com  Wed Sep 27 21:55: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 SMTP id VAA27316
	for ; Wed, 27 Sep 2000 21:55: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 e8S1hLC24060;
	Wed, 27 Sep 2000 18:43:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8S1sCU04974;
	Wed, 27 Sep 2000 18:54:12 -0700 (PDT)
Resent-Date: Wed, 27 Sep 2000 18:54:12 -0700 (PDT)
Message-ID: <39D2A23D.437623C1@worldspot.com>
Date: Wed, 27 Sep 2000 18:43:26 -0700
From: Rob Weltman 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steven Sonntag 
CC: ietf-ldapext@netscape.com, aclark@novell.com, miodrag@netscape.com,
        smerrill@novell.com
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39D25275.DD9616DD@novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"r04Z0.A.ENB.DTq05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Steven Sonntag wrote:

> Rob,
>
> Here are my responses to all of the issues except two.  Those I will
> address in a separate e-mail.
> In the responses below, I have elimated the text except the number and
> first sentence of the topic for most
> of my "OK" responses.  Those where I had more than an OK comment, are
> quoted more fully.
>

  Cool. I'll add a little to the remaining ones.


> > 3.
> > >
> > >  In the java-api-11 I-D, an application doing asynchronous search
> > >  operations is confronted with two different data formats when
> > handling
> > >  referrals and search continuation references.
> > >
> > >  When the application gets a referral status on a search operation,
> > >  referral URL information is retrieved by
> > LDAPResponse.getReferrals()
> > >  as an array of String objects.
> > >
> > >  When the application gets search continuation references as part of
> >
> > >  the search data, the continuation references are retrieved by
> > >  LDAPSearchResultReference.getURLs() as an array of LDAPUrl objects.
> >
> > >
> > >  To be consistent, shouldn't both return an array of LDAPUrl
> > objects?
> >
> > Returning String[] seems more flexible. Steve has recognized that in
> > one of his comments following this one. "...This is because the only
> > way to get the list is via the getURLs() method of the
> > LDAPSearchResultReference.Perhaps it should return the  URLs as a
> > string array, and let the applicationturn them into LDAPUrl objects if
> > desired.  This is backwards to what I said in an earlier e-mail,
> > butnow I see the need for Strings instead of LDAPUrls".
> >
> > So let's return String[] in both cases.
>
> Should the method names be unified, i.e. use getReferrals() instead of
> getUrls() ??

  OK


>
> > 4.
> > > An application doing its own referral handling may need to make
> > >  decisions based on the scheme of URLs returned from search
> > >  continuation references or referrals.
> > >
> > >  Shouldn't the LDAPUrl object provide a method to retrieve
> > >  the URL scheme, viz. ldap, http, & etc.
> >
> > This is an LDAP only URL and not a generic URL, so there is no reason
> > to report a URL scheme. However, there is a need to support ldaps with
> > some LDAP servers. To accomodate them, we propose a boolean method
> > isSecure().
>
> OK - Don't forget toadd this field to the constructors.

  For LDAPUrl? Do we need it there if referrals are only reported as strings?


> > 8.
> > > Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt
>
> OK
>
> > >  It seems that the LDAPRebind interface would be easier to implement
> > if
> > >  additional data were provided in the new LDAPConnection object.
> > Such as:
>
> ( ... )
>
> >   If it really is required (which duplicates what you can do with
> > LDAPBind), how about the following instead (let the implementation
> > pull whatever it needs from the original connection, as LDAPBind
> > does)?
> >
> > LDAPConnection bind(String ldapurl, LDAPConnection origConn);
>
> But LDAPBind doesn't - it returns a void.  If you change it to the
> above,
> i.e. returns LDAPConnection (the new connection) then - OK.
>

  Let me look into that a little.

> > 14.
> > >
> > >  I think the draft should describe more fully the
> > >  semantics of the implicit bind w/r automatic referral following:
> > >
> > >  I will describe what the I-D describes and where
> > >  I have questions:
> > >
> > >  1. Authentication - uses anonomyous credentials unless
> > >     LDAPRebind specified in LDAPConstraints.
>
> OK
>
> >
> > >  2. Protocol Version ?? - Does it use the same protocol
>
> As long as it is added to the constraints so it can be retrieved.

  OK

>
>
> > >  3. AuthenticationMethod: Is it the same as the originating
> > connection,
> > >      or is it "simple" - I assume simple is used.
>
> OK
>
> > >  4. Does it use the LDAPSocketFactory if specified on the
> > >      originating connection.  I am not sure what to do here.
> > >      It seems better to use it if available, then an encrypted
> > >      connection can be established and thus prevent
> > >      clear text password transmittion on the wire.  I just
> > >      talked myself into it - it should be used.
> >
> > If the referral ldap url specifies ldaps, the referral connection
> > should use ldaps (regardless of the original connection). At least in
> > our implementation :-) - since ldaps is being deprecated in favor of
> > startTLS, we may not want to mention it in this I-D (I just remembered
> > that I owe LDAPEXT an informational RFC draft on ldaps). For startTLS,
> > I guess the referral connection should attempt to use startTLS if the
> > original connection was in startTLS mode. Is there any other way to
> > determine whether or not to use startTLS?
>
> IMO the application if the connection is in startTLS mode, the new
> connections should also be startTLS.  Likewise,
> LDAPBind.bind() needs to be able to determine if the connection is in
> startTLS mode so it can also do startTLS, thus
> the app needs to be able to query if the connection is in startTLS mode.

  OK

>
> > 15.
> > >  When performing a search it is possible for the server ...
>
> OK - Just fix the wording a little to reflect this.  4.35.4
> . the last time it is called ..
> seems pretty final, when it really means all referral
> exceptions are the last elements of the enumeration.

  OK


> > 16.
> > >
> > >  Since LDAPResponseListener and LDAPSearchListener
> > >  objects implement exactly the same set of methods,
> > >  does it seem reasonable that an interface be created
> > >  named something like LDAPListener that specifies
> > >  those four methods, and that LDAPSearchListener
> > >  and LDAPResponseListener implement this interface.
> > >  This forces those methods to stay the same in both classes.
> > >
> >
> > > If an LDAPListener interface were created, then
> > > the two methods in LDAPv2.abandon
> > >
> > >    public void abandon(LDAPSearchListener listener)
> > >    public void abandon(LDAPResponseListener listener)
> > >
> > > Could be combined into one
> > >
> > >    public void abandon(LDAPListener listener)
> >
> > We have responded to this earlier, but here is a brief recap. In the
> > very first asynch draft, LDAPSearchListener extended
> > LDAPResponseListener. Later when we adding abandon(int) method, we
> > investigated removing LDAPSearchListener and leaving only
> > LDAPResponseListener because there were implementation issues
> > (multiplexing, and raising exceptions as a result of a lost
> > connection). Then, in order not to change the draft considerably, we
> > decided to make only minor changes and just resolve the implementation
> > problems. We kept LDAPSearchListener, but it does not extend
> > LDAPResponseListener any more.
>
> I get the feeling we are talking about different things.
> I wasn't describing LDAPSearchListener extending LDAPResponseListener,
> but both
> implementing a common interface, viz. LDAPListener, with methods
> getMessageIDs(), getResponse(), isResponseReceived(),
> and merge().  All four of  the methods of each class have identical
> signatures.  Doing this reduces abandon to one call, which
> can easily do exactly what it is doing now by using the instanceof
> operator.

  Sounds reasonable, but let me think about it a little more.


> > 18.
> > >
> > >  4.39.1 LDAPv2.abandon
> > >
> > >  The RFC 2251 and the C api draft allow controls to be specified
> > >  on an abandon operation.  In java it is allowed only using the
> > default
> > >  constraints object or search constraints object.  Should methods
> > >  be defined that allow constraints to be specified on abandon?
> >
> > Strictly speaking this is true, but if we look at the properties in
> > LDAPConstraints, none of them are applicable to abandon(). This change
> > is not required.
>
> Suppose an application needed to put a control on an abandon operation.
> What then?

  True. OK

> >>  What does it mean -
> >>
> >>     if the first version of the method (i.e. the one that specifies no mechanism)
> >>     is called, the LDAP server will be interrogated for its
> >>     supportedSaslMechanisms attribute of its root DSE.
> >>
> >>  What does it do after the LDAP server is interrogated?  Does it use one
> >>  of them, and if so how does the application know which one is used
> >>  and how does it know what kind of credentials to supply?
> >>
> >
> > Yes, if no mechanisms are specified, the mechanisms supported by the
> > server are processed until one is mutually agreed on. The callback
> > handler is called to obtain credentials. Are you thinking that the
> > credentials to be returned depend on the mechanism being negotiated?
> > Let me think about that a little...
>
> That is what I am thinking.  Is perhaps the ChoiceCallback used in some
> way to communicate the negogiated choice, or to
> influence the negotiation possibilities the app will accept?  This area
> is pretty new to me.

  I'm working on that area, too - as spec lead for JSR 28 in the JCP. I think it's a general SASL question, not one specific to the LDAP API. I'll need a little more time to clarify this item.

> > 25.
> >
> >>  4.40.1 bind specifying a mechanism
> >>
> >>  It would seem that if the mechanism is "simple"
> >>  that the API should specify how the password
> >>  is to be specified in the Hashtable object props
> >>  so that it is consistent across implementations.
> >>  Other mechanisms and associated Hashtable
> >>  values are the subject of other I-Ds.
> >>
> >>
> >>  My suggestions:
> >>
> >>        props.put("password", new String("user-password-value");)
> >>
> >
> >   Credentials are obtained from the callback handler.
>
> I was thinking of the same semantics as getPasswd() where the original
> credentials were
> contained in the HashTable.  But as you say, the credentials should be
> obtained
> from the callbackHandler. If the application is handling multiple
> connections each with different characteristics and possibly different
> users, it would need
> a different callback handler for each connection.  The callback handler
> needs to be
> available for implicit bind and explicit bind, and needs to be set in
> the new connection by
> the explicit bind method.  Do we need a mechanism them to get the
> callbackHandler?
>

  I don't think so. It is not persistent in the connection.

>
> What is contained in HashTable if not the credentials??

  See http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt, pages 7 - 8.

> > 27.
> >
> >> When using an explicit bind for referrals where sasl mechanisms
> >> were used on the original LDAPConnection, the LDAPBind.bind()
> >> method will need access to the Hashtable parameter passed on the
> >> bind to get the credentials used.  A method needs to be
> >> supplied in LDAPConnection to get the Hashtable object with
> >> semantics similar to what is now used for getAuthenticationPassword()
> >>
> >
> >   Does it need to be a public method? Can't it be a package scope
> > (implementation-defined) method?
>
> I was thinking it does need to be a public method as the explicit Bind
> method may need access to it.

  I need to think about that some more.

> > 30.
> >
> >> 4.26 LDAPException
> >>
> >>  I am trying to understand where the information in the
> >>  constructor serverMessage comes from.  I am not
> >>  aware of any message that is returned by the server with a
> >>  referral result, except for the actual referral URLs.
> >>
> >>  Do you intend that the class gets primed with the
> >>  referral URLs using the serverMessage parameter
> >>  and if so how are the referrals delimited - otherwise
> >>  can you elaborate on the meaning of this parameter
> >>  and explain how the referral URLs are placed into the
> >>  class.
> >>
> >
> >   That is correct. The server returns the referral URLs in the message
> > field. I don't know if it is necessary to define the representation
> > there (it is a contract between the upper layer of an implementation
> > and the BER decoding layer - which is not defined in the I-D); clients
> > query getURLs() to get the URLs.
> >
>
> A ldap_result  is made up of errmsg, referral, result, matched-dn.  Were
> you thinking of the error message field for ServerMessage?

  That's what is used in our implementation, but I don't think it matters - the client of the API should call getURLs() (or now, getReferrals()) to get the referrals. The client shouldn't need to know how they are stored internally.

Rob




From list@netscape.com  Thu Sep 28 16:20: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 SMTP id QAA01255
	for ; Thu, 28 Sep 2000 16:20: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 e8SKC2M18487;
	Thu, 28 Sep 2000 13:12:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8SKIYk19216;
	Thu, 28 Sep 2000 13:18:34 -0700 (PDT)
Resent-Date: Thu, 28 Sep 2000 13:18:34 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 28 Sep 2000 14:16:59 -0600
From: "Steve Sonntag" 
To: , ,
        "Alan Clark" ,
        "Steven Merrill" , 
Subject: LDAPMessage.nextElement() in java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0A52ED2F.CFAEC8FA"
Resent-Message-ID: <"BIONjD.A.7rE.Ye605"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_0A52ED2F.CFAEC8FA
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

As I was looking at LDAPMessage.nextElement()
I wondered how the API should communicate to the
application that an  LDAP error has occurred on the
connection such as TIMEOUT.  We cannot throw
an LDAPException because that violates the
Enumeration contract.

Should the description be extended to include
returned value may be=20
     an LDAPEntry, an LDAPResponse, or an LDAPReferralException
     where an LDAPResponse is returned on error cases and encapsulates
     the error code.
    =20
-Steve

------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software

--=_0A52ED2F.CFAEC8FA
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







As I was looking at LDAPMessage.nextElement()


I wondered how the API should communicate to the


application that an  LDAP error has occurred on the


connection such as TIMEOUT.  We cannot throw


an LDAPException because that violates the


Enumeration contract.


 


Should the description be extended to include


returned value may be 


     an LDAPEntry, an LDAPResponse, or an=20
LDAPReferralException


     where an LDAPResponse is returned on =
error=20
cases and encapsulates


     the error code.


     


-Steve


 


------------------------
Steve Sonntag
Novell, Inc., the =
leading=20
provider of Net services software


 


 


--=_0A52ED2F.CFAEC8FA--



From list@netscape.com  Fri Sep 29 17:15: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 SMTP id RAA07283
	for ; Fri, 29 Sep 2000 17:15: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 e8TL7PM24440;
	Fri, 29 Sep 2000 14:07:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8TGRWQ29065;
	Fri, 29 Sep 2000 09:27:32 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 09:27:32 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 29 Sep 2000 10:07:57 -0600
From: "Steve Sonntag" 
To: 
Cc: , "Alan Clark" ,
        "Steven Merrill" , 
Subject: Re: LDAPMessage.nextElement() in java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_4E16AE75.92F39532"
Resent-Message-ID: <"fZQaTB.A._AH.jLM15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_4E16AE75.92F39532
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

But the question still remains, how do you communicate a timeout
or other LDAP error to the application?

-Steve

>>> Miodrag Kekic  28-Sep-00 4:04:07 PM >>>
In out current implementation, we return only LDAPEntries and
LDAPExceptions (including also the LDAPReferralException being an
extension of LDAPException). LDAPResponse messages, are used only for
asynch operations. For synchronous ones, they are converted into
LDAPException and as such delivered to the application.

So the text should be "The returned value may be an LDAPEntry or an
LDAPException or an LDAPReferralException".

Miodrag

Steve Sonntag wrote:

>  As I was looking at LDAPMessage.nextElement()I wondered how the API
> should communicate to theapplication that an  LDAP error has occurred
> on theconnection such as TIMEOUT.  We cannot throwan LDAPException
> because that violates theEnumeration contract. Should the description
> be extended to includereturned value may be     an LDAPEntry, an
> LDAPResponse, or an LDAPReferralException     where an LDAPResponse is
> returned on error cases and encapsulates     the error
> code. -Steve ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software

--=_4E16AE75.92F39532
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







But the question still remains, how do you communicate =
a=20
timeout
or other LDAP error to the application?


 


-Steve

>>> Miodrag Kekic=20
<miodrag@netscape.com> 28-Sep-00 4:04:07 PM >>>
In out =
current=20
implementation, we return only LDAPEntries and
LDAPExceptions (including=
 also=20
the LDAPReferralException being an
extension of LDAPException). =
LDAPResponse=20
messages, are used only for
asynch operations. For synchronous ones, =
they are=20
converted into
LDAPException and as such delivered to the=20
application.

So the text should be "The returned value may be an=20
LDAPEntry or an
LDAPException or an=20
LDAPReferralException".

Miodrag

Steve Sonntag=20
wrote:

>  As I was looking at LDAPMessage.nextElement()I =
wondered=20
how the API
> should communicate to theapplication that an  =
LDAP=20
error has occurred
> on theconnection such as TIMEOUT.  We =
cannot=20
throwan LDAPException
> because that violates theEnumeration =
contract.=20
Should the description
> be extended to includereturned value may=20
be     an LDAPEntry, an
> LDAPResponse, or an=20
LDAPReferralException     where an LDAPResponse =
is
>=20
returned on error cases and encapsulates     the=20
error
> code. -Steve ------------------------
> Steve=20
Sonntag
> Novell, Inc., the leading provider of Net services=20
software



--=_4E16AE75.92F39532--



From list@netscape.com  Fri Sep 29 17:24: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 SMTP id RAA07346
	for ; Fri, 29 Sep 2000 17:24: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 e8TLBFC01986;
	Fri, 29 Sep 2000 14:11:15 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8T2GYY05067;
	Thu, 28 Sep 2000 19:16:34 -0700 (PDT)
Resent-Date: Thu, 28 Sep 2000 19:16:34 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 28 Sep 2000 19:26:59 -0600
From: "Steve Sonntag" 
To: 
Cc: , "Alan Clark" ,
        "Steven Merrill" , 
Subject: Re: LDAPMessage.nextElement() in java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_9AC27DF7.FA9BFDC6"
Resent-Message-ID: <"-dm-2.A.uOB.-t_05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_9AC27DF7.FA9BFDC6
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

But the question still remains, how do you communicate a timeout
to the application?

-Steve


>>> Miodrag Kekic  28-Sep-00 4:04:07 PM >>>
In out current implementation, we return only LDAPEntries and
LDAPExceptions (including also the LDAPReferralException being an
extension of LDAPException). LDAPResponse messages, are used only for
asynch operations. For synchronous ones, they are converted into
LDAPException and as such delivered to the application.

So the text should be "The returned value may be an LDAPEntry or an
LDAPException or an LDAPReferralException".

Miodrag

Steve Sonntag wrote:

>  As I was looking at LDAPMessage.nextElement()I wondered how the API
> should communicate to theapplication that an  LDAP error has occurred
> on theconnection such as TIMEOUT.  We cannot throwan LDAPException
> because that violates theEnumeration contract. Should the description
> be extended to includereturned value may be     an LDAPEntry, an
> LDAPResponse, or an LDAPReferralException     where an LDAPResponse is
> returned on error cases and encapsulates     the error
> code. -Steve ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software

--=_9AC27DF7.FA9BFDC6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







But the question still remains, how do you communicate =
a=20
timeout


to the application?


 


-Steve




>>> Miodrag Kekic <miodrag@netscape.com> =
28-Sep-00=20
4:04:07 PM >>>
In out current implementation, we return =
only=20
LDAPEntries and
LDAPExceptions (including also the LDAPReferralException=
=20
being an
extension of LDAPException). LDAPResponse messages, are used =
only=20
for
asynch operations. For synchronous ones, they are converted=20
into
LDAPException and as such delivered to the application.

So =
the=20
text should be "The returned value may be an LDAPEntry or an
LDAPExcepti=
on or=20
an LDAPReferralException".

Miodrag

Steve Sonntag=20
wrote:

>  As I was looking at LDAPMessage.nextElement()I =
wondered=20
how the API
> should communicate to theapplication that an  =
LDAP=20
error has occurred
> on theconnection such as TIMEOUT.  We =
cannot=20
throwan LDAPException
> because that violates theEnumeration =
contract.=20
Should the description
> be extended to includereturned value may=20
be     an LDAPEntry, an
> LDAPResponse, or an=20
LDAPReferralException     where an LDAPResponse =
is
>=20
returned on error cases and encapsulates     the=20
error
> code. -Steve ------------------------
> Steve=20
Sonntag
> Novell, Inc., the leading provider of Net services=20
software



--=_9AC27DF7.FA9BFDC6--



From list@netscape.com  Fri Sep 29 17: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 SMTP id RAA07356
	for ; Fri, 29 Sep 2000 17: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 e8TLBjC02182;
	Fri, 29 Sep 2000 14:11:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8T7j3A18785;
	Fri, 29 Sep 2000 00:45:03 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 00:45:03 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hoytkesterson@mail.earthlink.net
Message-Id: 
Date: Fri, 29 Sep 2000 00:42:23 -0700
To: OSI Directory List ,
        IETF LDAP 
From: "Hoyt L. Kesterson II" 
Subject: draft 4th edition directory texts
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Resent-Message-ID: <"CwDMVC.A.RlE.8hE15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hello all

Erik is in the zone and is rapidly producing the drafts of what will 
be our fourth edition of the directory standard

First drafts of X.501/part-2, X.511/part-3, X.518/part-4, 
X.520/part-6, and X.521/part-7 are up on the server in word and pdf 
formats at

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/

These drafts were constructed by applying the following to the base 
3rd edition:

1) the amendments that have been approved by ITU and are in FDAM 
ballot in ISO/IEC;

2) Erik's and Skip's best guess of what the Related Entries FDAM will 
look like after our editing meeting in November in Orlando;

3) Approved Technical Corrigenda;

4) Draft Technical Corrigenda currently under ballot with a close 
date that allows the comments to be reviewed at the Orlando meeting;

5) Draft Technical Corrigenda that is being developed now and 
submitted so that the ballot date will close before the ITU meeting 
at the end of January; and,

6) Corrected ASN.1 errors found with validaton tools.

These documents, or revisions of them, will be submitted to ITU by 
the morning of 9 October to meet their deadline for texts that will 
be approved at the ITU Study Grup 7 meeting in Geneva 29 January - 3 
February 2001.

Since it is unlikely that these documents will be identical to the 
output of  the editing meeting on Related Entries and with the 
resolution of comments on the Draft Technical Corrigenda, we will 
produce documents detailing the corrections needed. Those will be 
submitted by the seek before the SG7 meeting. In addition those 
documents will contain corrections that are found in the review.

We would like to minimize the number of those types of corrections so 
we are asking all of you to review as much of these texts as 
possible. Please send email to Erik ( mailto://era.als@get2net.dk ) 
and me ( mailto://hoytkesterson@earthlink.com ) describing any errors 
or problems you find. corrections will be incorporated into the texts 
sent to ITU by 9 October.

Erik has done yeoman work here. I intend to buy him a drink in Orlando

    hoyt



From list@netscape.com  Fri Sep 29 17:25:17 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 SMTP id RAA07369
	for ; Fri, 29 Sep 2000 17:25: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 e8TLHFM27658;
	Fri, 29 Sep 2000 14:17:15 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8SM5S207917;
	Thu, 28 Sep 2000 15:05:28 -0700 (PDT)
Resent-Date: Thu, 28 Sep 2000 15:05:28 -0700 (PDT)
Message-ID: <39D3C057.6E1A82CD@netscape.com>
Date: Thu, 28 Sep 2000 15:04:07 -0700
From: miodrag@netscape.com (Miodrag Kekic)
Organization: Netscape Communications
X-Mailer: Mozilla 4.73 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Sonntag 
CC: ietf-ldapext@netscape.com, Alan Clark ,
        Steven Merrill , robw@worldspot.com
Subject: Re: LDAPMessage.nextElement() in java-api-11
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"LCfNLC.A.36B.lC805"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

In out current implementation, we return only LDAPEntries and
LDAPExceptions (including also the LDAPReferralException being an
extension of LDAPException). LDAPResponse messages, are used only for
asynch operations. For synchronous ones, they are converted into
LDAPException and as such delivered to the application.

So the text should be "The returned value may be an LDAPEntry or an
LDAPException or an LDAPReferralException".

Miodrag

Steve Sonntag wrote:

>  As I was looking at LDAPMessage.nextElement()I wondered how the API
> should communicate to theapplication that an  LDAP error has occurred
> on theconnection such as TIMEOUT.  We cannot throwan LDAPException
> because that violates theEnumeration contract. Should the description
> be extended to includereturned value may be     an LDAPEntry, an
> LDAPResponse, or an LDAPReferralException     where an LDAPResponse is
> returned on error cases and encapsulates     the error
> code. -Steve ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software



From list@netscape.com  Fri Sep 29 17:25:34 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 SMTP id RAA07384
	for ; Fri, 29 Sep 2000 17:25: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 e8TLHLM27693;
	Fri, 29 Sep 2000 14:17:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8T1Ev215434;
	Thu, 28 Sep 2000 18:14:57 -0700 (PDT)
Resent-Date: Thu, 28 Sep 2000 18:14:57 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 28 Sep 2000 17:37:06 -0600
From: "Jim Sermersheim" 
To: 
Cc: "Duane Buss" 
Subject: Considering Attribute Subtypes during ACL evaluation
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_6A328D09.03620434"
Resent-Message-ID: <"PAH5ID.A.6wD.O0-05"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_6A328D09.03620434
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Are attribute subtypes considered when calculating access control =
information? In other words, if I have read permission to the "name" =
attribute, does that automatically give me read permission to sn, cn, =
givenName, etc?

I can't find any coverage of this in X.511 or the latest ACL draft. Due to =
the lack of anyone talking about it, my assumption is that, no, permissions=
 do not flow down attribute inheritance chains, they must be explicitly =
stated for each attribute.

Of course with LDAP, this brings up the question of whether they apply to =
attribute type options. It seems to make sense, under most circumstances, =
to apply them in this case. Oh, what a world - what a world.

--=_6A328D09.03620434
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







Are attribute subtypes considered when calculating =
access=20
control information? In other words, if I have read permission to the =
"name"=20
attribute, does that automatically give me read permission to sn, cn, =
givenName,=20
etc?


 


I can't find any coverage of this in X.511 or the =
latest ACL=20
draft. Due to the lack of anyone talking about it, my assumption is that, =
no,=20
permissions do not flow down attribute inheritance chains, they must be=20
explicitly stated for each attribute.


 


Of course with LDAP, this brings up the question of =
whether=20
they apply to attribute type options. It seems to make sense, under =
most=20
circumstances, to apply them in this case. Oh, what a world - what a=20
world.


--=_6A328D09.03620434--



From list@netscape.com  Fri Sep 29 19:37:06 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 SMTP id TAA08226
	for ; Fri, 29 Sep 2000 19:37: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 e8TNO1C26165;
	Fri, 29 Sep 2000 16:24:01 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8TNSFU08945;
	Fri, 29 Sep 2000 16:28:15 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 16:28:15 -0700 (PDT)
Message-ID: <39D50BEC.8D8E8DD9@novell.com>
Date: Fri, 29 Sep 2000 15:38:52 -0600
From: Steven Sonntag 
Organization: Novell, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rob Weltman , ietf-ldapext@netscape.com
CC: aclark@novell.com, smerrill@novell.com, miodrag@netscape.com
Subject: Re: Java LDAP API issues
References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39D25275.DD9616DD@novell.com> <39D2A23D.437623C1@worldspot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"e-4soD.A.KKC.HWS15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

A few remaining comments

Rob Weltman wrote:

> Steven Sonntag wrote:
>
> > Rob,
> >
> > Here are my responses to all of the issues except two.  Those I will
> > address in a separate e-mail.
> > In the responses below, I have elimated the text except the number and
> > first sentence of the topic for most
> > of my "OK" responses.  Those where I had more than an OK comment, are
> > quoted more fully.
> >
>
>   Cool. I'll add a little to the remaining ones.
>
> > > 3.
> > > >
> > > >  In the java-api-11 I-D, an application doing asynchronous search
> > > >  operations is confronted with two different data formats when
> > > handling
> > > >  referrals and search continuation references.
> > > >
> > > >  When the application gets a referral status on a search operation,
> > > >  referral URL information is retrieved by
> > > LDAPResponse.getReferrals()
> > > >  as an array of String objects.
> > > >
> > > >  When the application gets search continuation references as part of
> > >
> > > >  the search data, the continuation references are retrieved by
> > > >  LDAPSearchResultReference.getURLs() as an array of LDAPUrl objects.
> > >
> > > >
> > > >  To be consistent, shouldn't both return an array of LDAPUrl
> > > objects?
> > >
> > > Returning String[] seems more flexible. Steve has recognized that in
> > > one of his comments following this one. "...This is because the only
> > > way to get the list is via the getURLs() method of the
> > > LDAPSearchResultReference.Perhaps it should return the  URLs as a
> > > string array, and let the applicationturn them into LDAPUrl objects if
> > > desired.  This is backwards to what I said in an earlier e-mail,
> > > butnow I see the need for Strings instead of LDAPUrls".
> > >
> > > So let's return String[] in both cases.
> >
> > Should the method names be unified, i.e. use getReferrals() instead of
> > getUrls() ??
>
>   OK
>
> >
> > > 4.
> > > > An application doing its own referral handling may need to make
> > > >  decisions based on the scheme of URLs returned from search
> > > >  continuation references or referrals.
> > > >
> > > >  Shouldn't the LDAPUrl object provide a method to retrieve
> > > >  the URL scheme, viz. ldap, http, & etc.
> > >
> > > This is an LDAP only URL and not a generic URL, so there is no reason
> > > to report a URL scheme. However, there is a need to support ldaps with
> > > some LDAP servers. To accomodate them, we propose a boolean method
> > > isSecure().
> >
> > OK - Don't forget toadd this field to the constructors.
>
>   For LDAPUrl? Do we need it there if referrals are only reported as strings?
>

Are you thinking to eliminate the LDAPUrl class?
IMO it is certainly very useful when one needs to break apart a URL.
Connection.search( LDAPURL toGet) needs it, which I believe to
be a very useful function. An application doing its own referral
following certainly needs to break referrals apart, and what better
way than with the LDAPUrl class.  It makes a very nice utility class.
I say keep it.

>
> > > 8.
> > > > Re: LDAPBind as defined in draft-ietf-ldapext-ldap-java-api-11.txt
> >
> > OK
> >
> > > >  It seems that the LDAPRebind interface would be easier to implement
> > > if
> > > >  additional data were provided in the new LDAPConnection object.
> > > Such as:
> >
> > ( ... )
> >
> > >   If it really is required (which duplicates what you can do with
> > > LDAPBind), how about the following instead (let the implementation
> > > pull whatever it needs from the original connection, as LDAPBind
> > > does)?
> > >
> > > LDAPConnection bind(String ldapurl, LDAPConnection origConn);
> >
> > But LDAPBind doesn't - it returns a void.  If you change it to the
> > above,
> > i.e. returns LDAPConnection (the new connection) then - OK.
> >
>
>   Let me look into that a little.

I think bind() just has the wrong return type.

>
>
> > > 14.
> > > >
> > > >  I think the draft should describe more fully the
> > > >  semantics of the implicit bind w/r automatic referral following:
> > > >
> > > >  I will describe what the I-D describes and where
> > > >  I have questions:
> > > >
> > > >  1. Authentication - uses anonomyous credentials unless
> > > >     LDAPRebind specified in LDAPConstraints.
> >
> > OK
> >
> > >
> > > >  2. Protocol Version ?? - Does it use the same protocol
> >
> > As long as it is added to the constraints so it can be retrieved.
>
>   OK
>
> >
> >
> > > >  3. AuthenticationMethod: Is it the same as the originating
> > > connection,
> > > >      or is it "simple" - I assume simple is used.
> >
> > OK
> >
> > > >  4. Does it use the LDAPSocketFactory if specified on the
> > > >      originating connection.  I am not sure what to do here.
> > > >      It seems better to use it if available, then an encrypted
> > > >      connection can be established and thus prevent
> > > >      clear text password transmittion on the wire.  I just
> > > >      talked myself into it - it should be used.
> > >
> > > If the referral ldap url specifies ldaps, the referral connection
> > > should use ldaps (regardless of the original connection). At least in
> > > our implementation :-) - since ldaps is being deprecated in favor of
> > > startTLS, we may not want to mention it in this I-D (I just remembered
> > > that I owe LDAPEXT an informational RFC draft on ldaps). For startTLS,
> > > I guess the referral connection should attempt to use startTLS if the
> > > original connection was in startTLS mode. Is there any other way to
> > > determine whether or not to use startTLS?
> >
> > IMO the application if the connection is in startTLS mode, the new
> > connections should also be startTLS.  Likewise,
> > LDAPBind.bind() needs to be able to determine if the connection is in
> > startTLS mode so it can also do startTLS, thus
> > the app needs to be able to query if the connection is in startTLS mode.
>
>   OK
>
> >
> > > 15.
> > > >  When performing a search it is possible for the server ...
> >
> > OK - Just fix the wording a little to reflect this.  4.35.4
> > . the last time it is called ..
> > seems pretty final, when it really means all referral
> > exceptions are the last elements of the enumeration.
>
>   OK
>
> > > 16.
> > > >
> > > >  Since LDAPResponseListener and LDAPSearchListener
> > > >  objects implement exactly the same set of methods,
> > > >  does it seem reasonable that an interface be created
> > > >  named something like LDAPListener that specifies
> > > >  those four methods, and that LDAPSearchListener
> > > >  and LDAPResponseListener implement this interface.
> > > >  This forces those methods to stay the same in both classes.
> > > >
> > >
> > > > If an LDAPListener interface were created, then
> > > > the two methods in LDAPv2.abandon
> > > >
> > > >    public void abandon(LDAPSearchListener listener)
> > > >    public void abandon(LDAPResponseListener listener)
> > > >
> > > > Could be combined into one
> > > >
> > > >    public void abandon(LDAPListener listener)
> > >
> > > We have responded to this earlier, but here is a brief recap. In the
> > > very first asynch draft, LDAPSearchListener extended
> > > LDAPResponseListener. Later when we adding abandon(int) method, we
> > > investigated removing LDAPSearchListener and leaving only
> > > LDAPResponseListener because there were implementation issues
> > > (multiplexing, and raising exceptions as a result of a lost
> > > connection). Then, in order not to change the draft considerably, we
> > > decided to make only minor changes and just resolve the implementation
> > > problems. We kept LDAPSearchListener, but it does not extend
> > > LDAPResponseListener any more.
> >
> > I get the feeling we are talking about different things.
> > I wasn't describing LDAPSearchListener extending LDAPResponseListener,
> > but both
> > implementing a common interface, viz. LDAPListener, with methods
> > getMessageIDs(), getResponse(), isResponseReceived(),
> > and merge().  All four of  the methods of each class have identical
> > signatures.  Doing this reduces abandon to one call, which
> > can easily do exactly what it is doing now by using the instanceof
> > operator.
>
>   Sounds reasonable, but let me think about it a little more.

OK - seems reasonable to me also.

>
>
> > > 18.
> > > >
> > > >  4.39.1 LDAPv2.abandon
> > > >
> > > >  The RFC 2251 and the C api draft allow controls to be specified
> > > >  on an abandon operation.  In java it is allowed only using the
> > > default
> > > >  constraints object or search constraints object.  Should methods
> > > >  be defined that allow constraints to be specified on abandon?
> > >
> > > Strictly speaking this is true, but if we look at the properties in
> > > LDAPConstraints, none of them are applicable to abandon(). This change
> > > is not required.
> >
> > Suppose an application needed to put a control on an abandon operation.
> > What then?
>
>   True. OK
>
> > >>  What does it mean -
> > >>
> > >>     if the first version of the method (i.e. the one that specifies no mechanism)
> > >>     is called, the LDAP server will be interrogated for its
> > >>     supportedSaslMechanisms attribute of its root DSE.
> > >>
> > >>  What does it do after the LDAP server is interrogated?  Does it use one
> > >>  of them, and if so how does the application know which one is used
> > >>  and how does it know what kind of credentials to supply?
> > >>
> > >
> > > Yes, if no mechanisms are specified, the mechanisms supported by the
> > > server are processed until one is mutually agreed on. The callback
> > > handler is called to obtain credentials. Are you thinking that the
> > > credentials to be returned depend on the mechanism being negotiated?
> > > Let me think about that a little...
> >
> > That is what I am thinking.  Is perhaps the ChoiceCallback used in some
> > way to communicate the negogiated choice, or to
> > influence the negotiation possibilities the app will accept?  This area
> > is pretty new to me.
>
>   I'm working on that area, too - as spec lead for JSR 28 in the JCP. I think it's a general SASL question, not one specific to the LDAP API. I'll need a little more time to clarify this item.
>
> > > 25.
> > >
> > >>  4.40.1 bind specifying a mechanism
> > >>
> > >>  It would seem that if the mechanism is "simple"
> > >>  that the API should specify how the password
> > >>  is to be specified in the Hashtable object props
> > >>  so that it is consistent across implementations.
> > >>  Other mechanisms and associated Hashtable
> > >>  values are the subject of other I-Ds.
> > >>
> > >>
> > >>  My suggestions:
> > >>
> > >>        props.put("password", new String("user-password-value");)
> > >>
> > >
> > >   Credentials are obtained from the callback handler.
> >
> > I was thinking of the same semantics as getPasswd() where the original
> > credentials were
> > contained in the HashTable.  But as you say, the credentials should be
> > obtained
> > from the callbackHandler. If the application is handling multiple
> > connections each with different characteristics and possibly different
> > users, it would need
> > a different callback handler for each connection.  The callback handler
> > needs to be
> > available for implicit bind and explicit bind, and needs to be set in
> > the new connection by
> > the explicit bind method.  Do we need a mechanism them to get the
> > callbackHandler?
> >
>
>   I don't think so. It is not persistent in the connection.

I'm just trying to figure out how to solve the problem of multiple connections,
each with different connection characteristics, perhaps different users.
When doing an explicit bind, how does the application get credentials
specifiic to that connection/user.  Would the callback handler being
persistent help solve this, or ??

>
>
> >
> > What is contained in HashTable if not the credentials??
>
>   See http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt, pages 7 - 8.
>

Thanks, I had missed that one.

>
> > > 27.
> > >
> > >> When using an explicit bind for referrals where sasl mechanisms
> > >> were used on the original LDAPConnection, the LDAPBind.bind()
> > >> method will need access to the Hashtable parameter passed on the
> > >> bind to get the credentials used.  A method needs to be
> > >> supplied in LDAPConnection to get the Hashtable object with
> > >> semantics similar to what is now used for getAuthenticationPassword()
> > >>
> > >
> > >   Does it need to be a public method? Can't it be a package scope
> > > (implementation-defined) method?
> >
> > I was thinking it does need to be a public method as the explicit Bind
> > method may need access to it.
>
>   I need to think about that some more.
>
> > > 30.
> > >
> > >> 4.26 LDAPException
> > >>
> > >>  I am trying to understand where the information in the
> > >>  constructor serverMessage comes from.  I am not
> > >>  aware of any message that is returned by the server with a
> > >>  referral result, except for the actual referral URLs.
> > >>
> > >>  Do you intend that the class gets primed with the
> > >>  referral URLs using the serverMessage parameter
> > >>  and if so how are the referrals delimited - otherwise
> > >>  can you elaborate on the meaning of this parameter
> > >>  and explain how the referral URLs are placed into the
> > >>  class.
> > >>
> > >
> > >   That is correct. The server returns the referral URLs in the message
> > > field. I don't know if it is necessary to define the representation
> > > there (it is a contract between the upper layer of an implementation
> > > and the BER decoding layer - which is not defined in the I-D); clients
> > > query getURLs() to get the URLs.
> > >
> >
> > A ldap_result  is made up of errmsg, referral, result, matched-dn.  Were
> > you thinking of the error message field for ServerMessage?
>
>   That's what is used in our implementation, but I don't think it matters - the client of the API should call getURLs() (or now, getReferrals()) to get the referrals. The client shouldn't need to know how they are stored internally.
>
> Rob

--
------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software




From list@netscape.com  Fri Sep 29 19:38: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 SMTP id TAA08238
	for ; Fri, 29 Sep 2000 19:38: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 e8TNO1C26169;
	Fri, 29 Sep 2000 16:24:02 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8TNWWA13834;
	Fri, 29 Sep 2000 16:32:32 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 16:32:32 -0700 (PDT)
Message-Id: <5.0.0.25.0.20000929143030.00a83eb0@router.boolean.net>
X-Sender: guru@router.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 29 Sep 2000 14:53:12 -0700
To: "Jim Sermersheim" 
From: "Kurt D. Zeilenga" 
Subject: Re: Considering Attribute Subtypes during ACL evaluation
Cc: , "Duane Buss" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"MyQ6cB.A.MWD.MaS15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 05:37 PM 9/28/00 -0600, Jim Sermersheim wrote:
>Are attribute subtypes considered when calculating access control information? In other words, if I have read permission to the "name" attribute, does that automatically give me read permission to sn, cn, givenName, etc?
> 
>I can't find any coverage of this in X.511 or the latest ACL draft. Due to the lack of anyone talking about it, my assumption is that, no, permissions do not flow down attribute inheritance chains, they must be explicitly stated for each attribute.
> 
>Of course with LDAP, this brings up the question of whether they apply to attribute type options. It seems to make sense, under most circumstances, to apply them in this case. Oh, what a world - what a world.

When I asked this question previously, the answer was "no, ACLs
apply only to the specified type, not subtypes".

I have argued that each ACL should be applied subtypes.  One
issue in adding such is which ACL takes precedence.  This is
complicated due to multiple inheritance due to attribute
description options.

One possible precedence:
        type;a;b;c
        type
        supertype;a;b;c
        supertype

Of course, if one of the options was "binary", it sure would be
nice to allow
        type;a;binary;c
        type;a;c
        type
        supertype;a;binary;c
        supertype;a;c
        supertype

But this seems overly complicated.  An alternative would be to
say that ACLs apply to attribute types, not attribute descriptions.
So, access to "type;a;b;c" would be governed by:
        type
        supertype

I prefer this.

Kurt




From list@netscape.com  Fri Sep 29 19:38: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 SMTP id TAA08248
	for ; Fri, 29 Sep 2000 19:38: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 e8TNNtC26119;
	Fri, 29 Sep 2000 16:23:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8TNVGA12571;
	Fri, 29 Sep 2000 16:31:16 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 16:31:16 -0700 (PDT)
Date: Fri, 29 Sep 2000 14:23:04 -0700 (PDT)
Message-Id: <200009292123.e8TLN4H20724@ywing.netscape.com>
From: kesmet@ywing.netscape.com
To: money@netscape.com
Subject:  $$$$$$$$$ -BDAC
X-Reply-To:  kesmet@aol.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"q98S2.A.I8C.uYS15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

 I Saw this on the news its the real deal click below 
http://www.ticket-trust.com/$5Fast/mailer.cfm?id=1111
yours truly john




From list@netscape.com  Fri Sep 29 19:40: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 SMTP id TAA08309
	for ; Fri, 29 Sep 2000 19:40: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 e8TNWRM24555;
	Fri, 29 Sep 2000 16:32:27 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8TNd0s19534;
	Fri, 29 Sep 2000 16:39:00 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 16:39:00 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 29 Sep 2000 15:20:13 -0600
From: "Steve Sonntag" 
To: 
Cc: , "Alan Clark" ,
        "Steven Merrill" , 
Subject: Re: LDAPMessage.nextElement() in java-api-11
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_075FE684.FC9DFB65"
Resent-Message-ID: <"KbMuTC.A.zwE.TgS15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_075FE684.FC9DFB65
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Good!  The draft should then be reworded then to change 4.35.5 from

The returned value may be an LDAPEntry or an LDAPReferralException
    to
The returned value may be an LDAPEntry or an LDAPException


-Steve

>>> Miodrag Kekic  29-Sep-00 2:22:33 PM >>>
This is done through the LDAPExceptions which are returned as result =
elements rather than being thrown.  Example:=20
      LDAPSearchResults res =3D ld.search( base,ld.SCOPE_BASE, filter, =
null,false);=20
      while ( res.hasMoreElements() ) {=20
        Object o =3D res.nextElement();=20
        if ( o instanceof LDAPEntry ) {=20
          LDAPEntry findEntry =3D (LDAPEntry)o;=20
          System.err.println(findEntry);=20
          ...=20
        } else if ( o instanceof LDAPReferralException ) {=20
          LDAPReferralException e =3D (LDAPReferralException)o;=20
          LDAPUrl refUrls[] =3D e.getURLs();=20
          ...=20
        } else if ( o instanceof LDAPException ) { =20
          LDAPException e =3D (LDAPException)o;=20
          // check for the timeout=20
          if (e.getLDAPResultCode =3D=3D e.LDAP_TIMEOUT) {=20
           ...=20
          }=20
          ...=20
        }=20
Miodrag=20
Steve Sonntag wrote:=20
 But the question still remains, how do you communicate a timeout=20
or other LDAP error to the application? -Steve=20
>>> Miodrag Kekic  28-Sep-00 4:04:07 PM >>>=20
In out current implementation, we return only LDAPEntries and=20
LDAPExceptions (including also the LDAPReferralException being an=20
extension of LDAPException). LDAPResponse messages, are used only for=20
asynch operations. For synchronous ones, they are converted into=20
LDAPException and as such delivered to the application.=20
So the text should be "The returned value may be an LDAPEntry or an=20
LDAPException or an LDAPReferralException".=20
Miodrag=20
Steve Sonntag wrote:=20
>  As I was looking at LDAPMessage.nextElement()I wondered how the API=20
> should communicate to theapplication that an  LDAP error has occurred=20
> on theconnection such as TIMEOUT.  We cannot throwan LDAPException=20
> because that violates theEnumeration contract. Should the description=20
> be extended to includereturned value may be     an LDAPEntry, an=20
> LDAPResponse, or an LDAPReferralException     where an LDAPResponse =
is=20
> returned on error cases and encapsulates     the error=20
> code. -Steve ------------------------=20
> Steve Sonntag=20
> Novell, Inc., the leading provider of Net services software=20
=20

--=_075FE684.FC9DFB65
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable







Good!  The draft should then be reworded then to =
change=20
4.35.5 from


 


The returned value may be an LDAPEntry or an LDAPReferralException

    to


The returned value may be an LDAPEntry or an LDAPException


 


 


-Steve

>>> Miodrag Kekic <miodrag@netscape.com>=
=20
29-Sep-00 2:22:33 PM >>>
This is done through the LDAPException=
s=20
which are returned as result elements rather than being thrown.  =
Example:=20



      LDAPSearchResults res =3D ld.search(=
=20
base,ld.SCOPE_BASE, filter, null,false);=20

      while ( res.hasMoreElements() ) =
{=20

        Object o =3D=20
res.nextElement(); 
        =
if (=20
o instanceof LDAPEntry ) {=20

          LDAPEntry=20=

findEntry =3D (LDAPEntry)o;=20

         =20
System.err.println(findEntry);=20

          ...=20

        } else if ( o instanceof=
=20
LDAPReferralException ) {=20

         =20
LDAPReferralException e =3D (LDAPReferralException)o;=20

          LDAPUrl =
refUrls[]=20
=3D e.getURLs();=20

          ...=20

        } else if ( o instanceof=
=20
LDAPException ) { =20

          LDAPExceptio=
n e =3D=20
(LDAPException)o;=20

          // check =
for the=20
timeout 
         =
 if=20
(e.getLDAPResultCode =3D=3D e.LDAP_TIMEOUT) {=20

           =
...=20

          }=20

          ...=20

        }=20

Miodrag=20

Steve Sonntag wrote:=20

 But the question still =
remains,=20
  how do you communicate a timeout 
or other =
LDAP error=20
  to the application? -Steve=20
  
>>> Miodrag Kekic <miodrag@netscape.com> 28-Sep-00 =
4:04:07=20
  PM >>> 
In out current implementation, we return only =
LDAPEntries=20
  and 
LDAPExceptions (including also the LDAPReferralException being =
an=20
  
extension of LDAPException). LDAPResponse messages, are used only =
for=20
  
asynch operations. For synchronous ones, they are converted into=20
  
LDAPException and as such delivered to the application.=20
  
So the text should be "The returned value may be an LDAPEntry or =
an=20
  
LDAPException or an LDAPReferralException".=20
  
Miodrag=20
  
Steve Sonntag wrote:=20
  
>  As I was looking at LDAPMessage.nextElement()I wondered =
how the=20
  API 
> should communicate to theapplication that an  LDAP =
error has=20
  occurred 
> on theconnection such as TIMEOUT.  We cannot =
throwan=20
  LDAPException 
> because that violates theEnumeration contract. =
Should=20
  the description 
> be extended to includereturned value may=20
  be     an LDAPEntry, an 
> LDAPResponse, or =
an=20
  LDAPReferralException     where an LDAPResponse =
is=20
  
> returned on error cases and encapsulates    =
 the=20
  error 
> code. -Steve ------------------------ 
> Steve =
Sonntag=20
  
> Novell, Inc., the leading provider of Net services software=20
  
 


--=_075FE684.FC9DFB65--



From list@netscape.com  Fri Sep 29 19:51:15 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 SMTP id TAA08355
	for ; Fri, 29 Sep 2000 19:51: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 e8TNcPC29349;
	Fri, 29 Sep 2000 16:38:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8TNnIs26361;
	Fri, 29 Sep 2000 16:49:18 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 16:49:18 -0700 (PDT)
Date: Fri, 29 Sep 2000 16:49:05 -0700 (PDT)
Message-Id: <200009292349.e8TNmjI26369@xwing.netscape.com>
From: robnsli@nais.com
To: American@xwing.netscape.com, Dreamer@netscape.com
Subject:  Voted #1 Self-run e-Business
X-Reply-To:  robnsli@nais.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"z2g-kC.A.fbG.7pS15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Dear Friend,

How would you like to quit your job, become your own boss, and build up enough residual income to 
support yourself for the rest of your life?

...Forget the old days of Network Marketing where you had to show the "show the plan" and meet at the 
local high school for a "ra-ra" meeting. Our company offers you the opportunity that can be operated from 
in front of your computer screen.

Imagine the feeling of being able to offer our opportunity and products to millions of people in over 42 
countries and Territories around the World.

..Not only do you have the ability to own a profitable home-based business which is operating in the United 
States but you also have distributors all over the World.

Make a well informed decision which will impact your future today  !   

Simply visit our award-winning website:

http://www.cyber-action.com/oed/americandream.html      

 With My Warmest Regards,

Robert Adelmann
robnsli@nais.com                                                         




From list@netscape.com  Fri Sep 29 21:02: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 SMTP id VAA08881
	for ; Fri, 29 Sep 2000 21: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 e8U0oJC09170;
	Fri, 29 Sep 2000 17:50:20 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8U11DQ16800;
	Fri, 29 Sep 2000 18:01:13 -0700 (PDT)
Resent-Date: Fri, 29 Sep 2000 18:01:13 -0700 (PDT)
DATE: 29 Sep 00 7:51:25 AM
FROM: hotcallingcard1234@yahoo.com
Message-ID: 
SUBJECT: Less than a dollar for 100 minutes of long distance.
Resent-Message-ID: <"dTKiJC.A.OGE.YtT15"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Talk to Anyone, Anywhere in the U.S. for Less than a Penny per Minute.

With our calling card you'll get the lowest long distance prices anywhere! No connection fees, or any hidden costs of any kind. We can offer this fantastic deal because of our high volume of repeat business. We deliver the highest value in the industry and, best of all, your satisfaction is absolutely guaranteed! 

For just $39 you get 3910 minutes to call anywhere in the U.S., any time. That's less than a buck for 100 minutes! Don't wait! This is the best deal going from one of America's most dependable telecommunication's companies.

For your convenience we accept personal checks, cash, cashiers checks and money orders. CA residents please add 8.25% sales Tax.

Mark your order then print the following form and mail to:

SMARTEC
1626 N. Wilcox, Suite 590
Hollywood, CA 90028

___$39 for 3910 minutes	    ___ $59 for 6000 minutes
___$49 for 4950 minutes 	    ___ $79 for 8300 minutes

Ship to: _______________________________________________
Shipping Address: _______________________________________
City: __________________________________________________
State: _________________________________________________
Zip Code: ______________________________________________
Your email: _____________________________________________
Your telephone: _________________________________________

Make all checks payable to:  SMARTEC

All orders are shipped within 48 hours.


To be removed from our future mailing please email list2299@losangeles.usa.com and you will be removed instantly.

 



From list@netscape.com  Sat Sep 30 07:14: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 SMTP id HAA27237
	for ; Sat, 30 Sep 2000 07:14: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 e8UB6TM29592;
	Sat, 30 Sep 2000 04:06:30 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8UBD4E02236;
	Sat, 30 Sep 2000 04:13:04 -0700 (PDT)
Resent-Date: Sat, 30 Sep 2000 04:13:04 -0700 (PDT)
From: hahnt@us.ibm.com
Importance: Normal
To: 
Subject: Re: Considering Attribute Subtypes during ACL evaluation
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Endicott/IBM(Release 5.0.3 (Intl)|21
 March 2000) at 09/30/2000 06:33:14 AM,
	Serialize by Notes Client on Timothy Hahn/Endicott/IBM(Release 5.0.3 (Intl)|21
 March 2000) at 09/30/2000 06:33:14 AM,
	Serialize complete at 09/30/2000 06:33:14 AM,
	S/MIME Sign failed at 09/30/2000 06:33:14 AM: The cryptographic key was not
 found,
	Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August
 28, 2000) at 09/30/2000 07:13:00 AM,
	Serialize complete at 09/30/2000 07:13:00 AM
Message-ID: 
Date: Sat, 30 Sep 2000 07:12:59 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0039F9718525696A_="
Resent-Message-ID: <"l_TFI.A.qi.-qc15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multipart message in MIME format.
--=_alternative 0039F9718525696A_=
Content-Type: text/plain; charset="us-ascii"

Jim,

Good question!

I know that implementing access control such that attribute inheritance 
were taken into account would definitely be harder, but I feel that 
attribute inheritance SHOULD be considered during access control checks.

Thus, if some entity is granted read and write privileges to 'name', then 
they should be allowed the same privileges to 'cn', 'sn', and 
'cn;lang-en'.  (unless overidden by another permission that disallows such 
access).

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

To:     
cc:     "Duane Buss"  
Subject:        Considering Attribute Subtypes during ACL evaluation




Are attribute subtypes considered when calculating access  control 
information? In other words, if I have read permission to the "name" 
attribute, does that automatically give me read permission to sn, cn, 
givenName,  etc?
 
I can't find any coverage of this in X.511 or the latest ACL  draft. Due 
to the lack of anyone talking about it, my assumption is that, no, 
permissions do not flow down attribute inheritance chains, they must be 
explicitly stated for each attribute.
 
Of course with LDAP, this brings up the question of whether  they apply to 
attribute type options. It seems to make sense, under most  circumstances, 
to apply them in this case. Oh, what a world - what a  world.


--=_alternative 0039F9718525696A_=
Content-Type: text/html; charset="us-ascii"



Jim,



Good question!



I know that implementing access control such that attribute inheritance were taken into account would definitely be harder, but I feel that attribute inheritance SHOULD be considered during access control checks.



Thus, if some entity is granted read and write privileges to 'name', then they should be allowed the same privileges to 'cn', 'sn', and 'cn;lang-en'.  (unless overidden by another permission that disallows such access).



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



To:        <ietf-ldapext@netscape.com>

cc:        "Duane Buss" <DBuss@novell.com> 

Subject:        Considering Attribute Subtypes during ACL evaluation









Are attribute subtypes considered when calculating access  control information? In other words, if I have read permission to the "name"  attribute, does that automatically give me read permission to sn, cn, givenName,  etc?

 

I can't find any coverage of this in X.511 or the latest ACL  draft. Due to the lack of anyone talking about it, my assumption is that, no,  permissions do not flow down attribute inheritance chains, they must be  explicitly stated for each attribute.

 

Of course with LDAP, this brings up the question of whether  they apply to attribute type options. It seems to make sense, under most  circumstances, to apply them in this case. Oh, what a world - what a  world.




--=_alternative 0039F9718525696A_=--



From list@netscape.com  Sat Sep 30 07:14: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 SMTP id HAA27247
	for ; Sat, 30 Sep 2000 07:14: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 e8UB6WM29630;
	Sat, 30 Sep 2000 04:06:33 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8UBD7A02302;
	Sat, 30 Sep 2000 04:13:07 -0700 (PDT)
Resent-Date: Sat, 30 Sep 2000 04:13:07 -0700 (PDT)
From: hahnt@us.ibm.com
Importance: Normal
To: 
Subject: Re: Considering Attribute Subtypes during ACL evaluation
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
X-MIMETrack: S/MIME Sign by Notes Client on Timothy Hahn/Endicott/IBM(Release 5.0.3 (Intl)|21
 March 2000) at 09/30/2000 06:44:25 AM,
	Serialize by Notes Client on Timothy Hahn/Endicott/IBM(Release 5.0.3 (Intl)|21
 March 2000) at 09/30/2000 06:44:25 AM,
	Serialize complete at 09/30/2000 06:44:25 AM,
	S/MIME Sign failed at 09/30/2000 06:44:25 AM: The cryptographic key was not
 found,
	Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August
 28, 2000) at 09/30/2000 07:13:02 AM,
	Serialize complete at 09/30/2000 07:13:02 AM
Message-ID: 
Date: Sat, 30 Sep 2000 07:13:00 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 003AFF8F8525696A_="
Resent-Message-ID: <"AF8YKD.A.Qj.Brc15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multipart message in MIME format.
--=_alternative 003AFF8F8525696A_=
Content-Type: text/plain; charset="us-ascii"

Kurt,

If we limit the access control syntax/BNF so as to not allow attribute 
descriptions in the specification of the ACI, then it seems to me we can 
go with your final approach at the bottom.  This seems to me to be 
sufficient and expressive, and still allows an ACI to be specified on 
"name" and apply to "cn" and "sn", etc.

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

To:     "Jim Sermersheim" 
cc:     , "Duane Buss"  
Subject:        Re: Considering Attribute Subtypes during ACL evaluation



At 05:37 PM 9/28/00 -0600, Jim Sermersheim wrote:
>Are attribute subtypes considered when calculating access control 
information? In other words, if I have read permission to the "name" 
attribute, does that automatically give me read permission to sn, cn, 
givenName, etc?
>
>I can't find any coverage of this in X.511 or the latest ACL draft. Due 
to the lack of anyone talking about it, my assumption is that, no, 
permissions do not flow down attribute inheritance chains, they must be 
explicitly stated for each attribute.
>
>Of course with LDAP, this brings up the question of whether they apply to 
attribute type options. It seems to make sense, under most circumstances, 
to apply them in this case. Oh, what a world - what a world.

When I asked this question previously, the answer was "no, ACLs
apply only to the specified type, not subtypes".

I have argued that each ACL should be applied subtypes.  One
issue in adding such is which ACL takes precedence.  This is
complicated due to multiple inheritance due to attribute
description options.

One possible precedence:
        type;a;b;c
        type
        supertype;a;b;c
        supertype

Of course, if one of the options was "binary", it sure would be
nice to allow
        type;a;binary;c
        type;a;c
        type
        supertype;a;binary;c
        supertype;a;c
        supertype

But this seems overly complicated.  An alternative would be to
say that ACLs apply to attribute types, not attribute descriptions.
So, access to "type;a;b;c" would be governed by:
        type
        supertype

I prefer this.

Kurt




--=_alternative 003AFF8F8525696A_=
Content-Type: text/html; charset="us-ascii"



Kurt,



If we limit the access control syntax/BNF so as to not allow attribute descriptions in the specification of the ACI, then it seems to me we can go with your final approach at the bottom.  This seems to me to be sufficient and expressive, and still allows an ACI to be specified on "name" and apply to "cn" and "sn", etc.



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



To:        "Jim Sermersheim" <JIMSE@novell.com>

cc:        <ietf-ldapext@netscape.com>, "Duane Buss" <DBuss@novell.com> 

Subject:        Re: Considering Attribute Subtypes during ACL evaluation







At 05:37 PM 9/28/00 -0600, Jim Sermersheim wrote:

>Are attribute subtypes considered when calculating access control information? In other words, if I have read permission to the "name" attribute, does that automatically give me read permission to sn, cn, givenName, etc?

>

>I can't find any coverage of this in X.511 or the latest ACL draft. Due to the lack of anyone talking about it, my assumption is that, no, permissions do not flow down attribute inheritance chains, they must be explicitly stated for each attribute.

>

>Of course with LDAP, this brings up the question of whether they apply to attribute type options. It seems to make sense, under most circumstances, to apply them in this case. Oh, what a world - what a world.



When I asked this question previously, the answer was "no, ACLs

apply only to the specified type, not subtypes".



I have argued that each ACL should be applied subtypes.  One

issue in adding such is which ACL takes precedence.  This is

complicated due to multiple inheritance due to attribute

description options.



One possible precedence:

        type;a;b;c

        type

        supertype;a;b;c

        supertype



Of course, if one of the options was "binary", it sure would be

nice to allow

        type;a;binary;c

        type;a;c

        type

        supertype;a;binary;c

        supertype;a;c

        supertype



But this seems overly complicated.  An alternative would be to

say that ACLs apply to attribute types, not attribute descriptions.

So, access to "type;a;b;c" would be governed by:

        type

        supertype



I prefer this.



Kurt








--=_alternative 003AFF8F8525696A_=--



From list@netscape.com  Sat Sep 30 10:22: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 SMTP id KAA28597
	for ; Sat, 30 Sep 2000 10:22: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 e8UEDtM16689;
	Sat, 30 Sep 2000 07:13:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8UEKVg06555;
	Sat, 30 Sep 2000 07:20:31 -0700 (PDT)
Resent-Date: Sat, 30 Sep 2000 07:20:31 -0700 (PDT)
Date: Sat, 30 Sep 2000 07:20:28 -0700 (PDT)
Message-Id: <200009301420.e8UEKSI21578@xwing.netscape.com>
From: kesmet@xwing.netscape.com
To: money@netscape.com
Subject:  $$$$$$$$$ -OLOB
X-Reply-To:  kesmet@aol.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"nfNLLB.A.CmB.uaf15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

 I Saw this on the news its the real deal click below 
http://www.ticket-trust.com/$5Fast/mailer.cfm?id=1111
yours truly john




From list@netscape.com  Sat Sep 30 10:37: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 SMTP id KAA28656
	for ; Sat, 30 Sep 2000 10:37: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 e8UERuM17937;
	Sat, 30 Sep 2000 07:27:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8UEYWs10403;
	Sat, 30 Sep 2000 07:34:32 -0700 (PDT)
Resent-Date: Sat, 30 Sep 2000 07:34:32 -0700 (PDT)
Message-ID: <39D5FB0D.EC5E4F0B@netscape.com>
Date: Sat, 30 Sep 2000 07:39:09 -0700
From: prasanta@netscape.com (Prasanta Behera)
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hahnt@us.ibm.com
CC: ietf-ldapext@netscape.com
Subject: Re: Considering Attribute Subtypes during ACL evaluation
References: 
Content-Type: multipart/alternative;
 boundary="------------3646A3A18AC93DAE7B40C5B4"
Resent-Message-ID: <"cb-LeB.A.RiC.3nf15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


--------------3646A3A18AC93DAE7B40C5B4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Currently  the netscape/iPlanet DS ACL supports a attribute inheritance
of subtypes e.g. if you allow access to
"cn", it automatically means { cn, cn;* }

However, it is much harder to map "name" to "cn, sn".
Why can't this be a UI thing? Why does it have to be
declarative in the ACL syntax itself. It will be nice if it
can be supported but I don't see a big reason ...

thanks,
/prasanta

hahnt@us.ibm.com wrote:

>
> Jim,
>
> Good question!
>
> I know that implementing access control such that attribute
> inheritance were taken into account would definitely be harder, but I
> feel that attribute inheritance SHOULD be considered during access
> control checks.
>
> Thus, if some entity is granted read and write privileges to 'name',
> then they should be allowed the same privileges to 'cn', 'sn', and
> 'cn;lang-en'.  (unless overidden by another permission that disallows
> such access).
>
> 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
>
> To:        
> cc:        "Duane Buss" 
> Subject:        Considering Attribute Subtypes during ACL evaluation
>
>
>
>
> Are attribute subtypes considered when calculating access  control
> information? In other words, if I have read permission to the "name"
> attribute, does that automatically give me read permission to sn, cn,
> givenName,  etc?
>
> I can't find any coverage of this in X.511 or the latest ACL  draft.
> Due to the lack of anyone talking about it, my assumption is that,
> no,  permissions do not flow down attribute inheritance chains, they
> must be  explicitly stated for each attribute.
>
> Of course with LDAP, this brings up the question of whether  they
> apply to attribute type options. It seems to make sense, under most
> circumstances, to apply them in this case. Oh, what a world - what a
> world.
>

--------------3646A3A18AC93DAE7B40C5B4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Currently  the netscape/iPlanet DS ACL supports a attribute inheritance
of subtypes e.g. if you allow access to

"cn", it automatically means { cn, cn;* }

However, it is much harder to map "name" to "cn, sn".

Why can't this be a UI thing? Why does it have to be

declarative in the ACL syntax itself. It will be nice if it

can be supported but I don't see a big reason ...

thanks,

/prasanta

hahnt@us.ibm.com wrote:

 

Jim,

Good question!

I know that implementing access
control such that attribute inheritance were taken into account would definitely
be harder, but I feel that attribute inheritance SHOULD be considered during
access control checks.

Thus, if some entity is granted
read and write privileges to 'name', then they should be allowed the same
privileges to 'cn', 'sn', and 'cn;lang-en'.  (unless overidden by
another permission that disallows such access).

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

To:       
<ietf-ldapext@netscape.com>

cc:       
"Duane Buss" <DBuss@novell.com>

Subject:       
Considering Attribute Subtypes during ACL evaluation

 

 

 

Are attribute subtypes considered
when calculating access  control information? In other words, if I
have read permission to the "name"  attribute, does that automatically
give me read permission to sn, cn, givenName,  etc?

I can't find any coverage of this
in X.511 or the latest ACL  draft. Due to the lack of anyone talking
about it, my assumption is that, no,  permissions do not flow down
attribute inheritance chains, they must be  explicitly stated for
each attribute.

Of course with LDAP, this brings
up the question of whether  they apply to attribute type options.
It seems to make sense, under most  circumstances, to apply them in
this case. Oh, what a world - what a  world.

 



--------------3646A3A18AC93DAE7B40C5B4--



From list@netscape.com  Sat Sep 30 17:09:20 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 SMTP id RAA00836
	for ; Sat, 30 Sep 2000 17:09: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 e8UL0wM11043;
	Sat, 30 Sep 2000 14:00:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8UL7XI15764;
	Sat, 30 Sep 2000 14:07:33 -0700 (PDT)
Resent-Date: Sat, 30 Sep 2000 14:07:33 -0700 (PDT)
Message-Id: <5.0.0.25.0.20000930114328.00a66910@router.boolean.net>
X-Sender: guru@router.boolean.net
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sat, 30 Sep 2000 11:59:03 -0700
To: prasanta@netscape.com (Prasanta Behera)
From: "Kurt D. Zeilenga" 
Subject: Re: Considering Attribute Subtypes during ACL evaluation
Cc: hahnt@us.ibm.com, ietf-ldapext@netscape.com
In-Reply-To: <39D5FB0D.EC5E4F0B@netscape.com>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"LmJ92C.A.51D.UYl15"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 07:39 AM 9/30/00 -0700, Prasanta Behera wrote:
>Currently  the netscape/iPlanet DS ACL supports a attribute inheritance of subtypes e.g. if you allow access to 
>"cn", it automatically means { cn, cn;* } 
>
>However, it is much harder to map "name" to "cn, sn". 

Depends upon your server implementation...  I argue that
mapping "name" to "cn" is no harder than mapping "2.5.4.3"
to "cn".  Both require schema aware ACL evaluation and
once you have that, supporting subtyping is likely no big
deal. Implementing schema aware ACL evaluation may be hard,
but it's already required to handle alternative naming
of attribute types.

However, given that subtyping is optional in LDAPv3, one
could argue it's best to leave subtyping within ACLs as
being optional.

Kurt



From list@netscape.com  Sat Sep 30 18:40: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 SMTP id SAA01680
	for ; Sat, 30 Sep 2000 18:40: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 e8UMSEC01633;
	Sat, 30 Sep 2000 15:28:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id e8UMdAM07534;
	Sat, 30 Sep 2000 15:39:10 -0700 (PDT)
Resent-Date: Sat, 30 Sep 2000 15:39:10 -0700 (PDT)
From: 
Subject: EMERGING COMPANIES
Date: Sat, 30 Sep 2000 14:03:03
Message-Id: <815.274638.828621@Server02>
Resent-Message-ID: <"yPVL0B.A.c1B.Num15"@glacier>
To: ietf-ldapext@netscape.com
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


A CD will pay you how much? Less than 10% per year on your money? 
A real estate investment might double or even triple -- in how 
many years??? We found a little company whose stock was trading 
for pennies -- but they had a patent lurking in the background. 
We told our readers about it. In less than a year, this little 
company had been written up in several major publications and 
their investors had made over 600% on their money. Stocks on the 
over-the-counter bulletin board (OTC BB) are exploding. Deep in 
the heart of the OTC BB lies the next company ready to come out 
of nowhere, WOW the world and reward investors with HUGE gains! A 
company which has been reporting on Wall Street since 1992 is now 
covering this OTC BB market. Get your FREE SUBSCRIPTION today and 
explore the possibilities! 

FREE SUBSCRIPTION: Hit "Reply" and type "Subscribe" in the 
subject line. 

TO BE REMOVED: Hit "Reply" and type "Remove" in the subject line.


This message is sent in compliance with the new email bill 
section 301. Under Bill S.1618 TITLE III passed by the 105th US 
Congress, this message cannot be considered SPAM as long as we 
include the way to be removed, Paragraph (a)(c) of S.1618, 
further transmissions to you by the sender of this email may be 
stopped at no cost to you by sending a "Reply" email with 
"remove" typed into the subject line. We really will remove you 
immediately.