From list@netscape.com Sat Jan 1 13:50:34 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27805 for ; Sat, 1 Jan 2000 13:50:33 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA29652; Sat, 1 Jan 2000 10:46:37 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA15503; Sat, 1 Jan 2000 10:48:40 -0800 (PST) Resent-Date: Sat, 1 Jan 2000 10:48:40 -0800 (PST) Message-ID: <386E4C03.62BD056A@oblix.com> Date: Sat, 01 Jan 2000 10:48:35 -0800 From: Jeff Hodges Reply-To: JHodges@oblix.com Organization: Oblix Inc. (http://www.oblix.com/) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF LDAP Extensions WG Subject: Re: Authz/Authc state upon start TLS References: <3835FB2B.1BE204A3@boolean.net> <384D7EDF.CA7F05AD@oblix.com> <3.0.5.32.19991213082008.00941850@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Pr3RzB.A.9xD.Fwkb4"@glacier> 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've updated/enhanced/repaired the "LDAP Association State Diagram". The new version is v2.0b 1999-12-14 and is available here.. http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.html or.. http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.gif or.. http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.ps The intent is to diagram all of the possible states and state transitions of an LDAP association *security context*, and thus is a compendium of information gleaned from.. [1] Lightweight Directory Access Protocol (v3):Extension for Transport Layer Security. http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-ldapv3-tls-05.txt [2] Authentication Methods for LDAP. http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-authmeth-04.txt [3] Lightweight Directory Access Protocol (v3). http://www.faqs.org/rfcs/rfc2251.html ..where the security context is defined to consist of the LDAP association's notion of authentication and authorization identities, plus any present TLS (aka "session") layer's authentication identity. "Kurt D. Zeilenga" wrote: > > First, a general comment. This diagram scares the hell out of me. > I am quite concerned that we've added an unmanagable amount of > complexity to the authentication process. I agree it's complex. I don't agree it's "unmanageable". For example, there is at least one implementation presently available on the market that implements much if not all of the security context states and state transitions defined in the three above documents. And several others presently shipping that come very close if one is willing to view TLS/SSL-on-separate-port-(for now) as functionally equivalent to StartTLS-on-single-port. In fact, the purpose of the AuthMeth draft [2] is explicitly to provide guidance to implementers and deployers on what (a) what aspects of the overall security picture to implement, and (b) what mechanisms make sense to use in what given scenarios. > I can not even imagine > what affect introduction of IPSEC will have on this complexity. From the LDAP-cum-TLS/SSL perspective, IPSEC is a separate layer underneath. The only interaction envisioned at this time might be if an implementor enables the SASL EXTERNAL mechanism to assert an IPSEC-layer authentication identity as the source for an LDAP association's authorization identity. This is in fact noted in state 4 of the diagram. > Second, per AuthMeth: > 2->8 is inappropriate as 2 has no TLS identity, 2->5? Good catch. Fixed. > Third, per RFC2251, bind failures should cause connection to be > treated as "anonymous" > 4-EXTERNAL should return to 1 > 5-EXTERNAL should return to 2 > 7-NO should return to 3 > 11-NO should return to 3 I disagree. Perhaps you didn't read the explanation & rationale about this in my msg in this thread dated "Tue, 07 Dec 1999 13:40:47 -0800"? > One additional comment on 1->StartTLS->3. > > A StartTLS that asserts a TLS client identity should not automatically > imply or assert an LDAP authentication identity as shown in state 3. > State 3 should be no AuthID, no AuthzID as no bind has occurred. I > believe that any mapping of SASL client identity to the LDAP > authentication identity should be done upon SASL External bind. This was an admitted bug in StartTLSStateDiagram-8-May-1998.html, and is fixed in LDAPAssociationStateDiagram-1999-12-12.html & LDAPAssociationStateDiagram-1999-12-14.html. thanks, JeffH From list@netscape.com Sat Jan 1 15:55:06 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28252 for ; Sat, 1 Jan 2000 15:55:05 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA06268; Sat, 1 Jan 2000 12:52:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA05669; Sat, 1 Jan 2000 12:53:21 -0800 (PST) Resent-Date: Sat, 1 Jan 2000 12:53:21 -0800 (PST) Message-Id: <3.0.5.32.20000101125319.00998310@localhost> X-Sender: guru@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 01 Jan 2000 12:53:19 -0800 To: JHodges@oblix.com From: "Kurt D. Zeilenga" Subject: Re: Authz/Authc state upon start TLS Cc: IETF LDAP Extensions WG In-Reply-To: <386E4C03.62BD056A@oblix.com> References: <3835FB2B.1BE204A3@boolean.net> <384D7EDF.CA7F05AD@oblix.com> <3.0.5.32.19991213082008.00941850@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"c-Bng.A.RYB.Almb4"@glacier> 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:48 AM 1/1/00 -0800, Jeff Hodges wrote: >> Third, per RFC2251, bind failures should cause connection to be >> treated as "anonymous" >I disagree. Perhaps you didn't read the explanation & rationale about this in my msg in >this thread dated "Tue, 07 Dec 1999 13:40:47 -0800"? I did read it and just reread it. I still don't see an overriding reason for treating bind failures when TLS is established any differently than any other bind failure. Maybe you can elaborate on: "ldapv3-tls-05 is more correct from thinking about how security works" I believe SASL/EXTERNAL should be just like any other SASL mechanism. The SASL bind either passes or it fails, and if it fails the LDAP connection should be treated as "anonymous". I do believe it unwise to special case any bind failure in this regard. My rational is that the security specifications need to be simple such as to reduce the likelyhood that they are flawed or that their implementations (or deployments of implementations) are flawed. ---- Kurt D. Zeilenga Net Boolean Incorporated From list@netscape.com Sat Jan 1 19:54:10 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29391 for ; Sat, 1 Jan 2000 19:54:10 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA14349; Sat, 1 Jan 2000 16:51:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA07733; Sat, 1 Jan 2000 16:52:52 -0800 (PST) Resent-Date: Sat, 1 Jan 2000 16:52:52 -0800 (PST) Date: Sat, 01 Jan 2000 18:51:44 -0600 From: Mark Wahl Subject: FYI LDIF now in IETF-wide last call Sender: Mark.Wahl@INNOSOFT.COM To: ietf-ldapext@netscape.com Message-id: <7416.946774304@threadgill.austin.innosoft.com> Resent-Message-ID: <"U5RXeC.A.h4B.jFqb4"@glacier> 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: The IESG SUBJECT: Last Call: The LDAP Data Interchange Format (LDIF) - Technical Specification to Proposed Standard Date: Wed, 22 Dec 1999 11:00:30 -0500 The IESG has received a request to consider The LDAP Data Interchange Format (LDIF) - Technical Specification as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 12, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-good-ldap-ldif-05.txt Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Mon Jan 3 16:58:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08120 for ; Mon, 3 Jan 2000 16:58:37 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA04538; Mon, 3 Jan 2000 13:56:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA20354; Mon, 3 Jan 2000 13:57:06 -0800 (PST) Resent-Date: Mon, 3 Jan 2000 13:57:06 -0800 (PST) Date: Mon, 03 Jan 2000 14:53:04 -0700 From: Linda Grimaldi Subject: Newbie question To: ietf-ldapext@netscape.com Message-id: <001801bf5634$ee8a6a80$fcc6fea9@csp06121.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Mailer: Microsoft Outlook Express 4.72.3612.1700 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_97ei8rvKbErlEEdJ81uAvA)" X-Priority: 3 X-MSMail-priority: Normal Resent-Message-ID: <"KnWmY.A.q9E.wsRc4"@glacier> 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. --Boundary_(ID_97ei8rvKbErlEEdJ81uAvA) Content-type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies for the elementary nature of this question. If there is a = more appropriate mailing list to send it to, please let me know. Anyhow, I have been looking at the policy drafts from the IETF = (, for example) and I have been = doing some LDAP-related work for a couple of months. LDAP, near as I = can tell, has no transactional model. Relationships in network = management and policy management/deployment can get a little hairy. I = was wondering if the need for transactional support in LDAP is felt, or = if an architectural decision has been made that any transactional = enforcement is up to the application via a TP monitor or similar = product? Or if I am totally off base and there is some transactional = support mechanism in LDAP of which I am ignorant (wouldn't be the first = time.) Thanks, Linda Grimaldi linda.grimaldi@wcom.com --Boundary_(ID_97ei8rvKbErlEEdJ81uAvA) Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apologies for the elementary nature = of this=20 question.  If there is a more appropriate mailing list to send it = to,=20 please let me know.
 
Anyhow, I have been looking at the = policy drafts=20 from the IETF (<draft-ietf-policy-framework-00.txt>, for example) = and I=20 have been doing some LDAP-related work for a couple of months.  = LDAP, near=20 as I can tell, has no transactional model.  Relationships in = network=20 management and policy management/deployment can get a little = hairy.  I was=20 wondering if the need for transactional support in LDAP is felt, or if = an=20 architectural decision has been made that any transactional enforcement = is up to=20 the application via a TP monitor or similar product?  Or if I am = totally=20 off base and there is some transactional support mechanism in LDAP of = which I am=20 ignorant (wouldn't be the first time.)
 
Thanks,
Linda Grimaldi
linda.grimaldi@wcom.com
 
--Boundary_(ID_97ei8rvKbErlEEdJ81uAvA)-- From list@netscape.com Tue Jan 4 10:10:55 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29692 for ; Tue, 4 Jan 2000 10:10:52 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA16924; Tue, 4 Jan 2000 07:08:30 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA23669; Tue, 4 Jan 2000 07:09:33 -0800 (PST) Resent-Date: Tue, 4 Jan 2000 07:09:33 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Message-Id: To: thislist$@$domain.netscape.com Subject: Corporate Special! From: vacation@doitnow.8m.com Date: Tue, 04 Jan 2000 07:40:43 -0700 Resent-Message-ID: <"aOS6.A.jxF.s0gc4"@glacier> 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 01/03/00 Jim Sander Director of On-Line Travel Programs Orlando Magical Vacation, Inc. Re: A Spectacular Disney/Orlando Magical Vacation!! 5 days / 4 nights in a luxury 1200 sf condo at Summerfield Condo Resort. This discounted corporate vacation is NOW only $299.00 per person or $598.88 per family, plus tax. Travel up to six people per package. Kids Stay Free!! CALL NOW...1 800 230 7135 Ext.54 Make your travel arrangements anytime over the next 12 months! Register TODAY and Receive Complimentary: 2 Adult 4 Day Disney Park Hopper Passes 2 Adult Casino Cruise Passes Continental Breakfast Daily Shuttle Service to Disney Also receive your choice of a 3 day / 2 night Getaway Bonus with Over 50 locations to choose from!! Maui, Hawaii! Cancun, Mexico!! Las Vegas, Nevada!!! This promotional price includes EVERYTHING!!! Don't forget to ask your Agent about the Discounted Rental Car with UNLIMITED Mileage. CALL NOW!!! 1 800 230 7135 Ext.54 "Have your credit card ready" Hours of operation are 9 AM to 9 PM, Mon - Fri. 10AM-2PM, Sat (eastern) We anticipate a large volume of calls so If signal's busy, keep trying. If you wish not to receive further messages, please forward mail with "delete" in the subject line. Thanks... From list@netscape.com Tue Jan 4 18:54:59 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09865 for ; Tue, 4 Jan 2000 18:54:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA03430; Tue, 4 Jan 2000 15:52:30 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA18196; Tue, 4 Jan 2000 15:53:33 -0800 (PST) Resent-Date: Tue, 4 Jan 2000 15:53:33 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BEC8F@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Linda Grimaldi'" , ietf-ldapext@netscape.com Subject: RE: Newbie question Date: Tue, 4 Jan 2000 15:53:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF570E.E55DDEDA" Resent-Message-ID: <"tBRyhD.A.ybE.8foc4"@glacier> 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_01BF570E.E55DDEDA Content-Type: text/plain; charset="iso-8859-1" There is no transactional support in LDAP today. And the kind you are looking for conflicts with the desire for high availability. A TP monitor using LDAP as its store would not improve matters -- it wouldn't function as expected, and at past it would give high consistency at the expense of availability. -----Original Message----- From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com] Sent: Monday, January 03, 2000 1:53 PM To: ietf-ldapext@netscape.com Subject: Newbie question Apologies for the elementary nature of this question. If there is a more appropriate mailing list to send it to, please let me know. Anyhow, I have been looking at the policy drafts from the IETF (, for example) and I have been doing some LDAP-related work for a couple of months. LDAP, near as I can tell, has no transactional model. Relationships in network management and policy management/deployment can get a little hairy. I was wondering if the need for transactional support in LDAP is felt, or if an architectural decision has been made that any transactional enforcement is up to the application via a TP monitor or similar product? Or if I am totally off base and there is some transactional support mechanism in LDAP of which I am ignorant (wouldn't be the first time.) Thanks, Linda Grimaldi linda.grimaldi@wcom.com ------_=_NextPart_001_01BF570E.E55DDEDA Content-Type: text/html; charset="iso-8859-1"
There is no transactional support in LDAP today. And the kind you are looking for conflicts with the desire for high availability. A TP monitor using LDAP as its store would not improve matters -- it wouldn't function as expected, and at past it would give high consistency at the expense of availability.
-----Original Message-----
From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com]
Sent: Monday, January 03, 2000 1:53 PM
To: ietf-ldapext@netscape.com
Subject: Newbie question

Apologies for the elementary nature of this question.  If there is a more appropriate mailing list to send it to, please let me know.
 
Anyhow, I have been looking at the policy drafts from the IETF (<draft-ietf-policy-framework-00.txt>, for example) and I have been doing some LDAP-related work for a couple of months.  LDAP, near as I can tell, has no transactional model.  Relationships in network management and policy management/deployment can get a little hairy.  I was wondering if the need for transactional support in LDAP is felt, or if an architectural decision has been made that any transactional enforcement is up to the application via a TP monitor or similar product?  Or if I am totally off base and there is some transactional support mechanism in LDAP of which I am ignorant (wouldn't be the first time.)
 
Thanks,
Linda Grimaldi
 
------_=_NextPart_001_01BF570E.E55DDEDA-- From list@netscape.com Tue Jan 4 18:59:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09901 for ; Tue, 4 Jan 2000 18:59:32 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA16712; Tue, 4 Jan 2000 15:55:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA21001; Tue, 4 Jan 2000 15:58:19 -0800 (PST) Resent-Date: Tue, 4 Jan 2000 15:58:19 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BEC90@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Linda Grimaldi'" , "'ietf-ldapext@netscape.com'" Subject: RE: Newbie question Date: Tue, 4 Jan 2000 15:57:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF570F.89E020DA" Resent-Message-ID: <"gLdvIC.A.XHF.akoc4"@glacier> 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_01BF570F.89E020DA Content-Type: text/plain; charset="iso-8859-1" Here's a citation on the inevitability of this conflict: Coan, B., Oki, B., and Kolodner, E., "Limitations on Database Availability When Networks Partition, " Proc. 5th Symp. on Principles of Distributed Computing, Calgary, 1986, pp. 187-194. (BTW to others on this list -- this is the one I promised many moons ago -- I just found a search engine that makes this easy: www.csindex.com ) -----Original Message----- From: Paul Leach Sent: Tuesday, January 04, 2000 3:53 PM To: 'Linda Grimaldi'; ietf-ldapext@netscape.com Subject: RE: Newbie question There is no transactional support in LDAP today. And the kind you are looking for conflicts with the desire for high availability. A TP monitor using LDAP as its store would not improve matters -- it wouldn't function as expected, and at past it would give high consistency at the expense of availability. -----Original Message----- From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com] Sent: Monday, January 03, 2000 1:53 PM To: ietf-ldapext@netscape.com Subject: Newbie question Apologies for the elementary nature of this question. If there is a more appropriate mailing list to send it to, please let me know. Anyhow, I have been looking at the policy drafts from the IETF (, for example) and I have been doing some LDAP-related work for a couple of months. LDAP, near as I can tell, has no transactional model. Relationships in network management and policy management/deployment can get a little hairy. I was wondering if the need for transactional support in LDAP is felt, or if an architectural decision has been made that any transactional enforcement is up to the application via a TP monitor or similar product? Or if I am totally off base and there is some transactional support mechanism in LDAP of which I am ignorant (wouldn't be the first time.) Thanks, Linda Grimaldi linda.grimaldi@wcom.com ------_=_NextPart_001_01BF570F.89E020DA Content-Type: text/html; charset="iso-8859-1"
Here's a citation on the inevitability of this conflict:
Coan, B., Oki, B., and Kolodner, E., "Limitations on Database Availability When Networks Partition, " Proc. 5th Symp. on Principles of Distributed Computing, Calgary, 1986, pp. 187-194.
 
(BTW to others on this list -- this is the one I promised many moons ago -- I just found a search engine that makes this easy: www.csindex.com)
-----Original Message-----
From: Paul Leach
Sent: Tuesday, January 04, 2000 3:53 PM
To: 'Linda Grimaldi'; ietf-ldapext@netscape.com
Subject: RE: Newbie question

There is no transactional support in LDAP today. And the kind you are looking for conflicts with the desire for high availability. A TP monitor using LDAP as its store would not improve matters -- it wouldn't function as expected, and at past it would give high consistency at the expense of availability.
-----Original Message-----
From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com]
Sent: Monday, January 03, 2000 1:53 PM
To: ietf-ldapext@netscape.com
Subject: Newbie question

