From list@netscape.com Sun Oct 1 05:35: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 FAA07421 for ; Sun, 1 Oct 2000 05:35: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 e919N8C18307; Sun, 1 Oct 2000 02:23:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e919Y5U15317; Sun, 1 Oct 2000 02:34:05 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 02:34:05 -0700 (PDT) Date: Sun, 1 Oct 2000 02:34:01 -0700 (PDT) Message-Id: <200010010934.e919Xaf28102@xwing.netscape.com> From: xxtha@ser.nl Reply-To: ser.nl@xwing.netscape.com To: urhzr@aol.com Subject: GUARANTEED INCOME wtxal Resent-Message-ID: <"SROs8.A.DvD.MUw15"@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 program even offers you a Monthly Guaranteed Minimum Income!! GUARANTEED INCOME !!! Don't miss out on this Great Opportunity to secure yourself a Guaranteed Monthly Minimum Income !!! It's FREE to join our Post Launch Program !!! Your FREE membership # will also be entered into a lucky draw toWIN $100 to shop online !! ALL new members who join after you will be placed in ONE Straight Line down UNDER you. YOU can easily get 500-1,000 members under YOU in a month !! There is absolutely NO RISK to get involved and NO COST to join our Post Launch Program. To sign up simply reply to: mailto:greatopp@myezmail.com?subject=SignMeUp Your First and Last Name Your Email Address You have nothing to lose and potentially a lot to gain. Join Today !!! We will confirm your position and send you a special report as soon as possible. ==================================================== Removal mailto:nothankyou45@mrearl.com?subject=Remove From list@netscape.com Sun Oct 1 05:49:08 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07472 for ; Sun, 1 Oct 2000 05:49: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 e919f8M16292; Sun, 1 Oct 2000 02:41:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e919liw18408; Sun, 1 Oct 2000 02:47:44 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 02:47:44 -0700 (PDT) Subject: Valuable Real Estate Informational Guide -cqyfvlu Reply-To: real-estate-center14@excite.com Message-Id: Date: Sun, 01 Oct 2000 02:48:39 -0700 To: youmail@cwcgsai.mailnow.co.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT From: real-estate-center21@vqmm.excite.com Resent-Message-ID: <"DhAi8.A.LfE.-gw15"@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 Ext. 321 The book's retail value is $87.97. Order Today and receive for only $49.00 Shipping.is included! --------------------------------------------------------- unsubscribers: Reply to this message with "unsubscribe" in subject line. --------------------------------------------------------- From list@netscape.com Sun Oct 1 06:25: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 GAA07726 for ; Sun, 1 Oct 2000 06:25: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 e91ADMC21320; Sun, 1 Oct 2000 03:13:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e91AOJU26449; Sun, 1 Oct 2000 03:24:19 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 03:24:19 -0700 (PDT) Message-Id: <200010011024.e91AOGf05736@xwing.netscape.com> From: Subject: Guaranteed Downline, Guaranteed Income Date: Sun, 1 Oct 2000 02:56:30 Resent-Message-ID: <"iZB3xD.A._cG.SDx15"@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 Greetings, Have Your Downline Built BEFORE You Spend Any Money ! This program even offers you a Monthly Guaranteed Minimum Income !! GUARANTEED DOWNLINE, GUARANTEED INCOME !!! Don't miss out this Great Opportunity to secure yourself a Guaranteed Monthly Minimum Income !!! It's FREE to join Post Launch Program !!! Your FREE membership# will also be entered into a lucky draw to WIN $100 to shop online !! ALL new members join after you will be placed in ONE Straight Line down UNDER you. YOU can easily get 1000-5,000 members under YOU in a month !! There is absolutely NO RISK to get involved and NO COST to join Post Launch Program. To sign up simply reply to this email with the following :- Email Subject : Sign Me Up Email Body : Your First and Last Name : Your Email Address If the above information is incomplete we will not be able to register you for this program. You have nothing to lose and potentially a lot to gain, Join Today !!! We will confirm your position and send you a special report as soon as possible. This is a onetime mailing! 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 Sun Oct 1 06:38:11 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07813 for ; Sun, 1 Oct 2000 06:38: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 e91APdC22716; Sun, 1 Oct 2000 03:25:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e91AaaM29201; Sun, 1 Oct 2000 03:36:36 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 03:36:36 -0700 (PDT) Date: Sun, 01 Oct 2000 12:29:05 +0200 Message-ID: To: opt_in731@businessweekmail.com From: Subject: How you can make $100 - $500 an hour doing something FUN Resent-Message-ID: <"9tAJI.A.4HH.zOx15"@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 "Money Making Opportunities" Newsletter Saturday, 7 p.m. Hello, If you're interested in earning $100 - $500 an hour doing something FUN, Then I want to share something with you... 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 - $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 - $500 An Hour, Simply Click On The Email Link Below and Send Back The Following: Mailto:stargazing32@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:stargazing32@newmail.net And you'll be sent the full details on how to make $100 - $500 an hour, 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:unsubcribe-930@newmail.net From list@netscape.com Sun Oct 1 07:10: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 HAA08018 for ; Sun, 1 Oct 2000 07:10: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 e91B1vM26790; Sun, 1 Oct 2000 04:01:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e91B8Xs04936; Sun, 1 Oct 2000 04:08:33 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 04:08:33 -0700 (PDT) Subject: Are you worth WAY more than you are paid? Message-ID: Content-Type: text/plain From: Date: Sun, 01 Oct 2000 04:08:21 To: X-Accept-Language: en Resent-Message-ID: <"gAAbr.A.SMB.vsx15"@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's get right to the point. I am looking for positive motivated people that want and need to make a minimum of 10k per month. Do you have a burning desire to change the quality of your existing life? Would you like to live the life that others only dream about? If you think this is to good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from our efforts. The fact is we have many people in our enterprise that earn over 50k per month from the privacy of their own home and are retiring in 2-3 years obviously wealthy and having total freedom both personal and financial. How would you like to: 1. Drastically reduce personal, business and capital gains taxes? 2. Protect all assets from any form of seizure, liens, or judgments? 3. Create a six figure income every 4 months? How about: 1. Restoring and preserving complete personal and financial privacy? 2. Create and amass personal wealth, multiply it and protect it? 3. Realize a 3 to 6 times greater returns on your money? 4. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? Are you a BIG thinker, BIG dreamer and a person that believes they deserve to have the best in life? Are you capable of recognizing that once in a lifetime opportunity when it's looking right at you? Countless others have missed their shot at the title only to look back years later and wished they should've because they could've. If you are serious about changing your life... Call toll free: 1-888-253-8212 HI INTEGRITY! - NOT MLM! Best Regards Philip $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ --------------------------------------- This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301). "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to be removed. INSTRUCTIONS- REPLY with the word "REMOVE" in the subject line. From list@netscape.com Sun Oct 1 20:24: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 UAA13730 for ; Sun, 1 Oct 2000 20:24: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 e920GoM21974; Sun, 1 Oct 2000 17:16:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e920NQQ23452; Sun, 1 Oct 2000 17:23:26 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 17:23:26 -0700 (PDT) Reply-To: From: "Steven Legg" To: , Cc: Subject: RE: Feature discovery (Was: RFC 2596 questions) Date: Mon, 2 Oct 2000 11:21:40 +1100 Message-ID: <000f01c02c06$bd37cab0$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 In-Reply-To: <39CC9E0A.11579.5AAFC3@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Resent-Message-ID: <"HC2AzB.A.KuF.9V915"@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: Saturday, 23 September 2000 22:12 > To: Steven Legg; steven.legg@adacel.com.au; ietf-ldapext@netscape.com > Cc: osidirectory@az05.bull.com > Subject: RE: Feature discovery (Was: RFC 2596 questions) > > > 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) I wasn't really aiming at dynamic attribute subtyping (though it's doable) but rather at being able to choose an OID for an attribute with option that is the same as what everyone else chooses. > 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. Would these globally unique strings be things like, employeeNumber.attributeType.adacel.com.au and/or, joint-iso-ccitt.ds.attributeType.commonName and/or ( :-) ), 2.5.4.3 ? There are two situations we need to deal with; two different objects having the same identifier, and an object having multiple identifiers. The globally unique strings would fix the former but the latter also has its problems. If server S1 chains a search request on joint-iso-ccitt.ds.attributeType.commonName to server S2 but S2 only knows the attribute by the name 2.5.4.3 then it will respond with an empty result. Either the alternative names must be known (or discoverable - yuk!) everywhere, or a single specific name of the object must always be used in protocol. At the moment we have strings in LDAP and OIDs in DSP, etc. Insisting on dotted decimal OID notation in LDAP is one solution. However, if globally unique strings are going to be used to identify attribute types without there necessarily being a corresponding defined OID then I would suggest extending the attribute type (in X.500) to be a choice between an OID or a unique string. Either or both identifiers could be part of the attribute definition, but this would be set in concrete at the time of definition. > > 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. No argument there! > > 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. That helps by reducing the N x M problem to an M problem. We'd still need to have an OID for each attribute option, which they currently don't have. The attribute type could be changed to include a sequence of character string attribute options to allow a direct mapping from LDAP to DSP, but we'd have the usual problems of ambiguous identifier strings. Globally unique string names would solve that, though they could be a bit cumbersome. Regards, Steven > > 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 Sun Oct 1 20:37:04 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 UAA13838 for ; Sun, 1 Oct 2000 20:37: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 e920OiC11532; Sun, 1 Oct 2000 17:24:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e920Zfo26018; Sun, 1 Oct 2000 17:35:41 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 17:35:41 -0700 (PDT) Message-ID: <39D7D63D.9359129F@worldspot.com> Date: Sun, 01 Oct 2000 17:26:37 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) 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: <"vMcpFB.A.QWG.ah915"@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 think a few things overlap with the discussion earlier in September on this list, but I've provided responses to all on an item-by-item basis. Thanks for your detailed review! 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. I discussed the motivation for the behavior defined in the draft earlier in September. > 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? Yes > Section 4.5.1: > -------------- > Are alternative attribute type names, attribute subtypes, and > attribute descriptions accounted for in this comparison > implemenatation? Sorting is alphabetical, using the supplied attribute names. No attempt is made to canonicalize alternative names to "primary" names. Attribute subtypes are correctly sorted as a side-effect of their syntax (which lends itself well to alphabetical sorting). Attribute descriptions are not referenced or accounted for. > 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? Less than > Section 4.6.4: > -------------- > If the authentication method does not have an associated distinguished > name, does this method return null? An exception? It returns null if there is no DN associated with the binding (or lack of binding) of the connection. > 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? As currently defined, binds are always anonymous (since LDAP URLs do not allow specifying a password, and since the draft does not state if/how the constraints object is used to provide credentials for binding). That is of limited practical use, and I think it is a good suggestion to specify in the draft that the LDAPRebind or LDAPBind object is used to obtain credentials for the bind. If neither object is present, the search operation takes place with an anonymous connection. > 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. In practice, LDAPRebind is a simple interface for simple binds. For anything more complex, including SASL, LDAPBind should be used. > Section 4.7.8: > -------------- > A clarification: If the bind proc is null (the default), then no > authentication is done on the initial connection. Yes, except it doesn't apply to the initial connection anyway, but to the new connection which is produced to follow a referral. > 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. The normalization that is done is: escape processing white space between the RDN separator (",") and the following RDN case-insensitivity for RDNs with case-insensitive syntax Yes, determining which RDNs have case-insensitive syntax does require access to a subset of the schema of a particular server. However, LDAPDN.equals is a static method which does not take an LDAP connection or a schema as argument. In the Mozilla implementation, there is a built-in table of standard attributes which do not have case-insensitive syntax (most standard attributes do have case-insensitive syntax), culled from the inetOrgPerson and other documents; then there is a static method to specify additional attributes as "not case-insensitive". > 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? Yes > 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? Passing an LDAPDN instead of a String was considered at the time of the first draft (late Spring 1997), but rejected on the basis of one of the design goals: use standard Java classes and types wherever possible, facilitate adoption by not requiring class- and type-mapping. It is assumed that most applications do not know about nor want to know about LDAP DNs. > 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; > ... > } The values are not defined in the draft, so as to avoid redundancy. They are defined in RFC 2252. > Section 4.21: > ------------- > Since this set of modifications is ordered, should it be called > LDAPModificationList instead? It could be, but it's not worth changing at this point. > Section 4.21.2: > --------------- > A clarification. Since the list is ordered, add() should clarify that > it adds at the END of the list. OK > 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? Same answer as for 4.3.8 :-) > 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? That is correct. LDAPBind must be used for SASL or potentially other authentication methods. > Section 4.26.1: > --------------- > Clarification: the full response is received prior to throwing the > referral exception, correct? I'm not sure why you're referring to 4.26.1 with the question; is the question answered in 4.35.4? > Section 4.29.11: > ---------------- > "of attribute definitions" should be "of LDAPAttributeSchema > definitions". or "of LDAPAttributeSchema objects" > Section 4.29.12: > ---------------- > "of attribute definitions" should be "of LDAPObjectClassSchema > definitions". or "of LDAPObjectClassSchema objects" > Section 4.29.13: > ---------------- > "of attribute definitions" should be "of LDAPMatchingRuleSchema > definitions". or "of LDAPMatchingRuleSchema objects" > Section 4.29.20-25: > ------------------- > clarification: the returned Enumeration is an Enumeration of Strings, > correct? Yes > 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). It would mean that they would need to be declared in each of the seven other classes which extend the base class, or that another intermediate base class would need to be inserted - both unattractive options. I think it is OK that the methods return null where the derived element does not have the corresponding property. > Section 4.30.6: > --------------- > clarification: the returned Enumeration is an Enumeration of Strings, > correct? Yes > 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. OK > Section 4.30.12: > ---------------- > Also in this section, the value from "this.getValue()" is used as the > "attribute value to delete", correct? Yes > Section 4.31.1: > --------------- > Why is doReferrals set to "false" by default? Safety. > non-SIMPLE re-bind authentication seems to need more thought, in > general. Is anybody working on this? Yes: http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt and also: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_028_sasl.html LDAPBind and SASL or startTLS is the way to go. > Is hop_limit set to zero by default? Does zero imply no limit? The default value and the semantics of zero should be defined in the draft. Zero should imply no limit, but the default should be a reasonable value (to allow reasonable nesting levels of reference while preventing infinite loops); I propose 5. > 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 OK > 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? The latter: requests that are yet to be processed by the application (regardless of whether they have completely arrived from the server at the time or not). > Section 4.32.3: > --------------- > Would it be useful to have a "isReponseReceived( int msgid )" method > as well? That might be useful. > How about an "isComplete( int msgid )"? I'm not sure that makes sense: if all results have been retrieved for a particular message ID, there is no longer a queue maintained for it. getMessageIDs() will not return the ID. It would be difficult for the application to distinguish between the request being complete (all results retrieved for that ID) on the one hand, and an invalid ID on the other. > Section 4.35.5: > --------------- > "This the" should be "This is the" OK > "or an LDAPReferralException." should be "or an LDAPReferralException > is thrown." No. nextElement() doesn't throw exceptions. the LDAPReferralException is returned as an object. > 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. The text about referrals being returned after all other results stems back to the original draft, I think. Back then there were no LDAPv3 servers, and the only referrals being returned by LDAP servers were of the UMich type: as result code 14 in the response of a message. They, of course, came after all search results. When support for LDAPv3 referrals became available in servers, it was also supported in revisions of the draft. However the text implies that also references returned by a server as search results will be saved up and returned after all other search results (i.e. so they would be delivered to the application in the same way as UMich referrals). I think it's time to drop that text. Results are returned to the application in the order they are received from the server, period. Consider the case where a search returned a reference followed by 10,000 regular search results. Should an implementation of the API buffer up all 10,000 before returning the reference to the application? That seems inefficient. > Section 4.38.1: > --------------- > attrNames description, "null for all attributes". Should this be > "null or a single value of "*" for all attributes". Yes. The latter is redundant to specify in this draft, since it is an LDAP spec. Allowing "null" is an extension provided by the API. > 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." OK > Section 4.40.1: > --------------- > Will the client send off abandon requests for all outstanding (but > incomplete) operations if a bind() is invoked? No. That doesn't seem justified, IMHO. > > 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 Sun Oct 1 23:07: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 XAA17120 for ; Sun, 1 Oct 2000 23:07: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 e922xmM12153; Sun, 1 Oct 2000 19:59:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9236PI00329; Sun, 1 Oct 2000 20:06:25 -0700 (PDT) Resent-Date: Sun, 1 Oct 2000 20:06:25 -0700 (PDT) Message-Id: <5.0.0.25.0.20001001192819.00a8feb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 01 Oct 2000 20:03:25 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt Cc: hahnt@us.ibm.com, ietf-ldapext@netscape.com In-Reply-To: <39D7D63D.9359129F@worldspot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"caIc3B.A.1E.wu_15"@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:26 PM 10/1/00 -0700, Rob Weltman 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, 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. > > I discussed the motivation for the behavior defined in the draft >earlier in September. Please note language tags have no structure and should not be parsed. "cn;lang-ja-JP-kanji" is not a subtype of "cn;lang-ja" Note that since LDAP language tags are an extension to LDAP "core" protocol, I suggest that LDAP Java API language tag likewise be an extension and detailed in a separate TS. >> 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? > > Yes This behavior is inconsistent with LDAP/X.500 subtyping. attrSet is modifying the attrSet and hence should be consistent with the protocol modify... which would only delete "name" and not its subtypes. >> 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. > > In practice, LDAPRebind is a simple interface for simple binds. For >anything more complex, including SASL, LDAPBind should be used. s/more complex/secure/ >> 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. > > The normalization that is done is: > >escape processing >white space between the RDN separator (",") and the following RDN >case-insensitivity for RDNs with case-insensitive syntax > > Yes, determining which RDNs have case-insensitive syntax does require >access to a subset of the schema of a particular server. Actually, the parent of the entry named by the entry could be controlled by a different subschema, held by a different server... >> 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; >> ... >> } > > The values are not defined in the draft, so as to avoid redundancy. >They are defined in RFC 2252. I assume you mean RFC 2251 and the ASN.1 defined resultCode names and their corresponding values. However, the API uses different names than the ASN.1... hence there is a need for a explicit API name <-> ASN.1 name mapping table. (I'd prefer the API just use the ASN.1 names...) >> Section 4.31.1: >> --------------- >> Why is doReferrals set to "false" by default? > > Safety. Clarification: security considerations >> non-SIMPLE re-bind authentication seems to need more thought, in >> general. Is anybody working on this? > > Yes: > >http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt Is this going to progressed on the Standard Track as well? >> 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 > > OK I'd prefer using the ASN.1 names where ever possible, e.g: LDAPConnection.neverDerefAliases LDAPConnection.derefInSearching LDAPConnection.derefFindingBaseObj LDAPConnection.derefAlways >> Section 4.40.1: >> --------------- >> Will the client send off abandon requests for all outstanding (but >> incomplete) operations if a bind() is invoked? > > No. That doesn't seem justified, IMHO. I concur. Given that a bind request causes all outstanding requests to be abandoned automatically, sending off abandon requests for all outstanding operations would be pointless. Kurt From list@netscape.com Mon Oct 2 06:11: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 GAA04459 for ; Mon, 2 Oct 2000 06:11:00 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e929waC10138; Mon, 2 Oct 2000 02:58:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92A9Yw24660; Mon, 2 Oct 2000 03:09:34 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 03:09:34 -0700 (PDT) From: hahnt@us.ibm.com Importance: Normal Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 2 Oct 2000 05:50:01 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 10/02/2000 06:09:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"Lg14bB.A.CBG.c7F25"@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 Rob, Thanks for the responses. I have a couple more comments on these below - look for TJH> Thanks again, 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 Rob Weltman on 10/01/2000 08:26:37 PM To: Timothy Hahn/Endicott/IBM@IBMUS cc: ietf-ldapext@netscape.com Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt I think a few things overlap with the discussion earlier in September on this list, but I've provided responses to all on an item-by-item basis. Thanks for your detailed review! Rob hahnt@us.ibm.com wrote: > > Section 4.26.1: > --------------- > Clarification: the full response is received prior to throwing the > referral exception, correct? I'm not sure why you're referring to 4.26.1 with the question; is the question answered in 4.35.4? TJH> Seeing that LDAPReferralException is returned (not thrown), this now makes sense. > Section 4.31.1: > --------------- > Why is doReferrals set to "false" by default? Safety. > non-SIMPLE re-bind authentication seems to need more thought, in > general. Is anybody working on this? Yes: http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt and also: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_028_sasl.html LDAPBind and SASL or startTLS is the way to go. > Is hop_limit set to zero by default? Does zero imply no limit? The default value and the semantics of zero should be defined in the draft. Zero should imply no limit, but the default should be a reasonable value (to allow reasonable nesting levels of reference while preventing infinite loops); I propose 5. TJH> 5 sounds fine to me. > Section 4.32.3: > --------------- > Would it be useful to have a "isReponseReceived( int msgid )" method > as well? That might be useful. > How about an "isComplete( int msgid )"? I'm not sure that makes sense: if all results have been retrieved for a particular message ID, there is no longer a queue maintained for it. getMessageIDs() will not return the ID. It would be difficult for the application to distinguish between the request being complete (all results retrieved for that ID) on the one hand, and an invalid ID on the other. TJH> I agree that if there is no longer anything maintained for the message ID TJH> that it would be hard to distinguish. But if an application wanted to TJH> hold of on processing the response until the complete message was TJH> received it could test such an "isComplete()" result. > Section 4.40.1: > --------------- > Will the client send off abandon requests for all outstanding (but > incomplete) operations if a bind() is invoked? No. That doesn't seem justified, IMHO. TJH> agreed. > > 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 Mon Oct 2 06:12: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 GAA04480 for ; Mon, 2 Oct 2000 06:12: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 e92A3BM05364; Mon, 2 Oct 2000 03:03:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92A9mQ24956; Mon, 2 Oct 2000 03:09:48 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 03:09:48 -0700 (PDT) From: hahnt@us.ibm.com Importance: Normal Subject: Re: Considering Attribute Subtypes during ACL evaluation To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 2 Oct 2000 05:52:26 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 10/02/2000 06:09:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"6sqMVB.A.sEG.q7F25"@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 Kurt, I agree that the optional/mandatory specification for ACLs to be sensitive to subtyping should follow what an implementation does with attribute subtyping support, i.e. if attribute subtypes are supported, then the ACL implementation should be sensitive to them as well. 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 "Kurt D. Zeilenga" on 09/30/2000 02:59:03 PM To: prasanta@netscape.com (Prasanta Behera) cc: Timothy Hahn/Endicott/IBM@IBMUS, ietf-ldapext@netscape.com Subject: Re: Considering Attribute Subtypes during ACL evaluation 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 Mon Oct 2 08:27: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 IAA06774 for ; Mon, 2 Oct 2000 08:27: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 e92CJlM22366; Mon, 2 Oct 2000 05:19:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92CQPU24126; Mon, 2 Oct 2000 05:26:25 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 05:26:25 -0700 (PDT) Message-Id: <200010021207.IAA13151@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'Kurt D. Zeilenga'" , Jim Sermersheim Cc: ietf-ldapext@netscape.com, Duane Buss Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Mon, 2 Oct 2000 08:25:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02C6B.D5FD9524" Resent-Message-ID: <"_V5IxD.A.j4F.w7H25"@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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02C6B.D5FD9524 Content-Type: text/plain; charset="iso-8859-1" I have an attribute type "userCertificate" and have many values (PKI A certificate; PKI B certificate, etc.) My requirement is to constrain the management of that attribute value to the CA or appropriate named authority for that attribute value. I would not want to allow CA for PKI A to have all privileges wrt userCertificate for PKI B. as I read your proposal, I don't interpret this as supporting my requirement. is this correct? Sandi -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, September 29, 2000 5:53 PM To: Jim Sermersheim Cc: ietf-ldapext@netscape.com; 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 **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** ------_=_NextPart_001_01C02C6B.D5FD9524 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Considering Attribute Subtypes during ACL evaluation

I have an attribute type "userCertificate" = and have many values (PKI A certificate; PKI B certificate, etc.) =

My requirement is to constrain the management of that = attribute value to the CA or appropriate named authority for that = attribute value.

I would not want to allow CA for PKI A to have all = privileges wrt userCertificate for PKI B.

as I read your proposal, I don't interpret this as = supporting my requirement.

is this correct?

Sandi

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, September 29, 2000 5:53 PM
To: Jim Sermersheim
Cc: ietf-ldapext@netscape.com; 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




***************************************************************= **************
This confirms that this email message has been swept = by
MIMEsweeper for the presence of computer = viruses.
***************************************************************= ***************

------_=_NextPart_001_01C02C6B.D5FD9524-- From list@netscape.com Mon Oct 2 08:48: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 IAA07141 for ; Mon, 2 Oct 2000 08:48: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 e92CaKC27665; Mon, 2 Oct 2000 05:36:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92ClIw29211; Mon, 2 Oct 2000 05:47:18 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 05:47:18 -0700 (PDT) To: ietf-ldapext@netscape.com Subject: comments on draft-ietf-ldapext-ldap-taxonomy-03.txt From: Simon Josefsson Date: 02 Oct 2000 14:48:08 +0200 Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"aqtLYB.A.HIH.VPI25"@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 found this draft to be very useful, thanks. However, I'd like to know if it would be a good thing if each section described if/how the method allow for finding out the base object of the server too. It is mentioned in "client configuration" but not in any other section. For "Well known DNS alias" see section 6 of rfc2219. Perhaps this isn't an issue because of some reason? Thanks. From list@netscape.com Mon Oct 2 12:00: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 MAA10062 for ; Mon, 2 Oct 2000 12:00: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 e92FmYC20862; Mon, 2 Oct 2000 08:48:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92FxYw00300; Mon, 2 Oct 2000 08:59:34 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 08:59:34 -0700 (PDT) Sender: Mark.Wahl@Central.Sun.COM Message-ID: <39D8B0FF.E7BD4FAC@sun.com> Date: Mon, 02 Oct 2000 10:59:59 -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: Prasanta Behera CC: hahnt@us.ibm.com, ietf-ldapext@netscape.com Subject: Re: Considering Attribute Subtypes during ACL evaluation References: <39D5FB0D.EC5E4F0B@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hf61y.A.aE.kDL25"@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 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". > 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 ... The schema and access control may be managed by different individuals. One can envisage a user being permitted to define a subtype of an attribute but not having the ability to modify access control rights. As there are no rights to the new attribute, it might disappear. Mark Wahl Sun Microsystems, Inc. From list@netscape.com Mon Oct 2 13:15: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 NAA11172 for ; Mon, 2 Oct 2000 13:15: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 e92H1IC09499; Mon, 2 Oct 2000 10:01:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92HCIU14576; Mon, 2 Oct 2000 10:12:18 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 10:12:18 -0700 (PDT) Message-Id: <9F83DF9B4DD5D111999B00A0C96B12B60402A1DD@stca103a.bus.sc.rolm.com> From: "Skovgaard, Erik" To: "'hahnt@us.ibm.com'" , ietf-ldapext@netscape.com Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Mon, 2 Oct 2000 10:09:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C02C93.9794F430" Resent-Message-ID: <"1timVD.A.ejD.xHM25"@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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C02C93.9794F430 Content-Type: text/plain; charset="iso-8859-1" Tim, I am not so sure this is a good idea. I may want to allow anonymous readers access to sn, but not to gn, for instance. While those of us "in the know" may be able to set up a specific deny on gn, it may be less intuitive to people with less knowledge of the standards. Cheers, ....Erik. Erik Skovgaard Siemens Meta-Directory Solutions Phone: +1 604-204-0750 Fax: +1 604-204-0760 -----Original Message----- From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com] Sent: Saturday, September 30, 2000 04:13 To: ietf-ldapext@netscape.com Subject: Re: Considering Attribute Subtypes during ACL evaluation 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. ------_=_NextPart_000_01C02C93.9794F430 Content-Type: application/octet-stream; name="Skovgaard, Erik.vcf" Content-Disposition: attachment; filename="Skovgaard, Erik.vcf" BEGIN:VCARD VERSION:2.1 N:Skovgaard;Erik FN:Skovgaard, Erik ORG:Siemens Information and Communications Networks, Inc.;90726B NOTE;ENCODING=QUOTED-PRINTABLE:Employee works out of his home office in Richmond, British Columbia=0D=0A TEL;WORK;VOICE:+1 604-204-0750 TEL;HOME;VOICE:Erik.Skovgaard@icn.siemens.com TEL;HOME:Directory Team-Engineering EMAIL;PREF;INTERNET:Erik.Skovgaard@icn.siemens.com REV:20000518T232217Z END:VCARD ------_=_NextPart_000_01C02C93.9794F430-- From list@netscape.com Mon Oct 2 17:28: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 RAA14486 for ; Mon, 2 Oct 2000 17:28: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 e92LGJr02873; Mon, 2 Oct 2000 14:16:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92LRIU04057; Mon, 2 Oct 2000 14:27:18 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 14:27:18 -0700 (PDT) Message-ID: <39D8FD41.2AC9695F@novell.com> Date: Mon, 02 Oct 2000 15:25:21 -0600 From: Steven Sonntag Organization: Novell, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: hahnt@us.ibm.com CC: ietf-ldapext@netscape.com, robw@worldspot.com, smerrill@novell.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: <"k7xDyC.A.F_.12P25"@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 hahnt@us.ibm.com wrote: > Rob, > > Thanks for the responses. > > I have a couple more comments on these below - look for TJH> > > Thanks again, > Tim Hahn ---Snip--- > > Section 4.32.3: > > --------------- > > Would it be useful to have a "isReponseReceived( int msgid )" method > > as well? > > That might be useful. > In the same light an "LDAPMessage getResponse(int msgid)" would be very useful (4.32.2) -Steve From list@netscape.com Mon Oct 2 18:57:08 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15378 for ; Mon, 2 Oct 2000 18:57: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 e92MmnL22838; Mon, 2 Oct 2000 15:48:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92MtQk17452; Mon, 2 Oct 2000 15:55:26 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 15:55:26 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 02 Oct 2000 16:40:19 -0600 From: "Jim Sermersheim" To: , Cc: , Subject: Re: Considering Attribute Subtypes during ACL evaluation Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4C14A1CA.33523335" Resent-Message-ID: <"ulI17C.A.uPE.bJR25"@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. --=_4C14A1CA.33523335 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree for the exact same reason optional support of attr subtyping). It = would also be interesting to hear from the X.500 community on how this is = handled by different vendors. I found the whole thing unspecified. Jim >>> "Kurt D. Zeilenga" 9/30/00 12:59:03 PM >>> 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=20 >"cn", it automatically means { cn, cn;* }=20 > >However, it is much harder to map "name" to "cn, sn".=20 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 --=_4C14A1CA.33523335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree for the exact same reason optional support of = attr=20 subtyping). It would also be interesting to hear from the X.500 community = on how=20 this is handled by different vendors. I found the whole thing=20 unspecified.
 
Jim


>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 9/30/00=20 12:59:03 PM >>>
At 07:39 AM 9/30/00 -0700, Prasanta Behera=20 wrote:
>Currently  the netscape/iPlanet DS ACL supports a = attribute=20 inheritance of subtypes e.g. if you allow access to
>"cn", it=20 automatically means { cn, cn;* }
>
>However, it is much = harder to=20 map "name" to "cn, sn".

Depends upon your server implementation...&= nbsp;=20 I argue that
mapping "name" to "cn" is no harder than mapping "2.5.4.3"<= BR>to=20 "cn".  Both require schema aware ACL evaluation and
once you have = that,=20 supporting subtyping is likely no big
deal. Implementing schema aware = ACL=20 evaluation may be hard,
but it's already required to handle alternative= =20 naming
of attribute types.

However, given that subtyping is = optional=20 in LDAPv3, one
could argue it's best to leave subtyping within ACLs=20 as
being optional.

Kurt

--=_4C14A1CA.33523335-- From list@netscape.com Mon Oct 2 19:05: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 SMTP id TAA15496 for ; Mon, 2 Oct 2000 19:05: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 e92MrMr25367; Mon, 2 Oct 2000 15:53:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e92N4Lw23154; Mon, 2 Oct 2000 16:04:21 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 16:04:21 -0700 (PDT) Message-Id: <5.0.0.25.0.20001002153302.00a73d80@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 02 Oct 2000 16:03:36 -0700 To: ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: what are the server guys doing? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"QK7G.A.HpF.0RR25"@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'm sitting here watching the discussion on attribute sub-typing, and trying (without any success) to figure when I'd ever need an entry that had numerous subtypes within a single attribute. Can someone give me a good example of when a single LDAP entry would need one attribute with lots of subtypes present? It seems to me that this is going in a different direction that I'd like to see. As an LDAP application developer, I'm more interested in seeing other features added on the server side. I can make do without the sub-type stuff, but I really need to be able to selectively delete a sub-tree. Just out of curiosity, I'd be interested in finding out if anyone that builds a server has any plans on supporting any recently defined extensions (controls or extended operations). For example: LDAP Authentication Response Control (draft) LDAP Proxied Authentication Control (draft) LDAP Controls for Reply Signatures (draft) Returning Matched Values with LDAPv3 (draft) LDAP Control for a Duplicate Entry Representation of Search Results (draft) LDAP Tree Delete Control (draft) LDAP Client Update Protocol (draft) Simple Operations on Subtrees (for LDAP) (draft) An LDAP Control and Schema for Holding Operation Signatures (RFC 2649) I've probably missed a few that have been defined. I'm very interested in encouraging extension development. As far as I can tell, there is very little activity in this area, but I'd like to hear differently. I'm expecting deafening silence in response, but am hopefully of hearing some noise! I'm sure that there would be plenty of interested beta testers... 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 From list@netscape.com Mon Oct 2 20:12: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 UAA15993 for ; Mon, 2 Oct 2000 20:12: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 e92Nxlr11466; Mon, 2 Oct 2000 16:59:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e930Als28495; Mon, 2 Oct 2000 17:10:47 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 17:10:47 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 02 Oct 2000 17:54:19 -0600 From: "Jim Sermersheim" To: , Subject: Re: what are the server guys doing? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_94CC793C.F392F3E7" Resent-Message-ID: <"uZJSp.A.98G.GQS25"@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. --=_94CC793C.F392F3E7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Bruce, The problem is, when one tries to implement language tags (an RFC of the = ldapext WG) on the server, they run into all sorts of unanswered questions = and underspecified, or even conflicting requirements. I don't think the = goal is to specifically implement support for an entry with numerous = subtypes within a single attribute. I think people are just trying to = implement language tags in a correct and consistent manner. Though we'd like to implement many of the drafts listed below, we feel = more urgency to implement language tags now. We don't want to just throw a = solution together and get onto the next extension before we feel assured = of interoperability. Jim >>> Bruce Greenblatt 10/2/00 = 5:04:42 PM >>> I'm sitting here watching the discussion on attribute sub-typing, and=20 trying (without any success) to figure when I'd ever need an entry that = had=20 numerous subtypes within a single attribute. Can someone give me a = good=20 example of when a single LDAP entry would need one attribute with lots = of=20 subtypes present? It seems to me that this is going in a different=20 direction that I'd like to see. As an LDAP application developer, I'm = more=20 interested in seeing other features added on the server side. I can = make=20 do without the sub-type stuff, but I really need to be able to selectively= =20 delete a sub-tree. Just out of curiosity, I'd be interested in finding out if anyone that=20 builds a server has any plans on supporting any recently defined extensions= =20 (controls or extended operations). For example: LDAP Authentication Response Control (draft) LDAP Proxied Authentication Control (draft) LDAP Controls for Reply Signatures (draft) Returning Matched Values with LDAPv3 (draft) LDAP Control for a Duplicate Entry Representation of Search Results = (draft) LDAP Tree Delete Control (draft) LDAP Client Update Protocol (draft) Simple Operations on Subtrees (for LDAP) (draft) An LDAP Control and Schema for Holding Operation Signatures (RFC 2649) I've probably missed a few that have been defined. I'm very interested = in=20 encouraging extension development. As far as I can tell, there is very=20 little activity in this area, but I'd like to hear differently. I'm=20 expecting deafening silence in response, but am hopefully of hearing = some=20 noise! I'm sure that there would be plenty of interested beta testers... Thanks, Bruce =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 Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories:=20 http://www.phptr.com/ptrbooks/ptr_0139744525.html --=_94CC793C.F392F3E7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bruce,
 
The problem is, when one tries to implement language = tags (an=20 RFC of the ldapext WG) on the server, they run into all sorts of unanswered= =20 questions and underspecified, or even conflicting requirements. I don't = think=20 the goal is to specifically implement support for an entry with = numerous=20 subtypes within a single attribute. I think people are just trying to = implement=20 language tags in a correct and consistent manner.
 
Though we'd like to implement many of the drafts = listed below,=20 we feel more urgency to implement language tags now. We don't want to = just=20 throw a solution together and get onto the next extension before we fe= el=20 assured of interoperability.
 
Jim

>>> Bruce Greenblatt=20 <bgreenblatt@directory-applications.com> 10/2/00 5:04:42 PM=20 >>>
I'm sitting here watching the discussion on attribute=20 sub-typing, and
trying (without any success) to figure when I'd ever = need an=20 entry that had
numerous subtypes within a single attribute.  = Can=20 someone give me a good
example of when a single LDAP entry would need = one=20 attribute with lots of
subtypes present?  It seems to me that = this is=20 going in a different
direction that I'd like to see.  As an = LDAP=20 application developer, I'm more
interested in seeing other features = added on=20 the server side.   I can make
do without the sub-type stuff, = but I=20 really need to be able to selectively
delete a sub-tree.

Just = out of=20 curiosity, I'd be interested in finding out if anyone that
builds a = server=20 has any plans on supporting any recently defined extensions
(controls = or=20 extended operations).  For example:

LDAP Authentication = Response=20 Control  (draft)
LDAP Proxied Authentication Control =20 (draft)
LDAP Controls for Reply Signatures (draft)
Returning = Matched=20 Values with LDAPv3  (draft)
LDAP Control for a Duplicate Entry=20 Representation of Search Results (draft)
LDAP Tree Delete Control=20 (draft)
LDAP Client Update Protocol (draft)
Simple Operations on = Subtrees=20 (for LDAP) (draft)
An LDAP Control and Schema for Holding Operation=20 Signatures (RFC 2649)

I've probably missed a few that have been=20 defined.  I'm very interested in
encouraging extension=20 development.  As far as I can tell, there is very
little activity = in=20 this area, but I'd like to hear differently.  I'm
expecting = deafening=20 silence in response, but am hopefully of hearing some
noise!  I'm = sure=20 that there would be plenty of interested beta=20 testers...

Thanks,

Bruce

=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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applica= tions.com
See=20 my new Book on Internet Directories:
http://www.phptr= .com/ptrbooks/ptr_0139744525.html

--=_94CC793C.F392F3E7-- From list@netscape.com Mon Oct 2 20:43: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 UAA16346 for ; Mon, 2 Oct 2000 20:43: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 e930ZeL16972; Mon, 2 Oct 2000 17:35:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e930gHw14951; Mon, 2 Oct 2000 17:42:17 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 17:42:17 -0700 (PDT) From: hahnt@us.ibm.com Importance: Normal Subject: RE: Considering Attribute Subtypes during ACL evaluation To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 2 Oct 2000 20:36:19 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 10/02/2000 08:42:14 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 e930gGr14927 Resent-Message-ID: <"OEAecC.A.VpD.otS25"@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 e930ZeL16972 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA16346 Sandi, As I understand the LDAP ACL draft, access control is not applied to individual values within an attribute within an entry. Access control applies to all values for the attribute within the entry. Thus, I believe you are correct. 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 "Miklos, Sue A." on 10/02/2000 08:25:22 AM To: "'Kurt D. Zeilenga'" , Jim Sermersheim cc: ietf-ldapext@netscape.com, Duane Buss Subject: RE: Considering Attribute Subtypes during ACL evaluation I have an attribute type "userCertificate" and have many values (PKI A certificate; PKI B certificate, etc.) My requirement is to constrain the management of that attribute value to the CA or appropriate named authority for that attribute value. I would not want to allow CA for PKI A to have all privileges wrt userCertificate for PKI B. as I read your proposal, I don't interpret this as supporting my requirement. is this correct? Sandi -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, September 29, 2000 5:53 PM To: Jim Sermersheim Cc: ietf-ldapext@netscape.com; 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 ***************************************************************************** This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ****************************************************************************** From list@netscape.com Mon Oct 2 21:20: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 VAA16701 for ; Mon, 2 Oct 2000 21:20: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 e93181r27317; Mon, 2 Oct 2000 18:08:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e931AtU28689; Mon, 2 Oct 2000 18:10:55 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 18:10:55 -0700 (PDT) Message-Id: <00005b01326d$00005431$000069a4@[153.220.36.34]> To: From: Success101@aol.com Subject: Cyber-Biz Secrets Date: Mon, 02 Oct 2000 20:07:22 -0400 X-Priority: 3 X-Msmail-Priority: Normal Reply-To: netremove@netease.com Resent-Message-ID: <"V0b46D.A.c7G.FIT25"@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 Truth Is Finally Revealed.... How Does The Richest Man In The World Use The Greatest Business Secrets Of All Time To Make Over 32.4 Million Dollars A Day?!! No matter who you are, where you live or what your sex, age or race is by the time you finish reading this special article, you will know: * How to start a proven money making business that requires no inventory, no shipping and no employees within 7 days, guaranteed! * How to get a $300 professionally designed Web Site for FREE! * How to increase your sales by more than 137% in 30 days regardless of your business! * How to get paid for a 1000-hour workweek, without going to work! * How to turn 50 cents into $50, with a simple click of a button! * How to get a $179 business-building CD-ROM for FREE! * If you ever wanted a business where you could hit the ground running.... a business where you could just open a box and start making immediate profits.... a business that's completely set up and ready to pull in maximum sales.... with a product that sells itself... then I've got some great news for you! Act NOW <<<<<< There is A DEADLINE!!! >>>>>> Instant Information Request Directions: **>NOTE: You may also just Click Below to send it through your normal e-mail program. mailto:fastsuccess@yeah.net?subject=send_info_on_infomax102 It's much easier to do it this way, it will fill in the return e-mail and subject for you. 2. You will receive the complete info on the reports via e-mail within 24 hours. P.S. Act NOW!-- Only the first 75 requests will be granted to receive this Special Web Site e-Report for *FREE* titled "The Greatest Business Secrets Of All Time" P.P.S. *FREE Download Bonus e-Manual* "Microsoft, Viagra & Your Business Success" given to the first 35 people to respond within the next 24 hours, Your FREE reports will be fulfilled in the order in which they were received. Privacy Policy: We respect your privacy and your e-mail address/name will be kept strictly private it will never be sold, shared or given away for any reason. Simple Removal Instructions: To Be Removed: mailto:netremove@netease.com?subject=remove102 You will then be deleted from our e-mail database forever. Note: The removal process is totally automatic. Your reply must contain the word "remove" in the subject field! If it doesn't the computer will not be able to process your request. Thank You, and have a nice day! From list@netscape.com Mon Oct 2 23:01: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 XAA19617 for ; Mon, 2 Oct 2000 23:01: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 e932r1L10580; Mon, 2 Oct 2000 19:53:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e932xdM09195; Mon, 2 Oct 2000 19:59:39 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 19:59:39 -0700 (PDT) Message-ID: <39D94BF8.3BE423C1@worldspot.com> Date: Mon, 02 Oct 2000 20:01:12 -0700 From: Rob Weltman X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: hahnt@us.ibm.com, ietf-ldapext@netscape.com Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt References: <5.0.0.25.0.20001001192819.00a8feb0@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"NbhuHD.A.QPC.ZuU25"@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: > > At 05:26 PM 10/1/00 -0700, Rob Weltman 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, 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. > > > > I discussed the motivation for the behavior defined in the draft > >earlier in September. > > Please note language tags have no structure and should not be > parsed. "cn;lang-ja-JP-kanji" is not a subtype of "cn;lang-ja" > > Note that since LDAP language tags are an extension to LDAP "core" > protocol, I suggest that LDAP Java API language tag likewise be > an extension and detailed in a separate TS. > > >> 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? > > > > Yes > > This behavior is inconsistent with LDAP/X.500 subtyping. attrSet > is modifying the attrSet and hence should be consistent with > the protocol modify... which would only delete "name" and not > its subtypes. The operations defined in the API (for language-sensitive extraction of attributes) are operations on an object in memory at the client side, not LDAP protocol operations. There is no need and no benefit to having the operations on LDAPAttributeSet mimic the semantics of the search protocol operation. The intent of the language-sensitive operations in the API is to provide significant value to the user of the API, beyond what can be accomplished with search options. As I described in a message to this list on September 21, the semantics of the language-sensitive operations on LDAPAttributeSet were derived from a study of desired behavior in environments where localized and multi-language data is to be retrieved from a directory. > > >> 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. > > > > In practice, LDAPRebind is a simple interface for simple binds. For > >anything more complex, including SASL, LDAPBind should be used. > > s/more complex/secure/ > > >> 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. > > > > The normalization that is done is: > > > >escape processing > >white space between the RDN separator (",") and the following RDN > >case-insensitivity for RDNs with case-insensitive syntax > > > > Yes, determining which RDNs have case-insensitive syntax does require > >access to a subset of the schema of a particular server. > > Actually, the parent of the entry named by the entry could be > controlled by a different subschema, held by a different server... > > >> 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; > >> ... > >> } > > > > The values are not defined in the draft, so as to avoid redundancy. > >They are defined in RFC 2252. > > I assume you mean RFC 2251 and the ASN.1 defined resultCode > names and their corresponding values. However, the API uses > different names than the ASN.1... hence there is a need for a > explicit API name <-> ASN.1 name mapping table. (I'd prefer > the API just use the ASN.1 names...) I'll look them over. > >> Section 4.31.1: > >> --------------- > >> Why is doReferrals set to "false" by default? > > > > Safety. > > Clarification: security considerations > > >> non-SIMPLE re-bind authentication seems to need more thought, in > >> general. Is anybody working on this? > > > > Yes: > > > >http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt > > Is this going to progressed on the Standard Track as well? I'm not sure what the appropriate action is in this case, since I am pushing to get the API adopted as a standard Java extension though the JCP. > >> 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 > > > > OK > > I'd prefer using the ASN.1 names where ever possible, e.g: > LDAPConnection.neverDerefAliases > LDAPConnection.derefInSearching > LDAPConnection.derefFindingBaseObj > LDAPConnection.derefAlways That runs against the Java convention of all caps for constants :-) > >> Section 4.40.1: > >> --------------- > >> Will the client send off abandon requests for all outstanding (but > >> incomplete) operations if a bind() is invoked? > > > > No. That doesn't seem justified, IMHO. > > I concur. Given that a bind request causes all outstanding requests > to be abandoned automatically, sending off abandon requests for all > outstanding operations would be pointless. > > Kurt Rob From list@netscape.com Tue Oct 3 00:22: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 AAA20570 for ; Tue, 3 Oct 2000 00:22: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 e934DYL16493; Mon, 2 Oct 2000 21:13:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e934KAk00071; Mon, 2 Oct 2000 21:20:10 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 21:20:10 -0700 (PDT) Message-Id: <5.0.0.25.0.20001002211732.00a5feb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 02 Oct 2000 21:19:23 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt Cc: hahnt@us.ibm.com, ietf-ldapext@netscape.com In-Reply-To: <39D94BF8.3BE423C1@worldspot.com> References: <5.0.0.25.0.20001001192819.00a8feb0@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ov3BVC.A.e.05V25"@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 08:01 PM 10/2/00 -0700, Rob Weltman wrote: >> >> 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? >> > >> > Yes >> >> This behavior is inconsistent with LDAP/X.500 subtyping. attrSet >> is modifying the attrSet and hence should be consistent with >> the protocol modify... which would only delete "name" and not >> its subtypes. > > The operations defined in the API (for language-sensitive extraction of attributes) are operations on an object in memory at the client side, not LDAP protocol operations. There is no need and no benefit to having the operations on LDAPAttributeSet mimic the semantics of the search protocol operation. The intent of the language-sensitive operations in the API is to provide significant value to the user of the API, beyond what can be accomplished with search options. As I described in a message to this list on September 21, the semantics of the language-sensitive operations on LDAPAttributeSet were derived from a study of desired behavior in environments where localized and multi-language data is to be retrieved from a directory. How do I remove "name" from the attrSet without removing it's subtypes? From list@netscape.com Tue Oct 3 00:40: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 SMTP id AAA20763 for ; Tue, 3 Oct 2000 00:40: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 e934SQr27496; Mon, 2 Oct 2000 21:28:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e934dPY05663; Mon, 2 Oct 2000 21:39:25 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 21:39:25 -0700 (PDT) Message-ID: <39D963BE.B0476433@worldspot.com> Date: Mon, 02 Oct 2000 21:42:38 -0700 From: Rob Weltman X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: hahnt@us.ibm.com, ietf-ldapext@netscape.com Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt References: <5.0.0.25.0.20001001192819.00a8feb0@router.boolean.net> <5.0.0.25.0.20001002211732.00a5feb0@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"RQ05iD.A.zXB.6LW25"@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: > > > > > The operations defined in the API (for language-sensitive extraction of attributes) are operations on an object in memory at the client side, not LDAP protocol operations. There is no need and no benefit to having the operations on LDAPAttributeSet mimic the semantics of the search protocol operation. The intent of the language-sensitive operations in the API is to provide significant value to the user of the API, beyond what can be accomplished with search options. As I described in a message to this list on September 21, the semantics of the language-sensitive operations on LDAPAttributeSet were derived from a study of desired behavior in environments where localized and multi-language data is to be retrieved from a directory. > > How do I remove "name" from the attrSet without removing it's subtypes? My comment was misplaced - it really referred to the discussion in the previous paragraph about Section 4.3.5. I guess I could go either way as to the effect of removing "name" from LDAPAttributeSet. In the Mozilla implementation, the behavior is to remove only "name" and not any subtypes. Rob From list@netscape.com Tue Oct 3 01:22: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 BAA23224 for ; Tue, 3 Oct 2000 01:22: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 e935A5r06694; Mon, 2 Oct 2000 22:10:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e935L4215742; Mon, 2 Oct 2000 22:21:04 -0700 (PDT) Resent-Date: Mon, 2 Oct 2000 22:21:04 -0700 (PDT) Message-Id: <5.0.0.25.0.20000930112822.00a5d500@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 30 Sep 2000 11:38:38 -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: <"ggfjs.A.j1D._yW25"@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". I would say that server dependent. If your server has schema aware ACL evaluation (which I dare say is a must if you intend to handle alternative naming of attribute types), then handling subtyping is no big deal. Of course, subtyping in LDAP is completely optional. I would argue that subtyping within ACLs should likewise be optional. From list@netscape.com Tue Oct 3 06:57: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 GAA05554 for ; Tue, 3 Oct 2000 06:57: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 e93AnSL19258; Tue, 3 Oct 2000 03:49:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e93Au6w02422; Tue, 3 Oct 2000 03:56:06 -0700 (PDT) Resent-Date: Tue, 3 Oct 2000 03:56:06 -0700 (PDT) Date: Tue, 3 Oct 2000 03:55:42 -0700 (PDT) Message-Id: <200010031055.e93Atfj05139@ywing.netscape.com> From: bizdeal@hotmail.com To: .TSEJ@netscape.com Subject: I need to make YOU Wealthy so I can be Wealthy!!! X-Reply-To: bizdeal@hotmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"z_3N0C.A.kl.Ftb25"@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 There is so much money out there to be made on the internet. Don't you think you should be getting some of it?.... Dear Friend, Thank you for your time and interest. This email contains the ENTIRE PLAN of how YOU can make $50,000 or more in the next 90 days simply sending email! Seem impossible? Just read on and see how easy this is.... 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 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 have 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. You will understand once you try it yourself! ********* THE ENTIRE PLAN IS HERE BELOW ********* *** Print This Now For Future Reference *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days! Please read this program...THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello - My name is Johnathon Rourke, I'm from Rhode Island. 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. Two years ago, the corporation I worked 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. I am writing to share the experience in hopes that this could change your life FOREVER FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months 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 . 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 MACHINE I could start immediately without any debt. 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 I decided "WHY NOT!?!??" Initially I sent out 10,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 I also send the product (reports) by e-mail, my only expense is my time. 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 your time to read this plan, 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 and 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 fellow business owner and are in 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 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 retired from the program after sending thousands and thousands of 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 UP TO YOU NOW! DO IT ! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you delete this program from your in box, 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$$$$!!!! 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 business. 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 sell and deliver a product for EVERY dollar received. 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 EASIEST marketing plan anywhere! It is simply order filling by email! ******************************************************************* The product is informational and instructional material, keys to the secrets for everyone on to open the doors to the magic world of E-COMMERCE , the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by email. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Use any of the hundreds of bulk email services (search for "Bulk Email") and have them send 25,000 - 50,000 emails for you (about $49+) (4) Orders will come to you by postal mail - simply email them the Report they ordered. Let me ask you - isn't this about as easy as it gets? ******************************************************************* By the way there are over 50 MILLION email addresses with millions more ! joining the internet each year so don't worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter. I received this letter many times - then one day I decided it was time to try it. ******************************************************************* YOU CAN START TODAY - JUST DO THESE EASY STEPS: STEP #1. ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can't sell them if you don't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,000's of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you've ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. 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 ALL INFORMATION, every name and address, ! ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire email to send by email to prospects. Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month. Your cost to participate in this is practically nothing (surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! 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 email out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out hundreds of thousands of programs instead of 2,000 (Why stop at 2000?). But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0..5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!! !! REMEMBER FRIEND, THIS IS ASSUMING 1,990 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! METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet 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 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. Look how this small number accumulates to achieve the STAGGERING results below:! 1st level--your first 10 send you $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 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ----------$55,550 $$$$$$ AMAZING ISN'T IT? Remember friends, 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! Most people get 100's of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are going to get emails about this plan from you or somebody else and many will work this plan - the question is - Don't you want your name to be! on the emails they will send out? * * * DON'T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * * * SEE WHAT HAPPENS!!! *** YOU'LL BE AMAZED!!!* * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets of paper write: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: David Bowden P.O.Box 1036 Lismore, N.S.W 2480 Australia REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Richard Wright P.O.Box 3206 Knoxville, TN 37927-3206 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Suzie Davidson 1319 Pegusus Trail St. Peters, MO 63376 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: G.B. Scott P.O. Box 181 Chanute, KS 66720 ******* 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. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program - If you follow the instructions exactly - results WILL follow. $$$$ ******* 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. To generate more income, simply 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. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1. NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start!, Nothing to learn, NO skills needed! (Surely you know how to send email?) 2. No equipment to buy - you already have a computer and internet connection - so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Emailing copies of the reports is FREE!) 4. All of your customers pay you in CA$$H! This program will change your LIFE FOREVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above -- SUCCESS will be your reward. Thank you for your time and consideration. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ************************************************* This email has been sent to you because I was given your name as someone interested in receiving information about making money on the internet. If this has reached you in error please hit reply and type 'REMOVE' in the subject box. From list@netscape.com Tue Oct 3 08:42: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 IAA08512 for ; Tue, 3 Oct 2000 08:42: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 e93CTHr15560; Tue, 3 Oct 2000 05:29:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e93CeHc27931; Tue, 3 Oct 2000 05:40:17 -0700 (PDT) Resent-Date: Tue, 3 Oct 2000 05:40:17 -0700 (PDT) Message-Id: <200010031222.IAA27887@roadblock.missi.ncsc.mil> From: "Miklos, Sue A." To: "'hahnt@us.ibm.com'" , ietf-ldapext@netscape.com Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Tue, 3 Oct 2000 08:31:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02D35.E45847A2" Resent-Message-ID: <"Wi5-K.A.xzG.vOd25"@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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02D35.E45847A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the reply. One of the thoughts we've had (maybe a dangerous thing) is to use the subtyping capability and put some form of tag information into the = attribute type, indicating that it is of 'type RSA 2048' or 'type DSA 1024', etc. = and then try to apply ACIs against the type. Seems like a particularly burdensome way to present a repository that = can be managed by differing CA domains. any alternatives welcomed. regards, Sandi -----Original Message----- From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com] Sent: Monday, October 02, 2000 8:36 PM To: ietf-ldapext@netscape.com Subject: RE: Considering Attribute Subtypes during ACL evaluation Sandi, As I understand the LDAP ACL draft, access control is not applied to individual values within an attribute within an entry. Access control applies to all values for the attribute within the entry. Thus, I = believe you are correct. 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 "Miklos, Sue A." on 10/02/2000 08:25:22 AM To: "'Kurt D. Zeilenga'" , Jim Sermersheim cc: ietf-ldapext@netscape.com, Duane Buss Subject: RE: Considering Attribute Subtypes during ACL evaluation I have an attribute type "userCertificate" and have many values (PKI A certificate; PKI B certificate, etc.) My requirement is to constrain the management of that attribute value = to the CA or appropriate named authority for that attribute value. I would not want to allow CA for PKI A to have all privileges wrt userCertificate for PKI B. as I read your proposal, I don't interpret this as supporting my requirement. is this correct? Sandi -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, September 29, 2000 5:53 PM To: Jim Sermersheim Cc: ietf-ldapext@netscape.com; 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.=A0 One issue in adding such is which ACL takes precedence.=A0 This is complicated due to multiple inheritance due to attribute description options. One possible precedence: =A0=A0=A0=A0=A0=A0=A0 type;a;b;c =A0=A0=A0=A0=A0=A0=A0 type =A0=A0=A0=A0=A0=A0=A0 supertype;a;b;c =A0=A0=A0=A0=A0=A0=A0 supertype Of course, if one of the options was "binary", it sure would be nice to allow =A0=A0=A0=A0=A0=A0=A0 type;a;binary;c =A0=A0=A0=A0=A0=A0=A0 type;a;c =A0=A0=A0=A0=A0=A0=A0 type =A0=A0=A0=A0=A0=A0=A0 supertype;a;binary;c =A0=A0=A0=A0=A0=A0=A0 supertype;a;c =A0=A0=A0=A0=A0=A0=A0 supertype But this seems overly complicated.=A0 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: =A0=A0=A0=A0=A0=A0=A0 type =A0=A0=A0=A0=A0=A0=A0 supertype I prefer this. Kurt ************************************************************************= **** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ************************************************************************= **** ** ------_=_NextPart_001_01C02D35.E45847A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Considering Attribute Subtypes during ACL evaluation

Thank you for the reply.

One of the thoughts we've had (maybe a dangerous = thing) is to use the subtyping capability and put some form of tag = information into the attribute type, indicating that it is of 'type RSA = 2048' or 'type DSA 1024', etc. and then try to apply ACIs against the = type.

Seems like a particularly burdensome way to present a = repository that can be managed by differing CA domains.

any alternatives welcomed.

regards,
Sandi

-----Original Message-----
From: hahnt@us.ibm.com [mailto:hahnt@us.ibm.com]
Sent: Monday, October 02, 2000 8:36 PM
To: ietf-ldapext@netscape.com
Subject: RE: Considering Attribute Subtypes during = ACL evaluation



Sandi,

As I understand the LDAP ACL draft, access control is = not applied to
individual values within an attribute within an = entry.  Access control
applies to all values for the attribute within the = entry.  Thus, I believe
you are correct.

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


"Miklos, Sue A." = <samiklo@missi.ncsc.mil> on 10/02/2000 08:25:22 AM

To:   "'Kurt D. Zeilenga'" = <Kurt@OpenLDAP.org>, Jim Sermersheim
      = <JIMSE@novell.com>
cc:   ietf-ldapext@netscape.com, Duane = Buss <DBuss@novell.com>
Subject:  RE: Considering Attribute Subtypes = during ACL evaluation





I have an attribute type "userCertificate" = and have many values (PKI A
certificate; PKI B certificate, etc.)

My requirement is to constrain the management of that = attribute value to
the CA or appropriate named authority for that = attribute value.

I would not want to allow CA for PKI A to have all = privileges wrt
userCertificate for PKI B.

as I read your proposal, I don't interpret this as = supporting my
requirement.

is this correct?

Sandi

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, September 29, 2000 5:53 PM
To: Jim Sermersheim
Cc: ietf-ldapext@netscape.com; 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.=A0 One
issue in adding such is which ACL takes = precedence.=A0 This is
complicated due to multiple inheritance due to = attribute
description options.

One possible precedence:
=A0=A0=A0=A0=A0=A0=A0 type;a;b;c
=A0=A0=A0=A0=A0=A0=A0 type
=A0=A0=A0=A0=A0=A0=A0 supertype;a;b;c
=A0=A0=A0=A0=A0=A0=A0 supertype

Of course, if one of the options was = "binary", it sure would be
nice to allow
=A0=A0=A0=A0=A0=A0=A0 type;a;binary;c
=A0=A0=A0=A0=A0=A0=A0 type;a;c
=A0=A0=A0=A0=A0=A0=A0 type
=A0=A0=A0=A0=A0=A0=A0 supertype;a;binary;c
=A0=A0=A0=A0=A0=A0=A0 supertype;a;c
=A0=A0=A0=A0=A0=A0=A0 supertype

But this seems overly complicated.=A0 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:
=A0=A0=A0=A0=A0=A0=A0 type
=A0=A0=A0=A0=A0=A0=A0 supertype

I prefer this.

Kurt



***************************************************************= **************

This confirms that this email message has been swept = by
MIMEsweeper for the presence of computer = viruses.
***************************************************************= ***************




------_=_NextPart_001_01C02D35.E45847A2-- From list@netscape.com Tue Oct 3 18:57:04 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 SAA24511 for ; Tue, 3 Oct 2000 18:57: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 e93MiNr00392; Tue, 3 Oct 2000 15:44:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e93MtMw23081; Tue, 3 Oct 2000 15:55:22 -0700 (PDT) Resent-Date: Tue, 3 Oct 2000 15:55:22 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 03 Oct 2000 16:30:36 -0600 From: "Steve Sonntag" To: , Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D38B3D06.AFCEACEA" Resent-Message-ID: <"1W1oa.A._mF.NPm25"@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. --=_D38B3D06.AFCEACEA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> hahnt@us.ibm.com> 02-Oct-00 4:09:59 AM >> The current draft defines hop_limit as 10, see 4.7.7 & 4.39.39. I say leave it as it currently is in the draft -Steve > Is hop_limit set to zero by default? Does zero imply no limit? The default value and the semantics of zero should be defined in the draft. Zero should imply no limit, but the default should be a reasonable value (to allow reasonable nesting levels of reference while preventing infinite loops); I propose 5. TJH> 5 sounds fine to me. > Section 4.32.3: > --------------- > Would it be useful to have a "isReponseReceived( int msgid )" method > as well? That might be useful. > How about an "isComplete( int msgid )"? I'm not sure that makes sense: if all results have been retrieved for a particular message ID, there is no longer a queue maintained for it. getMessageIDs() will not return the ID. It would be difficult for the application to distinguish between the request being complete (all results retrieved for that ID) on the one hand, and an invalid ID on the other. TJH> I agree that if there is no longer anything maintained for the = message ID TJH> that it would be hard to distinguish. But if an application wanted = to TJH> hold of on processing the response until the complete message was TJH> received it could test such an "isComplete()" result. > Section 4.40.1: > --------------- > Will the client send off abandon requests for all outstanding (but > incomplete) operations if a bind() is invoked? No. That doesn't seem justified, IMHO. TJH> agreed. > > 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 --=_D38B3D06.AFCEACEA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


>>> 02-Oct-00 4:09:59 AM >>">hahnt@us.ibm.com&= gt;=20 02-Oct-00 4:09:59 AM >>

The current draft defines = hop_limit as=20 10, see 4.7.7 &
4.39.39.  I say leave it as it currently is in the draft
 
-Steve

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

  The default value and the semantics of zero = should=20 be defined in the
draft. Zero should imply no limit, but the default = should=20 be a
reasonable value (to allow reasonable nesting levels of = reference=20 while
preventing infinite loops); I propose 5.

TJH> 5 sounds = fine=20 to me.
 


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

  That might be useful.


> How about an=20 "isComplete( int msgid )"?

  I'm not sure that makes sense: if = all=20 results have been retrieved for
a particular message ID, there is no = longer a=20 queue maintained for it.
getMessageIDs() will not return the ID. It = would be=20 difficult for the
application to distinguish between the request = being=20 complete (all
results retrieved for that ID) on the one hand, and an = invalid=20 ID on the
other.

TJH> I agree that if there is no longer = anything=20 maintained for the message
ID
TJH> that it would be hard to=20 distinguish.  But if an application wanted to
TJH> hold of = on=20 processing the response until the complete message was
TJH> received = it=20 could test such an "isComplete()" result.



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

  No. That doesn't seem justified, IMHO.

TJH>= ;=20 agreed.

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



--=_D38B3D06.AFCEACEA-- From list@netscape.com Wed Oct 4 04:35: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 EAA13700 for ; Wed, 4 Oct 2000 04:35:33 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e948RCI27373; Wed, 4 Oct 2000 01:27:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e948Xpw04775; Wed, 4 Oct 2000 01:33:51 -0700 (PDT) Resent-Date: Wed, 4 Oct 2000 01:33:51 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Wed, 4 Oct 2000 01:30:21 -0700 To: OSI Directory List , IETF LDAP From: "Hoyt L. Kesterson II" Subject: additional draft 4th edition directory texts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Resent-Message-ID: <"gtf74C.A.VKB.vtu25"@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 Three more drafts have been produced First drafts of X.500/part-1, X.519/part-5, and X.535/part-9 are up on the server in word and pdf formats at ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ In addition, the pdf versions of all the documents except X.509/part-8 have been reconstructed to eliminate the truncation of text at the bottom of the pages. There is no change to the word versions of the documents. 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 week 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. hoyt From list@netscape.com Wed Oct 4 13: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 NAA27148 for ; Wed, 4 Oct 2000 13:42: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 e94HTGJ02504; Wed, 4 Oct 2000 10:29:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e94HeJA13081; Wed, 4 Oct 2000 10:40:19 -0700 (PDT) Resent-Date: Wed, 4 Oct 2000 10:40:19 -0700 (PDT) From: hahnt@us.ibm.com Importance: Normal Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 4 Oct 2000 10:01:02 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev01 |September 13, 2000) at 10/04/2000 01:40:11 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 e94HeFr12987 Resent-Message-ID: <"kb2UTC.A.cLD.Au225"@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 e94HTGJ02504 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA27148 Steve, Ok by me - as long as the default value is defined. 10 sounds fine. 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 "Steve Sonntag" on 10/03/2000 06:30:36 PM To: , Timothy Hahn/Endicott/IBM@IBMUS cc: Subject: Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt >>> hahnt@us.ibm.com> 02-Oct-00 4:09:59 AM >> The current draft defines hop_limit as 10, see 4.7.7 & 4.39.39.  I say leave it as it currently is in the draft -Steve > Is hop_limit set to zero by default?  Does zero imply no limit?   The default value and the semantics of zero should be defined in the draft. Zero should imply no limit, but the default should be a reasonable value (to allow reasonable nesting levels of reference while preventing infinite loops); I propose 5. TJH> 5 sounds fine to me. > Section 4.32.3: > --------------- > Would it be useful to have a "isReponseReceived( int msgid )" method > as well?   That might be useful. > How about an "isComplete( int msgid )"?   I'm not sure that makes sense: if all results have been retrieved for a particular message ID, there is no longer a queue maintained for it. getMessageIDs() will not return the ID. It would be difficult for the application to distinguish between the request being complete (all results retrieved for that ID) on the one hand, and an invalid ID on the other. TJH> I agree that if there is no longer anything maintained for the message ID TJH> that it would be hard to distinguish.  But if an application wanted to TJH> hold of on processing the response until the complete message was TJH> received it could test such an "isComplete()" result. > Section 4.40.1: > --------------- > Will the client send off abandon requests for all outstanding (but > incomplete) operations if a bind() is invoked?   No. That doesn't seem justified, IMHO. TJH> agreed. > > 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 Wed Oct 4 13:55: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 NAA27340 for ; Wed, 4 Oct 2000 13:55: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 e94HgKJ05888; Wed, 4 Oct 2000 10:42:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e94HrKs20406; Wed, 4 Oct 2000 10:53:20 -0700 (PDT) Resent-Date: Wed, 4 Oct 2000 10:53:20 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 04 Oct 2000 11:24:30 -0600 From: "Steven Merrill" To: Cc: Subject: comments on draft-ietf-ldapext-ldap-java-api-11.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e94Hqur20120 Resent-Message-ID: <"SkJfcC.A.C8E.K6225"@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 Internet Draft defines DEREF_FINDING = 1 and DEREF_SEARCHING = 2. RFC 2251 defines derefInSearching = 1 and derefFindingBaseObj = 2. The ID should be updated to reflect the 2251 definitions. -Steve From Internet Draft: 4.39.13 setOption LDAPConnection.DEREF_FINDING (1) aliases are dereferenced when finding the starting point for the search (but not when searching under that starting entry). LDAPConnection.DEREF_SEARCHING (2)Aliases are dereferenced when searching the entries beneath the starting point of the search (but not when finding the starting entry). From RFC 2251: derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, From list@netscape.com Wed Oct 4 15:41: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 PAA29934 for ; Wed, 4 Oct 2000 15:41: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 e94JSvJ00243; Wed, 4 Oct 2000 12:28:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e94JdwQ16130; Wed, 4 Oct 2000 12:39:58 -0700 (PDT) Resent-Date: Wed, 4 Oct 2000 12:39:58 -0700 (PDT) Date: Wed, 4 Oct 2000 12:39:47 -0700 (PDT) Message-Id: <200010041939.e94Jdgr12410@ywing.netscape.com> From: jumpinnow@angelfire.com To: ietf-ldapext@netscape.com Subject: Keep people at your website. X-Reply-To: jumpinnow@angelfire.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5k6l4D.A.w7D.Ne425"@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 $. We have not communicated in some time. Thought I would show you the hottest new product on the market and how you can both use this and make money at the same time. "If you have $99 and can type with one finger, you can now have a multi-media web presence for your small business, personal site, ecommerce site, family site, or any other content you may desire." ~Al Greene, eFlash Co-founder. This your 3rd message from our cutting edge eART Email Seminar System about eFlash Technologies revolutionary multimedia flash program. Let's learn exactly what flash technology is all about!! ===================== FLASH IS THE FUTURE?? ===================== Without a doubt, Flash is the technology of the internet's interactive future. You will quickly notice the Flash presence as you surf the web. Many leading-edge companies, such as Comedy Central, Sony, Nike, Ford and Disney rely on Flash and Flash Player to deliver the best possible Web content on their sites. ==================== FLASH IS EXPENSIVE!! ==================== However, you will also discover that only the Fortune 500 companies and select others have the funds to build and edit such powerful multi-media web sites. At $100+ per hour in programming costs, Flash has been limited to the "Big Players" on the web. ============================ Enter The eFlash Technology. ============================ eFlash Technologies brings the power of Flash Technology to the masses through multi-media build-it-yourself Flash websites. Our templated technology allows anyone, with access to a computer and the internet, to quickly and inexpensively build a multi-media flash website. The eFlash technology is completely turnkey and allows for unlimited editing of your flash site 24 hours a day. =============================== An Overview of Flash Technology =============================== Flash 4 is the solution for producing and delivering high-impact Web sites. Pulsing musical tracks, sound effects, gorgeous animations, and innovative interfaces all converge in Flash. Flash puts the flash in Web sites and other Web-enabled devices (such as WebTV). Flash uses vector graphics technology. Unlike bitmapped images that are optimized for a single resolution, vector images can adapt to multiple display sizes and resolutions. This is ideal for displaying Web sites uniformly on set-top boxes, hand-held computers, or PCs. Unlike bitmapped images such as GIFs and JPEGs used on the Web today, vector images—graphics, charts, maps, and animations—fit into compact, efficient files that speed over the Web. ========================= Why Use Flash Technology? ========================= Flash sites are more attractive than those using traditional Web technologies. All graphics created in Flash 4 appear smooth on screen (anti-aliased) so that users see what the Web designer intended. Beyond their good looks, Flash sites are also about speed. The vector-based sites play as they download, and Flash technology delivers Web sites efficiently, even over slow modem connections. Flash sites playback full-screen, on all monitor sizes, and consistently across multiple platforms users have a consistently dazzlingly experience. ==================================== The Flash Technology is Everywhere!! ==================================== Flash technology is already built-in. Over 222 million people can view graphics and animation created with Flash (source: NPD Research, March 2000). Flash sites are consistently viewable across Macintosh, Windows, Solaris, Linux, and additional Web-appliance platforms. The Flash Player is the most widely distributed high-impact Web site viewer today. Popular Web hardware and software products from Microsoft, Netscape, America Online, Apple, WebTV, Prodigy, Earthlink, Network Computer, Gateway, Compaq, Disney, and many others already have Flash technology built into their products. ========================= Download isn't Necessary! ========================= The majority of Web users can experience Flash content without having to download and install a player. Most Web browsers already have Flash Player installed. It is pre-installed on most computers, as it is included with all copies of Windows 98 (including all new Windows 98 computers), Netscape Navigator, Apple Macintosh operating systems, America Online, WebTV, and RealPlayer G2, among others. To provide Flash viewers with a seamless viewing experience, Flash Player is distributed through a number of key partners, including Microsoft, Netscape, and AOL. As you can see, flash technology is a poweful part of the Internet. But do not take our word for it.... ======================== Flash Technology Reviews ======================== PC Computing, January 1998 "Want to jazz up that dead-end site with a little animation? Do it yourself with this easy, inexpensive gem." Chicago Tribune, September 16, 1999 "...(Flash 4) is a worthwhile upgrade to a formidable program that will become increasingly popular as broad bandwidth takes over the Web." Internet.com, September 21, 1999 "The beauty of Flash is that you can have animation, interactivity, and scalability and still keep the file size small enough to stream across a normal modem connection. I recently came across a Web site that featured a 3 minute animated movie, complete with sound, that weighed in at just 191 KB. Now that's impressive." MacWorld, July 1999 "One program has emerged as something of a standard for Web animation. Flash has quickly become the dominant tool for creating animation and simple interactivity... " WebReview, July 1999 "Flash is no longer just the best web animation solution—now it's one of the most, if not the most, accessible web multimedia development solutions." To learn more and get involved please visit: http://www.eflashcash.com/er/success4unme/ And if you would like to get the Online seminar to learn everything about this great new product click on the Seminar Tab at the top of the page. To see the product in action please visit: http://www.eflashtech.com/intro/success4unme/ Thanks again. Sincerely: Peter. ------------------------------------------------------------------------------------------------------------------- We have communicated back and forth before. If you wish to stop receiving e-mail from us simply reply with Remove in the subject and the e-mail address you received this e-mail at in the body. Thanks again. From list@netscape.com Wed Oct 4 23:57: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 XAA09596 for ; Wed, 4 Oct 2000 23:57: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 e953ieJ03141; Wed, 4 Oct 2000 20:44:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e953tjc14327; Wed, 4 Oct 2000 20:55:45 -0700 (PDT) Resent-Date: Wed, 4 Oct 2000 20:55:45 -0700 (PDT) From: waytogo2k@yahoo.com Date: Wed, 04 Oct 00 22:33:25 EST To: Friend@public.com Subject: Adv Message-ID: <200009041628.JAA06240@emu.prod.itd.citydirect.com> X-UIDL: 91a82975769339c3e0d50cdcbaa408a8 Comments: Authenticated sender is Resent-Message-ID: <"dlJ_JB.A.cfD._u_25"@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 Hi, I thought I'd drop this one time quick note to let you know about an EXCELLENT e-Commerce Business which has enjoyed rapid and consistent growth in the last 3 years. It may fit very well into your business portfolio. This is the EASIEST and the BEST online business today, virtually a SELF-RUN ONLINE BUSINESS. It's TWICE voted as the #1 online business. *Christian, of Marion, OH. writes: "I'm having 10 times the success with this business as I did with my other MLMs that I tried. I have a personal closure rate of about 80%. And I attribute that totally to the system that you have created. It truly is the best company out there. Since joining in August of this year, I have been approached by 3 distributors of other companies, including 1 co-founder, but after explaining what I do in my business and how I work the opportunity, I guess they've given up knowing that their program is much harder to achieve success in." If your current program demands that you sell products and sponsor others you will fail 90% of the time! Put yourself in the power position; win 90% of the time offering a program that everyone wants to be involved with! Simply click below to visit the award-winning website: http://12.21.34.24/369875 It will ONLY take a minute to find out. You will be glad that you did! _______________________________________________________ _______________________________________________________ This message is sent in compliance with H.R. 3113 Sect. 5 para. (a) Pursuant to Sect. 5 para. (a)(2) further transmissions to you by the Sender of this message may be stopped at no cost by submitting a request to "Remove". Your e-mail address was acquired via a commercial list provider As someone interested in Internet Business Opportunities. Every Effort was taken to ensure list accuracy. If we received your e-mail address in error or you are no longer interested, please accept our apologies. Click on the link below and we will not contact you again. mailto:waytogo2k@yahoo.com?subject=Remove Thank You From list@netscape.com Thu Oct 5 12:11: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 MAA02248 for ; Thu, 5 Oct 2000 12:11: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 e95G2nI28857; Thu, 5 Oct 2000 09:02:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e95G6vM11067; Thu, 5 Oct 2000 09:06:57 -0700 (PDT) Resent-Date: Thu, 5 Oct 2000 09:06:57 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer goliath.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'Jim Sermersheim'" , prasanta@netscape.com, Kurt@openldap.org Cc: ietf-ldapext@netscape.com, hahnt@us.ibm.com Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Thu, 5 Oct 2000 18:04:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EE5.F26C8B70" Resent-Message-ID: <"AWLVMC.A.lnC.ScK35"@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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02EE5.F26C8B70 Content-Type: text/plain; charset="iso-8859-1" Hi Jim, X.500 says for opinion nothing about AccessControl and subtyping. Access Control can be given on an attribute basis and have nothing to do with the subtyping of attributes. Subtypes are defined in the schema and are only used in the search, if you give a supertype in a filter item all subtypes will be searched also. Helmut -----Original Message----- From: Jim Sermersheim [mailto:JIMSE@novell.com] Sent: Dienstag, 3. Oktober 2000 00:40 To: prasanta@netscape.com; Kurt@OpenLDAP.org Cc: ietf-ldapext@netscape.com; hahnt@us.ibm.com Subject: Re: Considering Attribute Subtypes during ACL evaluation I agree for the exact same reason optional support of attr subtyping). It would also be interesting to hear from the X.500 community on how this is handled by different vendors. I found the whole thing unspecified. Jim >>> "Kurt D. Zeilenga" 9/30/00 12:59:03 PM >>> 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 ------_=_NextPart_001_01C02EE5.F26C8B70 Content-Type: text/html; charset="iso-8859-1"
Hi Jim,
 
X.500 says for opinion nothing about AccessControl and subtyping. Access Control can be given on an
attribute basis and have nothing to do with the subtyping of attributes.
Subtypes are defined in the schema and are only used in the search, if you
give a supertype in a filter item all subtypes will be searched also.
 
Helmut
-----Original Message-----
From: Jim Sermersheim [mailto:JIMSE@novell.com]
Sent: Dienstag, 3. Oktober 2000 00:40
To: prasanta@netscape.com; Kurt@OpenLDAP.org
Cc: ietf-ldapext@netscape.com; hahnt@us.ibm.com
Subject: Re: Considering Attribute Subtypes during ACL evaluation

I agree for the exact same reason optional support of attr subtyping). It would also be interesting to hear from the X.500 community on how this is handled by different vendors. I found the whole thing unspecified.
 
Jim


>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 9/30/00 12:59:03 PM >>>
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

------_=_NextPart_001_01C02EE5.F26C8B70-- From list@netscape.com Fri Oct 6 18:05: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 SAA13736 for ; Fri, 6 Oct 2000 18:05: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 e96LvNI18508; Fri, 6 Oct 2000 14:57:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e96M45w29494; Fri, 6 Oct 2000 15:04:05 -0700 (PDT) Resent-Date: Fri, 6 Oct 2000 15:04:05 -0700 (PDT) Message-ID: <39DE4B7B.3D6E1CE5@software.com> Date: Fri, 06 Oct 2000 15:00:27 -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: Prasanta Behera , hahnt@us.ibm.com, ietf-ldapext@netscape.com Subject: Re: Considering Attribute Subtypes during ACL evaluation References: <5.0.0.25.0.20000930114328.00a66910@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kc-5q.A.cMH.Uxk35"@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: [snip] > However, given that subtyping is optional in LDAPv3, Kurt Could you please point to the text in RFC 2251 (or any other LDAP RFC) which explicitly states that subtyping is optional in LDAPv3. I just want to confirm. thanks sanjay > one > could argue it's best to leave subtyping within ACLs as > being optional. > > Kurt From list@netscape.com Fri Oct 6 18:56: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 SAA14370 for ; Fri, 6 Oct 2000 18:56: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 e96MhdJ21584; Fri, 6 Oct 2000 15:43:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e96MsjQ25725; Fri, 6 Oct 2000 15:54:45 -0700 (PDT) Resent-Date: Fri, 6 Oct 2000 15:54:45 -0700 (PDT) Message-ID: <39DE5760.B1FA298E@software.com> Date: Fri, 06 Oct 2000 15:51:12 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ldapext Subject: a question regarding qdstring defn in RFC 2252 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BSUVTC.A.lRG.0gl35"@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 ####
4.1. Common Encoding Aspects
[snip]

dstring         = 1*utf8
qdstring        = whsp "'" dstring "'" whsp
[snip]
####

In the defn of qdstring, should it be explicitly mentioned that
if the dstring contains a "'" then it should be escaped by "\" or
am I missing something ?

thanks
sanjay
 
  From list@netscape.com Fri Oct 6 19:25: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 TAA14686 for ; Fri, 6 Oct 2000 19:25: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 e96NChJ27038; Fri, 6 Oct 2000 16:12:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e96NJAE09906; Fri, 6 Oct 2000 16:19:10 -0700 (PDT) Resent-Date: Fri, 6 Oct 2000 16:19:10 -0700 (PDT) Message-Id: <5.0.0.25.0.20001006160742.00a437a0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Oct 2000 16:17:32 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: Considering Attribute Subtypes during ACL evaluation Cc: Prasanta Behera , hahnt@us.ibm.com, ietf-ldapext@netscape.com In-Reply-To: <39DE4B7B.3D6E1CE5@software.com> References: <5.0.0.25.0.20000930114328.00a66910@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"LFBfoB.A.7WC.X3l35"@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:00 PM 10/6/00 -0700, sanjay jain wrote: >"Kurt D. Zeilenga" wrote: > >[snip] > >> However, given that subtyping is optional in LDAPv3, > >Kurt > Could you please point to the text in RFC 2251 (or > any other LDAP RFC) which explicitly states that > subtyping is optional in LDAPv3. I just want to confirm. I believe it's implicit in the following statements: 3.2.2: Servers which follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms, and so these subschemas are not ordinary entries. LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema. The first sentence implies that servers may not follow X.500(93). 3.3: LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface. The interface is not violated if subtyping is not supported. From list@netscape.com Fri Oct 6 19:32: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 TAA14749 for ; Fri, 6 Oct 2000 19:32: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 e96NJYJ28547; Fri, 6 Oct 2000 16:19:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e96NUek17493; Fri, 6 Oct 2000 16:30:40 -0700 (PDT) Resent-Date: Fri, 6 Oct 2000 16:30:40 -0700 (PDT) Message-Id: <5.0.0.25.0.20001006162108.00a51500@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Oct 2000 16:30:19 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: a question regarding qdstring defn in RFC 2252 Cc: ldapext In-Reply-To: <39DE5760.B1FA298E@software.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ws8qCC.A.eQE.fCm35"@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:51 PM 10/6/00 -0700, sanjay jain wrote: >#### >4.1. Common Encoding Aspects >[snip] > >dstring = 1*utf8 >qdstring = whsp "'" dstring "'" whsp >[snip] >#### > >In the defn of qdstring, should it be explicitly mentioned that >if the dstring contains a "'" then it should be escaped by "\" or >am I missing something ? It should likely define an appropriate escaping mechanism ( \' or \27 ). I'll make a note of this for LDAPbis efforts. Kurt From list@netscape.com Fri Oct 6 19:34: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 TAA14774 for ; Fri, 6 Oct 2000 19:34: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 e96NQ9I08227; Fri, 6 Oct 2000 16:26:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e96NWoY18697; Fri, 6 Oct 2000 16:32:50 -0700 (PDT) Resent-Date: Fri, 6 Oct 2000 16:32:50 -0700 (PDT) Message-Id: <5.0.0.25.0.20001005171608.00a33da0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Oct 2000 16:29:45 -0700 To: "Jim Sermersheim" , From: Bruce Greenblatt Subject: Re: what are the server guys doing? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_20864401==_.ALT" Resent-Message-ID: <"lH6w4.A.BiE.dEm35"@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 --=====================_20864401==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed OK. I got the response that I expected. LDAP Server vendors are not planning on implementing any new extensions. Other than this language tag thing (which I see virtually no use for), what is going on is nothing. Bruce At 04:54 PM 10/2/2000, Jim Sermersheim wrote: >Bruce, > >The problem is, when one tries to implement language tags (an RFC of the >ldapext WG) on the server, they run into all sorts of unanswered questions >and underspecified, or even conflicting requirements. I don't think the >goal is to specifically implement support for an entry with numerous >subtypes within a single attribute. I think people are just trying to >implement language tags in a correct and consistent manner. > >Though we'd like to implement many of the drafts listed below, we feel >more urgency to implement language tags now. We don't want to just throw a >solution together and get onto the next extension before we feel assured >of interoperability. > >Jim > > >>> Bruce Greenblatt 10/2/00 > 5:04:42 PM >>> >I'm sitting here watching the discussion on attribute sub-typing, and >trying (without any success) to figure when I'd ever need an entry that had >numerous subtypes within a single attribute. Can someone give me a good >example of when a single LDAP entry would need one attribute with lots of >subtypes present? It seems to me that this is going in a different >direction that I'd like to see. As an LDAP application developer, I'm more >interested in seeing other features added on the server side. I can make >do without the sub-type stuff, but I really need to be able to selectively >delete a sub-tree. > >Just out of curiosity, I'd be interested in finding out if anyone that >builds a server has any plans on supporting any recently defined extensions >(controls or extended operations). For example: > >LDAP Authentication Response Control (draft) >LDAP Proxied Authentication Control (draft) >LDAP Controls for Reply Signatures (draft) >Returning Matched Values with LDAPv3 (draft) >LDAP Control for a Duplicate Entry Representation of Search Results (draft) >LDAP Tree Delete Control (draft) >LDAP Client Update Protocol (draft) >Simple Operations on Subtrees (for LDAP) (draft) >An LDAP Control and Schema for Holding Operation Signatures (RFC 2649) > >I've probably missed a few that have been defined. I'm very interested in >encouraging extension development. As far as I can tell, there is very >little activity in this area, but I'd like to hear differently. I'm >expecting deafening silence in response, but am hopefully of hearing some >noise! I'm sure that there would be plenty of interested beta testers... > >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 ============================================== 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 --=====================_20864401==_.ALT Content-Type: text/html; charset="us-ascii" OK.  I got the response that I expected.  LDAP Server vendors are not planning on implementing any new extensions.  Other than this language tag thing (which I see virtually no use for), what is going on is nothing.

Bruce

At 04:54 PM 10/2/2000, Jim Sermersheim wrote:

Bruce,
 
The problem is, when one tries to implement language tags (an RFC of the ldapext WG) on the server, they run into all sorts of unanswered questions and underspecified, or even conflicting requirements. I don't think the goal is to specifically implement support for an entry with numerous subtypes within a single attribute. I think people are just trying to implement language tags in a correct and consistent manner.
 
Though we'd like to implement many of the drafts listed below, we feel more urgency to implement language tags now. We don't want to just throw a solution together and get onto the next extension before we feel assured of interoperability.
 
Jim

>>> Bruce Greenblatt <bgreenblatt@directory-applications.com> 10/2/00 5:04:42 PM >>>
I'm sitting here watching the discussion on attribute sub-typing, and
trying (without any success) to figure when I'd ever need an entry that had
numerous subtypes within a single attribute.  Can someone give me a good
example of when a single LDAP entry would need one attribute with lots of
subtypes present?  It seems to me that this is going in a different
direction that I'd like to see.  As an LDAP application developer, I'm more
interested in seeing other features added on the server side.   I can make
do without the sub-type stuff, but I really need to be able to selectively
delete a sub-tree.

Just out of curiosity, I'd be interested in finding out if anyone that
builds a server has any plans on supporting any recently defined extensions
(controls or extended operations).  For example:

LDAP Authentication Response Control  (draft)
LDAP Proxied Authentication Control  (draft)
LDAP Controls for Reply Signatures (draft)
Returning Matched Values with LDAPv3  (draft)
LDAP Control for a Duplicate Entry Representation of Search Results (draft)
LDAP Tree Delete Control (draft)
LDAP Client Update Protocol (draft)
Simple Operations on Subtrees (for LDAP) (draft)
An LDAP Control and Schema for Holding Operation Signatures (RFC 2649)

I've probably missed a few that have been defined.  I'm very interested in
encouraging extension development.  As far as I can tell, there is very
little activity in this area, but I'd like to hear differently.  I'm
expecting deafening silence in response, but am hopefully of hearing some
noise!  I'm sure that there would be plenty of interested beta testers...

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

==============================================
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 --=====================_20864401==_.ALT-- From list@netscape.com Sat Oct 7 12:15: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 MAA06500 for ; Sat, 7 Oct 2000 12:15: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 e97G7aI15819; Sat, 7 Oct 2000 09:07:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e97GELA03760; Sat, 7 Oct 2000 09:14:21 -0700 (PDT) Resent-Date: Sat, 7 Oct 2000 09:14:21 -0700 (PDT) X-Sender: openreturn@excite.com From: Wholesaler To: ietf-ldapext@netscape.com Date: Sat, 07 Oct 2000 12:05:58 -0400 Subject: Spare-Time Work,Full-Time Income MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20001007161417.XNAB5657.mtiwmhc26.worldnet.att.net@localhost> Resent-Message-ID: <"STgpM.A.e6.cv035"@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 "WHAT'S IN IT FOR ME?" *Use our catalogs to get big orders *Distributorships opening in your area *On most items you can more than double your money *It only takes a few hours a week or month *You keep all the profits.We don't take a percentage of your sales. *We will help you every way we can, you'r not out there alone *There's no quota, no pressure.Sell as much as you want.Tell us how much you want to make and we will help you get there. ANSWER THIS EMAIL WITH SUB-WHOLESALER IN THE SUBJECT BOX. THANK YOU FOR YOUR VALUABLE TIME. ONE TIME MAILING. John Distribution Manager USWD From list@netscape.com Sun Oct 8 00: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 AAA11988 for ; Sun, 8 Oct 2000 00:41: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 e984WtI18691; Sat, 7 Oct 2000 21:32:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e984deg19487; Sat, 7 Oct 2000 21:39:40 -0700 (PDT) Resent-Date: Sat, 7 Oct 2000 21:39:40 -0700 (PDT) Date: Sat, 7 Oct 2000 21:39:15 -0700 (PDT) Message-Id: <200010080439.e984d4311837@xwing.netscape.com> From: marketstarter@TOYO.lycos.com To: Marketer@netscape.com Subject: Admit it, you need friends! X-Reply-To: marketstarter@lycos.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kBYu2D.A.DwE.Lq_35"@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 Note: Read to the bottom to find out how you can win a free computer! If you're one of the thousands of people out there working hard, just getting by, and never getting ahead, it could be because you don't know the right people. How many people do you know who got a lucky break because of a friend or relative? If you knew the right people, you would have access to venture capital, Internet resources, expert advice, and business secrets that others don't have. We have a simple web site that automatically locates successful people and makes friends for you. There's zero cost, and you don't have to do any work. Just answer a couple of questions, and then sit back while the system does all the work. We're so excited about our system that we will give you a chance to win a free computer just for trying it. Just for trying the system, you will be entered in a drawing to win a Gateway or Macintosh computer. Our system is free for a limited time. Use this link today to take advantage of this offer. http://216.233.48.249/dev/ You are receiving this email because either you, or someone representing you, has subscribed this email address. If you feel that this was done in error, or would like to be removed from our list, you can easily be removed at this url. http://216.233.48.249/dev/remove.html Or if it is more convenient. Email marketstarter@lycos.com Ensure REMOVE is in subject. From list@netscape.com Sun Oct 8 09:56: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 JAA09374 for ; Sun, 8 Oct 2000 09:56:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e98Dm6I10479; Sun, 8 Oct 2000 06:48:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e98DsqE23043; Sun, 8 Oct 2000 06:54:52 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 06:54:52 -0700 (PDT) Date: Sun, 8 Oct 2000 06:54:36 -0700 (PDT) From: John Brown <6756ty@hotmail.com> To: Message-Id: <419.436807.993296996756ty@hotmail.com> Subject: EARN $100,000 PER YEAR SENDING E-MAIL !!! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"rCqaAB.A.jnF.qyH45"@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 Work from home selling reports online, and achieve financial security! You can earn $50,000 or more in next the 90 day s sending e-mail, Seem impossible? Read on for details; is there a catch; NO, there is no catch, just send your emails and be on your way to financial freedom. 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 progr am 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. 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. The program ==================================================== This opportunity can be started with VERY LITTLE investment and the income return is staggering!!! THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people 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. 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 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 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several 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 net work 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. 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. It cost me about $15 for my time on-line. I do not 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. In less than one week, I was starting to receive orders for REPORT #1. A few weeks later, I had received 26 orders for REPORT #1. You must receive at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS, and at least 100 orders for report #2. If this does not happen, send out more emails. If you achieve this, then you can now relax and watch the orders magnify themselves. Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. I received $58,000 with more coming in every day. after this . I paid off ALL my debts and bought a much needed new car. THIS 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 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 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. Now I have several offices that make this and several other programs here and over seas. Follow the program EXACTLY AS INSTRUCTED. D o 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 UP TO YOU NOW! ************************************************************ INSTRUCTIONS: 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: * Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, YOUR NAME & RETURN ADDRESS (in case of a problem) and 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. * 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. * Look below for the listing of available reports. * After you've ordered the four reports, take this Advertisement 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! * Move the name and address under REPORT #3 down to REPORT #4. * Move the name and address under REPORT #2 down to REPORT #3. * Move the name and address under REPORT #1 down to REPORT #2. * Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 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 $20). You obviously already have an Internet Connection and e-mail is FREE! To assist you with marketing your business on the internet, the 4 reports you purchase will provide you with invaluable marketing information 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 information on Internet Marketing Clubs. This club specializes in providing 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.5% 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.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000+ $50,000 for a total of $55,550!!! REMEMBER, THIS IS ASSUMING 1,990 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! 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 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 mems from those 10 ($5 x 100).......$500 3rd level-10 mems from those 100 ($5 x 1,000) $5,000 4th level-10 mems from those 1,000 ($5 x 10k) $50,000 THIS TOTALS ---------------------------$55,550 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! Most people 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 (U.S. CURRENCY) FOR EACH REPORT CHEQUES 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 " Create your own Internet MLM Empire " If you're involved in multi-level marketing, the Internet is the most powerful tool at your fingertips.for building your downline. MLM is destined to make hundreds of individual entrepreneurs incredibly rich. ORDER REPORT #1 FROM: P.O Box 162 Ferny Hills Delivery Centre 4055 QLD Australia ______________________________________________________ REPORT #2 " The Authoritative E-Business Guide" An authoritative and informative e-book in its own right - You could resell just this book and make your money back. It is packed with powerful and useful information. ORDER REPORT #2 FROM: D Buch P.O.Box 712, Cresta, 2118, South Africa ______________________________________________________ REPORT #3 "A treasure chest Mail Order reports" This e-book contains a multitude of reports on Mail order and how to make mail order into a successful and profitable business. ORDER REPORT #3 FROM: J Engel P.O.Box 100 Saxonwold 2132 South Africa ______________________________________________________ REPORT #4 " Create and Publish information products The bottom line is simply that everybody in the world wants to know how they can get rich - without putting too much of an investement in either money, time, or effort....Learn everything about creating and publishing info products and how to collect the *big bucks* for little effort, time, or investment. ORDER REPORT #4 FROM: P Thomas 4 Jacana Lane Zeekoevlei 7945 Cape Town South Africa 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 r eceive 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 $20 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. TO HAVE YOUR EMAIL ADDRESS REMOVED We comply with all existing and pending state and federal laws governing the sending of commercial email. We provide you with a very easy method of having your email address removed. Simply reply to this message and place the single word REMOVE in the subject line and it will come back to us as a remove request. YOU MUST HAVE THE WORD REMOVE IN THE MESSAGE SUBJECT LINE OR OUR SOFTWARE WILL NOT RECOGNIZE IT AS A REMOVE REQUEST! This will prevent our software from sending any future commercial email messages to that email address. From list@netscape.com Sun Oct 8 18:43:12 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11816 for ; Sun, 8 Oct 2000 18:43: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 e98MUNJ17258; Sun, 8 Oct 2000 15:30:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e98MfXo21411; Sun, 8 Oct 2000 15:41:33 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 15:41:33 -0700 (PDT) Date: Sun, 8 Oct 2000 15:41:13 -0700 (PDT) Message-Id: <200010082241.e98Mf2305937@ywing.netscape.com> From: "jmeister" To: Dear.Entrepreneurs.QFPH@netscape.com Subject: adv -SFUP X-Reply-To: jb@futuregate.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jrt-VD.A.ROF.bgP45"@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 Entrepreneur, 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 T.V." 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 TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 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 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 multi-level e-mail order 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 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- BILLIONAIRE, 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 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 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 $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 $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 P.S. Do you have any idea what 11,700 $5 bills ($58,000) look 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, 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). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the five reports. You will need all five 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 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 and 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 INF0MATION 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 FRIEND, 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 THIS EQUALS----------------------------------------------$ 46,650 Remember friends, 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 (U.S. CURRENCY) FOR EACH REPORT CHEQUES NOT BE 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 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Jerald Hofmeister 3903 Woodglade Cove Winter Park, Fl. 32792 ______________________________________________________ REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Fred Simmonds 317 Oakhurst St. Altamonte Springs, Fl. 32701 ______________________________________________________ REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Ed Trupin 1577 C.R. 236 Clyde, Ohio 43410 ______________________________________________________ REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: David Jonsson Postbus 28 9600 AA Hoogezand, Netherlands ______________________________________________________ REPORT #5 "How to SEND 1,000,000 e-mails for FREE" B Hofmeister 3903 Woodglade Cove Winter Park, Fl. 32792 ______________________________________________________ There currently more than 175,000,000 people online 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 From list@netscape.com Sun Oct 8 18:54:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11882 for ; Sun, 8 Oct 2000 18:54: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 e98MfsJ18106; Sun, 8 Oct 2000 15:41:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e98Mr3g24205; Sun, 8 Oct 2000 15:53:03 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 15:53:03 -0700 (PDT) Date: Sun, 8 Oct 2000 22:47:42 GMT From: rsb@docsj.de Message-Id: <200010082247.WAA16473@www.sinet.net.cn> To: rsb@docsj.de Subject: At last, HERBAL V the all natural alternative! Resent-Message-ID: <"6FGFvD.A.75F.NrP45"@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 Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From list@netscape.com Sun Oct 8 19:18:44 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 TAA11994 for ; Sun, 8 Oct 2000 19:18: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 e98N5qJ19553; Sun, 8 Oct 2000 16:05:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e98NH2229425; Sun, 8 Oct 2000 16:17:02 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 16:17:02 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" Cc: Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Mon, 9 Oct 2000 10:15:49 +1100 Message-ID: <001001c0317d$b3073180$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 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Resent-Message-ID: <"XC6kAB.A.fLH.tBQ45"@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 Jim, I can't find anything in X.500 that clarifies whether attribute subtyping applies when evaluating access controls. Our implementation ignores subtyping when making access control decisions. It seems the safer choice. Regards, Steven -----Original Message----- From: Jim Sermersheim [mailto:JIMSE@novell.com] Sent: Tuesday, 3 October 2000 9:40 To: prasanta@netscape.com; Kurt@OpenLDAP.org Cc: ietf-ldapext@netscape.com; hahnt@us.ibm.com Subject: Re: Considering Attribute Subtypes during ACL evaluation I agree for the exact same reason optional support of attr subtyping). It would also be interesting to hear from the X.500 community on how this is handled by different vendors. I found the whole thing unspecified. Jim >>> "Kurt D. Zeilenga" 9/30/00 12:59:03 PM >>> 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 Sun Oct 8 20:34: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 UAA12439 for ; Sun, 8 Oct 2000 20:34: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 e990QII09765; Sun, 8 Oct 2000 17:26:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e990X4c13608; Sun, 8 Oct 2000 17:33:04 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 17:33:04 -0700 (PDT) From: bubblehead32@hotmail.com Message-Id: <200010090032.UAA09300@mail3.mia.bellsouth.net> To: <> Subject: WOW!!! Highest Payouts Around!!!!!!!! Date: Sun, 08 Oct 2000 20:16:55 -0400 X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"T7rlmB.A.WUD._IR45"@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 Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove From list@netscape.com Sun Oct 8 21:02: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 VAA12611 for ; Sun, 8 Oct 2000 21:02: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 e990sOI11203; Sun, 8 Oct 2000 17:54:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9911Ao19011; Sun, 8 Oct 2000 18:01:10 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 18:01:10 -0700 (PDT) Message-Id: <5.0.0.25.0.20001008175145.00a4deb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 08 Oct 2000 18:00:24 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: Considering Attribute Subtypes during ACL evaluation Cc: "'Jim Sermersheim'" , In-Reply-To: <001001c0317d$b3073180$b05508cb@osmium.adacel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"IJG_SD.A.xoE.VjR45"@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 10:15 AM 10/9/00 +1100, Steven Legg wrote: >I can't find anything in X.500 that clarifies whether attribute subtyping >applies when evaluating access controls. Our implementation ignores >subtyping when making access control decisions. What does it do for language tags and ;binary? These are forms of subtyping as well. >It seems the safer choice. X.500 doesn't have attribute type options, so direct comparisons are invalid. With the advent of LDAP attribute type options, in particular, language tags and ;binary, I believe it very important for that an ACI for "cn" apply not only to "cn" but "cn;lang-en" and "cn;binary". I would argue it best that if atribute type option subtyping is supported, then traditional X.500 subtyping should be supported as well (or at least allowed). Kurt From list@netscape.com Sun Oct 8 21:23:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12704 for ; Sun, 8 Oct 2000 21:23: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 e991AqJ26012; Sun, 8 Oct 2000 18:10:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e991M3g23564; Sun, 8 Oct 2000 18:22:03 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 18:22:03 -0700 (PDT) Message-Id: <200010090122.e991Lt315997@ywing.netscape.com> Date: Sun, 08 Oct 00 19:29:40 EST From: HomeLoans@s88s.fsnet.co.uk To: ietf-ldapext@netscape.com Subject: Attention: Homeowners & Soon To Be Homeowners Resent-Message-ID: <"QuOQRB.A.6vF.62R45"@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 ietf-ldapext@netscape.com, Hit reply to be removed. Homeowners, let the power of the internet work for you. Fill in our quick loan request form and you will get competitive mortgage quotes from 3 of over 150 lenders signed up for our service. When lenders compete you win. Cash back refinances No Equity 2nd Trust Deeds Debt Consolidation No Income Verification The most competitive interest rates! Lenders are standing by, ready to approve your loan today! They will contact you, often minutes after filling in the form or when it's best for you. Visit this site: http://angelfire.com-ns:homeloans@216.49.97.4/mortgageloans/?SP1008 (If web site doesn't come right up, please try back later) -Save Time -Save Money -Save Aggravation There is NEVER any fee to consumers for using this service. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Copyright © 1999, 2000 eWorld Marketing, Inc. 1-888-418-2575. This is not a solicitation or offer to lend money. eWorld Marketing is not a lender, broker or other financial intermediary. We provide marketing services to the mortgage industry. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From list@netscape.com Sun Oct 8 23:45: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 XAA15719 for ; Sun, 8 Oct 2000 23:44: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 e993WIJ02882; Sun, 8 Oct 2000 20:32:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e993hTQ19258; Sun, 8 Oct 2000 20:43:29 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 20:43:29 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Mon, 9 Oct 2000 14:42:30 +1100 Message-ID: <001701c031a2$f463fb70$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 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <5.0.0.25.0.20001008175145.00a4deb0@router.boolean.net> Resent-Message-ID: <"1Q1o9C.A.gsE.g7T45"@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, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, 9 October 2000 12:00 > To: steven.legg@adacel.com.au > Cc: 'Jim Sermersheim'; ietf-ldapext@netscape.com > Subject: RE: Considering Attribute Subtypes during ACL evaluation > > > At 10:15 AM 10/9/00 +1100, Steven Legg wrote: > >I can't find anything in X.500 that clarifies whether > attribute subtyping > >applies when evaluating access controls. Our implementation ignores > >subtyping when making access control decisions. > > What does it do for language tags and ;binary? These are forms > of subtyping as well. We have to be able to shuffle attribute types with language tags through DSP somehow, so we define attribute types with language tags as formal attribute subtypes in the X.500 sense (we don't support contexts). Obviously that means we are restricted to single inheritance. The access control decision function ignores subtyping so access controls on cn don't apply to cn;lang-en. We treat the ;binary option as a transfer encoding specifier, rather than as a subtype. It only determines how the attributes values are encoded to go out or come in. The bulk of the server code cares nothing about ;binary. The access control decision function, in particular, will appear to apply access controls on cn to cn;binary as well. > > >It seems the safer choice. > > X.500 doesn't have attribute type options, so direct comparisons > are invalid. I wouldn't say that. The question is whether LDAP access controls on a supertype should apply to the subtype. We are not prevented from looking elsewhere for inspiration. Whether X.500 access control does or doesn't support subtyping is still a worthwhile question, even though the answer does not constrain LDAP access control in any way because we are talking about an unrelated access control scheme. > With the advent of LDAP attribute type options, in > particular, language tags and ;binary, I believe it very important > for that an ACI for "cn" apply not only to "cn" but "cn;lang-en" > and "cn;binary". I would argue it best that if atribute type > option subtyping is supported, then traditional X.500 subtyping > should be supported as well (or at least allowed). The concern with this sort of inheritance is that the access controls may later apply to things that the access control creator was not aware of at the time of creation. If there is no inheritance there can be no surprises. By the way, I'm not strongly for or against such inheritance. > > Kurt > > Regards, Steven From list@netscape.com Mon Oct 9 00:30: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 AAA16051 for ; Mon, 9 Oct 2000 00:30: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 e994HRJ05370; Sun, 8 Oct 2000 21:17:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e994Sck27752; Sun, 8 Oct 2000 21:28:38 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 21:28:38 -0700 (PDT) Message-ID: <39E14A2B.C31480AE@worldspot.com> Date: Sun, 08 Oct 2000 21:31:39 -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: Java LDAP API issues summary - round 2 References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com> <39D023AE.6D038D1D@worldspot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TeoPwC.A.WxG.1lU45"@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 an attempt to summarize all issues discussed since my summary to the list on 9/24 this year. Rob 1. LDAPConnection.setOption/LDAPConnection.getOption I think Steve proposed eliminating it (since its functionality can be expressed with LDAPConstraints.setSearchConstraints). The only problem I have with that is that we distinguish between objects sharing the same physical connection (ones created with LDAPConnection.clone) and each having its own configuration, on the one hand, and configuration settings which globally affect all such objects on the other hand. All the settings in LDAPConstraints and LDAPSearchConstraints are private to each object, while some of the settings in setOption are global. Including global settings in LDAPConstraints and LDAPSearchConstraints may be confusing for a programmer using this API. 2. Getting the protocol level of the connection If we keep LDAPConnection.getOption, it should be there (since it is global to the physical connection); that is how it is implemented in the Mozilla SDK. If we eliminate LDAPConnection.getOption and include global settings in the constraints object, then the protocol level accessor will need to be moved to LDAPConstraints. 3. LDAPSearchResultReference.getURLs() -> LDAPSearchResultReference.getReferrals() Also, it returns an array of String, not an array of LDAPUrl. 4. Add overloaded bind method to LDAPBind: LDAPConnection bind( String ldapurl, LDAPConnection origConn ); 5. LDAPSearchListener and LDAPResponseListener implement a new interface: LDAPListener, with methods getMessageIDs(), getResponse(), isResponseReceived(), and merge(). 6. Add overloaded LDAPConnection.abandon signature which takes an LDAPConstraints argument (to allow passing a control) 7. Add method to LDAPConnection to get the properties Hashtable (if any) that was used on a SASL bind 8. Change wording in 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". 9. Clarification in 4.3.8: removing "cn" from and LDAPAttributeSet does not remove "cn;lang-en". 10. LDAPSearchListener Add methods isResponseReceived() and isComplete( int msgid ). 11. LDAPMessage Add method getResponse( int msgid ) 12. Names of constants for LDAP result codes Indicate the mapping to ASN.1 names in RFC 2251 13. 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 14. LDAPConstraints.setHopLimit Clarify that 0 means no limit 15. Typos in constant values LDAPConnection.DEREF_SEARCHING should be 1, LDAPConnection.DEREF_FINDING should be 2 From list@netscape.com Mon Oct 9 00:43: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 AAA16116 for ; Mon, 9 Oct 2000 00:43: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 e994UVJ06393; Sun, 8 Oct 2000 21:30:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e994fhk01194; Sun, 8 Oct 2000 21:41:43 -0700 (PDT) Resent-Date: Sun, 8 Oct 2000 21:41:43 -0700 (PDT) Message-Id: <5.0.0.25.0.20001008213021.00a50c80@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 08 Oct 2000 21:40:51 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: Considering Attribute Subtypes during ACL evaluation Cc: In-Reply-To: <001701c031a2$f463fb70$b05508cb@osmium.adacel.com.au> References: <5.0.0.25.0.20001008175145.00a4deb0@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"IW14xD.A.YS.GyU45"@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:42 PM 10/9/00 +1100, Steven Legg wrote: >The concern with this sort of inheritance is that the access controls >may later apply to things that the access control creator was not >aware of at the time of creation. AND could not be aware of... (e.g. arbitrary language tags) >If there is no inheritance there >can be no surprises. And no way for clients to specify language tags which are not explicitly allowed by access controls. >By the way, I'm not strongly for or against >such inheritance. I guess I'm strong in favor of allowing an attribute type description to be controlled by an ACI granting access to the attribute type. Without out such, managing access to language tags is a real pain. Beyond that, my feelings are less strong... Kurt From list@netscape.com Mon Oct 9 03:15: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 DAA29311 for ; Mon, 9 Oct 2000 03:15: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 e9976qI01522; Mon, 9 Oct 2000 00:06:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e997DdA27954; Mon, 9 Oct 2000 00:13:39 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 00:13:39 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer goliath.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'steven.legg@adacel.com.au'" , "'Jim Sermersheim'" Cc: ietf-ldapext@netscape.com Subject: RE: Considering Attribute Subtypes during ACL evaluation Date: Mon, 9 Oct 2000 09:13:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"PP1CjD.A.a0G.iAX45"@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 agree with Steven Helmut > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Montag, 9. Oktober 2000 01:16 > To: 'Jim Sermersheim' > Cc: ietf-ldapext@netscape.com > Subject: RE: Considering Attribute Subtypes during ACL evaluation > > > > Jim, > > I can't find anything in X.500 that clarifies whether > attribute subtyping > applies when evaluating access controls. Our implementation ignores > subtyping when making access control decisions. It seems the safer > choice. > > Regards, > Steven > > -----Original Message----- > From: Jim Sermersheim [mailto:JIMSE@novell.com] > Sent: Tuesday, 3 October 2000 9:40 > To: prasanta@netscape.com; Kurt@OpenLDAP.org > Cc: ietf-ldapext@netscape.com; hahnt@us.ibm.com > Subject: Re: Considering Attribute Subtypes during ACL evaluation > > > I agree for the exact same reason optional support of attr > subtyping). It > would also be interesting to hear from the X.500 community on > how this is > handled by different vendors. I found the whole thing unspecified. > > Jim > > > >>> "Kurt D. Zeilenga" 9/30/00 12:59:03 PM >>> > 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 Mon Oct 9 09:10: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 JAA03404 for ; Mon, 9 Oct 2000 09:10: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 e99D2BI24014; Mon, 9 Oct 2000 06:02:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99D8wk16644; Mon, 9 Oct 2000 06:08:58 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 06:08:58 -0700 (PDT) From: cashgrants3@bigfoot.com Date: Mon, 09 Oct 00 07:09:20 EST To: cashgrats30@bigfoot.com Subject: CASH FREE GRANTS Message-ID: <> Resent-Message-ID: <"eKpdE.A.yDE.pNc45"@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 Consumer Every day millions of dollars are given away!!! Our Government spends billions of tax dollars on government grants. Do you know that private foundations, trust and corporations are required to give away a portion of their assets. It does'nt matter, where you live, your employment status, or if you are broke, retired or living on a fixed income. There may be a grant for you! CASHING IN ON FREE GOVERNMENT GRANTS FOR PERSONAL NEEDS, BUSINESS, MEDICAL BILLS, EDUCATION, DEBTS AND MORE.... How would you like to get $125.000.00 to start your business? You can use the money to expand, finance equipment, pay salaries, rent and more. How about $8,000.00 spending money for your personal needs such as car payments, rent, clothing, credit card debts, home repair, groceries. Do you need $12,000.00 for education for yourself, or your children? You can get money for private, secondary and primary school. There are grants for undergraduate, graduate, professional and foreign studies and more. THE BEST PART IS THAT YOU NEVER HAVE TO PAY IT BACK! IT IS INTEREST FREE AND NON TAXABLE! NO CREDIT CHECKS, COSIGNERS, SECURITY DEPOSITS OR COLLATERAL REQUIRED. There are no strict requirements to meet. If you have a genuine need, the money can be yours. IT'S TIME FOR YOU TO TAKE ADVANTAGE OF THIS COUNTRY'S BEST KEPT SECRET! We have made the process easy. We have researched and compiled a manual that will help you find a grant. OUR MANUAL" HOW TO OBTAIN FREE CASH GRANTS" will provide you with 45 pages of grant sources. We list the foundations name, address, phone number, contact person and the type of grant they issue. QUESTIONS AND ANSWERS Q: Is obtaining a cash grant legal? A: It is 100% legal and yours for the asking. The Government wants you to take advantage of their grant program and our manual will show you how. Q: How do I get paid? A: The Government agency will send you an acceptance letter with your award amount. Q: Will bad credit interfere with obtaining a free cash grant? A: NO, In fact grants are not based on your credit. It is not a loan, even the unemployed receive grants. Q: What is the average grant amount awarded? A: $1,000.00 to 10,000.00 is average, but it depends on what the grant will be used for. Businesses that benefit the communities have been awarded $100,000 to millions in grant money. Q: If I obtain your publication manual, am I guaranteed to find a grant? A: The US Federal Trade Commission warns consumers that no one can guarantee you a grant, you must apply to the grant offering foundations, corporations etc.. They will review your request and supply your grant if your needs meet the requirements of the grant. We do provide you with a 60 day money back guarantee! This will give you time to apply for some grants and get a response. ACT IN THE NEXT 14 DAYS AND RECEIVE THE "HOW TO OBTAIN FREE CASH GRANT'S "MANUAL AND A FREE BONUS, "HOW TO WRITE A WINNING GRANT PROPOSAL". This guide will list the secrets on getting your grant proposal accepted. RECEIVE ALL THIS FOR THE UNBELIEVABLE LOW PRICE OF $24.95! ACT NOW!! ORDER INFORMATION SIMPLY SEND $24.95, CHECK, MONEY ORDER, OR CREDIT CARD INFORMATION INCLUDE YOUR NAME, ACCOUNT NUMBER, EXPIRATION DATE, ADDRESS AND PHONE NUMBER. TO: INFORMATION PLUS PO BOX 9889 PANAMA CITY BEACH, FL 32417 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! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of the new millennium! To be removed francis@dcemail.com From list@netscape.com Mon Oct 9 11:53: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 LAA05775 for ; Mon, 9 Oct 2000 11:53: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 e99FhkI14321; Mon, 9 Oct 2000 08:43:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99FoXc16489; Mon, 9 Oct 2000 08:50:33 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 08:50:33 -0700 (PDT) Sender: Mark.Wahl@Central.Sun.COM Message-ID: <39E1E961.EDF212B@sun.com> Date: Mon, 09 Oct 2000 10:50:57 -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: sanjay jain CC: ldapext Subject: Re: a question regarding qdstring defn in RFC 2252 References: <39DE5760.B1FA298E@software.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SUjsNB.A.4AE.Hle45"@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 RFC 2252 section 4.3: In encodings where an arbitrary string, not a Distinguished Name, is used as part of a larger production, and other than as part of a Distinguished Name, a backslash quoting mechanism is used to escape the following separator symbol character (such as "'", "$" or "#") if it should occur in that string. The backslash is followed by a pair of hexadecimal digits representing the next character. A backslash itself in the string which forms part of a larger syntax is always transmitted as '\5C' or '\5c'. An example is given in section 6.27. Mark Wahl Sun Microsystems, Inc. From list@netscape.com Mon Oct 9 12:23:12 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06192 for ; Mon, 9 Oct 2000 12:23: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 e99G8OJ27820; Mon, 9 Oct 2000 09:08:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99GJZA18428; Mon, 9 Oct 2000 09:19:35 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 09:19:35 -0700 (PDT) From: "Ryan Moats" To: , Subject: New draft: ldapext-ldap-taxonomy-04 Date: Mon, 9 Oct 2000 11:22:10 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Resent-Message-ID: <"ydMpI.A._dE.VAf45"@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 replace draft-ietf-ldapext-ldap-taxonomy-03 with the following. LDAPEXT folks: The following is a republication of the taxonomy draft. The only changes from -03 are in the References section. We've cleaned up all external dangling references. The only dangling references left are to LDAPEXT work items. Therefore, there is no need to recycle at working group last call. Now, if only the LDAPEXT work items that this is dependent on would get finished :-) Ryan ==========new draft Internet-Draft Ryan Moats draft-ietf-ldapext-ldap-taxonomy-04 Coreon, Inc. Expires in six months Roland Hedberg Track: Informational Catalogix October 2000 A Taxonomy of Methods for LDAP Clients Finding Servers Filename: draft-ietf-ldapext-ldap-taxonomy-04.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 4/30/2001 [Page 1] INTERNET DRAFT LDAP Taxonomy October 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 4/30/2001 [Page 2] INTERNET DRAFT LDAP Taxonomy October 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 4/30/2001 [Page 3] INTERNET DRAFT LDAP Taxonomy October 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," SVRLOC Template http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/ naming-directory_ldap.1.0.en [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)," http:// www.catalogix.se/doc/draft-hedberg-alvestrad-ndd-01.txt [11] R. Hedberg, L. Daigle, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," Internet Draft (work in progress), February 2000. Expires 4/30/2001 [Page 4] INTERNET DRAFT LDAP Taxonomy October 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 4/30/2001 [Page 5] From list@netscape.com Mon Oct 9 13:06:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06923 for ; Mon, 9 Oct 2000 13:06: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 e99GriJ05907; Mon, 9 Oct 2000 09:53:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99H4vU13674; Mon, 9 Oct 2000 10:04:57 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 10:04:57 -0700 (PDT) Message-Id: <002b01c03212$d4d71740$2f56b381@udev.cdc.com> From: "David Cahlander" To: "Mark Wahl" , "sanjay jain" Cc: "ldapext" References: <39DE5760.B1FA298E@software.com> <39E1E961.EDF212B@sun.com> Subject: Re: a question regarding qdstring defn in RFC 2252 Date: Mon, 9 Oct 2000 12:03:21 -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: <"mNDQj.A.YVD.4qf45"@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 wording of this section is really a problem. I am at a loss to understand what: the following separator symbol character (such as "'", "$" or "#") means. How can you specify "the following separator symbol character" and then give an example of the characters. Specific questions are: 1. What is the treatment of \xx when the input is not part of a production, and xx are hex digits? My guess is that the characters are treated as actual characters and \xx is returned on a read (search) function. 2. If the LDAP input is a production, the standard can be interpreted two ways. 2.1 In a production, the backslash quoting mechanism is always recognized. A Distinguished Name, in a production, uses the quote mechanism described for a DN as well as the \xx mechanism. 2.2 In a production, the backslash quoting mechanism is recognized only for characters that separate fields of the specific production. A Distinguished Name, in a production, uses the quote mechanism described for a DN as well as the \xx mechanism. Is \xx always interpreted as a hex representation of a character in a production? 3. With nested productions, as are used in some X500 syntaxes, when are the \xx fields converted to the characters? --- David Cahlander David.A.Cahlander@syntegra.com 651-415-3171 ----- Original Message ----- From: Mark Wahl To: sanjay jain Cc: ldapext Sent: Monday, October 09, 2000 10:50 AM Subject: Re: a question regarding qdstring defn in RFC 2252 | | RFC 2252 section 4.3: | | In encodings where an arbitrary string, not a Distinguished Name, is | used as part of a larger production, and other than as part of a | Distinguished Name, a backslash quoting mechanism is used to escape | the following separator symbol character (such as "'", "$" or "#") if | it should occur in that string. The backslash is followed by a pair | of hexadecimal digits representing the next character. A backslash | itself in the string which forms part of a larger syntax is always | transmitted as '\5C' or '\5c'. An example is given in section 6.27. | | Mark Wahl | Sun Microsystems, Inc. | | From list@netscape.com Mon Oct 9 13:14: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 NAA07077 for ; Mon, 9 Oct 2000 13:14: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 e99H1MJ07703; Mon, 9 Oct 2000 10:01:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99HCZo19157; Mon, 9 Oct 2000 10:12:35 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 10:12:35 -0700 (PDT) Message-ID: <39E1FB78.37F27BB9@software.com> Date: Mon, 09 Oct 2000 10:08: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: Prasanta Behera , hahnt@us.ibm.com, ietf-ldapext@netscape.com Subject: Re: what's optional in LDAP V3... References: <5.0.0.25.0.20000930114328.00a66910@router.boolean.net> <5.0.0.25.0.20001006160742.00a437a0@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0L68BB.A.qqE.Byf45"@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: > At 03:00 PM 10/6/00 -0700, sanjay jain wrote: > > >"Kurt D. Zeilenga" wrote: > > > >[snip] > > > >> However, given that subtyping is optional in LDAPv3, > > > >Kurt > > Could you please point to the text in RFC 2251 (or > > any other LDAP RFC) which explicitly states that > > subtyping is optional in LDAPv3. I just want to confirm. > > I believe it's implicit in the following statements: > > 3.2.2: > Servers which follow X.500(93) models SHOULD implement subschema > using the X.500 subschema mechanisms, and so these subschemas are not > ordinary entries. LDAP clients SHOULD NOT assume that servers > implement any of the other aspects of X.500 subschema. > > The first sentence implies that servers may not follow X.500(93). > > 3.3: > LDAP can be mapped onto any > other directory system so long as the X.500 data and service model as > used in LDAP is not violated in the LDAP interface. > > The interface is not violated if subtyping is not supported. IMO, its very hard to interpret based on above info that subtyping is optional in LDAP V3. Looks like if an LDAP client sends a search request with filter (name=xyz) and gets back objects which satisfy exactly this filter then it is not easy for the client to know whether the server does not support subtypes or there are no objects (in same scope etc..) which satisfy (cn=xyz) or (sn=xyz) types of filters. From list@netscape.com Mon Oct 9 13:31: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 NAA07348 for ; Mon, 9 Oct 2000 13:31: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 e99HMLI05370; Mon, 9 Oct 2000 10:22:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99HT8o28220; Mon, 9 Oct 2000 10:29:08 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 10:29:08 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 09 Oct 2000 11:28:37 -0600 From: "Jim Sermersheim" To: , Subject: Re: what are the server guys doing? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_E1B93752.5938464B" Resent-Message-ID: <"Bl7i4.A.j4G.iBg45"@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. --=_E1B93752.5938464B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable What we're planning on doing, and what we're doing right now may be two = different things. BTW, we're largely market-dirven, as I would imagine = most directory vendors are. That might account for server vendors = implementing technology that is needed before technology that is cool. = Language tags are a highly requested technology outside the U.S. >>> Bruce Greenblatt 10/6/00 = 5:29:45 PM >>> OK. I got the response that I expected. LDAP Server vendors are not = planning on implementing any new extensions. Other than this language tag = thing (which I see virtually no use for), what is going on is nothing.=20 Bruce At 04:54 PM 10/2/2000, Jim Sermersheim wrote: Bruce, =20 The problem is, when one tries to implement language tags (an RFC of the = ldapext WG) on the server, they run into all sorts of unanswered questions = and underspecified, or even conflicting requirements. I don't think the = goal is to specifically implement support for an entry with numerous = subtypes within a single attribute. I think people are just trying to = implement language tags in a correct and consistent manner. =20 Though we'd like to implement many of the drafts listed below, we feel = more urgency to implement language tags now. We don't want to just throw a = solution together and get onto the next extension before we feel assured = of interoperability. =20 Jim >>> Bruce Greenblatt 10/2/00 = 5:04:42 PM >>> I'm sitting here watching the discussion on attribute sub-typing, and=20 trying (without any success) to figure when I'd ever need an entry that = had=20 numerous subtypes within a single attribute. Can someone give me a = good=20 example of when a single LDAP entry would need one attribute with lots = of=20 subtypes present? It seems to me that this is going in a different=20 direction that I'd like to see. As an LDAP application developer, I'm = more=20 interested in seeing other features added on the server side. I can = make=20 do without the sub-type stuff, but I really need to be able to selectively= =20 delete a sub-tree. Just out of curiosity, I'd be interested in finding out if anyone that=20 builds a server has any plans on supporting any recently defined extensions= =20 (controls or extended operations). For example: LDAP Authentication Response Control (draft) LDAP Proxied Authentication Control (draft) LDAP Controls for Reply Signatures (draft) Returning Matched Values with LDAPv3 (draft) LDAP Control for a Duplicate Entry Representation of Search Results = (draft) LDAP Tree Delete Control (draft) LDAP Client Update Protocol (draft) Simple Operations on Subtrees (for LDAP) (draft) An LDAP Control and Schema for Holding Operation Signatures (RFC 2649) I've probably missed a few that have been defined. I'm very interested = in=20 encouraging extension development. As far as I can tell, there is very=20 little activity in this area, but I'd like to hear differently. I'm=20 expecting deafening silence in response, but am hopefully of hearing = some=20 noise! I'm sure that there would be plenty of interested beta testers... Thanks, Bruce =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 Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories:=20 http://www.phptr.com/ptrbooks/ptr_0139744525.html =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 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=20 --=_E1B93752.5938464B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What we're planning on doing, and what we're doing right now may = be two=20 different things. BTW, we're largely market-dirven, as I would imagine=20 most directory vendors are. That might account for server vendors=20 implementing technology that is needed before technology that is cool. = Language=20 tags are a highly requested technology outside the=20 U.S.

>>> Bruce Greenblatt=20 <bgreenblatt@directory-applications.com> 10/6/00 5:29:45 PM=20 >>>
OK.  I got the response that I expected.  LDAP = Server=20 vendors are not planning on implementing any new extensions.  Other = than=20 this language tag thing (which I see virtually no use for), what is going = on is=20 nothing.

Bruce

At 04:54 PM 10/2/2000, Jim Sermersheim = wrote:

Bruce,
 
The problem is, when = one tries=20 to implement language tags (an RFC of the ldapext WG) on the server, = they run=20 into all sorts of unanswered questions and underspecified, or even = conflicting=20 requirements. I don't think the goal is to specifically implement = support for=20 an entry with numerous subtypes within a single attribute. I think = people are=20 just trying to implement language tags in a correct and consistent=20 manner.
 
Though we'd like to implement = many of=20 the drafts listed below, we feel more urgency to implement language tags = now.=20 We don't want to just throw a solution together and get onto the next=20 extension before we feel assured of=20 interoperability.
 
Jim

>>> Bruce Greenblatt=20 <bgreenblatt@directory-applications.com> 10/2/00 5:04:42 PM=20 >>>
I'm sitting here watching the discussion on attribute=20 sub-typing, and
trying (without any success) to figure when I'd ever = need=20 an entry that had
numerous subtypes within a single attribute.  = Can=20 someone give me a good
example of when a single LDAP entry would = need one=20 attribute with lots of
subtypes present?  It seems to me that = this is=20 going in a different
direction that I'd like to see.  As an = LDAP=20 application developer, I'm more
interested in seeing other features = added=20 on the server side.   I can make
do without the sub-type = stuff,=20 but I really need to be able to selectively
delete a sub-tree.
Just=20 out of curiosity, I'd be interested in finding out if anyone that =
builds a=20 server has any plans on supporting any recently defined extensions=20
(controls or extended operations).  For example:

LDAP=20 Authentication Response Control  (draft)
LDAP Proxied Authenticat= ion=20 Control  (draft)
LDAP Controls for Reply Signatures=20 (draft)
Returning Matched Values with LDAPv3  (draft)
LDAP = Control=20 for a Duplicate Entry Representation of Search Results (draft)
LDAP = Tree=20 Delete Control (draft)
LDAP Client Update Protocol (draft)
Simple= =20 Operations on Subtrees (for LDAP) (draft)
An LDAP Control and Schema = for=20 Holding Operation Signatures (RFC 2649)

I've probably missed a = few that=20 have been defined.  I'm very interested in
encouraging = extension=20 development.  As far as I can tell, there is very
little = activity in=20 this area, but I'd like to hear differently.  I'm
expecting = deafening=20 silence in response, but am hopefully of hearing some
noise!  = I'm=20 sure that there would be plenty of interested beta=20 testers...

Thanks,

Bruce

=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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, = Inc.
http://www.directory-appli= cations.com
See=20 my new Book on Internet Directories:
http://www.php= tr.com/ptrbooks/ptr_0139744525.html

=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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://<= /A>www.directory-applications.com
See my new Book on = Internet=20 Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html

--=_E1B93752.5938464B-- From list@netscape.com Mon Oct 9 13:34: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 NAA07376 for ; Mon, 9 Oct 2000 13:34: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 e99HLoJ12117; Mon, 9 Oct 2000 10:21:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99HX3A00130; Mon, 9 Oct 2000 10:33:03 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 10:33:03 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 09 Oct 2000 11:32:51 -0600 From: "Jim Sermersheim" To: , Cc: , , Subject: Re: Considering Attribute Subtypes during ACL evaluation Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_E4BC3256.43225C50" Resent-Message-ID: <"EzYzGC.A.vB.NFg45"@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. --=_E4BC3256.43225C50 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Also, RFC 2256, Section 5.42 says: "... LDAP server implementations which do not support attribute subtyping = ... Client Implementations MUST NOT assume that LDAP servers are capable = of performing attribute subtyping." >>> "Kurt D. Zeilenga" 10/6/00 5:17:32 PM >>> At 03:00 PM 10/6/00 -0700, sanjay jain wrote: >"Kurt D. Zeilenga" wrote: > >[snip] > >> However, given that subtyping is optional in LDAPv3, > >Kurt > Could you please point to the text in RFC 2251 (or > any other LDAP RFC) which explicitly states that > subtyping is optional in LDAPv3. I just want to confirm. I believe it's implicit in the following statements: 3.2.2: Servers which follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms, and so these subschemas are not ordinary entries. LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema. The first sentence implies that servers may not follow X.500(93). 3.3: LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface. The interface is not violated if subtyping is not supported. --=_E4BC3256.43225C50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Also, RFC 2256, Section 5.42 says:
"... LDAP server implementations which do not = support=20 attribute subtyping ... Client Implementations MUST NOT assume that LDAP = servers=20 are capable of performing attribute subtyping."

>>> = "Kurt=20 D. Zeilenga" <Kurt@OpenLDAP.org> 10/6/00 5:17:32 PM >>>
A= t=20 03:00 PM 10/6/00 -0700, sanjay jain wrote:


>"Kurt D. = Zeilenga"=20 wrote:
>
>[snip]
>
>> However, given that = subtyping=20 is optional in LDAPv3,
>
>Kurt
>   Could you = please=20 point to the text in RFC 2251 (or
>   any other LDAP RFC) = which=20 explicitly states that
>   subtyping is optional in=20 LDAPv3.  I just want to confirm.

I believe it's implicit in = the=20 following statements:

3.2.2:
   Servers which = follow=20 X.500(93) models SHOULD implement subschema
   using the = X.500=20 subschema mechanisms, and so these subschemas are not
   = ordinary=20 entries.  LDAP clients SHOULD NOT assume that servers
  = =20 implement any of the other aspects of X.500 subschema.

The first = sentence=20 implies that servers may not follow X.500(93).

3.3:
   = LDAP=20 can be mapped onto any
   other directory system so long as = the=20 X.500 data and service model as
   used in LDAP is not = violated in=20 the LDAP interface.

The interface is not violated if subtyping is = not=20 supported.

--=_E4BC3256.43225C50-- From list@netscape.com Mon Oct 9 16:04: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 QAA09556 for ; Mon, 9 Oct 2000 16:04: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 e99JpBJ15218; Mon, 9 Oct 2000 12:51:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e99K2MM02872; Mon, 9 Oct 2000 13:02:22 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 13:02:22 -0700 (PDT) Message-ID: <39E22422.1F74EBA3@novell.com> Date: Mon, 09 Oct 2000 14:01:38 -0600 From: Steven Sonntag Organization: Novell, Inc. X-Mailer: Mozilla 4.75 [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 summary - round 2 References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com> <39D023AE.6D038D1D@worldspot.com> <39E14A2B.C31480AE@worldspot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"p67E0C.A.br.KRi45"@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: > This is an attempt to summarize all issues discussed since my summary to the list on 9/24 this year. > > Rob > > 1. LDAPConnection.setOption/LDAPConnection.getOption > > I think Steve proposed eliminating it (since its functionality can be expressed with LDAPConstraints.setSearchConstraints). The only problem I have with that is that we distinguish between objects sharing the same physical connection (ones created with LDAPConnection.clone) and each having its own configuration, on the one hand, and configuration settings which globally affect all such objects on the other hand. All the settings in LDAPConstraints and LDAPSearchConstraints are private to each object, while some of the settings in setOption are global. Including global settings in LDAPConstraints and LDAPSearchConstraints may be confusing for a programmer using this API. > > 2. Getting the protocol level of the connection > > If we keep LDAPConnection.getOption, it should be there (since it is global to the physical connection); that is how it is implemented in the Mozilla SDK. > > If we eliminate LDAPConnection.getOption and include global settings in the constraints object, then the protocol level accessor will need to be moved to LDAPConstraints. > ---snip--- > > > 8. Change wording in 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". > I am not sure from your e-mail what you intend to do here. I do agree that it is confusing to have global data in the constraints object. IMO global data like protocol level or hashTable should NOT be in the constraints object. They should be in data common to all the clones of a connection. Right now LDAPConnections supports separate APIs for setting / getting data that is global to the connection, viz. authenticationMethod authenticationDN authenticationPasswd host port inputStream outputStream property connected bound socketFactory The hashTable and protocol level also belong in this category. Are you suggesting that all options relating to constraints data be removed from the get/getOption API? I agree that is a good idea. Are you suggesting that options relating to global data be retained or added to set/getOption? I am not sure that is a good idea. It means that if the data type passed to setOption is wrong, it would not be caught at compile time, but via a RuntimeException. Personally I would rather see a compile error. On the otherhand, the get/set methods for the above now become an instance of get/setOption, simplifying the API and reducing the number of methods in LDAPConnection, but in its place multiplying variations of LDAPSetOption. Currently level and hashTable are set via the appropriate connect or bind method. This implies that only get methods are needed as the values are effectively read-only or informational after the connect / bind calls are complete. My vote is to add two get methods, one for protocol level, and one for hashTable. These should not be associated with constraints. -Steve From list@netscape.com Mon Oct 9 20:30:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11751 for ; Mon, 9 Oct 2000 20:30: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 e9A0HJJ20488; Mon, 9 Oct 2000 17:17:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9A0SVY28663; Mon, 9 Oct 2000 17:28:31 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 17:28:31 -0700 (PDT) Message-Id: <5.0.0.25.0.20001009170729.00a425a0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 09 Oct 2000 17:27:38 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: what's optional in LDAP V3... Cc: Prasanta Behera , hahnt@us.ibm.com, ietf-ldapext@netscape.com In-Reply-To: <39E1FB78.37F27BB9@software.com> References: <5.0.0.25.0.20000930114328.00a66910@router.boolean.net> <5.0.0.25.0.20001006160742.00a437a0@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"QMMSYD.A.q9G.qKm45"@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 10:08 AM 10/9/00 -0700, sanjay jain wrote: >> 3.2.2: >> 3.3: >> The interface is not violated if subtyping is not supported. > > IMO, its very hard to interpret based on above info that subtyping is > optional in LDAP V3. Jim pointed out that "RFC 2256, Section 5.42" makes an explicit statement in regard to subtyping support being elective. > Looks like if an LDAP client sends a search request with > filter (name=xyz) and gets back objects which satisfy exactly > this filter then it is not easy for the client to know whether the > server does not support subtypes or there are no objects (in same > scope etc..) which satisfy (cn=xyz) or (sn=xyz) types of filters. Feature discovery through trial and error is always problematic. A better mechanism, such as one of those previously proposed on this list, should be formalized. From list@netscape.com Mon Oct 9 21:24:44 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 VAA12256 for ; Mon, 9 Oct 2000 21:24: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 e9A1C0J06276; Mon, 9 Oct 2000 18:12:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9A1NDY20859; Mon, 9 Oct 2000 18:23:13 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 18:23:13 -0700 (PDT) Message-ID: <39E27039.8AF5DE35@worldspot.com> Date: Mon, 09 Oct 2000 18:26:17 -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 summary - round 2 References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com> <39D023AE.6D038D1D@worldspot.com> <39E14A2B.C31480AE@worldspot.com> <39E22422.1F74EBA3@novell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"j6uUcC.A.pFF.A-m45"@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: > > > This is an attempt to summarize all issues discussed since my summary to the list on 9/24 this year. > > > > Rob > > > > 1. LDAPConnection.setOption/LDAPConnection.getOption > > > > I think Steve proposed eliminating it (since its functionality can be expressed with LDAPConstraints.setSearchConstraints). The only problem I have with that is that we distinguish between objects sharing the same physical connection (ones created with LDAPConnection.clone) and each having its own configuration, on the one hand, and configuration settings which globally affect all such objects on the other hand. All the settings in LDAPConstraints and LDAPSearchConstraints are private to each object, while some of the settings in setOption are global. Including global settings in LDAPConstraints and LDAPSearchConstraints may be confusing for a programmer using this API. > > > > 2. Getting the protocol level of the connection > > > > If we keep LDAPConnection.getOption, it should be there (since it is global to the physical connection); that is how it is implemented in the Mozilla SDK. > > > > If we eliminate LDAPConnection.getOption and include global settings in the constraints object, then the protocol level accessor will need to be moved to LDAPConstraints. > > > > ---snip--- > > > > > > > 8. Change wording in 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". > > > > I am not sure from your e-mail what you intend to do here. I do agree that it is confusing to have global > data in the constraints object. IMO global data like protocol level or hashTable should NOT be in the > constraints object. They should be in data common to all the clones of a connection. > > Right now LDAPConnections supports separate APIs for setting / getting data that is global to the connection, viz. > authenticationMethod > authenticationDN > authenticationPasswd > host > port > inputStream > outputStream > property > connected > bound > socketFactory > > The hashTable and protocol level also belong in this category. > > Are you suggesting that all options relating to constraints data be removed from the > get/getOption API? I agree that is a good idea. > > Are you suggesting that options relating to global data be retained or added > to set/getOption? I am not sure that is a good idea. It means that if the data type > passed to setOption is wrong, it would not be caught at compile time, but via > a RuntimeException. Personally I would rather see a compile error. On the > otherhand, the get/set methods for the above now become an instance of get/setOption, > simplifying the API and reducing the number of methods in LDAPConnection, but in > its place multiplying variations of LDAPSetOption. > > Currently level and hashTable are set via the appropriate connect or bind method. This > implies that only get methods are needed as the values are effectively read-only or informational > after the connect / bind calls are complete. > > My vote is to add two get methods, one for protocol level, and one for hashTable. These should > not be associated with constraints. > > -Steve The draft currently defines the following global options for LDAPConnection.setOption: and the following per-instance options: LDAPConnection.DEREF LDAPConnection.SIZELIMIT From list@netscape.com Mon Oct 9 21:32:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12376 for ; Mon, 9 Oct 2000 21:32: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 e9A1JOJ08028; Mon, 9 Oct 2000 18:19:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9A1Ub223226; Mon, 9 Oct 2000 18:30:37 -0700 (PDT) Resent-Date: Mon, 9 Oct 2000 18:30:37 -0700 (PDT) Message-ID: <39E271E9.336B204@worldspot.com> Date: Mon, 09 Oct 2000 18:33:29 -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 summary - round 2 References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com> <39D023AE.6D038D1D@worldspot.com> <39E14A2B.C31480AE@worldspot.com> <39E22422.1F74EBA3@novell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lOnO0D.A.oqF.7En45"@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: > > > This is an attempt to summarize all issues discussed since my summary to the list on 9/24 this year. > > > > Rob > > > > 1. LDAPConnection.setOption/LDAPConnection.getOption > > > > I think Steve proposed eliminating it (since its functionality can be expressed with LDAPConstraints.setSearchConstraints). The only problem I have with that is that we distinguish between objects sharing the same physical connection (ones created with LDAPConnection.clone) and each having its own configuration, on the one hand, and configuration settings which globally affect all such objects on the other hand. All the settings in LDAPConstraints and LDAPSearchConstraints are private to each object, while some of the settings in setOption are global. Including global settings in LDAPConstraints and LDAPSearchConstraints may be confusing for a programmer using this API. > > > > 2. Getting the protocol level of the connection > > > > If we keep LDAPConnection.getOption, it should be there (since it is global to the physical connection); that is how it is implemented in the Mozilla SDK. > > > > If we eliminate LDAPConnection.getOption and include global settings in the constraints object, then the protocol level accessor will need to be moved to LDAPConstraints. > > > > ---snip--- > > > > > > > 8. Change wording in 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". > > > > I am not sure from your e-mail what you intend to do here. I do agree that it is confusing to have global > data in the constraints object. IMO global data like protocol level or hashTable should NOT be in the > constraints object. They should be in data common to all the clones of a connection. > > Right now LDAPConnections supports separate APIs for setting / getting data that is global to the connection, viz. > authenticationMethod > authenticationDN > authenticationPasswd > host > port > inputStream > outputStream > property > connected > bound > socketFactory > > The hashTable and protocol level also belong in this category. > > Are you suggesting that all options relating to constraints data be removed from the > get/getOption API? I agree that is a good idea. > > Are you suggesting that options relating to global data be retained or added > to set/getOption? I am not sure that is a good idea. It means that if the data type > passed to setOption is wrong, it would not be caught at compile time, but via > a RuntimeException. Personally I would rather see a compile error. On the > otherhand, the get/set methods for the above now become an instance of get/setOption, > simplifying the API and reducing the number of methods in LDAPConnection, but in > its place multiplying variations of LDAPSetOption. > > Currently level and hashTable are set via the appropriate connect or bind method. This > implies that only get methods are needed as the values are effectively read-only or informational > after the connect / bind calls are complete. > > My vote is to add two get methods, one for protocol level, and one for hashTable. These should > not be associated with constraints. > > -Steve I guess the draft doesn't define any global options for LDAPConnection.setOption, except for possibly: LDAPConnection.STRING_FORMAT The others are all per-instance options: LDAPConnection.DEREF LDAPConnection.SIZELIMIT LDAPConnection.SERVER_TIMELIMIT LDAPConnection.TIMELIMIT LDAPConnection.REFERRALS LDAPConnection.REFERRALS_REBIND_PROC LDAPConnection.BIND LDAPConnection.REFERRALS_HOP_LIMIT LDAPConnection.BATCHSIZE All the per-instance options can be eliminated immediately in favor of setConstraints/setSearchConstraints. And with nothing left (except possibly STRING_FORMAT), I agree that we can afford to add the two suggested additional methods to get the bound protocol level and the properties Hashtable used on binding. Rob From list@netscape.com Tue Oct 10 05:01: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 FAA29972 for ; Tue, 10 Oct 2000 05:01: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 e9A8rII02899; Tue, 10 Oct 2000 01:53:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9A906w09889; Tue, 10 Oct 2000 02:00:06 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 02:00:06 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 10 Oct 2000 02:59:25 -0600 From: "Puneet Agarwal" To: Subject: Remove Resent-Message-ID: <"4xVujC.A.9ZC.Vqt45"@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 list@netscape.com Tue Oct 10 06:43: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 GAA00831 for ; Tue, 10 Oct 2000 06:43: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 e9AAZCI10153; Tue, 10 Oct 2000 03:35:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9AAfxw04879; Tue, 10 Oct 2000 03:41:59 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 03:41:59 -0700 (PDT) Message-Id: <200010101040.GAA00731@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-04.txt Date: Tue, 10 Oct 2000 06:40:03 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"l1pdKC.A.vKB.0Jv45"@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-04.txt Pages : 5 Date : 09-Oct-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-04.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-04.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-04.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: <20001009132326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-taxonomy-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-taxonomy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001009132326.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Oct 10 12:45: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 MAA08004 for ; Tue, 10 Oct 2000 12:45: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 e9AGb1I16570; Tue, 10 Oct 2000 09:37:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9AGhoI21473; Tue, 10 Oct 2000 09:43:50 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 09:43:50 -0700 (PDT) From: felix323@123india.com Date: Wed, 11 Oct 2000 01:38:55 +0900 Message-Id: <200010101638.BAA23258@iris.ce.hallym.ac.kr> To: ietf-ldapext@netscape.com Subject: Your message to 309,000 OPP SEEKERS! Resent-Message-ID: <"j5HCqC.A.cOF.Cd045"@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 OF: Being shut down by your ISP's, People screaming, People sending you FLAMES, Being bombarded with COUNTER OFFERS, Then let us take over the hassles for you. THERE ISN’T ANOTHER COMPANY IN THE WORLD THAT CAN MAKE YOU A DEAL LIKE THIS! http://secure.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 Tue Oct 10 14:55: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 OAA10677 for ; Tue, 10 Oct 2000 14:55: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 e9AIlUI18851; Tue, 10 Oct 2000 11:47:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9AIoqM10949; Tue, 10 Oct 2000 11:50:52 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 11:50:52 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Tue, 10 Oct 2000 11:44:09 -0700 To: OSI Directory List , IETF LDAP From: "Hoyt L. Kesterson II" Subject: reservations for the orlando meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" Resent-Message-ID: <"mFKsnD.A.zpC.CU245"@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 i have been told that the 800 number i supplied on the announcement now goes to central reservations for wyndham instead of directly to the summerfield suites in orlando. the reservations staff there are not aware of the block of rooms set aside for our meeting at the $99 rate. if you have not already done so please use the +1 407-238-0777 number to make the reservation, ask for in-house reservations, and tell them you are making reservations for the "lockheed martin" meeting. if you already made reservations through the 800 number and did not get the $99 rate, please call the hotel in-house reservations directly. if you still have problems, contact Lisa Barclay in group sales at 407-352-2400 hoyt From list@netscape.com Tue Oct 10 20:55: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 UAA16297 for ; Tue, 10 Oct 2000 20:55: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 e9B0gxJ24217; Tue, 10 Oct 2000 17:43:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9B0sCw24774; Tue, 10 Oct 2000 17:54:12 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 17:54:12 -0700 (PDT) Message-ID: <39E3B90F.45FF2B60@software.com> Date: Tue, 10 Oct 2000 17:49:19 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ldapext Subject: which naming attribute ... Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MD4j4.A.VCG.xo745"@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 which naming attribute can be used to create alias objects ?

thanks From list@netscape.com Tue Oct 10 21:06: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 VAA16375 for ; Tue, 10 Oct 2000 21:06: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 e9B0rwJ25961; Tue, 10 Oct 2000 17:53:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9B15B229640; Tue, 10 Oct 2000 18:05:11 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 18:05:11 -0700 (PDT) Message-Id: <5.0.0.25.0.20001010180328.00a64480@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Oct 2000 18:04:22 -0700 To: sanjay jain , ldapext From: Bruce Greenblatt Subject: Re: which naming attribute ... In-Reply-To: <39E3B90F.45FF2B60@software.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_27741960==_.ALT" Resent-Message-ID: <"WX9ULC.A.2OH.Gz745"@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 --=====================_27741960==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:49 PM 10/10/2000, sanjay jain wrote: >which naming attribute can be used to create alias objects ? > >thanks Seeing as how this is the definition: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName ) I would think that the list of choices would be pretty small (i.e. just aliasedObjectName)... 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 --=====================_27741960==_.ALT Content-Type: text/html; charset="us-ascii" At 05:49 PM 10/10/2000, sanjay jain wrote:

which naming attribute can be used to create alias objects ?

thanks


Seeing as how this is the definition:

   ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )

I would think that the list of choices would be pretty small (i.e. just aliasedObjectName)...

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 --=====================_27741960==_.ALT-- From list@netscape.com Tue Oct 10 22:04: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 WAA17727 for ; Tue, 10 Oct 2000 22:04: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 e9B1uDI14073; Tue, 10 Oct 2000 18:56:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9B231w24188; Tue, 10 Oct 2000 19:03:01 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 19:03:01 -0700 (PDT) Message-Id: <5.0.0.25.0.20001010185531.00a62040@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Oct 2000 19:02:30 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: which naming attribute ... Cc: ldapext In-Reply-To: <39E3B90F.45FF2B60@software.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"z_B3m.A.q5F.Up845"@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:49 PM 10/10/00 -0700, sanjay jain wrote: >which naming attribute can be used to create alias objects ? There is not yet a Standard Track specification for representing aliases in the directory; however, there was an I-D on this subject at one time. In OpenLDAP, we support "named" alias objects (derived from "named" referral object I-Ds). That is, dn: cn=john doe, dc=example, dc=net objectclass: alias objectclass: extensibleObject cn=john doe aliasedObjectName: cn=jane doe, dc=example, dc=net From list@netscape.com Tue Oct 10 22:14: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 WAA17798 for ; Tue, 10 Oct 2000 22:14: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 e9B264I15491; Tue, 10 Oct 2000 19:06:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9B2Cqs29090; Tue, 10 Oct 2000 19:12:52 -0700 (PDT) Resent-Date: Tue, 10 Oct 2000 19:12:52 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'sanjay jain'" , "'ldapext'" Subject: RE: which naming attribute ... Date: Wed, 11 Oct 2000 13:12:00 +1100 Message-ID: <000a01c03328$a49d6220$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 In-Reply-To: <39E3B90F.45FF2B60@software.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Resent-Message-ID: <"6CYv6C.A.PGH.iy845"@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 Sanjay, Any desired naming attribute could be introduced by: (1) subclassing the alias object class, (2) defining an auxiliary object class with the naming attribute and adding the auxiliary class to the alias entry, or (3) putting the naming attribute in a DIT content rule for the alias object class. I lean towards (1). I think there might be implementations that require the naming attribute type of the alias to be the same as the aliased entry's naming attribute. You might want to conform to that. Regards, Steven -----Original Message----- From: sanjay jain [mailto:sanjay.jain@software.com] Sent: Wednesday, 11 October 2000 11:49 To: ldapext Subject: which naming attribute ... which naming attribute can be used to create alias objects ? thanks From list@netscape.com Wed Oct 11 03:07:49 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04034 for ; Wed, 11 Oct 2000 03:07: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 e9B6sjJ11259; Tue, 10 Oct 2000 23:54:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9B760g12332; Wed, 11 Oct 2000 00:06:00 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 00:06:00 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'steven.legg@adacel.com.au'" , "'sanjay jain'" , "'ldapext'" Subject: RE: which naming attribute ... Date: Wed, 11 Oct 2000 09:05:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"NjlMyC.A.aAD.XFB55"@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 Hi I think Bruce gives the correct definition. > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Mittwoch, 11. Oktober 2000 04:12 > To: 'sanjay jain'; 'ldapext' > Subject: RE: which naming attribute ... > > > > Sanjay, > > Any desired naming attribute could be introduced by: > > (1) subclassing the alias object class, why do want subclassing of aliases ? do you want to give an alias additional attributes (e.g. TN or e-mail address ?) > (2) defining an auxiliary object class with the naming attribute and > adding the auxiliary class to the alias entry, or > (3) putting the naming attribute in a DIT content rule for the alias > object class. > > I lean towards (1). > > I think there might be implementations that require the > naming attribute > type of the alias to be the same as the aliased entry's > naming attribute. But this is nowhere described in the standards ? Helmut > You might want to conform to that. > > Regards, > Steven > > -----Original Message----- > From: sanjay jain [mailto:sanjay.jain@software.com] > Sent: Wednesday, 11 October 2000 11:49 > To: ldapext > Subject: which naming attribute ... > > > which naming attribute can be used to create alias objects ? > thanks > From list@netscape.com Wed Oct 11 03:18: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 DAA04102 for ; Wed, 11 Oct 2000 03:18: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 e9B79eI26992; Wed, 11 Oct 2000 00:09:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9B7GTA14756; Wed, 11 Oct 2000 00:16:29 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 00:16:29 -0700 (PDT) Message-ID: <11981F9F5649D411BC92009027D0D18C017418FD@aspams01.cai.com> From: "Ramsay, Ron" To: "Volpers, Helmut" , "'steven.legg@adacel.com.au'" , "'sanjay jain'" , "'ldapext'" Subject: RE: which naming attribute ... Date: Wed, 11 Oct 2000 18:15:26 +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: <"deKNWD.A.PmD.LPB55"@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 believe it is as Steven says. In particular, aliasedObjectName is a DN an not realy suitable for use as an RDN! Ron. -----Original Message----- From: Volpers, Helmut [mailto:helmut.volpers@icn.siemens.de] Sent: Wednesday, 11 October 2000 18:06 To: 'steven.legg@adacel.com.au'; 'sanjay jain'; 'ldapext' Subject: RE: which naming attribute ... Hi I think Bruce gives the correct definition. > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Mittwoch, 11. Oktober 2000 04:12 > To: 'sanjay jain'; 'ldapext' > Subject: RE: which naming attribute ... > > > > Sanjay, > > Any desired naming attribute could be introduced by: > > (1) subclassing the alias object class, why do want subclassing of aliases ? do you want to give an alias additional attributes (e.g. TN or e-mail address ?) > (2) defining an auxiliary object class with the naming attribute and > adding the auxiliary class to the alias entry, or > (3) putting the naming attribute in a DIT content rule for the alias > object class. > > I lean towards (1). > > I think there might be implementations that require the > naming attribute > type of the alias to be the same as the aliased entry's > naming attribute. But this is nowhere described in the standards ? Helmut > You might want to conform to that. > > Regards, > Steven > > -----Original Message----- > From: sanjay jain [mailto:sanjay.jain@software.com] > Sent: Wednesday, 11 October 2000 11:49 > To: ldapext > Subject: which naming attribute ... > > > which naming attribute can be used to create alias objects ? > thanks > From list@netscape.com Wed Oct 11 09:25: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 JAA10063 for ; Wed, 11 Oct 2000 09:25: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 e9BDDtI02909; Wed, 11 Oct 2000 06:14:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BDKjc12599; Wed, 11 Oct 2000 06:20:45 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 06:20:45 -0700 (PDT) Message-ID: <003801c03385$f2655cd0$374aa8c0@ita.sonera.fi> From: "Ismo Heikkonen" To: References: <11981F9F5649D411BC92009027D0D18C017418FD@aspams01.cai.com> Subject: Re: which naming attribute ... Date: Wed, 11 Oct 2000 16:19:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Resent-Message-ID: <"2CDyDB.A.bED.rkG55"@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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 X.501 definition for alias object class is: "alias OBJECT-CLASS ::= { SUBCLASS OF { top } MUST CONTAIN { aliasedEntryName } ID id-oc-alias } NOTE - The object class alias does not specify appropriate attribute types for the RDN of an alias entry. Administrative Authorities may specify subclasses of the class alias which specify useful attribute types for RDNs of alias entries." So this is aligned with Steven's choice number 1, Ismo - ----- Original Message ----- From: To: ; ; ; Sent: Wednesday, October 11, 2000 10:15 AM Subject: RE: which naming attribute ... I believe it is as Steven says. In particular, aliasedObjectName is a DN an not realy suitable for use as an RDN! Ron. - -----Original Message----- From: Volpers, Helmut [mailto:helmut.volpers@icn.siemens.de] Sent: Wednesday, 11 October 2000 18:06 To: 'steven.legg@adacel.com.au'; 'sanjay jain'; 'ldapext' Subject: RE: which naming attribute ... Hi I think Bruce gives the correct definition. > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Mittwoch, 11. Oktober 2000 04:12 > To: 'sanjay jain'; 'ldapext' > Subject: RE: which naming attribute ... > > > > Sanjay, > > Any desired naming attribute could be introduced by: > > (1) subclassing the alias object class, why do want subclassing of aliases ? do you want to give an alias additional attributes (e.g. TN or e-mail address ?) > (2) defining an auxiliary object class with the naming attribute > and > adding the auxiliary class to the alias entry, or > (3) putting the naming attribute in a DIT content rule for the > alias > object class. > > I lean towards (1). > > I think there might be implementations that require the > naming attribute > type of the alias to be the same as the aliased entry's > naming attribute. But this is nowhere described in the standards ? Helmut > You might want to conform to that. > > Regards, > Steven > > -----Original Message----- > From: sanjay jain [mailto:sanjay.jain@software.com] > Sent: Wednesday, 11 October 2000 11:49 > To: ldapext > Subject: which naming attribute ... > > > which naming attribute can be used to create alias objects ? > thanks > -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 Int. iQA/AwUBOeRM2eqdT0kbnEDTEQJ0hgCg1QsT1C5ztfVhI5Gmxs8Pj+imSdUAnjP0 bpZo3h+DcfADTt6Wbw1E52AI =sjdT -----END PGP SIGNATURE----- From list@netscape.com Wed Oct 11 13:06: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 NAA15359 for ; Wed, 11 Oct 2000 13:06: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 e9BGqKJ14604; Wed, 11 Oct 2000 09:52:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BH3Zk14381; Wed, 11 Oct 2000 10:03:35 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 10:03:35 -0700 (PDT) Message-ID: <39E49C3F.8AA9A199@software.com> Date: Wed, 11 Oct 2000 09:58:39 -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: ldapext Subject: Re: which naming attribute ... References: <5.0.0.25.0.20001010185531.00a62040@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9MTaT.A.XgD.m1J55"@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: > At 05:49 PM 10/10/00 -0700, sanjay jain wrote: > >which naming attribute can be used to create alias objects ? > > There is not yet a Standard Track specification for representing > aliases in the directory; You mean 'alias' object class defn in RFC 2256, which is same/similar to X.500 (93) defn, is not enough to create alias objects in an LDAP directory AND there would be, in future, another doc on this topic ? Is support for aliases a MUST for LDAP V3 ? Although, my understanding is that LDAPBIS is going to define more specifically what is LDAP V3. sanjay > however, there was an I-D on this > subject at one time. In OpenLDAP, we support "named" alias > objects (derived from "named" referral object I-Ds). > > That is, > dn: cn=john doe, dc=example, dc=net > objectclass: alias > objectclass: extensibleObject > cn=john doe > aliasedObjectName: cn=jane doe, dc=example, dc=net From list@netscape.com Wed Oct 11 13:30: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 NAA15824 for ; Wed, 11 Oct 2000 13:30: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 e9BHHHJ19698; Wed, 11 Oct 2000 10:17:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BHSXw28126; Wed, 11 Oct 2000 10:28:33 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 10:28:33 -0700 (PDT) Message-Id: <5.0.0.25.0.20001011101444.00a3e5d0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 10:28:11 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: which naming attribute ... Cc: ldapext In-Reply-To: <39E49C3F.8AA9A199@software.com> References: <5.0.0.25.0.20001010185531.00a62040@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"i1pvrC.A.M3G._MK55"@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 09:58 AM 10/11/00 -0700, sanjay jain wrote: >"Kurt D. Zeilenga" wrote: > >> At 05:49 PM 10/10/00 -0700, sanjay jain wrote: >> >which naming attribute can be used to create alias objects ? >> >> There is not yet a Standard Track specification for representing >> aliases in the directory; > >You mean 'alias' object class defn in RFC 2256, which is >same/similar to X.500 (93) defn, is not enough to create alias >objects in an LDAP directory I think this whole thread answers that question. >AND there would be, in future, >another doc on this topic ? Yes. >Is support for aliases a MUST for LDAP V3 ? No. From list@netscape.com Wed Oct 11 13:48:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16186 for ; Wed, 11 Oct 2000 13:48: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 e9BHYpJ23701; Wed, 11 Oct 2000 10:34:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BHk7w07185; Wed, 11 Oct 2000 10:46:07 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 10:46:07 -0700 (PDT) Message-ID: <39E4A703.318A63EF@novell.com> Date: Wed, 11 Oct 2000 11:44:35 -0600 From: Steven Sonntag Organization: Novell, Inc. X-Mailer: Mozilla 4.75 [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 summary - round 2 References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com> <39D023AE.6D038D1D@worldspot.com> <39E14A2B.C31480AE@worldspot.com> <39E22422.1F74EBA3@novell.com> <39E271E9.336B204@worldspot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lqRuNB.A.1vB.ddK55"@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: > > > > > This is an attempt to summarize all issues discussed since my summary to the list on 9/24 this year. > > > --- snip --- > > > All the per-instance options can be eliminated immediately in favor of setConstraints/setSearchConstraints. And with nothing left (except possibly STRING_FORMAT), I agree that we can afford to add the two suggested additional methods to get the bound protocol level and the properties Hashtable used on binding. > > Rob I'm just curious why STRING_FORMAT is possily global. If I understand this API correctly an application could choose to get all data in T.61 format whether or not the connection is V2 or V3. Is it global because an application will probably deal only with one character set, or because of of something intrinsic to the connection itself. -Steve -- ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software From list@netscape.com Wed Oct 11 14:38: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 OAA17657 for ; Wed, 11 Oct 2000 14:38: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 e9BIPtJ03584; Wed, 11 Oct 2000 11:25:55 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BIb2s08844; Wed, 11 Oct 2000 11:37:02 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 11:37:02 -0700 (PDT) Message-ID: <39E4B2E4.D432908F@worldspot.com> Date: Wed, 11 Oct 2000 11:35:16 -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 , Steven Merrill , ietf-ldapext@netscape.com, aclark@novell.com, Miodrag Kekic Subject: Re: Java LDAP API issues summary - round 2 References: <39C59B3F.A94F2396@worldspot.com> <39CEEC62.F793684C@worldspot.com> <39CFCC98.FE7D6282@novell.com> <39D023AE.6D038D1D@worldspot.com> <39E14A2B.C31480AE@worldspot.com> <39E22422.1F74EBA3@novell.com> <39E271E9.336B204@worldspot.com> <39E4A703.318A63EF@novell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ip_zvC.A.rJC.JNL55"@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: > > > All the per-instance options can be eliminated immediately in favor of setConstraints/setSearchConstraints. And with nothing left (except possibly STRING_FORMAT), I agree that we can afford to add the two suggested additional methods to get the bound protocol level and the properties Hashtable used on binding. > > > > Rob > > I'm just curious why STRING_FORMAT is possily global. If I understand this API correctly > an application could choose to get all data in T.61 format whether or not the connection is V2 or V3. > > Is it global because an application will probably deal only with one character set, or because of of something > intrinsic to the connection itself. > > -Steve It doesn't need to be global to the connection, but the purpose of the API was to accomodate the wide range of character set encoding behavior of current LDAP servers. While the correct behavior is to return T.61 to an LDAPv2 client and UTF8 to an LDAPv3 client, some servers always return UTF8 (or do no conversion at all, just returning whatever was stored - which might be T.61 or UTF8). For this purpose, it makes sense to set the format once after a connection has been established (and the client knows what type of server it's talking to) for all threads or objects sharing the same physical connection. Rob From list@netscape.com Wed Oct 11 14:56: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 OAA18072 for ; Wed, 11 Oct 2000 14:56: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 e9BIloI03781; Wed, 11 Oct 2000 11:47:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BIseE17593; Wed, 11 Oct 2000 11:54:40 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 11:54:40 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 11 Oct 2000 12:54:01 -0600 From: "Steve Sonntag" To: Cc: , , "Alan Clark" , "Steven Merrill" Subject: Re: Java LDAP API issues summary - round 2 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_421A9240.72136CB4" Resent-Message-ID: <"HM5k-C.A.lSE.vdL55"@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. --=_421A9240.72136CB4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Rob, That sounds correct. I appreciate the clarification. -Steve >>> Rob Weltman 11-Oct-00 12:35:16 PM >>> Steven Sonntag wrote: > Rob Weltman wrote: > > > All the per-instance options can be eliminated immediately in favor = of setConstraints/setSearchConstraints. And with nothing left (except = possibly STRING_FORMAT), I agree that we can afford to add the two = suggested additional methods to get the bound protocol level and the = properties Hashtable used on binding. > > > > Rob > > I'm just curious why STRING_FORMAT is possily global. If I understand = this API correctly > an application could choose to get all data in T.61 format whether or = not the connection is V2 or V3. > > Is it global because an application will probably deal only with one = character set, or because of of something > intrinsic to the connection itself. > > -Steve It doesn't need to be global to the connection, but the purpose of the = API was to accomodate the wide range of character set encoding behavior of = current LDAP servers. While the correct behavior is to return T.61 to an = LDAPv2 client and UTF8 to an LDAPv3 client, some servers always return = UTF8 (or do no conversion at all, just returning whatever was stored - which might be T.61 or UTF8). = For this purpose, it makes sense to set the format once after a connection = has been established (and the client knows what type of server it's = talking to) for all threads or objects sharing the same physical connection= . Rob --=_421A9240.72136CB4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Rob,
 
That sounds correct.  I appreciate the clarification.
 
-Steve

>>> Rob Weltman <robw@worldspot.com> = 11-Oct-00=20 12:35:16 PM >>>
Steven Sonntag wrote:

> Rob = Weltman=20 wrote:
>
> >   All the per-instance options can = be=20 eliminated immediately in favor of setConstraints/setSearchConstraints. = And with=20 nothing left (except possibly STRING_FORMAT), I agree that we can afford = to add=20 the two suggested additional methods to get the bound protocol level and = the=20 properties Hashtable used on binding.
> >
> >=20 Rob
>
> I'm just curious why STRING_FORMAT is possily =20 global.  If I understand this API correctly
> an application = could=20 choose to get all data in T.61 format whether or not the connection is V2 = or=20 V3.
>
> Is it global because an application will probably deal = only=20 with one character set, or because of of something
> intrinsic to = the=20 connection itself.
>
> -Steve

  It doesn't need to = be=20 global to the connection, but the purpose of the API was to accomodate the = wide=20 range of character set encoding behavior of current LDAP servers. While = the=20 correct behavior is to return T.61 to an LDAPv2 client and UTF8 to an = LDAPv3=20 client, some servers always return UTF8 (or do no conversion
at all, = just=20 returning whatever was stored - which might be T.61 or UTF8). For this = purpose,=20 it makes sense to set the format once after a connection has been = established=20 (and the client knows what type of server it's talking to) for all threads = or=20 objects sharing the same physical=20 connection.

Rob


--=_421A9240.72136CB4-- From list@netscape.com Wed Oct 11 15:11: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 PAA18776 for ; Wed, 11 Oct 2000 15:11: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 e9BJ3EI07931; Wed, 11 Oct 2000 12:03:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BJA3M26038; Wed, 11 Oct 2000 12:10:03 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 12:10:03 -0700 (PDT) Message-Id: <5.0.0.25.0.20001011120401.00a6a5c0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 12:08:30 -0700 To: sanjay jain From: Bruce Greenblatt Subject: Re: which naming attribute ... Cc: ldapext In-Reply-To: <39E49C3F.8AA9A199@software.com> References: <5.0.0.25.0.20001010185531.00a62040@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"R2Q5_D.A.0VG.JsL55"@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 Sanjay, As I recall, in Novell's implementation (the Novell guys can correct me if I'm misremembering), NDS enforces the naming rules mandated by the base class of the object the Alias points to. So, if the alias points to a user object, you could use the cn attribute as a naming attribute. Similarly, if the alias points to an organizationalUnit object, you could use the ou attribute as a naming attribute. This behaviour is unique to Novell's implementation. In other implementations, you should use the aliasedObjectName as the naming attribute. 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 From list@netscape.com Wed Oct 11 15:40: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 PAA19693 for ; Wed, 11 Oct 2000 15:40: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 e9BJWTI15728; Wed, 11 Oct 2000 12:32:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BJdHo11191; Wed, 11 Oct 2000 12:39:17 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 12:39:17 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 11 Oct 2000 13:38:52 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: which naming attribute ... Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_A8F078DC.9BFA8524" Resent-Message-ID: <"oJ-ESD.A.ZuC.iHM55"@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. --=_A8F078DC.9BFA8524 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Bruce,=20 Your description of the NDS implementation is correct. Using aliasedObectNa= me as the RDN has the problem Ron pointed out earlier. One of the key = points of having an alias is to give it a different name. The use of = aliasedObjectName kind of restricts you in that regard. Jim >>> Bruce Greenblatt 10/11/00 = 1:08:30 PM >>> Sanjay, As I recall, in Novell's implementation (the Novell guys can correct me = if=20 I'm misremembering), NDS enforces the naming rules mandated by the = base=20 class of the object the Alias points to. So, if the alias points to a = user=20 object, you could use the cn attribute as a naming attribute. Similarly,= =20 if the alias points to an organizationalUnit object, you could use the = ou=20 attribute as a naming attribute. This behaviour is unique to Novell's=20 implementation. In other implementations, you should use the=20 aliasedObjectName as the naming attribute. Bruce =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 Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories:=20 http://www.phptr.com/ptrbooks/ptr_0139744525.html --=_A8F078DC.9BFA8524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bruce,
 
Your description of the NDS implementation is correct. = Using=20 aliasedObectName as the RDN has the problem Ron pointed out earlier. One = of=20 the key points of having an alias is to give it a different name. The = use=20 of aliasedObjectName kind of restricts you in that regard.
 
Jim


>>> Bruce Greenblatt=20 <bgreenblatt@directory-applications.com> 10/11/00 1:08:30 PM=20 >>>
Sanjay,

As I recall, in Novell's implementation = (the=20 Novell guys can correct me if
I'm misremembering),  NDS enforces = the=20 naming rules mandated by the base
class of the object the Alias = points=20 to.  So, if the alias points to a user
object, you could use the = cn=20 attribute as a naming attribute.  Similarly,
if the alias points = to an=20 organizationalUnit object, you could use the ou
attribute as a = naming=20 attribute.  This behaviour is unique to Novell's
implementation.&n= bsp;=20 In other implementations, you should use the
aliasedObjectName as the = naming=20 attribute.

Bruce



=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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applica= tions.com
See=20 my new Book on Internet Directories:
http://www.phptr= .com/ptrbooks/ptr_0139744525.html

--=_A8F078DC.9BFA8524-- From list@netscape.com Wed Oct 11 17:31: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 RAA22257 for ; Wed, 11 Oct 2000 17:31: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 e9BLIYJ14104; Wed, 11 Oct 2000 14:18:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BLTnE08448; Wed, 11 Oct 2000 14:29:49 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 14:29:49 -0700 (PDT) Message-Id: <9F83DF9B4DD5D111999B00A0C96B12B60402A219@stca103a.bus.sc.rolm.com> From: "Skovgaard, Erik" To: "'Bruce Greenblatt'" , sanjay jain Cc: ldapext Subject: RE: which naming attribute ... Date: Wed, 11 Oct 2000 14:29:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"2ae2GB.A.uDC.MvN55"@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 Bruce, The aliasedObjectName should contain the DN of the entry to which the alias points. The naming of the alias itself is a different story. The usual way to define an alias-type entry is to derive an Object Class from alias and specify the naming attribute as MUST. For instance, I could create an Object Class of aliasedOrgUnit where I make the organizationalUnit name mandatory. As a matter of interest, aliasedObjectName does not exist in X.500. It is called aliasedEntryName. I am not sure if this is an oversight or deliberate change. The correct term for a node in the DIT is 'entry', not object. Cheers, ....Erik. -----Original Message----- From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] Sent: Wednesday, October 11, 2000 12:09 To: sanjay jain Cc: ldapext Subject: Re: which naming attribute ... Sanjay, As I recall, in Novell's implementation (the Novell guys can correct me if I'm misremembering), NDS enforces the naming rules mandated by the base class of the object the Alias points to. So, if the alias points to a user object, you could use the cn attribute as a naming attribute. Similarly, if the alias points to an organizationalUnit object, you could use the ou attribute as a naming attribute. This behaviour is unique to Novell's implementation. In other implementations, you should use the aliasedObjectName as the naming attribute. 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 From list@netscape.com Wed Oct 11 17:38: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 RAA22405 for ; Wed, 11 Oct 2000 17:38: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 e9BLPDJ15839; Wed, 11 Oct 2000 14:25:13 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BLaSo12170; Wed, 11 Oct 2000 14:36:28 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 14:36:28 -0700 (PDT) Message-Id: <9F83DF9B4DD5D111999B00A0C96B12B60402A21A@stca103a.bus.sc.rolm.com> From: "Skovgaard, Erik" To: "'Jim Sermersheim'" , bgreenblatt@directory-applications.com, sanjay.jain@software.com Cc: ietf-ldapext@netscape.com Subject: RE: which naming attribute ... Date: Wed, 11 Oct 2000 14:36:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C033CB.49AFCE90" Resent-Message-ID: <"f44b-B.A.49C.b1N55"@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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C033CB.49AFCE90 Content-Type: text/plain; charset="iso-8859-1" We should probably think of alias as an Abstract Object Class. As I see it, it cannot exist alone since there is no naming attribute defined in the Object Class. Cheers, ....Erik Erik Skovgaard Siemens Meta-Directory Solutions Phone: +1 604-204-0750 Fax: +1 604-204-0760 -----Original Message----- From: Jim Sermersheim [mailto:JIMSE@novell.com] Sent: Wednesday, October 11, 2000 12:39 To: bgreenblatt@directory-applications.com; sanjay.jain@software.com Cc: ietf-ldapext@netscape.com Subject: Re: which naming attribute ... Bruce, Your description of the NDS implementation is correct. Using aliasedObectName as the RDN has the problem Ron pointed out earlier. One of the key points of having an alias is to give it a different name. The use of aliasedObjectName kind of restricts you in that regard. Jim >>> Bruce Greenblatt 10/11/00 1:08:30 PM >>> Sanjay, As I recall, in Novell's implementation (the Novell guys can correct me if I'm misremembering), NDS enforces the naming rules mandated by the base class of the object the Alias points to. So, if the alias points to a user object, you could use the cn attribute as a naming attribute. Similarly, if the alias points to an organizationalUnit object, you could use the ou attribute as a naming attribute. This behaviour is unique to Novell's implementation. In other implementations, you should use the aliasedObjectName as the naming attribute. 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 ------_=_NextPart_000_01C033CB.49AFCE90 Content-Type: application/octet-stream; name="Skovgaard, Erik.vcf" Content-Disposition: attachment; filename="Skovgaard, Erik.vcf" BEGIN:VCARD VERSION:2.1 N:Skovgaard;Erik FN:Skovgaard, Erik ORG:Siemens Information and Communications Networks, Inc.;90726B NOTE;ENCODING=QUOTED-PRINTABLE:Employee works out of his home office in Richmond, British Columbia=0D=0A TEL;WORK;VOICE:+1 604-204-0750 TEL;HOME;VOICE:Erik.Skovgaard@icn.siemens.com TEL;HOME:Directory Team-Engineering EMAIL;PREF;INTERNET:Erik.Skovgaard@icn.siemens.com REV:20000518T232217Z END:VCARD ------_=_NextPart_000_01C033CB.49AFCE90-- From list@netscape.com Wed Oct 11 18:55: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 SMTP id SAA23295 for ; Wed, 11 Oct 2000 18:55: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 e9BMg0J29066; Wed, 11 Oct 2000 15:42:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9BMrGA20096; Wed, 11 Oct 2000 15:53:16 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 15:53:16 -0700 (PDT) Message-ID: <39E4EE54.BC0E25D6@software.com> Date: Wed, 11 Oct 2000 15:48:52 -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: ldapext Subject: Re: which naming attribute, couple of more questions ... References: <5.0.0.25.0.20001010185531.00a62040@router.boolean.net> <5.0.0.25.0.20001011101444.00a3e5d0@router.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XgDPBB.A.u5E.b9O55"@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: > >Is support for aliases a MUST for LDAP V3 ? > > No. Please clarify few more things for me. Thanks. Which of the following are MUST for LDAP V3 ? - support for multiple AVAs in an RDN - server should be able to recognize an attribute by its OID or any of its textual names in the protocol (In DNs, attribute names in update operations, in required attr list and in filters etc..) - support for renaming (moddn) of a non-leaf node thanks From list@netscape.com Wed Oct 11 20:08: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 UAA24602 for ; Wed, 11 Oct 2000 20:08: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 e9BNtZJ10242; Wed, 11 Oct 2000 16:55:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9C06pU25484; Wed, 11 Oct 2000 17:06:51 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 17:06:51 -0700 (PDT) Message-Id: <5.0.0.25.0.20001011160758.00a47eb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 17:04:05 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: which naming attribute, couple of more questions ... Cc: ldapext In-Reply-To: <39E4EE54.BC0E25D6@software.com> References: <5.0.0.25.0.20001010185531.00a62040@router.boolean.net> <5.0.0.25.0.20001011101444.00a3e5d0@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"gVMkd.A.YNG.ZCQ55"@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:48 PM 10/11/00 -0700, sanjay jain wrote: >Please clarify few more things for me. Thanks. >Which of the following are MUST for LDAP V3 ? In my opinion, vendors have a good deal of freedom when implementing LDAPv3. I do, however, advocate that vendors implement not only all the MUSTs, but most of the SHOULDs, and many of the MAYs. > - support for multiple AVAs in an RDN optional. A server can return unwillingToPerform or other suitable resultCode if it is unwilling to accept multiple AVAs in an RDN as the target or base DN of an operation. However, as a value of user attribute or in a filter, it should accept it for any attribute of DN syntax it publishes support for. I know of a few implementations which do not support multi-valued RDNs. > - server should be able to recognize an attribute by its OID > or any of its textual names in the protocol (In DNs, attribute names > in update operations, in required attr list and in filters etc..) Off hand, I'd say 'optional'. As previously noted, there is plenty of play in the specification. I know of many implementations which do not support OID/NAME equivalences in all protocol elements. > - support for renaming (moddn) of a non-leaf node Optional. A server can return unwillingToPerform or other suitable resultCode if it is unwilling to perform the requested operation. I know of many implementations which do not support renaming of subtrees. From list@netscape.com Thu Oct 12 02:24: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 SMTP id CAA13295 for ; Thu, 12 Oct 2000 02:24: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 e9C6BeJ25207; Wed, 11 Oct 2000 23:11:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9C6MuE10875; Wed, 11 Oct 2000 23:22:56 -0700 (PDT) Resent-Date: Wed, 11 Oct 2000 23:22:56 -0700 (PDT) Message-Id: <200010120622.e9C6Ms301161@ywing.netscape.com> X-Freei-Sender: cassoc2000@ca.freei.net X-Sender: racassoc_2000@yahoo.com From: racassoc To: ietf-ldapext@netscape.com Date: Wed, 11 Oct 2000 23:28:12 -0700 Subject: CHECK IT OUT! IT'S FREE! Reply-To: racassoc_2000@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 X-MIME-Autoconverted: from base64 to 8bit by aka.mcom.com id e9C6Mtr10851 Resent-Message-ID: <"rsticC.A.ppC._iV55"@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 e9C6BeJ25207 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13295 CHECK IT OUT! IT'S FREE! GET 300 MEMBERS A MONTH!! ALL new members that come into the club COMPANY WIDE will go under YOU. A true VERTICAL downline YOU can easily get 300 members Under YOU in a month! How would you like to know that you have an existing down line, and team in place, to continue to help you develop a network... BEFORE you ever sign up or invest a penny? With our Post Launch program you can! How would you like a GUARANTEED Minimum commission every month? JOIN FREE!!!!!!! JOIN FREE!!!!!!! To join our FREE postlaunch program, click on: http://www.angelfire.com/ca6/af5/index.html … Or, send us an email (just hit reply) with "I would like to join Post launch for Free!" in the subject, and include your "firstname, lastname, and email"... We will send you an email to confirm your free membership, and provide additional benifits of the program. You have nothing to lose and potentially a lot to gain! ______________________________________________________________ If you choose not to receive info from us, just hit Reply and type "Please Remove" in the Subject, send us the email, and your wishes will be honored. _____________________________________________________________________ From list@netscape.com Fri Oct 13 03:09: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 DAA00529 for ; Fri, 13 Oct 2000 03:09: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 e9D6uaJ29836; Thu, 12 Oct 2000 23:56:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9D77sw28914; Fri, 13 Oct 2000 00:07:55 -0700 (PDT) Resent-Date: Fri, 13 Oct 2000 00:07:55 -0700 (PDT) Date: Fri, 13 Oct 2000 19:58:07 +1300 Message-Id: <200010130658.TAA03368@smtpout1.compass.net.nz> From: Name@TVOA.usa.net To: $Gary.SCAC@netscape.com Subject: " WE currently hiring SERIOUS HOMEWORKERS Position: -RCDJ X-Reply-To: homeworker67@usa.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"wRcdo.A.RDH.JTr55"@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 Online Marketer, I have found that you are doing business on the internet and hope everything is going well for you. As a result of the Internet our Company has grown very fast and we are in need of employes to work for us. We are hiring serious people from all over the world who would like to work and earn an additional income from their home. YOU WILL BE PAID WORKING FOR US AS FOLLOWS: 1. Control and checking of administrative data entry 2. Typing the company's sales and administrative letters, memos, payrolls, agendas, etc. 3. Sending out our e-mails 4. Developing our marketing campaign Experience is NOT necessary just have to know how to type. If you have new and specific ideas or skills that can be useful to our company, you can tell us and we will make an effort to help you. If you are looking for a get-rich-quick scheme or MLM program, please do not e-mail me. homeworker65@alloymail.com Subject:homeworker Please write short text those who are serious. Thank you for your time Rachel Thomas From list@netscape.com Fri Oct 13 08:19:36 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03973 for ; Fri, 13 Oct 2000 08:19: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 e9DCBAI18455; Fri, 13 Oct 2000 05:11:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9DCI3U17894; Fri, 13 Oct 2000 05:18:03 -0700 (PDT) Resent-Date: Fri, 13 Oct 2000 05:18:03 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 13 Oct 2000 06:17:41 -0600 From: "Haripriya S" To: Subject: ACL access decision question Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_3169E37B.E081F96F" Resent-Message-ID: <"bpqs5B.A.RXE.51v55"@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. --=_3169E37B.E081F96F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, The ACL model draft says that more specific functions should override less = specific ones, and deny overrides grant. Also, it says specificity applies = to both subject and attributes. Now given two ACIs for a target entry: aci1: entry#grant:r#attrname#group:cn=3Dg1,o=3Dn aci2: entry#grant:w#[all]#authzID-dn:cn=3Du1,o=3Dn If u1 belongs to group g1, which aci takes precedence?=20 aci1: because attrname is more specific than [all] or=20 aci2: because authxID-dn is more specific than group What happens if one is grant:w and another is deny:w in the above case? What is the precedence relation between various dimensions of ACIs: scope, = target specificity, subject specificity, attribute specificity, and = grant/deny. Thanks and Regards, Haripriya --=_3169E37B.E081F96F Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
The ACL model draft says that more specific functions = should=20 override less specific ones, and deny overrides grant. Also, it says = specificity=20 applies to both subject and attributes.
 
Now given two ACIs for a target entry:
 
aci1: entry#grant:r#attrname#group:cn=3Dg1,o=3Dn=
aci2: entry#grant:w#[all]#authzID-dn:cn=3Du1,o=3Dn
 
If u1 belongs to group g1, which aci takes = precedence?=20
aci1: because attrname is more specific than [all] = or=20
aci2: because authxID-dn is more specific than=20 group
 
What happens if one is grant:w and another is deny:w = in the=20 above case?
 
What is the precedence relation between various dimensions of = ACIs:=20 scope, target specificity, subject specificity, attribute specificity, = and=20 grant/deny.
 
Thanks and Regards,
Haripriya
--=_3169E37B.E081F96F-- From list@netscape.com Sun Oct 15 22:20: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 WAA12980 for ; Sun, 15 Oct 2000 22:20: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 e9G27Vs26635; Sun, 15 Oct 2000 19:07:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9G2Isk26788; Sun, 15 Oct 2000 19:18:54 -0700 (PDT) Resent-Date: Sun, 15 Oct 2000 19:18:54 -0700 (PDT) To: Stockwinner@aol.com From: Subject: Stock Pick of the Week Message-ID: <0025437150210a0CPIMSSMTPU01@email.msn.com> Date: 15 Oct 2000 19:15:48 -0700 Resent-Message-ID: <"qQki5.A.MiG.MWm65"@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 >>> STOCK PICK OF THE WEEK <<< For the week beginning Monday, 10-16-2000 Investment Snapshot - ATTP -- Affordable Telecom http://moneycentral.msn.com/scripts/webquote.dll?iPage=qd&Symbol=attp Target Price: $1.00 Current Price: $.12 Take a close look at this stock, it's going to rise fast! HOUSTON--(BUSINESS WIRE)--Oct. 3, 2000--Affordable Telecommunications Technology Corporation (OTC BB:ATTP) announced today its preliminary third quarter revenues will exceed expectations. Affordable Telecommunications announced preliminary projected revenues of $500,000 for the quarter ending September 30, 2000. Steven H. Bethke, president of Affordable Telecommunications, said, "We are extremely pleased to anticipate a 460% year-over-year increase in revenues, which exceed our expectations. Strong revenue gains indicate we are on track in building our revenue base through strategic marketing arrangements with leaders in the wireless industry." The Company expects to report its finalized quarterly results on or before November 15, 2000. From list@netscape.com Mon Oct 16 00:41: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 AAA15239 for ; Mon, 16 Oct 2000 00:41:50 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9G4Sps04071; Sun, 15 Oct 2000 21:28:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9G4eFw27238; Sun, 15 Oct 2000 21:40:15 -0700 (PDT) Resent-Date: Sun, 15 Oct 2000 21:40:15 -0700 (PDT) To: Email@xwing.netscape.com, Address@xwing.netscape.com, Owners@xwing.netscape.com From: mmcdonald@123go.com Subject: Top 5 Web Sites Date: Sun, 15 Oct 2000 22:14:15 -0600 Message-Id: <36814.926566793983500.12815@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit Resent-Message-ID: <"7T8tGD.A.RpG.uao65"@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 Top 5 Internet Sites

TOP 5 Internet Web Sites

1. $1000.00 Weekly Give Away, Gaming Newsletters, Bad Bets section, Chat, Handy Caper's, Sportsbooks, Online Casinos & more.http://www.top100gamingsites.com

 2. Computer Systems, Desktops, Notebooks, Mac, Still photo, Webcams, Accessories, Cameras Software, Memory, Storage, & more. http://shopper.cnet.com/

3.  Cracks, Patches, Free Software, Free MP3's, Free Movies, Learn how to hack, Underground webmasters Search Engine http://www.astalavista.box.sk
 
4.  Cheap Long Distance Calling Rates Cheapest International calling plans available, Pre Paid International Calling Cards and much more http://www.callmaster.com
 
5. Cool Flash Animated Sites, Free games, Make your own Music, Online Greeting Cards The Best Sites on the Net are Found at  http://www.shockwave.com
 From list@netscape.com Mon Oct 16 13:04: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 NAA10659 for ; Mon, 16 Oct 2000 13:04: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 e9GGtVD21599; Mon, 16 Oct 2000 09:55:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9GH2Ss19378; Mon, 16 Oct 2000 10:02:28 -0700 (PDT) Resent-Date: Mon, 16 Oct 2000 10:02:28 -0700 (PDT) From: "TSS" To: Subject: Successful Internet Business Date: Tue, 17 Oct 2000 01:51:51 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Resent-Message-ID: <"JGDRgC.A.ftE.iSz65"@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 $$$$Successful Internet Mailing Program with a Safety Catch. An Accountability list to ensure that ALL PARTICIPANTS get paid. Cheat Proof! Invest JUST $10 and see a return of $40,000 in 45 DAYS OR LESS. For FREE details$B!$(Be-mail i4tell@usa.net. From list@netscape.com Mon Oct 16 13:42:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11673 for ; Mon, 16 Oct 2000 13: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 e9GHTcs12697; Mon, 16 Oct 2000 10:29:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9GHf3218271; Mon, 16 Oct 2000 10:41:03 -0700 (PDT) Resent-Date: Mon, 16 Oct 2000 10:41:03 -0700 (PDT) Message-ID: <39EB3D3D.19E376E7@worldspot.com> Date: Mon, 16 Oct 2000 10:39:09 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com Subject: Re: LDAPBind in ldap-java-api-11.txt References: Content-Type: multipart/alternative; boundary="------------E6D8F163895E7E4057A65988" Resent-Message-ID: <"822DwC.A.IdE.t2z65"@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 --------------E6D8F163895E7E4057A65988 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I guess that's OK. RFC 2251 says: "If the client wishes to progress the operation, it MUST follow the referral by contacting any one of servers. All the URLs MUST be equally capable of being used to progress the operation." That means there is no order to the list, and a client is free to contact any one of the servers listed. Rob Steve Sonntag wrote: > Re: LDAPBind, section 4.4 > > I was just thinking about the LDAPBind functionality, specifically the > bind method. > > Would it make sense to pass into the bind method the whole array > of referral strings associated with a referral, i.e. > > public LDAPConnection bind(String[] ldapurl, LDAPConnection conn) > throws LDAPException > > The semantics are that the application implementing the LDAPBind > interface > binds with one server in the list and then returns the connection. If > it cannot > bind with any, it throws an appropriate LDAPException. > > This allows the application use its own mechanisms to make a "best > choice" > out of the list of servers and to see the whole list at once. > > What do you think? Is this an improvement or a cause for confusion? > > -Steve > > > > ------------------------ > Steve Sonntag > Novell, Inc., the leading provider of Net services software > > --------------E6D8F163895E7E4057A65988 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit   I guess that's OK. RFC 2251 says:

"If the client wishes to progress the operation, it MUST follow the referral by contacting any one of servers.  All the URLs MUST be equally capable of being used to progress the operation."

  That means there is no order to the list, and a client is free to contact any one of the servers listed.

Rob
 

Steve Sonntag wrote:

 Re: LDAPBind, section 4.4

I was just thinking about the LDAPBind functionality, specifically the bind method.

Would it make sense to pass into the bind method the whole array
of referral strings associated with a referral, i.e.

public LDAPConnection bind(String[] ldapurl, LDAPConnection conn)
                    throws LDAPException

The semantics are that the application implementing the LDAPBind interface
binds with one server in the list and then returns the connection.  If it cannot
bind with any, it throws an appropriate LDAPException.

This allows the application use its own mechanisms to make a "best choice"
out of the list of servers and to see the whole list at once.

What do you think?  Is this an improvement or a cause for confusion?

-Steve
 
 

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

--------------E6D8F163895E7E4057A65988-- From list@netscape.com Mon Oct 16 14:21:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12524 for ; Mon, 16 Oct 2000 14:21: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 e9GI8qs21189; Mon, 16 Oct 2000 11:08:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9GII6Q11973; Mon, 16 Oct 2000 11:18:06 -0700 (PDT) Resent-Date: Mon, 16 Oct 2000 11:18:06 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 16 Oct 2000 11:17:49 -0600 From: "Steve Sonntag" To: , Subject: LDAPBind in ldap-java-api-11.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D28A0D50.F594EE82" Resent-Message-ID: <"9-n1LD.A.d5C.UZ065"@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. --=_D28A0D50.F594EE82 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Re: LDAPBind, section 4.4 I was just thinking about the LDAPBind functionality, specifically the = bind method. Would it make sense to pass into the bind method the whole array of referral strings associated with a referral, i.e. public LDAPConnection bind(String[] ldapurl, LDAPConnection conn) throws LDAPException The semantics are that the application implementing the LDAPBind interface binds with one server in the list and then returns the connection. If it = cannot bind with any, it throws an appropriate LDAPException. This allows the application use its own mechanisms to make a "best choice" out of the list of servers and to see the whole list at once. What do you think? Is this an improvement or a cause for confusion? -Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software --=_D28A0D50.F594EE82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable  Re: LDAPBind, section 4.4

I was just thinking about the LDAPBind = functionality,=20 specifically the bind method.

Would it make sense to pass into the bind = method the=20 whole array
of referral strings associated with a referral, i.e.<= /P>

public LDAPConnection bind(String[] = ldapurl,=20 LDAPConnection=20 conn)
           =         =20 throws LDAPException

The semantics are that the application = implementing=20 the LDAPBind interface
binds with one server in the list and then = returns the=20 connection.  If it cannot
bind with any,=20 it throws an appropriate LDAPException.

This allows the application use its own = mechanisms to=20 make a "best choice"
out of the list of servers and to see the whole = list at=20 once.

What do you think?  Is this an = improvement or a=20 cause for confusion?

-Steve

 

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

 

 --=_D28A0D50.F594EE82-- From list@netscape.com Tue Oct 17 02:15:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05244 for ; Tue, 17 Oct 2000 02:15: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 e9H62Ls05502; Mon, 16 Oct 2000 23:02:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9H6Dlw08697; Mon, 16 Oct 2000 23:13:47 -0700 (PDT) Resent-Date: Mon, 16 Oct 2000 23:13:47 -0700 (PDT) From: changeyourlife@aussiemail.com.au Message-Id: <200010170400.FAA03864@rva.fcr.francetelecom.fr> Subject: RE: YOUR INQUIRY! Date: Mon, 16 Oct 2000 22:42:25 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0E86_00000C2D.00002FF1" X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"36PMND.A.kHC.Z4-65"@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 ------=_NextPart_000_0E86_00000C2D.00002FF1 Content-Type: text/html; 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-888-248-0843

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-888-248-0843

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: JohnandJean@aussiemail.com.au
and place remove in the subject
Thank you
*********************************************************

------=_NextPart_000_0E86_00000C2D.00002FF1-- From list@netscape.com Tue Oct 17 06:52: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 GAA07254 for ; Tue, 17 Oct 2000 06:52: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 e9HAhtD21973; Tue, 17 Oct 2000 03:43:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9HAoqo12229; Tue, 17 Oct 2000 03:50:52 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 03:50:52 -0700 (PDT) Message-Id: <200010171050.GAA07225@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-04.txt Date: Tue, 17 Oct 2000 06:50:17 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"vRhn7B.A.s-C.L8C75"@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-04.txt Pages : 8 Date : 16-Oct-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-04.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-04.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-04.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: <20001016145708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-matchedval-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-matchedval-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001016145708.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Oct 17 10:07: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 KAA12301 for ; Tue, 17 Oct 2000 10:07: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 e9HDsos24681; Tue, 17 Oct 2000 06:54:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9HE6FI06726; Tue, 17 Oct 2000 07:06:15 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 07:06:15 -0700 (PDT) Date: Wed, 18 Oct 2000 03:06:42 +1300 Message-Id: <200010171406.DAA13508@smtpout2.compass.net.nz> From: nzglobal@ADKR.usa.net To: $Gary.NKRD@netscape.com Subject: How would you like to quit your job, become your own boss, -KKYP X-Reply-To: homeworker67@usa.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"d0HMdD.A.xoB.WzF75"@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 plan" and meet at the local high school for a "ra-ra" meeting. Our company offers you an 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 the potential of having distributors all over the World. Make a well informed decision which will impact your future today ! For more info mail to: pleasemoreinfo@alloymail.com If you are not interested please hit "Reply" and type in the word "Remove" in the subject field and you will not be contacted again. From list@netscape.com Tue Oct 17 13:04:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16873 for ; Tue, 17 Oct 2000 13:04: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 e9HGoAs20156; Tue, 17 Oct 2000 09:50:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9HH1a618779; Tue, 17 Oct 2000 10:01:36 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 10:01:36 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 17 Oct 2000 11:01:25 -0600 From: "Steven Merrill" To: "Steve Sonntag" , Cc: Subject: ldap-java-api-11.txt (and 12) 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 e9HH1Yr18726 Resent-Message-ID: <"64b8FC.A._kE.vXI75"@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 Sections 4.11.2 escapeRDN and 4.11.3 unescapeRDN: Refers to [5] for a discussion of characters requiring escaping. This should be [4]. Also, [4] should refer to RFC 2253 instead of RFC 1779. -Steve From list@netscape.com Tue Oct 17 14:47:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19148 for ; Tue, 17 Oct 2000 14:47: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 e9HIYis09929; Tue, 17 Oct 2000 11:34:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9HIkAw16170; Tue, 17 Oct 2000 11:46:10 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 11:46:10 -0700 (PDT) Message-Id: From: david.a.cahlander@syntegra.com Subject: Returning Matched Values with LDAPv3 To: ietf-ldapext@netscape.com Date: Tue, 17 Oct 2000 13:44:36 -0500 (CDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"oQodzB.A.K6D.t5J75"@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 reference to http://www.ietf.org/internet-drafts/draft-ietf-ldapext-matchedval-04.txt I don't understand the filter used in example (3): ValuesReturnFilter control is set to (userCertificate:2.5.13.35:=USE'001'B) Some reference to a source of "string to filter" for USE'001'B would help. It is not clear from the description if example (2) could return the result on the basis of the name 'gunk' instead of on the basis of the OID. Does the substring filter capability allow a filter of the form: (attributeTypes=*'gunk'*) If I knew the OID number of "gunk", the entire "attributeTypes" attribute of the schema entry has probably been read, and I don't need the LDAP extension to read it. An example to retrieve an "objectClasses" attribute would help. I assume that this could be: (objectClasses:NAME:=inetOrgPerson) Is that correct? Would the filter (objectClasses=*'inetOrgPerson'*) work to get this string? Thanks. -- David A. Cahlander 651-415-3171 Syntegra David.A.Cahlander@Syntegra.com From list@netscape.com Tue Oct 17 15:10: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 PAA19509 for ; Tue, 17 Oct 2000 15:10: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 e9HIvos14131; Tue, 17 Oct 2000 11:57:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9HJ9Ho03395; Tue, 17 Oct 2000 12:09:17 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 12:09:17 -0700 (PDT) Message-Id: <5.0.0.25.0.20001017115523.00a59630@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 17 Oct 2000 12:08:20 -0700 To: david.a.cahlander@syntegra.com From: "Kurt D. Zeilenga" Subject: Re: Returning Matched Values with LDAPv3 Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"fWmURB.A.u0.bPK75"@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:44 PM 10/17/00 -0500, david.a.cahlander@syntegra.com wrote: >It is not clear from the description if example (2) could return the result >on the basis of the name 'gunk' instead of on the basis of the OID. > >Does the substring filter capability allow a filter of the form: > > (attributeTypes=*'gunk'*) There is no substrings matching rule for attributeTypes, so this assertion is 'Undefined'. I suggest the example use (attributeTypes=2.5.4.3) as the equality matching rule for attributeTypes is objectIdentifierFirstComponentMatch which requires an assertion value of syntax OID. Some servers support (attributeTypes=cn) as well. >If I knew the OID number of "gunk", the entire "attributeTypes" attribute of >the schema entry has probably been read, and I don't need the LDAP extension >to read it. You need an LDAP extension to return only the matched values. >An example to retrieve an "objectClasses" attribute would help. (objectClasses=2.5.4.0) or (objectClasses=objectclass) // supported by some servers Kurt From list@netscape.com Tue Oct 17 22:39: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 WAA27294 for ; Tue, 17 Oct 2000 22:39: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 e9I2TdD16687; Tue, 17 Oct 2000 19:29:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9I2aaw14085; Tue, 17 Oct 2000 19:36:36 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 19:36:36 -0700 (PDT) Message-Id: Subject: ADV - 10 MILLION ADDRESSES CHEAP! Reply-To: emailingnow@epost.com From: email@epostd.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT To: denny@bigfoot.com Date: Sat, 20 Nov 1999 07:27:35 -0800 Resent-Message-ID: <"FvDQ_B.A.kbD.zyQ75"@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 10 MILLION EMAIL ADDRESSES FOR ONLY $99 You want to make some money? we can put you in touch with over 10 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $250,000.00 That's right, we have 10 Million Fresh email addresses that we will sell for only $99. These are all fresh addresses with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1/10% response. That's $1,350,000 in your pocket !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! we will even include, a FREE demo copy of the worlds leading BULK MAILING SOFTARE! These 10 Million email addresses and software are yours to keep, so you can use them over and over and they come on 1 CD. This offer is not for everyone. If you can not see just how excellent the risk / reward ratio in this offer is then there is nothing we can do for you. To make money you must stop dreaming and TAKE ACTION. **************************************** 10 MILLION email addresses on CD These name are all in text files ready to mail!!! (includes bulk mailing sotware) $99.00 ************************************************************* VISA/MC ONLY STEP 1: Print out the below ORDER FORM STEP 2: Type or Print your order information into the form STEP 3: FAX Your order to us. FAX TO: 415-704-3071 (Order with confidence. This is a secure fax area. Only our qualified sales team will have access to your order information) ORDER FORM(Print clearly with DARK pen) ************************************************************************************************ Name: ________________________________ Address: ________________________________ * *BILLING ADDRESS ONLY City, State, ZIP: ________________________________ Country: ______________ (International Orders) Phone Number: ______________ (In case we can't make out your order) METHOD OF PAYMENT- CREDIT CARD ONLY [ ]Visa [ ]MasterCard Credit Card #: __________________________________ Exp Date: _______________ Signature: ____________________________ (Required) E-Mail Address: ____________________________ *(PRINT CLEARLY!!) ************************************************************************************************ WE WILL BILL 99.00 to your account plus the following shipping costs SHIPPING COST OF 4.85 FIRST CLASS MAIL INTERNATIOMAL ORDERS ADD 25.00 U.S. DOLLARS ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL, QUICKLY, PROPERLY, LEGALLY PROVIDED WITH ORDER Copyright 2000 All rights reserved From list@netscape.com Wed Oct 18 01:27:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02607 for ; Wed, 18 Oct 2000 01:27: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 e9I5J1D17967; Tue, 17 Oct 2000 22:19:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9I5PxM01272; Tue, 17 Oct 2000 22:25:59 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 22:25:59 -0700 (PDT) Reply-To: From: "Steven Legg" To: , Cc: Subject: RE: Returning Matched Values with LDAPv3 Date: Wed, 18 Oct 2000 16:25:22 +1100 Message-ID: <000501c038c3$d0f7e8e0$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Importance: Normal Resent-Message-ID: <"MyV-H.A.gT.mRT75"@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.a.cahlander@syntegra.com > [mailto:david.a.cahlander@syntegra.com] > Sent: Wednesday, 18 October 2000 5:45 > To: ietf-ldapext@netscape.com > Subject: Returning Matched Values with LDAPv3 > > > In reference to > > > http://www.ietf.org/internet-drafts/draft-ietf-ldapext-matched > val-04.txt > > I don't understand the filter used in example (3): > > ValuesReturnFilter control is set to > (userCertificate:2.5.13.35:=USE'001'B) The assertion syntax here is actually incorrect. The filter should read: (userCertificate:2.5.13.35:=( USE '001'B )) > > Some reference to a source of "string to filter" for > > USE'001'B > > would help. It is an encoding of a defined in Section 3.2 of http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-01.txt, which example (3) already references. > > It is not clear from the description if example (2) could > return the result > on the basis of the name 'gunk' instead of on the basis of the OID. > > Does the substring filter capability allow a filter of the form: > > (attributeTypes=*'gunk'*) > > If I knew the OID number of "gunk", the entire > "attributeTypes" attribute of > the schema entry has probably been read, and I don't need the > LDAP extension > to read it. > > An example to retrieve an "objectClasses" attribute would > help. I assume > that this could be: > > (objectClasses:NAME:=inetOrgPerson) > > Is that correct? Would the filter > > (objectClasses=*'inetOrgPerson'*) > > work to get this string? Kurt has already pointed out that substring matching on attributeTypes or objectClasses is undefined. However matching attributeTypes or objectClasses values by name is something that is supported by the component matching rules draft that I've nearly finished writing up. The filters in this case would look like: (attributeTypes:componentFilterMatch:=item:{ component "name.*", rule caseIgnoreMatch, value "gunk" }) (objectClasses:componentFilterMatch:=item:{ component "name.*", rule caseIgnoreMatch, value "inetOrgPerson" }) They could be used in a search filter or a ValuesReturnFilter. Regards, Steven > > Thanks. > -- > David A. Cahlander 651-415-3171 Syntegra > David.A.Cahlander@Syntegra.com > > From list@netscape.com Wed Oct 18 02:05: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 CAA12352 for ; Wed, 18 Oct 2000 02:05: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 e9I5uwD22976; Tue, 17 Oct 2000 22:56:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9I63vs11440; Tue, 17 Oct 2000 23:03:57 -0700 (PDT) Resent-Date: Tue, 17 Oct 2000 23:03:57 -0700 (PDT) Message-Id: <5.0.0.25.0.20001017223917.00a7b850@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 17 Oct 2000 23:03:12 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Matched values: valuesReturnFilter string representation In-Reply-To: <200010171050.GAA07225@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"0qzcl.A.byC.L1T75"@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 Section 5 says: The string representation of the valuesReturnFilter in the examples below uses the notation defined in RFC 2254 [11]. However, as a valuesReturnFilter is a sequence of simple filters, the string representation of valuesReturnFilter is actually more like: valuesReturnFilter = "(" 1*simplefilter ")" simplefilter = "(" item ")" where item is as defined by RFC2254. I suggest the string representation should be specified in the I-D. Using the above BNF, all of the single item valueReturnFilter presented in the examples need to be wrapped by another set of parens, e.g: ((attributeTypes=1.2.3.4.5)) One could define a BNF that for sequences of 1 simplefilter the outer parens were eliminated. However, having the outer parens distinguishes valueReturnFilters from filters. Kurt From list@netscape.com Wed Oct 18 04:10: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 EAA13215 for ; Wed, 18 Oct 2000 04:10: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 e9I7uas22086; Wed, 18 Oct 2000 00:56:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9I884M13795; Wed, 18 Oct 2000 01:08:04 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 01:08:04 -0700 (PDT) X-Sender: steve3354@UCSD.com From: Steve To: ietf-ldapext@netscape.com Date: Wed, 18 Oct 2000 18:05:17 +1000 Subject: Check this out MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <0f8ae06080712a0KNET@knet> Resent-Message-ID: <"TBkPID.A.MXD.jpV75"@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 HERE IS A PROGRAM NOT TO BE MISSED! It has now been out for 3 weeks, and is making people money faster than any other program on the www for one investment of US $5. The program uses e-gold.com, which is international, so everyone can have a go. Anyone can get an e-gold account. If you don't have one yet go to http://www.e-gold.com/e-gold.asp?cid=185289 "For only investing $5 I can't believe what my e-gold account looks like. I invested the $5 then sent 23 emails to friends and 4 days later I checked my e-gold account to find $245 more in it, after two weeks of being in this program I've made approximately $6300 and all it took was a small investment and about 15 minutes. I am now sending out more emails this is truly a fantastic program". Janine This is a 100% legal service. If you don't believe it check it out for yourself. This program has 5 platforms and moves VERY FAST so if you want money in your e-gold account faster than you can say BOO! give it a try. Don't stop any other program you are doing, because this one only takes about 15 minutes, then you can forget about it, or you can keep sending out more emails for even better results (the more you send out the better response you will get). OK! This is what to do: Follow these steps carefully. STEP 1: If you do not have an e-gold account go to http://www.e-gold.com/e-gold.asp?cid=164513 and then you need to fund your account by going to http://www.goldchanger.com STEP 2: Go into your e-gold account and click on SPEND, spend US $5 to the e-gold account on platform number 1. In the MEMO section type "Quick Gold" STEP 3: Retype the platform list by deleting Platform No. 1 completely, Move the Platform numbers up so that P2 becomes P1, P3 becomes P2 etc and then put your e-gold account number in Platform No.5 (Do not change any other part of this letter as it has been working very well as it is) STEP 4: Email as many copies of the letter as you can. Put Something like "NOT TO BE MISSED!!!" as the subject. STEP 5: Watch your e-gold account grow before your eyes (sometimes it only takes a few hours). PLATFORMS P1: 185289 P2: 148040 P3: 124304 P4: 176593 P5: 177025 Just think, when you get to platform No.1 there could be 1500 people or more putting $5 in your e-gold account. That's $4,500. It's only $5 to enter and that could easily be thrown away on the lotto or poker machines or betting on the horses, at least with this program you know you will easily get back what you put into it. Well, what are you waiting for? ----------------------------------------------- This is not spam. You are receiving this email because we are both members of the same opt-in list. To be removed from this list, reply to this message with 'Remove' in the subject. Thank you. From list@netscape.com Wed Oct 18 12:32:13 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26655 for ; Wed, 18 Oct 2000 12:32: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 e9IEcxs27919; Wed, 18 Oct 2000 07:39:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9IEjpg02503; Wed, 18 Oct 2000 07:45:51 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 07:45:51 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 18 Oct 2000 08:44:03 -0600 From: "Ed Reed" To: , , , , , , Subject: Fwd: Re: Edition 4 of X.500 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4119984A.D9B8D414" Resent-Message-ID: <"_10tJB.A.0l.Ueb75"@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 --=_4119984A.D9B8D414 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For all those who may not have seen the attached, the near-final pre-public= ation versions of X.500(2000) are now posted. =20 Best regards, Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_4119984A.D9B8D414 Content-Type: message/rfc822 Received: from lionfish.az05.bull.com by reed.oncalldba.com; Wed, 18 Oct 2000 02:31:03 -0600 Received: from nc-17.ma02.bull.com (root@bull.com [128.35.253.3]) by lionfish.az05.bull.com (8.9.3/8.9.3) with ESMTP id BAA39592 for ; Wed, 18 Oct 2000 01:22:01 -0700 Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by nc-17.ma02.bull.com (8.10.1/8.10.1) with ESMTP id e9I8M0621760 for ; Wed, 18 Oct 2000 04:22:00 -0400 Received: from [38.29.122.219] (ip219.phoenix10.az.pub-ip.psi.net [38.29.122.219]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id EAA17553; Wed, 18 Oct 2000 04:20:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: In-Reply-To: <01C038E7.37244AA0.era.als@get2net.dk> References: <01C038E7.37244AA0.era.als@get2net.dk> Date: Wed, 18 Oct 2000 01:19:35 -0700 To: Erik Andersen , "Bull exploder (E-mail)" , "ISSS-WS-DIR (E-mail)" From: "Hoyt L. Kesterson II" Subject: Re: Edition 4 of X.500 Cc: "Herbert V. Bertine (E-mail)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" thanks for reminding me erik. i created the PDFs the day you sent me the texts but for some reason did not put them up on the server. they are there now as V2 PDFs and Office 98 docs at ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ i'll get the DTCs up this week hoyt At 9:25 AM +0200 10/18/00, Erik Andersen wrote: >Hi Folks, > >The edition 4 text was submitted to ITU-T before the deadline 9 October, >9.00 AM. I also sent a copy to Hoyt to put on the server. I have also asked >that the text be put on the ISSS server for people that find it more >convenient to access that server. Please be aware that this is not the >absolute final text. The text will be amended to reflect the ballot >resolutions on Related Entries and Draft Technical Corrigenda. It is >expected that amendment text will be produced during our Orlando meeting. > >There are also a number of new Draft Technical Corrigenda that should also >be put on the servers. > > >Erik Andersen >CEN/ISSS/WS-DIR Chairman >Mobile: +45 20 97 14 90 >E-mail; era.als@get2net.dk >Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm >Public server: ftp://ftp.cenorm.be/pub/dir --=_4119984A.D9B8D414-- From list@netscape.com Wed Oct 18 16:39: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 QAA28903 for ; Wed, 18 Oct 2000 16:39: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 e9IKTFD24180; Wed, 18 Oct 2000 13:29:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9IKaFc23583; Wed, 18 Oct 2000 13:36:15 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 13:36:15 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 18 Oct 2000 14:35:55 -0600 From: "Steve Sonntag" To: Cc: , , "Alan Clark" , "Steven Merrill" Subject: Java LDAP API - LDAPControl class Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_124AC8A4.3B5A2191" Resent-Message-ID: <"IVIf7.A._vF.-mg75"@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. --=_124AC8A4.3B5A2191 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The LDAPControl class needs a setValue method. I realize that the value can be set on the constructor, but take the following example. Suppose I want to build a class in my application that extends control to build my control, for example, server side sort. =20 public class LDAPSortControl extends LDAPControl { static String oid=3D"1.2.840.113556.1.4.473"; public LDAPSortControl( boolean critical, LDAPSortKey key) { super( oid, critical, (byte[])null); // This line must be first in = the constructor // oops, we haven't built the control value yet - how do we pass = it in to=20 // the LDAPControl object???? // need a setValue method to get the job done. } Suggested prototype - public setValue( byte[] value); -Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software --=_124AC8A4.3B5A2191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The LDAPControl class needs a setValue method.
 
I realize that the value can be set on the constructor, but take
=
the following example.
 
Suppose I want to build a class in my application that extends
control to build my control, for example, server side sort. = =20
 
public class LDAPSortControl extends LDAPControl
{
  static String oid=3D"1.2.840.113556.1.4.473";
  public  LDAPSortControl( boolean critical, LDAPSortKey=20 key)
  {
     super( oid, critical, (byte[])null);  = // This=20 line must be first in the constructor
        // oops, we haven't built = the=20 control value yet - how do we pass it in to
        // the LDAPControl=20 object????
        // need a setValue method = to get=20 the job done.
  }
 
Suggested prototype -
 
public setValue( byte[] value);
 
-Steve
 
------------------------
Steve Sonntag
Novell, Inc., the = leading=20 provider of Net services software
 
 
--=_124AC8A4.3B5A2191-- From list@netscape.com Wed Oct 18 17:06: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 RAA02443 for ; Wed, 18 Oct 2000 17:06: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 e9IKr3s26892; Wed, 18 Oct 2000 13:53:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9IL4UE09059; Wed, 18 Oct 2000 14:04:30 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 14:04:30 -0700 (PDT) Message-ID: <39EE0FD1.61EABFAD@worldspot.com> Date: Wed, 18 Oct 2000 14:02:09 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com, miodrag@netscape.com, Alan Clark , Steven Merrill Subject: Re: Java LDAP API - LDAPControl class References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ueg8t.A.wMC.bBh75"@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 Does it need to be public? If it's only for use by extensions (and I think that is the case), the method can be protected instead. Rob Steve Sonntag wrote: > The LDAPControl class needs a setValue method. I realize that the > value can be set on the constructor, but takethe following > example. Suppose I want to build a class in my application that > extendscontrol to build my control, for example, server side > sort. public class LDAPSortControl extends LDAPControl{ static String > oid="1.2.840.113556.1.4.473"; public LDAPSortControl( boolean > critical, LDAPSortKey key) { super( oid, critical, > (byte[])null); // This line must be first in the constructor > // oops, we haven't built the control value yet - how do we pass it in > to // the LDAPControl object???? // need a setValue > method to get the job done. } Suggested prototype - public setValue( > byte[] value); -Steve ------------------------ > Steve Sonntag > Novell, Inc., the leading provider of Net services software From list@netscape.com Wed Oct 18 18:23: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 SMTP id SAA11168 for ; Wed, 18 Oct 2000 18:23: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 e9IMArs09406; Wed, 18 Oct 2000 15:10:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9IMMLs19290; Wed, 18 Oct 2000 15:22:21 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 15:22:21 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 18 Oct 2000 16:21:51 -0600 From: "Steve Sonntag" To: Cc: , , "Alan Clark" , "Steven Merrill" Subject: Re: Java LDAP API - LDAPControl class Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0058DA9D.7E1F64E9" Resent-Message-ID: <"xaFgsC.A.nsE.aKi75"@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. --=_0058DA9D.7E1F64E9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree protected is adequate -Steve >>> Rob Weltman 18-Oct-00 3:02:09 PM >>> Does it need to be public? If it's only for use by extensions (and I think that is the case), the method can be protected instead. Rob Steve Sonntag wrote: > The LDAPControl class needs a setValue method. I realize that the > value can be set on the constructor, but takethe following > example. Suppose I want to build a class in my application that > extendscontrol to build my control, for example, server side > sort. public class LDAPSortControl extends LDAPControl{ static String > oid=3D"1.2.840.113556.1.4.473"; public LDAPSortControl( boolean > critical, LDAPSortKey key) { super( oid, critical, > (byte[])null); // This line must be first in the constructor > // oops, we haven't built the control value yet - how do we pass it in > to // the LDAPControl object???? // need a setValue > method to get the job done. } Suggested prototype - public setValue( > byte[] value); -Steve ------------------------ > Steve Sonntag > Novell, Inc., the leading provider of Net services software --=_0058DA9D.7E1F64E9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree protected is adequate
 
-Steve

>>> Rob Weltman <robw@worldspot.com> = 18-Oct-00=20 3:02:09 PM >>>
  Does it need to be public? If it's only = for=20 use by extensions (and I
think that is the case), the method can be = protected=20 instead.

Rob

Steve Sonntag wrote:

>  The=20 LDAPControl class needs a setValue method. I realize that the
> = value can=20 be set on the constructor, but takethe following
> example. Suppose = I want=20 to build a class in my application that
> extendscontrol to build = my=20 control, for example, server side
> sort. public class LDAPSortContro= l=20 extends LDAPControl{  static String
>=20 oid=3D"1.2.840.113556.1.4.473";  public  LDAPSortControl(=20 boolean
> critical, LDAPSortKey key)  {    = =20 super( oid, critical,
> (byte[])null);  // This line must be = first in=20 the constructor
> // oops, we haven't built the control value yet - = how do=20 we pass it in
> to        // = the=20 LDAPControl object????        // need = a=20 setValue
> method to get the job done.  } Suggested prototype = -=20 public setValue(
> byte[] value); -Steve ------------------------
= >=20 Steve Sonntag
> Novell, Inc., the leading provider of Net services=20= software

--=_0058DA9D.7E1F64E9-- From list@netscape.com Wed Oct 18 18:34:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12395 for ; Wed, 18 Oct 2000 18:34: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 e9IMLms11370; Wed, 18 Oct 2000 15:21:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9IMXGs25361; Wed, 18 Oct 2000 15:33:16 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 15:33:16 -0700 (PDT) Message-Id: <5.0.0.25.0.20001018152735.00a69d20@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 18 Oct 2000 15:31:45 -0700 To: "Steve Sonntag" , From: Bruce Greenblatt Subject: Re: Java LDAP API - LDAPControl class Cc: , , "Alan Clark" , "Steven Merrill" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15747413==_.ALT" Resent-Message-ID: <"2yqDmB.A.sLG.pUi75"@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 --=====================_15747413==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I would expect that when the LDAPControl is subclassed for a specific control that a better SetValue() method would be provided in the subclass. For example, if the value of the control is essentially a string, I would hope to see the subclass define a SetValue() method such as: public setValue(String value); So, in the description of the SetValue() method, I would like to see language that indicates that implementors of subclasses of "control specific" LDAPControls SHOULD provide a setValue() method that is specific to the value of the control being implemented... Bruce At 03:21 PM 10/18/2000, Steve Sonntag wrote: >I agree protected is adequate > >-Steve > > >>> Rob Weltman 18-Oct-00 3:02:09 PM >>> > Does it need to be public? If it's only for use by extensions (and I >think that is the case), the method can be protected instead. > >Rob > >Steve Sonntag wrote: > > > The LDAPControl class needs a setValue method. I realize that the > > value can be set on the constructor, but takethe following > > example. Suppose I want to build a class in my application that > > extendscontrol to build my control, for example, server side > > sort. public class LDAPSortControl extends LDAPControl{ static String > > oid="1.2.840.113556.1.4.473"; public LDAPSortControl( boolean > > critical, LDAPSortKey key) { super( oid, critical, > > (byte[])null); // This line must be first in the constructor > > // oops, we haven't built the control value yet - how do we pass it in > > to // the LDAPControl object???? // need a setValue > > method to get the job done. } Suggested prototype - public setValue( > > byte[] value); -Steve ------------------------ > > Steve Sonntag > > Novell, Inc., the leading provider of Net services software ============================================== 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 --=====================_15747413==_.ALT Content-Type: text/html; charset="us-ascii" I would expect that when the LDAPControl is subclassed for a specific control that a better SetValue() method would be provided in the subclass.  For example, if the value of the control is essentially a string, I would hope to see the subclass define a SetValue() method such as:

public setValue(String value);

So, in the description of the SetValue() method, I would like to see language that indicates that implementors of subclasses of "control specific" LDAPControls SHOULD provide a setValue() method that is specific to the value of the control being implemented...

Bruce

At 03:21 PM 10/18/2000, Steve Sonntag wrote:
I agree protected is adequate
 
-Steve

>>> Rob Weltman <robw@worldspot.com> 18-Oct-00 3:02:09 PM >>>
  Does it need to be public? If it's only for use by extensions (and I
think that is the case), the method can be protected instead.

Rob

Steve Sonntag wrote:

>  The LDAPControl class needs a setValue method. I realize that the
> value can be set on the constructor, but takethe following
> example. Suppose I want to build a class in my application that
> extendscontrol to build my control, for example, server side
> sort. public class LDAPSortControl extends LDAPControl{  static String
> oid="1.2.840.113556.1.4.473";  public  LDAPSortControl( boolean
> critical, LDAPSortKey key)  {     super( oid, critical,
> (byte[])null);  // This line must be first in the constructor
> // oops, we haven't built the control value yet - how do we pass it in
> to        // the LDAPControl object????        // need a setValue
> method to get the job done.  } Suggested prototype - public setValue(
> byte[] value); -Steve ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software

==============================================
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 --=====================_15747413==_.ALT-- From list@netscape.com Wed Oct 18 18:58: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 SAA15003 for ; Wed, 18 Oct 2000 18:58: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 e9IMncD24444; Wed, 18 Oct 2000 15:49:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9IMucQ08446; Wed, 18 Oct 2000 15:56:38 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 15:56:38 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 18 Oct 2000 16:56:18 -0600 From: "Steve Sonntag" To: , Cc: , , "Alan Clark" , "Steven Merrill" Subject: Re: Java LDAP API - LDAPControl class Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1C44C689.7C1D66ED" Resent-Message-ID: <"TfrYgD.A.ODC.kqi75"@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. --=_1C44C689.7C1D66ED Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree, but you still need a way to populate the date into the LDAPControl class, i.e. still need the method in LDAPControl. -Steve >>> Bruce Greenblatt 18-Oct-00 = 4:31:45 PM >>> I would expect that when the LDAPControl is subclassed for a specific = control that a better SetValue() method would be provided in the subclass. = For example, if the value of the control is essentially a string, I would = hope to see the subclass define a SetValue() method such as: public setValue(String value); So, in the description of the SetValue() method, I would like to see = language that indicates that implementors of subclasses of "control = specific" LDAPControls SHOULD provide a setValue() method that is specific = to the value of the control being implemented... Bruce At 03:21 PM 10/18/2000, Steve Sonntag wrote: I agree protected is adequate =20 -Steve >>> Rob Weltman 18-Oct-00 3:02:09 PM >>> Does it need to be public? If it's only for use by extensions (and I think that is the case), the method can be protected instead. Rob Steve Sonntag wrote: > The LDAPControl class needs a setValue method. I realize that the > value can be set on the constructor, but takethe following > example. Suppose I want to build a class in my application that > extendscontrol to build my control, for example, server side > sort. public class LDAPSortControl extends LDAPControl{ static String > oid=3D"1.2.840.113556.1.4.473"; public LDAPSortControl( boolean > critical, LDAPSortKey key) { super( oid, critical, > (byte[])null); // This line must be first in the constructor > // oops, we haven't built the control value yet - how do we pass it in > to // the LDAPControl object???? // need a setValue > method to get the job done. } Suggested prototype - public setValue( > byte[] value); -Steve ------------------------ > Steve Sonntag > Novell, Inc., the leading provider of Net services software =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 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=20 --=_1C44C689.7C1D66ED Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I agree, but you still need a way to populate = the
date into the LDAPControl class, i.e. still need
the method in LDAPControl.
 
-Steve

>>> Bruce Greenblatt=20 <bgreenblatt@directory-applications.com> 18-Oct-00 4:31:45 PM=20 >>>
I would expect that when the LDAPControl is subclassed for = a=20 specific control that a better SetValue() method would be provided in = the=20 subclass.  For example, if the value of the control is essentially = a=20 string, I would hope to see the subclass define a SetValue() method = such=20 as:

public setValue(String value);

So, in the description of = the=20 SetValue() method, I would like to see language that indicates that = implementors=20 of subclasses of "control specific" LDAPControls SHOULD provide a = setValue()=20 method that is specific to the value of the control being=20 implemented...

Bruce

At 03:21 PM 10/18/2000, Steve Sonntag=20= wrote:
I agree = protected is=20 adequate
 
-Steve

>>> Rob Weltman=20 <robw@worldspot.com> 18-Oct-00 3:02:09 PM >>>
  = Does it=20 need to be public? If it's only for use by extensions (and I
think = that is=20 the case), the method can be protected instead.

Rob

Steve= =20 Sonntag wrote:

>  The LDAPControl class needs a = setValue=20 method. I realize that the
> value can be set on the constructor, = but=20 takethe following
> example. Suppose I want to build a class in = my=20 application that
> extendscontrol to build my control, for = example,=20 server side
> sort. public class LDAPSortControl extends=20 LDAPControl{  static String
> oid=3D"1.2.840.113556.1.4.473";&= nbsp;=20 public  LDAPSortControl( boolean
> critical, LDAPSortKey = key) =20 {     super( oid, critical,
> (byte[])null);&nb= sp;=20 // This line must be first in the constructor
> // oops, we = haven't=20 built the control value yet - how do we pass it in
>=20 to        // the LDAPControl=20 object????        // need a=20 setValue
> method to get the job done.  } Suggested prototype = -=20 public setValue(
> byte[] value); -Steve=20 ------------------------
> Steve Sonntag
> Novell, Inc., = the=20 leading provider of Net services software

=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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
<= /A>See my=20 new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html

--=_1C44C689.7C1D66ED-- From list@netscape.com Wed Oct 18 23:28:02 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16572 for ; Wed, 18 Oct 2000 23:28: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 e9J3JVD01252; Wed, 18 Oct 2000 20:19:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9J3QUE27440; Wed, 18 Oct 2000 20:26:30 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 20:26:30 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 18 Oct 2000 21:24:49 -0600 From: "Ed Reed" To: Cc: , Subject: Re: Fwd: controlling visability of subentries 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 e9J3QSr27413 Resent-Message-ID: <"WTIs1D.A.bsG.lnm75"@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 Okay, Kurt - I've reviewed what X.511 specifies for the service control used to control subentry visibility. What is your opinion on what we should do in LDAP? 1) create a control which has no parameters, but has the effect that when it is present, it is interpreted identically to an X.511 service control with the subentries bit set TRUE; or 2) create a control which has a parameter identical to the service control specified by X.511. This would have the effect of providing a lot of the additional controls needed to add distributed operations to LDAP (including preferChaining, chainingProhibited, etc.), but would also provide things like timeLimit, sizeLimit, scopeOfReferral, and attributeSizeLimit, etc. In X.511, the serviceControls are among the CommonArguments included with each request. I suppose we could consider the list of controls in LDAP providing the equivalent to the set of CommonArguments. What's your take? 1 would be easier to document. 2 would lay important groundwork that should be considered in the context of future work to add distributed operations to LDAP. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 08/01/00 07:41AM >>> Forwarded to LDUP list >Date: Mon, 31 Jul 2000 16:23:57 -0400 >To: ietf-ldapext@OpenLDAP.org >From: "Kurt D. Zeilenga" >Subject: controlling visability of subentries > >One other issue I would like to raise in regards to LDAP subentry >is the mechanism proposed to control their visibility. I believe >the approach of overloading the search filter to control visibility >is not the best approach. As we've found previously, the semantics >of such overloads are difficult to define (and hence implement) when >the filter is complex (which we must assume it will be). > >I believe that LDAPsubentry visibility should be control by a mechanism >more closely modeled after the X.500 subentry visibility mechanism. >In particular, I suggest use of a control. The use of a control >will allow a clear and concise specification of visibility semantics >which facilitates implementation and use. > >Comments? > > Kurt From list@netscape.com Thu Oct 19 02:48: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 SMTP id CAA01206 for ; Thu, 19 Oct 2000 02:48: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 e9J6Wos26102; Wed, 18 Oct 2000 23:32:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9J6iJg10018; Wed, 18 Oct 2000 23:44:19 -0700 (PDT) Resent-Date: Wed, 18 Oct 2000 23:44:19 -0700 (PDT) Date: Wed, 18 Oct 2000 23:43:54 -0700 (PDT) Message-Id: <200010190643.e9J6hsR10526@xwing.netscape.com> From: Mr.D.Bowden@xwing.netscape.com To: .XVVF@netscape.com Subject: $2,000,000 in YOUR Mailbox$$$ X-Reply-To: dbsg5834@mail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7JbtEB.A.LcC.Bhp75"@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 NEW program has been designed to turn everyday people into MILLIONAIRES without a large investment!!! Dear Investor, This email will change your life. It contains the entire method of how YOU CAN EARN $2,000,000 and live a life of luxury. Join the long list of new Millionaires in the world who have made their fortune from MLM. The results have 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. You will understand once you try it yourself! ********* THE ENTIRE PLAN IS HERE BELOW ********* *** Print This Now For Future Reference *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least 2 Million Dollars Please read this program...THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money This simplified e-mail marketing program works perfectly 100% EVERY TIME! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This Marketing Program WILL MAKE YOU A FORTUNE$$$ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Unlike other MLM programs that make you money from 4 levels, this program will build you wealth from 8 levels deep which means your potential income is HUGE!!!! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you delete this program from your in box, 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!!! $$$ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU 2 MILLION DOLLAR$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $2M or more in the next twelve months. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making business. 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 sell and deliver a product for EVERY dollar received. 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 EASIEST marketing plan anywhere! It is simply order filling by email! By the way there are over 50 MILLION email addresses with millions more ! joining the internet each year so don't worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter. I received this letter many times - then one day I decided it was time to try it. ******************************************************************* Your cost to participate in this is practically nothing (surely you can afford $40 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! IT'S THIS SIMPLE: STEP 1 - You order the 8 reports listed below ($5 each) They come to you by email. They will be emailed to you a few days after you order them. STEP 2 - Save a copy of this entire letter and put your name after Report #1 and move the other names down. The Name and Address at Report #1 moves down to Report #2, Move all the other names down to the Report below. The name currently at Report #8 is removed completely. This person has already been through the cycle and made a FORTUNE$$$. STEP 3 - Use any of the hundreds of bulk email services (search for "Bulk Email") and have them send 25,000 - 50,000 emails for you (about $49+). You send this modified letter with YOUR NAME in POSITION #1. STEP 4 - Orders will come to you by postal mail (With $5 CASH!!) - simply email them the Report they ordered. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Advertising on the internet 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 5 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 5 downline members. Look how this small number accumulates to achieve the STAGGERING results below:! 1st level--your first 5 send you $5................................$25 2nd level--5 members from those 5 ($5 x 25)......................$125 3rd level--5 members from those 25 ($5 x 125)...................$625 4th level--5 members from those 125 ($5 x 625)...............$3,125 5th level--5 members from those 625 ($5 x 3,125)...........$15,625 6th level--5 members from those 3,125 ($5 x 15,625).......$78,125 7th level--5 members from those 15,625 ($5 x 78,125).....$390,625 8th level--5 members from those 78,125 ($5 x 390,625).$1,953,125 $$$$$$ THIS TOTALS ----------$2,441,400 $$$$$$ AMAZING ISN'T IT? Remember friends, this assumes that the people who participate only recruit 5 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are going to get emails about this plan from you or somebody else and many will work this plan - the question is - Don't you want your name to be! on the emails they will send out? * * * DON'T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * * * SEE WHAT HAPPENS!!! *** YOU'LL BE AMAZED!!!* * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET STARTED TODAY: PLACE YOUR ORDER FOR THE EIGHT REPORTS NOW. Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets of paper write: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. REPORT #1 "ADVERTISING FOR FREE ON THE INTERNET" ORDER REPORT #1 FROM: David Bowden P.O.Box 1036 Lismore, N.S.W 2480 Australia REPORT #2 "FREE AND LOW COST SITES TO PLACE CLASSIFIED ADS" ORDER REPORT #2 FROM: Mahlon Rissler 1311 Greystone Street Harrisonburg, VA. 22802 REPORT #3 "TIPS FOR CHOOSING A BULK E-MAIL COMPANY" ORDER REPORT #3 FROM: Thomas Ford 1081 hwy 121 leesville, LA. 71446 REPORT #4 "8 POINTS TO CONSIDER WHEN SENDING YOUR OWN BULK E-MAILS" ORDER REPORT #4 FROM: Susan A. Lear 106 Pottawatomie St Hiawatha, KS. 66434-2535 REPORT #5 "THE SECRETS TO MULTI-LEVEL MARKETING ON THE INTERNET" ORDER REPORT #5 FROM: Hank Vos P.O.Box 353 Beecroft N.S.W. 2119 Australia REPORT #6 "YOUR E-MAIL REPORT BUSINESS" ORDER REPORT #6 FROM: Ms. Jeanette Valencia 899 Via Savalza Rio Rico, AZ 85648 REPORT #7 "HOW TO BECOME A MILLIONAIRE UTILIZING THE POWER OF MLM AND THE INTERNET" ORDER REPORT #7 FROM: Grandfive P.O.Box 11025 Jackson, TN 38308 REPORT #8 "MARKETING YOUR MLM PROGRAM" ORDER REPORT #8 FROM: John Howell 6209 Ridge Rd. #4 Parma, OH. 44129 *********************************************************** 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 and you'll lose out on a lot of money! You must order all eight reports! You can not sell them if you don't have them!! ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the eight 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. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program - If you follow the instructions exactly - results WILL follow. $$$$ ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 10 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 50 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 50 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! To generate more income, simply 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. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1. NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start!, Nothing to learn, NO skills needed! (Surely you know how to send email?) 2. No equipment to buy - you already have a computer and internet connection - so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Emailing copies of the reports is FREE!) 4. All of your customers pay you in CA$$H! This program will change your LIFE FOREVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above -- SUCCESS will be your reward. Thank you for your time and consideration. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ************************************************* From list@netscape.com Thu Oct 19 04:01: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 EAA09923 for ; Thu, 19 Oct 2000 04:01: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 e9J7qJD20953; Thu, 19 Oct 2000 00:52:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9J7xJw27796; Thu, 19 Oct 2000 00:59:19 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 00:59:19 -0700 (PDT) From: fgw3@aol.com Message-Id: <200010190759.QAI00528@mail.elflow.com> To: jkn8@aol.com Subject: The time to switch from cable to satellite is now! Date: Thu, 19 Oct 00 03:43:34 Eastern Daylight Time Reply-To: fgw3@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: <"0FOqJC.A.ZxG.Vnq75"@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; If you've ever considered switching from cable to satellite now is the time.

The benefits of satellite television:

* Affordable -- No equipment to purchase
* Excellent Quality -- Because it's digital, the picture and sound is crystal clear
* More Programming -- Dish offers all your favorite channels + pay per view movies
* Local Channels -- Now you can get your own local channels delivered to your home.

The benefits of subscribing now:

* Free shipping
* Free Installation
* 30 day satisfaction guarantee
* FREE HBO, STARZ ENCORE, CINEMAX, SHOWTIME for 3 months

When you sign up you will get America's Top 100 channels for only $34.99 a
month or America's Top 150 for only 44.99 a month.

America's Top 150 Programming Package includes:
Sports-- ESPN, ESPN2, ESPN News, ESPN Classic, Outdoor Life Network,
SpeedVision, Golf Channel
News -- CNN, CNN Headline News, BBC, All-News Network, Bloomberg, C-Span,
C-Span 2, Fox News, MSNBC, CNN FN, CNN International
Music -- MTV, VH1, Much Music, MTV 2, Country Music Television,
Learning -- Discovery Channel, Discovery Health Channel , Discovery Science
Channel, Discovery Wings Channel, Discovery Civilization Channel, Discovery
People, DIY, The Learning Channel, History Channel, History Channel
International, Food Network, Mystery, Travel, E!, Biography, Animal Planet,
Noggin, America's Voice
Variety -- A&E, BET ZDTV, Court TV, Health Network, Home Shopping, QVC, TNN,
Weather Channel, TNT, hBoomerang,, USA, TBN, Bravo, Comedy Central, Game Show,
FX, Sci-Fi Channel, TV Land, AMC, Turner Classic Movies, Univision, The Outdoor
Channel, Turner South. Fox Movie Channel,
Kids -- The Cartoon Network, The Disney Channel, The Disney Toon Channel,
Nickelodeon, The Fox Family Channel, The Discovery Kids Channel
Music -- Over 30 channels of CD quality music!

* Must be a first time Dish Network customer, continental US only.
* Ask us about our great gift/Christmas gift special--Complete satellite
system with Free installation only $49.00. The perfect gift certificate for
all occasions.


Please call us now at 1-877-728-1500 Mention Code: LOB

 ------=_NextPart_000_018C_01BD9940.715D52A0-- From list@netscape.com Thu Oct 19 04:05: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 EAA10293 for ; Thu, 19 Oct 2000 04:05: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 e9J7uYD21749; Thu, 19 Oct 2000 00:56:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9J83Yk00516; Thu, 19 Oct 2000 01:03:34 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 01:03:34 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'Ed Reed'" , Kurt@openldap.org Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 10:02:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"UfjpKD.A.6G.Srq75"@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 Hi Ed, I personally think that solution 2 is the best one, specially for the future. If you take solution 1 it will also work, but at least you will create a control for every additional service control you will support. I think to work with a control is a clean solution but the number of controls increase rapitly and different servers have a lot of different controls they support. I think there is the requirement that the protocol has to be compatible and only some administrative clients will use this feature and a simple LDAP Client should not been broken. We handle subentries over LDAP for all update operations like normal entries and for the search in a special way, so if the filter contains ObjectClass=SUBENTRY the search operation is only for subentries and all other search operations exclude subentries. Is this a problem ? > -----Original Message----- > From: Ed Reed [mailto:eer@OnCallDBA.COM] > Sent: Thursday, October 19, 2000 5:25 AM > To: Kurt@OpenLDAP.org > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: Re: Fwd: controlling visability of subentries > > > Okay, Kurt - I've reviewed what X.511 specifies for the > service control > used to control subentry visibility. What is your opinion on > what we should > do in LDAP? > > 1) create a control which has no parameters, but has the > effect that when > it is present, it is interpreted identically to an X.511 > service control with the > subentries bit set TRUE; or > > 2) create a control which has a parameter identical to the > service control > specified by X.511. This would have the effect of providing > a lot of the > additional controls needed to add distributed operations to > LDAP (including > preferChaining, chainingProhibited, etc.), but would also > provide things > like timeLimit, sizeLimit, scopeOfReferral, and > attributeSizeLimit, etc. > In X.511, the serviceControls are among the CommonArguments included > with each request. > > I suppose we could consider the list of controls in LDAP providing the > equivalent to the set of CommonArguments. > > What's your take? 1 would be easier to document. 2 would lay > important groundwork that should be considered in the context > of future > work to add distributed operations to LDAP. > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >Subject: controlling visability of subentries > > > >One other issue I would like to raise in regards to LDAP subentry > >is the mechanism proposed to control their visibility. I believe > >the approach of overloading the search filter to control visibility > >is not the best approach. As we've found previously, the semantics > >of such overloads are difficult to define (and hence implement) when > >the filter is complex (which we must assume it will be). > > > >I believe that LDAPsubentry visibility should be control by > a mechanism > >more closely modeled after the X.500 subentry visibility mechanism. > >In particular, I suggest use of a control. The use of a control > >will allow a clear and concise specification of visibility semantics > >which facilitates implementation and use. > > > >Comments? > > > > Kurt > > From list@netscape.com Thu Oct 19 08:14: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 IAA11072 for ; Thu, 19 Oct 2000 08:14: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 e9JC5dD10858; Thu, 19 Oct 2000 05:05:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JCCcc08390; Thu, 19 Oct 2000 05:12:38 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 05:12:38 -0700 (PDT) To: Stockwinner@aol.com From: Subject: Stock Pick of the Week Message-ID: <076a911081213a0CPIMSSMTPU10@email.msn.com> Date: 19 Oct 2000 05:08:21 -0700 Resent-Message-ID: <"E1BusB.A.tBC.yUu75"@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 >>> STOCK PICK OF THE WEEK <<< For the week beginning Monday, 10-16-2000 Investment Snapshot - ATTP -- Affordable Telecom http://moneycentral.msn.com/scripts/webquote.dll?iPage=qd&Symbol=attp Target Price: $1.00 Current Price: $.18 Take a close look at this stock, it's going to rise fast! Monday it was $.12...It's jumping each day HOUSTON--(BUSINESS WIRE)--Oct. 3, 2000--Affordable Telecommunications Technology Corporation (OTC BB:ATTP) announced today its preliminary third quarter revenues will exceed expectations. Affordable Telecommunications announced preliminary projected revenues of $500,000 for the quarter ending September 30, 2000. Steven H. Bethke, president of Affordable Telecommunications, said, "We are extremely pleased to anticipate a 460% year-over-year increase in revenues, which exceed our expectations. Strong revenue gains indicate we are on track in building our revenue base through strategic marketing arrangements with leaders in the wireless industry." The Company expects to report its finalized quarterly results on or before November 15, 2000. From list@netscape.com Thu Oct 19 09:08: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 JAA22755 for ; Thu, 19 Oct 2000 09:08: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 e9JD03D15246; Thu, 19 Oct 2000 06:00:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JD74k23091; Thu, 19 Oct 2000 06:07:04 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 06:07:04 -0700 (PDT) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <39EEF1F1.4345A416@netscape.com> Date: Thu, 19 Oct 2000 09:06:57 -0400 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: "Volpers Helmut" CC: "'Ed Reed'" , Kurt@openldap.org, ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Fwd: controlling visability of subentries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8MtySD.A.eoF.2Hv75"@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 problem I see with solution 2 (create a control that mimics the X511 ServiceControls) is that there would be no way for an LDAP client to discover the subset of ServiceControls that is supported on a given LDAP server. Surely we are not going to require support for everything in ServiceControls just to solve the subentry problem. Therefore, I prefer solution 1. And so everyone knows what we are talking about, from X.511: A ServiceControls parameter contains the controls, if any, that are to direct or constrain the provision of the service. ServiceControls ::= SET { options [0] BIT STRING { preferChaining (0), chainingProhibited (1), localScope (2), dontUseCopy (3), dontDereferenceAliases (4), subentries (5), copyShallDo (6), } DEFAULT {}, partialNameResolution (7), manageDSAIT (8) } } DEFAULT {}, priority [1] INTEGER { low (0), medium (1), high (2) } DEFAULT medium, timeLimit [2] INTEGER OPTIONAL, sizeLimit [3] INTEGER OPTIONAL, scopeOfReferral [4] INTEGER { dmd(0), country(1) } OPTIONAL, attributeSizeLimit [5] INTEGER OPTIONAL manageDSAITPlaneRef [6] SEQUENCE { dsaName Name, agreementID AgreementID } OPTIONAL } -- Mark Smith Netscape Communications Corp. "Volpers, Helmut" wrote: > > Hi Ed, > > I personally think that solution 2 is the best one, specially for > the future. > If you take solution 1 it will also work, but at least you will create > a control for every additional service control you will support. > I think to work with a control is a clean solution but the number > of controls increase rapitly and different servers have a lot of > different controls they support. > I think there is the requirement that the protocol has to be compatible > and only some administrative clients will use this feature and a simple > LDAP Client should not been broken. > We handle subentries over LDAP for all update operations like normal entries > and for the search in a special way, so if the filter contains > ObjectClass=SUBENTRY > the search operation is only for subentries and all other search operations > exclude subentries. Is this a problem ? > > > -----Original Message----- > > From: Ed Reed [mailto:eer@OnCallDBA.COM] > > Sent: Thursday, October 19, 2000 5:25 AM > > To: Kurt@OpenLDAP.org > > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > > Subject: Re: Fwd: controlling visability of subentries > > > > > > Okay, Kurt - I've reviewed what X.511 specifies for the > > service control > > used to control subentry visibility. What is your opinion on > > what we should > > do in LDAP? > > > > 1) create a control which has no parameters, but has the > > effect that when > > it is present, it is interpreted identically to an X.511 > > service control with the > > subentries bit set TRUE; or > > > > 2) create a control which has a parameter identical to the > > service control > > specified by X.511. This would have the effect of providing > > a lot of the > > additional controls needed to add distributed operations to > > LDAP (including > > preferChaining, chainingProhibited, etc.), but would also > > provide things > > like timeLimit, sizeLimit, scopeOfReferral, and > > attributeSizeLimit, etc. > > In X.511, the serviceControls are among the CommonArguments included > > with each request. > > > > I suppose we could consider the list of controls in LDAP providing the > > equivalent to the set of CommonArguments. > > > > What's your take? 1 would be easier to document. 2 would lay > > important groundwork that should be considered in the context > > of future > > work to add distributed operations to LDAP. > > > > Ed > > > > ================= > > Ed Reed > > Reed-Matthews, Inc. > > +1 801 796 7065 > > http://www.Reed-Matthews.COM > > > > >>> "Kurt D. Zeilenga" 08/01/00 07:41AM >>> > > Forwarded to LDUP list > > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > > >To: ietf-ldapext@OpenLDAP.org > > >From: "Kurt D. Zeilenga" > > >Subject: controlling visability of subentries > > > > > >One other issue I would like to raise in regards to LDAP subentry > > >is the mechanism proposed to control their visibility. I believe > > >the approach of overloading the search filter to control visibility > > >is not the best approach. As we've found previously, the semantics > > >of such overloads are difficult to define (and hence implement) when > > >the filter is complex (which we must assume it will be). > > > > > >I believe that LDAPsubentry visibility should be control by > > a mechanism > > >more closely modeled after the X.500 subentry visibility mechanism. > > >In particular, I suggest use of a control. The use of a control > > >will allow a clear and concise specification of visibility semantics > > >which facilitates implementation and use. > > > > > >Comments? > > > > > > Kurt > > > > From list@netscape.com Thu Oct 19 09:37: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 JAA27941 for ; Thu, 19 Oct 2000 09:37: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 e9JDOis25218; Thu, 19 Oct 2000 06:24:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JDaFg01377; Thu, 19 Oct 2000 06:36:15 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 06:36:15 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 19 Oct 2000 07:35:10 -0600 From: "Ed Reed" To: , Cc: , Subject: RE: Fwd: controlling visability of subentries 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 e9JDaDr01350 Resent-Message-ID: <"dRo7vC.A.MV.Njv75"@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 Hi, Helmut - The ObjectClass=SUBENTRY approach (call that option 3) was my original suggestion, but the objection to that is that search filters can quickly become very complex, particularly if there are other similar "special" filters to add to the mix, and that pulling them out into a control allows much more clarity of the search filters themselves. Reasonable. So, I agree a control is prefered, and now we need to decide what that control should look like - and thus my mail note. In another response, Mark Smith copied the X.511 description of the service control data strcture which governs subentry visibility as part of the CommonArguments parameter of X.500 requests. And he points out that there is a lot of stuff there that not everyone will support in the near (or even distant) future. I suppose the "LDAP" thing to do would be to create a separate control for subentry visibility, and if some LDAPv3bis work item in the future wants to consolidate several controls into a single control ala X.511 we can consider that then. My current thinking is that makes sense. But - would like to hear from more of the lists, first. Thanks, Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Volpers, Helmut" 10/19/00 02:03AM >>> Hi Ed, I personally think that solution 2 is the best one, specially for the future. If you take solution 1 it will also work, but at least you will create a control for every additional service control you will support. I think to work with a control is a clean solution but the number of controls increase rapitly and different servers have a lot of different controls they support. I think there is the requirement that the protocol has to be compatible and only some administrative clients will use this feature and a simple LDAP Client should not been broken. We handle subentries over LDAP for all update operations like normal entries and for the search in a special way, so if the filter contains ObjectClass=SUBENTRY the search operation is only for subentries and all other search operations exclude subentries. Is this a problem ? > -----Original Message----- > From: Ed Reed [mailto:eer@OnCallDBA.COM] > Sent: Thursday, October 19, 2000 5:25 AM > To: Kurt@OpenLDAP.org > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: Re: Fwd: controlling visability of subentries > > > Okay, Kurt - I've reviewed what X.511 specifies for the > service control > used to control subentry visibility. What is your opinion on > what we should > do in LDAP? > > 1) create a control which has no parameters, but has the > effect that when > it is present, it is interpreted identically to an X.511 > service control with the > subentries bit set TRUE; or > > 2) create a control which has a parameter identical to the > service control > specified by X.511. This would have the effect of providing > a lot of the > additional controls needed to add distributed operations to > LDAP (including > preferChaining, chainingProhibited, etc.), but would also > provide things > like timeLimit, sizeLimit, scopeOfReferral, and > attributeSizeLimit, etc. > In X.511, the serviceControls are among the CommonArguments included > with each request. > > I suppose we could consider the list of controls in LDAP providing the > equivalent to the set of CommonArguments. > > What's your take? 1 would be easier to document. 2 would lay > important groundwork that should be considered in the context > of future > work to add distributed operations to LDAP. > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >Subject: controlling visability of subentries > > > >One other issue I would like to raise in regards to LDAP subentry > >is the mechanism proposed to control their visibility. I believe > >the approach of overloading the search filter to control visibility > >is not the best approach. As we've found previously, the semantics > >of such overloads are difficult to define (and hence implement) when > >the filter is complex (which we must assume it will be). > > > >I believe that LDAPsubentry visibility should be control by > a mechanism > >more closely modeled after the X.500 subentry visibility mechanism. > >In particular, I suggest use of a control. The use of a control > >will allow a clear and concise specification of visibility semantics > >which facilitates implementation and use. > > > >Comments? > > > > Kurt > > From list@netscape.com Thu Oct 19 10:21: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 KAA04563 for ; Thu, 19 Oct 2000 10:21: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 e9JE7vs29484; Thu, 19 Oct 2000 07:07:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JEJSI13234; Thu, 19 Oct 2000 07:19:28 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 07:19:28 -0700 (PDT) Message-Id: <5.0.0.25.0.20001018203414.00a4fe00@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 07:18:07 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Fwd: controlling visability of subentries Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"hrFRXD.A.bOD.vLw75"@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 prefer option 1 as it is simple, adequately resolves this issue, and is consistent with other such extensions (e.g. manageDsaIT control). As LDAP subentry TS is an elective extension to the LDAP protocol, I believe this to be best. I would prefer to keep "future work" off this particular table so that we might reach closure on the LDAP subentry TS soon. Kurt At 09:24 PM 10/18/00 -0600, Ed Reed wrote: >Okay, Kurt - I've reviewed what X.511 specifies for the service control >used to control subentry visibility. What is your opinion on what we should >do in LDAP? > >1) create a control which has no parameters, but has the effect that when >it is present, it is interpreted identically to an X.511 service control with the >subentries bit set TRUE; or > >2) create a control which has a parameter identical to the service control >specified by X.511. This would have the effect of providing a lot of the >additional controls needed to add distributed operations to LDAP (including >preferChaining, chainingProhibited, etc.), but would also provide things >like timeLimit, sizeLimit, scopeOfReferral, and attributeSizeLimit, etc. >In X.511, the serviceControls are among the CommonArguments included >with each request. > >I suppose we could consider the list of controls in LDAP providing the >equivalent to the set of CommonArguments. > >What's your take? 1 would be easier to document. 2 would lay >important groundwork that should be considered in the context of future >work to add distributed operations to LDAP. From list@netscape.com Thu Oct 19 10:42: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 KAA07124 for ; Thu, 19 Oct 2000 10:42: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 e9JESHs02050; Thu, 19 Oct 2000 07:28:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JEdmo22639; Thu, 19 Oct 2000 07:39:48 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 07:39:48 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer goliath.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'Kurt D. Zeilenga'" , Ed Reed Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 16:39:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"l-5UBB.A.FhF.xew75"@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 think Kurt is right. It's the simplest solution. Does this mean that an LDAPServer should never gives a subentry in the search result if this control is not set ? Helmut > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, October 19, 2000 4:18 PM > To: Ed Reed > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: Re: Fwd: controlling visability of subentries > > > I prefer option 1 as it is simple, adequately resolves this issue, > and is consistent with other such extensions (e.g. manageDsaIT > control). As LDAP subentry TS is an elective extension to the > LDAP protocol, I believe this to be best. I would prefer > to keep "future work" off this particular table so that we might > reach closure on the LDAP subentry TS soon. > > Kurt > > At 09:24 PM 10/18/00 -0600, Ed Reed wrote: > >Okay, Kurt - I've reviewed what X.511 specifies for the > service control > >used to control subentry visibility. What is your opinion > on what we should > >do in LDAP? > > > >1) create a control which has no parameters, but has the > effect that when > >it is present, it is interpreted identically to an X.511 > service control with the > >subentries bit set TRUE; or > > > >2) create a control which has a parameter identical to the > service control > >specified by X.511. This would have the effect of providing > a lot of the > >additional controls needed to add distributed operations to > LDAP (including > >preferChaining, chainingProhibited, etc.), but would also > provide things > >like timeLimit, sizeLimit, scopeOfReferral, and > attributeSizeLimit, etc. > >In X.511, the serviceControls are among the CommonArguments included > >with each request. > > > >I suppose we could consider the list of controls in LDAP > providing the > >equivalent to the set of CommonArguments. > > > >What's your take? 1 would be easier to document. 2 would lay > >important groundwork that should be considered in the > context of future > >work to add distributed operations to LDAP. > > From list@netscape.com Thu Oct 19 12:52: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 MAA27376 for ; Thu, 19 Oct 2000 12:52: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 e9JGdDs20447; Thu, 19 Oct 2000 09:39:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JGoh208959; Thu, 19 Oct 2000 09:50:43 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 09:50:43 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 19 Oct 2000 10:49:48 -0600 From: "Ed Reed" To: , Cc: , Subject: RE: Fwd: controlling visability of subentries 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 e9JGofr08932 Resent-Message-ID: <"h0EBcB.A.qLC.hZy75"@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 Yes - to follow the model of X.511, the following will apply: If the control is present, then NO other entries will be considered for return to a search operation, though other entries may be referenced in the base of the search, and normal ACI policy will be inforced. If the control is NOT present, then NO subentries will be considered for return to a search operation. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Volpers, Helmut" 10/19/00 08:39AM >>> I think Kurt is right. It's the simplest solution. Does this mean that an LDAPServer should never gives a subentry in the search result if this control is not set ? Helmut > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, October 19, 2000 4:18 PM > To: Ed Reed > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: Re: Fwd: controlling visability of subentries > > > I prefer option 1 as it is simple, adequately resolves this issue, > and is consistent with other such extensions (e.g. manageDsaIT > control). As LDAP subentry TS is an elective extension to the > LDAP protocol, I believe this to be best. I would prefer > to keep "future work" off this particular table so that we might > reach closure on the LDAP subentry TS soon. > > Kurt > > At 09:24 PM 10/18/00 -0600, Ed Reed wrote: > >Okay, Kurt - I've reviewed what X.511 specifies for the > service control > >used to control subentry visibility. What is your opinion > on what we should > >do in LDAP? > > > >1) create a control which has no parameters, but has the > effect that when > >it is present, it is interpreted identically to an X.511 > service control with the > >subentries bit set TRUE; or > > > >2) create a control which has a parameter identical to the > service control > >specified by X.511. This would have the effect of providing > a lot of the > >additional controls needed to add distributed operations to > LDAP (including > >preferChaining, chainingProhibited, etc.), but would also > provide things > >like timeLimit, sizeLimit, scopeOfReferral, and > attributeSizeLimit, etc. > >In X.511, the serviceControls are among the CommonArguments included > >with each request. > > > >I suppose we could consider the list of controls in LDAP > providing the > >equivalent to the set of CommonArguments. > > > >What's your take? 1 would be easier to document. 2 would lay > >important groundwork that should be considered in the > context of future > >work to add distributed operations to LDAP. > > From list@netscape.com Thu Oct 19 13:25: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 NAA02725 for ; Thu, 19 Oct 2000 13: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 e9JHGUD25101; Thu, 19 Oct 2000 10:16:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JHNVY28396; Thu, 19 Oct 2000 10:23:31 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 10:23:31 -0700 (PDT) X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Mark Smith'" , "'Volpers Helmut'" Cc: "'Ed Reed'" , , , Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 04:27:02 +1000 Message-ID: <000301c039fa$2dc709c0$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <39EEF1F1.4345A416@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Resent-Message-ID: <"7b4Bv.A.45G.P4y75"@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 [Mark] The problem I see with solution 2 (create a control that mimics the X511 ServiceControls) is that there would be no way for an LDAP client to discover the subset of ServiceControls that is supported on a given LDAP server. Surely we are not going to require support for everything in ServiceControls just to solve the subentry problem. Therefore, I prefer solution 1. And so everyone knows what we are talking about, from X.511: [long list of X.511 controls snipped] [Albert] I've got no opinion either way on option 1 or option 2 as not familiar and don't have time to study it. However I question the validity of this argument against option 2. Would have thought that the usual "discovery" mechanism would work ok. Client tries to use a control, server returns error response, client that cares notes that server does not support control and caches that info for as long as they wish to. Clients that don't care don't care, so they don't try to use the control and don't get error responses. Sorry if there is some obvious flaw in that. I haven't studied the details. PS This also a "hi" to all in view of long absence. Sorry I haven't been able to respond to latest requirements doc due to other commitments (still stuck in those for a while yet). But then nobody else has either. I do believe it was a significant improvement and genuine effort to address my objections. For the record: 1. I'm assuming some means of guaranteeing eventual convergence *will* be proposed with at least an initial draft prior to final call on the requirements draft. I believe there is probably a consensus for eventual convergence and the apparant ambiguity in the requirements draft about this may be unintentional and therefore easily fixed. A fix would remove the contradictory references to non-convergent models in the final para of section 3. The whole discussion of models in section 3 is just confusing if in fact the intention is to require guaranteed eventual convergence. Model 2 should be clearly stated as *the* (only) relevant model. Actual requirements 4.1 G1 and G2 are also confusing. But the real test of whether there is in fact an intention to guarantee convergence is however whether anyone is actually working on a means to achieve it. The current URP and architecture simply does not. I still haven't seen a redraft of URP and architecture to meet the apparant consensus to support reliable eventual convergence under all circumstances. 2. My objection to non-atomicity still stands for final call but I'm assuming there is little point arguing about it further within LDUP unless others want to take it up. The draft now at least makes it possible to have serious discussion about the issue in IETF review and does include several requirements which cannot in fact be met without atomicity, such as accurate replication of access controls and attributes such as "modifiers name". although I disagree with much of the analysis in appendix B.5 and also the continued misunderstanding of applications for multi-master replication in appendix A on usage scenarios. There are still some inadequacies in presentation of the issue but the fundamental question is now simply whether or not atomicity should be a requirement rather than whether a document that shows no comprehension of the issue at all should be presented to the IETF at all. I still believe a fundamental technical mistake is being made on that question. I also still believe the requirements draft should be actively seeking input from directory users on the impact of non-atomicity. 3. I agree with the requirement 4.1 G6 for no unbounded conflict resolution records. This is a better description than "oscillation". It is not met by my MDCR draft and would need further work if in fact the current URP and architecture drafts do not come up with a means of guaranteed eventual convergence based only on timestamps. I'm not planning to do any work on it unless some interest is shown by others as a result of failure to deliver a viable URP and architecture with eventual convergence. Sorry I simply don't have time to follow up on these issues at the moment. Am just reminding that they are still there in case others want to take them up before the document goes from LDUP to IETF final call. From list@netscape.com Thu Oct 19 13:29:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03282 for ; Thu, 19 Oct 2000 13:29: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 e9JHG9s28203; Thu, 19 Oct 2000 10:16:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JHRcE01168; Thu, 19 Oct 2000 10:27:38 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 10:27:38 -0700 (PDT) Message-ID: <39EF2D9F.CB708C7@software.com> Date: Thu, 19 Oct 2000 10:21:36 -0700 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Volpers, Helmut" CC: "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Fwd: controlling visability of subentries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1bW22C.A.PR.F8y75"@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 "Volpers, Helmut" wrote: > I think Kurt is right. It's the simplest solution. > Does this mean that an LDAPServer should never gives a subentry in the > search result if this control is not set ? I guess, going with the new scheme would require change in the following text from RFC 2251: " Clients MUST only retrieve attributes from a subschema entry by requesting a base object search of the entry, where the search filter is "(objectClass=subschema)". (This will allow LDAPv3 servers which gateway to X.500(93) to detect that subentry information is being requested.) " Any backward compatibility issues (existing clients using RFC 2251 scheme to read subschema subentries) ? > > > Helmut > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Thursday, October 19, 2000 4:18 PM > > To: Ed Reed > > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > > Subject: Re: Fwd: controlling visability of subentries > > > > > > I prefer option 1 as it is simple, adequately resolves this issue, > > and is consistent with other such extensions (e.g. manageDsaIT > > control). As LDAP subentry TS is an elective extension to the > > LDAP protocol, I believe this to be best. I would prefer > > to keep "future work" off this particular table so that we might > > reach closure on the LDAP subentry TS soon. > > > > Kurt > > > > At 09:24 PM 10/18/00 -0600, Ed Reed wrote: > > >Okay, Kurt - I've reviewed what X.511 specifies for the > > service control > > >used to control subentry visibility. What is your opinion > > on what we should > > >do in LDAP? > > > > > >1) create a control which has no parameters, but has the > > effect that when > > >it is present, it is interpreted identically to an X.511 > > service control with the > > >subentries bit set TRUE; or > > > > > >2) create a control which has a parameter identical to the > > service control > > >specified by X.511. This would have the effect of providing > > a lot of the > > >additional controls needed to add distributed operations to > > LDAP (including > > >preferChaining, chainingProhibited, etc.), but would also > > provide things > > >like timeLimit, sizeLimit, scopeOfReferral, and > > attributeSizeLimit, etc. > > >In X.511, the serviceControls are among the CommonArguments included > > >with each request. > > > > > >I suppose we could consider the list of controls in LDAP > > providing the > > >equivalent to the set of CommonArguments. > > > > > >What's your take? 1 would be easier to document. 2 would lay > > >important groundwork that should be considered in the > > context of future > > >work to add distributed operations to LDAP. > > > > From list@netscape.com Thu Oct 19 14:01: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 OAA07581 for ; Thu, 19 Oct 2000 14:01:00 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9JHlbs04169; Thu, 19 Oct 2000 10:47:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JHx7A19814; Thu, 19 Oct 2000 10:59:07 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 10:59:07 -0700 (PDT) Message-Id: <5.0.0.25.0.20001019104256.00aae340@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 10:58:14 -0700 To: sanjay jain From: "Kurt D. Zeilenga" Subject: Re: Fwd: controlling visability of subentries Cc: "Volpers, Helmut" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com In-Reply-To: <39EF2D9F.CB708C7@software.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Ygb_zB.A.70E.pZz75"@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 10:21 AM 10/19/00 -0700, sanjay jain wrote: >"Volpers, Helmut" wrote: > >> I think Kurt is right. It's the simplest solution. >> Does this mean that an LDAPServer should never gives a subentry in the >> search result if this control is not set ? > >I guess, going with the new scheme would require change in the >following text from RFC 2251: > >" Clients MUST only retrieve attributes from a subschema entry by > requesting a base object search of the entry, where the search filter > is "(objectClass=subschema)". (This will allow LDAPv3 servers which > gateway to X.500(93) to detect that subentry information is being > requested.) " > >Any backward compatibility issues (existing clients >using RFC 2251 scheme to read subschema subentries) ? Yes. And they will have to be addressed in due course. I suggest the LDAP subentry I-D itself not directly address issues surrounding the LDAP subschema "entry (or subentry)" as described in RFC 2251. This is better left to LDAPbis efforts. Some of the issues are: RFC 2251 says "subschema entry (or subentry)" RFC 2251 is referring to X.500's subentry LDAP subentry != X.500 subentry Support for subentries (of any flavor) is optional in LDAP (as currently defined). RFC 2251 ONLY allows "(objectClass=subschema)" and clients often want to apply more complex filters (such as an objectClasses or attributeTypes assertion) I suggest discussing regarding the updating of RFC 2251 and other core documents be moved to the LDAPbis mailing list . Kurt From list@netscape.com Thu Oct 19 14:26: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 OAA11266 for ; Thu, 19 Oct 2000 14:26: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 e9JIIID09771; Thu, 19 Oct 2000 11:18:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JILFs03549; Thu, 19 Oct 2000 11:21:15 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 11:21:15 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 19 Oct 2000 12:20:36 -0600 From: "Steve Sonntag" To: Cc: , , "Alan Clark" , "Steven Merrill" Subject: Java LDAP API - LDAPConnection.getConstraints Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_EFB7346A.F091E514" Resent-Message-ID: <"i4xv5.A.t0.Vuz75"@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. --=_EFB7346A.F091E514 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I think the getConstraints and getSearchConstraints methods of LDAPConnection should be specific as to whether the API returns a reference to an internal object or whether a reference to a cloned object is returned. -Steve --=_EFB7346A.F091E514 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think the getConstraints and getSearchConstraints methods
of LDAPConnection should be specific as to whether the API
returns a reference to an internal object or whether a reference
=
to a cloned object is returned.
 
-Steve
--=_EFB7346A.F091E514-- From list@netscape.com Thu Oct 19 14:29: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 OAA11753 for ; Thu, 19 Oct 2000 14:29: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 e9JIKaD10262; Thu, 19 Oct 2000 11:20:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JIRaM07925; Thu, 19 Oct 2000 11:27:37 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 11:27:37 -0700 (PDT) Message-ID: <39EF3CBE.2A7AE51D@worldspot.com> Date: Thu, 19 Oct 2000 11:26:06 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Sonntag CC: robw@worldspot.com, ietf-ldapext@netscape.com, miodrag@netscape.com, Alan Clark , Steven Merrill Subject: Re: Java LDAP API - LDAPConnection.getConstraints References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"iq12X.A.S7B.W0z75"@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. They return a cloned object. Rob Steve Sonntag wrote: > I think the getConstraints and getSearchConstraints methodsof > LDAPConnection should be specific as to whether the APIreturns a > reference to an internal object or whether a referenceto a cloned > object is returned. -Steve From list@netscape.com Thu Oct 19 14:41: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 OAA14254 for ; Thu, 19 Oct 2000 14:41: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 e9JIWaD12865; Thu, 19 Oct 2000 11:32:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JIdb213976; Thu, 19 Oct 2000 11:39:37 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 11:39:37 -0700 (PDT) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <39EF3FDF.1C86C55B@netscape.com> Date: Thu, 19 Oct 2000 14:39:27 -0400 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: sanjay jain CC: Volpers Helmut , "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: Fwd: controlling visability of subentries References: <39EF2D9F.CB708C7@software.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6u9xl.A.fZD.m_z75"@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 sanjay jain wrote: > > "Volpers, Helmut" wrote: > > > I think Kurt is right. It's the simplest solution. > > Does this mean that an LDAPServer should never gives a subentry in the > > search result if this control is not set ? > > I guess, going with the new scheme would require change in the > following text from RFC 2251: > > " Clients MUST only retrieve attributes from a subschema entry by > requesting a base object search of the entry, where the search filter > is "(objectClass=subschema)". (This will allow LDAPv3 servers which > gateway to X.500(93) to detect that subentry information is being > requested.) " > > Any backward compatibility issues (existing clients > using RFC 2251 scheme to read subschema subentries) ? Perhaps. A reasonable compromise might be to return LDAP subentries in these two cases: 1) When a returnSubEntries control (to be defined) is present in the search request. 2) When the scope of the search is baseObject. Why return LDAP subentries in case 2)? Because it is more compatible with 2251. And because I do not think it does any harm -- if a client knows the name of a subentry, it might just as well be able to retrieve it without using any controls. Comments? -- Mark Smith Netscape From list@netscape.com Thu Oct 19 15:33:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25310 for ; Thu, 19 Oct 2000 15:33: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 e9JJJxs21767; Thu, 19 Oct 2000 12:19:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JJVTs10440; Thu, 19 Oct 2000 12:31:29 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 12:31:29 -0700 (PDT) Message-ID: From: "Salter, Thomas A" To: Mark Smith , sanjay jain Cc: Volpers Helmut , "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 15:30:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"sNRjyB.A.ziC.Ow075"@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 Your option 2 is the X.500 definition. The subentries control applies to one-level and whole tree searches and lists, but not to baseObject or read. You can always get the entry with its name. > -----Original Message----- > From: Mark Smith [mailto:mcs@netscape.com] > Sent: Thursday, October 19, 2000 2:39 PM > To: sanjay jain > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > ietf-ldapext@netscape.com > Subject: Re: Fwd: controlling visability of subentries > > > sanjay jain wrote: > > > > "Volpers, Helmut" wrote: > > > > > I think Kurt is right. It's the simplest solution. > > > Does this mean that an LDAPServer should never gives a > subentry in the > > > search result if this control is not set ? > > > > I guess, going with the new scheme would require change in the > > following text from RFC 2251: > > > > " Clients MUST only retrieve attributes from a subschema entry by > > requesting a base object search of the entry, where the > search filter > > is "(objectClass=subschema)". (This will allow LDAPv3 > servers which > > gateway to X.500(93) to detect that subentry > information is being > > requested.) " > > > > Any backward compatibility issues (existing clients > > using RFC 2251 scheme to read subschema subentries) ? > > Perhaps. A reasonable compromise might be to return LDAP > subentries in > these two cases: > > 1) When a returnSubEntries control (to be defined) is present in the > search request. > > 2) When the scope of the search is baseObject. > > Why return LDAP subentries in case 2)? Because it is more compatible > with 2251. And because I do not think it does any harm -- > if a client > knows the name of a subentry, it might just as well be able > to retrieve > it without using any controls. Comments? > > -- > Mark Smith > Netscape > From list@netscape.com Thu Oct 19 17:10: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 RAA10082 for ; Thu, 19 Oct 2000 17:10: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 e9JL1sD15648; Thu, 19 Oct 2000 14:01:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9JL8uk02636; Thu, 19 Oct 2000 14:08:56 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 14:08:56 -0700 (PDT) Date: Thu, 19 Oct 2000 14:08:50 -0700 (PDT) Message-Id: <200010192108.e9JL8dR00119@xwing.netscape.com> From: h8work@joinme.com To: ietf-ldapext@netscape.com Subject: Make $30,000 Part Time -JJNX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GgPLiB.A.xo.lL275"@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 YOU CAN MAKE OVER 30,000 DOLLARS/ MONTH WITH NO MONEY INVESTED!!! Do You ever lay there at night wide awake, worried about your finacial situation? I do. I hate it! I am sick of living paycheck to paycheck worried if I have enough money to cover rent. But it is changing for me this year...I am now on track to be able to quit my job and make more money working half the hours! YOU CAN TOO! Do you like your job? Does it pay you what you ara worth? And if it does, do you have enough spare time to do the things you enjoy most? Do you look at home based business opportunities and love the concept; but it either costs too much for you to get started, or you can't find anyone else with enough money to get involved? I have been searching for years trying to find the perfect home business...to tell you the truth I still have not found it, but I think this comes the closest. YOU CAN MAKE OVER 30,000 DOLLARS/MONTH WITH NO MONEY INVESTED!!! Because most people who need to make more money don't have lots to spare this is perfect! Anyone who lives in the US can join this program for free, and if you live anywhere else it will only cost you $5 US. And you never pay a dime out of your pocket again! This is the simplest and most duplicateable home business I have ever seen. All you need is the disire to make some good money. Just show it to your friends, it won't cost them anything to join, you make money! and so can they! To know more detail reply with "show me" in the subject box Thank you for your time, I hope you have a great day Jay PS. I know this all sounds too good to be true, but it is for real. This company has been around for over 2 years and thousands of people, just like you and me, are good making money. Reply to this email so you can find out how easy it really can be to become finacially independant, and help out a lot of your friends and family in the process. ................................................................... To be removed from this mailing list please send a reply to this with remove in the subject box. Sorry for any Inconvience. DO NOT SPAM. IT HURTS ALL OF US From list@netscape.com Thu Oct 19 20:22: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 SMTP id UAA02108 for ; Thu, 19 Oct 2000 20:22: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 e9K09Ps17909; Thu, 19 Oct 2000 17:09:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9K0KuE29459; Thu, 19 Oct 2000 17:20:56 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 17:20:56 -0700 (PDT) Message-Id: <5.0.0.25.0.20001019170331.00aebdb0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 17:20:18 -0700 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: Fwd: controlling visability of subentries Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com, ietf-ldapbis@openldap.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"SsryHC.A.tLH.m_475"@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:30 PM 10/19/00 -0400, Salter, Thomas A wrote: >Your [Mark Smith's] option 2 [scope base] is the X.500 definition. The subentries control applies to >one-level and whole tree searches and lists, but not to baseObject or read. >You can always get the entry with its name. That's an interesting point. RFC 2251 says "(objectclass=subentry)" was introduced to "allow LDAPv3 servers which gateway to X.500(93) to detect that subentry information is being requested." However, given that the requirement is for a scope base search, an LDAP/DAP gateway could do a direct translation of the request and the appropriate subentry would be returned by the DAP server to the gateway for the LDAP client. So my question is: why does a LDAP/DAP gateway need to detect that the request is for a subentry? Kurt PS: I've cc'ed ietf-ldapbis@openldap.org > > -----Original Message----- > > From: Mark Smith [mailto:mcs@netscape.com] > > Sent: Thursday, October 19, 2000 2:39 PM > > To: sanjay jain > > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > > ietf-ldapext@netscape.com > > Subject: Re: Fwd: controlling visability of subentries > > > > > > sanjay jain wrote: > > > > > > "Volpers, Helmut" wrote: > > > > > > > I think Kurt is right. It's the simplest solution. > > > > Does this mean that an LDAPServer should never gives a > > subentry in the > > > > search result if this control is not set ? > > > > > > I guess, going with the new scheme would require change in the > > > following text from RFC 2251: > > > > > > " Clients MUST only retrieve attributes from a subschema entry by > > > requesting a base object search of the entry, where the > > search filter > > > is "(objectClass=subschema)". (This will allow LDAPv3 > > servers which > > > gateway to X.500(93) to detect that subentry > > information is being > > > requested.) " > > > > > > Any backward compatibility issues (existing clients > > > using RFC 2251 scheme to read subschema subentries) ? > > > > Perhaps. A reasonable compromise might be to return LDAP > > subentries in > > these two cases: > > > > 1) When a returnSubEntries control (to be defined) is present in the > > search request. > > > > 2) When the scope of the search is baseObject. > > > > Why return LDAP subentries in case 2)? Because it is more compatible > > with 2251. And because I do not think it does any harm -- > > if a client > > knows the name of a subentry, it might just as well be able > > to retrieve > > it without using any controls. Comments? > > > > -- > > Mark Smith > > Netscape > > From list@netscape.com Thu Oct 19 21:49: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 VAA14175 for ; Thu, 19 Oct 2000 21:49: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 e9K1fMD13699; Thu, 19 Oct 2000 18:41:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9K1mNY01003; Thu, 19 Oct 2000 18:48:23 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 18:48:23 -0700 (PDT) Reply-To: From: "Steven Legg" To: "'Salter, Thomas A'" Cc: , Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 12:47:59 +1100 Message-ID: <000501c03a37$c7aa6860$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Resent-Message-ID: <"OLhybB.A.WP.lR675"@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 Thomas, How did you reach the conclusion that the subentries service control does not apply to baseObject searches ? I've just read X.511 and it says the control applies to search and list operations, but it doesn't qualify the type of search at all. It would be sensible to ignore the setting of the subentries service control for baseObject searches but X.511 doesn't read that way. Regards, Steven > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Salter, Thomas A > Sent: Friday, 20 October 2000 6:31 > To: Mark Smith; sanjay jain > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > ietf-ldapext@netscape.com > Subject: RE: Fwd: controlling visability of subentries > > > Your option 2 is the X.500 definition. The subentries > control applies to > one-level and whole tree searches and lists, but not to > baseObject or read. > You can always get the entry with its name. > > > -----Original Message----- > > From: Mark Smith [mailto:mcs@netscape.com] > > Sent: Thursday, October 19, 2000 2:39 PM > > To: sanjay jain > > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > > ietf-ldapext@netscape.com > > Subject: Re: Fwd: controlling visability of subentries > > > > > > sanjay jain wrote: > > > > > > "Volpers, Helmut" wrote: > > > > > > > I think Kurt is right. It's the simplest solution. > > > > Does this mean that an LDAPServer should never gives a > > subentry in the > > > > search result if this control is not set ? > > > > > > I guess, going with the new scheme would require change in the > > > following text from RFC 2251: > > > > > > " Clients MUST only retrieve attributes from a subschema entry by > > > requesting a base object search of the entry, where the > > search filter > > > is "(objectClass=subschema)". (This will allow LDAPv3 > > servers which > > > gateway to X.500(93) to detect that subentry > > information is being > > > requested.) " > > > > > > Any backward compatibility issues (existing clients > > > using RFC 2251 scheme to read subschema subentries) ? > > > > Perhaps. A reasonable compromise might be to return LDAP > > subentries in > > these two cases: > > > > 1) When a returnSubEntries control (to be defined) is > present in the > > search request. > > > > 2) When the scope of the search is baseObject. > > > > Why return LDAP subentries in case 2)? Because it is more > compatible > > with 2251. And because I do not think it does any harm -- > > if a client > > knows the name of a subentry, it might just as well be able > > to retrieve > > it without using any controls. Comments? > > > > -- > > Mark Smith > > Netscape > > > From list@netscape.com Thu Oct 19 22:22:22 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 WAA20847 for ; Thu, 19 Oct 2000 22:22: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 e9K29Js06047; Thu, 19 Oct 2000 19:09:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9K2Ko213373; Thu, 19 Oct 2000 19:20:50 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 19:20:50 -0700 (PDT) From: Message-Id: <200010200209.KAA0000008897@search08.sohu.com> Date: Thu, 19 Oct 2000 19:07:57 Content-Transfer-Encoding: 7bit Sensitivity: Company-Confidential X-References: 04141BCB3, 0B1357F83 References: 05BB69356 Subject: create and amass personal wealth To: X-Mailer: Mozilla 2.45 [en] (Win95; I) X-Accept-Language: en X-Via: <5xqutbd3sq0ruk3.191020001907@localhost>$(@}# X-Other-References: 02FF41199 MIME-Version: 1.0 Content-Type: text/plain MessageID: <5xqutbd3sq0ruk3.191020001907@localhost> Resent-Message-ID: <"xok-7C.A.fQD.Aw675"@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 Multiply Your Income... Seeking positive and motivated individuals that are serious about creating 6-7 figure wealth. Do you have a burning desire to enhance the quality of your existing life? Would you like to live the life that others only dream about? The fact is we have many people in this enterprise that earn from 10K to 50k per month from the privacy of their own home and are achieving financial independence in 2-3 years obviously wealthy and having total freedom both personal and financial. If you think this is too good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from our efforts. This is all about Education and Knowledge that was once reserved for the ultra wealthy and the well connected. By calling the phone number below you will hear about a powerful Wealth Building Educational Program and a brilliant marketing concept. How would you like to: 1. Drastically reduce personal, business and capital gains taxes? 2. Protect all assets from any form of seizure, liens, or judgments? 3. Create a six-figure income every 4 months? How about: 1. Restoring and preserving complete personal and financial privacy? 2. Create and amass personal wealth, multiply it and protect it? 3. Realize a 3 to 6 times greater returns on your money? 4. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? Are you a BIG thinker, BIG dreamer and a person that believes they deserve to have the best in life? Are you capable of recognizing that once in a lifetime opportunity when it's looking right at you? Countless others have missed their shot at the title only to look back years later and wished they should've because they could've. If you have Moderate People Skills, a Strong Work Ethic, and a Burning Desire to become Financially Independent in the next 2-3 years then I invite you to take a tour of the turnkey information system. There are 3 steps in the process: 1st step: 1"888"269"5535 3-minute intro (24 hr toll free) 2nd step: Leave your name and phone number requesting a informational interview 3rd step: Receive a detailed overview of the product and marketing plan This is about money, freedom, and financial independence. It is unlike any other business and it is NOT MLM Take the time to gather the information...It is truly remarkable!!! The most effective WAY TO BE REMOVED FROM FUTURE MAILINGS IS TO REPLY TO THE FOLLOWING LINK mailto:removeme@greysuitandtie.net?subject=REMOVE ******************************************************************* It appears that the incorporation of agonistic cultural constraints suffices to account for irrelevant intervening contexts in selectional rules. ******************************************************************* From list@netscape.com Thu Oct 19 23:36: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 XAA04686 for ; Thu, 19 Oct 2000 23:36: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 e9K3RQD28564; Thu, 19 Oct 2000 20:27:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9K3YQg01201; Thu, 19 Oct 2000 20:34:26 -0700 (PDT) Resent-Date: Thu, 19 Oct 2000 20:34:26 -0700 (PDT) Message-Id: <001101c03a46$7ae4a360$82dc8f96@arhdialin.cdc.com> Reply-To: "David A. Cahlander" From: "David A. Cahlander" To: "Mark Smith" , "sanjay jain" Cc: "Volpers Helmut" , "'Kurt D. Zeilenga'" , "Ed Reed" , , References: <39EF2D9F.CB708C7@software.com> <39EF3FDF.1C86C55B@netscape.com> Subject: Re: Fwd: controlling visability of subentries Date: Thu, 19 Oct 2000 22:33:13 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"B91eoC.A.cS.B1775"@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 Syntegra has modified the X500 directory to return an entry for a base object search. With X500 logic, a "read" would return the entry, but no search would return the entry. With the change, a base level search returns the entry. As I read the X500 specs, the flag to return the subentry is an exclusive flag. Only subentries are returned or only non-subentries are returned. An X500 browser needed to make two calls to the directory to read all the entries in a list command (one-level search). We added three Syntegra specific controls to pass on the information about subentries and operational attributes. Return operational attributes as well as user attributes: #define LDAP_C_SETOPERATTR_OID "2.16.840.1.113531.18.2.4" Return only subentries: #define LDAP_C_SETSUBENTRIES_OID "2.16.840.1.113531.18.2.5" Return normal entries as well as sub-entries: #define LDAP_C_SETALLENTRIES_OID "2.16.840.1.113531.18.2.11" The complete list of controls added for X500 are: /* * Define LDAP controls. */ #define LDAP_C_SETOPTIONS_OID "2.16.840.1.113531.18.2.1" #define LDAP_C_SETDONTUSECOPY_OID "2.16.840.1.113531.18.2.2" #define LDAP_C_SETLOCALSCOPE_OID "2.16.840.1.113531.18.2.3" #define LDAP_C_SETOPERATTR_OID "2.16.840.1.113531.18.2.4" #define LDAP_C_SETSUBENTRIES_OID "2.16.840.1.113531.18.2.5" #define LDAP_C_SETUSEALIAS_OID "2.16.840.1.113531.18.2.6" #define LDAP_C_SETPREFERCHAIN_OID "2.16.840.1.113531.18.2.7" #define LDAP_C_SETX500DN_OID "2.16.840.1.113531.18.2.8" #define LDAP_C_SETCOPYSHALLDO_OID "2.16.840.1.113531.18.2.9" #define LDAP_C_SETDONTMAPATTRS_OID "2.16.840.1.113531.18.2.10" #define LDAP_C_SETALLENTRIES_OID "2.16.840.1.113531.18.2.11" Thanks. --- David Cahlander David.A.Cahlander@syntegra.com 651-415-3171 ----- Original Message ----- From: "Mark Smith" Perhaps. A reasonable compromise might be to return LDAP subentries in these two cases: 1) When a returnSubEntries control (to be defined) is present in the search request. 2) When the scope of the search is baseObject. Why return LDAP subentries in case 2)? Because it is more compatible with 2251. And because I do not think it does any harm -- if a client knows the name of a subentry, it might just as well be able to retrieve it without using any controls. Comments? -- Mark Smith Netscape From list@netscape.com Fri Oct 20 04:49: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 EAA29206 for ; Fri, 20 Oct 2000 04:49: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 e9K8efD23527; Fri, 20 Oct 2000 01:40:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9K8lgE08539; Fri, 20 Oct 2000 01:47:42 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 01:47:42 -0700 (PDT) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'Salter, Thomas A'" , Mark Smith , sanjay jain Cc: "Volpers, Helmut" , "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 10:46:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ypfViD.A.GFC.saA85"@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 Hi Thomas, By a read its true, but in a search (also base) you have to set the service Control subentries=TRUE I think. Helmut > -----Original Message----- > From: Salter, Thomas A [mailto:Thomas.Salter@unisys.com] > Sent: Thursday, October 19, 2000 9:31 PM > To: Mark Smith; sanjay jain > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > ietf-ldapext@netscape.com > Subject: RE: Fwd: controlling visability of subentries > > > Your option 2 is the X.500 definition. The subentries > control applies to > one-level and whole tree searches and lists, but not to > baseObject or read. > You can always get the entry with its name. > > > -----Original Message----- > > From: Mark Smith [mailto:mcs@netscape.com] > > Sent: Thursday, October 19, 2000 2:39 PM > > To: sanjay jain > > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > > ietf-ldapext@netscape.com > > Subject: Re: Fwd: controlling visability of subentries > > > > > > sanjay jain wrote: > > > > > > "Volpers, Helmut" wrote: > > > > > > > I think Kurt is right. It's the simplest solution. > > > > Does this mean that an LDAPServer should never gives a > > subentry in the > > > > search result if this control is not set ? > > > > > > I guess, going with the new scheme would require change in the > > > following text from RFC 2251: > > > > > > " Clients MUST only retrieve attributes from a subschema entry by > > > requesting a base object search of the entry, where the > > search filter > > > is "(objectClass=subschema)". (This will allow LDAPv3 > > servers which > > > gateway to X.500(93) to detect that subentry > > information is being > > > requested.) " > > > > > > Any backward compatibility issues (existing clients > > > using RFC 2251 scheme to read subschema subentries) ? > > > > Perhaps. A reasonable compromise might be to return LDAP > > subentries in > > these two cases: > > > > 1) When a returnSubEntries control (to be defined) is > present in the > > search request. > > > > 2) When the scope of the search is baseObject. > > > > Why return LDAP subentries in case 2)? Because it is more > compatible > > with 2251. And because I do not think it does any harm -- > > if a client > > knows the name of a subentry, it might just as well be able > > to retrieve > > it without using any controls. Comments? > > > > -- > > Mark Smith > > Netscape > > > From list@netscape.com Fri Oct 20 09:48: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 JAA14212 for ; Fri, 20 Oct 2000 09:48: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 e9KDZ8s01448; Fri, 20 Oct 2000 06:35:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9KDkd621769; Fri, 20 Oct 2000 06:46:39 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 06:46:39 -0700 (PDT) Message-ID: From: "Salter, Thomas A" To: steven.legg@adacel.com.au Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: RE: Fwd: controlling visability of subentries Date: Fri, 20 Oct 2000 09:45:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"zMg2ZB.A.0TF.-yE85"@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 You are correct. I mistakenly equated baseObject search with Read. Tom > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Thursday, October 19, 2000 9:48 PM > To: 'Salter, Thomas A' > Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: RE: Fwd: controlling visability of subentries > > > > Hi Thomas, > > How did you reach the conclusion that the subentries service control > does not apply to baseObject searches ? I've just read X.511 and it > says the control applies to search and list operations, but > it doesn't > qualify the type of search at all. > > It would be sensible to ignore the setting of the subentries service > control for baseObject searches but X.511 doesn't read that way. > > Regards, > Steven > > > -----Original Message----- > > From: owner-ietf-ldup@mail.imc.org > > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Salter, Thomas A > > Sent: Friday, 20 October 2000 6:31 > > To: Mark Smith; sanjay jain > > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; ietf-ldup@imc.org; > > ietf-ldapext@netscape.com > > Subject: RE: Fwd: controlling visability of subentries > > > > > > Your option 2 is the X.500 definition. The subentries > > control applies to > > one-level and whole tree searches and lists, but not to > > baseObject or read. > > You can always get the entry with its name. > > > > > -----Original Message----- > > > From: Mark Smith [mailto:mcs@netscape.com] > > > Sent: Thursday, October 19, 2000 2:39 PM > > > To: sanjay jain > > > Cc: Volpers Helmut; 'Kurt D. Zeilenga'; Ed Reed; > ietf-ldup@imc.org; > > > ietf-ldapext@netscape.com > > > Subject: Re: Fwd: controlling visability of subentries > > > > > > > > > sanjay jain wrote: > > > > > > > > "Volpers, Helmut" wrote: > > > > > > > > > I think Kurt is right. It's the simplest solution. > > > > > Does this mean that an LDAPServer should never gives a > > > subentry in the > > > > > search result if this control is not set ? > > > > > > > > I guess, going with the new scheme would require change in the > > > > following text from RFC 2251: > > > > > > > > " Clients MUST only retrieve attributes from a > subschema entry by > > > > requesting a base object search of the entry, where the > > > search filter > > > > is "(objectClass=subschema)". (This will allow LDAPv3 > > > servers which > > > > gateway to X.500(93) to detect that subentry > > > information is being > > > > requested.) " > > > > > > > > Any backward compatibility issues (existing clients > > > > using RFC 2251 scheme to read subschema subentries) ? > > > > > > Perhaps. A reasonable compromise might be to return LDAP > > > subentries in > > > these two cases: > > > > > > 1) When a returnSubEntries control (to be defined) is > > present in the > > > search request. > > > > > > 2) When the scope of the search is baseObject. > > > > > > Why return LDAP subentries in case 2)? Because it is more > > compatible > > > with 2251. And because I do not think it does any harm -- > > > if a client > > > knows the name of a subentry, it might just as well be able > > > to retrieve > > > it without using any controls. Comments? > > > > > > -- > > > Mark Smith > > > Netscape > > > > > > From list@netscape.com Fri Oct 20 13:00: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 NAA14124 for ; Fri, 20 Oct 2000 13: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 e9KGoQD22889; Fri, 20 Oct 2000 09:50:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9KGvTQ27733; Fri, 20 Oct 2000 09:57:29 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 09:57:29 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 20 Oct 2000 10:56:01 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_E0B82438.34553915" Resent-Message-ID: <"jiDBCC.A.vwG.3lH85"@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. --=_E0B82438.34553915 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Getting back to this: The example David gives below shows a subtype inheriting from multiple = supertypes. As of yet, I believe that this is illegal in X.500/LDAP and as = such might cause problems with existing servers. I don't have a good feeling of closure on this subject. We need to revise = 4.1.5 of RFC 2251 to say one of the following: 1) "An AttributeDescription with one or more options is treated as a = direct subtype of the attribute type without any options" (inserted = direct) or 2) "An AttributeDescription with one option is treated as a direct subtype = of the attribute type without any options. An AttributeDescription with = more than one option is treated as a direct subtype of all the possible = AttributeDescriptions that could be made up of all lesser combinations the = options" That description is pretty ugly and could be fixed. It says that cn;a;b;c;d= is in a direct subtype of: cn;a cn;a;b cn;a;c cn;a;d cn;a;b;c cn;a;b;d cn;a;c;d cn;b cn;b;c cn;b;d cn;b;c;d cn;c cn;c;d cn;d This also tells me that attribute subtype inheritance is at most two = levels, but infinitely wide (leaf can multiply inherit from any number of = supertypes) or "An AttributeDescription with one option is treated as a direct subtype of = the attribute type without any options. An AttributeDescription with more = than one option is treated as a direct subtype of all the possible = AttributeDescriptions that could be made up of all combinations the = options sans one option" Using the former example, this produces: cn;a (direct subtype of cn) cn;b (direct subtype of cn) cn;c (direct subtype of cn) cn;d (direct subtype of cn) cn;a;b (direct subtype of cn;a and cn;b) cn;a;c (direct subtype of cn;a and cn;c) cn;a;d (direct subtype of cn;a and cn;d) cn;b;c (direct subtype of cn;b and cn;c) cn;b;d (direct subtype of cn;b and cn;d) cn;c;d (direct subtype of cn;c and cn;d) cn;a;b;c (direct subtype of cn;a;b and cn;a;c and cn;b;c) cn;a;b;d (direct subtype of cn;a;b and cn;a;d and cn;b;d) cn;a;c;d (direct subtype of cn;a;c and cn;a;d and cn;c;d) cn;b;c;d (direct subtype of cn;b;c and cn;b;d and cn;c;d) cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and cn;a;c;d) =20 In the context of language tags, the implications might be benign, but = when combining disparate options some combinations might cause problems. I personally prefer 1). Though it may be less flexible, It's simpler to = understand and fits well with the current subtyping model. Jim >>> "David Chadwick" 9/23/00 5:11:55 AM >>> > 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,=20 Yes, I would say so. The new dual language subtype is a subtype=20 of both single language subtypes. The order does not matter. We=20 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. >=20 > Jim >=20 *************************************************** 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 *************************************************** --=_E0B82438.34553915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Getting back to this:
 
The example David gives below shows a subtype = inheriting from=20 multiple supertypes. As of yet, I believe that this is illegal in = X.500/LDAP and=20 as such might cause problems with existing servers.
 
I don't have a good feeling of closure on this = subject. We=20 need to revise 4.1.5 of RFC 2251 to say one of the following:
 
1) "An AttributeDescription with one or more options = is=20 treated as a direct subtype of the attribute type without any options" = (inserted=20 direct)
 
or
 
2) "An AttributeDescription with one option is treated = as a=20 direct subtype of the attribute type without any options. An=20 AttributeDescription with more than one option is treated as a direct = subtype of=20 all the possible AttributeDescriptions that could be made up of all = lesser=20 combinations the options"
 
That description is pretty ugly and could be fixed. It = says=20 that cn;a;b;c;d is in a direct subtype of:
cn;a
cn;a;b
cn;a;c
cn;a;d
cn;a;b;c
cn;a;b;d
cn;a;c;d
cn;b
cn;b;c
cn;b;d
cn;b;c;d
cn;c
cn;c;d
cn;d
 
This also tells me that attribute subtype inheritance is at most = two=20 levels, but infinitely wide (leaf can multiply inherit from any number= of=20 supertypes)
 
or
 
"An AttributeDescription with one option is treated as = a=20 direct subtype of the attribute type without any options. An=20 AttributeDescription with more than one option is treated as a direct = subtype of=20 all the possible AttributeDescriptions that could be made up of all = combinations=20 the options sans one option"
 
Using the former example, this produces:
cn;a (direct subtype of cn)
cn;b (direct subtype of cn)
cn;c (direct subtype of cn)
cn;d (direct subtype of cn)
cn;a;b (direct = subtype=20 of cn;a and cn;b)
cn;a;c (direct subtype of cn;a and cn;c)
cn;a;d (direct subtype of cn;a and cn;d)
cn;b;c (direct subtype of cn;b and cn;c)
cn;b;d (direct subtype of cn;b and cn;d)
cn;c;d (direct subtype = of=20 cn;c and cn;d)
cn;a;b;c (direct subtype of cn;a;b and = cn;a;c=20 and cn;b;c)
cn;a;b;d (direct subtype of cn;a;b and cn;a;d = and=20 cn;b;d)
cn;a;c;d (direct subtype of cn;a;c and cn;a;d = and=20 cn;c;d)
cn;b;c;d (direct subtype of cn;b;c and cn;b;d and=20 cn;c;d)
cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and=20 cn;a;c;d)

 
In the context of language tags, the implications might be benign, = but when=20 combining disparate options some combinations might cause problems.
 
I personally prefer 1). Though it may be less flexible, It's simpler = to=20 understand and fits well with the current subtyping model.
 
Jim
 

>>> "David Chadwick" <d.w.chadwick@salford.ac.uk>= =20 9/23/00 5:11:55 AM >>>

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

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

          = ;    =20 supertype
          &n= bsp; =20 /            &n= bsp;    =20 \
subtype=20 1            &n= bsp;      =20 subtype=20 2
           &nbs= p; =20 \            &n= bsp;   =20 /
           &nbs= p; =20 subtype1-2

David

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


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

Davi= d=20 Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 = 161=20 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email=20 D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac= .uk/its024/chadwick.htm
Understanding=20 X.500  http://www.salford.ac.uk/= its024/X500.htm
X.500/LDAP=20 Seminars http://www.salford.ac= .uk/its024/seminars.htm
Entrust=20 key validation string=20 MLJ9-DU5T-HV8J

***************************************************
--=_E0B82438.34553915-- From list@netscape.com Fri Oct 20 13:28: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 SMTP id NAA17271 for ; Fri, 20 Oct 2000 13:28: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 e9KHJfD29536; Fri, 20 Oct 2000 10:19:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9KHQhE14978; Fri, 20 Oct 2000 10:26:43 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 10:26:43 -0700 (PDT) Date: Fri, 20 Oct 2000 18:21:47 +0100 From: aeskr@aol.com Message-Id: <200010201721.SAA15004@mail.freecall-uk.co.uk> To: cnyss@generalpublic.netscape.com Reply-To: sam5u2@n2mail.com Subject: Affordable Offshore Income! [zqbuh] Resent-Message-ID: <"29vnBB.A.OpD.QBI85"@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 Partners Wanted - $100.00 to start. As a partner you can develop a secondary offshore income of $500 - $5,000 a day or more - you decide!! Take advantage of an OFFSHORE account with high projected returns, accessible with a secured, international MasterCard. All confidential. Unlimited global market, unlimited income. You can: Eliminate your debt Secure your Assets Own an offshore retirement fund Retain ALL your money with tax savings Pass your wealth on to your heirs The Super Rich have done this for years. Isn't it time you started? For more info, type "Offshore Info Please" as the subject. mailto:sam5@n2mail.com?subject=Offshore_Info_Please Have a Great Day! From list@netscape.com Fri Oct 20 13:36: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 NAA18254 for ; Fri, 20 Oct 2000 13:36: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 e9KHSLD01815; Fri, 20 Oct 2000 10:28:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9KHZNk19076; Fri, 20 Oct 2000 10:35:23 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 10:35:23 -0700 (PDT) Message-Id: <5.0.0.25.0.20001020103023.00a610d0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 20 Oct 2000 10:34:19 -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: <"kzdDCC.A.spE.aJI85"@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 Note that "cn;a;b;c;d" should be a direct subtype of "name;a;b;c;d" as well... From list@netscape.com Fri Oct 20 15:03:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28102 for ; Fri, 20 Oct 2000 15:03: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 e9KIlLs23882; Fri, 20 Oct 2000 11:47:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9KIwr602829; Fri, 20 Oct 2000 11:58:53 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 11:58:53 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 20 Oct 2000 12:57:56 -0600 From: "Steve Sonntag" To: Cc: , , "Alan Clark" , "Steven Merrill" Subject: Re: Java LDAP API - Unsolicited Notifications Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9FC75BAB.B3D2BE85" Resent-Message-ID: <"5SuWv.A.dr.rXJ85"@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. --=_9FC75BAB.B3D2BE85 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Is it possible using the JAVA API to check for and read unsolicited notifications, i.e. to get messages with messageID 0 as described by RFC2251? I am guessing, it is not possible, and I think the problem is that the API will probably throw them away because they are not a messageID associated with any request. Should there be a method in LDAPConnection that is something like setUnsolicitedNotifications(boolean arg) that enables or disables keeping unsolicited notifications where the default is false - throw them away. -Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software --=_9FC75BAB.B3D2BE85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
Is it possible using the JAVA API to check for
and read unsolicited notifications, i.e. to get<= /DIV>
messages with messageID 0 as described
by RFC2251?
 
I am guessing, it is not possible, and
I think the problem is that the API will probably
throw them away because they are not a messageID=
associated with any request.
 
Should there be a method in LDAPConnection
=
that is something like setUnsolicitedNotifications(bool= ean=20 arg)
that enables or disables keeping unsolicited
notifications where the default is false - throw = them=20 away.
 
-Steve
 
------------------------
Steve Sonntag
Novell, = Inc., the=20 leading provider of Net services software
 
 
--=_9FC75BAB.B3D2BE85-- From list@netscape.com Fri Oct 20 16:27: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 QAA14824 for ; Fri, 20 Oct 2000 16:27: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 e9KKIiD09993; Fri, 20 Oct 2000 13:18:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9KKPlE17727; Fri, 20 Oct 2000 13:25:47 -0700 (PDT) Resent-Date: Fri, 20 Oct 2000 13:25:47 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 20 Oct 2000 14:25:17 -0600 From: "Jim Sermersheim" To: Cc: , , Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_346CF03F.E584E8FC" Resent-Message-ID: <"K7hRW.A.qUE.KpK85"@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. --=_346CF03F.E584E8FC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yeah, but only if the server supports subtyping. >>> "Kurt D. Zeilenga" 10/20/00 11:34:19 AM >>> Note that "cn;a;b;c;d" should be a direct subtype of "name;a;b;c;d" as well... --=_346CF03F.E584E8FC Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, but only if the server supports=20 subtyping.

>>> "Kurt D. Zeilenga"=20 <Kurt@OpenLDAP.org> 10/20/00 11:34:19 AM >>>
Note = that=20 "cn;a;b;c;d" should be a direct subtype of "name;a;b;c;d"
as=20 well...

--=_346CF03F.E584E8FC-- From list@netscape.com Sat Oct 21 11:09: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 LAA13358 for ; Sat, 21 Oct 2000 11:09: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 e9LF0hD18193; Sat, 21 Oct 2000 08:00:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LF7kQ15836; Sat, 21 Oct 2000 08:07:46 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:07:46 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Skovgaard, Erik" , ldapext Date: Sat, 21 Oct 2000 16:08:21 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: which naming attribute ... Reply-to: d.w.chadwick@salford.ac.uk CC: ldapext Message-ID: <39F1BF75.14762.F975E4@localhost> Priority: normal In-reply-to: <9F83DF9B4DD5D111999B00A0C96B12B60402A219@stca103a.bus.sc.rolm.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"rx2tTD.A.w2D.AFb85"@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 > As a matter of interest, aliasedObjectName does not exist in X.500. > It is called aliasedEntryName. I am not sure if this is an oversight > or deliberate change. The correct term for a node in the DIT is > 'entry', not object. It was called aliasedObjectName in the 1988 standard and changed to aliasedEntryName in the 93 standard. David > > Cheers, ....Erik. > > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Wednesday, October 11, 2000 12:09 To: sanjay jain Cc: ldapext > Subject: Re: which naming attribute ... > > > Sanjay, > > As I recall, in Novell's implementation (the Novell guys can correct > me if I'm misremembering), NDS enforces the naming rules mandated by > the base class of the object the Alias points to. So, if the alias > points to a user object, you could use the cn attribute as a naming > attribute. Similarly, if the alias points to an organizationalUnit > object, you could use the ou attribute as a naming attribute. This > behaviour is unique to Novell's implementation. In other > implementations, you should use the aliasedObjectName as the naming > attribute. > > 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 > > *************************************************** 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 Oct 21 11:09: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 LAA13382 for ; Sat, 21 Oct 2000 11:09: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 e9LEuSs10311; Sat, 21 Oct 2000 07:56:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LF82k16167; Sat, 21 Oct 2000 08:08:02 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:08:02 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Date: Sat, 21 Oct 2000 16:08:22 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Matched values: valuesReturnFilter string representation Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39F1BF76.18559.F97883@localhost> Priority: normal In-reply-to: <5.0.0.25.0.20001017223917.00a7b850@router.boolean.net> References: <200010171050.GAA07225@ietf.org> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"BrCdAD.A.d7D.PFb85"@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 From: "Kurt D. Zeilenga" > Section 5 says: > The string representation of the valuesReturnFilter in the examples > below uses the notation defined in RFC 2254 [11]. > > However, as a valuesReturnFilter is a sequence of simple > filters, the string representation of valuesReturnFilter is > actually more like: > > valuesReturnFilter = "(" 1*simplefilter ")" > simplefilter = "(" item ")" Yes you are right > > where item is as defined by RFC2254. I suggest the string > representation should be specified in the I-D. Do you mean repeating all the "item" BNF from 2254, or just inserting the 2 lines above. I have assumed the latter and made that change. > > Using the above BNF, all of the single item valueReturnFilter > presented in the examples need to be wrapped by another set of > parens, e.g: ((attributeTypes=1.2.3.4.5)) agreed and done for version 5. David > > One could define a BNF that for sequences of 1 simplefilter > the outer parens were eliminated. However, having the > outer parens distinguishes valueReturnFilters from > filters. > > 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 Sat Oct 21 11:09: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 LAA13407 for ; Sat, 21 Oct 2000 11:09: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 e9LEufs10448; Sat, 21 Oct 2000 07:56:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LF8EU16401; Sat, 21 Oct 2000 08:08:14 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:08:14 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Jim Sermersheim" , , Date: Sat, 21 Oct 2000 16:08:23 +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: <39F1BF77.11677.F97C56@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"yo8ukB.A._-D.bFb85"@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, 20 Oct 2000 09:57:30 -0700 (PDT) Date sent: Fri, 20 Oct 2000 10:56:01 -0600 From: "Jim Sermersheim" To: Copies to: , Subject: Re: RFC 2596 questions Forwarded by: ietf-ldapext@netscape.com > Getting back to this: > > The example David gives below shows a subtype inheriting from multiple > supertypes. As of yet, I believe that this is illegal in X.500/LDAP It might be illegal in LDAP but it is not illegal in X.501. > and as such might cause problems with existing servers. > > I don't have a good feeling of closure on this subject. We need to > revise 4.1.5 of RFC 2251 to say one of the following: From the 3 options I prefer option 3 from a modelling perspective, but pragmatically what are the implementation implications of the 3 different models (not being a server implementer myself)? David > > 1) "An AttributeDescription with one or more options is treated as a > direct subtype of the attribute type without any options" (inserted > direct) > > or > > 2) "An AttributeDescription with one option is treated as a direct > subtype of the attribute type without any options. An > AttributeDescription with more than one option is treated as a direct > subtype of all the possible AttributeDescriptions that could be made > up of all lesser combinations the options" > > That description is pretty ugly and could be fixed. It says that > cn;a;b;c;d is in a direct subtype of: cn;a cn;a;b cn;a;c cn;a;d > cn;a;b;c cn;a;b;d cn;a;c;d cn;b cn;b;c cn;b;d cn;b;c;d cn;c cn;c;d > cn;d > > This also tells me that attribute subtype inheritance is at most two > levels, but infinitely wide (leaf can multiply inherit from any number > of supertypes) > > or > > "An AttributeDescription with one option is treated as a direct > subtype of the attribute type without any options. An > AttributeDescription with more than one option is treated as a direct > subtype of all the possible AttributeDescriptions that could be made > up of all combinations the options sans one option" > > Using the former example, this produces: > cn;a (direct subtype of cn) > cn;b (direct subtype of cn) > cn;c (direct subtype of cn) > cn;d (direct subtype of cn) > cn;a;b (direct subtype of cn;a and cn;b) > cn;a;c (direct subtype of cn;a and cn;c) > cn;a;d (direct subtype of cn;a and cn;d) > cn;b;c (direct subtype of cn;b and cn;c) > cn;b;d (direct subtype of cn;b and cn;d) > cn;c;d (direct subtype of cn;c and cn;d) > cn;a;b;c (direct subtype of cn;a;b and cn;a;c and cn;b;c) > cn;a;b;d (direct subtype of cn;a;b and cn;a;d and cn;b;d) > cn;a;c;d (direct subtype of cn;a;c and cn;a;d and cn;c;d) > cn;b;c;d (direct subtype of cn;b;c and cn;b;d and cn;c;d) > cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and cn;a;c;d) > > > In the context of language tags, the implications might be benign, but > when combining disparate options some combinations might cause > problems. > > I personally prefer 1). Though it may be less flexible, It's simpler > to understand and fits well with the current subtyping model. > > Jim > > > >>> "David Chadwick" 9/23/00 5:11:55 AM > >>> >>> > > > 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 > > *************************************************** > *************************************************** 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 Oct 21 11:11: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 LAA13595 for ; Sat, 21 Oct 2000 11:11: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 e9LEv0s10683; Sat, 21 Oct 2000 07:57:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LF8YA16874; Sat, 21 Oct 2000 08:08:34 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:08:34 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Date: Sat, 21 Oct 2000 16:08:23 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Returning Matched Values with LDAPv3 Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Message-ID: <39F1BF77.21687.F97EDF@localhost> Priority: normal In-reply-to: <5.0.0.25.0.20001017115523.00a59630@router.boolean.net> References: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"ftZLv.A.DGE.rFb85"@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 From: "Kurt D. Zeilenga" > At 01:44 PM 10/17/00 -0500, david.a.cahlander@syntegra.com wrote: >It > is not clear from the description if example (2) could return the > result >on the basis of the name 'gunk' instead of on the basis of the > OID. > >Does the substring filter capability allow a filter of the > form: > > (attributeTypes=*'gunk'*) > > There is no substrings matching rule for attributeTypes, so this > assertion is 'Undefined'. > > I suggest the example use (attributeTypes=2.5.4.3) as the equality > matching rule for attributeTypes is > objectIdentifierFirstComponentMatch which requires an assertion value > of syntax OID. Kurt, I dont understand why changing the example to retrieve cn rather than gunk will help the understanding. Further, since everyone already knows the definition of cn, one might ask why are we wanting to retrieve this definition! > Some servers support (attributeTypes=cn) as well. Then we need to formally specify a stringThirdComponent matching rule as an equality matching rule for attributeTypes, if we are to widely support this. (Note this is counting NAME as the second component). Should we do this? > > >If I knew the OID number of "gunk", the entire "attributeTypes" > >attribute of the schema entry has probably been read, and I don't > >need the LDAP extension to read it. > > You need an LDAP extension to return only the matched values. > > >An example to retrieve an "objectClasses" attribute would help. to retrieve the objectClasses attribute definition the valuesReturnFilter would be ((attributeTypes=2.5.21.6)) to retrieve the complete objectClasses attribute from an entry, you dont need the valuesReturnFilter as you want all the values to be returned to retrieve a specific objectClasses attribute value from the objectClasses attribute of an entry, the valuesReturnFilter would be ((objectClasses=)) > > (objectClasses=2.5.4.0) Kurt, I am not quite sure what the above filter is meant to be David > > or > (objectClasses=objectclass) // supported by some servers > > 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 Sat Oct 21 11:12:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13699 for ; Sat, 21 Oct 2000 11:12: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 e9LEuls10528; Sat, 21 Oct 2000 07:56:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LF8LI16592; Sat, 21 Oct 2000 08:08:21 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:08:21 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Haripriya S" , Date: Sat, 21 Oct 2000 16:08:24 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ACL access decision question Reply-to: d.w.chadwick@salford.ac.uk Message-ID: <39F1BF78.30109.F982DC@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"yqW8PD.A.1AE.gFb85"@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, 13 Oct 2000 05:18:03 -0700 (PDT) Date sent: Fri, 13 Oct 2000 06:17:41 -0600 From: "Haripriya S" To: Subject: ACL access decision question Forwarded by: ietf-ldapext@netscape.com Haripriya I have already raised a similar issue with Ellen. My point is that the aci should be ordered in a precedence order and then you move down the list for the particular operation you are evaluating. If it is a modify operation, then the aci2 would be used to grant permission to add values (but not remove them), and if it is a search operation you are evaluating, then aci1 would be used to grant read permission to attrname David > Hi, > > The ACL model draft says that more specific functions should override > less specific ones, and deny overrides grant. Also, it says > specificity applies to both subject and attributes. > > Now given two ACIs for a target entry: > > aci1: entry#grant:r#attrname#group:cn=g1,o=n > aci2: entry#grant:w#[all]#authzID-dn:cn=u1,o=n > > If u1 belongs to group g1, which aci takes precedence? > aci1: because attrname is more specific than [all] or > aci2: because authxID-dn is more specific than group > > What happens if one is grant:w and another is deny:w in the above > case? > > What is the precedence relation between various dimensions of ACIs: > scope, target specificity, subject specificity, attribute specificity, > and grant/deny. > > Thanks and Regards, > Haripriya > *************************************************** 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 Oct 21 11:34: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 LAA16134 for ; Sat, 21 Oct 2000 11:34: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 e9LFLFs13172; Sat, 21 Oct 2000 08:21:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LFWos23056; Sat, 21 Oct 2000 08:32:50 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:32:50 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021081410.00a75270@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 08:32:09 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Returning Matched Values with LDAPv3 Cc: ietf-ldapext@netscape.com, ietf-ldapext@netscape.com In-Reply-To: <39F1BF77.21687.F97EDF@localhost> References: <5.0.0.25.0.20001017115523.00a59630@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"mWhp9B.A.7nF.gcb85"@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 04:08 PM 10/21/00 +0100, David Chadwick wrote: >From: "Kurt D. Zeilenga" > >> At 01:44 PM 10/17/00 -0500, david.a.cahlander@syntegra.com wrote: >It >> is not clear from the description if example (2) could return the >> result >on the basis of the name 'gunk' instead of on the basis of the >> OID. > >Does the substring filter capability allow a filter of the >> form: > > (attributeTypes=*'gunk'*) >> >> There is no substrings matching rule for attributeTypes, so this >> assertion is 'Undefined'. >> >> I suggest the example use (attributeTypes=2.5.4.3) as the equality >> matching rule for attributeTypes is >> objectIdentifierFirstComponentMatch which requires an assertion value >> of syntax OID. > >Kurt, I dont understand why changing the example to retrieve cn >rather than gunk will help the understanding. I changed (attributeTypes=*'gunk'*) to (attributeTypes=2.5.4.3) namely because as attribute types has no substrings matching rule, the name/OID itself doesn't matter. >Further, since >everyone already knows the definition of cn, one might ask why are >we wanting to retrieve this definition! Sadily enough, my value may not be the same as yours! Note that there are some alterations allowed by the RFC 2252. In particular, an implementation is free to recognize alternative names and to add private experiments (X- terms) to standard track schema items. >> Some servers support (attributeTypes=cn) as well. > >Then we need to formally specify a stringThirdComponent matching >rule as an equality matching rule for attributeTypes, if we are to >widely support this. (Note this is counting NAME as the second >component). Should we do this? You could define another matching rule, but the practice is actually to overload the existing equality matching rule. Given that we overload NAMEs/OIDs most everywhere else, it seems natural to me to overload it here as well. >> >If I knew the OID number of "gunk", the entire "attributeTypes" >> >attribute of the schema entry has probably been read, and I don't >> >need the LDAP extension to read it. >> >> You need an LDAP extension to return only the matched values. >> >> >An example to retrieve an "objectClasses" attribute would help. > >to retrieve the objectClasses attribute definition the >valuesReturnFilter would be ((attributeTypes=2.5.21.6)) I meant an example to retreive an specific objectClasses value, e.g. ((objectClasses=1.2.3.4)), would be nice to include. >> (objectClasses=2.5.4.0) > >Kurt, I am not quite sure what the above filter is meant to be It should be ((objectClasses=2.5.4.0))... match the objectClasses value with OID 2.5.4.0. From list@netscape.com Sat Oct 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 LAA16530 for ; Sat, 21 Oct 2000 11:37: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 e9LFTLD21528; Sat, 21 Oct 2000 08:29:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LFaPE24251; Sat, 21 Oct 2000 08:36:25 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 08:36:25 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021083240.00a78280@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 08:36:04 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: Matched values: valuesReturnFilter string representation Cc: ietf-ldapext@netscape.com In-Reply-To: <39F1BF76.18559.F97883@localhost> References: <5.0.0.25.0.20001017223917.00a7b850@router.boolean.net> <200010171050.GAA07225@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"CmbFxB.A.i6F.4fb85"@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 04:08 PM 10/21/00 +0100, David Chadwick wrote: >> where item is as defined by RFC2254. I suggest the string >> representation should be specified in the I-D. > >Do you mean repeating all the "item" BNF from 2254, or just >inserting the 2 lines above. I have assumed the latter and made that >change. I prefer the latter. However, it would be okay to include an "informational purposes only" copy the BNF from 2254 if so desired. From list@netscape.com Sat Oct 21 12:15: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 MAA20584 for ; Sat, 21 Oct 2000 12:15: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 e9LG6RD23416; Sat, 21 Oct 2000 09:06:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LGDV601426; Sat, 21 Oct 2000 09:13:31 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 09:13:31 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021085809.00a48650@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 09:12:54 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC 2596 questions Cc: In-Reply-To: <39F1BF77.11677.F97C56@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"BWTG0.A.zV.pCc85"@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 04:08 PM 10/21/00 +0100, David Chadwick wrote: >> The example David gives below shows a subtype inheriting from multiple >> supertypes. As of yet, I believe that this is illegal in X.500/LDAP > >It might be illegal in LDAP but it is not illegal in X.501. ????? The X.501(93~97) AttributeTypeDescription appears to allow only one 'derivation'... that is, an attribute type can have zero or one direct supertypes. (I'm actually looking at a draft of the 97 spec) From list@netscape.com Sat Oct 21 12:59: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 MAA25452 for ; Sat, 21 Oct 2000 12:59: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 e9LGpDD25747; Sat, 21 Oct 2000 09:51:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LGwHA09484; Sat, 21 Oct 2000 09:58:17 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 09:58:17 -0700 (PDT) Message-Id: <002d01c03b7f$f3645c60$82dc8f96@arhdialin.cdc.com> Reply-To: "David A. Cahlander" From: "David A. Cahlander" To: , "Kurt D. Zeilenga" Cc: References: <5.0.0.25.0.20001017115523.00a59630@router.boolean.net> <5.0.0.25.0.20001021081410.00a75270@router.boolean.net> Subject: Re: Returning Matched Values with LDAPv3 Date: Sat, 21 Oct 2000 11:57:08 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"P6ZASB.A.3TC.nsc85"@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 think that I now understand your answer to the question about the operation of example (2). The attribute filter: ((attributeTypes=1.2.3.4.5)) should return the same results as ((attributeTypes=gunk)) since the right hand side of the "attributeTypes=" needs to go through some string to OID conversion. This conversion would return the same results for both filter values. In particular, this produces a very useful operation for a client. The user creates an LDAP search operation with a baseObject set to cn=subschema subentry, o=myorg, a scope of base, a filter set to (objectClass=subschema), the list of attributes to be returned set to "objectClasses", and the ValuesReturnFilter set to ((objectClasses=inetOrgPerson)) The search result returned by the server would consist of the following entry: dn: cn=subschema subentry, o=myorg objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) Thanks. --- David Cahlander David.A.Cahlander@syntegra.com 651-415-3171 From list@netscape.com Sat Oct 21 14:03: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 OAA02476 for ; Sat, 21 Oct 2000 14:03: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 e9LHslD28956; Sat, 21 Oct 2000 10:54:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LI1pA21999; Sat, 21 Oct 2000 11:01:51 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 11:01:51 -0700 (PDT) Date: Sat, 21 Oct 2000 11:01:09 -0700 (PDT) Message-Id: <200010211801.e9LI0wR02773@xwing.netscape.com> From: wmb@AVWU.flashmail.com To: Friend@netscape.com Subject: Free 32 Page Booklet... Earn $5,000/Week -INTC X-Reply-To: wmb3@mail.flashmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"P1xjbC.A.aXF.Nod85"@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, You can earn up to $5,000 a week within 180 days with our amazing new Internet Marketing Program. InfoShare is a breakthrough Web Marketing concept that cannot fail. Find out how to earn more money than you ever dreamed possible. Download our FREE 32 page booklet "Earn Big Money With InfoShare" NOW! It normally would cost as much as $99.95, but for now I am giving it away... absolutely FREE! Just hit reply and type "Send Booklet" in the subject line. Best Regards Willie wmb3@mail.flashmail.com From list@netscape.com Sat Oct 21 14:59: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 OAA11235 for ; Sat, 21 Oct 2000 14:59: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 e9LIkAs23993; Sat, 21 Oct 2000 11:46:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LIviU02331; Sat, 21 Oct 2000 11:57:44 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 11:57:44 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "David A. Cahlander" , Date: Sat, 21 Oct 2000 19:58:33 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Returning Matched Values with LDAPv3 Reply-to: d.w.chadwick@salford.ac.uk CC: Mark Wahl Message-ID: <39F1F569.29806.1CC3F92@localhost> Priority: normal In-reply-to: <002d01c03b7f$f3645c60$82dc8f96@arhdialin.cdc.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"3YSccB.A.Gk.mce85"@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: "David A. Cahlander" From: "David A. Cahlander" > I think that I now understand your answer to the question about the > operation of example (2). The attribute filter: > > ((attributeTypes=1.2.3.4.5)) > > should return the same results as > > ((attributeTypes=gunk)) > > since the right hand side of the "attributeTypes=" needs to go through > some string to OID conversion. This conversion would return the same > results for both filter values. I also now see where you are coming from, and I agree that it is an improvement to the ID to add the facility for the user to present the string of the schema element rather than its OID. This does require a change somewhere in the LDAP specs to say that schema names and OIDs can be used interchangably in the protocol. I am not sure where this change should go, but will ask Mark to comment on this. Were you wanting the following example to go into the ID, or are you happy with the attribute example being enough David > > In particular, this produces a very useful operation for a client. > > The user creates an LDAP search operation with a baseObject set to > cn=subschema subentry, o=myorg, a scope of base, a filter set to > (objectClass=subschema), the list of attributes to be returned set to > "objectClasses", and the ValuesReturnFilter set to > ((objectClasses=inetOrgPerson)) > > The search result returned by the server would consist of the > following entry: > > dn: cn=subschema subentry, o=myorg > objectClasses: ( 2.16.840.1.113730.3.2.2 > NAME 'inetOrgPerson' > SUP organizationalPerson > STRUCTURAL > MAY ( > audio $ businessCategory $ carLicense $ departmentNumber $ > displayName $ employeeNumber $ employeeType $ givenName $ > homePhone $ homePostalAddress $ initials $ jpegPhoto $ > labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ > roomNumber $ secretary $ uid $ userCertificate $ > x500uniqueIdentifier $ preferredLanguage $ > userSMIMECertificate $ userPKCS12 > ) > ) > > Thanks. > --- > David Cahlander David.A.Cahlander@syntegra.com 651-415-3171 > > > *************************************************** 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 Oct 21 14:59: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 OAA11273 for ; Sat, 21 Oct 2000 14:59: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 e9LIkSs24167; Sat, 21 Oct 2000 11:46:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LIw1202631; Sat, 21 Oct 2000 11:58:01 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 11:58:01 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , Date: Sat, 21 Oct 2000 19:58:33 +0100 MIME-Version: 1.0 Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Subject: Re: RFC 2596 questions Reply-to: d.w.chadwick@salford.ac.uk CC: Message-ID: <39F1F569.5231.1CC3CC7@localhost> Priority: normal In-reply-to: <5.0.0.25.0.20001021085809.00a48650@router.boolean.net> References: <39F1BF77.11677.F97C56@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"Tq3PDC.A.7n.2ce85"@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: Quoted-printable Date sent: Sat, 21 Oct 2000 09:12:54 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" < 0000,0000,0000> > The X.501(93~97) AttributeTypeDescription appears to allow > only one 'derivation'... that is, an attribute type can > have zero or one direct supertypes. > I am basing my evidence of support for multiple superclasses on th= e following from X.501 (and also that I was at the meeting when it was discussed and agreed upon) 0100,0100,0100Ti= mes7.1.13 subclass: Relative to one or more superc= lasses =96 an object class derived from one or more superclasses. The members of the subclass share all the charac= teristics of the super classes and additional characteristics possessed by none of the = members of those superclasses. from 7.2 An object class is an identified family of obj= ects, or conceivable objects, which share certain characteristics. Every object belongs to at least one class. An ob= ject class may be a subclass of other object classes, in which case the = members of the former class, the subclass, are also considered to be members of the latter classes, the= superclasses. There may be subclasses of subclasses, etc., to an arbitrary depth. From 7.3 Each entry contains an indication of the object classes, and th= eir superclasses, to which the entry belongs. From 8.3 An object class may be derived from two or more direct supercla= sses (superclasses not part of the same superclass chain). This feature of subclassing is termed = multiple inheritance. 12.3 Object class definition The definition of an object class involves: outa) indicating which classes this = object class is to be a subclass of; outb) indicating what kind of object= class is being defined; outc) listing the mandatory<= /italic> attribute types that an entry of the object class shall contain in addition to the mandatory attribute types of all its superclasses; outd) listing the optional <= /italic>attribute types that an entry of the object class may contain in addition to the optional attributes of all its superclasses; oute) assigning an object identifier= for the object class. I think this is pretty conclusive evidence that multiple superclasses are = supported (i.e. multiple inheritance) David 0000,0000,0000Arial> > *************************************************** 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 Oct 21 14:59:49 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11311 for ; Sat, 21 Oct 2000 14:59: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 e9LIkTs24179; Sat, 21 Oct 2000 11:46:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LIw2o02635; Sat, 21 Oct 2000 11:58:02 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 11:58:02 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, ietf-ldapext@netscape.com Date: Sat, 21 Oct 2000 19:58:34 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Returning Matched Values with LDAPv3 Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com, ietf-ldapext@netscape.com Message-ID: <39F1F56A.10180.1CC443D@localhost> Priority: normal In-reply-to: <5.0.0.25.0.20001021081410.00a75270@router.boolean.net> References: <39F1BF77.21687.F97EDF@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"uGMJUB.A.Go.3ce85"@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 sent: Sat, 21 Oct 2000 08:32:09 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" > Sadily enough, my value may not be the same as yours! Note > that there are some alterations allowed by the RFC 2252. In > particular, an implementation is free to recognize alternative > names and to add private experiments (X- terms) to standard > track schema items. > Clearly a private implementation can do what the heck it likes, but that does not mean that we should support or condone it. I can build an IP intranet using your IP addresses if I want, but I would not expect the Internet to support me when I tried to connect into it. Consequently we should not provide any hooks for private directories that take standard schema definitions/OIDs and add their own bits to it. And I am including here MS and Netscape who I believe have both altered the definition of oc top - in different ways of course - whilst keeping the X.500 oid. Thus we should be stating somewhere that if an implementation uses a standard OID then it MUST use the standard definition to go along with it. As there is no shortage of OIDs that I am aware, they can redine standard schema elements to their heart's content, as long as they use private OIDs for their new definitions. > >> Some servers support (attributeTypes=cn) as well. > > > >Then we need to formally specify a stringThirdComponent matching rule > >as an equality matching rule for attributeTypes, if we are to widely > >support this. (Note this is counting NAME as the second component). > >Should we do this? > > You could define another matching rule, but the practice is actually > to overload the existing equality matching rule. Given that we > overload NAMEs/OIDs most everywhere else, it seems natural to me to > overload it here as well. I agree, providing that somewhere it is clearly specified that OIDs and string names are freely interchangeable and implementation MUST support this. Should this be sent to the bis list? > I meant an example to retreive an specific objectClasses > value, e.g. ((objectClasses=1.2.3.4)), would be nice to include. > > >> (objectClasses=2.5.4.0) > > > >Kurt, I am not quite sure what the above filter is meant to be > > It should be ((objectClasses=2.5.4.0))... match the objectClasses > value with OID 2.5.4.0. there wont be any, as all of 2.5.4 are reserved for attribute types. This is why I was confused by your example. X.500 OCs all start with 2.5.6 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 Oct 21 15:12: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 PAA12732 for ; Sat, 21 Oct 2000 15:12: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 e9LJ44D04043; Sat, 21 Oct 2000 12:04:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LJB8k07167; Sat, 21 Oct 2000 12:11:08 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 12:11:08 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021120927.00a88d00@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 12:10:31 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC 2596 questions Cc: In-Reply-To: <39F1F569.5231.1CC3CC7@localhost> References: <5.0.0.25.0.20001021085809.00a48650@router.boolean.net> <39F1BF77.11677.F97C56@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Jii3hD.A.qvB.Lpe85"@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:58 PM 10/21/00 +0100, David Chadwick wrote: >I think this is pretty conclusive evidence that multiple superclasses are supported (i.e. multiple inheritance) Of object classes, yes. But we're talking about multiple inheritance of attribute types. From list@netscape.com Sat Oct 21 16:19: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 QAA19909 for ; Sat, 21 Oct 2000 16:19: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 e9LKAXD07505; Sat, 21 Oct 2000 13:10:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LKHb619116; Sat, 21 Oct 2000 13:17:37 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 13:17:37 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Ed Reed" , , Date: Sat, 21 Oct 2000 21:17:50 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fwd: controlling visability of subentries Reply-to: d.w.chadwick@salford.ac.uk CC: , Message-ID: <39F207FE.21899.214D7E8@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"K-9Lh.A.XqE.gnf85"@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 sent: Wed, 18 Oct 2000 21:24:49 -0600 From: "Ed Reed" To: Copies to: , Subject: Re: Fwd: controlling visability of subentries > Okay, Kurt - I've reviewed what X.511 specifies for the service > control used to control subentry visibility. What is your opinion on > what we should do in LDAP? Ed I prefer option 1 for the following reasons i) several of the common arguments are already in LDAP e.g size limit so we dont want to add them again ii) at least one is already a LDAPv3 control e.g. manageDSAIT iii) we have had previous battles over some of the other common arguments (esp dontUseCopy) and there was no concensus to add them so it would not be sensible to add them all in one go. KISS David > > 1) create a control which has no parameters, but has the effect that > when it is present, it is interpreted identically to an X.511 service > control with the subentries bit set TRUE; or > > 2) create a control which has a parameter identical to the service > control specified by X.511. This would have the effect of providing a > lot of the additional controls needed to add distributed operations to > LDAP (including preferChaining, chainingProhibited, etc.), but would > also provide things like timeLimit, sizeLimit, scopeOfReferral, and > attributeSizeLimit, etc. In X.511, the serviceControls are among the > CommonArguments included with each request. > > I suppose we could consider the list of controls in LDAP providing the > equivalent to the set of CommonArguments. > > What's your take? 1 would be easier to document. 2 would lay > important groundwork that should be considered in the context of > future work to add distributed operations to LDAP. > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >Subject: controlling visability of subentries > > > >One other issue I would like to raise in regards to LDAP subentry is > >the mechanism proposed to control their visibility. I believe the > >approach of overloading the search filter to control visibility is > >not the best approach. As we've found previously, the semantics of > >such overloads are difficult to define (and hence implement) when the > >filter is complex (which we must assume it will be). > > > >I believe that LDAPsubentry visibility should be control by a > >mechanism more closely modeled after the X.500 subentry visibility > >mechanism. In particular, I suggest use of a control. The use of a > >control will allow a clear and concise specification of visibility > >semantics which facilitates implementation and use. > > > >Comments? > > > > 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 Sat Oct 21 16:19: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 QAA19919 for ; Sat, 21 Oct 2000 16:19: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 e9LKAfD07567; Sat, 21 Oct 2000 13:10:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LKHjI19247; Sat, 21 Oct 2000 13:17:45 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 13:17:45 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: sanjay jain , Mark Smith Date: Sat, 21 Oct 2000 21:17:52 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Fwd: controlling visability of subentries Reply-to: d.w.chadwick@salford.ac.uk CC: Volpers Helmut , "'Kurt D. Zeilenga'" , Ed Reed , ietf-ldup@imc.org, ietf-ldapext@netscape.com Message-ID: <39F20800.22032.214DE2D@localhost> Priority: normal In-reply-to: <39EF3FDF.1C86C55B@netscape.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"x0YAKD.A.wrE.lnf85"@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 sent: Thu, 19 Oct 2000 14:39:27 -0400 From: Mark Smith > Perhaps. A reasonable compromise might be to return LDAP subentries > in these two cases: Mark I agree with you. If the dn of the subentry is used in a base Search (and the schema subentry DN can be easily got from every entry that holds the subschemaSubentry op attribute for example), then it would be churlish to not return any information just because the control is not set David > > 1) When a returnSubEntries control (to be defined) is present in the > search request. > > 2) When the scope of the search is baseObject. > > Why return LDAP subentries in case 2)? Because it is more compatible > with 2251. And because I do not think it does any harm -- if a client > knows the name of a subentry, it might just as well be able to > retrieve it without using any controls. Comments? > > -- > Mark Smith > Netscape > *************************************************** 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 Oct 21 16:30: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 QAA21107 for ; Sat, 21 Oct 2000 16:30: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 e9LKGws00633; Sat, 21 Oct 2000 13:16:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LKSWo22450; Sat, 21 Oct 2000 13:28:32 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 13:28:32 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021121749.00a73b50@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 13:28:06 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: attributeTypes value variences (Was: Returning Matched Values with LDAPv3) Cc: ietf-ldapext@netscape.com, ietf-ldapbis@openldap.org In-Reply-To: <39F1F56A.10180.1CC443D@localhost> References: <5.0.0.25.0.20001021081410.00a75270@router.boolean.net> <39F1BF77.21687.F97EDF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"M0DnSC.A.deF.vxf85"@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:58 PM 10/21/00 +0100, David Chadwick wrote: [trimmed] >Clearly a private implementation can do what the heck it likes, but >that does not mean that we should support or condone it. I can build >an IP intranet using your IP addresses if I want, but I would not >expect the Internet to support me when I tried to connect into it. >Consequently we should not provide any hooks for private >directories that take standard schema definitions/OIDs and add >their own bits to it. RFC 2252 only allows limited alternation by implementations. In particular, it allows for implementation to recognize attribute types by alternative names. This allows a server to recognize 'commonName' as a alternative to 'cn'. This allows a server to provide compatibility to clients which don't yet use standard track names WITHOUT breaking clients adhering to the specification. This is good. I believe the schema description extension mechanism is provided to support extension of the underlying ASN.1. RFC 2251 says that implementations must ignore elements of SEQUENCE encodings whose tags they do not recognize. LDAP schema descriptions are string representations of SEQUENCE elements. It's my belief that the extension mechanism is provided so that the string representation can adapt to future changes in to the SEQUENCE. This is good. To support such change, RFC 2252 allows for various schema descriptions formats to be updated. It hoped that such changes, if necessary, can be made in manner which provides both forward and backwards compatibility. Regrettably, the extension mechanism for standard track extensions doesn't provide the same compatibility as the private extensions mechanism does (because standard track extensions term are not restricted to being followed by ). (LDAPbis might want to consider adding such a restriction). >Thus we should be stating somewhere that if an implementation >uses a standard OID then it MUST use the standard definition to go >along with it. Today's spec or tomorrow's? I believe we need to provide means for updating the specification in a manner which provides forward and backwards compatibility. I believe the schema extensions mechanisms and allowed variences are designed to, and when used appropriately, improve interoperability. I also support mechanisms designed to allow private experimentation in manner which doesn't break implementations which conform to the standard track specification. There are a number of such extensions which I hope will eventually become standard track. (For example, extensions indicating which LDAP syntaxes the server allows/requires ;binary transfer for). I concur that implementations should not make any change which are not allowed by the specifications. There are some cases where the specifications likely need to be tightened. In particular, if a server should not return a requested standard track attribute by a non-standard track names unless explicitly requested to do so. >> >> Some servers support (attributeTypes=cn) as well. >> > >> >Then we need to formally specify a stringThirdComponent matching rule >> >as an equality matching rule for attributeTypes, if we are to widely >> >support this. (Note this is counting NAME as the second component). >> >Should we do this? >> >> You could define another matching rule, but the practice is actually >> to overload the existing equality matching rule. Given that we >> overload NAMEs/OIDs most everywhere else, it seems natural to me to >> overload it here as well. > >I agree, providing that somewhere it is clearly specified that OIDs >and string names are freely interchangeable and implementation >MUST support this. Should this be sent to the bis list? I believe so. I've cc'ed ldapbis in my reply. >> I meant an example to retreive an specific objectClasses >> value, e.g. ((objectClasses=1.2.3.4)), would be nice to include. >> >> >> (objectClasses=2.5.4.0) >> > >> >Kurt, I am not quite sure what the above filter is meant to be >> >> It should be ((objectClasses=2.5.4.0))... match the objectClasses >> value with OID 2.5.4.0. > >there wont be any, as all of 2.5.4 are reserved for attribute types. >This is why I was confused by your example. X.500 OCs all start >with 2.5.6 Sorry for the confusion. BTW, I suggest using OID/NAMES from RFC 2252/2256 in examples. (note that implementations are not required to provide all schema elements detailed in the "core" specification). From list@netscape.com Sat Oct 21 17:03: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 RAA24783 for ; Sat, 21 Oct 2000 17:03: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 e9LKrpD10565; Sat, 21 Oct 2000 13:53:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LL0ts28170; Sat, 21 Oct 2000 14:00:55 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 14:00:55 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021134723.00a7e710@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 14:00:20 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: objectIdentifier{,First}Match Cc: , In-Reply-To: <39F1F569.29806.1CC3F92@localhost> References: <002d01c03b7f$f3645c60$82dc8f96@arhdialin.cdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"oiZ4hB.A.13G.GQg85"@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:58 PM 10/21/00 +0100, David Chadwick wrote: >This [(attributeTypes=desc) matching] does require a change somewhere in the LDAP specs to say >that schema names and OIDs can be used interchangably in the >protocol. I am not sure where this change should go, but will ask >Mark to comment on this. RFC 2252, 4.1/8.1/8.4 indicate that matching rules should support "descr" OID forms. Some clarification here may be appropriate. Kurt From list@netscape.com Sat Oct 21 17:05: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 RAA25018 for ; Sat, 21 Oct 2000 17:05: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 e9LKv5D11064; Sat, 21 Oct 2000 13:57:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LL49A29293; Sat, 21 Oct 2000 14:04:09 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 14:04:09 -0700 (PDT) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , Date: Sat, 21 Oct 2000 22:04:00 +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: <39F212D0.17925.23F1C7F@localhost> Priority: normal In-reply-to: <5.0.0.25.0.20001021120927.00a88d00@router.boolean.net> References: <39F1F569.5231.1CC3CC7@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Resent-Message-ID: <"If8sEC.A.YJH.ITg85"@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: Sat, 21 Oct 2000 12:11:09 -0700 (PDT) Date sent: Sat, 21 Oct 2000 12:10:31 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC 2596 questions Copies to: Forwarded by: ietf-ldapext@netscape.com > At 07:58 PM 10/21/00 +0100, David Chadwick wrote: > >I think this is pretty conclusive evidence that multiple superclasses > >are supported (i.e. multiple inheritance) > > Of object classes, yes. > But we're talking about multiple inheritance of attribute types. > > Slight disconnect there !. I agree that multiple inheritance of attribute types is not supported by X.501 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 Oct 21 19:26:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10326 for ; Sat, 21 Oct 2000 19:26:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9LNHmD17301; Sat, 21 Oct 2000 16:17:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9LNOrY23480; Sat, 21 Oct 2000 16:24:53 -0700 (PDT) Resent-Date: Sat, 21 Oct 2000 16:24:53 -0700 (PDT) Message-Id: <5.0.0.25.0.20001021153534.00a92870@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Oct 2000 16:24:22 -0700 To: mark_meredith@novell.com From: "Kurt D. Zeilenga" Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"UXayeD.A.huF.DXi85"@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 Mark, Here are some comments... Kurt The abstract says: "MUST NOT be used for feature advertisement or discovery" yet section 3.1 describes exactly this. 4.1 vendorName This attribute contains a single string, which represents the name of the LDAP server implementer. I suggest the specification allow the vendorName to contain any string representing the name of the vendor. In the world of OEM'ed software, the name of the implementor may not be the most appropriate name to place here. 4.2 vendorVersion 4.2 states "This string MUST be unique between two versions". I assume it's up to the vendor to determine what constitutes a version. 5. Notes to Server Implementors I suggest, like HTTP vendor version strings, the I-D state that server implementors may make the vendorName and vendorVersion strings configuration items. The reality is that clients will abuse these values and servers need to support spoofing. 6. Notes to Client Developers It should be noted that an anomalies often on affect subset of implementations reporting the same version information. Most implementations support multiple platforms, have numerous configuration options, and often support plugins. Lastly, I believe Informational would be a more suitable category for this proposal. From list@netscape.com Sun Oct 22 13:35:13 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23071 for ; Sun, 22 Oct 2000 13: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 e9MHM5s22547; Sun, 22 Oct 2000 10:22:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9MHXfw21435; Sun, 22 Oct 2000 10:33:41 -0700 (PDT) Resent-Date: Sun, 22 Oct 2000 10:33:41 -0700 (PDT) Message-Id: <5.0.0.25.0.20001022092800.00a51160@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 22 Oct 2000 10:33:01 -0700 To: robw@worldspot.com From: "Kurt D. Zeilenga" Subject: Comments: draft-weltman-ldapv3-auth-response-02.txt Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ZtDB7D.A.mOF.0Ty85"@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 Rob, It should be noted that the identity assumed by the client may not be represented as an LDAP DN and nor be associated with any entry in the directory (RFC2829). This control only defines a mechanism to return the identity assumed by the client when that identity is in the form of a DN. You may want to allow return of other forms. I suggest the response return the identity in the form of an AuthzId form. As you've noted the authorization identity assumed by the client may later be mapped to an access control (subject) identity and this is the identity to be returned. However, the I-D inconsistently refers to this identity as the authentication identity. As there are often multiple identities (authentication, authorization, access control) associated with a session, it may be appropriate to expand the response to include other identities. I also believe the Security Considerations needs work. The I-D states "No additional confidential information is passed in the control." This is not necessarily true. The fact is that this control passes additional information, a DN, and a DN may contain confidential information. The reader should be minimally referred to RFC 2253 security considerations section. However, as previously noted, a critical consideration for this control is that it is not protected by security layers negotiated by the bind operation. As the primary purpose of providing such information is for verify security relations and/or managing information used to establish security relations, it would likely be quite appropriate to require or recommend the use of other security services (such as TLS). In fact, this consideration may be significant enough to warrant redesign of the mechanism itself. Use of an extended operation may be more appropriate. From list@netscape.com Sun Oct 22 19:22: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 TAA00887 for ; Sun, 22 Oct 2000 19:22: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 e9MNE8D02067; Sun, 22 Oct 2000 16:14:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9MNLDQ24203; Sun, 22 Oct 2000 16:21:13 -0700 (PDT) Resent-Date: Sun, 22 Oct 2000 16:21:13 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Sun, 22 Oct 2000 17:20:43 -0600 From: "Mark Meredith" To: Cc: Subject: Re: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id e9MNLCr24176 Resent-Message-ID: <"9vwLCB.A.25F.oZ385"@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 Kurt, This is now being done on the Informational track. I have been working with Patrk Faltstrom on this. For section 4.1, I understand what you are saying, but I think it is reasonable to have something like OpenLDAP, XYZ Inc. To state that XYZ Inc. did this version of OpenLDAP. This way the application developers would know that OpenLDAP was the base and XYZ was the company that was ultimatly responsible for the possible differences from the OpenLDAP code if any. For section 4.2, It is up to the vendor to determine what and how his versions are done. this is only to state that the version MUST change between releases so version 1.0 and version 1.1, or "OpenLDAP 2.0.6 XYZ Inc. 3.1" For section 5, I understand what you are saying, but I feel, that if these attributes are able to be modified then the clients and applications, are no better off than today in not knowing what server they are talking to. For section 6, I like your addition. I think that most LDAP servers should support plug-ins and that could change the behavior for that extension, or control, etc. I will add that to my copy of the draft. -Mark Mark Meredith Software Engineer Novell Inc 1800 Novell Place, Provo UT 84606 mark_meredith@novell.com 801-861-2645 Novell, Inc., the leading provider of Net service software www.novell.com --------------------- A boat in the harbor is safe, but that is not what boats are for. --John A. Shed --------------------- >>> "Kurt D. Zeilenga" 10/21/00 05:24PM >>> Mark, Here are some comments... Kurt The abstract says: "MUST NOT be used for feature advertisement or discovery" yet section 3.1 describes exactly this. 4.1 vendorName This attribute contains a single string, which represents the name of the LDAP server implementer. I suggest the specification allow the vendorName to contain any string representing the name of the vendor. In the world of OEM'ed software, the name of the implementor may not be the most appropriate name to place here. 4.2 vendorVersion 4.2 states "This string MUST be unique between two versions". I assume it's up to the vendor to determine what constitutes a version. 5. Notes to Server Implementors I suggest, like HTTP vendor version strings, the I-D state that server implementors may make the vendorName and vendorVersion strings configuration items. The reality is that clients will abuse these values and servers need to support spoofing. 6. Notes to Client Developers It should be noted that an anomalies often on affect subset of implementations reporting the same version information. Most implementations support multiple platforms, have numerous configuration options, and often support plugins. Lastly, I believe Informational would be a more suitable category for this proposal. From list@netscape.com Mon Oct 23 12: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 MAA07097 for ; Mon, 23 Oct 2000 12: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 e9NGBgD28875; Mon, 23 Oct 2000 09:11:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NGIm203295; Mon, 23 Oct 2000 09:18:48 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 09:18:48 -0700 (PDT) Message-Id: <5.0.0.25.0.20001023091802.00a93070@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Oct 2000 09:18:10 -0700 To: robw@worldspot.com From: "Kurt D. Zeilenga" Subject: comments: draft-weltman-ldapv3-proxy-05.txt Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"l9YtxB.A.2y.mTG95"@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 Rob, Most (but not all) of this is a repeat of past comments. http://www.OpenLDAP.org/lists/ietf-ldapext/200007/msg00262.html I include all current comments below for completeness: Abstract: "The Proxied Authorization Control allows a connection with sufficient privileges to assume the identity of another entry for the duration of an LDAP request." "duration of an LDAP request" implies the control may affect unrelated operations (in the same session) which are concurrently being processed. "of another entry" assumes that the identity refers to an entry. An authorization identity does have to refer to an entry, let alone be a DN. I suggest: "The Proxied Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of as the current authorization identity associated with the session [RFC2829]." Note that I suggest you add a reference to RFC 2829 as it provides the technical specification of authentication methods in LDAP including the specification of authorization identity forms. 2. Publishing support for the Proxied Authorization Control s/supportedExtensions/supportedControl/ 3. Proxied Authorization Control This control may be included in any search, compare, modify, delete, or modrdn request message as part of the controls field of the LDAPMessage, as defined in [1]. Cannot be used with add? What about extended operations? Obviosiusly it makes not sense to allow use with StartTLS, but there are others which this control would be quite useful. The syntax of controlType should be LDAPOID and have the value of the assigned OID. I suggest you add a statement that servers recognizing this control MUST return an error if the control is not marked as being critical. The controlValue contains the BER encoding of a DN used for evaluating the requested rights: Suggest (needs work): The control value is the BER encoded proxyAuthValue where proxyDN (proxyAuthzId) contains the value representing the authorization identity who's rights are requested. Note that RFC 2829 prescribes an authorization identity form authzId be used with LDAP authentication operations. I suggest it used here as well. 4. Permission to execute as proxy "This means that fewer results, or no results, may be returned" I assume you meant fewer entry and references responses, not results. 5. Security Considerations A more detailed security analysis may be appropriate. In particular of dangers of using this control in environments without appropriate integrity and confidentiality protections The risk of a control being added/modified/removed in transit should be briefly discussed. The I-D states: No additional confidential information is passed in the control. I suggest: This control allows for an additional authorization identity to be passed. In some deployments, these identities may contain confidential information which require privacy protection. From list@netscape.com Mon Oct 23 14:25: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 OAA26794 for ; Mon, 23 Oct 2000 14:25: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 e9NIBMs01241; Mon, 23 Oct 2000 11:11:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NIN1A08383; Mon, 23 Oct 2000 11:23:01 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 11:23:01 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 23 Oct 2000 12:22:46 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_C99109ED.CBAAC7D8" Resent-Message-ID: <"R8OSaD.A.qCC.DII95"@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. --=_C99109ED.CBAAC7D8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable And this is one of my concerns about specifying any kind of multiple = attribute subtype inheritance via attribute type options. I imagine that = X.500 vendors may want to reuse whatever attribute subtyping mechanisms = they already have when implementing support for attribute type options. I = also just don't like stating that an attribute type options is a subtype = and then having a set of (unspecified) exceptions to that statement. It would be preferable if 2251 stated that AttributeDescriptions with one = or more options are *sometimes* treated as subtypes of the attribute type = without any options, and then go on to explain whatever nuances we agree = they have. Jim >>> "David Chadwick" 10/21/00 3:04:00 PM >>> Date forwarded: Sat, 21 Oct 2000 12:11:09 -0700 (PDT) Date sent: Sat, 21 Oct 2000 12:10:31 -0700 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC 2596 questions Copies to: Forwarded by: ietf-ldapext@netscape.com > At 07:58 PM 10/21/00 +0100, David Chadwick wrote: > >I think this is pretty conclusive evidence that multiple superclasses > >are supported (i.e. multiple inheritance)=20 >=20 > Of object classes, yes. > But we're talking about multiple inheritance of attribute types. >=20 >=20 Slight disconnect there !.=20 I agree that multiple inheritance of attribute types is not supported=20 by X.501 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 *************************************************** --=_C99109ED.CBAAC7D8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And this is one of my concerns about specifying any = kind of=20 multiple attribute subtype inheritance via attribute type options. I = imagine=20 that X.500 vendors may want to reuse whatever attribute subtyping = mechanisms=20 they already have when implementing support for attribute type options. I = also=20 just don't like stating that an attribute type options is a subtype and = then=20 having a set of (unspecified) exceptions to that statement.
 
It would be preferable if 2251 stated that AttributeDescriptions with one or more options are *sometimes* = treated as=20 subtypes of the attribute type without any options, and then go on to = explain=20 whatever nuances we agree they have.
 
Jim


>>> "David Chadwick" <d.w.chadwick@salford.ac.uk&g= t;=20 10/21/00 3:04:00 PM >>>
Date forwarded:     = Sat, 21=20 Oct 2000 12:11:09 -0700 (PDT)
Date sent:     = =20     Sat, 21 Oct 2000 12:10:31=20 -0700
To:          &nb= sp; =20    =20 d.w.chadwick@salford.ac.uk
From:      &nbs= p;   =20     "Kurt D. Zeilenga"=20 <Kurt@OpenLDAP.org>
Subject:      &n= bsp;=20     Re: RFC 2596 questions
Copies=20 to:         =20 <ietf-ldapext@netscape.com>
Forwarded by:  =20     ietf-ldapext@netscape.com

> At 07:58 PM = 10/21/00=20 +0100, David Chadwick wrote:
> >I think this is pretty conclusive= =20 evidence that multiple superclasses
> >are supported (i.e. = multiple=20 inheritance)
>
> Of object classes, yes.
> But we're = talking=20 about multiple inheritance of attribute types.
>
>
Slight= =20 disconnect there !.
I agree that multiple inheritance of attribute = types is=20 not supported
by=20 X.501

David


*********************************************= ******

David=20 Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 = 161=20 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email=20 D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac= .uk/its024/chadwick.htm
Understanding=20 X.500  http://www.salford.ac.uk/= its024/X500.htm
X.500/LDAP=20 Seminars http://www.salford.ac= .uk/its024/seminars.htm
Entrust=20 key validation string=20 MLJ9-DU5T-HV8J

***************************************************
--=_C99109ED.CBAAC7D8-- From list@netscape.com Mon Oct 23 14:26:54 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26979 for ; Mon, 23 Oct 2000 14:26: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 e9NII6D27279; Mon, 23 Oct 2000 11:18:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NIPDQ10202; Mon, 23 Oct 2000 11:25:13 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 11:25:13 -0700 (PDT) Message-Id: <5.0.0.25.0.20001023111807.00a6f6c0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Oct 2000 11:24:12 -0700 To: "Steve Sonntag" , From: Bruce Greenblatt Subject: Re: Java LDAP API - LDAPControl class Cc: , , "Alan Clark" , "Steven Merrill" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5030062==_.ALT" Resent-Message-ID: <"iH-vVD.A.MeC.GKI95"@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 --=====================_5030062==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:56 PM 10/18/2000, Steve Sonntag wrote: >I agree, but you still need a way to populate the >date into the LDAPControl class, i.e. still need >the method in LDAPControl. That isn't exactly true. You do not need to have a setValue() method in the LDAPControl class for it to be in the LDAPSortControl class (or any other subclass). But that's just a nitpicky statement about Java. I would suggest that the setValue() method is a protected method of the LDAPControl class. It is not much value to the application developer since the actual value is generally some ASN.1 encoded structure. It would be better to have the setValue() method only callable in the subclass, when it creates a more appropriate interface for application developers. > >-Steve > > >>> Bruce Greenblatt 18-Oct-00 > 4:31:45 PM >>> >I would expect that when the LDAPControl is subclassed for a specific >control that a better SetValue() method would be provided in the >subclass. For example, if the value of the control is essentially a >string, I would hope to see the subclass define a SetValue() method such as: > >public setValue(String value); > >So, in the description of the SetValue() method, I would like to see >language that indicates that implementors of subclasses of "control >specific" LDAPControls SHOULD provide a setValue() method that is specific >to the value of the control being implemented... > >Bruce > >At 03:21 PM 10/18/2000, Steve Sonntag wrote: >>I agree protected is adequate >> >>-Steve >> >> >>> Rob Weltman 18-Oct-00 3:02:09 PM >>> >> Does it need to be public? If it's only for use by extensions (and I >>think that is the case), the method can be protected instead. >> >>Rob >> >>Steve Sonntag wrote: >> >> > The LDAPControl class needs a setValue method. I realize that the >> > value can be set on the constructor, but takethe following >> > example. Suppose I want to build a class in my application that >> > extendscontrol to build my control, for example, server side >> > sort. public class LDAPSortControl extends LDAPControl{ static String >> > oid="1.2.840.113556.1.4.473"; public LDAPSortControl( boolean >> > critical, LDAPSortKey key) { super( oid, critical, >> > (byte[])null); // This line must be first in the constructor >> > // oops, we haven't built the control value yet - how do we pass it in >> > to // the LDAPControl object???? // need a setValue >> > method to get the job done. } Suggested prototype - public setValue( >> > byte[] value); -Steve ------------------------ >> > Steve Sonntag >> > Novell, Inc., the leading provider of Net services software > >============================================== >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 ============================================== 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 --=====================_5030062==_.ALT Content-Type: text/html; charset="us-ascii" At 03:56 PM 10/18/2000, Steve Sonntag wrote:
I agree, but you still need a way to populate the
date into the LDAPControl class, i.e. still need
the method in LDAPControl.

That isn't exactly true.  You do not need to have a setValue() method in the LDAPControl class for it to be in the LDAPSortControl class (or any other subclass).  But that's just a nitpicky statement about Java.  I would suggest that the setValue() method is a protected method of the LDAPControl class.  It is not much value to the application developer since the actual value is generally some ASN.1 encoded structure.  It would be better to have the setValue() method only callable in the subclass, when it creates a more appropriate interface for application developers.

 
-Steve

>>> Bruce Greenblatt <bgreenblatt@directory-applications.com> 18-Oct-00 4:31:45 PM >>>
I would expect that when the LDAPControl is subclassed for a specific control that a better SetValue() method would be provided in the subclass.  For example, if the value of the control is essentially a string, I would hope to see the subclass define a SetValue() method such as:

public setValue(String value);

So, in the description of the SetValue() method, I would like to see language that indicates that implementors of subclasses of "control specific" LDAPControls SHOULD provide a setValue() method that is specific to the value of the control being implemented...

Bruce

At 03:21 PM 10/18/2000, Steve Sonntag wrote:
I agree protected is adequate
 
-Steve

>>> Rob Weltman <robw@worldspot.com> 18-Oct-00 3:02:09 PM >>>
  Does it need to be public? If it's only for use by extensions (and I
think that is the case), the method can be protected instead.

Rob

Steve Sonntag wrote:

>  The LDAPControl class needs a setValue method. I realize that the
> value can be set on the constructor, but takethe following
> example. Suppose I want to build a class in my application that
> extendscontrol to build my control, for example, server side
> sort. public class LDAPSortControl extends LDAPControl{  static String
> oid="1.2.840.113556.1.4.473";  public  LDAPSortControl( boolean
> critical, LDAPSortKey key)  {     super( oid, critical,
> (byte[])null);  // This line must be first in the constructor
> // oops, we haven't built the control value yet - how do we pass it in
> to        // the LDAPControl object????        // need a setValue
> method to get the job done.  } Suggested prototype - public setValue(
> byte[] value); -Steve ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software

==============================================
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

==============================================
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 --=====================_5030062==_.ALT-- From list@netscape.com Mon Oct 23 15:15: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 PAA08911 for ; Mon, 23 Oct 2000 15:15: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 e9NJ20s11571; Mon, 23 Oct 2000 12:02:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NJDe209136; Mon, 23 Oct 2000 12:13:40 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 12:13:40 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 23 Oct 2000 13:13:08 -0600 From: "Steve Sonntag" To: , Cc: , , "Alan Clark" , "Steven Merrill" Subject: Re: Java LDAP API - LDAPControl class Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_E8B028C0.B3D2BF5F" Resent-Message-ID: <"ats5q.A.JOC.g3I95"@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. --=_E8B028C0.B3D2BF5F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Rob's comments to my initial statement suggests that it be a protected = method, and I concur. Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software >>> Bruce Greenblatt 23-Oct-00 = 12:24:12 PM >>> At 03:56 PM 10/18/2000, Steve Sonntag wrote: I agree, but you still need a way to populate the date into the LDAPControl class, i.e. still need the method in LDAPControl. That isn't exactly true. You do not need to have a setValue() method in = the LDAPControl class for it to be in the LDAPSortControl class (or any = other subclass). But that's just a nitpicky statement about Java. I = would suggest that the setValue() method is a protected method of the = LDAPControl class. It is not much value to the application developer = since the actual value is generally some ASN.1 encoded structure. It = would be better to have the setValue() method only callable in the = subclass, when it creates a more appropriate interface for application = developers. -Steve >>> Bruce Greenblatt 18-Oct-00 = 4:31:45 PM >>> I would expect that when the LDAPControl is subclassed for a specific = control that a better SetValue() method would be provided in the subclass. = For example, if the value of the control is essentially a string, I would = hope to see the subclass define a SetValue() method such as: public setValue(String value); So, in the description of the SetValue() method, I would like to see = language that indicates that implementors of subclasses of "control = specific" LDAPControls SHOULD provide a setValue() method that is specific = to the value of the control being implemented... Bruce At 03:21 PM 10/18/2000, Steve Sonntag wrote: I agree protected is adequate =20 -Steve >>> Rob Weltman 18-Oct-00 3:02:09 PM >>> Does it need to be public? If it's only for use by extensions (and I think that is the case), the method can be protected instead. Rob Steve Sonntag wrote: > The LDAPControl class needs a setValue method. I realize that the > value can be set on the constructor, but takethe following > example. Suppose I want to build a class in my application that > extendscontrol to build my control, for example, server side > sort. public class LDAPSortControl extends LDAPControl{ static String > oid=3D"1.2.840.113556.1.4.473"; public LDAPSortControl( boolean > critical, LDAPSortKey key) { super( oid, critical, > (byte[])null); // This line must be first in the constructor > // oops, we haven't built the control value yet - how do we pass it in > to // the LDAPControl object???? // need a setValue > method to get the job done. } Suggested prototype - public setValue( > byte[] value); -Steve ------------------------ > Steve Sonntag > Novell, Inc., the leading provider of Net services software =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 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=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 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=20 --=_E8B028C0.B3D2BF5F Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Rob's comments to my initial statement suggests that = it be a=20 protected method,
and I concur.
 
Steve
 
------------------------
Steve Sonntag
Novell, Inc., the = leading=20 provider of Net services software
 


>>> Bruce Greenblatt=20 <bgreenblatt@directory-applications.com> 23-Oct-00 12:24:12 PM=20 >>>
At 03:56 PM 10/18/2000, Steve Sonntag wrote:
I agree, but = you still=20 need a way to populate the
date into the LDAPControl class, = i.e.=20 still need
the method in LDAPControl.

That isn't = exactly=20 true.  You do not need to have a setValue() method in the LDAPControl = class=20 for it to be in the LDAPSortControl class (or any other subclass).  = But=20 that's just a nitpicky statement about Java.  I would suggest that = the=20 setValue() method is a protected method of the LDAPControl class.  It = is=20 not much value to the application developer since the actual value is = generally=20 some ASN.1 encoded structure.  It would be better to have the = setValue()=20 method only callable in the subclass, when it creates a more appropriate=20= interface for application developers.


-Steve

>>> = Bruce=20 Greenblatt <bgreenblatt@directory-applications.com> 18-Oct-00 = 4:31:45 PM=20 >>>
I would expect that when the LDAPControl is subclassed = for a=20 specific control that a better SetValue() method would be provided in = the=20 subclass.  For example, if the value of the control is essentially = a=20 string, I would hope to see the subclass define a SetValue() method = such=20 as:

public setValue(String value);

So, in the description = of the=20 SetValue() method, I would like to see language that indicates that=20 implementors of subclasses of "control specific" LDAPControls SHOULD = provide a=20 setValue() method that is specific to the value of the control being=20 implemented...

Bruce

At 03:21 PM 10/18/2000, Steve = Sonntag=20 wrote:
I agree = protected is=20 adequate
 
-Steve

>>> Rob Weltman=20 <robw@worldspot.com> 18-Oct-00 3:02:09 PM >>>
  = Does=20 it need to be public? If it's only for use by extensions (and = I
think=20 that is the case), the method can be protected=20 instead.

Rob

Steve Sonntag wrote:

>  = The=20 LDAPControl class needs a setValue method. I realize that the
> = value=20 can be set on the constructor, but takethe following
> = example.=20 Suppose I want to build a class in my application that
>=20 extendscontrol to build my control, for example, server side
> = sort.=20 public class LDAPSortControl extends LDAPControl{  static=20 String
> oid=3D"1.2.840.113556.1.4.473";  public =20 LDAPSortControl( boolean
> critical, LDAPSortKey key) =20 {     super( oid, critical,
> (byte[])null);&= nbsp;=20 // This line must be first in the constructor
> // oops, we = haven't=20 built the control value yet - how do we pass it in
>=20 to        // the LDAPControl=20 object????        // need a=20 setValue
> method to get the job done.  } Suggested = prototype -=20 public setValue(
> byte[] value); -Steve=20 ------------------------
> Steve Sonntag
> Novell, Inc., = the=20 leading provider of Net services=20 software

=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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, = Inc.
http://www.directory-applications.com
See my = new Book=20 on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html= =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
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
<= /A>See my=20 new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html

--=_E8B028C0.B3D2BF5F-- From list@netscape.com Mon Oct 23 16:24: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 SMTP id QAA19475 for ; Mon, 23 Oct 2000 16: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 e9NKBVs22066; Mon, 23 Oct 2000 13:11:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NKN9Y14174; Mon, 23 Oct 2000 13:23:09 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 13:23:09 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 23 Oct 2000 14:22:27 -0600 From: "Steven Merrill" To: "Jim Sermersheim" , "Steve Sonntag" , Cc: Subject: Re: Java LDAP API 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 e9NKN7r14147 Resent-Message-ID: <"_IKrr.A.JdD.r4J95"@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 section "4.3.5 getAttribute" contains definitions for two getAttribute methods. The second definition is written as: public LDAPAttribute[] getAttribute(String attrName, String lang) Returns a single best-match attribute, or none if no match is available in the entry. ========= If the method returns a "single" best-match attribute, why is it returned in LDAPAttribute[] instead of LDAPAttribute? Is it possible to return multiple LDAPAttributes? If so, what example would show that behavior? ========= Shouldn't the description read: Returns a single best-match attribute, or null if no match is available in the entry. ========= The last word "specification" needs to be made plural in the parameter definition of lang: lang A language specification as in [9], with optional subtypes appended using "-" as separator. "lang- en", "lang-en-us", "lang-ja", and "lang-ja-JP- kanji" are valid language specifications. From list@netscape.com Mon Oct 23 16:48: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 QAA22241 for ; Mon, 23 Oct 2000 16:48: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 e9NKdPD26975; Mon, 23 Oct 2000 13:39:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NKkW627059; Mon, 23 Oct 2000 13:46:32 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 13:46:32 -0700 (PDT) Date: Mon, 23 Oct 2000 13:46:25 -0700 (PDT) Message-Id: <200010232046.e9NKkPD06878@ywing.netscape.com> From: bizizgood2@angelfire.com To: @netscape.com Subject: This weeks Feebie!!! X-Reply-To: bizizgood2@angelfire.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dh0HZD.A.emG.nOK95"@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 Everyone. What a beautiful Fall we are having. Hope yours is just as wonderful. And those on the underside I hope your Spring is just as nice. I have another Freebie for all of you. It will only yake a few minutes to get your FREE website set up and start referring your friends. Enjoy! Go to: http://www.freeinternetincome.com/?PT654 Thanks. Peter. From list@netscape.com Mon Oct 23 16:48:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22252 for ; Mon, 23 Oct 2000 16:48:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9NKZ9s26171; Mon, 23 Oct 2000 13:35:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9NKklA27401; Mon, 23 Oct 2000 13:46:47 -0700 (PDT) Resent-Date: Mon, 23 Oct 2000 13:46:47 -0700 (PDT) Message-ID: <39F4A354.C9066651@worldspot.com> Date: Mon, 23 Oct 2000 13:45:09 -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 Merrill CC: Jim Sermersheim , Steve Sonntag , ietf-ldapext@netscape.com Subject: Re: Java LDAP API References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"sMjWNC.A.aqG.yOK95"@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 Merrill wrote: > The section "4.3.5 getAttribute" contains definitions for two getAttribute > methods. The second definition is written as: > > public LDAPAttribute[] getAttribute(String attrName, String lang) > > Returns a single best-match attribute, or none if no match is > available in the entry. > > ========= > If the method returns a "single" best-match attribute, why is it > returned in LDAPAttribute[] instead of LDAPAttribute? > > Is it possible to return multiple LDAPAttributes? If so, what example > would show that behavior? > Typo - it should be public LDAPAttribute getAttribute(String attrName, String lang) > > ========= > Shouldn't the description read: > > Returns a single best-match attribute, or null if no match is > available in the entry. > Yes. > > ========= > The last word "specification" needs to be made plural in the parameter > definition of lang: > > lang A language specification as in [9], with optional > subtypes appended using "-" as separator. "lang- > en", "lang-en-us", "lang-ja", and "lang-ja-JP- > kanji" are valid language specifications. OK Rob From list@netscape.com Tue Oct 24 06:11: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 GAA02203 for ; Tue, 24 Oct 2000 06:11: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 e9OA3HD02934; Tue, 24 Oct 2000 03:03:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9OAANo06642; Tue, 24 Oct 2000 03:10:23 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 03:10:23 -0700 (PDT) Message-Id: <200010241009.GAA01718@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-legg-ldapext-component-matching-00.txt Date: Tue, 24 Oct 2000 06:09:58 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"IkzIH.A.dnB.OAW95"@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. Title : LDAP & X.500 Component Matching Rules Author(s) : S. Legg Filename : draft-legg-ldapext-component-matching-00.txt Pages : 44 Date : 23-Oct-00 The syntaxes of attributes in an LDAP or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. The matching rules defined for the complex syntaxes, if any, usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. Generic string encodings for attribute and assertion values of arbitrary syntax are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-legg-ldapext-component-matching-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-legg-ldapext-component-matching-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001023112254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-legg-ldapext-component-matching-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-legg-ldapext-component-matching-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001023112254.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Oct 24 10:47: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 KAA05474 for ; Tue, 24 Oct 2000 10:47: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 e9OEYTs10088; Tue, 24 Oct 2000 07:34:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9OEkAw07811; Tue, 24 Oct 2000 07:46:10 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 07:46:10 -0700 (PDT) Message-Id: <200010241445.e9OEjRD17131@ywing.netscape.com> From: Subject: Targeted e-mails starting at only $15! Date: Tue, 24 Oct 2000 06:07:33 Resent-Message-ID: <"7HrfcC.A.W5B.wCa95"@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!!******** Visit the site for more details! http://virtue.nu/tel1023 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! --> Highly Deliverable Lists! Our lists are cleaned and updated on a daily basis! Which means we have the lowest undeliverable rate out there! We've also made sure to filter out all those unwanted e-mail address such as .mil, .org, .org, .gov, etc. --> What YOUR Reponse Could Be! If you order the list of 200,000 and achieve a reponse rate of only 1%, you could have over 2,000 reponses to your ad, and that is just in ONE mailing. Note: it usually takes someone an average of 7 times to be exposed to a message before he/she responds to it. Visit the site for more details! http://virtue.nu/tel1023 10,000 opportunity seekers e-mails for only $15 **New List TODAY** 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 - InfoDisk with 1000+ Money Making Reports - URL cloaking software Combined value of over $250! 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, you can be removed at no cost to you simply by pressing "Reply" and place "Remove" in the Subject line. _________________________________________________________________ From list@netscape.com Tue Oct 24 13:44: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 NAA05064 for ; Tue, 24 Oct 2000 13:44: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 e9OHV9s09288; Tue, 24 Oct 2000 10:31:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9OHgng14274; Tue, 24 Oct 2000 10:42:49 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 10:42:49 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 24 Oct 2000 11:41:13 -0600 From: "Steve Sonntag" To: Cc: , "Jim Sermersheim" , "Steven Merrill" , "Scott Zhang" Subject: Java LDAP API - LDAPListener/SearchListener Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_BFE77ED2.11701E3B" Resent-Message-ID: <"x4dr0.A.teD.Xoc95"@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. --=_BFE77ED2.11701E3B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Re: LDAPListener and LDAPSearchListener classes There is some confusion as to what the methods do in these classes. Let me say what I think they do. getMessageIDs - returns the IDs for outstanding requests, i.e. LDAPResponse has not been received for the IDs in the list. The ID is removed from the list even if the=20 application has not read all the messages via getResponse??? It seems to make more sense to say, returns the IDs=20 for outstanding requests (LDAPResponse not received) or for requests which still have messages to be read by getResponse? In this way IDs has more meaning,=20 it is still alive until all messages are read. isResponseReceived - returns true if any response is received and not yet retrieved by getResponse. If getResponse has been used to retrieve all messages received to this point, then isResponse returns false. (i.e. is is somthing on the queue or not). (The way it reads now, it seems to say, "true" if any response received - ever! - even if all of them have been retrieved by getResponse). isComplete - suggested for the next draft isComplete - true if all results have been received, i.e. LDAPResponse has been received for the ID. There may still be messages waiting to be retrieved by getResponse. Am I right in my interpretation? Does the doc need to be clarified? -Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software --=_BFE77ED2.11701E3B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Re: LDAPListener and LDAPSearchListener = classes

There is some confusion as to what the methods
do in these classes.  Let me say what I think they do.
 
getMessageIDs - returns the IDs for outstanding requests,
i.e. LDAPResponse has not been received for the IDs
in the list.  The ID is removed from the list even if the
application has not read all the messages via getResponse???
 
It seems to make more sense to say, returns the IDs
for outstanding requests (LDAPResponse not received)
or for requests which still have messages to be read by
getResponse? In this way IDs has more meaning,
it is still alive until all messages are read.
 
isResponseReceived - returns true if any response is received
and not yet retrieved by getResponse. If getResponse has been
used to retrieve all messages received to this point,=20 then isResponse
returns false. (i.e. is is somthing on the queue or not).
(The way it reads now, it seems to say, "true" if any response = received=20 -
ever! - even if all of them have been retrieved by getResponse).
=
 
isComplete - suggested for the next draft
isComplete - true if all results have been received, i.e.=20 LDAPResponse
has been received for the ID.  There may still be messages=20 waiting
to be retrieved by getResponse.
 
Am I right in my interpretation?  Does the doc need to be=20 clarified?
 
-Steve
 
------------------------
Steve Sonntag
Novell, Inc., the = leading=20 provider of Net services software
 
 
--=_BFE77ED2.11701E3B-- From list@netscape.com Tue Oct 24 21:42:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14581 for ; Tue, 24 Oct 2000 21:42: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 e9P1Tes03433; Tue, 24 Oct 2000 18:29:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9P1fKA03422; Tue, 24 Oct 2000 18:41:20 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 18:41:20 -0700 (PDT) Message-Id: <9F83DF9B4DD5D111999B00A0C96B12B60402A273@stca103a.bus.sc.rolm.com> From: "Skovgaard, Erik" To: "'Kurt D. Zeilenga'" , mark_meredith@novell.com Cc: ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Date: Tue, 24 Oct 2000 18:41:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"nph9eD.A.J1._oj95"@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 All, Did anyone consider using an OID for the value of this attribute. That would remove any potential doubt about which form the vendor's name should have (e.g. Siemens vs Siemens AG). Cheers, ....Erik. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Saturday, October 21, 2000 16:24 To: mark_meredith@novell.com Cc: ietf-ldapext@netscape.com Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Mark, Here are some comments... Kurt The abstract says: "MUST NOT be used for feature advertisement or discovery" yet section 3.1 describes exactly this. 4.1 vendorName This attribute contains a single string, which represents the name of the LDAP server implementer. I suggest the specification allow the vendorName to contain any string representing the name of the vendor. In the world of OEM'ed software, the name of the implementor may not be the most appropriate name to place here. 4.2 vendorVersion 4.2 states "This string MUST be unique between two versions". I assume it's up to the vendor to determine what constitutes a version. 5. Notes to Server Implementors I suggest, like HTTP vendor version strings, the I-D state that server implementors may make the vendorName and vendorVersion strings configuration items. The reality is that clients will abuse these values and servers need to support spoofing. 6. Notes to Client Developers It should be noted that an anomalies often on affect subset of implementations reporting the same version information. Most implementations support multiple platforms, have numerous configuration options, and often support plugins. Lastly, I believe Informational would be a more suitable category for this proposal. From list@netscape.com Tue Oct 24 22:13:44 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 WAA17985 for ; Tue, 24 Oct 2000 22:13: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 e9P20Vs07056; Tue, 24 Oct 2000 19:00:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9P2CB219420; Tue, 24 Oct 2000 19:12:11 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 19:12:11 -0700 (PDT) Date: Tue, 24 Oct 2000 19:12:06 -0700 (PDT) Message-Id: <200010250212.e9P2C6R29035@xwing.netscape.com> From: ualtt@hotbot.com To: awsfl@Netmart.netscape.com Reply-To: ben4u@n2mail.com Subject: "BreakFree" from Government Control/Interference! [srcaq] Resent-Message-ID: <"CDupWB.A.suE.4Fk95"@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 AMERICANS: BreakFree from Government Control/Interference! ====================================================== The GOVERNMENT thinks it OWNS you! It thinks YOU are its PROPERTY! You can BREAK their grip on you, and TAKE CONTROL of yourself and your property (including earnings) -- so they can NEVER confiscate ANY of it, ever again! You can learn how to: * FORCE the IRS to pay any tax liabilities FOR you! * HALT Mortgage Foreclosures! * STOP Credit Card liens! * KILL Lawsuits! * TAKE CONTROL of any trial and force the Judge to give YOU the Order of the Court. * and, much, much more! Take CHARGE and turn EVERYTHING they use to come against you -- AROUND -- and make it work against THEM! Learn how to take control and power over your life (and those who would come in opposition against you) in ways that you've never even dreamed about. To learn more, put "BreakFree" in the Subject. mailto:sam13@n2mail.com?subject=BreakFree Have a Great Day! PS: To be removed from the list, just type "Remove" in the subject and send. From list@netscape.com Wed Oct 25 01:32: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 BAA25662 for ; Wed, 25 Oct 2000 01:32: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 e9P5NbD06704; Tue, 24 Oct 2000 22:23:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9P5Uig10442; Tue, 24 Oct 2000 22:30:44 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 22:30:44 -0700 (PDT) Message-Id: <200010250335.MAA00685@tele02.hidanet.ne.jp> From: "Oscar Wayne" Subject: Your Achievments #7A52 To: list78j@tele02.hidanet.ne.jp X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Tue, 24 Oct 2000 23:32:41 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Resent-Message-ID: <"Gpf16D.A.1iC.DAn95"@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 a free
listing 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

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 Wed Oct 25 02:40: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 CAA25178 for ; Wed, 25 Oct 2000 02:40: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 e9P6VfD11324; Tue, 24 Oct 2000 23:31:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9P6cng28297; Tue, 24 Oct 2000 23:38:49 -0700 (PDT) Resent-Date: Tue, 24 Oct 2000 23:38:49 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 25 Oct 2000 00:37:46 -0600 From: "Ed Reed" To: Cc: , Subject: concensus, I think: controlling visability of subentries 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 e9P6ckr28270 Resent-Message-ID: <"fy_10D.A.05G.3_n95"@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 David - I've heard several others voice the same opinion, and I'm glad to see you endorse the KISS principle, too. My reading of the concensus and arguments is to go with option 1. So be it. Ed >>> "David Chadwick" 10/21/00 02:17PM >>> Date sent: Wed, 18 Oct 2000 21:24:49 -0600 From: "Ed Reed" To: Copies to: , Subject: Re: Fwd: controlling visability of subentries > Okay, Kurt - I've reviewed what X.511 specifies for the service > control used to control subentry visibility. What is your opinion on > what we should do in LDAP? Ed I prefer option 1 for the following reasons i) several of the common arguments are already in LDAP e.g size limit so we dont want to add them again ii) at least one is already a LDAPv3 control e.g. manageDSAIT iii) we have had previous battles over some of the other common arguments (esp dontUseCopy) and there was no concensus to add them so it would not be sensible to add them all in one go. KISS David > > 1) create a control which has no parameters, but has the effect that > when it is present, it is interpreted identically to an X.511 service > control with the subentries bit set TRUE; or > > 2) create a control which has a parameter identical to the service > control specified by X.511. This would have the effect of providing a > lot of the additional controls needed to add distributed operations to > LDAP (including preferChaining, chainingProhibited, etc.), but would > also provide things like timeLimit, sizeLimit, scopeOfReferral, and > attributeSizeLimit, etc. In X.511, the serviceControls are among the > CommonArguments included with each request. > > I suppose we could consider the list of controls in LDAP providing the > equivalent to the set of CommonArguments. > > What's your take? 1 would be easier to document. 2 would lay > important groundwork that should be considered in the context of > future work to add distributed operations to LDAP. > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 08/01/00 07:41AM >>> > Forwarded to LDUP list > >Date: Mon, 31 Jul 2000 16:23:57 -0400 > >To: ietf-ldapext@OpenLDAP.org > >From: "Kurt D. Zeilenga" > >Subject: controlling visability of subentries > > > >One other issue I would like to raise in regards to LDAP subentry is > >the mechanism proposed to control their visibility. I believe the > >approach of overloading the search filter to control visibility is > >not the best approach. As we've found previously, the semantics of > >such overloads are difficult to define (and hence implement) when the > >filter is complex (which we must assume it will be). > > > >I believe that LDAPsubentry visibility should be control by a > >mechanism more closely modeled after the X.500 subentry visibility > >mechanism. In particular, I suggest use of a control. The use of a > >control will allow a clear and concise specification of visibility > >semantics which facilitates implementation and use. > > > >Comments? > > > > 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 *************************************************** ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From list@netscape.com Wed Oct 25 06:18: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 GAA23926 for ; Wed, 25 Oct 2000 06:18: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 e9PA4js11323; Wed, 25 Oct 2000 03:04:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9PAGRs29131; Wed, 25 Oct 2000 03:16:27 -0700 (PDT) Resent-Date: Wed, 25 Oct 2000 03:16:27 -0700 (PDT) Message-Id: <200010251015.GAA23121@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-rharrison-ldap-extpartresp-02.txt Date: Wed, 25 Oct 2000 06:15:50 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"SNtwiB.A.2GH.4Lr95"@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. Title : Extended Partial Response Protocol Enhancement to LDAP v3 Author(s) : R. Harrison Filename : draft-rharrison-ldap-extpartresp-02.txt Pages : 4 Date : 24-Oct-00 This document describes the ExtendedPartialResponse, an element of LDAP v3 protocol which allows multiple responses to LDAP v3 extended requests. Extended partial responses are backward compatible with the existing LDAP v3 Extended Operation defined in [LDAPv3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rharrison-ldap-extpartresp-02.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-rharrison-ldap-extpartresp-02.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-rharrison-ldap-extpartresp-02.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: <20001024110903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rharrison-ldap-extpartresp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-rharrison-ldap-extpartresp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001024110903.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Oct 25 13:01: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 NAA10096 for ; Wed, 25 Oct 2000 13:01: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 e9PGqwD15261; Wed, 25 Oct 2000 09:52:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9PH07s06848; Wed, 25 Oct 2000 10:00:07 -0700 (PDT) Resent-Date: Wed, 25 Oct 2000 10:00:07 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 20 Oct 2000 00:15:41 -0600 From: "Jim Sermersheim" To: Cc: , Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1F47DCBE.E180EE47" Resent-Message-ID: <"R84tJC.A.0oB.SGx95"@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. --=_1F47DCBE.E180EE47 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Getting back to this: The example David gives below shows a subtype inheriting from multiple = supertypes. As of yet, I believe that this is illegal in X.500/LDAP and as = such might cause problems with existing servers. I don't have a good feeling of closure on this subject. We need to revise = 4.1.5 of RFC 2251 to say one of the following: 1) "An AttributeDescription with one or more options is treated as a = direct subtype of the attribute type without any options" (inserted = direct) or 2) "An AttributeDescription with one option is treated as a direct subtype = of the attribute type without any options. An AttributeDescription with = more than one option is treated as a direct subtype of all the possible = AttributeDescriptions that could be made up of all lesser combinations the = options" That description is pretty ugly and could be fixed. It says that cn;a;b;c;d= is in a direct subtype of: cn;a cn;a;b cn;a;c cn;a;d cn;a;b;c cn;a;b;d cn;a;c;d cn;b cn;b;c cn;b;d cn;b;c;d cn;c cn;c;d cn;d This also tells me that attribute subtype inheritance is at most two = levels, but infinitely wide (leaf can multiply inherit from any number of = supertypes) or "An AttributeDescription with one option is treated as a direct subtype of = the attribute type without any options. An AttributeDescription with more = than one option is treated as a direct subtype of all the possible = AttributeDescriptions that could be made up of all combinations the = options sans one option" Using the former example, this produces: cn;a (direct subtype of cn) cn;b (direct subtype of cn) cn;c (direct subtype of cn) cn;d (direct subtype of cn) cn;a;b (direct subtype of cn;a and cn;b) cn;a;c (direct subtype of cn;a and cn;c) cn;a;d (direct subtype of cn;a and cn;d) cn;b;c (direct subtype of cn;b and cn;c) cn;b;d (direct subtype of cn;b and cn;d) cn;c;d (direct subtype of cn;c and cn;d) cn;a;b;c (direct subtype of cn;a;b and cn;a;c and cn;b;c) cn;a;b;d (direct subtype of cn;a;b and cn;a;d and cn;b;d) cn;a;c;d (direct subtype of cn;a;c and cn;a;d and cn;c;d) cn;b;c;d (direct subtype of cn;b;c and cn;b;d and cn;c;d) cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and cn;a;c;d) In the context of language tags, the implications might be benign, but = when combining disparate options some combinations might cause problems. I personally prefer 1). Though it may be less flexible, It's simpler to = understand and fits well with the current subtyping model. Jim >>> "David Chadwick" 9/23/00 5:11:55 AM >>> > 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,=20 Yes, I would say so. The new dual language subtype is a subtype=20 of both single language subtypes. The order does not matter. We=20 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. >=20 > Jim >=20 *************************************************** 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 *************************************************** --=_1F47DCBE.E180EE47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Getting back to this:
 
The example David gives below shows a subtype = inheriting from=20 multiple supertypes. As of yet, I believe that this is illegal in = X.500/LDAP and=20 as such might cause problems with existing servers.
 
I don't have a good feeling of closure on this = subject. We=20 need to revise 4.1.5 of RFC 2251 to say one of the following:
 
1) "An AttributeDescription with one or more options = is=20 treated as a direct subtype of the attribute type without any options" = (inserted=20 direct)
 
or
 
2) "An AttributeDescription with one option is treated = as a=20 direct subtype of the attribute type without any options. An=20 AttributeDescription with more than one option is treated as a direct = subtype of=20 all the possible AttributeDescriptions that could be made up of all = lesser=20 combinations the options"
 
That description is pretty ugly and could be fixed. It = says=20 that cn;a;b;c;d is in a direct subtype of:
cn;a
cn;a;b
cn;a;c
cn;a;d
cn;a;b;c
cn;a;b;d
cn;a;c;d
cn;b
cn;b;c
cn;b;d
cn;b;c;d
cn;c
cn;c;d
cn;d
 
This also tells me that attribute subtype inheritance is at most = two=20 levels, but infinitely wide (leaf can multiply inherit from any number= of=20 supertypes)
 
or
 
"An AttributeDescription with one option is treated as = a=20 direct subtype of the attribute type without any options. An=20 AttributeDescription with more than one option is treated as a direct = subtype of=20 all the possible AttributeDescriptions that could be made up of all = combinations=20 the options sans one option"
 
Using the former example, this produces:
cn;a (direct subtype of cn)
cn;b (direct subtype of cn)
cn;c (direct subtype of cn)
cn;d (direct subtype of cn)
cn;a;b (direct = subtype=20 of cn;a and cn;b)
cn;a;c (direct subtype of cn;a and cn;c)
cn;a;d (direct subtype of cn;a and cn;d)
cn;b;c (direct subtype of cn;b and cn;c)
cn;b;d (direct subtype of cn;b and cn;d)
cn;c;d (direct subtype = of=20 cn;c and cn;d)
cn;a;b;c (direct subtype of cn;a;b and = cn;a;c=20 and cn;b;c)
cn;a;b;d (direct subtype of cn;a;b and cn;a;d = and=20 cn;b;d)
cn;a;c;d (direct subtype of cn;a;c and cn;a;d = and=20 cn;c;d)
cn;b;c;d (direct subtype of cn;b;c and cn;b;d and=20 cn;c;d)
cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and=20 cn;a;c;d)

 
In the context of language tags, the implications might be benign, = but when=20 combining disparate options some combinations might cause problems.
 
I personally prefer 1). Though it may be less flexible, It's simpler = to=20 understand and fits well with the current subtyping model.
 
Jim
 

>>> "David Chadwick" <d.w.chadwick@salford.ac.uk>= =20 9/23/00 5:11:55 AM >>>

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

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

          = ;    =20 supertype
          &n= bsp; =20 /            &n= bsp;    =20 \
subtype=20 1            &n= bsp;      =20 subtype=20 2
           &nbs= p; =20 \            &n= bsp;   =20 /
           &nbs= p; =20 subtype1-2

David

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


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

Davi= d=20 Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 = 161=20 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email=20 D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac= .uk/its024/chadwick.htm
Understanding=20 X.500  http://www.salford.ac.uk/= its024/X500.htm
X.500/LDAP=20 Seminars http://www.salford.ac= .uk/its024/seminars.htm
Entrust=20 key validation string=20 MLJ9-DU5T-HV8J

***************************************************
--=_1F47DCBE.E180EE47-- From list@netscape.com Wed Oct 25 14:10: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 OAA18717 for ; Wed, 25 Oct 2000 14:10: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 e9PI0bD00402; Wed, 25 Oct 2000 11:00:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9PI7kE15222; Wed, 25 Oct 2000 11:07:46 -0700 (PDT) Resent-Date: Wed, 25 Oct 2000 11:07:46 -0700 (PDT) Message-Id: <5.0.0.25.0.20001025104604.00b05b10@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 25 Oct 2000 11:07:07 -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: <"clBi7C.A.htD.xFy95"@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:15 AM 10/20/00 -0600, Jim Sermersheim wrote: >We need to revise 4.1.5 of RFC 2251 to say one of the following: > >1) "An AttributeDescription with one or more options is treated as a direct subtype of the attribute type without any options" (inserted direct) > >or > >2) "An AttributeDescription with one option is treated as a direct subtype of the attribute type without any options. An AttributeDescription with more than one option is treated as a direct subtype of all the possible AttributeDescriptions that could be made up of all lesser combinations the options" Note that neither of these two descriptions imply "cn;lang-x-foo" can be returned with "name;lang-x-foo" is requested. I believe we need to separately describe attribute description "subtyping" (which should be an elective feature like attriute type subtyping). Attribute description subtyping likely depends on a number of factors including attribute type subtyping. Attribute description subtyping will likely rely on multiple inheritance. I concur that RFC 2251 needs to be revised to provide an adequate specification of attribute description subtyping behavior. Kurt From list@netscape.com Wed Oct 25 14:25:32 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20620 for ; Wed, 25 Oct 2000 14:25: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 e9PIGnD03626; Wed, 25 Oct 2000 11:16:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9PINwo27520; Wed, 25 Oct 2000 11:23:58 -0700 (PDT) Resent-Date: Wed, 25 Oct 2000 11:23:58 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 25 Oct 2000 12:23:41 -0600 From: "Jim Sermersheim" To: "Jim Sermersheim" , Cc: , Subject: Re: RFC 2596 questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_A2FA6121.274628A6" Resent-Message-ID: <"vzyTmB.A.rtG.9Uy95"@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. --=_A2FA6121.274628A6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable please ignore that last post. demented mailer. >>> "Jim Sermersheim" 10/20/00 12:15:41 AM >>> Getting back to this: The example David gives below shows a subtype inheriting from multiple = supertypes. As of yet, I believe that this is illegal in X.500/LDAP and as = such might cause problems with existing servers. I don't have a good feeling of closure on this subject. We need to revise = 4.1.5 of RFC 2251 to say one of the following: 1) "An AttributeDescription with one or more options is treated as a = direct subtype of the attribute type without any options" (inserted = direct) or 2) "An AttributeDescription with one option is treated as a direct subtype = of the attribute type without any options. An AttributeDescription with = more than one option is treated as a direct subtype of all the possible = AttributeDescriptions that could be made up of all lesser combinations the = options" That description is pretty ugly and could be fixed. It says that cn;a;b;c;d= is in a direct subtype of: cn;a cn;a;b cn;a;c cn;a;d cn;a;b;c cn;a;b;d cn;a;c;d cn;b cn;b;c cn;b;d cn;b;c;d cn;c cn;c;d cn;d This also tells me that attribute subtype inheritance is at most two = levels, but infinitely wide (leaf can multiply inherit from any number of = supertypes) or "An AttributeDescription with one option is treated as a direct subtype of = the attribute type without any options. An AttributeDescription with more = than one option is treated as a direct subtype of all the possible = AttributeDescriptions that could be made up of all combinations the = options sans one option" Using the former example, this produces: cn;a (direct subtype of cn) cn;b (direct subtype of cn) cn;c (direct subtype of cn) cn;d (direct subtype of cn) cn;a;b (direct subtype of cn;a and cn;b) cn;a;c (direct subtype of cn;a and cn;c) cn;a;d (direct subtype of cn;a and cn;d) cn;b;c (direct subtype of cn;b and cn;c) cn;b;d (direct subtype of cn;b and cn;d) cn;c;d (direct subtype of cn;c and cn;d) cn;a;b;c (direct subtype of cn;a;b and cn;a;c and cn;b;c) cn;a;b;d (direct subtype of cn;a;b and cn;a;d and cn;b;d) cn;a;c;d (direct subtype of cn;a;c and cn;a;d and cn;c;d) cn;b;c;d (direct subtype of cn;b;c and cn;b;d and cn;c;d) cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and cn;a;c;d) =20 In the context of language tags, the implications might be benign, but = when combining disparate options some combinations might cause problems. I personally prefer 1). Though it may be less flexible, It's simpler to = understand and fits well with the current subtyping model. Jim >>> "David Chadwick" 9/23/00 5:11:55 AM >>> > 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,=20 Yes, I would say so. The new dual language subtype is a subtype=20 of both single language subtypes. The order does not matter. We=20 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. >=20 > Jim >=20 *************************************************** 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 *************************************************** --=_A2FA6121.274628A6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable please ignore that last post. demented=20 mailer.

>>> "Jim Sermersheim" <JIMSE@novell.com&g= t;=20 10/20/00 12:15:41 AM >>>
Getting back to this:
 
The example David gives below shows a subtype = inheriting from=20 multiple supertypes. As of yet, I believe that this is illegal in = X.500/LDAP and=20 as such might cause problems with existing servers.
 
I don't have a good feeling of closure on this = subject. We=20 need to revise 4.1.5 of RFC 2251 to say one of the following:
 
1) "An AttributeDescription with one or more options = is=20 treated as a direct subtype of the attribute type without any options" = (inserted=20 direct)
 
or
 
2) "An AttributeDescription with one option is treated = as a=20 direct subtype of the attribute type without any options. An=20 AttributeDescription with more than one option is treated as a direct = subtype of=20 all the possible AttributeDescriptions that could be made up of all = lesser=20 combinations the options"
 
That description is pretty ugly and could be fixed. It = says=20 that cn;a;b;c;d is in a direct subtype of:
cn;a
cn;a;b
cn;a;c
cn;a;d
cn;a;b;c
cn;a;b;d
cn;a;c;d
cn;b
cn;b;c
cn;b;d
cn;b;c;d
cn;c
cn;c;d
cn;d
 
This also tells me that attribute subtype inheritance is at most = two=20 levels, but infinitely wide (leaf can multiply inherit from any number= of=20 supertypes)
 
or
 
"An AttributeDescription with one option is treated as = a=20 direct subtype of the attribute type without any options. An=20 AttributeDescription with more than one option is treated as a direct = subtype of=20 all the possible AttributeDescriptions that could be made up of all = combinations=20 the options sans one option"
 
Using the former example, this produces:
cn;a (direct subtype of cn)
cn;b (direct subtype of cn)
cn;c (direct subtype of cn)
cn;d (direct subtype of cn)
cn;a;b (direct = subtype=20 of cn;a and cn;b)
cn;a;c (direct subtype of cn;a and cn;c)
cn;a;d (direct subtype of cn;a and cn;d)
cn;b;c (direct subtype of cn;b and cn;c)
cn;b;d (direct subtype of cn;b and cn;d)
cn;c;d (direct subtype = of=20 cn;c and cn;d)
cn;a;b;c (direct subtype of cn;a;b and = cn;a;c=20 and cn;b;c)
cn;a;b;d (direct subtype of cn;a;b and cn;a;d = and=20 cn;b;d)
cn;a;c;d (direct subtype of cn;a;c and cn;a;d = and=20 cn;c;d)
cn;b;c;d (direct subtype of cn;b;c and cn;b;d and=20 cn;c;d)
cn;a;b;c;d (direct subtype of cn;a;b;c and cn;a;b;d and=20 cn;a;c;d)

 
In the context of language tags, the implications might be benign, = but when=20 combining disparate options some combinations might cause problems.
 
I personally prefer 1). Though it may be less flexible, It's simpler = to=20 understand and fits well with the current subtyping model.
 
Jim
 

>>> "David Chadwick" <d.w.chadwick@salford.ac.uk>= =20 9/23/00 5:11:55 AM >>>

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

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

          = ;    =20 supertype
          &n= bsp; =20 /            &n= bsp;    =20 \
subtype=20 1            &n= bsp;      =20 subtype=20 2
           &nbs= p; =20 \            &n= bsp;   =20 /
           &nbs= p; =20 subtype1-2

David

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


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

Davi= d=20 Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 = 161=20 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email=20 D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac= .uk/its024/chadwick.htm
Understanding=20 X.500  http://www.salford.ac.uk/= its024/X500.htm
X.500/LDAP=20 Seminars http://www.salford.ac= .uk/its024/seminars.htm
Entrust=20 key validation string=20 MLJ9-DU5T-HV8J

***************************************************
 --=_A2FA6121.274628A6-- From list@netscape.com Thu Oct 26 00:48:31 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14223 for ; Thu, 26 Oct 2000 00:48:30 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9Q4Z2s00629; Wed, 25 Oct 2000 21:35:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9Q4kj215289; Wed, 25 Oct 2000 21:46:45 -0700 (PDT) Resent-Date: Wed, 25 Oct 2000 21:46:45 -0700 (PDT) Message-ID: <39F7B7C3.E2FDFD19@worldspot.com> Date: Wed, 25 Oct 2000 21:49:07 -0700 From: Rob Weltman X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com, Jim Sermersheim , Steven Merrill , Scott Zhang Subject: Re: Java LDAP API - LDAPListener/SearchListener References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GXQ3nB.A.kuD.0c795"@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 getMessageIDs does not remove any messages or IDs, it just returns the list of outstanding message request IDs: the IDs of any requests that have been submitted and for which the responses have not been consumed with getResponse. I think that's different from your first statement but the same as the second one. I agree with the clarifications on isResponseReceived and isComplete. Rob From list@netscape.com Thu Oct 26 02:36: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 CAA02185 for ; Thu, 26 Oct 2000 02:35: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 e9Q6RMD16586; Wed, 25 Oct 2000 23:27:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9Q6YU611112; Wed, 25 Oct 2000 23:34:30 -0700 (PDT) Resent-Date: Wed, 25 Oct 2000 23:34:30 -0700 (PDT) From: officialprespolltaker2@hotmail.com Date: Fri, 15 Sep 00 21:35:17 EST To: officialprespolltaker1@hotmail.com Subject: Here's the Question-"Is Gov. Bush Really Prepared To Be President?" Message-ID: Reply-To: officialprespolltaker2@hotmail.com Comments: Authenticated sender is Resent-Message-ID: <"iCEMND.A.TtC.0B995"@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 Hi, We are an Independent polling company looking to make a difference in This Critical Election by polling internet voters and citizens, then make those results available to the news media and post them on the internet. Your opinions may sway the undecided voters and put the right guy in the White House. The Internet Poll question is, "Is George W. Bush really prepared to be President, or should his past disqualify him?" The results will be posted on the Internet and sent to a number of news agencies 24 to 48 hours before the election and could make the difference in this very tight race. Although we have no way of knowing, we ask that you leave your opinion only once, otherwise this may be seen as votes when posted and may give one candidate an unfair advantage over the other. To give your opinion please call 1-900-226-0388. If response is strong, a question will be asked about V.P. Al Gore and his fitness to be president during the last week of the election. You may suggest a question to be asked when You give Your opinion About Gov. Bush. One will be chosen from Your responses. There is a charge of $1.99 per minute to leave your opinion, a very small price to be heard and to have an opportunity to influence this critical election. ******************************************************** 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 mstrsrvcs@mailme.org with the word remove in the subject line. ********************************************************* 2 From list@netscape.com Thu Oct 26 14:56: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 OAA07141 for ; Thu, 26 Oct 2000 14:56: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 e9QIlaD10217; Thu, 26 Oct 2000 11:47:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9QIslE24449; Thu, 26 Oct 2000 11:54:47 -0700 (PDT) Resent-Date: Thu, 26 Oct 2000 11:54:47 -0700 (PDT) Date: Thu, 26 Oct 2000 19:39:23 +0200 From: "globalincome1@hotmail.com" Subject: Your $49.95 = $620 x 12 x 12 = ??? X-Sender: globalincome1@hotmail.com To: Opportunuty Seeker! Reply-to: breakthebank@themail.com Message-id: <0G3100828SZX28@jhb-imta.mweb.co.za> Organization: Opportunity Seekers Alliance MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quotedGMprintable Resent-Message-ID: <"IGuuS.A.i9F.13H-5"@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: quotedGMprintable Join in the SUCCESS of the most successful company on the Internet. Reserve YOUR position TODAY! for more info:=20 mailto:breakthebank@themail.com?subject=3Dbreakthebank **************************************************** From list@netscape.com Thu Oct 26 15:17: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 PAA09670 for ; Thu, 26 Oct 2000 15:17: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 e9QJ8WD14853; Thu, 26 Oct 2000 12:08:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9QJFg211363; Thu, 26 Oct 2000 12:15:42 -0700 (PDT) Resent-Date: Thu, 26 Oct 2000 12:15:42 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 26 Oct 2000 13:15:26 -0600 From: "Mark Meredith" To: , Cc: Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_F7AF3BDC.A9C8A714" Resent-Message-ID: <"kRdaD.A.rwC.cLI-5"@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. --=_F7AF3BDC.A9C8A714 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable So do you mean that each vendor would have an OID assigned to them or in = the case of OEM they would use the original OID? Can you explain how this would work in more detail? -Mark Mark Meredith Software Engineer Novell Inc 1800 Novell Place, Provo UT 84606 mark_meredith@novell.com 801-861-2645 Novell, Inc., the leading provider of Net service software www.novell.com --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- >>> "Skovgaard, Erik" 10/24/00 07:41PM = >>> All, Did anyone consider using an OID for the value of this attribute. That would remove any potential doubt about which form the vendor's name should have (e.g. Siemens vs Siemens AG). Cheers, ....Erik. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Saturday, October 21, 2000 16:24 To: mark_meredith@novell.com Cc: ietf-ldapext@netscape.com Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Mark, Here are some comments... Kurt The abstract says: "MUST NOT be used for feature advertisement or discovery" yet section 3.1 describes exactly this. =20 4.1 vendorName This attribute contains a single string, which represents the name of the LDAP server implementer. I suggest the specification allow the vendorName to contain any string representing the name of the vendor. In the world of OEM'ed software, the name of the implementor may not be the most appropriate name to place here. 4.2 vendorVersion 4.2 states "This string MUST be unique between two versions". I assume it's up to the vendor to determine what constitutes a version. 5. Notes to Server Implementors I suggest, like HTTP vendor version strings, the I-D state that server implementors may make the vendorName and vendorVersion strings configuration items. The reality is that clients will abuse these values and servers need to support spoofing. 6. Notes to Client Developers It should be noted that an anomalies often on affect subset of implementations reporting the same version information. Most implementations support multiple platforms, have numerous configuration options, and often support plugins. Lastly, I believe Informational would be a more suitable category for this proposal. --=_F7AF3BDC.A9C8A714 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So do you mean that each vendor would have an OID = assigned to=20 them or in the case of OEM they would use the original OID?
 
Can you explain how this would work in more=20 detail?
 
-Mark
 
 
Mark Meredith
Software Engineer
Novell Inc
1800 Novell = Place,=20 Provo UT 84606
mark_meredith@novell.com
80= 1-861-2645
 
Novell, Inc., the leading provider of Net service software
www.novell.com
 
---------------------
A boat in the harbor is safe,
but that = is not=20 what boats are for.
--John A.=20 Shed
---------------------

>>> "Skovgaard, Erik"=20 <Erik.Skovgaard@icn.siemens.com> 10/24/00 07:41PM=20 >>>
All,

Did anyone consider using an OID for the value = of=20 this attribute.  That
would remove any potential doubt about which = form=20 the vendor's name should
have (e.g. Siemens vs Siemens=20 AG).

Cheers,         &n= bsp;      =20 ....Erik.


-----Original Message-----
From: Kurt D. Zeilenga = [mailto:Kurt@OpenLDAP.org]
Sent:= =20 Saturday, October 21, 2000 16:24
To: mark_meredith@novell.com
Cc:=20 ietf-ldapext@netscape.com
Subject: Comments:=20 draft-mmeredith-rootdse-vendor-info-03.txt


Mark,

Here = are some=20 comments...

    Kurt


The abstract says: = "MUST=20 NOT be used for feature advertisement or
discovery" yet section 3.1 = describes=20 exactly this. 

4.1 vendorName
   This = attribute=20 contains a single string, which represents the name
   of the = LDAP=20 server implementer.

I suggest the specification allow the vendorName= to=20 contain any
string representing the name of the vendor.  In the = world=20 of
OEM'ed software, the name of the implementor may not be the
most= =20 appropriate name to place here.

4.2 vendorVersion

4.2 states = "This=20 string MUST be unique between two versions".
I assume it's up to the = vendor=20 to determine what constitutes
a version.

5. Notes to Server=20 Implementors

I suggest, like HTTP vendor version strings, the I-D = state=20 that
server implementors may make the vendorName and vendorVersion
st= rings=20 configuration items.  The reality is that clients will
abuse = these=20 values and servers need to support spoofing.

6. Notes to Client=20 Developers

It should be noted that an anomalies often on affect=20 subset
of implementations reporting the same version information.
Mos= t=20 implementations support multiple platforms, have numerous
configuration= =20 options, and often support plugins.

Lastly, I believe Informational = would=20 be a more suitable category
for this proposal.

--=_F7AF3BDC.A9C8A714-- From list@netscape.com Thu Oct 26 19:30: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 TAA19497 for ; Thu, 26 Oct 2000 19:30: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 e9QNM6D05138; Thu, 26 Oct 2000 16:22:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9QNTHs23889; Thu, 26 Oct 2000 16:29:17 -0700 (PDT) Resent-Date: Thu, 26 Oct 2000 16:29:17 -0700 (PDT) Message-Id: <9F83DF9B4DD5D111999B00A0C96B12B60402A27E@stca103a.bus.sc.rolm.com> From: "Skovgaard, Erik" To: "'Mark Meredith'" , Kurt@openldap.org Cc: ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Date: Thu, 26 Oct 2000 16:28:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Si8XNC.A.40F.L5L-5"@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 Mark, Any vendor that plays in the Directory space should have an OID assigned to them, so that should not be an issue. If a vendor has OEM'd the software and added features, I think the OID should be that of the value-added vendor. If no features have been added, I would think the vendor can choose to use either the original developer's OID or the vendor's own OID. I did consider allowing multiple values for this attribute (e.g. original vendor, value-added1, value-added2), but this may not be palatable by the marketing people. The OID would, IMHO be more specific than a text-based vendor name. Cheers, ....Erik. -----Original Message----- From: Mark Meredith [mailto:MMEREDIT@novell.com] Sent: Thursday, October 26, 2000 12:15 To: Skovgaard, Erik; Kurt@OpenLDAP.org Cc: ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt So do you mean that each vendor would have an OID assigned to them or in the case of OEM they would use the original OID? Can you explain how this would work in more detail? -Mark Mark Meredith Software Engineer Novell Inc 1800 Novell Place, Provo UT 84606 mark_meredith@novell.com 801-861-2645 Novell, Inc., the leading provider of Net service software www.novell.com --------------------- A boat in the harbor is safe, but that is not what boats are for. --John A. Shed --------------------- >>> "Skovgaard, Erik" 10/24/00 07:41PM >>> All, Did anyone consider using an OID for the value of this attribute. That would remove any potential doubt about which form the vendor's name should have (e.g. Siemens vs Siemens AG). Cheers, ....Erik. -----Original Message----- From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org] Sent: Saturday, October 21, 2000 16:24 To: mark_meredith@novell.com Cc: ietf-ldapext@netscape.com Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Mark, Here are some comments... Kurt The abstract says: "MUST NOT be used for feature advertisement or discovery" yet section 3.1 describes exactly this. 4.1 vendorName This attribute contains a single string, which represents the name of the LDAP server implementer. I suggest the specification allow the vendorName to contain any string representing the name of the vendor. In the world of OEM'ed software, the name of the implementor may not be the most appropriate name to place here. 4.2 vendorVersion 4.2 states "This string MUST be unique between two versions". I assume it's up to the vendor to determine what constitutes a version. 5. Notes to Server Implementors I suggest, like HTTP vendor version strings, the I-D state that server implementors may make the vendorName and vendorVersion strings configuration items. The reality is that clients will abuse these values and servers need to support spoofing. 6. Notes to Client Developers It should be noted that an anomalies often on affect subset of implementations reporting the same version information. Most implementations support multiple platforms, have numerous configuration options, and often support plugins. Lastly, I believe Informational would be a more suitable category for this proposal. From list@netscape.com Thu Oct 26 19:47: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 TAA24656 for ; Thu, 26 Oct 2000 19:47: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 e9QNXIs08368; Thu, 26 Oct 2000 16:33:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9QNj3A04045; Thu, 26 Oct 2000 16:45:03 -0700 (PDT) Resent-Date: Thu, 26 Oct 2000 16:45:03 -0700 (PDT) Message-Id: <5.0.0.25.0.20001026164057.00b14510@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 26 Oct 2000 16:44:19 -0700 To: "Skovgaard, Erik" From: "Kurt D. Zeilenga" Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Cc: "'Mark Meredith'" , ietf-ldapext@netscape.com In-Reply-To: <9F83DF9B4DD5D111999B00A0C96B12B60402A27E@stca103a.bus.sc.r olm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"T2SIqD.A.0-.9HM-5"@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 believe a directory string would be more appropriate than an object identifier for display purposes. At 04:28 PM 10/26/00 -0700, Skovgaard, Erik wrote: >Mark, > >Any vendor that plays in the Directory space should have an OID assigned to >them, so that should not be an issue. > >If a vendor has OEM'd the software and added features, I think the OID >should be that of the value-added vendor. If no features have been added, I >would think the vendor can choose to use either the original developer's OID >or the vendor's own OID. I did consider allowing multiple values for this >attribute (e.g. original vendor, value-added1, value-added2), but this may >not be palatable by the marketing people. > >The OID would, IMHO be more specific than a text-based vendor name. > >Cheers, ....Erik. > > >-----Original Message----- >From: Mark Meredith [mailto:MMEREDIT@novell.com] >Sent: Thursday, October 26, 2000 12:15 >To: Skovgaard, Erik; Kurt@OpenLDAP.org >Cc: ietf-ldapext@netscape.com >Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt > > >So do you mean that each vendor would have an OID assigned to them or in the >case of OEM they would use the original OID? > >Can you explain how this would work in more detail? > >-Mark > > >Mark Meredith >Software Engineer >Novell Inc >1800 Novell Place, Provo UT 84606 >mark_meredith@novell.com >801-861-2645 > >Novell, Inc., the leading provider of Net service software >www.novell.com > >--------------------- >A boat in the harbor is safe, >but that is not what boats are for. >--John A. Shed >--------------------- > >>>> "Skovgaard, Erik" 10/24/00 07:41PM >>> >All, > >Did anyone consider using an OID for the value of this attribute. That >would remove any potential doubt about which form the vendor's name should >have (e.g. Siemens vs Siemens AG). > >Cheers, ....Erik. > > >-----Original Message----- >From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org] > >Sent: Saturday, October 21, 2000 16:24 >To: mark_meredith@novell.com >Cc: ietf-ldapext@netscape.com >Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt > > >Mark, > >Here are some comments... > > Kurt > > >The abstract says: "MUST NOT be used for feature advertisement or >discovery" yet section 3.1 describes exactly this. > >4.1 vendorName > This attribute contains a single string, which represents the name > of the LDAP server implementer. > >I suggest the specification allow the vendorName to contain any >string representing the name of the vendor. In the world of >OEM'ed software, the name of the implementor may not be the >most appropriate name to place here. > >4.2 vendorVersion > >4.2 states "This string MUST be unique between two versions". >I assume it's up to the vendor to determine what constitutes >a version. > >5. Notes to Server Implementors > >I suggest, like HTTP vendor version strings, the I-D state that >server implementors may make the vendorName and vendorVersion >strings configuration items. The reality is that clients will >abuse these values and servers need to support spoofing. > >6. Notes to Client Developers > >It should be noted that an anomalies often on affect subset >of implementations reporting the same version information. >Most implementations support multiple platforms, have numerous >configuration options, and often support plugins. > >Lastly, I believe Informational would be a more suitable category >for this proposal. From list@netscape.com Thu Oct 26 20:58:44 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 UAA17534 for ; Thu, 26 Oct 2000 20:58: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 e9R0jQs24778; Thu, 26 Oct 2000 17:45:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9R0vBs14121; Thu, 26 Oct 2000 17:57:11 -0700 (PDT) Resent-Date: Thu, 26 Oct 2000 17:57:11 -0700 (PDT) Message-Id: <9F83DF9B4DD5D111999B00A0C96B12B60402A282@stca103a.bus.sc.rolm.com> From: "Skovgaard, Erik" To: "'Kurt D. Zeilenga'" Cc: "'Mark Meredith'" , ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Date: Thu, 26 Oct 2000 17:56:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Ucyy-.A.UcD.lLN-5"@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 Kurt, Agreed. Perhaps there should also be an attribute for the text form? Or the attribute could be a compound form, for instance: vendorName=2.16.840.1.113999{SuperDirectory Corp.} That would address both the display and the machine use. Cheers, ....Erik. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, October 26, 2000 16:44 To: Skovgaard, Erik Cc: 'Mark Meredith'; ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt I believe a directory string would be more appropriate than an object identifier for display purposes. At 04:28 PM 10/26/00 -0700, Skovgaard, Erik wrote: >Mark, > >Any vendor that plays in the Directory space should have an OID assigned to >them, so that should not be an issue. > >If a vendor has OEM'd the software and added features, I think the OID >should be that of the value-added vendor. If no features have been added, I >would think the vendor can choose to use either the original developer's OID >or the vendor's own OID. I did consider allowing multiple values for this >attribute (e.g. original vendor, value-added1, value-added2), but this may >not be palatable by the marketing people. > >The OID would, IMHO be more specific than a text-based vendor name. > >Cheers, ....Erik. > > >-----Original Message----- >From: Mark Meredith [mailto:MMEREDIT@novell.com] >Sent: Thursday, October 26, 2000 12:15 >To: Skovgaard, Erik; Kurt@OpenLDAP.org >Cc: ietf-ldapext@netscape.com >Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt > > >So do you mean that each vendor would have an OID assigned to them or in the >case of OEM they would use the original OID? > >Can you explain how this would work in more detail? > >-Mark > > >Mark Meredith >Software Engineer >Novell Inc >1800 Novell Place, Provo UT 84606 >mark_meredith@novell.com >801-861-2645 > >Novell, Inc., the leading provider of Net service software >www.novell.com > >--------------------- >A boat in the harbor is safe, >but that is not what boats are for. >--John A. Shed >--------------------- > >>>> "Skovgaard, Erik" 10/24/00 07:41PM >>> >All, > >Did anyone consider using an OID for the value of this attribute. That >would remove any potential doubt about which form the vendor's name should >have (e.g. Siemens vs Siemens AG). > >Cheers, ....Erik. > > >-----Original Message----- >From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org] > >Sent: Saturday, October 21, 2000 16:24 >To: mark_meredith@novell.com >Cc: ietf-ldapext@netscape.com >Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt > > >Mark, > >Here are some comments... > > Kurt > > >The abstract says: "MUST NOT be used for feature advertisement or >discovery" yet section 3.1 describes exactly this. > >4.1 vendorName > This attribute contains a single string, which represents the name > of the LDAP server implementer. > >I suggest the specification allow the vendorName to contain any >string representing the name of the vendor. In the world of >OEM'ed software, the name of the implementor may not be the >most appropriate name to place here. > >4.2 vendorVersion > >4.2 states "This string MUST be unique between two versions". >I assume it's up to the vendor to determine what constitutes >a version. > >5. Notes to Server Implementors > >I suggest, like HTTP vendor version strings, the I-D state that >server implementors may make the vendorName and vendorVersion >strings configuration items. The reality is that clients will >abuse these values and servers need to support spoofing. > >6. Notes to Client Developers > >It should be noted that an anomalies often on affect subset >of implementations reporting the same version information. >Most implementations support multiple platforms, have numerous >configuration options, and often support plugins. > >Lastly, I believe Informational would be a more suitable category >for this proposal. From list@netscape.com Fri Oct 27 08:58: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 IAA13477 for ; Fri, 27 Oct 2000 08:58: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 e9RCnjD22784; Fri, 27 Oct 2000 05:49:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9RCuuU16116; Fri, 27 Oct 2000 05:56:56 -0700 (PDT) Resent-Date: Fri, 27 Oct 2000 05:56:56 -0700 (PDT) Message-Id: <200010271236.IAA29715@roadblock.missi.ncsc.mil> From: "Miklos A. Sue" To: "'Kurt D. Zeilenga'" , "Skovgaard, Erik" Cc: "'Mark Meredith'" , ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt Date: Fri, 27 Oct 2000 08:56:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04015.63C1CCB0" Resent-Message-ID: <"ggW2iC.A.f7D.XuX-5"@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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04015.63C1CCB0 Content-Type: text/plain; charset="iso-8859-1" Is there a global mechanism to avoid string collisions? -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, October 26, 2000 7:44 PM To: Skovgaard, Erik Cc: 'Mark Meredith'; ietf-ldapext@netscape.com Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt I believe a directory string would be more appropriate than an object identifier for display purposes. At 04:28 PM 10/26/00 -0700, Skovgaard, Erik wrote: >Mark, > >Any vendor that plays in the Directory space should have an OID assigned to >them, so that should not be an issue. > >If a vendor has OEM'd the software and added features, I think the OID >should be that of the value-added vendor. If no features have been added, I >would think the vendor can choose to use either the original developer's OID >or the vendor's own OID. I did consider allowing multiple values for this >attribute (e.g. original vendor, value-added1, value-added2), but this may >not be palatable by the marketing people. > >The OID would, IMHO be more specific than a text-based vendor name. > >Cheers, ....Erik. > > >-----Original Message----- >From: Mark Meredith [mailto:MMEREDIT@novell.com] >Sent: Thursday, October 26, 2000 12:15 >To: Skovgaard, Erik; Kurt@OpenLDAP.org >Cc: ietf-ldapext@netscape.com >Subject: RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt > > >So do you mean that each vendor would have an OID assigned to them or in the >case of OEM they would use the original OID? > >Can you explain how this would work in more detail? > >-Mark > > >Mark Meredith >Software Engineer >Novell Inc >1800 Novell Place, Provo UT 84606 >mark_meredith@novell.com >801-861-2645 > >Novell, Inc., the leading provider of Net service software >www.novell.com > >--------------------- >A boat in the harbor is safe, >but that is not what boats are for. >--John A. Shed >--------------------- > >>>> "Skovgaard, Erik" 10/24/00 07:41PM >>> >All, > >Did anyone consider using an OID for the value of this attribute. That >would remove any potential doubt about which form the vendor's name should >have (e.g. Siemens vs Siemens AG). > >Cheers, ....Erik. > > >-----Original Message----- >From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org] > >Sent: Saturday, October 21, 2000 16:24 >To: mark_meredith@novell.com >Cc: ietf-ldapext@netscape.com >Subject: Comments: draft-mmeredith-rootdse-vendor-info-03.txt > > >Mark, > >Here are some comments... > > Kurt > > >The abstract says: "MUST NOT be used for feature advertisement or >discovery" yet section 3.1 describes exactly this. > >4.1 vendorName > This attribute contains a single string, which represents the name > of the LDAP server implementer. > >I suggest the specification allow the vendorName to contain any >string representing the name of the vendor. In the world of >OEM'ed software, the name of the implementor may not be the >most appropriate name to place here. > >4.2 vendorVersion > >4.2 states "This string MUST be unique between two versions". >I assume it's up to the vendor to determine what constitutes >a version. > >5. Notes to Server Implementors > >I suggest, like HTTP vendor version strings, the I-D state that >server implementors may make the vendorName and vendorVersion >strings configuration items. The reality is that clients will >abuse these values and servers need to support spoofing. > >6. Notes to Client Developers > >It should be noted that an anomalies often on affect subset >of implementations reporting the same version information. >Most implementations support multiple platforms, have numerous >configuration options, and often support plugins. > >Lastly, I believe Informational would be a more suitable category >for this proposal. **************************************************************************** * This confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **************************************************************************** ** ------_=_NextPart_001_01C04015.63C1CCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments: draft-mmeredith-rootdse-vendor-info-03.txt

Is there a global mechanism to avoid string = collisions?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, October 26, 2000 7:44 PM
To: Skovgaard, Erik
Cc: 'Mark Meredith'; = ietf-ldapext@netscape.com
Subject: RE: Comments: = draft-mmeredith-rootdse-vendor-info-03.txt


I believe a directory string would be more = appropriate than
an object identifier for display purposes.

At 04:28 PM 10/26/00 -0700, Skovgaard, Erik = wrote:
>Mark,
>
>Any vendor that plays in the Directory space = should have an OID assigned to
>them, so that should not be an issue.
>
>If a vendor has OEM'd the software and added = features, I think the OID
>should be that of the value-added vendor.  = If no features have been added, I
>would think the vendor can choose to use either = the original developer's OID
>or the vendor's own OID.  I did consider = allowing multiple values for this
>attribute (e.g. original vendor, value-added1, = value-added2), but this may
>not be palatable by the marketing people.
>
>The OID would, IMHO be more specific than a = text-based vendor name.
>
>Cheers,        &nbs= p;           &nbs= p;           &nbs= p; ....Erik.
>
>
>-----Original Message-----
>From: Mark Meredith [mailto:MMEREDIT@novell.com]
>Sent: Thursday, October 26, 2000 12:15
>To: Skovgaard, Erik; Kurt@OpenLDAP.org
>Cc: ietf-ldapext@netscape.com
>Subject: RE: Comments: = draft-mmeredith-rootdse-vendor-info-03.txt
>
>
>So do you mean that each vendor would have an = OID assigned to them or in the
>case of OEM they would use the original = OID?
>
>Can you explain how this would work in more = detail?
>
>-Mark
>
>
>Mark Meredith
>Software Engineer
>Novell Inc
>1800 Novell Place, Provo UT 84606
>mark_meredith@novell.com <mailto:mark_meredith@novell.com= >
>801-861-2645
>
>Novell, Inc., the leading provider of Net = service software
>www.novell.com <http://www.novell.com>
>
>---------------------
>A boat in the harbor is safe,
>but that is not what boats are for.
>--John A. Shed
>---------------------
>
>>>> "Skovgaard, Erik" = <Erik.Skovgaard@icn.siemens.com> 10/24/00 07:41PM = >>>
>All,
>
>Did anyone consider using an OID for the value = of this attribute.  That
>would remove any potential doubt about which = form the vendor's name should
>have (e.g. Siemens vs Siemens AG).
>
>Cheers,        &nbs= p;        ....Erik.
>
>
>-----Original Message-----
>From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org]
><mailto:Kurt@OpenLDAP.org]> =
>Sent: Saturday, October 21, 2000 16:24
>To: mark_meredith@novell.com
>Cc: ietf-ldapext@netscape.com
>Subject: Comments: = draft-mmeredith-rootdse-vendor-info-03.txt
>
>
>Mark,
>
>Here are some comments...
>
>    Kurt
>
>
>The abstract says: "MUST NOT be used for = feature advertisement or
>discovery" yet section 3.1 describes = exactly this. 
>
>4.1 vendorName
>   This attribute contains a single = string, which represents the name
>   of the LDAP server = implementer.
>
>I suggest the specification allow the vendorName = to contain any
>string representing the name of the = vendor.  In the world of
>OEM'ed software, the name of the implementor may = not be the
>most appropriate name to place here.
>
>4.2 vendorVersion
>
>4.2 states "This string MUST be unique = between two versions".
>I assume it's up to the vendor to determine what = constitutes
>a version.
>
>5. Notes to Server Implementors
>
>I suggest, like HTTP vendor version strings, the = I-D state that
>server implementors may make the vendorName and = vendorVersion
>strings configuration items.  The reality = is that clients will
>abuse these values and servers need to support = spoofing.
>
>6. Notes to Client Developers
>
>It should be noted that an anomalies often on = affect subset
>of implementations reporting the same version = information.
>Most implementations support multiple platforms, = have numerous
>configuration options, and often support = plugins.
>
>Lastly, I believe Informational would be a more = suitable category
>for this proposal.



***************************************************************= **************
This confirms that this email message has been swept = by
MIMEsweeper for the presence of computer = viruses.
***************************************************************= ***************

------_=_NextPart_001_01C04015.63C1CCB0-- From list@netscape.com Sat Oct 28 00:23: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 AAA14937 for ; Sat, 28 Oct 2000 00:23: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 e9S49ms09297; Fri, 27 Oct 2000 21:09:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9S4KME06552; Fri, 27 Oct 2000 21:20:22 -0700 (PDT) Resent-Date: Fri, 27 Oct 2000 21:20:22 -0700 (PDT) Date: Sat, 28 Oct 2000 06:15:40 GMT From: dontreply@thisaddress.com Message-Id: <200010280615.FAL011.23@SERVER.shtrani.it> MIME-Version: 1.0 Reply-To: dontreply@thisaddress.com To: dontreply@thisaddress.com Subject: BULK E-MAIL WORKS! Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"Ww499.A.rkB.AQl-5"@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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id e9S49ms09297 Content-Transfer-Encoding: quoted-printable BULK E-MAIL WORKS!!!
click here to be removed
BULK E-MAIL WORKS!!!

There is NO better way to reach SO MANY people for SO LITTLE money!!!
We have one goal here: to increase traffic to our clients' web sites!
There is really only one way to achieve this goal cost
 effectively -- e-mail advertising.

MASSIVE EXPOSURE =3D MASSIV= E TRAFFIC =3D $$$ MASSIVE PROFIT!!! $$$

Dollar-for-dollar, nothing = provides a better return on investment
than bulk e-mail and it do= esn=92t matter what product or service you sell.

Introduce new products and sell them right away!
Introduce your new services and sell them right away!
Introduce your new business opportunity and sign people up right away!

Create a surge of hot, qual= ified leads and new customers!

THINK ABOUT IT: Just ONE good letter could bring you tons of hot leads and new
customers, get them to keep buying over and over again, reactivate=
=91lost=92 customers, and even provide you with a constant stream = of referrals.
So anytime you need more business - you simply turn to us for your promotions...
it=92s like having the goose that lays the golden egg.

$$$  Create a massi= ve "cash surge"!  $$$

WHAT WE DO:
We send out the mail for you
We host your web site
We help you write your ad copy
We take the worry and hassle out of bulk e-mail
We keep your web site from being shut down
We keep your ISP from terminating your account


There is a right way and a wrong way to go about bulk e-ma= il promotions. The wrong way includes hijacking e-mail servers, relaying e-m= ail, and refusing to honor remove requests. We don't resort to any of those tactics, and we dislike them every bit as much as anyone. We deliver YOUR e-mail ad using resources we pay for and adhering to all state laws.
In short, we do bul= k e-mail the right way.
Doing bulk email the right way means knowing h= ow to get your e-mails delivered properly and making sure those who don't want to be bothered get removed from the list. When you hire us, you'll get professional services, not empty promises.

Some people may tell you that it doesn't work, (don't listen to them!!!) WE can make BULK E-MAIL the most successful promotion you have EVER done!!!

We believe in your right to free speech, fr= ee enterprise and the right to advertise on the Internet just as any other tree cutting down, environmentally unfriendly, old fashioned paper spam mail, land fill packing business can do.

ARE YOU<= /b>
$$$$  READY FOR SUCCE= SS???!!!  $$$$

YES! I'm ready for success and= I'm ready to order now!

CHOOSE YOUR PROMOTION!
(check a box)

Number of E-mails<= /td> Price
100,000 $250.00 + setup =3D $350.00
250,000 $400.00 + setup =3D $500.00
500,000 $700.00 + setup =3D $800.00
1,000,000 $1,200.00 + setup =3D $1,300.= 00
Note: If you order another e-mail campaign within one week of the end of your previous one, you do not have to pay the setup charge again. 
    FIELDS MARKE=
D WITH * ARE REQUIRED.
    Your Name:*
    Address:*=
    City, State, Zip= :*
    Phone:*
    Fax:
    E-mail Address:*=
    I will be paying= by:* Credit= Card
    Money = Order
    Check
    Credit Card information:
    Visa MasterCard
    Number: 
    Expiration: 
    OR call me for my credit card number.

    Add to Mailing Li= st:
    Yes No

    Your E-mail Text:=

    Comments or Reque= sts:


© 2000 All Rights Reserved.
BizEmail
From list@netscape.com Sun Oct 29 08:11: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 IAA08707 for ; Sun, 29 Oct 2000 08:11:05 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9TD2HD03006; Sun, 29 Oct 2000 05:02:17 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9TD9Uo22966; Sun, 29 Oct 2000 05:09:31 -0800 (PST) Resent-Date: Sun, 29 Oct 2000 05:09:31 -0800 (PST) Subject: RE: RE:Real Estate income opportunity w/o a license Message-Id: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT From: real_estate_center29@excite.com To: real_estate_center28@excite.com Date: Sun, 29 Oct 2000 05:21:21 -0700 Resent-Message-ID: <"Mpy-zD.A.elF.JGC_5"@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 START YOUR OWN REAL ESTATE BUSINESS FOR UNDER $100 Would you like to get off the business opportunity merry-go-round and make some serious money? Are you tired of spending your hard-earned cash for worthless MLM, envelope stuffing and get rich quick moneymaking schemes? "How to sell and control real estate without a license or money" will be the last program you will ever need because it will show you how to make a lot of money from your home, part-time or full-time in a legitimate home-based business it's that simple, you will wonder why you haven't heard of it before. If our can read a newspaper and fill out a simple form, you can be successful in this business. "How to sell and control real estate without a license or money," is the most unique and lucrative real estate business opportunity ever offered. It's very realistic to expect to make $100,000.000 per year part-time from your home using the simple techniques you will learn in this program. "How to sell and control real estate without a license or money," is designed and targeted to attract the person who wants to sell their property fast and at full market price. Your ads will be geared to attract many buyers for the same property. The lenders you will have access to are eager and waiting to lend money to just about anyone that has a job. Now I ask you, how many homes do you think you can sell if you have several buyers for each home, and have a list of lenders that will lend to almost anyone who has a job even though their credit is less than perfect? You will learn the secrets of selling each and every home you have under your control in less than 30 days by tailoring your ads to attract sub-prime home buyers. Did you know that the sub-prime homebuyers market in real estate is 2 1/2 times as big as the regular real estate market? What this all means is that there are thousands of potential home buyers out there that can't qualify for a regular mortgage since they don't meet the rigid credit requirements of local lenders. "How to sell and control real estate without a license or money," shows you how to tap into this market of sub-prime lenders and get these people a mortgage even though they have less than perfect credit. These people will buy all the homes you have for sale!!! This is a much-needed service that will allow you to make thousands of dollars part-time right from your home helping people with less than perfect credit purchase a home. By working with home purchasers in the sub-prime real estate market, you will learn that the homes you control will sell for full price every time. Under normal conditions in the market place qualified A-A+ credit buyers drive the price of homes down by making less than full price offers. Here's what you will learn in "How to sell and control real estate without a license or money," * You will learn how to sell real estate legally without a license anywhere in the country! You will learn how to capture a property at the best price possible with a small investment (usually only $1.00) and resell this property at full market value within 30 days. * You will learn how to make $2,500.00 with only $1.00 investment. Now that is leverage! You will learn the technique of taking a small amount of money and turning it into a large sum of money within 30 days. Its called leverage - this is one of the techniques used by investors to make millions of dollars!!! * You will learn how to control $1,000,000.00 in real estate for only $100.00! Impossible you say - not really when you understand and apply the techniques in "How to sell and control real estate without a license or money," * You will learn how to stay in control of your own deals! By that I mean you will be both buyer and seller. You accept or reject any offer you want to. You are in control. * You will learn to maneuver in real estate, make big money and learn how to control a real estate empire with little or no money! You will learn the techniques of creating a legal paper trail or footprint to protect yourself while being in control of several properties and all the profits generated by their sale. * You will learn insider secrets on how the big investors acquire massive wealth by controlling real estate for pennies on the dollar! Real estate investors know that a low profile financial exposure is the ideal position to be in when controlling a piece of property for profit - yes you will be exposed to this moneymaking technique known and used by big real estate investors. * You will learn how to create ownership rights in real estate without having to make a mortgage payment, pay taxes or insurance payments! This document will put you in the drivers seat and on the fast track to making thousands of dollars in real estate without ever having to qualify and acquire a real estate license in your state. * You will learn the inside secrets about the late night TV infomercial real estate talking heads, and what they tell you about how easy it is to buy real estate with "no money down." It's all bull fertilizer compared to the information that you will be exposed to in this program! Most people seeking "no money down deals," lack money/credit or the expertise to negotiate. That's why most fail in their efforts to procure a piece of property. However, "How to sell and control real estate without a license or money," will show you how to capture a piece of property at a set price; turn around and sell that property, make $2,500.00 to $25,000.00, and have 100's of people calling begging you to sell their homes. * You will learn how to make your phone ring off the hook, and how to sell your properties at full appraised 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! This is the trade secret in this whole program - we show you how to tap into the sub-prime lenders in the country and how to access them. It's as simple as bringing your sub-prime buyer of the home that you control together with a sub-prime lender that lends to people with less than perfect credit. It's just that simple and I guarantee that if you put any effort into implementing this simple to start, easy to run program you will make tons of money! If you order "How to sell and control real estate without a license or money" in the next 10 days, you'll receive as an extra bonus, "How to Live in Your Home for Free," and you will learn how and where to access up to a $120,000.00 home loan at 3% interest without fees or credit check. If our program doesn't work for you...No Problem - Take Advantage of our 60 DAY MONEY BACK GUARANTEE! Call Now! 1.480.990.4463 EXT. 4930 "Have Your Credit Card Ready" For One LOW Payment of - $49.95 (Priority Shipping Included) --------------------------------------------------------- To Unsubscribe: Reply with "UNSUBSCRIBE" in subject line --------------------------------------------------------- From list@netscape.com Mon Oct 30 00:21: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 AAA06509 for ; Mon, 30 Oct 2000 00:21:00 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9U5CAD26669; Sun, 29 Oct 2000 21:12:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9U5JPQ17516; Sun, 29 Oct 2000 21:19:25 -0800 (PST) Resent-Date: Sun, 29 Oct 2000 21:19:25 -0800 (PST) Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" Cc: , Subject: RE: RFC 2596 questions Date: Mon, 30 Oct 2000 16:19:02 +1100 Message-ID: <000a01c04230$ec98e380$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Resent-Message-ID: <"KteUBB.A.XRE.bTQ_5"@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 Jim, > -----Original Message----- > From: Jim Sermersheim [mailto:JIMSE@novell.com] > Sent: Tuesday, 24 October 2000 5:23 > To: Kurt@OpenLDAP.org; d.w.chadwick@salford.ac.uk > Cc: ietf-ldapext@netscape.com > Subject: Re: RFC 2596 questions > > > And this is one of my concerns about specifying any kind of multiple > attribute subtype inheritance via attribute type options. I imagine that > X.500 vendors may want to reuse whatever attribute subtyping mechanisms > they already have when implementing support for attribute type options. It's not so much a desire as a necessity. I use the existing subtyping mechanism to deal with LDAP attribute options because I don't currently have an alternative. As a solution it has its drawbacks. One drawback is the potentially large number of attribute definitions. If there are N attribute types that can have M different options then there must be N x M explicit subtype definitions. I also need to find OIDS for each of these. There is no imperative from the LDAP side of the fence that causes these OIDs to be defined and no imperative for the notional optioned subtypes to be defined as explicit subtypes in a subschema subentry. There are also the problems that the X.500 ATTRIBUTE information object and the AttributeTypeDescription ASN.1 type only allow a single supertype, and some attribute options, like ";binary", are non-sensical as subtypes from the X.500 point of view (because everything there is ";binary"). One solution to align LDAP attribute options with X.500 is for X.500 to revise the attribute descriptions to allow multiple inheritance, and for LDAP to formally require optioned attribute types to be explicitly defined in subschema as subtypes of the unoptioned attribute type. I don't expect the latter to happen. LDAP-only vendors don't get any benefit to make it worthwhile for them to support such a requirement. A second solution is for X.500's attribute type to be extended to carry attribute options. That would require extensive changes but at least LDAP and X.500 would be brought into perfect alignment with regard to attribute options (once we've sorted out exactly how attribute options are supposed to work, of course). The required changes to search filters, etc, to support attribute options in the X.500 protocols would be much like the changes already made to support contexts, so I've recently been revisiting the question of how contexts could be used to represent attribute options in the X.500 protocols and data model. An X.500 context has a type and one or more values. An attribute value can have zero, one or more contexts. The obvious mapping from attribute options to contexts is for each kind of option (e.g. language tags) to be represented by a context type, and each option of that kind (e.g. lang-en, lang-jp) to be represented by a value of the context type. An AttributeValueAssertion may contain one or more context assertions which, if present, must also be satified for a match to return true for a particular value. The context assertions can be written as a conjunction or a disjunction of context types and values. The conjunctions are most useful here. The context assertions also apply to any attribute subtypes. What this all means is that there is a straightforward mapping that gives the apparent LDAP behaviour that a request for name;a;b will match name;a;b, name;a;b;c, sn;a;b, sn;a;b;c, among other things (i.e. name, or any of its attribute subtypes, that has at least the attribute options ;a and ;b). The order of context values is not significant so with the simplest mapping to contexts, sn;a;b is the same as sn;b;a. There is a problem though. An attribute value also matches a context assertion if it does not have any context values of the context type in the assertion. So for example, a request for sn;lang-en can also return attribute values of just sn. The model used seems to be that an attribute value without a context value for a specific context type implicitly has all possible values of that context type. I need it to be treated as though it has none of the possible context values. To get the desired behaviour it would be necessary to add something like a lang-null context value (hidden, as an attribute option, from LDAP clients) to *all* attribute values that don't otherwise have a language context and to translate all requests for the attribute type without options into requests for attribute values with the lang-null context value. Apart from being messy, this workaround requires fore knowledge of all the context types a server is going to receive in requests, and isn't really backward compatible with an X.500 server not supporting attribute options through contexts. A much cleaner solution would be the ability to define a context type where context assertions for that context type evaluate to false for attribute values not having the context type, instead of evaluating to true. This leads me to a proposal for sorting out the LDAP attribute options and their relationship to X.500: (1) In X.500: extend the CONTEXT information object to include a new optional field that specifies whether a context assertion on the context type returns true (current behaviour) or false for values not having the context type. (2) Somewhere (I prefer a new RFC): define a CONTEXT information object for LDAP attribute options using the new field, and describe the mapping from attribute options into this new context type, noting that some options (e.g. ;binary) don't map to context values. (3) In LDAPbis (RFC 2251): describe the attribute options in a way that is consistent with the behaviour resulting from (2), and as something clearly separate from the attribute type hierarchy. (4) In LDAPbis (RFC 2252): change the ABNF to disallow the use of attribute options on attribute types in the NAME and SUP fields of an AttributeTypeDescription, the MUST and MAY fields of an ObjectClassDescription, and the APPLIES field of a MatchingRuleUseDescription. (5) Somewhere (the new RFC): define a schema operational attribute, e.g. called AttributeOptionUse, to capture any capability anyone thinks is lost from doing (4), and/or to add an ability to control how attribute options are used in a subschema administrative area. > I also just don't like stating that an attribute type options is a subtype > and then having a set of (unspecified) exceptions to that statement. > > It would be preferable if 2251 stated that AttributeDescriptions with one > or more options are *sometimes* treated as subtypes of the attribute type > without any options, and then go on to explain whatever nuances we agree > they have. Even better (assuming a mapping to contexts) if the effect of an AttributeDescription is described without using the word "subtype". Regards, Steven > > Jim > > > >>> "David Chadwick" 10/21/00 3:04:00 PM >>> > Date forwarded: Sat, 21 Oct 2000 12:11:09 -0700 (PDT) > Date sent: Sat, 21 Oct 2000 12:10:31 -0700 > To: d.w.chadwick@salford.ac.uk > From: "Kurt D. Zeilenga" > Subject: Re: RFC 2596 questions > Copies to: > Forwarded by: ietf-ldapext@netscape.com > > > At 07:58 PM 10/21/00 +0100, David Chadwick wrote: > > >I think this is pretty conclusive evidence that multiple superclasses > > >are supported (i.e. multiple inheritance) > > > > Of object classes, yes. > > But we're talking about multiple inheritance of attribute types. > > > > > Slight disconnect there !. > I agree that multiple inheritance of attribute types is not supported > by X.501 > > 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 Mon Oct 30 02:43: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 CAA04474 for ; Mon, 30 Oct 2000 02:43:44 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9U7YqD05446; Sun, 29 Oct 2000 23:34:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9U7g6s13562; Sun, 29 Oct 2000 23:42:06 -0800 (PST) Resent-Date: Sun, 29 Oct 2000 23:42:06 -0800 (PST) Message-Id: <200010300735.e9U7ZvR19308@smtp11.singnet.com.sg> X-Sender: Joseph.Mo@prontomail.com From: Webmaster To: "eweb8" Date: Mon, 30 Oct 2000 15:43:15 +0800 Subject: "w "Have_You_Grabbed_This_YET?? MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Resent-Message-ID: <"e5uJiB.A.VTD.MZS_5"@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 e9U7YqD05446 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA04474 Hi, HAVE YOU GRABBED THIS YET? You won’t believe what you get for FREE, but it’s TRUE. Get YOUR OWN centralized online PROFIT MACHINE with TWENTY individual profit centers! And much more, check it out at Request for info! mailto:eewin@email.com?subject=mscinfo! You even get FREE TRAINING to help you learn marketing! WOW! Our exclusive new HYIB program now paying via Cashlink Debit Card! I have one in my wallet now and so could you. Have A Nice Day! ....................................................................... To be removed from this mailing list please send mailto:eewin@email.com?subject=remove me! Sorry for any Inconvience. From list@netscape.com Mon Oct 30 15:55: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 PAA06847 for ; Mon, 30 Oct 2000 15:55:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9UKgCs27100; Mon, 30 Oct 2000 12:42:12 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9UKs2s00782; Mon, 30 Oct 2000 12:54:02 -0800 (PST) Resent-Date: Mon, 30 Oct 2000 12:54:02 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 30 Oct 2000 13:53:29 -0700 From: "Steve Sonntag" To: , Subject: JavaLDAP Draft - change to Extended Operation Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_AEF667DD.91F09AF1" Resent-Message-ID: <"XrKzSC.A.5K.n_d_5"@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. --=_AEF667DD.91F09AF1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Previously we discussed adding setValue to LDAPControl, but a similar method is also needed for LDAPExtendedOperation. protected void setValue(byte[] newVals); Both LDAPExtendedOperation and LDAPControl also need protected void setID(String newoid) Without these methods a child class is required to know the OID and the = BER encoded data at the beginning of its constructor. Most child classes = have to do some manupulation before they have build the BER encoded data = and the OID Should the scope be public or protected? Probably protected is adequate -Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software --=_AEF667DD.91F09AF1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Previously we discussed adding setValue to LDAPControl,
but a similar method is also needed for LDAPExtendedOperation.
 
protected void setValue(byte[] newVals);
 
Both LDAPExtendedOperation and LDAPControl also need
 
protected void setID(String newoid)
 
 
Without these methods a child class is required to = know the=20 OID and the BER encoded data at the beginning of its constructor.  = Most=20 child classes have to do some manupulation before they have build = the BER=20 encoded data and the OID
 
Should the scope be public or protected?
 
Probably protected is adequate
 
-Steve
 
------------------------
Steve Sonntag
Novell, Inc., the = leading=20 provider of Net services software
 
 
--=_AEF667DD.91F09AF1-- From list@netscape.com Mon Oct 30 16:02:22 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 QAA07797 for ; Mon, 30 Oct 2000 16:02:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9UKmws29086; Mon, 30 Oct 2000 12:48:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9UL0mk06067; Mon, 30 Oct 2000 13:00:48 -0800 (PST) Resent-Date: Mon, 30 Oct 2000 13:00:48 -0800 (PST) Message-ID: <39FDE12E.6C37A9C6@worldspot.com> Date: Mon, 30 Oct 2000 12:59:26 -0800 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Sonntag CC: ietf-ldapext@netscape.com Subject: Re: JavaLDAP Draft - change to Extended Operation References: Content-Type: multipart/alternative; boundary="------------65B5100A99FC8EC51983E16F" Resent-Message-ID: <"0rjbAB.A.eeB._Fe_5"@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 --------------65B5100A99FC8EC51983E16F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree with LDAPExtendedOperation.setValue, but I don't see a need for setID, except for on deserialization. The ID is not computed, it is a constant. But we might have to add setID to allow deserialization of an LDAPControl. Does LDAPExtendedOperation need to be serializable? Rob Steve Sonntag wrote: > Previously we discussed adding setValue to LDAPControl,but a similar method is also needed for LDAPExtendedOperation. protected void setValue(byte[] newVals); Both LDAPExtendedOperation and LDAPControl also need protected void setID(String newoid) Without these methods a child class is required to know the OID and the BER encoded data at the beginning of its constructor. Most child classes have to do some manupulation before they have build the BER encoded data and the OID Should the scope be public or protected? Probably protected is adequate > -Steve ------------------------ > Steve Sonntag > Novell, Inc., the leading provider of Net services software --------------65B5100A99FC8EC51983E16F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit   I agree with LDAPExtendedOperation.setValue, but I don't see a need for setID, except for on deserialization. The ID is not computed, it is a constant.

  But we might have to add setID to allow deserialization of an LDAPControl. Does LDAPExtendedOperation need to be serializable?

Rob

Steve Sonntag wrote:

 Previously we discussed adding setValue to LDAPControl,but a similar method is also needed for LDAPExtendedOperation. protected void setValue(byte[] newVals); Both LDAPExtendedOperation and LDAPControl also need protected void setID(String newoid)  Without these methods a child class is required to know the OID and the BER encoded data at the beginning of its constructor.  Most child classes have to do some manupulation before they have build the BER encoded data and the OID Should the scope be public or protected? Probably protected is adequate 
 -Steve ------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software  
--------------65B5100A99FC8EC51983E16F-- From list@netscape.com Mon Oct 30 17:17: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 RAA19990 for ; Mon, 30 Oct 2000 17:17:26 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9UM3is13349; Mon, 30 Oct 2000 14:03:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9UMFZU13274; Mon, 30 Oct 2000 14:15:35 -0800 (PST) Resent-Date: Mon, 30 Oct 2000 14:15:35 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 30 Oct 2000 15:15:10 -0700 From: "Steve Sonntag" To: Cc: Subject: Re: JavaLDAP Draft - change to Extended Operation Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_B9E170E7.E584EEA8" Resent-Message-ID: <"K0mbJ.A.FPD.FMf_5"@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. --=_B9E170E7.E584EEA8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Suppose you have a class that based on the input parameters and must choose from a selection of OIDs to generate an extended operation or control , i.e., the class is of an OID multiplexor. In this case the OIDs constants, but must be chosen and then put into the constuctor of the class. -Steve >>> Rob Weltman 30-Oct-00 1:59:26 PM >>> I agree with LDAPExtendedOperation.setValue, but I don't see a need for = setID, except for on deserialization. The ID is not computed, it is a = constant.=20 But we might have to add setID to allow deserialization of an LDAPControl= . Does LDAPExtendedOperation need to be serializable?=20 Rob=20 Steve Sonntag wrote:=20 Previously we discussed adding setValue to LDAPControl,but a similar = method is also needed for LDAPExtendedOperation. protected void setValue(by= te[] newVals); Both LDAPExtendedOperation and LDAPControl also need = protected void setID(String newoid) Without these methods a child class = is required to know the OID and the BER encoded data at the beginning of = its constructor. Most child classes have to do some manupulation before = they have build the BER encoded data and the OID Should the scope be = public or protected? Probably protected is adequate =20 -Steve ------------------------=20 Steve Sonntag=20 Novell, Inc., the leading provider of Net services software =20 --=_B9E170E7.E584EEA8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Suppose you have a class that based on the input = parameters=20 and
must choose from a selection of OIDs to generate an=20 extended
operation or control , i.e., the class is of an = OID=20 multiplexor.
 
In this case the OIDs constants, but must be chosen and = then
put into the constuctor of the class.
 
-Steve

>>> Rob Weltman <robw@worldspot.com> = 30-Oct-00=20 1:59:26 PM >>>
  I agree with LDAPExtendedOperation.setVal= ue,=20 but I don't see a need for setID, except for on deserialization. The ID is = not=20 computed, it is a constant.

  But we might have to add setID to allow deserialization of an=20 LDAPControl. Does LDAPExtendedOperation need to be serializable?=20

Rob=20

Steve Sonntag wrote:=20

 Previously we discussed adding setValue = to=20 LDAPControl,but a similar method is also needed for=20 LDAPExtendedOperation. protected void setValue(byte[= ]=20 newVals); Both LDAPExtendedOperation and LDAPControl also=20 need protected void setID(String=20 newoid)  Without these methods a child = class is=20 required to know the OID and the BER encoded data at the beginning of = its=20 constructor.  Most child classes have to do some manupulation = before they=20 have build the BER encoded data and the OID Should the scope = be=20 public or protected? Probably protected is adequate =20
 -Steve ------------------------
Steve Sonntag =
Novell,=20 Inc., the leading provider of Net services=20 software  
--=_B9E170E7.E584EEA8-- From list@netscape.com Mon Oct 30 17:20:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21039 for ; Mon, 30 Oct 2000 17:20:53 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9UM7Ts14309; Mon, 30 Oct 2000 14:07:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9UMJKA15400; Mon, 30 Oct 2000 14:19:20 -0800 (PST) Resent-Date: Mon, 30 Oct 2000 14:19:20 -0800 (PST) Message-ID: <39FDF391.187ED693@worldspot.com> Date: Mon, 30 Oct 2000 14:17:53 -0800 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Sonntag CC: robw@worldspot.com, ietf-ldapext@netscape.com Subject: Re: JavaLDAP Draft - change to Extended Operation References: Content-Type: multipart/alternative; boundary="------------DABAAE77069DB961FE652BE5" Resent-Message-ID: <"aQd9NC.A.TwD.nPf_5"@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 --------------DABAAE77069DB961FE652BE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doesn't that confirm that you don't need a set ID method? The OID multiplexor is a factory for controls or extended operations, invoking the right constructor after figuring out what OID to use. Rob Steve Sonntag wrote: > Suppose you have a class that based on the input parameters andmust choose from a selection of OIDs to generate an extendedoperation or control , i.e., the class is of an OID multiplexor. In this case the OIDs constants, but must be chosen and thenput into the constuctor of the class. -Steve > > >>> Rob Weltman 30-Oct-00 1:59:26 PM >>> > I agree with LDAPExtendedOperation.setValue, but I don't see a need for setID, except for on deserialization. The ID is not computed, it is a constant. But we might have to add setID to allow deserialization of an LDAPControl. Does LDAPExtendedOperation need to be serializable? > > Rob > > Steve Sonntag wrote: > >> Previously we discussed adding setValue to LDAPControl,but a similar method is also needed for LDAPExtendedOperation. protected void setValue(byte[] newVals); Both LDAPExtendedOperation and LDAPControl also need protected void setID(String newoid) Without these methods a child class is required to know the OID and the BER encoded data at the beginning of its constructor. Most child classes have to do some manupulation before they have build the BER encoded data and the OID Should the scope be public or protected? Probably protected is adequate >> -Steve ------------------------ >> Steve Sonntag >> Novell, Inc., the leading provider of Net services software > --------------DABAAE77069DB961FE652BE5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit   Doesn't that confirm that you don't need a set ID method? The OID multiplexor is a factory for controls or extended operations, invoking the right constructor after figuring out what OID to use.

Rob
 

Steve Sonntag wrote:

 Suppose you have a class that based on the input parameters andmust choose from a selection of OIDs to generate an extendedoperation or control , i.e., the class is of an OID multiplexor. In this case the OIDs constants, but must be chosen and thenput into the constuctor of the class. -Steve

>>> Rob Weltman <robw@worldspot.com> 30-Oct-00 1:59:26 PM >>>
  I agree with LDAPExtendedOperation.setValue, but I don't see a need for setID, except for on deserialization. The ID is not computed, it is a constant.  But we might have to add setID to allow deserialization of an LDAPControl. Does LDAPExtendedOperation need to be serializable?

Rob

Steve Sonntag wrote:

 Previously we discussed adding setValue to LDAPControl,but a similar method is also needed for LDAPExtendedOperation. protected void setValue(byte[] newVals); Both LDAPExtendedOperation and LDAPControl also need protected void setID(String newoid) Without these methods a child class is required to know the OID and the BER encoded data at the beginning of its constructor.  Most child classes have to do some manupulation before they have build the BER encoded data and the OID Should the scope be public or protected? Probably protected is adequate
 -Steve ------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software
--------------DABAAE77069DB961FE652BE5-- From list@netscape.com Mon Oct 30 17:29: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 RAA23776 for ; Mon, 30 Oct 2000 17:29:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9UML1D08955; Mon, 30 Oct 2000 14:21:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9UMSHA21254; Mon, 30 Oct 2000 14:28:17 -0800 (PST) Resent-Date: Mon, 30 Oct 2000 14:28:17 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 30 Oct 2000 15:27:51 -0700 From: "Steve Sonntag" To: Cc: , "Javed Khan" Subject: Re: JavaLDAP Draft - change to Extended Operation Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_B8E071E1.DABBD192" Resent-Message-ID: <"uBAMR.A.xLF._Xf_5"@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. --=_B8E071E1.DABBD192 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable You're right, don't need setID we ust need setValue -Steve >>> Rob Weltman 30-Oct-00 3:17:53 PM >>> Doesn't that confirm that you don't need a set ID method? The OID = multiplexor is a factory for controls or extended operations, invoking the = right constructor after figuring out what OID to use.=20 Rob=20 =20 Steve Sonntag wrote:=20 Suppose you have a class that based on the input parameters andmust = choose from a selection of OIDs to generate an extendedoperation or = control , i.e., the class is of an OID multiplexor. In this case the OIDs = constants, but must be chosen and thenput into the constuctor of the = class. -Steve=20 >>> Rob Weltman 30-Oct-00 1:59:26 PM >>>=20 I agree with LDAPExtendedOperation.setValue, but I don't see a need for = setID, except for on deserialization. The ID is not computed, it is a = constant. But we might have to add setID to allow deserialization of an = LDAPControl. Does LDAPExtendedOperation need to be serializable?=20 Rob=20 Steve Sonntag wrote:=20 Previously we discussed adding setValue to LDAPControl,but a similar = method is also needed for LDAPExtendedOperation. protected void setValue(by= te[] newVals); Both LDAPExtendedOperation and LDAPControl also need = protected void setID(String newoid) Without these methods a child class is = required to know the OID and the BER encoded data at the beginning of its = constructor. Most child classes have to do some manupulation before they = have build the BER encoded data and the OID Should the scope be public or = protected? Probably protected is adequate=20 -Steve ------------------------=20 Steve Sonntag=20 Novell, Inc., the leading provider of Net services software --=_B8E071E1.DABBD192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You're right,  don't need setID
 
we ust need setValue
 
-Steve

>>> Rob Weltman <robw@worldspot.com> = 30-Oct-00=20 3:17:53 PM >>>
  Doesn't that confirm that you don't need = a set=20 ID method? The OID multiplexor is a factory for controls or extended = operations,=20 invoking the right constructor after figuring out what OID to use.

Rob
 =20

Steve Sonntag wrote:=20

 Suppose you have a class = that=20 based on the input parameters andmust choose from a selection of OIDs = to=20 generate an extendedoperation or control , i.e., the class is of an = OID=20 multiplexor. In this case the OIDs constants, but must be chosen and = thenput=20 into the constuctor of the class. -Steve=20

>>> Rob Weltman <robw@worldspot.com> 30-Oct-00 1:59:26 = PM=20 >>>
  I agree with LDAPExtendedOperation.setValue, but = I=20 don't see a need for setID, except for on deserialization. The ID is = not=20 computed, it is a constant.  But we might have to add setID to = allow=20 deserialization of an LDAPControl. Does LDAPExtendedOperation need to = be=20 serializable?=20

Rob=20

Steve Sonntag wrote:=20

 Previously we discussed adding setValue = to=20 LDAPControl,but a similar method is also needed for LDAPExtendedOperati= on.=20 protected void setValue(byte[] newVals); = Both=20 LDAPExtendedOperation and LDAPControl also need protect= ed void=20 setID(String newoid) Without these methods a = child=20 class is required to know the OID and the BER encoded data at the = beginning=20 of its constructor.  Most child classes have to do some manupulati= on=20 before they have build the BER encoded data and the OID Should = the=20 scope be public or protected? Probably protected is adequate=20
 -Steve ------------------------
Steve Sonntag
Novell,= =20 Inc., the leading provider of Net services=20 software
--=_B8E071E1.DABBD192-- From list@netscape.com Tue Oct 31 01:18: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 BAA05548 for ; Tue, 31 Oct 2000 01:18:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9V66OD14898; Mon, 30 Oct 2000 22:06:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9V6Ddo19446; Mon, 30 Oct 2000 22:13:39 -0800 (PST) Resent-Date: Mon, 30 Oct 2000 22:13:39 -0800 (PST) From: patrick5236@kmail.com.au Subject: Learn How To Create True Wealth From Home Date: Mon, 30 Oct 2000 21:54:57 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_4DC7_00002055.00005179" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <20001031054945812.ACK263.175@default> Resent-Message-ID: <"khf6YB.A.hvE.SMm_5"@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_000_4DC7_00002055.00005179 Content-Type: text/html;

FUTURE PERFECT



DO YOU TELL PEOPLE THAT YOU LOVE YOUR JOB??



DO YOU TELL PEOPLE THAT YOU EARN ALL THE MONEY YOU DESIRE??



DO YOU TELL PEOPLE THAT YOU PAY LITTLE OR NO TAXES??



DO YOU TELL PEOPLE YOU HAVE THE TIME YOU WANT TO SPEND WITH YOUR FAMILY??



I DO

I AM LOOKING FOR A FEW SPECIAL PEOPLE WITH A GOOD WORK ETHIC AND EXTRAORDINARY DESIRE WHO WANT TO CHANGE THEIR LIVES.



YOU DO NOT HAVE TO HAVE PRIOR EXPERIENCE!



YOU DO NOT HAVE TO HAVE ANY SPECIAL EDUCATION!



I'M LOOKING FOR PEOPLE WHO WANT TO EARN AT LEAST $10,000 PER MONTH!



WE WILL GIVE YOU ALL THE TRAINING AND SUPPORT THAT YOU WILL NEED TO ENSURE YOUR SUCCESS!



IF I CAN DO THIS ....SO CAN YOU!!!!!



CALL NOW FOR FREE INFO

24 HOUR TOLL FREE RECORDING!



1-888-248-0843



------=_NextPart_000_4DC7_00002055.00005179-- From list@netscape.com Tue Oct 31 07:14: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 HAA22562 for ; Tue, 31 Oct 2000 07:14:02 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9VBwJs01112; Tue, 31 Oct 2000 03:58:19 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9VCACM13160; Tue, 31 Oct 2000 04:10:12 -0800 (PST) Resent-Date: Tue, 31 Oct 2000 04:10:12 -0800 (PST) From: jimmy_o@angelfire.com Subject: Make money with the BANK'S money. Reply-To: jimmy_o@angelfire.com Date: 31 Oct 2000 07:16:27 -0500 Mime-Version: 1.0 Content-Type: text/html Message-Id: <20001031115142.JIX9978@mailhost.attcanada.net> Resent-Message-ID: <"635pYB.A.LND.iar_5"@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 e9VBwJs01112 Content-Transfer-Encoding: quoted-printable

Remove ins= truction at the bottom

 <= ![endif]>

QUICK CASH SECRET BANKING SYSTEM, THE SECRETS = OF THE RICH & FAMOUS REVEALED AT LAST!!! Make money with the abundance of the bank=92s money<= span style=3D"mso-spacerun: yes">=A0

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

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= ! 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 no= t let the greatest opportunity of your life pass you by because you were so eag= er to jump into conclusions that you did not get all the facts. Please, read on= and try to get the concept of what I can give you here and now, before you fo= rm 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 money order and Postal Money Order must be INTERNATIONAL.=A0 You can also send a cheque (we acc= ept cash) to:

All Moreir <= /span>

970 Queen St. E. #98165

Toronto, Ontario, Canada

M4M 1J0

___________<= /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 $ystem right now, please.=A0 Here is the $49US<= /u>. Postal Money Order must be INTERNATIO= NAL

Write legible please=

________ Check here if = you would like to receive this information by e-mail as an attachment and save the $5.00 shipping and handling fee, which is the faste= st service; if not please add $5US for S&H.

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= MORE THAN ONE MILLION OPT-IN ADDRESSES- FREE!!

Postal= Money Orders MUST be international- - if not, this will not be negotiable outside the USA and wi= ll be returned.

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 is not jus= t money. Wealth is also the ability to spend it the way you choose to do, w= hen 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" wea= lthy person; I want you to have great amounts of money, and great amounts of f= ree 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 most 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 Tue Oct 31 18:59: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 SAA18544 for ; Tue, 31 Oct 2000 18:59:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9VNnpD03480; Tue, 31 Oct 2000 15:49:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id e9VNLJ217249; Tue, 31 Oct 2000 15:21:19 -0800 (PST) Resent-Date: Tue, 31 Oct 2000 15:21:19 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 31 Oct 2000 16:20:31 -0700 From: "Jim Sermersheim" To: Cc: Subject: Relationship between dupent and matched values Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2E76E5D3.68096222" Resent-Message-ID: <"tu9ZPB.A.vME.tP1_5"@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. --=_2E76E5D3.68096222 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'm wrapping up the final edits for a new version of the duplicate entries = draft and I was going to add a comment about the usefulness of pairing it = with the matched values draft. I'm hesitating now, only because I'd like = to see this draft get to RFC status soon and so I don't want to reference = a draft that isn't scheduled to be immediately advanced. Does anyone have strong feelings about this? We could put the note in the = matched values draft. Jim --=_2E76E5D3.68096222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm wrapping up the final edits for a new version of the = duplicate=20 entries draft and I was going to add a comment about the usefulness of = pairing=20 it with the matched values draft. I'm hesitating now, only because I'd = like to=20 see this draft get to RFC status soon and so I don't want to reference a = draft=20 that isn't scheduled to be immediately advanced.
 
Does anyone have strong feelings about this? We could put the note = in the=20 matched values draft.
 
Jim
 --=_2E76E5D3.68096222-- From list@netscape.com Tue Oct 31 19:10:28 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20948 for ; Tue, 31 Oct 2000 19:10:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id e9VNtss26176; Tue, 31 Oct 2000 15:55:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id eA107m620535; Tue, 31 Oct 2000 16:07:48 -0800 (PST) Resent-Date: Tue, 31 Oct 2000 16:07:48 -0800 (PST) Message-Id: <5.0.0.25.0.20001031160517.00a663b0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 31 Oct 2000 16:06:59 -0800 To: "Jim Sermersheim" , From: Bruce Greenblatt Subject: Re: Relationship between dupent and matched values Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17903523==_.ALT" Resent-Message-ID: <"Z3Ps-D.A.iAF.T71_5"@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 --=====================_17903523==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:20 PM 10/31/2000, Jim Sermersheim wrote: >>I'm wrapping up the final edits for a new version of the duplicate >>entries draft and I was going to add a comment about the usefulness of >>pairing it with the matched values draft. I'm hesitating now, only >>because I'd like to see this draft get to RFC status soon and so I don't >>want to reference a draft that isn't scheduled to be immediately advanced. >> >>Does anyone have strong feelings about this? We could put the note in the >>matched values draft. >> >>Jim IMHO, the two drafts have nothing to do with each other. Duplicate entries deals with entries as a whole. Matched values (vainly) attempts to solve an attribute-value level problem. Definitely do NOT tie one to the other! 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 --=====================_17903523==_.ALT Content-Type: text/html; charset="us-ascii" At 03:20 PM 10/31/2000, Jim Sermersheim wrote:
I'm wrapping up the final edits for a new version of the duplicate entries draft and I was going to add a comment about the usefulness of pairing it with the matched values draft. I'm hesitating now, only because I'd like to see this draft get to RFC status soon and so I don't want to reference a draft that isn't scheduled to be immediately advanced.
 
Does anyone have strong feelings about this? We could put the note in the matched values draft.
 
Jim

IMHO, the two drafts have nothing to do with each other.  Duplicate entries deals with entries as a whole.  Matched values (vainly) attempts to solve an attribute-value level problem.  Definitely do NOT tie one to the other!

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 --=====================_17903523==_.ALT-- From list@netscape.com Tue Oct 31 19:44: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 TAA28378 for ; Tue, 31 Oct 2000 19:44:23 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id eA10Urs12685; Tue, 31 Oct 2000 16:30:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id eA10cOc13879; Tue, 31 Oct 2000 16:38:24 -0800 (PST) Resent-Date: Tue, 31 Oct 2000 16:38:24 -0800 (PST) Message-Id: <5.0.0.25.0.20001031161001.0275c840@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 31 Oct 2000 16:37:36 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Relationship between dupent and matched values Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"647YUB.A.VXD.3X2_5"@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 04:20 PM 10/31/00 -0700, Jim Sermersheim wrote: >>I'm wrapping up the final edits for a new version of the duplicate entries draft and I was going to add a comment about the usefulness of pairing it with the matched values draft. I'm hesitating now, only because I'd like to see this draft get to RFC status soon and so I don't want to reference a draft that isn't scheduled to be immediately advanced. >> >>Does anyone have strong feelings about this? We could put the note in the matched values draft. You could make the comment in a manner which doesn't require a normative reference to the matched values I-D [see note in RFC 2026, 2.2]. If it doesn't matter which I-D the note is added to, placing it the one to progress later seems reasonable. But do note that the first one progressed to the AD is not necessarily the first one approved by the IESG. Kurt From list@netscape.com Tue Oct 31 20:30: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 UAA09080 for ; Tue, 31 Oct 2000 20:30:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id eA11LUD01927; Tue, 31 Oct 2000 17:21:30 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id eA114pY02217; Tue, 31 Oct 2000 17:04:51 -0800 (PST) Resent-Date: Tue, 31 Oct 2000 17:04:51 -0800 (PST) Date: Tue, 31 Oct 2000 17:04:35 -0800 (PST) Message-Id: <200011010104.eA114ZR12626@xwing.netscape.com> From: uowpb@hotbot.com To: ziavm@smartclients.netscape.com Reply-To: sam19a2me2@n2mail.com Subject: Could You Use an Extra $30,000 for the Holidays This Year? [mlimz] Resent-Message-ID: <"RJdXjB.A.ce.ow2_5"@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 Sell Incredible Cash Flow ! MAKE $30,000 IN THE NEXT 40 TO 60 DAYS! Sell our Idea to 3 People... Who Sell 3 People... IT'S REAL, IT'S LEGIT AND WE'LL SHOW YOU HOW TO PLUG INTO OUR SYSTEM. DO IT ALL WITH NO MONEY OUT OF YOUR POCKET... ZERO DOWN! Your THREE people follow you through our revolutionary Wealth Generating System Making More Money Faster and Easier than you ever dreamed possible! To start your incredible chain reaction through our program, all you have to do is just find 3 people who want to make lots of money, NOT buy lots of products! When your 3 ENTER our Program you've already earned your first $1,000 AND it’s just the beginning! Next you're on your way to $5500 check from the SAME three people...and it's all AUTOMATIC, now! AND...IT'S STILL JUST THE BEGINNING! NOW, you are MOVING! Your LIFE IS REALLY CHANGING, NOW! Your three people are now making you checks of $5000 and $10,000 AND THERE'S STILL SO MUCH MORE! I could go ON AND ON...it's SO exciting! But, just to keep it simple, let me put it this way... EACH AND EVERY SALE IS WORTH AN AVERAGE OF $14,000 TO YOU! AND...EVERYONE LOVES YOUR PRODUCT... PROFIT! Get the whole scoop! and be IN THE GREEN for the HOLIDAYS THIS YEAR! For more info, reply with "More Cash Flow Info" as the subject. mailto:sam19a2me@n2mail.com?subject=More_Cash_Flow_Info Have a Great Day! Deb