Apologies for the elementary nature of this question.  If there is a more appropriate mailing list to send it to, please let me know.
 
Anyhow, I have been looking at the policy drafts from the IETF (<draft-ietf-policy-framework-00.txt>, for example) and I have been doing some LDAP-related work for a couple of months.  LDAP, near as I can tell, has no transactional model.  Relationships in network management and policy management/deployment can get a little hairy.  I was wondering if the need for transactional support in LDAP is felt, or if an architectural decision has been made that any transactional enforcement is up to the application via a TP monitor or similar product?  Or if I am totally off base and there is some transactional support mechanism in LDAP of which I am ignorant (wouldn't be the first time.)
 
Thanks,
Linda Grimaldi
 
------_=_NextPart_001_01BF570F.89E020DA-- From list@netscape.com Wed Jan 5 06:53: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 ESMTP id GAA01696 for ; Wed, 5 Jan 2000 06:53:15 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA03135; Wed, 5 Jan 2000 03:49:55 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA14181; Wed, 5 Jan 2000 03:52:16 -0800 (PST) Resent-Date: Wed, 5 Jan 2000 03:52:16 -0800 (PST) Message-Id: <200001051152.GAA01639@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-java-api-09.txt Date: Wed, 05 Jan 2000 06:52:15 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"3-czZ.A.TdD.vBzc4"@glacier> 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 : The Java LDAP Application Program Interface Author(s) : R. Weltman, C. Tomlinson, M. Smith, T. Howes Filename : draft-ietf-ldapext-ldap-java-api-09.txt Pages : 94 Date : 04-Jan-00 This document defines a java language application program interface to the lightweight directory access protocol (LDAP), in the form of a class library. It complements but does not replace RFC 1823 ([7]), which describes a C language application program interface. It updates and the previous draft in correcting a few minor errors which are listed in appendix B. The companion document draft-ietf-ldapext-ldap-java-api-asynch [10] defines the mandatory to implement asynchronous layer of the API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-09.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-java-api-09.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-java-api-09.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: <20000104103153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-java-api-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-java-api-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000104103153.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Jan 5 06:53:24 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01706 for ; Wed, 5 Jan 2000 06:53:24 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA24286; Wed, 5 Jan 2000 03:51:17 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA14295; Wed, 5 Jan 2000 03:52:22 -0800 (PST) Resent-Date: Wed, 5 Jan 2000 03:52:22 -0800 (PST) Message-Id: <200001051152.GAA01655@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-java-api-asynch-ext-04.txt Date: Wed, 05 Jan 2000 06:52:20 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"s8AkV.A.weD.0Bzc4"@glacier> 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 : The Java LDAP Application Program Interface Asynchronous Extension Author(s) : R. Weltman, C. Tomlinson, M. Kekic Filename : draft-ietf-ldapext-ldap-java-api-asynch-ext-04.txt Pages : 22 Date : 04-Jan-00 This document defines asynchronous extensions to the java language application program interface to the lightweight directory access protocol (LDAP) defined in [JAVALDAP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-asynch-ext-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-java-api-asynch-ext-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-java-api-asynch-ext-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: <20000104103205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-java-api-asynch-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-java-api-asynch-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000104103205.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Jan 5 09:06:45 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05164 for ; Wed, 5 Jan 2000 09:06:44 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA10283; Wed, 5 Jan 2000 06:03:25 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA07708; Wed, 5 Jan 2000 06:05:47 -0800 (PST) Resent-Date: Wed, 5 Jan 2000 06:05:47 -0800 (PST) From: opportunities45@eastmail.com Date: Wed, 5 Jan 2000 05:24:33 Message-Id: <374.418399.343608@mail45.rastameeew.com> Resent-Message-ID: <"1tnvND.A.K4B.6-0c4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com JOIN ME AT THE TOP My name is Robert Todd The Golden Era Of Internet Marketing Has Arrived! Will You Be Part Of It? How Can You? Having the potential to reach millions with relatively little investment, the Internet provides opportunities for mass marketing that have never been seen before! You can now compete on the same level as the Big Boys. Your presence on the World Wide Web can be as great as the biggest of the big corporations -- IF YOU HAVE THE TOOLS - and - IF YOU KNOW HOW TO USE THEM! You now have before you the Opportunity to get in on the Ground Floor of a BRAND NEW Network Marketing Opportunity? Have you ever wished you could have started out in the beginning with Nu-Skin, Amway or any of the other networking Giants? Our plan is to bring massive signups into our program. The support and tools we provide are unequaled . These tools have been used by networkers to build enormous downlines in short periods of time. (One Networker built a downline of 80,000 in 12 months while working a full time job, using our tools). And I promise you will not find a more qualified nor will you find a more supportive upline anywhere in the world. What we are offering is a business with the following * FREE State of the art webpage * FREE On hands Training. * FREE Tremendous Upline Support! * FREE Step-By-Step Business Building Plan! * FREE Opportunity Business Conferences Daily! * FREE take advantage of our unlimited lead generating system. Also Everyone Who Joins Us can have * Merchant account - 99% approval * Web Hosting * Flat Rate Long Distance Telephone Service for only $39.99 per month. * You can add unlimited calling card for additional $59.99 Monthly. This service is 24 hours X 7 days a week only in the lower 48 states When you decide to take advantage of this Opportunity, you will: * HAVE the Potential to Earn an unlimited Income! * HAVE a Golden Opportunity to Secure Your Financial Future! * AND finally earn the Money most Networkers only Dream about * Be Mentored by networking Leaders from Nu-Skin, Amway, Excel, Etc. * Unlimited access to all our leaders. * $5,500 Bonus commission on 6 sales! No limit on $5,500 Bonuses. Be a part of the fastest growing market in the world! About the Internet: The Internet has grown from 2 million users in 1993 to over 70 million users today Experts project that there will be 500 million users by the year 2000 The number of new users on the "Net" doubles every 8 months Every cable, long distance company and "Baby Bell" will insure that all Americans have easy access to the Internet including TV set access through "Web TV" providers We Provide a complete "Marketplace on the Internet" for home and business consumers -This is a precious commodity. Busy consumers are looking for faster, more hassle free ways to do their shopping- According to The Kiplinger Letter, May 9, 1997, the number of firms currently using the Internet to buy or sell is growing 10% per month... doubling every seven months! Make sure you DO NOT miss this new and exciting opportunity that is taking the Internet by storm! WE ALREADY HAVE MLM LEADERS JOINING OUR COMPANY DAILY. SECURE YOUR POSITION NOW FOR A MOST REASONABLE JOINING FEE! If interested please fill in info below and I'll get back to you ASAP. Send to kahuna-info2@online-venture.com Name: Email address: Telephone: Best time to call: Sincerely yours, Robert Todd ~~~~~~~~~~~~~~~~~~~~ Robert Todd ICQ#1769450 PO Box 3077 Oneco, FL 34205 USA cyber-kahuna@webtv.net http://www.freeyellow.com/members/irongate/index.htm Toll Free VoiceMail 877-817-6020 FAX 310-495-0415 From list@netscape.com Wed Jan 5 09:46:07 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06111 for ; Wed, 5 Jan 2000 09:46:01 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA05980; Wed, 5 Jan 2000 06:44:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA17347; Wed, 5 Jan 2000 06:45:06 -0800 (PST) Resent-Date: Wed, 5 Jan 2000 06:45:06 -0800 (PST) From: opportunities45@eastmail.com Date: Fri, 7 Jan 2000 01:52:34 Message-Id: <202.866638.610886@mail.mia.spjiioj.com> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Resent-Message-ID: <"nXCB4B.A.iOE.xj1c4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com JOIN ME AT THE TOP My name is Robert Todd The Golden Era Of Internet Marketing Has Arrived! Will You Be Part Of It? How Can You? Having the potential to reach millions with relatively little investment, the Internet provides opportunities for mass marketing that have never been seen before! You can now compete on the same level as the Big Boys. Your presence on the World Wide Web can be as great as the biggest of the big corporations -- IF YOU HAVE THE TOOLS - and - IF YOU KNOW HOW TO USE THEM! You now have before you the Opportunity to get in on the Ground Floor of a BRAND NEW Network Marketing Opportunity? Have you ever wished you could have started out in the beginning with Nu-Skin, Amway or any of the other networking Giants? Our plan is to bring massive signups into our program. The support and tools we provide are unequaled . These tools have been used by networkers to build enormous downlines in short periods of time. (One Networker built a downline of 80,000 in 12 months while working a full time job, using our tools). And I promise you will not find a more qualified nor will you find a more supportive upline anywhere in the world. What we are offering is a business with the following * FREE State of the art webpage * FREE On hands Training. * FREE Tremendous Upline Support! * FREE Step-By-Step Business Building Plan! * FREE Opportunity Business Conferences Daily! * FREE take advantage of our unlimited lead generating system. Also Everyone Who Joins Us can have * Merchant account - 99% approval * Web Hosting * Flat Rate Long Distance Telephone Service for only $39.99 per month. * You can add unlimited calling card for additional $59.99 Monthly. This service is 24 hours X 7 days a week only in the lower 48 states When you decide to take advantage of this Opportunity, you will: * HAVE the Potential to Earn an unlimited Income! * HAVE a Golden Opportunity to Secure Your Financial Future! * AND finally earn the Money most Networkers only Dream about * Be Mentored by networking Leaders from Nu-Skin, Amway, Excel, Etc. * Unlimited access to all our leaders. * $5,500 Bonus commission on 6 sales! No limit on $5,500 Bonuses. Be a part of the fastest growing market in the world! About the Internet: The Internet has grown from 2 million users in 1993 to over 70 million users today Experts project that there will be 500 million users by the year 2000 The number of new users on the "Net" doubles every 8 months Every cable, long distance company and "Baby Bell" will insure that all Americans have easy access to the Internet including TV set access through "Web TV" providers We Provide a complete "Marketplace on the Internet" for home and business consumers -This is a precious commodity. Busy consumers are looking for faster, more hassle free ways to do their shopping- According to The Kiplinger Letter, May 9, 1997, the number of firms currently using the Internet to buy or sell is growing 10% per month... doubling every seven months! Make sure you DO NOT miss this new and exciting opportunity that is taking the Internet by storm! WE ALREADY HAVE MLM LEADERS JOINING OUR COMPANY DAILY. SECURE YOUR POSITION NOW FOR A MOST REASONABLE JOINING FEE! If interested please fill in info below and I'll get back to you ASAP. Send to kahuna-info2@online-venture.com Name: Email address: Telephone: Best time to call: Sincerely yours, Robert Todd ~~~~~~~~~~~~~~~~~~~~ Robert Todd ICQ#1769450 PO Box 3077 Oneco, FL 34205 USA cyber-kahuna@webtv.net http://www.freeyellow.com/members/irongate/index.htm Toll Free VoiceMail 877-817-6020 FAX 310-495-0415 From list@netscape.com Thu Jan 6 14:53:10 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21065 for ; Thu, 6 Jan 2000 14:53:03 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA05270; Thu, 6 Jan 2000 11:49:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA01895; Thu, 6 Jan 2000 11:50:26 -0800 (PST) Resent-Date: Thu, 6 Jan 2000 11:50:26 -0800 (PST) Message-ID: <4992824A0863D211964B0008C7B1ACB803F9AF63@fifi.platinum.corp.microsoft.com> From: Michael Armijo To: "'internet-drafts@ietf.org'" Cc: "'ietf-ldapext@netscape.com'" Subject: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Thu, 6 Jan 2000 11:46:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF587E.B868B37A" Resent-Message-ID: <"A_TlfD.A.Id.AIPd4"@glacier> 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_01BF587E.B868B37A Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF587E.B868B37A" ------_=_NextPart_001_01BF587E.B868B37A Content-Type: text/plain; charset="iso-8859-1" Internet-Drafts Editor: Please replace draft-ietf-ldapext-locate-00.txt with the updated version draft-ietf-ldapext-locate-01.txt. LDAPEXT DL Members: I have updated the Locate document. It now includes a reference to RFC 2052, per WG request. A sentence has been added referring to 'Assigned Numbers' for the use of 'ldap' in the SRV record. Note that "ldap" is the symbolic name for the LDAP service in Assigned Numbers [7], as required by the SRV Protocol[6]. There were a few other minor editorial changes. I would like to submit this version for WG last call. WG chairs, please advise. thanks, Michael <> ------_=_NextPart_001_01BF587E.B868B37A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services = with DNS

Internet-Drafts Editor:
Please replace = draft-ietf-ldapext-locate-00.txt with the updated version = draft-ietf-ldapext-locate-01.txt.

LDAPEXT DL Members:
I have updated the Locate = document.

It now includes a reference to RFC = 2052, per WG request.

A sentence has been added referring to = 'Assigned Numbers' for the use of 'ldap' in the SRV record.

        Note that "ldap" is the symbolic name for the = LDAP service in
        Assigned Numbers [7], as required by the SRV = Protocol[6].

There were a few other minor editorial = changes.
I would like to submit this version = for WG last call.  WG chairs, please advise.

thanks,
Michael


= <<draft-ietf-ldapext-locate-01.txt>>

------_=_NextPart_001_01BF587E.B868B37A-- ------_=_NextPart_000_01BF587E.B868B37A Content-Type: text/plain; name="draft-ietf-ldapext-locate-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ldapext-locate-01.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT Michael P. = Armijo Levon = Esibov January, 2000 Paul = Leach Expires: July, 2000 Microsoft = Corporation Discovering LDAP Services with DNS 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. Distribution of this memo is unlimited. It is filed as , and expires on July 4, 2000. =20 Please send comments to the authors. 1. Abstract This draft defines a way that native Internet LDAP servers can make=20 use of the DNS's knowledge base to provide clients a method to=20 resolve LDAP services for a given domain. 2. Introduction The LDAPv3 protocol [1] is designed to be a lightweight access=20 protocol for directory services supporting X.500 models. This may=20 be the X.500 directory itself, but the LDAP specification=20 explicitly allows it to be a different directory. Let us define=20 a "native LDAP server" to be one that is not a front end to the=20 X.500 directory service. Let us further define an "Internet based=20 organization" as one that has a domain name, and an "Internet LDAP=20 server" to be one containing a directory entries for such an=20 organization. This draft defines a way that native Internet LDAP servers can make=20 use of the DNS's knowledge base to perform the same function, while=20 still supporting integration with the X.500 directory. This draft builds on RFC 2247[2] to define a mechanism by which=20 collections of native Internet LDAP servers can be integrated to=20 create a directory service. That work supports this cause by=20 defining a mapping from an LDAP DN to a DNS name that can be=20 resolved to the address of a server holding the entry corresponding=20 to the DN. For example, the DN = "CN=3DFred,OU=3DEng,DC=3Dexample,DC=3Dnet"=20 maps to the DNS name "example.net".=20 In an Internet context, many of the names about which users seek=20 information are DNS names, or include DNS names. A native LDAP based = directory service for the Internet should make it convenient to=20 process such names -- there is a huge social investment spanning two = decades to get to the point where names like=20 "john.doe@somewhere.example" and "http://www.example.net" can=20 appear in newspaper articles, TV commercials, and on billboards=20 and millions of people understand what to do with them. As a result, = we assume that Internet based organizations wish to preserve this=20 investment, yet also want to deploy directory services. Widespread use of, and dependence on, LDAP services will require = that=20 they are robust and scalable. Both of these features are typically=20 supported by replicated servers. Use of SRV records to locate LDAP=20 servers supports clients' use of replicated servers. 3. Locating LDAP servers through DNS LDAP server location information is to be stored using DNS Service=20 Location Record (SRV)[6]. The data in a SRV record contains the DNS = name of the server that provides the LDAP service, corresponding = Port=20 number, and parameters that enable the client to choose an=20 appropriate server from multiple servers according to the algorithm=20 described in the SRV protocol[6]. The name of this record always = has=20 the following format: _._. where is always "ldap", is a protocol that can=20 be either "udp" or "tcp", and is the domain hosted by the=20 LDAP Server. Note that "ldap" is the symbolic name for the LDAP=20 service in Assigned Numbers [7], as required by the SRV Protocol[6]. Presence of such records enables clients to find the LDAP servers=20 using standard DNS query [3]. As an example, a client that searches = for an LDAP server in the example.net domain that supports TCP = protocol=20 will submit a DNS query for a set of SRV records with owner name: =20 _ldap._tcp.example.net. The client will receive the list of SRV records published in DNS=20 that satisfy the requested criteria. The following is an example=20 of such record: _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net. The set of returned records may contain multiple records in the=20 case where multiple LDAP servers serve the same domain. =20 4. Security Considerations This document describes a method that uses DNS SRV records to=20 discover LDAP servers. All security considerations related to DNS SRV records are inherited by this document. See the security=20 considerations section in [6] for more details. 5. References [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access=20 Protocol(v3)". RFC 2251, December 1997. [2] S. Kille, M. Wahl, "Using Domains in LDAP/X.500 Distinguished=20 Names". RFC 2247, January 1998. [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND = FACILITIES, =20 November, 1987. =20 [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND=20 SPECIFICATION, November, 1987. [5] T. Howes, M. Smith, "The LDAP URL Format". RFC 2255 December = 1997. [6] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying = the=20 location of services (DNS SRV)".=20 http://www.ietf.org/internet-drafts/draft-ietf- dnsind-rfc2052bis-05.txt, November 1999. [7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, October 1994 6. Authors' Addresses Michael P. Armijo One Microsoft Way Redmond, WA 98052 micharm@microsoft.com Paul Leach One Microsoft Way Redmond, WA 98052 paulle@microsoft.com Levon Esibov One Microsoft Way Redmond, WA 98052 levone@microsoft.com Expires July, 2000 ------_=_NextPart_000_01BF587E.B868B37A-- From list@netscape.com Fri Jan 7 06:40:54 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14202 for ; Fri, 7 Jan 2000 06:40:54 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA27395; Fri, 7 Jan 2000 03:38:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA25395; Fri, 7 Jan 2000 03:39:50 -0800 (PST) Resent-Date: Fri, 7 Jan 2000 03:39:50 -0800 (PST) Message-Id: <200001071139.GAA14157@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-locate-01.txt Date: Fri, 07 Jan 2000 06:39:40 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"Y3GHGC.A.hMG.FCdd4"@glacier> 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 : Discovering LDAP Services with DNS Author(s) : M. Armijo, L. Esibov, P. Leach Filename : draft-ietf-ldapext-locate-01.txt Pages : 3 Date : 06-Jan-00 This draft defines a way that native Internet LDAP servers can make use of the DNS's knowledge base to provide clients a method to resolve LDAP services for a given domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-01.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-locate-01.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-locate-01.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: <20000106145049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-locate-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-locate-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000106145049.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Fri Jan 7 19:36: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 ESMTP id TAA29505 for ; Fri, 7 Jan 2000 19:36:43 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA16356; Fri, 7 Jan 2000 16:33:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA18979; Fri, 7 Jan 2000 16:35:29 -0800 (PST) Resent-Date: Fri, 7 Jan 2000 16:35:29 -0800 (PST) Message-Id: <3.0.5.32.20000107163506.009245a0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 07 Jan 2000 16:35:06 -0800 To: Michael Armijo , roland@catalogix.ac.se, jayhawk@att.com From: Bruce Greenblatt Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Cc: "'ietf-ldapext@netscape.com'" In-Reply-To: <4992824A0863D211964B0008C7B1ACB803F9AF63@fifi.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"z36C5C.A.RoE.QZod4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Michael, All this draft says is that if you use DC naming, you can look up the appropriate LDAP server using DNS. Is that right? Or is there something more? If there isn't anything more, why do we need to say it here. Shouldn't it go into Ryan and Roland's taxonomy draft, since they already have a section (2.5) on using SRV records? Thanks, Bruce P.S. As an aside, who in California has the personalized license plate LDAP??? ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Fri Jan 7 19:57:03 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29577 for ; Fri, 7 Jan 2000 19:57:03 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA03879; Fri, 7 Jan 2000 16:54:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA01154; Fri, 7 Jan 2000 16:55:51 -0800 (PST) Resent-Date: Fri, 7 Jan 2000 16:55:51 -0800 (PST) From: Luke Howard Message-Id: <200001080057.LAA88826@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: bgreenblatt@directory-applications.com Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Cc: ietf-ldapext@netscape.com, leif@netscape.com Reply-To: lukeh@PADL.COM Date: Sat, 8 Jan 2000 11:57:34 +1100 Versions: dmail (bsd44) 2.2g/makemail 2.9a Resent-Message-ID: <"cSQSkD.A.OR.Vsod4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >P.S. As an aside, who in California has the personalized license plate LDAP??? I believe it's Leif Hedstrom, who works at Netscape. -- Luke -- Luke Howard PADL Software Pty Ltd http://www.padl.com From list@netscape.com Fri Jan 7 20:02:52 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29710 for ; Fri, 7 Jan 2000 20:02:51 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA05010; Fri, 7 Jan 2000 17:00:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA05045; Fri, 7 Jan 2000 17:01:47 -0800 (PST) Resent-Date: Fri, 7 Jan 2000 17:01:47 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Fri, 7 Jan 2000 17:01:38 -0800 (PST) From: "RL 'Bob' Morgan" Reply-To: "RL 'Bob' Morgan" To: Bruce Greenblatt cc: Michael Armijo , roland@catalogix.ac.se, jayhawk@att.com, "'ietf-ldapext@netscape.com'" Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <3.0.5.32.20000107163506.009245a0@pop.walltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"iduLSD.A.dOB.6xod4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com On Fri, 7 Jan 2000, Bruce Greenblatt wrote: > All this draft says is that if you use DC naming, you can look up the > appropriate LDAP server using DNS. Is that right? Or is there > something more? If there isn't anything more, why do we need to say > it here. Shouldn't it go into Ryan and Roland's taxonomy draft, since > they already have a section (2.5) on using SRV records? Because ldapext-locate would become a Proposed Standard, and needs to be so to satisfy both common sense and the requirements of draft-ietf-dnsind-rfc2052bis-05.txt: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification. whereas the taxonomy draft will be Informational only. - RL "Bob" From list@netscape.com Sun Jan 9 17:10:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10553 for ; Sun, 9 Jan 2000 17:10:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA04281; Sun, 9 Jan 2000 14:08:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA02037; Sun, 9 Jan 2000 14:09:20 -0800 (PST) Resent-Date: Sun, 9 Jan 2000 14:09:20 -0800 (PST) From: jeffallen@sourcenet.org Subject: Good Luck in the New Millenium Date: Sun, 9 Jan 2000 17:14:59 Message-Id: <779.573764.159825@sourcenet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"C47BrC.A.jf.PcQe4"@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 To be removed from this mailing list immediately press reply and enter REMOVE on the subject line. Would you like to be able to buy Computers and Software at wholesale? At below what the stores Pay? Reply with "MORE INFO" in the subject field If you are a reseller and would like information on paying what the distributors pay then Reply with Reseller in the subject field. If you have computer products you need to sell then email your details From list@netscape.com Mon Jan 10 11:07:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06789 for ; Mon, 10 Jan 2000 11:07:00 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA26727; Mon, 10 Jan 2000 07:59:23 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA05448; Mon, 10 Jan 2000 08:00:33 -0800 (PST) Resent-Date: Mon, 10 Jan 2000 08:00:33 -0800 (PST) Message-Id: <200001101600.IAA17186@nasnfs.eng.sun.com> Date: Mon, 10 Jan 2000 08:00:34 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS To: bgreenblatt@directory-applications.com, rlmorgan@cac.washington.edu Cc: micharm@Exchange.Microsoft.com, roland@catalogix.ac.se, jayhawk@att.com, ietf-ldapext@netscape.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bEbzsc93cu8nfcIsQ6Hcvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Resent-Message-ID: <"YarniB.A.kUB.gIge4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Ryan's draft includes a number of other techniques for locating LDAP servers. Interoperability using them could benefit by standardization as well. Is LDAPEXT interested in considering proposals for standarization of other location methods? jak >Resent-Date: Fri, 7 Jan 2000 17:02:10 -0800 (PST) >X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs >Date: Fri, 7 Jan 2000 17:01:38 -0800 (PST) >From: "RL 'Bob' Morgan" >To: Bruce Greenblatt >cc: Michael Armijo , roland@catalogix.ac.se, jayhawk@att.com, "'ietf-ldapext@netscape.com'" >Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS >MIME-Version: 1.0 >Resent-Message-ID: <"iduLSD.A.dOB.6xod4"@glacier> >Resent-From: ietf-ldapext@netscape.com >X-Mailing-List: >X-Loop: ietf-ldapext@netscape.com >Resent-Sender: ietf-ldapext-request@netscape.com > > >On Fri, 7 Jan 2000, Bruce Greenblatt wrote: > >> All this draft says is that if you use DC naming, you can look up the >> appropriate LDAP server using DNS. Is that right? Or is there >> something more? If there isn't anything more, why do we need to say >> it here. Shouldn't it go into Ryan and Roland's taxonomy draft, since >> they already have a section (2.5) on using SRV records? > >Because ldapext-locate would become a Proposed Standard, and needs to be >so to satisfy both common sense and the requirements of >draft-ietf-dnsind-rfc2052bis-05.txt: > > Applicability Statement > > In general, it is expected that SRV records will be used by clients > for applications where the relevant protocol specification indicates > that clients should use the SRV record. Such specification MUST > define the symbolic name to be used in the Service field of the SRV > record as described below. It also MUST include security > considerations. Service SRV records SHOULD NOT be used in the absence > of such specification. > >whereas the taxonomy draft will be Informational only. > > - RL "Bob" > > From list@netscape.com Mon Jan 10 20:54:37 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16129 for ; Mon, 10 Jan 2000 20:54:37 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA21560; Mon, 10 Jan 2000 17:50:55 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA09527; Mon, 10 Jan 2000 17:53:25 -0800 (PST) Resent-Date: Mon, 10 Jan 2000 17:53:25 -0800 (PST) From: egiweisikjf@jgjpqjtacfy.ukonline.co.uk.netscape.com Subject: Top Of The Line FREE Pager -uqbrddb To: iqax5@netscape.com Message-ID: Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 09 Nov 1999 17:53:50 -0800 Resent-Message-ID: <"A9z5aD.A.SUC.U0oe4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com FREE PAGER Get a Brand New Satellite Pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check Put Free pagers on your kids Give one to your wife Paging America is going to give you a top of the line full featured pager in your choice of color for FREE. This top viewable display pager is one of the smallest and lightest pagers on the market today and holds up to 32 numeric messages, has 9 music alerts or silent vibration mode, flex technology which provides three times the battery life, message time and day stamping and smart alarm so you can set a daily or weekly reminder. This pager comes in black, teal (green) and blue. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. Airtime for this pager is only $9.95 per month billed monthly or only $8.95 per month if we bill your credit card or checking account each month. Just call the toll free number and we'll ship your Free pager to you immediately in your choice of color already programmed with a local telephone number for your town. For immediate delivery call Paging America 24 hours a day at 800-443-3122 This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph(a)(2)(c) of S.1618 From list@netscape.com Tue Jan 11 00:12: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 ESMTP id AAA19507 for ; Tue, 11 Jan 2000 00:12:17 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA07295; Mon, 10 Jan 2000 21:10:25 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA20364; Mon, 10 Jan 2000 21:11:36 -0800 (PST) Resent-Date: Mon, 10 Jan 2000 21:11:36 -0800 (PST) From: 93.1145@compuserve.com Date: Mon, 10 Jan 2000 21:11:33 -0800 (PST) Message-Id: <200001110511.VAA25871@xwing.netscape.com> To: fvbh787@aol.com Subject: Avoid Fines And Tickets Resent-Message-ID: <"vUcYUB.A.69E.Gure4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 1-937-586-9313 rem- mem778mem@popmail.com From list@netscape.com Fri Jan 14 01:56:49 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04612 for ; Fri, 14 Jan 2000 01:56:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id WAA07105; Thu, 13 Jan 2000 22:49:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA27723; Thu, 13 Jan 2000 22:52:30 -0800 (PST) Resent-Date: Thu, 13 Jan 2000 22:52:30 -0800 (PST) From: fine6999@continet.com Message-ID: <000011194679$000070ea$00005732@localhost.com> To: Subject: ACCEPT CREDIT CARDS NOW (FREE SIGN UP) !!!!!fgd Date: Thu, 13 Jan 2000 22:47:52 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Eudora pro 4.0 Resent-Message-ID: <"i7hGa.A.3wG.tesf4"@glacier> 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 {\rtf1\ansi\ansicpg1252\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans Serif;= }{\f1\froman\fcharset2 Symbol;}{\f2\fswiss MS Sans Serif;}} {\colortbl\red0\green0\blue0;} \deflang1033\pard\plain\f2\fs16\cf0 \par \par \par \par \par \par \par
\par
\par
You are receiving = this Email from \par me because you have either sent me an Email, Registered on my Web sit= e, belong \par to a program of which I am also a member, or you are a Member of a Sa= fe List to \par which I also subscribe. Just like you,
\par
 I am on= ly interested in \par contacting others that
have agreed they want to receive this infor= mation. If \par you no longer Wish to receive information from me, just click here or= copy and \par paste this into your
\par \par
 browser= \par
\par
 You will imm= ediately be \par removed from my Lists.
Thanks for your Time.  \par

INCREASE SALES UP \par TO 200%

ACCEPT CREDIT CARDS OVER THE INTERNET
NO SETUP \par FEES

<= /DIV> \par


\par

Good Credit / Bad Credit/ No Credit **** NO \par PROBLEM****!!!

= It Just \par Doesn't Matter - Everyone Gets Approved

No Up front Fees Fo= r \par Application-Processing

WE \par CHARGE ZERO FOR SETUP FEES!!

Limited Offer So Take Advantage Of It!!
= We Specialize \par In Servicing The Following:

*Web Page Design
*Multilevel \par Marketing
*Mail Order/Phone Sales
*At Home Business
*INTERNE= T BASED \par BUSINESS
*New Business*Small Business
Whatever!!! We Do It \par All!!!
Everyone Is Welcome!

Call 1-888-248-5565 No= w!

CALL WITHIN 72 HOURS AND RECEIVE A FREE \par APPLICATION AND SETUP OF YOUR     MERCHANT= \par ACCOUNT!  (A $195 VALUE!)

= If line is \par busy please keep trying we are experiencing high volume do to our inc= redible \par
offer!

\par

<= BR>

\par

(We will get you set up and taking credit c= ard orders \par within 5-7 days. )

\par

<= BR>

\par

Other companies take up to 4 weeks to get you set u= p and \par approved, that is if you get approved?

We will get you approv= ed, even if \par you are just starting out. Check our rates too.
We are very \par competitive.

WHAT MAKES US SO SPECIAL?


* We have a \par 98% approval ratio
* We \par offer secured on-line real time transactions.
* We offer 24 hour c= ustomer \par service 7 days a week.
* We offer complete training and installati= on through \par our technical
support group.
* We offer a life time warranty a= nd \par unlimited upgrades.
* We help make money for your company and your= \par customers.

\par


What Can We Do For Your \par Company????

>>>>>INTERNET \par SERVICE<<<<<

It's \par finally here!!!
A fast and reliable way to process credit cards th= rough your \par web site.
The Internet's reach is global it knows no time zones or= \par physical
boundaries. With our user friendly, easy to use program, = you will \par
convert your web site from an electronic brochure to a virtual st= orefront \par
without the addition of a sales clerk!!!!!

SECURE REAL-= TIME \par ON-LINE TRANSACTIONS make it as easy as possible for
your cus= tomers to \par purchase your products or services.
We use SSL SECURITY (best on = the NET \par today).

You will summon your customers' impulse buying when yo= u can \par safely
process credit cards through a secured web site linked dir= ectly to \par your web
page. The Internet is the fastest growing industry in tod= ay's direct \par marketing Business.
DON'T BE LEFT BEHIND!!!

Give your custo= mers the \par convenience of ordering products right from your
web page.
Now tell \par me if this doesn't sound intriguing, lets say a customer visits
yo= ur web site \par and decides they want to buy your product(s) or service(s).
They w= ould simply \par enter their credit card information and receive an approval WITHIN 5 \par SECONDS.
That's all there is to it!!!

From that point on, = the sale is \par complete and the money will be directly
deposited into your busine= ss checking \par account within 24 to 48 hours.
So you will have LIQUID ASSETS AVAI= LABLE \par ALMOST IMMEDIATELY!!!!
Your customer will be e-mailed a receipt a= nd you will \par be e-mailed an
invoice slip, all instantaneously. Now, since this = program is \par automated
for 24 hours a day 7 days a week, you will be receiving = orders and \par
making money in your sleep!!!!!
IT'S JUST THAT \par EASY!!!!

<= FONT size=3D4 \par PTSIZE=3D"11">




Call 1-888-248-5565 Now!

CALL WITHIN 72 HOURS AND REC= EIVE A FREE APPLICATION AND SETUP OF YOUR  =    \par MERCHANT ACCOUNT!  (= A $195 \par VALUE!) \par













 
\par


\par


\par \par }

{\rtf1\ansi\ansicpg1252\deff0\deftab720{\fon= ttbl{\f0\fswiss MS Sans Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fswiss M= S Sans Serif;}}

{\colortbl\red0\green0\blue0;}

\deflang1033\pard\plain= \f2\fs16\cf0

From list@netscape.com Sun Jan 16 15:19:45 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10939 for ; Sun, 16 Jan 2000 15:19:44 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA23452; Sun, 16 Jan 2000 12:15:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA25440; Sun, 16 Jan 2000 12:18:32 -0800 (PST) Resent-Date: Sun, 16 Jan 2000 12:18:32 -0800 (PST) Message-Id: <3.0.5.32.20000116121640.00920de0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 16 Jan 2000 12:16:40 -0800 To: internet-drafts@ietf.org From: Bruce Greenblatt Subject: draft-greenblatt-ldap-certinfo-schema-01 Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_948082600==_" Resent-Message-ID: <"-uCWR.A.kMG.Weig4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_948082600==_ Content-Type: text/plain; charset="us-ascii" I-D editor: please replace draft-greenblatt-ldap-certinfo-schema-00 with the following draft-greenblatt-ldap-certinfo-schema-01. LDAPEXT: Attached is a personal draft that defines a new object class to hold information about certificates, so that all of a user's certificates don't need to be directly attached to the user's entry in LDAP. It has been updated with comments I've received over the last few months. Enjoy... Ryan --=====================_948082600==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="cert-type-01.out" Application Working Group Bruce Greenblatt Internet Draft Expires in six months LDAP Object Class for Holding Certificate Information Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, andits working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "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. Distribution of this document is unlimited. Abstract This draft describes a means for LDAP applications to store large numbers of certificates for a single user, and to still have individual certificates easily retrievable without the need for any extensions to the LDAP v2 or v3 protocols. 1. Mechanism When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 [2], it is normally only possible to read either the attribute type, or the attribute type and all its values. It is not possible to selectively read just a few of the attribute values using the basic structures of Greenblatt [Page 1] Internet Draft January 2000 the protocol defined in [1] or [2]. Certain information that belongs to a user may have many different values. For example, some users may have quite a large number of certificates that need to be stored in the directory. If a user has 1000s of certificates, then it may be diffi- cult to find the exact one that is needed. If only one certificate is needed by the LDAP client, then retrieving the entire userCertificate attribute that has 1000s of values is a waste of time. If numerous application services are going to want to selectively retrieve certificates (which is perfectly valid), a general solution in the schema should be provided. The following solution is given: RFC 2587 defines a schema for holding certificate information, but assumes that all of a user's certificates are attached to that user's LDAP entry. Use this structural class to indicate that an object in the directory is a specific type of certificate. Each certificateType object in the directory appears directly beneath the owner of the cer- tificate in the directory hierarchy. RFC 2459 [3] specifies a profile for X.509 v3 certificates. It's definitions are used to define the attributes that can be placed in a certificateType object. ( o.i.d.m.i.s.s.i.n.g. NAME 'certificateType' SUP top STRUCTURAL MUST typeName MAY ( serialNumber $ issuer $ validityNotBefore $ vallidityNo- tAfter $ subject $ subjectPublicKeyInfo) certificateExtension $ other- Info ) ) The attributes are defined as follows: ( NAME 'typeName' SUP name SINGLE-VALUE ) The typeName attribute specifies the application defined type of the certificate that is attached to this entry using the strongAuthenti- cationUser auxiliary object class. Note that there may not be any cer- tificates attached to this entry if the user has no certificates of the specified type. Each type name uniquely identifies an entry within the container. The following attributes are the LDAP representations of the cer- tificate attributes defined in RFC 2459, and have been pulled out as separate attributes to ease searching. ( NAME 'serialNumber' SUP name SINGLE-VALUE ) Rather than using the ASN.1 integer type as is used in RC 2459, the serialNumber attribute represents the value in string format representa- tion of the decimal format of the serial number. Greenblatt [Page 2] Internet Draft January 2000 ( NAME 'issuer' SUP distinguishedName SINGLE-VALUE ) ( NAME 'validityNotBefore' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( NAME 'validityNotAfter' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) The 'validityNotBefore" and 'validityNotAfter' attributes have split the 'validity' attribute defined in RFC 2459 which uses an ASN.1 sequence containing a "notBefore" and a "notAfter" value. Instead of using an ASN.1 Sequence, the character string representation of each time as defined in section 6.14 of RFC 2252 is used for each time. For example, if the 'validityNotBefore' attribute held the time value: "199412161032Z" and the 'validityNotAfter' attribute held the time val- uee: "199512161032Z", then that would indicate that the certificate described by this entry was valid from December 16, 1994 to December 16, 1995. ( NAME 'subject' SUP distinguishedName SINGLE-VALUE ) ( NAME 'subjectPublicKeyInfo' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} SINGLE-VALUE ) The certificateExtension attribute is used to store whatever inter- esting extension from the certifcate that are pulled out of the stored certificate. Note that it is the only multi-valued attribute of the certificateType object class. ( NAME 'certificateExtension' octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) The format of the certificate extension attribute value is a string representation of an OID according to the specifications of RFC 2252 [4], followed by a '$' as the separation character, followed by the value. Octets following the dollar sign may be binary data. For exam- ple, the keyUsage extension defined in RFC 2459 is a bitString. For extensions that are ASN.1 encoded (such as the keyUsage extension), the entire ASN.1 encoding MUST immediately follow the separation character. Other certificate formats that allow non ASN.1 encoded extensions MUST place their values immediately following the separation character as well. Greenblatt [Page 3] Internet Draft January 2000 ( NAME 'otherInfo' SUP name ) The purpose of the otherInfo attribute is to allow descriptive information to be placed in entry that does not appear in the certifi- cate itself. The values of this attribute are free form text strings, e.g. "this certificate gets me into the IETF web site". Note that the certificateType object class does not include an attribute for holding the actual certificate. This is due to the fact that the certificate will be held in an attribute of an auxiliary object class that will be attached to the entry. 2. Comparison with Matched Values Only Control A control has been defined that allows for only certain values of a specified attribute to be returned from a matching entry [5]. In this section, these two approaches are compared. The major benefit of the Matched Values Only Control is that it does not require any changes to the DIT. If a customer has deployed certificate information in such a way that individual entries have numerous certificates attached to them then the Matched Values Only Control is useful. While it is a simple matter to modify the DIT in such a way that all certificate information is removed from the entries, and placed in the container directly beneath the entries according to the definitions of this specification, it is less simple to simultaneously modify all of the applications that depend on certificates being stored in the entry. Thus, it may be desirable to duplicate the certificate information, by having it appear in the entry, as well as in the container beneath the entry for a short period of time, in order to allow for migration of the applications to the new LDAP schema. As in any situation in which information is dupli- cated, great care must be taken in order to insure the integrity of the information. There are several advantages to using the certificateType object class. No special matching rules are needed to retrieve a specific cer- tificate. Any field in the certificate can be used in the search fil- ter. Even information that doesn't appear in the certificate can be used in a search filter. It is easier to remove certificates from the DIT, since the entire certificate DER does not have to be supplied in the modify operation. 3. Examples Using the certificate given in Section D.2 of RFC 2459, the follow- ing values would be used for the attributes defined in this draft: Greenblatt [Page 4] Internet Draft January 2000 typeName - "General Purpose Certificate" serialNumber - "18" issuer - "OU=nist; O=gov; C=US" subject - "CN=Tim Polk; OU=nist; O=gov; C=US" validityNotBefore - "970730000000Z" validityNotAfter - "971231000000Z" certificateExtension: "2.5.29.17: " + 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76 otherInfo - "contains a 1024 bit DSA public key", "this was issued for test purposes only" 4. References [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Proto- col" RFC 1777, March 1995. [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Proto- col, (v3)" RFC 2251, December 1997. [3] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile. RFC 2459, January 1999. [4] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions" RFC 2252, December 1997. [5] D. Chadwick, Sean Mullan, "Returning Matched Values with LDAPv3", Internet Draft (work in progress), September 1999. 5. Author's Address Bruce Greenblatt Directory Tools and Application Services, Inc. 6841 Heaton Moor Drive San Jose, CA 95119 USA Email: bgreenblatt@directory-applications.com Greenblatt [Page 5] --=====================_948082600==_ Content-Type: text/plain; charset="us-ascii" ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=====================_948082600==_-- From list@netscape.com Sun Jan 16 15:32:00 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11022 for ; Sun, 16 Jan 2000 15:32:00 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA27312; Sun, 16 Jan 2000 12:29:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA27896; Sun, 16 Jan 2000 12:30:57 -0800 (PST) Resent-Date: Sun, 16 Jan 2000 12:30:57 -0800 (PST) Message-Id: <3.0.5.32.20000116122936.00921dd0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 16 Jan 2000 12:29:36 -0800 To: ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: Re: draft-greenblatt-ldap-certinfo-schema-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"wlW3-C.A.SzG.Aqig4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Also, note that I placed a diagram on my web site that shows a portion of the DIT that might exist if the schema proposed by this draft were implemented. It shows a user with three 'certificateType' objects. Check it out at: http://www.directory-applications.com/drafts/certType.htm Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Sun Jan 16 21:35:35 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12892 for ; Sun, 16 Jan 2000 21:35:35 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA09944; Sun, 16 Jan 2000 18:32:28 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA08036; Sun, 16 Jan 2000 18:33:46 -0800 (PST) Resent-Date: Sun, 16 Jan 2000 18:33:46 -0800 (PST) From: jbagsofmoney@ecuamail.com.ec To: Date: Tue, 18 Jan 2000 13:38:27 Message-Id: <587.565863.154691@mail.miv.spfghdfg.com> Subject: ADV: Homeowners....Debt Consolidation and Refinancing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TCo1iD.A.O9B.J-ng4"@glacier> 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 Comparison shop thousands of loan programs through hundreds of lenders by filling in a single short form. Let lenders compete for your business! => Cash back refinances => No Equity 2nd Trust Deeds => Debt Consolidation => No Income Verification => The most competitive interest rates. Fill in our quick pre-qualification form and you will be contacted by up to three lenders that specialize in the type of loan you are looking for. Visit this website: http://3499894548/%7elI0?EK0114 (If the page does not come right up try again later) => Save Time => Save Money => Save Aggravation There is NEVER any fee to consumers for using this service. to be removed email jbagsofmoney@ecuamail.com.ec or dial 888 248 0765 From list@netscape.com Mon Jan 17 19:41:17 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10724 for ; Mon, 17 Jan 2000 19:41:16 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA01227; Mon, 17 Jan 2000 16:35:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA14850; Mon, 17 Jan 2000 16:37:11 -0800 (PST) Resent-Date: Mon, 17 Jan 2000 16:37:11 -0800 (PST) Message-Id: <3.0.5.32.20000117163620.00922920@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 17 Jan 2000 16:36:20 -0800 To: ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <4992824A0863D211964B0008C7B1ACB803F9AF63@fifi.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1qxIs.A.wnD.2W7g4"@glacier> 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 don't understand (or necessarily agree with) the first two paragraphs of this draft. What difference does it make to this mechanism what a "native" LDAP server is? If this mechanism doesn't work for non-native LDAP servers, shouldn't the draft explain why this is the case? I'd just drop this whole notion from the draft. Can this same mechanism be used to find an LDAP server from an email address? It seems like you should be able to find the appropriate SRV record from an email address just as easy as you can from a DN that conforms to the DC naming principles. Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Tue Jan 18 03:06:47 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26868 for ; Tue, 18 Jan 2000 03:06:47 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA23402; Tue, 18 Jan 2000 00:04:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA20243; Tue, 18 Jan 2000 00:05:49 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 00:05:49 -0800 (PST) From: joejonston33@mundomail.net To: Date: Tue, 18 Jan 2000 00:31:34 Message-Id: <779.737988.118847@mail45.rasasjdsaiod.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MTT_g.A.B8E.d7Bh4"@glacier> Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Put Money Into Your Pocket! Use our bulk email service today! Send your message to lots and lots of people NOW! Half million email broadcast $550.00. One million email broadcast $1200.00. Call today, 1 877 205 9117 for details on how to put your cold calling days to an end! SENT BY E MAIL SPECIALTIES TORONTO CANADA ALL PRICES IN US FUNDS From list@netscape.com Tue Jan 18 03:55:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27053 for ; Tue, 18 Jan 2000 03:55:01 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA25998; Tue, 18 Jan 2000 00:52:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA27667; Tue, 18 Jan 2000 00:53:56 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 00:53:56 -0800 (PST) From: joejonston33@mundomail.net To: Date: Tue, 18 Jan 2000 00:16:01 Message-Id: <488.483582.748998@mail45.rasasjdsaiod.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Q3Pe4C.A._vG.joCh4"@glacier> Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Put Money Into Your Pocket! Use our bulk email service today! Send your message to lots and lots of people NOW! Half million email broadcast $550.00. One million email broadcast $1200.00. Call today, 1 877 205 9117 for details on how to put your cold calling days to an end! SENT BY E MAIL SPECIALTIES TORONTO CANADA ALL PRICES IN US FUNDS From list@netscape.com Tue Jan 18 04:16:35 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27173 for ; Tue, 18 Jan 2000 04:16:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id BAA27775; Tue, 18 Jan 2000 01:13:38 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id BAA00947; Tue, 18 Jan 2000 01:14:57 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 01:14:57 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Tue, 18 Jan 2000 01:14:41 -0800 (PST) From: "RL 'Bob' Morgan" Reply-To: "RL 'Bob' Morgan" To: Bruce Greenblatt cc: ietf-ldapext@netscape.com Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <3.0.5.32.20000117163620.00922920@pop.walltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"8LbHoC.A.hO.Q8Ch4"@glacier> 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 don't understand (or necessarily agree with) the first two > paragraphs of this draft. What difference does it make to this > mechanism what a "native" LDAP server is? If this mechanism doesn't > work for non-native LDAP servers, shouldn't the draft explain why this > is the case? I'd just drop this whole notion from the draft. You're right that this method is useful independent of what kind of LDAP server is to be discovered (it is of course only defined in the case of DNs that map to DNS domain names); hence this text and the "Internet based organization" bits are not needed. Also, this paragraph: This draft defines a way that native Internet LDAP servers can make use of the DNS's knowledge base to perform the same function, while still supporting integration with the X.500 directory. is misleading since the method can be used by any process, client or server, that wants to determine server names from a DN. I think this motivational material would be better put into the taxonomy draft, which seems to me to be lacking in info about why you would use one discovery technique over another. The taxonomy draft should IMHO highlight the SRV-record approach, which in its limited domain solves the problem quite nicely. > Can this same mechanism be used to find an LDAP server from an email > address? It seems like you should be able to find the appropriate SRV > record from an email address just as easy as you can from a DN that > conforms to the DC naming principles. This would depend on whether the organization had chosen to represent the entities with those email addresses (whatever those entities are) as the corresponding directory entries. This is recommended in RFC 2377 but is obviously optional. A DN presumably identifies a directory object but an email address may or may not. Also, IMHO finding a dir entry corresponding to an email address implies a search operation for an entry with that email address as an attribute (which attribute might vary based on what it is you're trying to do); whereas a DN obviously identifies an entry directly. There may be a doc to be written about "finding directory entries based on RFC 822 email addresses" ... - RL "Bob" From list@netscape.com Tue Jan 18 10:33:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00887 for ; Tue, 18 Jan 2000 10:33:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA21668; Tue, 18 Jan 2000 07:30:42 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA06526; Tue, 18 Jan 2000 07:31:57 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 07:31:57 -0800 (PST) Message-ID: <438D12915E64D2118AB10000F8C1C07802159863@zcard00e.ca.nortel.com> From: "James Benedict" To: "RL 'Bob' Morgan" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 10:31:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF61C9.0E142DEC" Resent-Message-ID: <"SqRfE.A.slB.sdIh4"@glacier> 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_01BF61C9.0E142DEC Content-Type: text/plain; charset="iso-8859-1" The problem with this method is that the resolving client must already have knowledge about the directory containing the DN. Specificly, the resolving client must expect that the DC tree represented by the DN is a valid internet domain. For examlple, a an enterprise intranet directory for example.net may have internal DNS domains internal.example.net and external.example.net giving the DN "cn=External Person, ou=customers, dc=external, dc=example, dc=net" However, this gives no guarentee that _ldap._tcp.external.example.net exists on the internet. In this case it is possible that _ldap._tcp.external.net provides access to the referenced directory structure. So not only does this method assume that the directory is arranged by DNS domain, but it also assumes that the directory is arranged by DNS domains that are externally exposed. I actually believe that email, or web address is a better resolution mechanism, because they are more likely to point to an address that can be resolved on the internet. James A Benedict Advisor, IP Directory Systems Architecture Carrier Packet Solutions NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: RL 'Bob' Morgan [mailto:rlmorgan@cac.washington.edu] > Sent: Tuesday, January 18, 2000 4:15 AM > To: Bruce Greenblatt > Cc: ietf-ldapext@netscape.com > Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > > > I don't understand (or necessarily agree with) the first two > > paragraphs of this draft. What difference does it make to this > > mechanism what a "native" LDAP server is? If this mechanism doesn't > > work for non-native LDAP servers, shouldn't the draft > explain why this > > is the case? I'd just drop this whole notion from the draft. > > You're right that this method is useful independent of what > kind of LDAP > server is to be discovered (it is of course only defined in > the case of > DNs that map to DNS domain names); hence this text and the > "Internet based > organization" bits are not needed. Also, this paragraph: > > This draft defines a way that native Internet LDAP servers > can make > use of the DNS's knowledge base to perform the same > function, while > still supporting integration with the X.500 directory. > > is misleading since the method can be used by any process, client or > server, that wants to determine server names from a DN. > > I think this motivational material would be better put into > the taxonomy > draft, which seems to me to be lacking in info about why you > would use one > discovery technique over another. The taxonomy draft should IMHO > highlight the SRV-record approach, which in its limited > domain solves the > problem quite nicely. > > > Can this same mechanism be used to find an LDAP server from an email > > address? It seems like you should be able to find the > appropriate SRV > > record from an email address just as easy as you can from a DN that > > conforms to the DC naming principles. > > This would depend on whether the organization had chosen to > represent the > entities with those email addresses (whatever those entities > are) as the > corresponding directory entries. This is recommended in RFC > 2377 but is > obviously optional. A DN presumably identifies a directory > object but an > email address may or may not. Also, IMHO finding a dir entry > corresponding to an email address implies a search operation > for an entry > with that email address as an attribute (which attribute > might vary based > on what it is you're trying to do); whereas a DN obviously > identifies an > entry directly. There may be a doc to be written about > "finding directory > entries based on RFC 822 email addresses" ... > > - RL "Bob" > > > ------_=_NextPart_001_01BF61C9.0E142DEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services = with DNS

The problem with this method is that the resolving = client must already
have knowledge about the directory containing the = DN.  Specificly, the
resolving client must expect that the DC tree = represented by the DN
is a valid internet domain.

For examlple, a an enterprise intranet directory for = example.net may
have internal DNS domains internal.example.net and = external.example.net
giving the DN "cn=3DExternal Person, = ou=3Dcustomers, dc=3Dexternal, dc=3Dexample,
dc=3Dnet" However, this gives no guarentee that = _ldap._tcp.external.example.net
exists on the internet. In this case it is possible = that _ldap._tcp.external.net provides access to the referenced = directory structure. 

So not only does this method assume that the = directory is arranged by DNS domain, but it also assumes that the = directory is arranged by DNS domains

that are externally exposed.

I actually believe that email, or web address is a = better resolution
mechanism, because they are more likely to point to = an address that
can be resolved on the internet.

James A Benedict
Advisor, IP Directory Systems Architecture
Carrier Packet Solutions
NORTEL NETWORKS
Ph:  (613) 763-3909


> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:rlmorgan@cac.washingt= on.edu]
> Sent: Tuesday, January 18, 2000 4:15 AM
> To: Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: Re: draft-ietf-ldapext-locate-01.txt - = Discovering LDAP
> Services with DNS
>
>
>
> > I don't understand (or necessarily agree = with) the first two
> > paragraphs of this draft.  What = difference does it make to this
> > mechanism what a "native" LDAP = server is?  If this mechanism doesn't
> > work for non-native LDAP servers, = shouldn't the draft
> explain why this
> > is the case?  I'd just drop this = whole notion from the draft.
>
> You're right that this method is useful = independent of what
> kind of LDAP
> server is to be discovered (it is of course = only defined in
> the case of
> DNs that map to DNS domain names); hence this = text and the
> "Internet based
> organization" bits are not needed.  = Also, this paragraph:
>
>    This draft defines a way that = native Internet LDAP servers
> can make
>    use of the DNS's knowledge = base to perform the same
> function, while
>    still supporting integration = with the X.500 directory.
>
> is misleading since the method can be used by = any process, client or
> server, that wants to determine server names = from a DN.
>
> I think this motivational material would be = better put into
> the taxonomy
> draft, which seems to me to be lacking in info = about why you
> would use one
> discovery technique over another.  The = taxonomy draft should IMHO
> highlight the SRV-record approach, which in its = limited
> domain solves the
> problem quite nicely.
>
> > Can this same mechanism be used to find an = LDAP server from an email
> > address? It seems like you should be able = to find the
> appropriate SRV
> > record from an email address just as easy = as you can from a DN that
> > conforms to the DC naming = principles.
>
> This would depend on whether the organization = had chosen to
> represent the
> entities with those email addresses (whatever = those entities
> are) as the
> corresponding directory entries.  This is = recommended in RFC
> 2377 but is
> obviously optional.  A DN presumably = identifies a directory
> object but an
> email address may or may not.  Also, IMHO = finding a dir entry
> corresponding to an email address implies a = search operation
> for an entry
> with that email address as an attribute (which = attribute
> might vary based
> on what it is you're trying to do); whereas a = DN obviously
> identifies an
> entry directly.  There may be a doc to be = written about
> "finding directory
> entries based on RFC 822 email addresses" = ...
>
>  - RL "Bob"
>
>
>

------_=_NextPart_001_01BF61C9.0E142DEC-- From list@netscape.com Tue Jan 18 15:00:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05239 for ; Tue, 18 Jan 2000 15:00:56 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA07600; Tue, 18 Jan 2000 11:58:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA13558; Tue, 18 Jan 2000 11:59:34 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 11:59:34 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 18 Jan 2000 12:59:05 -0700 From: "Steven Merrill" To: "<" Subject: Java LDAP API section 4.28.2 add Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"5BabmC.A.eSD.kYMh4"@glacier> 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05239 The addition of the convenience method: public void add(LDAPEntry entry) throws LDAPException; to section 4.28.2 (add) of "draft-ietf-ldapext-ldap-java-api-09.txt" would make that section more consistent with sections: 4.28.4 compare, 4.28.6 delete, 4.28.9 modify, 4.28.10 read, etc..., where the LDAPConstraints parameter need not be specified. I vote the above method be added to the draft. Steve Merrill Novell, Inc. From list@netscape.com Tue Jan 18 17:53:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06936 for ; Tue, 18 Jan 2000 17:53:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA04887; Tue, 18 Jan 2000 14:51:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA00623; Tue, 18 Jan 2000 14:52:22 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 14:52:22 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Tue, 18 Jan 2000 14:49:14 -0800 (PST) From: "RL 'Bob' Morgan" Reply-To: "RL 'Bob' Morgan" To: James Benedict cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <438D12915E64D2118AB10000F8C1C07802159863@zcard00e.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"WJpERB.A.dJ.l6Oh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com On Tue, 18 Jan 2000, James Benedict wrote: > So not only does this method assume that the directory is arranged by > DNS domain Indeed, if directory objects are named based on DNS names, then this method can be used. Otherwise, there is no defined dynamic discovery method. I know which naming scheme I'll choose. > but it also assumes that the directory is arranged by DNS domains that > are externally exposed. True. Use of the referenced directory also depends on it being accessible by the client. If applications don't have access to the network resources they need then they fail. Presumably those doing deployments will do their best to avoid this situation. I'm not sure what conclusion to draw. If your point is that the DNS service supplying the SRV records might have different access control than the LDAP directory service that is being referenced, this is certainly true; in practice it seems to me that DNS is much more likely to be Internet-accessible than an LDAP DS. > I actually believe that email, or web address is a better resolution > mechanism, because they are more likely to point to an address that > can be resolved on the internet. The locate spec only specifies what to do if you're starting with a DN, since DNs are how directory entries are named. Mapping from the domain part of an RFC-822 email address to a DN is defined in RFC 2247; if the client arrives at the DN by this means, then discovers the D based on that DN, then this would presumably do what you want. I would say that deployment models of LDAP directories to take advantage of dc-names and SRV records in order to form a DNS-name-based Internet-wide directory service is a rich and interesting topic. I'm sure there will be further discussion ... - RL "Bob" From list@netscape.com Tue Jan 18 20:45:23 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08427 for ; Tue, 18 Jan 2000 20:45:20 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA01948; Tue, 18 Jan 2000 17:42:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA21714; Tue, 18 Jan 2000 17:44:09 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 17:44:09 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED50@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Bruce Greenblatt'" , ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 17:33:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"zwMFv.A.mSF.obRh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Monday, January 17, 2000 4:36 PM > To: ietf-ldapext@netscape.com > Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > I don't understand (or necessarily agree with) the first two > paragraphs of > this draft. What difference does it make to this mechanism > what a "native" > LDAP server is? We needed a word to describe servers whose NCs have DNs that start with a series of "DC=" components. Ones that don't have such names for their NCs are using the X.500 naming model with LDAP front ends -- those are "X.500-ish" LDAP servers. > If this mechanism doesn't work for non-native LDAP > servers, shouldn't the draft explain why this is the case? Of course it doesn't work -- what DNS name corresponds to "O=Example,C=US"? The mechanism depends on the DN starting with a series of DC= components; i.e., that they be "native". > I'd just drop > this whole notion from the draft. > > Can this same mechanism be used to find an LDAP server from an email > address? It seems like you should be able to find the appropriate SRV > record from an email address just as easy as you can from a DN that > conforms to the DC naming principles. Sure, but only if the SRV records are registered. Nothing today existing says they should be. I don't think finding an LDAP server from a email address is particularly interesting by itself, only in association with a larger task, such as perhaps finding a certificate for a user given their email address, or (in general) their directory entry, in order to get their telephone number or manager's name or whatever. I believee there was some discussion about that sort of thing, even a draft. Paul From list@netscape.com Tue Jan 18 20:52:02 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08455 for ; Tue, 18 Jan 2000 20:52:01 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA02851; Tue, 18 Jan 2000 17:49:37 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA24928; Tue, 18 Jan 2000 17:50:58 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 17:50:58 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED51@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'James Benedict'" , "RL 'Bob' Morgan" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 17:42:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"b9OV3D.A.-EG.AiRh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com -----Original Message----- From: James Benedict [mailto:grunt@nortelnetworks.com] Sent: Tuesday, January 18, 2000 7:31 AM To: RL 'Bob' Morgan; Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS > The problem with this method is that the resolving client must already > have knowledge about the directory containing the DN. Specificly, the > resolving client must expect that the DC tree represented by the DN > is a valid internet domain. This isn't strictly true. The client just guesses that the "DC=" components form a DNS name; if the guess is wrong, it will find out soon enough. Since, as Bob points out, one is currently hosed if this guess is wrong, the incentive to make it be correct will be high. I think this is "a good thing". Paul From list@netscape.com Tue Jan 18 21:30:57 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08647 for ; Tue, 18 Jan 2000 21:30:56 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA17542; Tue, 18 Jan 2000 18:25:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA07397; Tue, 18 Jan 2000 18:28:40 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 18:28:40 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED53@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'RL 'Bob' Morgan'" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 18:19:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"V4N6MC.A._yB.XFSh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > -----Original Message----- > From: RL 'Bob' Morgan [mailto:rlmorgan@cac.washington.edu] > Sent: Tuesday, January 18, 2000 1:15 AM > To: Bruce Greenblatt > Cc: ietf-ldapext@netscape.com > Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > > > I don't understand (or necessarily agree with) the first two > > paragraphs of this draft. What difference does it make to this > > mechanism what a "native" LDAP server is? If this mechanism doesn't > > work for non-native LDAP servers, shouldn't the draft > explain why this > > is the case? I'd just drop this whole notion from the draft. > > You're right that this method is useful independent of what > kind of LDAP > server is to be discovered (it is of course only defined in > the case of > DNs that map to DNS domain names); hence this text and the > "Internet based > organization" bits are not needed. Also, this paragraph: > > This draft defines a way that native Internet LDAP servers > can make > use of the DNS's knowledge base to perform the same > function, while > still supporting integration with the X.500 directory. > > is misleading since the method can be used by any process, client or > server, that wants to determine server names from a DN. I just read the draft again, and I agree that this section seems out of context. The phrase "the same function" seems to be unbound to any antecedant. As I looked back at a previous draft, a paragraph got lost. It used to say: "A native LDAP server can not rely upon the X.500 directory's knowledge base to locate the appropriate server to service a request on an object in a part of the directory tree (DIT) other than the naming context(s) it stores. This draft defines a way that native Internet LDAP servers can make use of the DNS's knowledge base (which it stores as "glue" records) to perform the same function, while still supporting integration with the X.500 directory." This still isn't great, but at least there's no danglisng reference. All I was trying to say is that native LDAP servers have a unique problem that they wouldn't have if LDAP servers were just front ends for the X.500 directory. In that case, a client wanting to resolve a DN could contact any LDAP server, and if the DN weren't stored in one of that server's NCs, it could generate a referral to a better LDAP server, which would ultimately get to the server storing the DN. Since native LDAP servers have no backing X.500 directory, they can't do that. What they can do is try to use DNS instead -- by constructing a DNS name from the "DC=" components. I don't think this is worth holding up progress for. I can make an editorial change befre the RFC is published, if people think its really important. Paul From list@netscape.com Tue Jan 18 21:51:07 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09713 for ; Tue, 18 Jan 2000 21:51:06 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA19412; Tue, 18 Jan 2000 18:47:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA15739; Tue, 18 Jan 2000 18:50:02 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 18:50:02 -0800 (PST) Message-Id: <3.0.5.32.20000118184943.00923230@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 18 Jan 2000 18:49:43 -0800 To: Paul Leach , ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <19398D273324D3118A2B0008C7E9A569051BED50@SIT.platinum.corp .microsoft.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_948278983==_" Resent-Message-ID: <"WI5nFB.A.p1D.ZZSh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_948278983==_ Content-Type: text/plain; charset="us-ascii" At 05:33 PM 1/18/00 -0800, Paul Leach wrote: > > >> -----Original Message----- >> From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] >> Sent: Monday, January 17, 2000 4:36 PM >> To: ietf-ldapext@netscape.com >> Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP >> Services with DNS >> >> >> I don't understand (or necessarily agree with) the first two >> paragraphs of >> this draft. What difference does it make to this mechanism >> what a "native" >> LDAP server is? > >We needed a word to describe servers whose NCs have DNs that start with a >series of "DC=" components. Ones that don't have such names for their NCs >are using the X.500 naming model with LDAP front ends -- those are >"X.500-ish" LDAP servers. > OK. The draft should drop the use of "native", and just say that it applies to LDAP servers that have standardiz(s)ed on the "DC" naming RFC. I liked the words in the original version of the taxonomy draft that said something to the effect of: "If the directory uses DC naming then you can do this...". I'd also mention the sentiments expressed by R. L. "Bob": >Indeed, if directory objects are named based on DNS names, then this >method can be used. Otherwise, there is no defined dynamic discovery >method. I know which naming scheme I'll choose. > I've also attached my (very) old draft that talks about how to get a directory entry from an email address. The locate draft and the taxonomy draft don't seem to deal with this issue. Does anyone think that I should update this and get it moved forward as an Informational Draft? Bruce --=====================_948278983==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="defema02c.out" Application Working Group Bruce Greenblatt Internet Draft Expires in six months Directory Entries From Email Address Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, andits 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. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Abstract This draft describes various means for finding a user's direc- tory entry in a LDAP directory presuming that the user's electronic mail address is known. This draft does not presume any specific DIT structure or schema modifications. 1. Mechanism It is crucial to the success of finding services in the Internet that SRV records as defined in [1] be deployed. This draft shows how these records can be used in a straightforward manner to assist in the location of user records. First, assume that a users email address is of the form: name@domain, and domain is of the form: dcn. ... .dc0.tld, where: tld is a top level domain, dc0 is an IETF registered domain name, and dcn through dc1 are locally administer subdomains of dc1, and n is greater than or equal to 0. Examples of Greenblatt [Page 1] Internet Draft July 1997 valid name forms are: - bgg@novell.com - user@scvwd.ca.us - foo@bar2.bar1.bar0.za In order to find the directory entry that corresponds to these email addresses, find the most specific domain name, i.e. dcn. ... .dco.tld, and use this string in a DNS lookup for an LDAP [3] service according to the mechanisms defined in [1]. If such a service is not found, then continue stripping off domain components until the dc0.tld component of the address is extracted and used in a DNS lookup for an LDAP service according to the mechanisms defined in [1]. So, in the last example above, the DNS lookups would start with bar2.bar1.bar0.za, and if that one yields no LDAP service, the next lookup would be for bar1.bar0.za, and if that lookup were again not successful the third try would be for the full hostname of bar0.za. An example SRV record that might appear in the bar0.za zone file is: ldap.tcp SRV 0 0 389 ldap.bar0.za If such a service is found in one of the DNS lookups, then an LDAP subtree search for a person object with a "mail" attribute EQUAL to the known email address is then used. The search base for the search should be set to the empty string, since it is not obvious from examining the email address, what the appropriate search base should be. It is presumed that most directory services will be optimized for fast lookups based on email addresses. If the email address is valid, and the LDAP server for the registered domain either has an entry for the person, or can generate a referal to another directory server (possibly non-LDAP, e.g. X.500, Whois++, etc.), then we're done, and we have (or will shortly have) the direc- tory entry in question. Just as email administrators need to put MX records for each publicized domain in the email address, the direc- tory administrator needs to put SRV records for the various services for each publicized domain name. On the other hand, if the search fails, there are several ave- nues available to help find this user. - the timeLimit parameter of the session control can be raised to a higher limit. - do a SUBSTRING search against the "mail" attribute with just the Greenblatt [Page 2] Internet Draft July 1997 name component - an LDAP service for a more fully qualified domain (e.g. dc1.dc0.tld) can be looked up, again according to the definitions in [1] - a well known indexing [2] Internet directory service can be queried for the email address Note that it is possible that there is no directory entry for the user, in which case all possible lookups will fail. If the user's email address and directory entry are controlled by different domains with no links between the two domains, it will not be possible to find the user's directory entry from the email address initially, but if an Indexed Internet directory that has retrieved the user's direc- tory entry from the second domain, then it is likely that the Indexed Internet directory will be able to generate a referal to the appropriate domain, even though we initially started out with no direct information about that domain. For example, a directory ser- vice for a small Internet Service Provider (smallisp.com) might be maintained by a wider area Directory Service (bigldap.org) on a con- tract basis. Thus, the search for an LDAP service for smallisp.com might fail, but the ldap lookup to the Indexing Internet Directory would result in a referal to bigldap.com. What is more likely to be the case is that smallisp.com will create an SRV record for its LDAP service that points to bigldap.com. Note that this mechanism works regardless of the DIT structure. The DIT hierarchy can be built by making use of the traditional "O=" or "OU=" containers, or it can be built making use of alternative proposals along the lines of RFC 1279 [4]. This is due to the fact that the proposal assumes a particular DNS infrastructure rather than a particular X.500/LDAP infrastructure. 2. References [1] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)," RFC 2052, October 1996. [2] J. Allen, "The Common Indexing Protocol (CIP)," Internet Draft (work in progress) 19 November 1996. [3] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro- tocol", RFC 1777, March 1995. [4] S. Kille, "X.500 and Domains", RFC 1279, November 1991. Greenblatt [Page 3] Internet Draft July 1997 3. Author's Address Bruce Greenblatt Novell 2180 Fortune Drive San Jose, CA 95131 USA Phone: +1-408-577-7688 Fax: +1-408-577-7605 Email: bgg@novell.com Greenblatt [Page 4] --=====================_948278983==_ Content-Type: text/plain; charset="us-ascii" ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=====================_948278983==_-- From list@netscape.com Tue Jan 18 21:59: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 ESMTP id VAA09741 for ; Tue, 18 Jan 2000 21:59:00 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA20309; Tue, 18 Jan 2000 18:55:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA17325; Tue, 18 Jan 2000 18:57:57 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 18:57:57 -0800 (PST) Message-ID: <438D12915E64D2118AB10000F8C1C07802159995@zcard00e.ca.nortel.com> From: "James Benedict" To: Paul Leach , "RL 'Bob' Morgan" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 21:57:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6228.EE892A26" Resent-Message-ID: <"2RmD8.A.bOE.0gSh4"@glacier> 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_01BF6228.EE892A26 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Paul Leach [mailto:paulle@Exchange.Microsoft.com] > Sent: Tuesday, January 18, 2000 8:42 PM > To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt > Cc: ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > > -----Original Message----- > From: James Benedict [mailto:grunt@nortelnetworks.com] > Sent: Tuesday, January 18, 2000 7:31 AM > To: RL 'Bob' Morgan; Bruce Greenblatt > Cc: ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering > LDAP Services > with DNS > > > > The problem with this method is that the resolving client > must already > > have knowledge about the directory containing the DN. > Specificly, the > > resolving client must expect that the DC tree represented by the DN > > is a valid internet domain. > > This isn't strictly true. The client just guesses that the > "DC=" components > form a DNS name; if the guess is wrong, it will find out soon enough. > Agreed, but the value in making this computation is in having a high degree of confidence that it will be correct. What I am saying is that there is no real way of gaining a high degree of confidence without having prior knowledge of the directory service. > Since, as Bob points out, one is currently hosed if this > guess is wrong, the > incentive to make it be correct will be high. I think this is "a good > thing". > Agreed, to a point. I think that having a domain-based directory tree can be a good thing, in some cases, an OSI-based tree in others. What this solution requires is some sort of agreement around two assumptions: 1) That "Internet" LDAP DNs are arranged by domain component, and 2) The aforementioned domain components can, eventually, be resolved on the internet. (a third, and obvious assumption: that this form of discovery is supported) I just don't think these are all that practical. What I would suggest is to embed the DNS name of the Internet LDAP server in the DN, maybe as the root. Something like: cn=James Benedict, ou=sales, ou=employees, o=nortelnetworks, ldap=ldap.nortelnetworks.com or cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com Where ldap=ldap.nortelnetworks.com is an explicit reference to the DSN record you are trying to determine, regardless of how the company's actual DNS is structured. eg. ldap.nortelnetworks.com could be an alias for a firewall, which in turn, forwards port 387 to server1.dmz.nortelnetworks.com and server2.dmz.nortelnetworks.com. Both of which are replicas of ldap.us.nortelnetworks.com. Note that by providing an internal DNS record for ldap.nortelnetworks.com I can also use this discovery technique for internal and external resolution. This only requires one assumption: 1) The ldap= (or whatever attribute name makes sense) is resolvable Still a hefty assumption, but far less imposing. It doesn't constrain the DIT as much, and it allows the client to make one simple check (is ldap= in the DN) before it decides whether to use this resolution or not. > Paul > Anyways, just my $0.02 (or 0.0133333 $CDN :-) James A Benedict Advisor, IP Directory Systems Architecture Carrier Packet Solutions NORTEL NETWORKS Ph: (613) 763-3909 ------_=_NextPart_001_01BF6228.EE892A26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services = with DNS

> -----Original Message-----
> From: Paul Leach [mailto:paulle@Exchange.Mic= rosoft.com]
> Sent: Tuesday, January 18, 2000 8:42 PM
> To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' = Morgan; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: draft-ietf-ldapext-locate-01.txt - = Discovering LDAP
> Services with DNS
>
>
>
> -----Original Message-----
> From: James Benedict [mailto:grunt@nortelnetworks.com= ]
> Sent: Tuesday, January 18, 2000 7:31 AM
> To: RL 'Bob' Morgan; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: draft-ietf-ldapext-locate-01.txt - = Discovering
> LDAP Services
> with DNS
>
>
> > The problem with this method is that the = resolving client
> must already
> > have knowledge about the directory = containing the DN. 
> Specificly, the
> > resolving client must expect that the DC = tree represented by the DN
> > is a valid internet domain.
>
> This isn't strictly true. The client just = guesses that the
> "DC=3D" components
> form a DNS name; if the guess is wrong, it will = find out soon enough.
>
Agreed, but the value in making this computation is = in having a high degree
of confidence that it will be correct.  What I = am saying is that there is no
real way of gaining a high degree of confidence = without having prior knowledge
of the directory service.

> Since, as Bob points out, one is currently hosed = if this
> guess is wrong, the
> incentive to make it be correct will be high. I = think this is "a good
> thing".
>

Agreed, to a point.  I think that having a = domain-based directory tree can be a good thing, in some cases, an = OSI-based tree in others.  What this solution requires is some = sort of agreement around two assumptions:

1)  That "Internet" LDAP DNs are = arranged by domain component, and
2)  The aforementioned domain components can, = eventually, be resolved on
    the internet.

(a third, and obvious assumption:  that this = form of discovery is supported)

I just don't think these are all that = practical.  What I would suggest is to
embed the DNS name of the Internet LDAP server in = the DN, maybe as the root.
Something like:

cn=3DJames Benedict, ou=3Dsales, ou=3Demployees, = o=3Dnortelnetworks, ldap=3Dldap.nortelnetworks.com
or
cn=3DJames Benedict, ou=3Dsales, dc=3Dus, = dc=3Dnortelnetworks, dc=3Dcom

Where ldap=3Dldap.nortelnetworks.com is an explicit = reference to the DSN record
you are trying to determine, regardless of how the = company's actual DNS
is structured.

eg.  ldap.nortelnetworks.com could be an alias = for a firewall, which in turn,
forwards port 387 to server1.dmz.nortelnetworks.com = and server2.dmz.nortelnetworks.com.  Both of which are replicas of = ldap.us.nortelnetworks.com. 

Note that by providing an internal DNS record for = ldap.nortelnetworks.com I can also use this discovery technique for = internal and external resolution.

This only requires one assumption:

1) The ldap=3D<server> (or whatever attribute = name makes sense) is resolvable

Still a hefty assumption, but far less = imposing.  It doesn't constrain the DIT as much, and it allows the = client to make one simple check (is ldap=3D<whatever> in the DN) = before it decides whether to use this resolution or not.

> Paul
>

Anyways, just my $0.02 (or 0.0133333 $CDN :-)

James A Benedict
Advisor, IP Directory Systems Architecture
Carrier Packet Solutions
NORTEL NETWORKS
Ph:  (613) 763-3909

------_=_NextPart_001_01BF6228.EE892A26-- From list@netscape.com Tue Jan 18 22:25:47 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09884 for ; Tue, 18 Jan 2000 22:25:47 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id TAA22685; Tue, 18 Jan 2000 19:21:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA23878; Tue, 18 Jan 2000 19:24:41 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 19:24:41 -0800 (PST) Message-Id: <3.0.5.32.20000118192422.0092da00@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 18 Jan 2000 19:24:22 -0800 To: Paul Leach , ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <19398D273324D3118A2B0008C7E9A569051BED54@SIT.platinum.corp .microsoft.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_948281062==_" Resent-Message-ID: <"2BkrEC.A.o0F.35Sh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_948281062==_ Content-Type: text/plain; charset="us-ascii" At 07:12 PM 1/18/00 -0800, Paul Leach wrote: > >That's too long and bulky to say everywhere it currently says "native". > Maybe not. Attached is a fixed up version of the draft that doesn't use the term "native", removes some "noise", and says the same thing. > >Paul > > > --=====================_948281062==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ldapext-locate-01-revised.txt" INTERNET-DRAFT Michael P. Armijo Levon Esibov January, 2000 Paul Leach Expires: July, 2000 Microsoft Corporation Discovering LDAP Services with DNS 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. Distribution of this memo is unlimited. It is filed as , and expires on July 4, 2000. Please send comments to the authors. 1. Abstract This draft defines a way that LDAP servers can make use of the DNS's knowledge base to provide clients a method to resolve LDAP services for a given domain. 2. Introduction This draft builds on RFC 2247[2] to define a mechanism by which collections of LDAP servers can be integrated to create a directory service. That work supports this cause by defining a mapping from an LDAP DN to a DNS name that can be resolved to the address of a server holding the entry corresponding to the DN. For example, the DN "CN=Fred,OU=Eng,DC=example,DC=net" maps to the DNS name "example.net". This specification does not apply to LDAP servers that don't support RFC 2247 naming. In an Internet context, many of the names about which users seek information are DNS names, or include DNS names, such as email addresses. Widespread use of, and dependence on, LDAP services will require that they are robust and scalable. Both of these features are typically supported by replicated servers. Use of SRV records to locate LDAP servers supports clients' use of replicated servers. 3. Locating LDAP servers through DNS LDAP server location information is to be stored using DNS Service Location Record (SRV)[6]. The data in a SRV record contains the DNS name of the server that provides the LDAP service, corresponding Port number, and parameters that enable the client to choose an appropriate server from multiple servers according to the algorithm described in the SRV protocol[6]. The name of this record always has the following format: _._. where is always "ldap", is a protocol that can be either "udp" or "tcp", and is the domain hosted by the LDAP Server. Note that "ldap" is the symbolic name for the LDAP service in Assigned Numbers [7], as required by the SRV Protocol[6]. Presence of such records enables clients to find the LDAP servers using standard DNS query [3]. As an example, a client that searches for an LDAP server in the example.net domain that supports TCP protocol will submit a DNS query for a set of SRV records with owner name: _ldap._tcp.example.net. The client will receive the list of SRV records published in DNS that satisfy the requested criteria. The following is an example of such record: _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net. The set of returned records may contain multiple records in the case where multiple LDAP servers serve the same domain. 4. Security Considerations This document describes a method that uses DNS SRV records to discover LDAP servers. All security considerations related to DNS SRV records are inherited by this document. See the security considerations section in [6] for more details. 5. References [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol(v3)". RFC 2251, December 1997. [2] S. Kille, M. Wahl, "Using Domains in LDAP/X.500 Distinguished Names". RFC 2247, January 1998. [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES, November, 1987. [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION, November, 1987. [5] T. Howes, M. Smith, "The LDAP URL Format". RFC 2255 December 1997. [6] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)". http://www.ietf.org/internet-drafts/draft-ietf- dnsind-rfc2052bis-05.txt, November 1999. [7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, October 1994 6. Authors' Addresses Michael P. Armijo One Microsoft Way Redmond, WA 98052 micharm@microsoft.com Paul Leach One Microsoft Way Redmond, WA 98052 paulle@microsoft.com Levon Esibov One Microsoft Way Redmond, WA 98052 levone@microsoft.com Expires July, 2000 --=====================_948281062==_ Content-Type: text/plain; charset="us-ascii" ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=====================_948281062==_-- From list@netscape.com Tue Jan 18 22:27: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 ESMTP id WAA09895 for ; Tue, 18 Jan 2000 22:27:03 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id TAA23232; Tue, 18 Jan 2000 19:23:11 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA24769; Tue, 18 Jan 2000 19:26:00 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 19:26:00 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED54@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Bruce Greenblatt'" , ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 19:12:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"5CNLWB.A.vCG.H7Sh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Tuesday, January 18, 2000 6:50 PM > To: Paul Leach; ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > At 05:33 PM 1/18/00 -0800, Paul Leach wrote: > > > > > >> -----Original Message----- > >> From: Bruce Greenblatt > [mailto:bgreenblatt@directory-applications.com] > >> Sent: Monday, January 17, 2000 4:36 PM > >> To: ietf-ldapext@netscape.com > >> Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > >> Services with DNS > >> > >> > >> I don't understand (or necessarily agree with) the first two > >> paragraphs of > >> this draft. What difference does it make to this mechanism > >> what a "native" > >> LDAP server is? > > > >We needed a word to describe servers whose NCs have DNs that > start with a > >series of "DC=" components. Ones that don't have such names > for their NCs > >are using the X.500 naming model with LDAP front ends -- those are > >"X.500-ish" LDAP servers. > > > > OK. The draft should drop the use of "native", and just say that it > applies to LDAP servers that have standardiz(s)ed on the "DC" > naming RFC. That's too long and bulky to say everywhere it currently says "native". I don't see what's wrong with "native" -- it means that they aren't a front end to X.500. Hence they can't use X.500 capabilities, and clients can expect service that requires those capabilities. In some cases, that means both clients and servers are out of luck -- clients have to apriori know the DNS name of the server that stores a given DN, and a server that recieves a request for a DN in an NC it doesn't store can't generate a referral. However, if the DN starts with "DC=", then things can be better if they follow the proposal in the draft: the client can get to a server, or a server given a request for such a DN can generate a referral. All the server has to do is get SRV records registered for the NCs it stores -- ones that are resolvable by all the clients it cares to serve. Paul From list@netscape.com Tue Jan 18 22:40:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10921 for ; Tue, 18 Jan 2000 22:40:56 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id TAA24687; Tue, 18 Jan 2000 19:37:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA27922; Tue, 18 Jan 2000 19:39:52 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 19:39:52 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED55@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'James Benedict'" , "RL 'Bob' Morgan" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 19:30:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"2JARjC.A.A0G.IITh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com -----Original Message----- From: James Benedict [mailto:grunt@nortelnetworks.com] Sent: Tuesday, January 18, 2000 6:58 PM To: Paul Leach; RL 'Bob' Morgan; Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS > Agreed, but the value in making this computation is in having a high degree > of confidence that it will be correct. What I am saying is that there is no > real way of gaining a high degree of confidence without having prior knowledge > of the directory service. It does not require prior knowledge about any one server -- just that enough servers use the scheme to make it worthwhile to try -- since the alternative is a _hard_ requirement for prior knowledge -- of the DNS name of the server. >> Since, as Bob points out, one is currently hosed if this >> guess is wrong, the >> incentive to make it be correct will be high. I think this is "a good >> thing". > > Agreed, to a point. I think that having a domain-based directory tree can be a good thing, in some cases, an OSI-based tree in others. I wasn't making any statement at all in that regard. I was saying that the fact there was incentive to register the SRV records is a good thing. > What this solution requires is some sort of agreement around two assumptions: > 1) That "Internet" LDAP DNs are arranged by domain component, and No, it does not depend on any such agreement. It _allows_ _some_ people to so arrange their DNs. In exchange, it lets them get resolved, without requiring prior knowledge of the DNS name of the server holding the DN. I think that that's a powerful incentive, enough to cause its use to be widespread. > 2) The aforementioned domain components can, eventually, be resolved on the internet. > (a third, and obvious assumption: that this form of discovery is supported) > I just don't think these are all that practical. Seems easy, to me. > What I would suggest is to > embed the DNS name of the Internet LDAP server in the DN, maybe as the root. > Something like: > cn=James Benedict, ou=sales, ou=employees, o=nortelnetworks, ldap=ldap.nortelnetworks.com Unfortunately, "ldap=" is not a legal DN component. It took RFC 2247 to make "dc=" a legal DN component. We went through these kinds of alternatives in the process of coming up with the current proposal. Paul From list@netscape.com Tue Jan 18 22:42:09 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10939 for ; Tue, 18 Jan 2000 22:42:08 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id TAA14825; Tue, 18 Jan 2000 19:39:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA28796; Tue, 18 Jan 2000 19:41:05 -0800 (PST) Resent-Date: Tue, 18 Jan 2000 19:41:05 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED56@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Bruce Greenblatt'" , ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Tue, 18 Jan 2000 19:36:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"XeLgMC.A.qBH.QJTh4"@glacier> 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 really dislike specs that present solutions without describing the problem being solved. > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Tuesday, January 18, 2000 7:24 PM > To: Paul Leach; ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > At 07:12 PM 1/18/00 -0800, Paul Leach wrote: > > > >That's too long and bulky to say everywhere it currently > says "native". > > > > Maybe not. Attached is a fixed up version of the draft that > doesn't use the > term "native", removes some "noise", and says the same thing. > > > >Paul > > > > > > > From list@netscape.com Wed Jan 19 09:22:39 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29230 for ; Wed, 19 Jan 2000 09:22:38 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA19247; Wed, 19 Jan 2000 06:20:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA10835; Wed, 19 Jan 2000 06:21:25 -0800 (PST) Resent-Date: Wed, 19 Jan 2000 06:21:25 -0800 (PST) Message-ID: <438D12915E64D2118AB10000F8C1C078021599F4@zcard00e.ca.nortel.com> From: "James Benedict" To: Paul Leach , "RL 'Bob' Morgan" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Wed, 19 Jan 2000 09:20:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6288.5F91C048" Resent-Message-ID: <"gdynDC.A.zoC.khch4"@glacier> 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_01BF6288.5F91C048 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Paul Leach [mailto:paulle@Exchange.Microsoft.com] > Sent: Tuesday, January 18, 2000 10:30 PM > To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt > Cc: ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > ... > > What this solution requires is some sort of agreement around two > assumptions: > > 1) That "Internet" LDAP DNs are arranged by domain component, and > > No, it does not depend on any such agreement. > It _allows_some_ people to These words make me cringe when I hear them. Anything that is designed to "allow some" people to do something implies that "other" people will be doing something else. This doesn't speak well for convergence of directory applications. Having said that: I understand, and accept, the fact that LDAP directories will always be "slightly" different, and will likely require a multitude of service discovery methods. I not sure see this approach as being usefull on the "Internet" as much as in an "Intranet". If I use a dc-structure, it is more likely to reflect my internal domain structure, unless my directory is real small. It does raise the question of whether I would *actually* expose that directory tree to the Internet or not... I guess my real problem with this particular method is the fact that the client never really has any confidence until it queries DNS. I would suggest an addendum to the draft that "recommends" that "Internet" directories arranged with a dc-tree provide some sort of LDAP service that can be resolved at some point by walking up the tree. eg. cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com Maybe I don't want to make _ldap._tcp.us.nortelnetworks.com and _ldap._tcp.uk.nortelnetworks.com, etc. visible to the Internet, but _ldap._tcp.nortelnetworks.com wouldn't be too bad. It would have for us a while ago when we went from nt.com to nortelnetworks.com externally first, then internally. But that could be solved with an alias. --james James A Benedict Advisor, IP Directory Systems Architecture Carrier Packet Solutions NORTEL NETWORKS Ph: (613) 763-3909 ------_=_NextPart_001_01BF6288.5F91C048 Content-Type: text/html; charset="iso-8859-1" RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS

> -----Original Message-----
> From: Paul Leach [mailto:paulle@Exchange.Microsoft.com]
> Sent: Tuesday, January 18, 2000 10:30 PM
> To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
>
...
> > What this solution requires is some sort of agreement around two
> assumptions:
> > 1)  That "Internet" LDAP DNs are arranged by domain component, and
>
> No, it does not depend on any such agreement.

> It _allows_some_ people to

These words make me cringe when I hear them.  Anything that is designed
to "allow some" people to do something implies that "other" people will
be doing something else.  This doesn't speak well for convergence of
directory applications.

Having said that:  I understand, and accept, the fact that LDAP
directories will always be "slightly" different, and will likely
require a multitude of service discovery methods.

I not sure see this approach as being usefull on the "Internet" as
much as in an "Intranet".  If I use a dc-structure, it is more likely
to reflect my internal domain structure, unless my directory is real
small.  It does raise the question of whether I would *actually* expose
that directory tree to the Internet or not...

I guess my real problem with this particular method is the fact that
the client never really has any confidence until it queries DNS.

I would suggest an addendum to the draft that "recommends" that "Internet"
directories arranged with a dc-tree provide some sort of LDAP service
that can be resolved at some point by walking up the tree.  eg.

cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com

Maybe I don't want to make _ldap._tcp.us.nortelnetworks.com and
_ldap._tcp.uk.nortelnetworks.com, etc. visible to the Internet, but
_ldap._tcp.nortelnetworks.com wouldn't be too bad. It would have for
us a while ago when we went from nt.com to nortelnetworks.com externally
first, then internally.  But that could be solved with an alias.

--james
James A Benedict
Advisor, IP Directory Systems Architecture
Carrier Packet Solutions
NORTEL NETWORKS
Ph:  (613) 763-3909

------_=_NextPart_001_01BF6288.5F91C048-- From list@netscape.com Wed Jan 19 10:56: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 ESMTP id KAA01047 for ; Wed, 19 Jan 2000 10:56:42 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA07040; Wed, 19 Jan 2000 07:52:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA15659; Wed, 19 Jan 2000 07:55:37 -0800 (PST) Resent-Date: Wed, 19 Jan 2000 07:55:37 -0800 (PST) X-Envelope-Sender-Is: teodor.dumitrescu@icn.siemens.de (at relayer david.siemens.de) Message-ID: From: "Dumitrescu, Teodor" To: "'Paul Leach'" , "'Bruce Greenblatt'" , ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Wed, 19 Jan 2000 16:55:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"39A8RC.A.J0D.x5dh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Paul, I wasn't aware that "native" means non-X.500. And for the purpose of this discussion the X.500 LDAP front ends do support DC= naming components. In fact they are/should be indistinguishable over the wire from "native" servers. Teo > -----Original Message----- > From: Paul Leach [mailto:paulle@Exchange.Microsoft.com] > Sent: Mittwoch, 19. Januar 2000 04:13 > To: 'Bruce Greenblatt'; ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > .... > > > That's too long and bulky to say everywhere it currently says > "native". > > I don't see what's wrong with "native" -- it means that they > aren't a front > end to X.500. Hence they can't use X.500 capabilities, and clients can > expect service that requires those capabilities. In some > cases, that means > both clients and servers are out of luck -- clients have to > apriori know the > DNS name of the server that stores a given DN, and a server > that recieves a > request for a DN in an NC it doesn't store can't generate a referral. > > However, if the DN starts with "DC=", then things can be > better if they > follow the proposal in the draft: the client can get to a server, or a > server given a request for such a DN can generate a referral. > All the server > has to do is get SRV records registered for the NCs it stores > -- ones that > are resolvable by all the clients it cares to serve. > > Paul > From list@netscape.com Wed Jan 19 11:18:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01347 for ; Wed, 19 Jan 2000 11:18:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA01699; Wed, 19 Jan 2000 08:15:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA22036; Wed, 19 Jan 2000 08:16:59 -0800 (PST) Resent-Date: Wed, 19 Jan 2000 08:16:59 -0800 (PST) From: "Alexis Bor" To: "Dumitrescu, Teodor" , "'Paul Leach'" , "'Bruce Greenblatt'" , Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Wed, 19 Jan 2000 08:15:53 -0800 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Resent-Message-ID: <"pPfXd.A.AYF.6Neh4"@glacier> 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 all gets back to the forgotten history. LDAP is an interface. The 'back ends' vary from implementation to implementation. To name a few, there are Oracle, Exchange, Jet, Ingress, DB2, and many less known brands of database engines as well as proprietary stores. In fact, how about the old QUIPU use of disk file systems. The major change that happened quite a few years ago was that Tim Howes and others added a mechanism to LDAP for a locally defined data store rather than translate LDAP queries into DAP protocol. When the marketing people got involved (around the time of the Netscape press release on 40 companies jumping on the LDAP bandwagon), suddenly LDAP became all things for all people. It should all come back to the question - does the product support LDAP or does it not. I used to pound on Novell about calling NDS "X.500-like" - I used to always compare it to calling a woman pregnant-like. Either you are LDAP compliant or you are not. It's that simple!!! Let's keep religion and the influence of marketing hype out of this, if at all possible. Let's avoid this native versus native-like comparison, please!!! -- Alexis Alexis Bor Directory Works, Inc. P.O. Box 470276 Celebration, FL 34747-0276 alexis.bor@directoryworks.com -----Original Message----- From: Dumitrescu, Teodor [mailto:teodor.dumitrescu@icn.siemens.de] Sent: Wednesday, January 19, 2000 7:55 AM To: 'Paul Leach'; 'Bruce Greenblatt'; ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Paul, I wasn't aware that "native" means non-X.500. And for the purpose of this discussion the X.500 LDAP front ends do support DC= naming components. In fact they are/should be indistinguishable over the wire from "native" servers. Teo > -----Original Message----- > From: Paul Leach [mailto:paulle@Exchange.Microsoft.com] > Sent: Mittwoch, 19. Januar 2000 04:13 > To: 'Bruce Greenblatt'; ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > .... > > > That's too long and bulky to say everywhere it currently says > "native". > > I don't see what's wrong with "native" -- it means that they > aren't a front > end to X.500. Hence they can't use X.500 capabilities, and clients can > expect service that requires those capabilities. In some > cases, that means > both clients and servers are out of luck -- clients have to > apriori know the > DNS name of the server that stores a given DN, and a server > that recieves a > request for a DN in an NC it doesn't store can't generate a referral. > > However, if the DN starts with "DC=", then things can be > better if they > follow the proposal in the draft: the client can get to a server, or a > server given a request for such a DN can generate a referral. > All the server > has to do is get SRV records registered for the NCs it stores > -- ones that > are resolvable by all the clients it cares to serve. > > Paul > From list@netscape.com Wed Jan 19 13:48:31 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03332 for ; Wed, 19 Jan 2000 13:48:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA00435; Wed, 19 Jan 2000 10:44:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA29227; Wed, 19 Jan 2000 10:46:51 -0800 (PST) Resent-Date: Wed, 19 Jan 2000 10:46:51 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED58@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Dumitrescu, Teodor'" , ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Wed, 19 Jan 2000 10:39:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"F_20M.A.ZIH.bagh4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > -----Original Message----- > From: Dumitrescu, Teodor [mailto:teodor.dumitrescu@icn.siemens.de] > Sent: Wednesday, January 19, 2000 7:55 AM > To: Paul Leach; 'Bruce Greenblatt'; ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > Paul, > > I wasn't aware that "native" means non-X.500. And for the > purpose of this > discussion the X.500 LDAP front ends do support DC= naming > components. In > fact they are/should be indistinguishable over the wire from "native" > servers. It's a fairly typical way of using the term "native" in the computer industry. As I noted, there is a difference, at least internally -- a "native" LDAP directory does not enjoy the advantage of powerful knowledge management inherent in the X.500 directory. Hence, DN resolution presents a problem -- no X.500 knowledge with which to generate referrals. On the wire, they would be indistinguishable in the case that the client had prior knowledge of the DNS name of the server holding the DN it wished to resolve. Paul From list@netscape.com Wed Jan 19 14:02:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03582 for ; Wed, 19 Jan 2000 14:02:16 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA03319; Wed, 19 Jan 2000 10:58:19 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA05466; Wed, 19 Jan 2000 11:01:10 -0800 (PST) Resent-Date: Wed, 19 Jan 2000 11:01:10 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED57@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'James Benedict'" , "RL 'Bob' Morgan" , Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Wed, 19 Jan 2000 10:31:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF62AB.70B56DF2" Resent-Message-ID: <"-uUgiC.A.iUB.zngh4"@glacier> 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_01BF62AB.70B56DF2 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: James Benedict [mailto:grunt@nortelnetworks.com] Sent: Wednesday, January 19, 2000 6:21 AM To: Paul Leach; RL 'Bob' Morgan; Bruce Greenblatt Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS > -----Original Message----- > From: Paul Leach [ mailto:paulle@Exchange.Microsoft.com ] > Sent: Tuesday, January 18, 2000 10:30 PM > To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt > Cc: ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > ... > > What this solution requires is some sort of agreement around two > assumptions: > > 1) That "Internet" LDAP DNs are arranged by domain component, and > > No, it does not depend on any such agreement. > It _allows_some_ people to These words make me cringe when I hear them. Anything that is designed to "allow some" people to do something implies that "other" people will be doing something else. This doesn't speak well for convergence of directory applications. [Paul Leach] People who choose to use "O=Foo,C=Bar" as their name form have to do _something_ else. If I knew what they could do, I'd make a proposal --e xcept that if I did, I'd run into an incredible political tarpit -- many people have tried in the past, and no one has suceeded. People who choose to use "dc=example,dc=com" and don't want to use the proposed mechanism -- well, I think that's what it was designed for (but you'd have to ask Steve Kille and Mark Wahl to be sure), so I don't know why they wouldn't want to use it. But they don't _have_ to. In fact, for backwards compatibility, the ability to use prior knowledge of the DNS name of the server holding the DN is required -- so in that sense, too, the "native" proposal is only "allowed". But, to address your fears -- there isn't an alternate way to do the same thing as the draft proposes. But it isn't required that everyone deploy it in order to make it useful. [Paul Leach] I would suggest an addendum to the draft that "recommends" that "Internet" directories arranged with a dc-tree provide some sort of LDAP service that can be resolved at some point by walking up the tree. eg. cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com Maybe I don't want to make _ldap._tcp.us.nortelnetworks.com and _ldap._tcp.uk.nortelnetworks.com, etc. visible to the Internet, but _ldap._tcp.nortelnetworks.com wouldn't be too bad. It would have for us a while ago when we went from nt.com to nortelnetworks.com externally first, then internally. But that could be solved with an alias. [Paul Leach] That's what I thought, too. Since it was easy to solve with an alias, I thought "why complicate things? Use the DNS mechansim that exists". Paul ------_=_NextPart_001_01BF62AB.70B56DF2 Content-Type: text/html; charset="iso-8859-1" RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS
 
-----Original Message-----
From: James Benedict [mailto:grunt@nortelnetworks.com]
Sent: Wednesday, January 19, 2000 6:21 AM
To: Paul Leach; RL 'Bob' Morgan; Bruce Greenblatt
Cc: ietf-ldapext@netscape.com
Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS



> -----Original Message-----
> From: Paul Leach [mailto:paulle@Exchange.Microsoft.com]
> Sent: Tuesday, January 18, 2000 10:30 PM
> To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
>
...
> > What this solution requires is some sort of agreement around two
> assumptions:
> > 1)  That "Internet" LDAP DNs are arranged by domain component, and
>
> No, it does not depend on any such agreement.

> It _allows_some_ people to

These words make me cringe when I hear them.  Anything that is designed
to "allow some" people to do something implies that "other" people will
be doing something else.  This doesn't speak well for convergence of
directory applications.
[Paul Leach] People who choose to use "O=Foo,C=Bar" as their name form have to do _something_ else. If I knew what they could do, I'd make a proposal --e xcept that if I did, I'd run into an incredible political tarpit -- many people have tried in the past, and no one has suceeded. People who choose to use "dc=example,dc=com" and don't want to use the proposed mechanism -- well, I think that's what it was designed for (but you'd have to ask Steve Kille and Mark Wahl to be sure), so I don't know why they wouldn't want to use it. But they don't _have_ to. In fact, for backwards compatibility, the ability to use prior knowledge of the DNS name of the server holding the DN is required -- so in that sense, too, the "native" proposal is only "allowed".

But, to address your fears -- there isn't an alternate way to do the same thing as the draft proposes. But it isn't required that everyone deploy it in order to make it useful.

[Paul Leach] <snip>

 I would suggest an addendum to the draft that "recommends" that "Internet"
directories arranged with a dc-tree provide some sort of LDAP service
that can be resolved at some point by walking up the tree.  eg.

cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com

Maybe I don't want to make _ldap._tcp.us.nortelnetworks.com and
_ldap._tcp.uk.nortelnetworks.com, etc. visible to the Internet, but
_ldap._tcp.nortelnetworks.com wouldn't be too bad. It would have for
us a while ago when we went from nt.com to nortelnetworks.com externally
first, then internally.  But that could be solved with an alias.
[Paul Leach] That's what I thought, too. Since it was easy to solve with an alias, I thought "why complicate things? Use the DNS mechansim that exists".

Paul

------_=_NextPart_001_01BF62AB.70B56DF2-- From list@netscape.com Wed Jan 19 19:31:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06795 for ; Wed, 19 Jan 2000 19:31:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA20874; Wed, 19 Jan 2000 16:29:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA10080; Wed, 19 Jan 2000 16:30:43 -0800 (PST) Resent-Date: Wed, 19 Jan 2000 16:30:43 -0800 (PST) Message-Id: <3.0.5.32.20000119162934.00923100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 19 Jan 2000 16:29:34 -0800 To: "'James Benedict'" From: "Kurt D. Zeilenga" Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Cc: "RL 'Bob' Morgan" , Bruce Greenblatt , ietf-ldapext@netscape.com In-Reply-To: <19398D273324D3118A2B0008C7E9A569051BED57@SIT.platinum.corp .microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"w-ViFC.A._cC.yclh4"@glacier> 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:31 AM 1/19/00 -0800, James Benedict wrote: > I would suggest an addendum to the draft that "recommends" that "Internet" > directories arranged with a dc-tree provide some sort of LDAP service > that can be resolved at some point by walking up the tree. eg. I disagree... The algorithm should be simple and require no LDAP nor DNS tree walking. An DN of: cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com is associated with the domain "us.nortelnetworks.com". If SRV RRs are not available at "_ldap._tcp.us.nortelnetworks.com", the application should not attempt further SRV based discovery. If walking were to be required (or even allowed) then we must describe how far up the DNS tree a client should walk... I think it's a real bad idea to walk up to national SLD, TLDs, or . Kurt From list@netscape.com Thu Jan 20 14:12:22 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12474 for ; Thu, 20 Jan 2000 14:12:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA29675; Thu, 20 Jan 2000 11:09:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA21335; Thu, 20 Jan 2000 11:11:12 -0800 (PST) Resent-Date: Thu, 20 Jan 2000 11:11:12 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Thu, 20 Jan 2000 10:40:55 -0800 (PST) From: "RL 'Bob' Morgan" Reply-To: "RL 'Bob' Morgan" To: Paul Leach cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS In-Reply-To: <19398D273324D3118A2B0008C7E9A569051BED54@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"3XB_k.A.AMF.K31h4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Paul: > I really dislike specs that present solutions without describing the > problem being solved. Sure, but you have to define the "problem" at the right level. A problem description that spends two paragraphs on issues that need a lengthy document to adequately describe them creates more confusion than enlightenment. RFC 2247, as one example, scopes its problem description appropriately IMHO. This doc is about a particular method to determine servers based on DNs. Presumably this method is interesting to the extent that other methods don't meet particular requirements. I suggest that a description of the range of requirements and possible solutions, so as to explain how this one fits in, is way beyond the scope of this doc. Even the taxonomy doc, which attempts to cover more of this territory, doesn't do enough IMHO. This is why there still needs to be a LSD working group ... > I don't see what's wrong with "native" -- it means that they aren't a > front end to X.500. Hence they can't use X.500 capabilities, and > clients can expect service that requires those capabilities. In some > cases, that means both clients and servers are out of luck -- clients > have to apriori know the DNS name of the server that stores a given > DN, and a server that recieves a request for a DN in an NC it doesn't > store can't generate a referral. This use of "native" may be useful for some purpose, but I think it's not particularly relevant to the mechanism being specified. What the doc is trying to express by "a front end to the X.500 directory service" is more precisely the use of the method of embedding knowledge references in the DIT to glue together DSAs. The DNS-based mechanism is obviously being offered as an alternative to this. But this really isn't a X.500/not-X.500 distinction. In practice there is no worldwide X.500 Directory based on civil naming or any other naming, so real X.500 DSAs are glued together into communities of only local scope (possibly national in some cases; can any X.500-knowledgable people comment on the status of this?). So even a X.500-capable DSA that uses some DIT-based glue might find the DNS-based mechanism useful if it allows it to discover servers for NCs that it couldn't otherwise. Conversely, despite the methods not really being standardized, in practice people do use embedded knowledge references to glue together LDAP-only DSAs; the DNS-based method might appeal to them also. So here's the pitch: (1) you need to glue together DSAs somehow (2) doing this with records in the DIT is possible, but hasn't yet proven effective globally (3) DNS SRV records can be used for this (4) this takes advantage of globally-deployed DNS (5) it only works (so far) for directory objects with DNS-based names, but that's OK since we're already familiar with DNS-based names. I could write this up more formally ... 8^) I'll note in passing that though this method is only defined for DC-based DNs at this point, it's possible to imagine mapping civil-name-style DNs to DNS labels (under some traditionally-named domain(s)) and hence using SRV records to find them too. - RL "Bob" From list@netscape.com Thu Jan 20 15:48:59 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15045 for ; Thu, 20 Jan 2000 15:48:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA16167; Thu, 20 Jan 2000 12:46:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA15335; Thu, 20 Jan 2000 12:48:03 -0800 (PST) Resent-Date: Thu, 20 Jan 2000 12:48:03 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED75@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'RL 'Bob' Morgan'" Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Thu, 20 Jan 2000 12:00:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"Kr1Dv.A.IvD.CS3h4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > -----Original Message----- > From: RL 'Bob' Morgan [mailto:rlmorgan@cac.washington.edu] > Sent: Thursday, January 20, 2000 10:41 AM > To: Paul Leach > Cc: ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > Paul: > > > So here's the pitch: > > (1) you need to glue together DSAs somehow > (2) doing this with records in the DIT is possible, but hasn't yet > proven effective globally > (3) DNS SRV records can be used for this > (4) this takes advantage of globally-deployed DNS > (5) it only works (so far) for directory objects with > DNS-based names, > but that's OK since we're already familiar with > DNS-based names. I agree with all this. > > I could write this up more formally ... 8^) I'd be happy for you to do so. > > I'll note in passing that though this method is only defined > for DC-based > DNs at this point, it's possible to imagine mapping > civil-name-style DNs > to DNS labels (under some traditionally-named domain(s)) and > hence using > SRV records to find them too. Indeed. I'd be happy if someone made a proposal to do that, as well. Paul From list@netscape.com Thu Jan 20 17:55:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16633 for ; Thu, 20 Jan 2000 17:55:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA01504; Thu, 20 Jan 2000 14:51:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA09021; Thu, 20 Jan 2000 14:54:40 -0800 (PST) Resent-Date: Thu, 20 Jan 2000 14:54:40 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 20 Jan 2000 15:54:27 -0700 From: "Steven Merrill" To: "<" Subject: Java API draft suggestion Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"Dgdu0.A.rMC.vI5h4"@glacier> 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA16633 In section 4.13 (LDAPException) of "draft-ietf-ldapext-ldap-java-api-09.txt", an accessor method is specified in section 4.13.5 (getMatchedDN) for retrieving a matchedDN. The problem is, we lack a constructor or a mutator method for setting the matchedDN value. I'd like to see a constructor added to the draft for LDAPException that would allow an implementation to set this value. Steve Merrill Novell, Inc. From list@netscape.com Thu Jan 20 22:00:29 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19563 for ; Thu, 20 Jan 2000 22:00:14 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA25551; Thu, 20 Jan 2000 18:56:12 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA26678; Thu, 20 Jan 2000 18:59:05 -0800 (PST) Resent-Date: Thu, 20 Jan 2000 18:59:05 -0800 (PST) Message-Id: <3.0.5.32.20000120185821.00926d20@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Jan 2000 18:58:21 -0800 To: "RL 'Bob' Morgan" , Paul Leach From: Bruce Greenblatt Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Cc: ietf-ldapext@netscape.com In-Reply-To: References: <19398D273324D3118A2B0008C7E9A569051BED54@SIT.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ohXB8D.A.ZgG.4t8h4"@glacier> 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:40 AM 1/20/00 -0800, RL 'Bob' Morgan wrote: [snip] >So here's the pitch: > > (1) you need to glue together DSAs somehow > (2) doing this with records in the DIT is possible, but hasn't yet > proven effective globally > (3) DNS SRV records can be used for this > (4) this takes advantage of globally-deployed DNS > (5) it only works (so far) for directory objects with DNS-based names, > but that's OK since we're already familiar with DNS-based names. > As far as I can tell this isn't correct. This draft doesn't "glue" LDAP servers together. It presents an algorithm that helps you find one LDAP server that will probably have an entry for the DN that you have. So, here's my pitch (1) Sometimes you get a DN from places other than the LDAP server in which the DN lives (2) You need to find the LDAP server to get some other information about the entry to which the DN refers, e.g. email address (3)-(5) see above... Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Fri Jan 21 04:13:50 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05648 for ; Fri, 21 Jan 2000 04:13:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id BAA15097; Fri, 21 Jan 2000 01:09:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id BAA26232; Fri, 21 Jan 2000 01:12:45 -0800 (PST) Resent-Date: Fri, 21 Jan 2000 01:12:45 -0800 (PST) Message-ID: <19398D273324D3118A2B0008C7E9A569051BED81@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Bruce Greenblatt'" , "RL 'Bob' Morgan" , Paul Leach Cc: ietf-ldapext@netscape.com Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS Date: Fri, 21 Jan 2000 01:12:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"pvzv3B.A.mZG.MMCi4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Thursday, January 20, 2000 6:58 PM > To: RL 'Bob' Morgan; Paul Leach > Cc: ietf-ldapext@netscape.com > Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP > Services with DNS > > > At 10:40 AM 1/20/00 -0800, RL 'Bob' Morgan wrote: > [snip] > >So here's the pitch: > > > > (1) you need to glue together DSAs somehow > > (2) doing this with records in the DIT is possible, but hasn't yet > > proven effective globally > > (3) DNS SRV records can be used for this > > (4) this takes advantage of globally-deployed DNS > > (5) it only works (so far) for directory objects with > DNS-based names, > > but that's OK since we're already familiar with > DNS-based names. > > > > As far as I can tell this isn't correct. This draft doesn't > "glue" LDAP > servers together. It presents an algorithm that helps you > find one LDAP > server that will probably have an entry for the DN that you have. So, > here's my pitch If an LDAP server for DC=example1,DC=com got a request for DC=example2,DC=com, the draft also lets it generate a referall to the right server. That's the sense in which it glues servers together. Paul From list@netscape.com Sat Jan 22 03:34:24 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06839 for ; Sat, 22 Jan 2000 03:34:19 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA04440; Sat, 22 Jan 2000 00:31:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA14588; Sat, 22 Jan 2000 00:32:40 -0800 (PST) Resent-Date: Sat, 22 Jan 2000 00:32:40 -0800 (PST) From: daywatch@mailroom.com Message-Id: <200001220832.AAA04778@ywing.netscape.com> Subject: -=+FREE! Investor Newsletter+=- Date: Sat, 22 Jan 2000 00:03:21 Resent-Message-ID: <"7yBaKD.A.6iD.lsWi4"@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 ...... -This is not SPAM. We are not selling anything, but rather are here to offer you a FREE NEWSLETTER SUBSCRIPTION to: ==========The StockTech Express========== You may UNSUBSCRIBE at any time. This can be done by following the unsubscribe instructions at the bottom of this page. The Stocktech Express is a FREE independent service that sends you timely advice and solid recommendations on companies with tremendous capital gains potential. We search North America and around the globe for emerging stocks that have the potential and the expertise to give substantial ROI (return on investment). Our goal is to showcase these companies and prove that even in emerging markets, tremendous profits can be found. The StockTech Express is a FREE indispensable source of trading information. we deliver twice daily. First, a midday update which will inform you of breaking news, and the days outlook. Second, a closing accurate read of your business day and perspectives on the upcoming day in trading. Finally, The weekend market rap on Saturday . Which will cover a variety of updates, such as the latest and greatest in technology and other emerging markets. The StockTech Express provides you with FREE information that is crucial to every successful investment strategy: financial analysis that is current, insightful and honest. With StockTech you get uncompromising, objective commentary from some of the premier journalistic minds in the industry today. The proof is in the print, you decide! All instructions below. DO NOT FORGET TO SHARE THIS WITH YOUR FRIENDS. ============ To receive your FREE SUBSCRIPTION to The Stock Tech Express: [ mailto:daywatch@beer.com?subject=newsletter ] you may unsubscribe at any time. ============ To UNSUBSCRIBE OR BE PLACED IN OUR "PERMANENT REMOVE DATABASE". [ mailto:daywatch@mailroom.com?subject=UNSUBSCRIBE ] WE HONOR ALL REMOVE REQUESTS. * From list@netscape.com Sun Jan 23 18:58:37 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12520 for ; Sun, 23 Jan 2000 18:58:37 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA00213; Sun, 23 Jan 2000 15:54:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA05180; Sun, 23 Jan 2000 15:57:23 -0800 (PST) Resent-Date: Sun, 23 Jan 2000 15:57:23 -0800 (PST) From: 01092000@mycampus.com To: any5one@gte.net Subject: Opportunity Knocks!!!!!!! MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on ggnotes01/Ggtech(Release 5.0.2a |November 23, 1999) at 01/23/2000 05:49:39 PM, Serialize by Router on ggnotes01/Ggtech(Release 5.0.2a |November 23, 1999) at 01/23/2000 05:49:58 PM, Serialize complete at 01/23/2000 05:49:58 PM Date: Sun, 23 Jan 2000 17:49:39 -0600 Message-ID: Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"_L51O.A.ZQB.fV5i4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... We're searching for only 10 elite individuals with the work thic necessary to generate a cash-flow for themselves of $2,000 - 5,000 per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income! Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.) Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme? If you would like to build an amazing income that will grow lightning-fast and have you profit $1,100.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need. Call NOW our TOLL FREE, PRE-RECORDED Message:1-888-780-7191 We market a real product, that pays real commissions to you, $1,100.00 per sale, just for making the initial contacts. With our turnkey lead generation systems you'll always talk to people who actually WANT to talk to you. You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now! The call is FREE, and there is absolutely no obligation, So what have you got to lose? Call Toll Free 1-888-780-7191 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. To be removed from our mailing list please reply to this email and put remove in the subject. From list@netscape.com Mon Jan 24 16:46:39 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25980 for ; Mon, 24 Jan 2000 16:46:38 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA09495; Mon, 24 Jan 2000 13:42:11 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA29399; Mon, 24 Jan 2000 13:45:11 -0800 (PST) Resent-Date: Mon, 24 Jan 2000 13:45:11 -0800 (PST) Message-Id: <200001242145.QAA25885@ietf.org> To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: The IESG SUBJECT: Last Call: LDAP Control Extension for Server Side Sorting of Search Results to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 24 Jan 2000 16:45:01 -0500 Sender: scoya@cnri.reston.va.us Resent-Message-ID: <"vv22TC.A.nKH.lfMj4"@glacier> 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 IESG has received a request from the The Wahoo Working Group Working Group to consider LDAP Control Extension for Server Side Sorting of Search Results as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 7, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ldapext-sorting-02.txt From list@netscape.com Mon Jan 24 17:20:12 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27228 for ; Mon, 24 Jan 2000 17:20:10 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA15519; Mon, 24 Jan 2000 14:16:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA17426; Mon, 24 Jan 2000 14:18:54 -0800 (PST) Resent-Date: Mon, 24 Jan 2000 14:18:54 -0800 (PST) Message-Id: <200001242218.RAA27174@ietf.org> To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: The IESG SUBJECT: Last Call: LDAP Control Extension for Server Side Sorting of Search Results to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 24 Jan 2000 17:18:46 -0500 Sender: scoya@cnri.reston.va.us Resent-Message-ID: <"1UMQYB.A.1PE.N_Mj4"@glacier> 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 retransmisson of the Last Call announcement, this time with the correct Working Group. The IESG has received a request from the LDAP Extensions Working Group to consider LDAP Control Extension for Server Side Sorting of Search Results as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 7, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ldapext-sorting-02.txt From list@netscape.com Thu Jan 27 16:25:48 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15084 for ; Thu, 27 Jan 2000 16:25:46 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA05859; Thu, 27 Jan 2000 13:21:27 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA08468; Thu, 27 Jan 2000 13:24:32 -0800 (PST) Resent-Date: Thu, 27 Jan 2000 13:24:32 -0800 (PST) From: mike8@2891xxbecker22.net.netscape.com Date: Fri, 28 Jan 2000 05:26:08 +0800 Message-Id: <200001272126.FAA26283@dns.zzu.edu.cn> To: Subject: adv: Search Engine Registration MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"4S7qPC.A.WDC.OeLk4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com To be removed call: 888-800-6339 X1377 I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 From list@netscape.com Sat Jan 29 16:34:42 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23405 for ; Sat, 29 Jan 2000 16:34:42 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA22345; Sat, 29 Jan 2000 13:31:56 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA16025; Sat, 29 Jan 2000 13:33:30 -0800 (PST) Resent-Date: Sat, 29 Jan 2000 13:33:30 -0800 (PST) Message-Id: <3.0.5.32.20000129133320.00932470@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 29 Jan 2000 13:33:20 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: RFC2596: multiple language codes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"DOpziB.A.H6D.ny1k4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com RFC2296, 3.1 says: Multiple language options may be present on a particular value. Implying that an entry containing: name;lang-EN;lang-EN-US: Billy Ray The document does not detail how operations should behave in the face of values with multiple language options and may even have meant to imply the above is valid. Also note that the examples do not list options is in "ascending order" per RFC2251. The dynamic option should be listed before any language code option. Kurt From list@netscape.com Mon Jan 31 00:09:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16622 for ; Mon, 31 Jan 2000 00:09:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA23402; Sun, 30 Jan 2000 21:06:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA22078; Sun, 30 Jan 2000 21:08:19 -0800 (PST) Resent-Date: Sun, 30 Jan 2000 21:08:19 -0800 (PST) From: tran2@indiatimes.com Date: Sun, 30 Jan 2000 21:08:06 -0800 (PST) Message-Id: <200001310508.VAA29827@xwing.netscape.com> To: reps@hotmail.com Subject: Only 14 Good Reps Needed ... Resent-Message-ID: <"BPWO0B.A.vXF.8iRl4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com

ONLY 14 GOOD REPS NEEDED
We are looking to train 14 individuals to work from their
home in the Travel Industry distributing information
and promoting corporate awareness.

Huge Compensation Plan Available - For The Right Person
Enjoy Working From The Comfort Of Your Own Home

Click Here Now

From list@netscape.com Mon Jan 31 14:37:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13978 for ; Mon, 31 Jan 2000 14:37:57 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA07847; Mon, 31 Jan 2000 11:35:11 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA18012; Mon, 31 Jan 2000 11:36:26 -0800 (PST) Resent-Date: Mon, 31 Jan 2000 11:36:26 -0800 (PST) From: mike8@2891xxbecker22.net.netscape.com Date: Tue, 1 Feb 2000 03:37:48 +0800 Message-Id: <200001311937.DAA01108@sieco.com.cn> To: Subject: ADV: Search Engine Registration MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"uNgRY.A.KZE.5Qel4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com To be removed call: 888-800-6339 X1377 I saw your listing on the internet. I work for a company that submits websites to search engines. We can submit your website to over 350 of the worlds best search engines and directories for a one time charge of only $39.95. If you would like to put your website in the fast lane and receive more traffic call me on our toll-free number listed below. All work is verified! Sincerely, Mike Davidson (888) 892-7537