From list@netscape.com Tue Feb 1 21:41:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12965 for ; Tue, 1 Feb 2000 21:41: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 SAA26356; Tue, 1 Feb 2000 18:36:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA15488; Tue, 1 Feb 2000 18:39:51 -0800 (PST) Resent-Date: Tue, 1 Feb 2000 18:39:51 -0800 (PST) Message-ID: <3897C2D9.2B1680F8@software.com> Date: Tue, 01 Feb 2000 21:38:33 -0800 From: sanjay jain Organization: Software.Com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext Subject: 'mail' attribute syntax Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Vf1T0C.A.uxD.1j5l4"@glacier> 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 could somebody please point me to the description
of 0.9.2342.19200300.100.3.5{256} attribute syntax.
It is 'mail' attribute syntax referred in http://www.alternic.com/drafts/drafts-s-t/draft-smith-ldap-inetorgperson-01.txt

thanks
sanjay From list@netscape.com Wed Feb 2 02:16: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 CAA29212 for ; Wed, 2 Feb 2000 02:16:36 -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 XAA13703; Tue, 1 Feb 2000 23:11:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id XAA14316; Tue, 1 Feb 2000 23:14:16 -0800 (PST) Resent-Date: Tue, 1 Feb 2000 23:14:16 -0800 (PST) Message-Id: <3.0.5.32.20000201231834.00926770@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 01 Feb 2000 23:18:34 -0800 To: sanjay jain , ietf-ldapext From: Bruce Greenblatt Subject: Re: 'mail' attribute syntax In-Reply-To: <3897C2D9.2B1680F8@software.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"F2E0H.A.afD.Hl9l4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Whenever you want to find out what an OID is, please check out Harald Alvestrand's OID Registry. I notice that it has moved since the last time I looked anything up there to: http://www.alvestrand.no/objectid It indicates that 0.9.2342.19200300 is used in RFC 1274 to define OIDs for the "Pilot" schema used in the X.500 directory pilot. Bruce At 09:38 PM 2/1/00 -0800, sanjay jain wrote: > could somebody please point me to the description >of 0.9.2342.19200300.1 > > > >00.3{256attribute ntax. > is 'mail' >attribute >syntax >referred >in >http://www.alternic.com/drafts/drafts-s-t/draft-smith-ldap-inetorgperson-01 .txt thanks >sanjay ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Wed Feb 2 12:29:25 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15986 for ; Wed, 2 Feb 2000 12:29: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 JAA13674; Wed, 2 Feb 2000 09:26:40 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA05720; Wed, 2 Feb 2000 09:28:16 -0800 (PST) Resent-Date: Wed, 2 Feb 2000 09:28:16 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 02 Feb 2000 10:27:53 -0700 From: "Mark Meredith" To: , Cc: , , , Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_98C13539.35546CA5" Resent-Message-ID: <"QVbryB.A.GZB.vkGm4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_98C13539.35546CA5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I am getting ready to do the second draft for vendor info. In going over all of the responses I have some questions about the = supportedFeature, and whether or not I should include it in this draft? The examples that Helmut asks about at the end: "Supported features: TLS, = Cram-MD5, schema-publishing, LDAP-ACL, Ldap-replication , etc ??" I think that these should be specified in their own specific attributes. I = am afraid that if something like supportedFeatures were present, it could = become a catch all for every new proposal, it may even get to the point = that it would be very hard to sift through the information to find what = you are looking for? So what does everyone think? Should I just go forward with the vendorName = and vendorVersion and let the supportedFeatures be a separate draft if at = all? Or have all three in this draft? -Mark Mark Meredith Novell Inc 122 E. 1700 S. Provo UT 84606 mark_meredith@novell.com 801-861-2645 --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- >>> Helmut Volpers 11/21/99 02:47AM >>> Hi, > "Paul Leach (Exchange)" schrieb: >=20 > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:kurt@boolean.net] > > Sent: Friday, November 19, 1999 7:27 AM > > To: Mark Smith > > Cc: Peter Strong; Paul Leach (Exchange); Mark Meredith; ietf-ldapext >=20 > > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt > > > > > > I'm thinking we just need to define an operational attribute for the >=20 > > root DSE: > > > > supportedFeature > > > > The values of this attribute are OBJECT IDENTIFIERs identifying > the > > supported optional or vendor-defined features which the > > server supports. > > > > ( supportedFeatureOID NAME 'supportedFeature' > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) > > > > The key is that it lists features directly and eliminates the > > need to maintain out of band feature lists for each vendor version. >=20 > This sounds fine to me. Having vendor name and version is fine, too, > as long as it is _explicitly_ declared that it isn't to be used to > discover features. I agree that the vendor name (or product name) and version is fine to find out with which product and which version I interwork etc. We for example support=20 RFC 1565 (Network Services Monitoring MIB) where all this information is already availible and it will not be a problem to make this information availible to a ldap-client when it retrieves the Root. But I hope we will not encourage client implementors to build there clients that they derive special features of the product from this information. For example: we support schema publishing over ldap but if an administrator set the access control that only special users (administrators) can read the ldapsubschema-subentry then a client have to live without exploring the schema. >=20 > In addition to the above, shouldn't one look at supported controls, > and what classes exist, rather than try to categorize everything as a > "feature"? Can somebody give me a real example for this feature list ? Is it something like: Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL, Ldap-replication , etc ?? Bye Helmut --=_98C13539.35546CA5 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

I am getting ready to do the second draft for vendor info.
 
In going over all of the responses I have some questions about the supportedFeature, and whether or not I should include it in this draft?
 
The examples that Helmut asks about at the end: "Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL, Ldap-replication , etc ??"
 
I think that these should be specified in their own specific attributes. I am afraid that if something like supportedFeatures were present, it could become a catch all for every new proposal, it may even get to the point that it would be very hard to sift through the information to find what you are looking for?
 
So what does everyone think?  Should I just go forward with the vendorName and vendorVersion and let the supportedFeatures be a separate draft if at all? Or have all three in this draft?
 
-Mark
 
Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
mark_meredith@novell.com
801-861-2645
---------------------
A boat in the harbor is safe,
but that is not what boats are for.
--John A. Shed
---------------------

>>> Helmut Volpers <Helmut.Volpers@icn.siemens.de> 11/21/99 02:47AM >>>
Hi,

> "Paul Leach (Exchange)" schrieb:
>
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:kurt@boolean.net]
> > Sent: Friday, November 19, 1999 7:27 AM
> > To: Mark Smith
> > Cc: Peter Strong; Paul Leach (Exchange); Mark Meredith; ietf-ldapext
>
> > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
> >
> >
> > I'm thinking we just need to define an operational attribute for the
>
> > root DSE:
> >
> > supportedFeature
> >
> >    The values of this attribute are OBJECT IDENTIFIERs identifying
> the
> >    supported optional or vendor-defined features which the
> > server supports.
> >
> >     ( supportedFeatureOID NAME 'supportedFeature'
> >      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
> >
> > The key is that it lists features directly and eliminates the
> > need to maintain out of band feature lists for each vendor version.
>
> This sounds fine to me. Having vendor name and version is fine, too,
> as long as it is _explicitly_ declared that it isn't to be used to
> discover features.

I agree that the vendor name (or product name) and version is fine to
find
out with which product and which version I interwork etc. We for example
support
RFC 1565 (Network Services Monitoring MIB) where all this information
is already availible and it will not be a problem to make this
information
availible to a ldap-client when it retrieves the Root.
But I hope we will not encourage client implementors to build there
clients
that they derive special features of the product from this information.
For example: we support schema publishing over ldap but if an
administrator
set the access control that  only special users (administrators) can
read
the ldapsubschema-subentry then a client have to live without exploring
the
schema.
>
> In addition to the above, shouldn't one look at supported controls,
> and what classes exist, rather than try to categorize everything as a
> "feature"?

Can somebody give me a real example for this feature list ? Is it
something
like:

Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL,
Ldap-replication , etc ??

Bye

Helmut
--=_98C13539.35546CA5-- From list@netscape.com Wed Feb 2 12:40:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16374 for ; Wed, 2 Feb 2000 12:40: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 JAA01553; Wed, 2 Feb 2000 09:35:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA12709; Wed, 2 Feb 2000 09:39:05 -0800 (PST) Resent-Date: Wed, 2 Feb 2000 09:39:05 -0800 (PST) Message-ID: <38986CE9.87FC48F0@us.oracle.com> Date: Wed, 02 Feb 2000 09:44:09 -0800 From: Lok Sheung Organization: Oracle X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: 'mailGroup' object class Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"CdSE2C.A.TGD.4uGm4"@glacier> 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 'mailGroup' is referenced in  ftp://playground.sun.com/pub/laser/laser-1999-02-02.txt.  Can someone point me where I can find the specification for 'mailGroup'?

Thanks

Lok From list@netscape.com Wed Feb 2 15:13:43 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20093 for ; Wed, 2 Feb 2000 15:13: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 MAA28369; Wed, 2 Feb 2000 12:09:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA20962; Wed, 2 Feb 2000 12:12:23 -0800 (PST) Resent-Date: Wed, 2 Feb 2000 12:12:23 -0800 (PST) Message-ID: From: Gil Kirkpatrick To: "'Mark Meredith'" , paulle@Exchange.Microsoft.com, Helmut.Volpers@icn.siemens.de Cc: kurt@boolean.net, ietf-ldapext@netscape.com, mcs@netscape.com, pestrong@nortelnetworks.com Subject: RE: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt Date: Wed, 2 Feb 2000 13:09:46 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Resent-Message-ID: <"CO_CQC.A.QHF.m-Im4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Mark, I think you're right. The supportedFeature attribute can be a separate draft. I recommend getting the vendor info stuff done and consider the supportedFeature attr separately. -g Gil Kirkpatrick Director of Engineering NetPro > -----Original Message----- > From: Mark Meredith [SMTP:MMEREDIT@novell.com] > Sent: Wednesday, February 02, 2000 10:28 AM > To: paulle@Exchange.Microsoft.com; Helmut.Volpers@icn.siemens.de > Cc: kurt@boolean.net; ietf-ldapext@netscape.com; mcs@netscape.com; > pestrong@nortelnetworks.com > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt > > I am getting ready to do the second draft for vendor info. > > In going over all of the responses I have some questions about the > supportedFeature, and whether or not I should include it in this draft? > > The examples that Helmut asks about at the end: "Supported features: TLS, > Cram-MD5, schema-publishing, LDAP-ACL, Ldap-replication , etc ??" > > I think that these should be specified in their own specific attributes. I > am afraid that if something like supportedFeatures were present, it could > become a catch all for every new proposal, it may even get to the point > that it would be very hard to sift through the information to find what > you are looking for? > > So what does everyone think? Should I just go forward with the vendorName > and vendorVersion and let the supportedFeatures be a separate draft if at > all? Or have all three in this draft? > > -Mark > > > Mark Meredith > Novell Inc > 122 E. 1700 S. Provo UT 84606 > mark_meredith@novell.com > 801-861-2645 > --------------------- > A boat in the harbor is safe, > but that is not what boats are for. > --John A. Shed > --------------------- > > >>> Helmut Volpers 11/21/99 02:47AM >>> > Hi, > > > "Paul Leach (Exchange)" schrieb: > > > > > -----Original Message----- > > > From: Kurt D. Zeilenga [mailto:kurt@boolean.net] > > > Sent: Friday, November 19, 1999 7:27 AM > > > To: Mark Smith > > > Cc: Peter Strong; Paul Leach (Exchange); Mark Meredith; ietf-ldapext > > > > > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt > > > > > > > > > I'm thinking we just need to define an operational attribute for the > > > > > root DSE: > > > > > > supportedFeature > > > > > > The values of this attribute are OBJECT IDENTIFIERs identifying > > the > > > supported optional or vendor-defined features which the > > > server supports. > > > > > > ( supportedFeatureOID NAME 'supportedFeature' > > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) > > > > > > The key is that it lists features directly and eliminates the > > > need to maintain out of band feature lists for each vendor version. > > > > This sounds fine to me. Having vendor name and version is fine, too, > > as long as it is _explicitly_ declared that it isn't to be used to > > discover features. > > I agree that the vendor name (or product name) and version is fine to > find > out with which product and which version I interwork etc. We for example > support > RFC 1565 (Network Services Monitoring MIB) where all this information > is already availible and it will not be a problem to make this > information > availible to a ldap-client when it retrieves the Root. > But I hope we will not encourage client implementors to build there > clients > that they derive special features of the product from this information. > For example: we support schema publishing over ldap but if an > administrator > set the access control that only special users (administrators) can > read > the ldapsubschema-subentry then a client have to live without exploring > the > schema. > > > > In addition to the above, shouldn't one look at supported controls, > > and what classes exist, rather than try to categorize everything as a > > "feature"? > > Can somebody give me a real example for this feature list ? Is it > something > like: > > Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL, > Ldap-replication , etc ?? > > Bye > > Helmut From list@netscape.com Wed Feb 2 15:41:16 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20845 for ; Wed, 2 Feb 2000 15:41: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 MAA01989; Wed, 2 Feb 2000 12:36:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA29429; Wed, 2 Feb 2000 12:40:11 -0800 (PST) Resent-Date: Wed, 2 Feb 2000 12:40:11 -0800 (PST) Message-ID: <389895D5.1E86A581@netscape.com> Date: Wed, 02 Feb 2000 15:38:45 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gil Kirkpatrick CC: "'Mark Meredith'" , paulle@Exchange.Microsoft.com, Helmut.Volpers@icn.siemens.de, kurt@boolean.net, ietf-ldapext@netscape.com, pestrong@nortelnetworks.com Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"UIQo0.A.jLH.qYJm4"@glacier> 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 agree -- keep your draft focused on the vendor info. stuff. It will be easier to make progress if you limit the scope of your document as much as possible. For the record, I don't like the idea of a general supportedFeature attribute (for the reasons Mark M. mentioned). We already have supportedExtension, supportedControl, supportedSASLMechanisms and so on, which are fairly specific and line up clearly with LDAP protocol extensions. I'd rather see us add additional specific attributes like those (if someone can demonstrate a clear need). -- Mark Smith iPlanet Directory Architect / Sun-Netscape Alliance My words are my own, not my employer's. Got LDAP? Gil Kirkpatrick wrote: > > Mark, I think you're right. The supportedFeature attribute can be a separate > draft. I recommend getting the vendor info stuff done and consider the > supportedFeature attr separately. > > -g > > Gil Kirkpatrick > Director of Engineering > NetPro > > > -----Original Message----- > > From: Mark Meredith [SMTP:MMEREDIT@novell.com] > > Sent: Wednesday, February 02, 2000 10:28 AM > > To: paulle@Exchange.Microsoft.com; Helmut.Volpers@icn.siemens.de > > Cc: kurt@boolean.net; ietf-ldapext@netscape.com; mcs@netscape.com; > > pestrong@nortelnetworks.com > > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt > > > > I am getting ready to do the second draft for vendor info. > > > > In going over all of the responses I have some questions about the > > supportedFeature, and whether or not I should include it in this draft? > > > > The examples that Helmut asks about at the end: "Supported features: TLS, > > Cram-MD5, schema-publishing, LDAP-ACL, Ldap-replication , etc ??" > > > > I think that these should be specified in their own specific attributes. I > > am afraid that if something like supportedFeatures were present, it could > > become a catch all for every new proposal, it may even get to the point > > that it would be very hard to sift through the information to find what > > you are looking for? > > > > So what does everyone think? Should I just go forward with the vendorName > > and vendorVersion and let the supportedFeatures be a separate draft if at > > all? Or have all three in this draft? > > > > -Mark > > > > > > Mark Meredith > > Novell Inc > > 122 E. 1700 S. Provo UT 84606 > > mark_meredith@novell.com > > 801-861-2645 > > --------------------- > > A boat in the harbor is safe, > > but that is not what boats are for. > > --John A. Shed > > --------------------- > > > > >>> Helmut Volpers 11/21/99 02:47AM >>> > > Hi, > > > > > "Paul Leach (Exchange)" schrieb: > > > > > > > -----Original Message----- > > > > From: Kurt D. Zeilenga [mailto:kurt@boolean.net] > > > > Sent: Friday, November 19, 1999 7:27 AM > > > > To: Mark Smith > > > > Cc: Peter Strong; Paul Leach (Exchange); Mark Meredith; ietf-ldapext > > > > > > > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt > > > > > > > > > > > > I'm thinking we just need to define an operational attribute for the > > > > > > > root DSE: > > > > > > > > supportedFeature > > > > > > > > The values of this attribute are OBJECT IDENTIFIERs identifying > > > the > > > > supported optional or vendor-defined features which the > > > > server supports. > > > > > > > > ( supportedFeatureOID NAME 'supportedFeature' > > > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) > > > > > > > > The key is that it lists features directly and eliminates the > > > > need to maintain out of band feature lists for each vendor version. > > > > > > This sounds fine to me. Having vendor name and version is fine, too, > > > as long as it is _explicitly_ declared that it isn't to be used to > > > discover features. > > > > I agree that the vendor name (or product name) and version is fine to > > find > > out with which product and which version I interwork etc. We for example > > support > > RFC 1565 (Network Services Monitoring MIB) where all this information > > is already availible and it will not be a problem to make this > > information > > availible to a ldap-client when it retrieves the Root. > > But I hope we will not encourage client implementors to build there > > clients > > that they derive special features of the product from this information. > > For example: we support schema publishing over ldap but if an > > administrator > > set the access control that only special users (administrators) can > > read > > the ldapsubschema-subentry then a client have to live without exploring > > the > > schema. > > > > > > In addition to the above, shouldn't one look at supported controls, > > > and what classes exist, rather than try to categorize everything as a > > > "feature"? > > > > Can somebody give me a real example for this feature list ? Is it > > something > > like: > > > > Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL, > > Ldap-replication , etc ?? > > > > Bye > > > > Helmut From list@netscape.com Fri Feb 4 06:35: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 GAA21903 for ; Fri, 4 Feb 2000 06:35:25 -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 DAA03149; Fri, 4 Feb 2000 03:32:38 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA27352; Fri, 4 Feb 2000 03:34:16 -0800 (PST) Resent-Date: Fri, 4 Feb 2000 03:34:16 -0800 (PST) From: zq2qOi7e5@werner.exp-math.uni-essen.de DATE: 04 Feb 00 6:34:14 AM Message-ID: SUBJECT: ==>=>=> FREE PCS Cell Phone! <=<=<== lsdkjd3 Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Resent-Message-ID: <"ovUaED.A.1qG.2krm4"@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 How to get the 1st and ONLY Free PCS Digital Cell Phone with NO Long Distance and NO Roaming ANYTIME MINUTES. Now Available on the Net! Bad credit... No problem. You will be notified if you need to make a deposit to activate service. That's right! You get a *FREE* PCS Digital Cell Phone. Unprecedented Nationwide, Limited Time Offer!!! Your Free Digital Phone includes the following: * Choice of a Samsung model # SCH-2000 or Qualcomm Thin Phone [These phones would cost you over $200.00 at any retail Cellular store - we have no store overhead so you Save money.] * All NEW phones. * No Activation Fee. * No Up-Front Cost. The first bill is within 30 days from date received. [ All you pay is sales tax on the phone.] * FREE Long Distance and Roaming. * FREE Caller ID. * FREE Call Waiting. * FREE VoiceMail. * FREE Paging. [Get rid of your pager bill] * FREE First Incoming Minute. * FREE Home Charger. * Lightweight -- 6 oz. * Crystal Clear digital NATIONWIDE* PCS service [USA Only] [Nations BEST Digital Carrier] * Choice of Voice Activation on Samsung model only. * FREE Delivery by UPS within 10-15 working days of approval. * 30 day return policy [restrictions may apply]. * There is no better cell phone Deal on the planet! Hi Folks: Want or need a free cell phone? Sure everyone does. Nice to have for emergencies. Easy to qualify. Just fill out the form below & fax it to us. [If you are not approved, you will be notified as to your need for a deposit] TO ORDER and receive your FREE CELL PHONE just print this message and fill out the simple application form. Then fax only the application to the number below. You should have your new cell phone within 10-15 business days of "approval." [Not from the time you fax it.] Sorry, no email orders. Is there any question that this is an incredible opportunity? Apply now for the best wireless phone service for the new millennium and get your new, FREE PCS digital cell phone. You can't lose!!! Don't pass up this incredible offer! Go Ahead And Order Now! If due to the response to this offer the fax lines are busy please try again. Thanks, Bob Waterman Free Cell Phone Agent ------- CUT HERE ------- Fax Order Center: (775) 522-0741 (The fax number IS ACTIVATED...call back immediately!) PLEASE PRINT or TYPE CLEARLY & FAX O N L Y this application page APPLICATION MUST BE COMPLETED OR IT WILL NOT BE PROCESSED. No blank fields. "VERY CLEARLY" TYPE or WRITE YOUR EMAIL ADDRESS HERE:_________________________________ NAME First:__________________ M.I. ____ Last:__________________________ USA Address:______________________________________Apt#.___________ City:_______________________________ST:________ Zip:_________ County:_______________________[NEEDED TO FIND YOUR COVERAGE AREA] (*No coverage in MT, MS, NC, SC, AK) SS#________________________ Date Of Birth:______/_____/___________ DL#:__________________________ Exp. Date:_____/_____/_______ Home Ph#:(___)_______________[NO PAGER NUMBERS] Work Ph#:(____)_____________Ext#:______[NO PAGER NUMBERS] Best Time To Call:_________________________ Time Zone:_____________ YOUR Business or EMPLOYER Information: Check one: ____Self employed ____Employee If Self Employed your business license # ______________ or Sales Tax ID #_____________ COMPANY NAME:________________________________________________ ADDRESS:______________________________________ City:_______________________________ST:________ Zip:_________ Phone #:______________________ Check phone model you want: ___Samsung model # SCH-2000 ___ Qualcomm Thin Phone Calling Plans: Check the one you want. You can upgrade or downgrade at any time. _____$ 29.99/month for 120 ANYTIME MIN.[over plan per min charge $.35 cents] _____$ 49.99/month for 400 ANYTIME MIN.[over plan per min charge $.30 cents] _____$ 69.99/month for 600 ANYTIME MIN.[over plan per min charge $.25 cents] _____$ 99.99/month for 1,000 ANYTIME MIN.[over plan per min charge $.25 cents] _____$ 149.99/month for 1,500 ANYTIME MIN.[over plan per min charge $.25 cents] Signature: (BW) __________________________________ Date:_____/_____/___________ NO UPFRONT MONEY - your first bill within 30 days from receipt of phone. [2 year Air Time contract] BW Authorization for credit check and contract approved by my signature. Check your application status by calling 435-508-1156 Fax Order Center: (775) 522-0741 ------- CUT HERE ------- =-=-=-=-=-=-=-=-=-=-REMOVE INSTRUCTIONS-=-=-=-=-=-=-=-= Please follow the instructions below to be removed from our in-house mailing list. We will immediately take action to remove you from future mailings. Access the website below. If this service page has been shut down, it is because someone actually complained about this service!!! If this is the case, sorry for the inconvenience. http://sede.aecoc.es%647key=removeremoveindex=ixbtl730iq%403522794361/~joe b/remove/21268.htm From list@netscape.com Fri Feb 4 09:24:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27818 for ; Fri, 4 Feb 2000 09:24: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 GAA13988; Fri, 4 Feb 2000 06:20:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA28558; Fri, 4 Feb 2000 06:22:32 -0800 (PST) Resent-Date: Fri, 4 Feb 2000 06:22:32 -0800 (PST) Message-Id: <3.0.3.32.20000204142450.006fb394@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 04 Feb 2000 14:24:50 +0000 To: directory@opengroup.org, ietf-ldapext@netscape.com From: Chris Harding Subject: (c.harding 38467) bug in blits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"jWigS.A.89G.nCum4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi - It seems a bit surprising that this hasn't come up before. Should we change BLITS as suggested? >From: Christopher Oliva >To: "'capple@att.com'" , > "'c.harding@opengroup.org'" > , > "'ludovic.poitou@france.sun.com'" > >Subject: (c.harding 38467) bug in blits >Date: Thu, 3 Feb 2000 14:26:36 -0500 >X-Mailer: Internet Mail Service (5.5.2650.21) >Comments: (c.harding 38467) > >Hi, > >I have a bug report for the following tests in the BLITS suite: > >3.3.2.9.2 >3.3.2.9.3 >3.3.2.9.4 > >They are testing the ldap server response to a search where no entries match >the search filter. They require the "noSuchObject" error to be returned. In >reality, this is not correct. I can tell you that from working with many >(commercial release) directory products that none of them return this error. >The correct response from the server is a "success" code with no matching >search result entries i.e. there will be no matches and the search completes >successfully. > >The reason is in X.500. Clause 10.2.3 of X.511 (1997) says this: > >The search request succeeds if the baseObject is located, regardless of >whether there are any subordinates to return. > >Furthermore, noSuchObject is defined as follows in clause 12 of X.511: > >noSuchObject - The name supplied does not match the name of any object > >Applied to the search operation, this means the base object parameter of the >search (if it cannot be located) will result in this error. > >This is substantiated by the description of how an LDAPResult is constructed >in RFC 2251 4.1.10. > >As a result of this, I think the BLITS test should be changed. I think some >directory implementations may code the incorrect behaviour into their >products unless this is changed. > >Please let me know what you think. > >Chris. > > > Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Directory Program Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- From list@netscape.com Fri Feb 4 10:03:34 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29293 for ; Fri, 4 Feb 2000 10:03:34 -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 HAA18982; Fri, 4 Feb 2000 07:00:51 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA12016; Fri, 4 Feb 2000 07:02:29 -0800 (PST) Resent-Date: Fri, 4 Feb 2000 07:02:29 -0800 (PST) Message-ID: <389AE9BE.ACF64678@netscape.com> Date: Fri, 04 Feb 2000 10:01:18 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harding CC: directory@opengroup.org, ietf-ldapext@netscape.com Subject: Re: (c.harding 38467) bug in blits References: <3.0.3.32.20000204142450.006fb394@mailhome.rdg.opengroup.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jConCB.A.e7C.Eoum4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Yes, it sounds to me like BLITS should be changed as Chris O. suggests. -- Mark Smith Directory & Security Group / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? Chris Harding wrote: > > Hi - > > It seems a bit surprising that this hasn't come up before. Should we change > BLITS as suggested? > > >From: Christopher Oliva > >To: "'capple@att.com'" , > > "'c.harding@opengroup.org'" > > , > > "'ludovic.poitou@france.sun.com'" > > > >Subject: (c.harding 38467) bug in blits > >Date: Thu, 3 Feb 2000 14:26:36 -0500 > >X-Mailer: Internet Mail Service (5.5.2650.21) > >Comments: (c.harding 38467) > > > >Hi, > > > >I have a bug report for the following tests in the BLITS suite: > > > >3.3.2.9.2 > >3.3.2.9.3 > >3.3.2.9.4 > > > >They are testing the ldap server response to a search where no entries match > >the search filter. They require the "noSuchObject" error to be returned. In > >reality, this is not correct. I can tell you that from working with many > >(commercial release) directory products that none of them return this error. > >The correct response from the server is a "success" code with no matching > >search result entries i.e. there will be no matches and the search completes > >successfully. > > > >The reason is in X.500. Clause 10.2.3 of X.511 (1997) says this: > > > >The search request succeeds if the baseObject is located, regardless of > >whether there are any subordinates to return. > > > >Furthermore, noSuchObject is defined as follows in clause 12 of X.511: > > > >noSuchObject - The name supplied does not match the name of any object > > > >Applied to the search operation, this means the base object parameter of the > >search (if it cannot be located) will result in this error. > > > >This is substantiated by the description of how an LDAPResult is constructed > >in RFC 2251 4.1.10. > > > >As a result of this, I think the BLITS test should be changed. I think some > >directory implementations may code the incorrect behaviour into their > >products unless this is changed. > > > >Please let me know what you think. > > > >Chris. > > > > > From list@netscape.com Fri Feb 4 10:27:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00037 for ; Fri, 4 Feb 2000 10:27: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 HAA21460; Fri, 4 Feb 2000 07:24:11 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA19652; Fri, 4 Feb 2000 07:25:50 -0800 (PST) Resent-Date: Fri, 4 Feb 2000 07:25:50 -0800 (PST) Sender: vinnie@oasis.ireland.Sun.COM Message-ID: <389AEE8D.2E4A19C6@Ireland.Sun.COM> Date: Fri, 04 Feb 2000 15:21:49 +0000 From: Vincent Ryan Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harding CC: directory@opengroup.org, ietf-ldapext@netscape.com Subject: Re: (c.harding 38467) bug in blits References: <3.0.3.32.20000204142450.006fb394@mailhome.rdg.opengroup.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"IJ8ALB.A.yyE.99um4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit The tests listed below all attempt to perform a search at a non-existent entry. It is correct to expect a noSuchObject error to be returned. Admittedly, the Procedure clause in each of the test specifications is a little misleading and could be replaced with: Submit a {subtree | single-level | base-level} search request where the base object does not exist. Chris Harding wrote: > > Hi - > > It seems a bit surprising that this hasn't come up before. Should we change > BLITS as suggested? > > >From: Christopher Oliva > >To: "'capple@att.com'" , > > "'c.harding@opengroup.org'" > > , > > "'ludovic.poitou@france.sun.com'" > > > >Subject: (c.harding 38467) bug in blits > >Date: Thu, 3 Feb 2000 14:26:36 -0500 > >X-Mailer: Internet Mail Service (5.5.2650.21) > >Comments: (c.harding 38467) > > > >Hi, > > > >I have a bug report for the following tests in the BLITS suite: > > > >3.3.2.9.2 > >3.3.2.9.3 > >3.3.2.9.4 > > > >They are testing the ldap server response to a search where no entries match > >the search filter. They require the "noSuchObject" error to be returned. In > >reality, this is not correct. I can tell you that from working with many > >(commercial release) directory products that none of them return this error. > >The correct response from the server is a "success" code with no matching > >search result entries i.e. there will be no matches and the search completes > >successfully. > > > >The reason is in X.500. Clause 10.2.3 of X.511 (1997) says this: > > > >The search request succeeds if the baseObject is located, regardless of > >whether there are any subordinates to return. > > > >Furthermore, noSuchObject is defined as follows in clause 12 of X.511: > > > >noSuchObject - The name supplied does not match the name of any object > > > >Applied to the search operation, this means the base object parameter of the > >search (if it cannot be located) will result in this error. > > > >This is substantiated by the description of how an LDAPResult is constructed > >in RFC 2251 4.1.10. > > > >As a result of this, I think the BLITS test should be changed. I think some > >directory implementations may code the incorrect behaviour into their > >products unless this is changed. > > > >Please let me know what you think. > > > >Chris. > > > > > > > > Regards, > > Chris > +++++ > > ------------------------------------------------------------------------- > Chris Harding > T H E Directory Program Manager > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK > G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 > WWW: http://www.opengroup.org Fx: +44 118 950 0110 > > OSF/1, Motif, UNIX and the "X" device are registered trademarks in > the US and other countries, and IT DialTone and The Open Group are > trademarks of The Open Group. > ------------------------------------------------------------------------- From list@netscape.com Sun Feb 6 13:53:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11390 for ; Sun, 6 Feb 2000 13:53:12 -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 KAA11111; Sun, 6 Feb 2000 10:50:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA22224; Sun, 6 Feb 2000 10:51:56 -0800 (PST) Resent-Date: Sun, 6 Feb 2000 10:51:56 -0800 (PST) Message-Id: <4.2.2.20000206124644.00a4b580@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 06 Feb 2000 12:52:26 -0600 To: internet-drafts@ietf.org, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Steve Coya From: Ellen Stokes Subject: please publish - draft-ietf-ldapext-acl-reqts-03.txt Cc: Keith Moore , Ned Freed , ietf-ldapext@netscape.com In-Reply-To: <234079.3158829413@[192.168.111.25]> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_7255096==_" Resent-Message-ID: <"n8FwDC.A.-aF.KLcn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_7255096==_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Please publish - it reflects the changes requested per IESG comments: 1. RFC2119 references: - used RFC 2696 as a model - modified the abstract to reflect the accepted wording - added a reference to RFC 2119 in the reference section ([bradner97] 2. Renamed reference [2] to [ecma] and reworded its reference in the glossary section. And yes, we used some of the definitions from the ECMA glossary, but only those pertinent to this requirements document. 3. Put in the correct 'Status of Memo' and 'Copyright' stuff and in the=20 same order as RFC 2696. Ellen At 12:36 PM 2/6/00 +0100, Patrik F=E4ltstr=F6m wrote: >--On 2000-02-04 12.27 -0500, Steve Coya wrote: > > > Ellen, > > > > You'll be submitting the update as an new I-D, right? > >Ellen, can you please see that you send in the new version of the document >to internet-drafts@ietf.org, and let me know when you see the announcement? > > Patrik > --=====================_7255096==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="draft-ietf-ldapext-acl-reqts-03.txt" Content-Transfer-Encoding: quoted-printable LDAP Extensions Working Group E. Stokes Internet Draft D. Byrne Intended Category: Informational IBM Expires: 6 August 2000 B. Blakley Dascom P. Behera Netscape 6 February 2000 Access Control Requirements for LDAP 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. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com COPYRIGHT NOTICE Copyright (C) The Internet Society (1997). All Rights Reserved. Stokes, et al. Expires 6 August 2000 [Page 1] =0C Internet Draft ACI Requirements February 2000 ABSTRACT This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97]. 1. Introduction The ability to securely access (replicate and distribute) directory information throughout the network is necessary for successful deployment. LDAP's acceptance as an access protocol for directory information is driving the need to provide an access control model definition for LDAP directory content among servers within an enterprise and the Internet. Currently LDAP does not define an access control model, but is needed to ensure consistent secure access across heterogeneous LDAP implementations. The requirements for access control are critical to the successful deployment and acceptance of LDAP in the market place. The RFC 2119 terminology is used in this document. 2. Objectives The major objective is to provide a simple, but secure, highly efficient access control model for LDAP while also providing the appropriate flexibility to meet the needs of both the Internet and enterprise environments and policies. This generally leads to several general requirements that are discussed below. Stokes, et al. Expires 6 August 2000 [Page 2] =0C Internet Draft ACI Requirements February 2000 3. Requirements This section is divided into several areas of requirements: general, semantics/policy, usability, and nested groups (an unresolved issue). The requirements are not in any priority order. Examples and explanatory text is provided where deemed necessary. Usability is perhaps the one set of requirements that is generally overlooked, but must be addressed to provide a secure system. Usability is a security issue, not just a nice design goal and requirement. If it is impossible to set and manage a policy for a secure situation that a human can understand, then what was set up will probably be non-secure. We all need to think of usability as a functional security requirement. 3.1 General G1. Model SHOULD be general enough to support extensibility to add desirable features in the future. G2. When in doubt, safer is better, especially when establishing defaults. G3. ACL administration SHOULD be part of the LDAP protocol. Access control information MUST be an LDAP attribute. G4. Object reuse protection SHOULD be provided and MUST NOT inhibit implementation of object reuse. The directory SHOULD support policy controlling the re-creation of deleted DNs, particularly in cases where they are re- created for the purpose of assigning them to a subject other than the owner of the deleted DN. 3.2 Semantics / Policy S1. Omitted as redundant; see U8. S2. More specific policies must override less specific ones (e.g. individual user entry in ACL SHOULD take precedence over group entry) for the evaluation of an ACL. S3. Multiple policies of equal specificity SHOULD be Stokes, et al. Expires 6 August 2000 [Page 3] =0C Internet Draft ACI Requirements February 2000 combined in some easily-understood way (e.g. union or intersection). This is best understood by example. Suppose user A belongs to 3 groups and those 3 groups are listed on the ACL. Also suppose that the permissions for each of those groups are not identical. Each group is of equal specificity (e.g. each group is listed on the ACL) and the policy for granting user A access (given the example) SHOULD be combined in some easily understood way, such as by intersection or union. For example, an intersection policy here may yield a more limited access for user A than a union policy. S4. Newly created directory entries SHOULD be subject to a secure default policy. S5. Access policy SHOULD NOT be expressed in terms of attributes which the directory administrator or his organization cannot administer (e.g. groups whose membership is administered by another organization). S6. Access policy SHOULD NOT be expressed in terms of attributes which are easily forged (e.g. IP addresses). There may be valid reasons for enabling access based on attributes that are easily forged and the behavior/implications of doing that should be documented. S7. Humans (including administrators) SHOULD NOT be required to manage access policy on the basis of attributes which are not "human-readable" (e.g. IP addresses). S8. It MUST be possible to deny a subject the right to invoke a directory operation. The system SHOULD NOT require a specific implementation of denial (e.g. explicit denial, implicit denial). S9. The system MUST be able (semantically) to support either default-grant or default-deny semantics (not simultaneously). S10. The system MUST be able to support either union semantics or intersection semantics for aggregate subjects (not simultaneously). S11. Absence of policy SHOULD be interpretable as grant Stokes, et al. Expires 6 August 2000 [Page 4] =0C Internet Draft ACI Requirements February 2000 or deny. Deny takes precedence over grant among entries of equal specificity. S12. ACL policy resolution MUST NOT depend on the order of entries in the ACL. S13. Rights management MUST have no side effects. Granting a subject one right to an object MUST NOT implicitly grant the same or any other subject a different right to the same object. Granting a privilege attribute to one subject MUST NOT implicitly grant the same privilege attribute to any other subject. Granting a privilege attribute to one subject MUST NOT implicitly grant a different privilege attribute to the same or any other subject. Definition: An ACL's "scope" is defined =20 as the set of directory objects governed by the policy it defines; this set of objects is a sub-tree of the directory. Changing the policy asserted by an ACL (by changing one or more of its entries) MUST NOT implicitly change the policy governed by an ACL in a different scope. S14. It SHOULD be possible to apply a single policy to multiple directory entries, even if those entries are in different subtrees. Applying a single policy to multiple directory entries SHOULD NOT require creation and storage of multiple copies of the policy data. The system SHOULD NOT require a specific implementation (e.g. nested groups, named ACLs) of support for policy sharing. 3.3 Usability (Manageability) U1. When in doubt, simpler is better, both at the interface and in the implementation. U2. Subjects MUST be drawn from the "natural" LDAP namespace; they should be DNs. U3. It SHOULD NOT be possible via ACL administration to lock all users, including all administrators, out of the directory. U4. Administrators SHOULD NOT be required to evaluate arbitrary Boolean predicates in order to create or understand policy. Stokes, et al. Expires 6 August 2000 [Page 5] =0C Internet Draft ACI Requirements February 2000 U5. Administrators SHOULD be able to administer access to directories and their attributes based on their sensitivity, without having to understand the semantics of individual schema elements and their attributes (see U9). U6. Management of access to resources in an entire subtree SHOULD require only one ACL (at the subtree root). Note that this makes access control based explicitly on attribute types very hard, unless you constrain the types of entries in subtrees. For example, another attribute is added to an entry. That attribute may fall outside the grouping covered by the ACL and hence require additional administration where the desired affect is indeed a different ACL. Access control information specified in one administrative area MUST NOT have jurisdiction in another area. You SHOULD NOT be able to control access to the aliased entry in the alias. You SHOULD be able to control access to the alias name. U7. Override of subtree policy MUST be supported on a per-directory-entry basis. U8. Control of access to individual directory entry attributes (not just the whole directory entry) MUST be supported. U9. Administrator MUST be able to coarsen access policy granularity by grouping attributes with similar access sensitivities. U10. Control of access on a per-user granularity MUST be supported. U11. Administrator MUST be able to aggregate users (for example, by assigning them to groups or roles) to simplify administration. U12. It MUST be possible to review "effective access" of any user, group, or role to any entry's attributes. This aids the administrator in setting the correct policy. U13. A single administrator SHOULD be able to define policy for the entire directory tree. An administrator MUST be able to delegate policy administration for Stokes, et al. Expires 6 August 2000 [Page 6] =0C Internet Draft ACI Requirements February 2000 specific subtrees to other users. This allows for the partitioning of the entire directory tree for policy administration, but still allows a single policy to be defined for the entire tree independent of partitioning. (Partition in this context means scope of administration). An administrator MUST be able to create new partitions at any point in the directory tree, and MUST be able to merge a superior and subordinate partition. An administrator MUST be able to configure whether delegated access control information from superior partitions is to be accepted or not. U14. It MUST be possible to authorize users to traverse directory structure even if they are not authorized to examine or modify some traversed entries; it MUST also be possible to prohibit this. The tree structure MUST be able to be protected from view if so desired by the administrator. U15. It MUST be possible to create publicly readable entries, which may be read even by unauthenticated clients. U16. The model for combining multiple access control list entries referring to a single individual MUST be easy to understand. U17. Administrator MUST be able to determine where inherited policy information comes from, that is, where ACLs are located and which ACLs were applied. Where inheritance of ACLs is applied, it must be able to be shown how/where that new ACL is derived from. U18. It SHOULD be possible for the administrator to configure the access control system to permit users to grant additional access control rights for entries which they create. 4. Security Considerations Access control is a security consideration. This documents addresses the requirements. Stokes, et al. Expires 6 August 2000 [Page 7] =0C Internet Draft ACI Requirements February 2000 5. Glossary This glossary is intended to aid the novice not versed in depth about access control. It contains a list of terms and their definitions that are commonly used in discussing access control [emca]. Access control - The prevention of use of a resource by unidentified and/or unauthorized entities in any other that an authorized manner. Access control list - A set of control attributes. It is a list, associated with a security object or a group of security objects. The list contains the names of security subjects and the type of access that may be granted. Access control policy - A set of rules, part of a security policy, by which human users, or their representatives, are authenticated and by which access by these users to applications and other services and security objects is granted or denied. Access context - The context, in terms of such variables as location, time of day, level of security of the underlying associations, etc., in which an access to a security object is made. Authorization - The granting of access to a security object. Authorization policy - A set of rules, part of an access control policy, by which access by security subjects to security objects is granted or denied. An authorization policy may be defined in terms of access control lists, capabilities, or attributes assigned to security subjects, security objects, or both. Control attributes - Attributes, associated with a security object that, when matched against the privilege attributes of a security subject, are used to grant or deny access to the security object. An access control list or list of rights or time of day range are examples of control attributes. Stokes, et al. Expires 6 August 2000 [Page 8] =0C Internet Draft ACI Requirements February 2000 Credentials - Data that serve to establish the claimed identity of a security subject relative to a given security domain. Privilege attributes - Attributes, associated with a security subject that, when matched against control attributes of a security object, are used to grant or deny access to that subject. Group and role memberships are examples of privilege attributes. Security attributes - A general term covering both privilege attributes and control attributes. The use of security attributes is defined by a security policy. Security object - An entity in a passive role to which a security policy applies. Security policy - A general term covering both access control policies and authorization policies. Security subject - An entity in an active role to which a security policy applies. 6. References [ldap] Steve Kille, Tim Howes, M. Wahl, "Lightweight Directory Access Protocol (v3)", RFC 2251, August 1997. [ecma] ECMA, "Security in Open Systems: A Security Framework" ECMA TR/46, July 1988 [bradner97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. AUTHOR(S) ADDRESS Bob Blakley Ellen Stokes Dascom IBM 5515 Balcones Drive 11400 Burnet Rd Austin, TX 78731 Austin, TX 78758 USA USA mail-to: blakley@dascom.com mail-to:= stokes@austin.ibm.com Stokes, et al. Expires 6 August 2000 [Page 9] =0C Internet Draft ACI Requirements February 2000 phone: +1 512 458 4037 ext 5012 phone: +1 512 838 3725 fax: +1 512 458 2377 fax: +1 512 838 0156 Debbie Byrne Prasanta Behera IBM Netscape 11400 Burnet Rd 501 Ellis Street Austin, TX 78758 Mountain View, CA 94043 USA USA mail-to: djbyrne@us.ibm.com mail-to:= prasanta@netscape.com phone: +1 512 838 1930 phone: +1 650 937 4948 fax: +1 512 838 8597 fax: +1 650 528-4164 Stokes, et al. Expires 6 August 2000 [Page 10] =0C Internet Draft ACI Requirements February 2000 7. Full Copyright Statement Copyright (C) The Internet Society (1999).=A0 All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.=A0 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al. Expires 6 August 2000 [Page 11] =0C --=====================_7255096==_-- From list@netscape.com Sun Feb 6 16:33:38 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12672 for ; Sun, 6 Feb 2000 16:33: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 NAA11677; Sun, 6 Feb 2000 13:29:05 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA11596; Sun, 6 Feb 2000 13:32:29 -0800 (PST) Resent-Date: Sun, 6 Feb 2000 13:32:29 -0800 (PST) Message-Id: <3.0.5.32.20000206133217.0096f100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 06 Feb 2000 13:32:17 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: attributeTypes for AttributeDescriptions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ogch0B.A.20C.shen4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com RFC2252 appears to allow attributeTypes values such as: ( 1.2.3 NAME 'userCertificate;binary' SUP userCertificate SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) Is this an intended use? What are intended uses of attributeTypes values which name attribute descriptions? I assume that OID should be unique to the attributeTypes value and not that of the associated attribute type. Kurt From list@netscape.com Mon Feb 7 09:17:16 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09888 for ; Mon, 7 Feb 2000 09:17: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 GAA02235; Mon, 7 Feb 2000 06:14:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA24278; Mon, 7 Feb 2000 06:16:05 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 06:16:05 -0800 (PST) From: FRANK@XGLOBE.COM To: Date: Wed, 9 Feb 2000 01:20:09 Message-Id: <548.893204.468935@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"yRE7R.A.E7F.kOtn4"@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 web sites offered for only 12.95 per month with a 40.00 set up. service includes hosting your own domain with your own "yourname@yourname.com" email address. all sites are prepaid annually in advance with a 90 day money back guarantee. all sites start at 5 megs. dial 1 888 248 0765 for more information. "." From list@netscape.com Mon Feb 7 12:41:16 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16559 for ; Mon, 7 Feb 2000 12:41: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 JAA25170; Mon, 7 Feb 2000 09:38:28 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA19625; Mon, 7 Feb 2000 09:40:10 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 09:40:10 -0800 (PST) Message-Id: <3.0.5.32.20000207094004.009392d0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Feb 2000 09:40:04 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: RFC2251: RootDSE subschemasubentry issue Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"80IvXB.A.XyE.5Nwn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com As previously noted <8525679B.003DD02B.00@D51MTA04.pok.ibm.com>, RFC 2251 states subschemaSubentry attribute type within the Root DSE may contain multiple values though the attribute type is single valued. I do not believe it necessary to provide a mechanism to allow clients to obtain a complete list of subschema entries (or subentries) known to this server. This list could be quite large and, IMO, rather useless. Applications need to known which subschema controls which entries. I suggest that applications obtain the DN of the subschema entry (subentry) from either the entry(ies) they intend to access or from the entry at the root of the naming context. To resolve this issue, I suggest: RFC 2251, 3.4 "--subsubschemaSubentry" subsection be removed and that a note be added to the end of the section: Note: the subsubschemaSubentry attribute type, if present, contains the Distinguished Name of the subschema entry (or subentry) which controls the schema for the Root DSE. Comments? Kurt From list@netscape.com Mon Feb 7 13:16:44 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18015 for ; Mon, 7 Feb 2000 13:16: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 KAA03359; Mon, 7 Feb 2000 10:13:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA09618; Mon, 7 Feb 2000 10:15:34 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 10:15:34 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com Subject: RE: attributeTypes for AttributeDescriptions Date: Mon, 7 Feb 2000 13:16:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"f61lnB.A.AWC.Fvwn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com RFC2252 allows this, but it's not consistent with the definition of ;binary. Both RFC 2251 and 2252 say that the binary option applies to the way the attribute value is transfered in protocol, not the way it is stored. That being the case, it wouldn't make sense to define two different OIDs for the same attribute. Your example also changes the syntax of the derived attribute. In X.500 that is illegal. X.501, 12.4.2 says "If the attribute syntax is indicated and the attribute has a direct supertype, the indicated syntax must be compatible with the supertype's syntax, i.e. every possible value satisfying the attribute's syntax must also satisfy the supertype's syntax." This is just expressing the usual notions of inheritance. There is also a statement about matching rules of the supertype applying to the subtype. I think these restrictions are all here to allow searching for the supertype to work as expected. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Sunday, February 06, 2000 4:32 PM > To: ietf-ldapext@netscape.com > Subject: attributeTypes for AttributeDescriptions > > > RFC2252 appears to allow attributeTypes values such as: > ( 1.2.3 NAME 'userCertificate;binary' SUP userCertificate > SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) > > Is this an intended use? What are intended uses of attributeTypes > values which name attribute descriptions? I assume that OID > should be unique to the attributeTypes value and not that of > the associated attribute type. > > Kurt > From list@netscape.com Mon Feb 7 13:41: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 NAA18576 for ; Mon, 7 Feb 2000 13:41: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 KAA08616; Mon, 7 Feb 2000 10:37:45 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA22052; Mon, 7 Feb 2000 10:39:27 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 10:39:27 -0800 (PST) Message-Id: <3.0.5.32.20000207103909.00986c80@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Feb 2000 10:39:09 -0800 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: attributeTypes for AttributeDescriptions Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"d9kqlD.A.SYF.fFxn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com So, I ask: > > What are intended uses of attributeTypes values which > > name attribute descriptions? From list@netscape.com Mon Feb 7 15:07:42 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20523 for ; Mon, 7 Feb 2000 15:07: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 MAA12231; Mon, 7 Feb 2000 12:03:07 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA15827; Mon, 7 Feb 2000 12:06:29 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 12:06:29 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com Subject: RE: attributeTypes for AttributeDescriptions Date: Mon, 7 Feb 2000 15:07:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"EC08C.A.n2D.DXyn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com maybe its different with language codes ? > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, February 07, 2000 1:39 PM > To: Salter, Thomas A > Cc: ietf-ldapext@netscape.com > Subject: RE: attributeTypes for AttributeDescriptions > > > So, I ask: > > > What are intended uses of attributeTypes values which > > > name attribute descriptions? > > From list@netscape.com Mon Feb 7 15:38:00 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21139 for ; Mon, 7 Feb 2000 15:37: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 MAA01203; Mon, 7 Feb 2000 12:35:07 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA00829; Mon, 7 Feb 2000 12:36:50 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 12:36:50 -0800 (PST) From: smd@iris.com Subject: Search reference question To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Build V60_01192000 January 19, 2000 Message-ID: Date: Mon, 7 Feb 2000 15:36:14 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/07/2000 03:37:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"sgGSuD.A.tM.hzyn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Section 4.5.3. of RFC 2251 states: In order to complete the search, the client MUST issue a new search operation for each SearchResultReference that is returned. Can someone help me with the interpretation. Does this mean that if a client receives a SearchResultReference it MUST issue a new search operation to the referenced server? Or rather, if the client wishes to complete the search it MUST (really should) issue a new search operation? Thanks, Scott M Davidson Iris Associates smd@iris.com (978) 392-5436 Five Technology Park Drive Westford, MA 01886 From list@netscape.com Mon Feb 7 15:46: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 PAA21306 for ; Mon, 7 Feb 2000 15:46:31 -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 MAA18513; Mon, 7 Feb 2000 12:41:57 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA05961; Mon, 7 Feb 2000 12:45:15 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 12:45:15 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 07 Feb 2000 13:44:53 -0700 From: "Roger Harrison" To: , Subject: Re: Search reference question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"WFZXpD.A.3cB.b7yn4"@glacier> 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 PAA21306 Your second interpretation is correct. I think the sticking point here is what it meant by "complete." I believe that the authors are using the term complete to mean the entire set of entries for the given search (as opposed to the completion of a given search request). The fact that a SearchResultReference was sent by the server means that one or more entries will be missing from the set unless the client issues a new search operation for the SearchResultReference. Thus, the search will not be complete unless a new search operation is issued for the SearchResultReference. The client is not required to issue the new search request for each SearchResultReference, but the expected set of entries won't be complete until it does. Roger Harrison roger_harrison@novell.com Novell, Inc. >>> 02/07/00 01:37PM >>> Section 4.5.3. of RFC 2251 states: In order to complete the search, the client MUST issue a new search operation for each SearchResultReference that is returned. Can someone help me with the interpretation. Does this mean that if a client receives a SearchResultReference it MUST issue a new search operation to the referenced server? Or rather, if the client wishes to complete the search it MUST (really should) issue a new search operation? Thanks, Scott M Davidson Iris Associates smd@iris.com (978) 392-5436 Five Technology Park Drive Westford, MA 01886 From list@netscape.com Mon Feb 7 16:14:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21921 for ; Mon, 7 Feb 2000 16:14:12 -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 NAA23256; Mon, 7 Feb 2000 13:09:25 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA21244; Mon, 7 Feb 2000 13:12:51 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 13:12:51 -0800 (PST) Message-Id: <3.0.5.32.20000207131242.00987aa0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Feb 2000 13:12:42 -0800 To: smd@iris.com From: "Kurt D. Zeilenga" Subject: Re: Search reference question Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"InBiWB.A.qLF.SVzn4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:36 PM 2/7/00 -0500, smd@iris.com wrote: >Section 4.5.3. of RFC 2251 states: > In order to complete the search, the client MUST issue a new search > operation for each SearchResultReference that is returned. > >Can someone help me with the interpretation. Does this mean that if a >client receives a SearchResultReference it MUST issue a new search >operation to the referenced server? Or rather, if the client wishes to >complete the search it MUST (really should) issue a new search operation? The MUST does not require the operation to be completed nor state when the client should attempt to complete the operation. The MUST says what the client MUST do to complete the operation. The client may choose (or be required*) not to complete any operation. * RFC 2251, Section 6.2. They [clients] MUST NOT repeatedly contact the same server for the same request with the same target entry name, scope and filter. Note: the first sentence of 6.2: Clients which request referrals MUST ensure that they do not loop between servers. should, IMO, be reworded in RFC 2251bis to: Clients which chase referrals and/or references MUST ensure that type do not loop between servers. From list@netscape.com Mon Feb 7 22:10:11 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26826 for ; Mon, 7 Feb 2000 22:10: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 TAA04801; Mon, 7 Feb 2000 19:05:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA10302; Mon, 7 Feb 2000 19:09:04 -0800 (PST) Resent-Date: Mon, 7 Feb 2000 19:09:04 -0800 (PST) From: spy2@post.com Reply-To: spy2@post.com Date: Sun, 07 Nov 1999 19:08:57 -0800 Message-Id: To: wefr@yeys.ua.netscape.com Subject: INTERNET SPY! Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT X-SMTP-HELO: tryout X-SMTP-MAIL-FROM: spy2@post.com X-SMTP-RCPT-TO: ietf-run@mailbag.cps.intel.com,ietf-ldapext@netscape.com,ietf-l2tp@aptis.com,ietf-hosts@nnsc.nsf.net,ietf-charsets@innosoft.comnov,ietf-charsets@innosoft.com,ietech@mindspring.com,ietco@sympatico.ca,ietcnzix@fbs.cz,ietc@ietc-team.com,ietaosnsgz@ezoh.au,ietam@asuacad.bitnet,ietagqnhlkok@jmdwiie.cr,ietaadri@sirius.ceu.hu,iet@vflsiyf.de,iet@vcomm.net,iet@uvcs.uvic.ca,iet@sonic.net,iet@portti.edita.fi,iet@myservice.com X-SMTP-PEER-INFO: [194.134.96.21] Resent-Message-ID: <"CeItxB.A.sgC.Pj4n4"@glacier> 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 

internet spy



 

INTERNET 
SPY ORDER FORM!!




////////////////////////////////////////
This is a one time mailing! No need to be removed. 
////////////////////////////////////////

CONFIDENTIAL INFORMATION YOU WANT TO KNOW.

This is the software they want banned from the INTERNET!

"The Internet Desktop Spy" shows you how to get the facts on anyone using the 

Internet.

LOCATE MISSING PERSONS, find lost relatives, obtain addresses and phone 
numbers of old school friends, even skip trace dead beat spouses.  This is 
not a Private Investigator, but a SOFTWARE program DESIGNED to automatically 
CRACK YOUR CASE with links to thousands of Public Record Databases

Find out SECRETS about your relatives, friends, enemies, and everyone else! 
-- even your spouse! With the New - "Internet Desktop SPY"

You will be AMAZED at what you can discover:

LICENSE PLATE NUMBER - Get anyone's name and address with just a license 
plate number! (Find that girl you met in traffic!)

DRIVING RECORD - Get anyone's driving record!

SOCIAL SECURITY NUMBER - Trace anyone by social security number!

ADDRESS - Get anyone's address with just a name!

UNLISTED PHONE NUMBERS - Get anyone's phone number with just a name- even 
unlisted numbers!

LOCATE - Long lost friends, relatives, a past lover who broke your heart!

E-MAIL - Send anyone anonymous e-mail that's completely untraceable!

DIRTY SECRETS - Discover dirty secrets your in-laws don't want you to know!

INVESTIGATE ANYONE - Use the sources that private investigators use (all on 
the Internet) secretly!

EX-SPOUSE - Learn how to get information on an ex-spouse that will help you 
win in court! (Dig up old skeletons)

CRIMINAL SEARCH - BACKGROUND CHECK - Find out about your daughter's 
boyfriend! (or her husband)

FIND OUT - If you are being investigated!

NEIGHBORS - Learn all about your mysterious neighbors!  Find out what they 
have to hide!

PEOPLE YOU WORK WITH - Be astonished by what you'll learn about the people 
you work with!

EDUCATION VERIFICATION - Did he really graduate college?  Find out!

"The Internet Desktop Spy" will help you discover ANYTHING about anyone, with 

clickable hyperlinks and no typing in Internet addresses!  Just download the 
software and go!  You will be shocked and amazed by the secrets that can 
be discovered about absolutely everyone!  Find out the secrets they don't 
want you to know!  About others, about yourself!

LIMITED TIME OFFER -- ORDER TODAY!  ONLY $20 (US)

You can dowmload the  "The Internet DeskTop Spy" software NOW so you can 
begin 
discovering all the secrets you ever wanted to know!  You can know EVERYTHING 

about ANYONE with "The Internet DeskTop Spy" software.  

- Works with all browsers and all versions of AOL
- PC Versions available Only!

DON'T WAIT TO GET STARTED… It's as easy as 1, 2, 3.  
ORDER TODAY - While this software is still legal!

VISA/MC ONLY

For Credit Card Orders, Click on the link below:

Click
Here To Order!

NOTES:
- This program will not work on Windows 3.11 and older
- DISCLAIMER - The seller of this powerful software resource will not be held 

responsible for how the purchaser chooses to use its resources.
From list@netscape.com Tue Feb 8 03:31: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 DAA12404 for ; Tue, 8 Feb 2000 03:31: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 AAA25523; Tue, 8 Feb 2000 00:26:30 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA00490; Tue, 8 Feb 2000 00:29:55 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 00:29:55 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Tue, 8 Feb 2000 00:30:22 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: IETF ldapext WG Subject: what ldapext-locate is about Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"OGY69B.A.YH.DQ9n4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com During the recent thread of comments on draft-ietf-ldapext-locate-01.txt Bruce Greenblatt asked this question: > 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. and I think others asked it too, more or less. I think this question is based on a misconception of the issue that draft-ietf-ldapext-locate-01.txt is addressing. Since I was confused about this too and only came to understand it after some reflection, let me argue the point here so we can all (I hope) be clear about it. (I've also submitted text to the document authors along this line.) The first parameter of the Search operation is the baseObject, "the LDAPDN that is the base object entry relative to which the search is to be performed." All other substantive LDAP operations, ie Modify, Add, Delete, ModifyDN, and Compare also all have a DN as the first parameter, in each case specifying the directory object on which the operation is to be performed. To successfully perform any of these operations, the request must eventually be processed by a server that stores that DN (or the subtree, in the case of Search) locally. Finding that server, based on the DN in the request, is precisely what this document is about, no more, no less. This is an *internal* directory function that has to happen for any LDAP operation to be carried out. Whether it is done by the client or the server doesn't matter for this discussion. The fact that in practice, these days, this function is almost always null -- because servers don't know anything about other servers, and clients are configured only to talk to particular servers for particular data and never ask about anything else -- tends to obscure this point; but opening up the current narrow-focus nature of LDAP directory usage is exactly what this spec is about. On the other hand, finding a directory entry for a person who has a particular email address, as above, is an *application* that uses the directory, not an internal functional component of the directory itself. It's the same kind of thing as finding all entries of people at UW with the surname "Lee", or using the directory to route email, or any of the other million directory-enabled apps that specify what the DS client should do (construct request 'R' using DN 'D', use the value of attribute 'X' to do 'Y', etc), and what schema and data should be in the DIT to support the app. These sorts of things certainly need to be documented, but in their own docs. The observation that, when looking up info about a DNS-named thing, the DNS name is first turned into a DC-name-based DN, then back into a DNS name to do the SRV lookup, might lead one to believe that the DN is superfluous and can just be skipped but clearly this isn't so. Note that it's the client application that does the DNS-to-DN to construct the request, while it will likely be the server, doing chaining or referral, that does the DN-to-DNS before doing the SRV record lookup. Agreed? - RL "Bob" From list@netscape.com Tue Feb 8 06:33:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13759 for ; Tue, 8 Feb 2000 06:33:50 -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 DAA01638; Tue, 8 Feb 2000 03:30:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA28827; Tue, 8 Feb 2000 03:32:41 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 03:32:41 -0800 (PST) Message-Id: <200002081132.GAA13712@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-acl-reqts-03.txt Date: Tue, 08 Feb 2000 06:32:37 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"3eTVGD.A.JCH.X7_n4"@glacier> 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 : Access Control Requirements for LDAP Author(s) : E. Stokes, D. Byrne, B. Blakley, P. Behera Filename : draft-ietf-ldapext-acl-reqts-03.txt Pages : 11 Date : 07-Feb-00 This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-reqts-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-acl-reqts-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-acl-reqts-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-acl-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-acl-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125741.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Feb 8 14:22:51 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08438 for ; Tue, 8 Feb 2000 14:22:50 -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 LAA24592; Tue, 8 Feb 2000 11:18:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA13805; Tue, 8 Feb 2000 11:21:41 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 11:21:41 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 08 Feb 2000 12:20:34 -0700 From: "Mark Meredith" To: Cc: Subject: please publish draft-mmeredith-rootdse-vendor-info-01.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_3861ADA4.EE8FBB57" Resent-Message-ID: <"rfBqQD.A.ZXD.DzGo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_3861ADA4.EE8FBB57 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish - this reflects the changes requested via feed back on = draft-00. Please review this draft and submit comments. -Mark Mark Meredith Novell Inc 122 E. 1700 S. Provo UT 84606 mark_meredith@novell.com 801-861-2645 --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- --=_3861ADA4.EE8FBB57 Content-Type: text/plain Content-Disposition: attachment; filename="draft-mmeredith-rootdse-vendor-info-01.txt" Individual Submission to the LDAPExt Working Group Mark Meredith Internet Draft Novell Inc. Document: draft-mmeredith-rootdse-vendor-info-01.txt February 7, 2000 Category: Proposed Standard Storing Vendor Information in the root DSE 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 made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list ietf-ldapext@netscape.com or the author. 1. Abstraction This document specifies two new attributes, vendorName and vendorVersion that can be included in the root DSE to contain vendor-specific information. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2219] 3. Overview The root DSE query is a mechanism used by clients to find out what controls, extensions, etc. is available from a given LDAP server. It is useful to be able to query an LDAP server to determine the vendor of that server and see what version of that vendor’s code is currently installed. Since vendors can implement X- options for attributes, classes, and syntaxes (described in section 4 of [RFC2251] and section 4 of [RFC2252] ) that may or may not be published, this would allow users or applications to be able to determine if these features are available from a given server. It is also possible for vendors to have an LDAP server implementation to be incomplete in some respect or to have M. Meredith Expires August-2000 1 LDAP root DSE to display vendor information February 2000 implementation quirks that must be worked around until they can be fixed in the subsequent release. The vendorName and vendorVersion allow client developers to identify a specific implementation of LDAP and work around any shortcomings of that implementation as needed. 4. Vendor specific information This is an addition to the Server-specific Data Requirements defined in section 3.4 of [RFC-2251] and the associated syntaxes defined in section 4 of [RFC-2252]. - vendorName All LDAP server implementations SHOULD maintain a vendorName, which is generally the name of the company that wrote the LDAP Server code like "Novell, Inc." This is single-valued so that it will only have one vendor. ( 2.16.840.1.113719.1.27.4.43 NAME 'vendorName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE USAGE dSAOperation ) - vendorVersion All LDAP server implementations SHOULD maintain a vendorVersion, which is the release number of the LDAP server product, (as opposed to the supportedLDAPVersion, which specifies the version of the LDAP protocol supported by this server). This is single- valued so that it will only have one version number. ( 2.16.840.1.113719.1.27.4.44 NAME 'vendorVersion' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE USAGE dSAOperation ) 5. Notes to Implementers Implementers may want to consider tying the vendorVersion attribute value to the build mechanism so that it is automatically updated when the version number changes. 6. Notes to Client Developers The use of vendorName and vendorVersion SHOULD NOT be used to discover features. It is just an informational attribute. If a client relies on a vendorVersion number then that client MUST be coded to work with later versions and not just one version and no other. 7. Security Considerations The vendorName and vendorVersion attributes are provided only as an aid to help client implementers assess what features may or may not exist in a given server implementation. Server and application implementers should realize that the existence of a given value in the vendorName or vendorVersion attribute is no guarantee that the server was actually built by the asserted vendor or that its version is the asserted version and should act accordingly. M. Meredith Expires August-2000 2 LDAP root DSE to display vendor information February 2000 8. References RFC-2219 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 RFC-2026 Bradner, S., "The Internet Standards Process-Revision 3", BCP 9, RFC 2026, October 1996. RFC-2251 Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997 RFC-2252 Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997 9. Acknowledgments The author would like to thank the generous input and review by individuals at Novell including but not limited to Jim Sermersheim, Mark Hinckley, Renea Campbell, and Roger Harrison. 10. Author’s Addresses Mark Meredith Novell Inc. 122 E. 1700 S. Provo, UT 84606 Phone: 801-861-2645 Email: mark_meredith@novell.com Full Copyright Statement Copyright (c) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. M. Meredith Expires August-2000 3 --=_3861ADA4.EE8FBB57-- From list@netscape.com Tue Feb 8 14:34: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 OAA08897 for ; Tue, 8 Feb 2000 14:34: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 LAA02043; Tue, 8 Feb 2000 11:32:02 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA27088; Tue, 8 Feb 2000 11:33:45 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 11:33:45 -0800 (PST) Message-Id: <3.0.5.32.20000208113335.0095d8a0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Feb 2000 11:33:35 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: substring matching rules Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"XA4PPD.A.wmG.Y-Go4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com RFC 2252, 8.3 says: The Substring Assertion syntax is used only as the syntax of assertion values in the extensible match. It is not used as the syntax of attributes, or in the substring filter. ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) [...] Servers SHOULD be capable of performing the following matching rules, which are used in substring filters. ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) I find this a bit confusing. The SYNTAX should not be used as part of substring filters but then is used to specify the syntax used with substring filters. Shouldn't the syntax of caseIgnoreSubstringsMatch, for use with substring filters, have a syntax of DirectoryString like other caseIngore*Match filters and that a separate matching rule be defined specifically for use extended filters? Is it safe to presume that the syntax of asserted substring components are of the same syntax as the attribute value being tested? From list@netscape.com Tue Feb 8 14:43:26 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09150 for ; Tue, 8 Feb 2000 14:43:25 -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 LAA29205; Tue, 8 Feb 2000 11:38:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA01456; Tue, 8 Feb 2000 11:42:15 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 11:42:15 -0800 (PST) From: kime@freeservers.com Message-Id: <200002081939.OAA09063@ec1.maxime.net> Date: Tue, 08 Feb 2000 13:35:33 To: X-Mailer: Microsoft Outlook Express 4.72.3110.7 Subject: Professional email services. MIME-Version: 1.0 Content-Type: text/plain X-In-Response-To: 087D4275A MessageID: <5f1sh5f7ucvivtt.080220001335@LocalHost> X-See-Also: 08760D117 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Message-ID: <"kHnpCC.A.eW.WGHo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Thanks to the invention of the Internet. Anyone can now market their ideas and products to millions of people. Imagine having a product or idea and selling it for only $10. Now imagine sending an ad for your product or idea to 25 million people! If you only get a 1/10 of 1% response you have just made $250,000!! You hear about people getting rich off the Internet everyday on TV, now is the perfect time for you to jump in on all the action. Targeted email works!! Email marketing is the most cost effective form of marketing available. Call now to order 702-248-1057 We are terribly sorry if you have received this message in error. If you wish to be removed go to 721064@caramail.com and type in the word "REMOVE" From list@netscape.com Tue Feb 8 15:31: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 PAA10389 for ; Tue, 8 Feb 2000 15:31:34 -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 MAA13240; Tue, 8 Feb 2000 12:28:46 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA26419; Tue, 8 Feb 2000 12:30:28 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 12:30:28 -0800 (PST) Message-Id: <3.0.5.32.20000208123016.0092f490@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Feb 2000 12:30:16 -0800 To: "Mark Meredith" From: "Kurt D. Zeilenga" Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"j-wG.A.gcG.jzHo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Mark, a few comments: I suggest that this draft be a informational elective feature. I believe that prior operational experience with such features have proven to be source of numerous interoperability problems. You'll end up with clients that only support select versions of select vendor products and other vendors resorting to spoofing the vendor names/versions. (We've already have received requests (and patches) from users to do exactly this!). I suggest adding an applicability statement to the overview, such as: This document describes an elective feature which LDAP servers MAY implement. I then suggest that the applicability statement in each attribute descriptions be replaced with a technical specification. The value of vendorName contains the name of the vendor producing or providing server implementation. Example: "Novell, Inc." Likewise for vendorVersion: The value of vendorVersion contains the string indicating the version of the directory implementation. Example: "NDS 2100-r1.2.3/NT4SP3/US-crypto-128-1.1/TurboBlaster-v2 compat FooDir" No matching rules are defined. An EQUALITY matching rule should minimally be defined. I suggest caseExactMatch. Security Considerations: You may want to add a note publishing specific vendor information may be used by clients to determine what security holes a server provides (by feature or flaw). You may note that servers MAY restrict access to vendorName/vendorVersion and clients SHOULD NOT expect such attribute to be available. From list@netscape.com Tue Feb 8 15:45: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 PAA10729 for ; Tue, 8 Feb 2000 15:45: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 MAA15900; Tue, 8 Feb 2000 12:43:02 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA01881; Tue, 8 Feb 2000 12:44:46 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 12:44:46 -0800 (PST) From: "Alexis Bor" To: "Mark Meredith" Cc: Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Date: Tue, 8 Feb 2000 12:43:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Resent-Message-ID: <"aZ3-b.A.Hd.9AIo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark, An initial reading of your draft raises lots of questions and concerns. I agree that from a client perspective, it would help to know how to behave in specific situations. At the same time, a server may want to also know how to behave when communicating with another server. It is a sad statement when client applications have to build up a knowledge base to be able to work in every LDAP Server environment. This raises the value of groups like the Directory Interoperability Forum (DIF) - which Novell and many others are members of. I went to the last DIF meeting in San Diego and wasn't fully convinced of their long-term relevance. However, I am now convinced that we need such an industry group to solve/document interoperability issues. Just think, when we have a directory of LDAP servers, you can quickly connect to each server and build a profile of the brands that are out there and maintain a census of brands and versions. I don't know if this is good or bad - but when I was a senior at UC Irvine, we had to take a class on the "Social Impacts of Computing on Society". This certainly would have been a discussion topic. Unfortunately, I don't see any other way for an application to manage its behavior based on which vendor product it is connected to. The current process for LDAP standards has intentionally built a loose protocol that makes behavior inconsistent between vendors. This is chaos that most of us are willing to live with. Too bad... -- Alexis Alexis Bor Directory Works, Inc. alexis.bor@directoryworks.com http://www.directoryworks.com -----Original Message----- From: Mark Meredith [mailto:MMEREDIT@novell.com] Sent: Tuesday, February 08, 2000 11:21 AM To: internet-drafts@ietf.org Cc: ietf-ldapext@netscape.com Subject: please publish draft-mmeredith-rootdse-vendor-info-01.txt Please publish - this reflects the changes requested via feed back on draft-00. Please review this draft and submit comments. -Mark Mark Meredith Novell Inc 122 E. 1700 S. Provo UT 84606 mark_meredith@novell.com 801-861-2645 --------------------- A boat in the harbor is safe, but that is not what boats are for. --John A. Shed --------------------- From list@netscape.com Tue Feb 8 18:08: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 SAA13278 for ; Tue, 8 Feb 2000 18:08:41 -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 PAA09659; Tue, 8 Feb 2000 15:05:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA00989; Tue, 8 Feb 2000 15:07:33 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 15:07:33 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Date: Tue, 8 Feb 2000 23:07:04 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: <3.0.5.32.20000207094004.009392d0@infidel.boolean.net> X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"EZzfC.A.LP.0GKo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Mon, 7 Feb 2000 09:40:11 -0800 (PST) Date sent: Mon, 07 Feb 2000 09:40:04 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: RFC2251: RootDSE subschemasubentry issue Forwarded by: ietf-ldapext@netscape.com > As previously noted <8525679B.003DD02B.00@D51MTA04.pok.ibm.com>, > RFC 2251 states subschemaSubentry attribute type within the > Root DSE may contain multiple values though the attribute type > is single valued. Sorry, I dont follow this. What do you mean by "THe attribute type is single valued." Do you mean the attribute type definition mandates a single valued attribute? This is surely wrong, as the definition must allow for multiple values. > > I do not believe it necessary to provide a mechanism to allow > clients to obtain a complete list of subschema entries (or > subentries) known to this server. This is part of the confusion, and is due to poor wording in 2251. What the RFC is trying to say is "subschema entries known to be controlling the entries held in this server". It does not mean subschema entries anywhere in the world that this server happens to know about. If you read further in the RFC you will find some limited clarification about subschema subentries for master and copy entries viz: If the server does not master entries and does not know the locations of schema information, the subschemaSubentry attribute is not present in the root DSE. If the server masters directory entries under one or more schema rules, there may be any number of values of the subschemaSubentry attribute in the root DSE. Again, this is ambiguously worded, as "may be any number of values" should really be "will be an equivalent number of values" > This list could be quite > large and, IMO, rather useless. Applications need to known > which subschema controls which entries. Agreed. This is due to a wrong interpretation of the RFC (due to ambiguous wording) > > I suggest that applications obtain the DN of the subschema entry > (subentry) from either the entry(ies) they intend to access or > from the entry at the root of the naming context. In general a client may not know the root of the naming context, but will know the root of the DIT, hence the ability to find the subschema entry from the root. > > To resolve this issue, I suggest: > > RFC 2251, 3.4 "--subsubschemaSubentry" subsection be removed > and that a note be added to the end of the section: I disagree, but a better wording should be used. > > Note: the subsubschemaSubentry attribute type, if > present, contains the Distinguished Name of the > subschema entry (or subentry) which controls the > schema for the Root DSE. This is wrong. The subschema subentry does not control the schema of the root DSE - nothing does. Rather it controls the schema of a naming context. David > > Comments? > > Kurt > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Tue Feb 8 18:44:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13592 for ; Tue, 8 Feb 2000 18:44:02 -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 PAA05377; Tue, 8 Feb 2000 15:39:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA14888; Tue, 8 Feb 2000 15:42:53 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 15:42:53 -0800 (PST) Message-Id: <3.0.5.32.20000208154242.009699c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Feb 2000 15:42:42 -0800 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC2251: RootDSE subschemasubentry issue Cc: ietf-ldapext@netscape.com In-Reply-To: References: <3.0.5.32.20000207094004.009392d0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"QSayn.A.JoD.7nKo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:07 PM 2/8/00 -0000, David Chadwick wrote: >> As previously noted <8525679B.003DD02B.00@D51MTA04.pok.ibm.com>, >> RFC 2251 states subschemaSubentry attribute type within the >> Root DSE may contain multiple values though the attribute type >> is single valued. > >Sorry, I dont follow this. What do you mean by "THe attribute type is >single valued." Do you mean the attribute type definition mandates a >single valued attribute? Yes. RFC 2252, 5.1.5. subschemaSubentry The value of this attribute is the name of a subschema entry (or subentry if the server is based on X.500(93)) in which the server makes available attributes specifying the schema. ( 2.5.18.10 NAME 'subschemaSubentry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION SINGLE-VALUE USAGE directoryOperation ) >This is surely wrong, as the definition must >allow for multiple values. I believe SINGLE-VALUED is appropriate as an entry can only have one controlling subschema subentry. I believe the use of this attribute type when the RootDSE to list available subschema subentries is inappropriate as it imparts no knowledge to the client as to which value controls which entries. >If the server does not master entries and does >not know the locations > of schema information, the subschemaSubentry >attribute is not present > in the root DSE. If the server masters >directory entries under one > or more schema rules, there may be any number >of values of the > subschemaSubentry attribute in the root DSE. Which implies that the subschema controlling an entry may not be listed in the RootDSE whilst other subschemesubentries are listed, such as when the entry is not mastered by the server (and subschema not published this slaves), yet other name contexts are. >Again, this is ambiguously worded, as "may be any >number of values" should really be "will be an >equivalent number of values" In the Root DSE, which subschemasubentry value(s) belongs to which namingContexts value(s)? >> To resolve this issue, I suggest: >> >> RFC 2251, 3.4 "--subsubschemaSubentry" subsection be removed >> and that a note be added to the end of the section: > >I disagree, but a better wording should be used. > >> >> Note: the subsubschemaSubentry attribute type, if >> present, contains the Distinguished Name of the >> subschema entry (or subentry) which controls the >> schema for the Root DSE. > >This is wrong. The subschema subentry does not control the >schema of the root DSE - nothing does. Something must... a client should be able to determine the schema of attributes provided in the RootDSE and should have some mechanism to determine which schema controls the RootDSE. >Rather it controls the >schema of a naming context. Which naming context? A server can support multiple naming contexts each with different controlling subschemas. The subschemasubentry values of the RootDSE are fairly worthless without knownledge of which value controls which naming context. From list@netscape.com Tue Feb 8 20:58: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 UAA14667 for ; Tue, 8 Feb 2000 20:58: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 RAA05642; Tue, 8 Feb 2000 17:55:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA05679; Tue, 8 Feb 2000 17:56:41 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 17:56:41 -0800 (PST) Message-Id: <3.0.5.32.20000208175632.00960270@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Feb 2000 17:56:32 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: substring matching rules In-Reply-To: <3.0.5.32.20000208113335.0095d8a0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"BL5c5.A.dYB.YlMo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:33 AM 2/8/00 -0800, Kurt D. Zeilenga wrote: >RFC 2252, 8.3 says: > ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) > Interesting enough, the inetOrgPerson draft says: 13.3.3. Additional matching rules from X.520 ( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) I don't have a copy of X.520 to confirm correctness. But appear so. When used in a substrings filter, the asserted substrings are each of directoryString syntax, not each a substringsAssertion syntax. The caseIgnoreSubstringsMatch implies that in a substrings filter, each of the asserted substrings are each of substringsAssertion syntax. This is incorrect. Each should be a directoryString. I believe two matching rules, one for substrings filters and one for extended matching using substrings assertions, are needed for every match algorithm. That is: ( .1 NAME 'mySubstringsMatch' DESC 'for use with substring filters' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( .2 NAME 'mySubstringsExtendedMatch' DESC 'for use with extended match filters' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) (where is replaced with some valid OID). From list@netscape.com Wed Feb 9 00:25: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 AAA18827 for ; Wed, 9 Feb 2000 00:24:29 -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 VAA21958; Tue, 8 Feb 2000 21:21:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA25953; Tue, 8 Feb 2000 21:23:00 -0800 (PST) Resent-Date: Tue, 8 Feb 2000 21:23:00 -0800 (PST) Message-ID: <007b01bf72bd$f47a3ba0$90071896@sktelecom.com> From: =?ks_c_5601-1987?B?wMy1v7Hi?= To: Subject: Question about OID(Object Identifier) Date: Wed, 9 Feb 2000 14:24:20 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01BF7309.5A90C440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Resent-Message-ID: <"DrnvWC.A._UG.vmPo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_0072_01BF7309.5A90C440 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQooMi41LjQuMjAgIE5BTUUgoa50ZWxlcGhvbmVOdW1iZXKhryBFUVVBTElUWSB0ZWxlcGhvbmVO dW1iZXJNYXRjaA0KU1VCU1RSIHRlbGVwaG9uZU51bWJlclN1YnN0cmluZ3NNYXRjaA0KU1lOVEFY IDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjE1ezMyfSkpDQoNCkFib3ZlIGlzIHRha2VuIGZy b20gTERBUCB2MyBSRkMgMjU1Mi4gSSdkIGxpa2UgdG8ga25vdyB3aGVyZSBjYW4gSSBmaW5kIHRo ZSBkb2N1bWVudHMgYWJvdXQgbmFtaW5nIGNvbnZlbnRpb25zLiBGb3IgZXhhbXBsZSAyLjUuNC4y MCwgd2hhdCBkb2VzIDIsIDUsIDQsIDIwIGVhY2ggcmVwcmVzZW50PyBBbmQgYWxzbyB3aGljaCBk b2N1bWVudCBkb2VzIGhhdmUgaW5mb3JtYXRpb24gYWJvdXQgZWFjaCBkZWNpbWFsIG51bWJlciBv ZiBjbGFzcyBpZGVudGlmaWVyPyAoSSBrbm93IGZyb20gYSBsaXR0bGUgZXhwZXJpZW5jZSBvZiBT Tk1QIHRoYXQgMSBtZWFucyBJU08sICBhbmQgc29tZXRoaW5nIG1lYW5zIERPRCwgYW5kIHNvbWV0 aGluZyBtZWFucyBJbnRlcm5ldCwgUHJpdmF0ZSAuLi4uKSANCkFueSBoZWxwIHdpbGwgYmUgZ3Jl YXRseSBhcHByZWNpYXRlZC4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K Z2FsYWhhZEBuZXRzZ28uY29tDQpEb25na2llIExlaWdoDQpNb2JpbGU6KzgyLTExLTc1OC00MzU5 DQpDb3JlIE5ldHdvcmsgRGV2ZWxvcG1lbnQgVGVhbQ0KU0sgVGVsZWNvbQ0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo= ------=_NextPart_000_0072_01BF7309.5A90C440 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPigyLjUuNC4yMCZuYnNwOyBOQU1FIKGudGVs ZXBob25lTnVtYmVyoa8gRVFVQUxJVFkgDQp0ZWxlcGhvbmVOdW1iZXJNYXRjaDxCUj5TVUJTVFIg dGVsZXBob25lTnVtYmVyU3Vic3RyaW5nc01hdGNoPEJSPlNZTlRBWCANCjEuMy42LjEuNC4xLjE0 NjYuMTE1LjEyMS4xLjE1ezMyfSkpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QWJvdmUgaXMgdGFrZW4gZnJvbSBM REFQIHYzIFJGQyAyNTUyLiBJJ2QgbGlrZSB0byBrbm93IHdoZXJlIA0KY2FuIEkgZmluZCB0aGUg ZG9jdW1lbnRzIGFib3V0IG5hbWluZyBjb252ZW50aW9ucy4gRm9yIGV4YW1wbGUgMi41LjQuMjAs IHdoYXQgDQpkb2VzIDIsIDUsIDQsIDIwIGVhY2ggcmVwcmVzZW50PyBBbmQgYWxzbyZuYnNwO3do aWNoIGRvY3VtZW50IGRvZXMgaGF2ZSANCmluZm9ybWF0aW9uIGFib3V0IGVhY2ggZGVjaW1hbCBu dW1iZXIgb2YgY2xhc3MgaWRlbnRpZmllcj8gKEkga25vdyZuYnNwO2Zyb20gYSANCmxpdHRsZSBl eHBlcmllbmNlIG9mIFNOTVAgdGhhdCAxIG1lYW5zIElTTywgIGFuZCBzb21ldGhpbmcgbWVhbnMg RE9ELCBhbmQgDQpzb21ldGhpbmcgbWVhbnMgSW50ZXJuZXQsIFByaXZhdGUgLi4uLikgPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QW55IGhlbHAgd2lsbCBiZSBncmVhdGx5IGFwcHJl Y2lhdGVkLjwvRElWPjwvRk9OVD4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRElWPjwvRk9O VD4NCjxESVY+PEZPTlQgc2l6ZT0yPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 QlI+PEEgDQpocmVmPSJtYWlsdG86Z2FsYWhhZEBuZXRzZ28uY29tIj5nYWxhaGFkQG5ldHNnby5j b208L0E+PEJSPkRvbmdraWUgDQpMZWlnaDxCUj5Nb2JpbGU6KzgyLTExLTc1OC00MzU5PEJSPkNv cmUgTmV0d29yayBEZXZlbG9wbWVudCBUZWFtPEJSPlNLIA0KVGVsZWNvbTxCUj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0072_01BF7309.5A90C440-- From list@netscape.com Wed Feb 9 08:26: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 IAA05525 for ; Wed, 9 Feb 2000 08:26: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 FAA20519; Wed, 9 Feb 2000 05:23:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA21736; Wed, 9 Feb 2000 05:25:11 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 05:25:11 -0800 (PST) Date: Wed, 09 Feb 2000 07:24:05 -0600 From: Mark Wahl Subject: Re: RFC2251: RootDSE subschemasubentry issue In-reply-to: "Your message of Mon, 07 Feb 2000 09:40:04 PST." <3.0.5.32.20000207094004.009392d0@infidel.boolean.net> Sender: Mark.Wahl@INNOSOFT.COM To: "Kurt D. Zeilenga" Cc: ietf-ldapext@netscape.com Message-id: <7078.950102645@threadgill.austin.innosoft.com> Resent-Message-ID: <"2Yx4-C.A.WTF.2qWo4"@glacier> 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 role of the subschemaSubentry attribute of the root DSE was discussed on the IETF-ASID mailing list during the design of LDAPv3. It provides an important adminstrative function to allow management clients to determine the capabilities of an LDAP server and the data it contains. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 9 08:29:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05561 for ; Wed, 9 Feb 2000 08:29: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 FAA03711; Wed, 9 Feb 2000 05:24:33 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA22633; Wed, 9 Feb 2000 05:27:56 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 05:27:56 -0800 (PST) Date: Wed, 09 Feb 2000 07:26:51 -0600 From: Mark Wahl Subject: Re: substring matching rules In-reply-to: "Your message of Tue, 08 Feb 2000 17:56:32 PST." <3.0.5.32.20000208175632.00960270@infidel.boolean.net> Sender: Mark.Wahl@INNOSOFT.COM To: "Kurt D. Zeilenga" Cc: ietf-ldapext@netscape.com Message-id: <7416.950102811@threadgill.austin.innosoft.com> Resent-Message-ID: <"S3Yw6D.A.XhF.btWo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Thanks for pointing out this discrepancy in inetorgperson section 13.3.3. I'll check with X.501/X.520 and suggest a change to Mark Smith. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 9 10:06:00 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07646 for ; Wed, 9 Feb 2000 10:05:59 -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 HAA10464; Wed, 9 Feb 2000 07:01:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA14695; Wed, 9 Feb 2000 07:05:17 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 07:05:17 -0800 (PST) Message-ID: <38A181E4.C683919C@netscape.com> Date: Wed, 09 Feb 2000 10:04:04 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Wahl CC: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Subject: Re: substring matching rules References: <7416.950102811@threadgill.austin.innosoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JA1JBC.A.VlD.sIYo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark Wahl wrote: > > Thanks for pointing out this discrepancy in inetorgperson section 13.3.3. > I'll check with X.501/X.520 and suggest a change to Mark Smith. Yes, this looks like a bug in the inetOrgPerson document... to match X.520, the definition of caseExactSubstringsMatch should be: ( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) I replaced the DirectoryString syntax OID with the OID for SubstringAssertion. Correct? According to X.520, the values that make up a Substring Assertion are each of syntax DirectoryString: 6.1.3 Case Ignore Substrings Match The Case Ignore Substrings Match rule determines whether a presented value is a substring of an attribute value of type DirectoryString, without regard to the case (upper or lower) of the strings. caseIgnoreSubstringsMatch MATCHING-RULE ::= { SYNTAX SubstringAssertion ID id-mr-caseIgnoreSubstringsMatch } SubstringAssertion ::= SEQUENCE OF CHOICE { initial [0] DirectoryString {ub-match}, any [1] DirectoryString {ub-match}, final [2] DirectoryString {ub-match} } -- at most one initial and one final component Kurt, I think the syntaxes associated with matching rules refer to the syntax of a presented value, e.g., a value that is in a search filter. That's how I think about it anyway.... -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Wed Feb 9 10:08: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 KAA07675 for ; Wed, 9 Feb 2000 10:08: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 HAA10966; Wed, 9 Feb 2000 07:04:02 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA15550; Wed, 9 Feb 2000 07:07:31 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 07:07:31 -0800 (PST) From: "Peter Strong" To: "Kurt D. Zeilenga" , Mark Meredith Cc: ietf-ldapext Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Date: Wed, 9 Feb 2000 10:10:06 -0500 Message-ID: <002401bf730f$bf525190$3750fb8d@net-pstrong.corpnorth.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <3.0.5.32.20000208123016.0092f490@infidel.boolean.net> Resent-Message-ID: <"ySUQRB.A.syD.zKYo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt/Mark > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Tuesday, February 08, 2000 3:30 PM > To: Mark Meredith > Cc: ietf-ldapext > Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt > > Mark, a few comments: > > I suggest that this draft be a informational elective feature. As a designer of products that have to support multiple directory implementations, I have to disagree. Vendor identification information should be mandatory in all directory implementations until such time as vendors get together, solve their differences and make their directory implementations truely interoperable. (I'm not holding my breath for this momentous event!) > I believe that prior operational experience with such features > have proven to be source of numerous interoperability problems. I don't think that providing useful information is the source of interoperability problems. The source of interoperability problems is the basic fact that vendors will always implement part or all of a standard in order to say that they comply and will then add other features/bells/whistles to differentiate their product from their competitor's. This may cause some clients difficulties, but it's the way the world works and the way that new technologies are introduced and (eventually) standardized. As we progress with directory technology, more and more of the basic standards are implemented by vendors, but this implementation takes place at different rates for different vendors. Knowing the vendor and the version via a "standard" mechanism simply makes it easier to determine what implementation you're talking to and what "implementation quirks" might exist. I think Mark makes it clear that clients shouldn't depend on this information too heavily: The use of vendorName and vendorVersion SHOULD NOT be used to discover features. It is just an informational attribute. If a client relies on a vendorVersion number then that client MUST be coded to work with later versions and not just one version and no other. > You'll end up with clients that only support select versions > of select vendor products and other vendors resorting to > spoofing the vendor names/versions. (We've already have > received requests (and patches) from users to do exactly > this!). This is like saying that indicator lights on cars are dangerous because a driver may signal one way and turn the other; therefore, we shouldn't have signal lights on cars! If you're stupid enough to develop a client with hard-coded limits based on this information, you get what you deserve! If you have vendors spoofing this information, they'll get what they deserve - in the marketplace! All debate aside, this "feature" is simple, straightforward and useful to those of us who must attempt to integrate our products with multiple directory implementations. We're currently faced with delivering product that must interwork with Netscape, Novell, Active Directory and an in-house directory, with others on the way. As one example of what we have to deal with, each of these directories has a subtly different way of altering the schema definitions (even though there is a standard for this behaviour). We currently have to perform some really disgusting, poking and prodding to determine what type of directory we're talking to in order to perform the schema changes properly. We'd rather just query some attributes at a well-known location and perform the appropriate schema update based on that information. Directory implementations will always have differences. It's that simple. If we're arguing about such a simple addition on the basis that it may disrupt the ivory tower of interoperability, I fail to see how far more complex aspects of directory usage will ever be standardized or agreed to. > I suggest adding an applicability statement to the overview, > such as: > This document describes an elective feature which LDAP > servers MAY implement. > > I then suggest that the applicability statement in each > attribute descriptions be replaced with a technical > specification. > The value of vendorName contains the name of the vendor > producing or providing server implementation. > Example: "Novell, Inc." > > Likewise for vendorVersion: > The value of vendorVersion contains the string indicating > the version of the directory implementation. > Example: "NDS > 2100-r1.2.3/NT4SP3/US-crypto-128-1.1/TurboBlaster-v2 compat FooDir" > > No matching rules are defined. An EQUALITY > matching rule should minimally be defined. I suggest > caseExactMatch. > > Security Considerations: > > You may want to add a note publishing specific vendor > information may be used by clients to determine what > security holes a server provides (by feature or flaw). > > You may note that servers MAY restrict access to > vendorName/vendorVersion and clients SHOULD NOT > expect such attribute to be available. > > > Regards, Peter ------------------------------------------------------------------------ Peter Strong Software Architect Nortel Networks - Optivity Policy Services (OPS) and NetID pestrong@nortelnetworks.com (613) 831-6615 From list@netscape.com Wed Feb 9 10:48:31 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08399 for ; Wed, 9 Feb 2000 10:48:30 -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 HAA03029; Wed, 9 Feb 2000 07:45:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA25999; Wed, 9 Feb 2000 07:47:19 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 07:47:19 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com Subject: RE: substring matching rules Date: Wed, 9 Feb 2000 10:48:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"wLEzoB.A.7VG.FwYo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here's the X.511 definition of Filter. The need for two matching rules arises from the definition of substrings as three different value components each having the syntax of the substrings matching rule. The extensibleMatch component has only a single value component which, for a substring match, must be the same SEQUENCE defined in the strings component of the substrings filter item. Filter ::= CHOICE { item [0] FilterItem, and [1] SET OF Filter, or [2] SET OF Filter, not [3] Filter } FilterItem ::= CHOICE { equality [0] AttributeValueAssertion, substrings [1] SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), strings SEQUENCE OF CHOICE { initial [0] ATTRIBUTE.&Type ({SupportedAttributes}{@substrings.type}), any [1] ATTRIBUTE.&Type ({SupportedAttributes}{@substrings.type}), final [2] ATTRIBUTE.&Type ({SupportedAttributes}{@substrings.type})}}, greaterOrEqual [2] AttributeValueAssertion, lessOrEqual [3] AttributeValueAssertion, present [4] AttributeType, approximateMatch [5] AttributeValueAssertion, extensibleMatch [6] MatchingRuleAssertion } MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] SET SIZE (1..MAX) OF MATCHING-RULE.&id, type [2] AttributeType OPTIONAL, matchValue [3] MATCHING-RULE.&AssertionType ( CONSTRAINED BY { - matchValue must be a value of type specified by the &AssertionType field of -- one of the MATCHING-RULE information objects identified by matchingRule -- } ), dnAttributes [4] BOOLEAN DEFAULT FALSE } > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Tuesday, February 08, 2000 8:57 PM > To: ietf-ldapext@netscape.com > Subject: Re: substring matching rules > > > At 11:33 AM 2/8/00 -0800, Kurt D. Zeilenga wrote: > >RFC 2252, 8.3 says: > > ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) > > > > Interesting enough, the inetOrgPerson draft says: > > 13.3.3. Additional matching rules from X.520 > > ( 2.5.13.5 NAME 'caseExactMatch' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > ( 2.5.13.7 NAME 'caseExactSubstringsMatch' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > I don't have a copy of X.520 to confirm correctness. But > appear so. When used in a substrings filter, the asserted > substrings are each of directoryString syntax, not each a > substringsAssertion syntax. > > The caseIgnoreSubstringsMatch implies that in a substrings > filter, each of the asserted substrings are each of > substringsAssertion syntax. This is incorrect. Each should > be a directoryString. > > I believe two matching rules, one for substrings filters > and one for extended matching using substrings assertions, > are needed for every match algorithm. That is: > > ( .1 NAME 'mySubstringsMatch' > DESC 'for use with substring filters' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > ( .2 NAME 'mySubstringsExtendedMatch' > DESC 'for use with extended match filters' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) > > (where is replaced with some valid OID). > > From list@netscape.com Wed Feb 9 10:52: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 KAA08555 for ; Wed, 9 Feb 2000 10:52: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 HAA16057; Wed, 9 Feb 2000 07:48:02 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA27530; Wed, 9 Feb 2000 07:51:29 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 07:51:29 -0800 (PST) Date: Wed, 09 Feb 2000 09:50:14 -0600 From: Mark Wahl Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt In-reply-to: "Your message of Tue, 08 Feb 2000 12:20:34 MST." Sender: Mark.Wahl@INNOSOFT.COM To: Mark Meredith Cc: ietf-ldapext@netscape.com Message-id: <24386.950111414@threadgill.austin.innosoft.com> Resent-Message-ID: <"YmyTMB.A.ztG.A0Yo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Again, I believe this is the wrong approach to specifying server behavior and will not lead to interoperable clients. If there is a element of service X which two or more vendors implement differently, then there should be a proposal for a new attribute or similar for the server to advertise how it implements X. For example, allowsMultipleSubschemas: TRUE or accessControlScheme: 1.2.3.4 A standards-track proposal would be best for each, because during the course of discussion on the mailing list, we may find that the root DSE it not the best place for it, or there are more than an anticipated number of approaches and so what was a BOOLEAN option flag might be better described some other way. E.g. if a server uses chaining to automatically forward operations in a naming context to other servers which is a different implementation, then the capabilities that the chaining initiating server might advertise would potentially be more than if the server was not chaining. Another example. A server implementation allows the subschema subentry to be modified to introduce new object classes, for compatibility with Netscape-oriented clients. It also allows subsubentries to be created below the subschema subentry to introduce new object classes, for compatibility with Active Directory-oriented clients. That server would advertise: allowsSubschemaEntryModification: TRUE implementsSubschemaLikeActiveDirectory: TRUE > If a client relies on a vendorVersion number then that client MUST > be coded to work with later versions and not just one version and > no other. I don't see how this would work at all. If the first version of the server ships on 1-JAN-2000, the client ships on 1-JAN-2001 and the next version of the server makes an incompatible change to something and ships on 1-JAN-2002, that would mean that the client would need to know a year in advance what non-backwards compatible changes would be made. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 9 10:58:51 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08652 for ; Wed, 9 Feb 2000 10:58:50 -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 HAA05134; Wed, 9 Feb 2000 07:56:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA29277; Wed, 9 Feb 2000 07:57:48 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 07:57:48 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 09 Feb 2000 08:57:38 -0700 From: "Roger Harrison" To: , "Mark Meredith" Cc: Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"Dg2Hk.A.EJH.75Yo4"@glacier> 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 KAA08652 I agree wholeheartedly with your thoughts. For documented server features, the best way to specify server behavior is by some standard mechanism. There could even be some sort of grading provided to allow servers to specify which portions of a feature are implemented. However, every server implementation has "quirks" (also sometimes known as bugs), which may not be known in advance of shipping the server. A client that wants to interoperate with a server that doesn't do something quite right can be greatly aided if it knows the server's vendor and version. Often there's a way to work around quirky behavior if that information is available. Roger Harrison Novell, Inc. >>> Mark Wahl 02/09/00 08:51AM >>> Again, I believe this is the wrong approach to specifying server behavior and will not lead to interoperable clients. If there is a element of service X which two or more vendors implement differently, then there should be a proposal for a new attribute or similar for the server to advertise how it implements X. For example, allowsMultipleSubschemas: TRUE or accessControlScheme: 1.2.3.4 A standards-track proposal would be best for each, because during the course of discussion on the mailing list, we may find that the root DSE it not the best place for it, or there are more than an anticipated number of approaches and so what was a BOOLEAN option flag might be better described some other way. E.g. if a server uses chaining to automatically forward operations in a naming context to other servers which is a different implementation, then the capabilities that the chaining initiating server might advertise would potentially be more than if the server was not chaining. Another example. A server implementation allows the subschema subentry to be modified to introduce new object classes, for compatibility with Netscape-oriented clients. It also allows subsubentries to be created below the subschema subentry to introduce new object classes, for compatibility with Active Directory-oriented clients. That server would advertise: allowsSubschemaEntryModification: TRUE implementsSubschemaLikeActiveDirectory: TRUE > If a client relies on a vendorVersion number then that client MUST > be coded to work with later versions and not just one version and > no other. I don't see how this would work at all. If the first version of the server ships on 1-JAN-2000, the client ships on 1-JAN-2001 and the next version of the server makes an incompatible change to something and ships on 1-JAN-2002, that would mean that the client would need to know a year in advance what non-backwards compatible changes would be made. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 9 11:47:58 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10186 for ; Wed, 9 Feb 2000 11:47: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 IAA23609; Wed, 9 Feb 2000 08:43:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA22675; Wed, 9 Feb 2000 08:46:53 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 08:46:53 -0800 (PST) Date: Wed, 09 Feb 2000 10:45:43 -0600 From: Mark Wahl Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt In-reply-to: "Your message of Wed, 09 Feb 2000 08:57:38 MST." Sender: Mark.Wahl@INNOSOFT.COM To: Roger Harrison Cc: Mark Meredith , ietf-ldapext@netscape.com Message-id: <1014.950114743@threadgill.austin.innosoft.com> Resent-Message-ID: <"sl9WpB.A.-hF.8nZo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > However, every server implementation has "quirks" (also sometimes known as > bugs), which may not be known in advance of shipping the server. Correct. My concern is primarily that the draft is proposing also doing feature selection with this. I don't have a problem in general with using version names and numbers for bug detection though, so long as the client behavior is specified along the lines of If the client does not recognize the specific vendor/version as one it has its 'bug workaround needed' table, then the client must assume that the server it is talking to is complete and correct. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 9 11:51:16 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10292 for ; Wed, 9 Feb 2000 11:51: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 IAA24696; Wed, 9 Feb 2000 08:46:35 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA25864; Wed, 9 Feb 2000 08:50:03 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 08:50:03 -0800 (PST) Message-Id: <3.0.5.32.20000209084941.00939140@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 08:49:41 -0800 To: Mark Wahl From: "Kurt D. Zeilenga" Subject: Re: RFC2251: RootDSE subschemasubentry issue Cc: ietf-ldapext@netscape.com In-Reply-To: <7078.950102645@threadgill.austin.innosoft.com> References: <"Your message of Mon, 07 Feb 2000 09:40:04 PST." <3.0.5.32.20000207094004.009392d0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"AxShc.A.ISG.4qZo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:24 AM 2/9/00 -0600, Mark Wahl wrote: >The role of the subschemaSubentry attribute of the root DSE was discussed on >the IETF-ASID mailing list during the design of LDAPv3. Are the archives to the IETF-ASID mailing list still available? >It provides an important adminstrative function to allow management >clients to determine the capabilities of an LDAP server and the data >it contains. A couple of questions: How does a client determine which subschema subentry controls the RootDSE? David said that this wasn't needed. I disagre. The RootDSE may contain additional attributes to which the client may desire to access and hence may desire to discover schema for. It's possible that attribute type "foo" be listed differently in two different subschemas (because each was being separately maintained). Which defines "foo" as used in the Root DSE? But how can an attribute type restricted to SINGLE-VALUE (RFC 2252) take on multiple values as prescribed (RFC 2251)? Seems that one of the two documents must be in error. Kurt From list@netscape.com Wed Feb 9 12:09:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10935 for ; Wed, 9 Feb 2000 12:09:22 -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 JAA28047; Wed, 9 Feb 2000 09:04:41 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA04276; Wed, 9 Feb 2000 09:08:10 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 09:08:10 -0800 (PST) Message-Id: <3.0.5.32.20000209090759.0097bc80@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 09:07:59 -0800 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: substring matching rules Cc: Mark Wahl , ietf-ldapext@netscape.com In-Reply-To: <38A181E4.C683919C@netscape.com> References: <7416.950102811@threadgill.austin.innosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"lDsJO.A.iCB.57Zo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com So, if I want to define a bitString substring matching rule where each asserted component is a bitString, I should define a bitStringSubstrings (assertion) syntax and than use this as the syntax of asserted values of bitStringSubstringsMatch? Okay, so why? ( 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) This says that each asserted substring component is of directoryString syntax. I would think each asserted substring component should be of numericString syntax. From list@netscape.com Wed Feb 9 12:48:30 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12668 for ; Wed, 9 Feb 2000 12:48:30 -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 JAA04419; Wed, 9 Feb 2000 09:43:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA23447; Wed, 9 Feb 2000 09:47:12 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 09:47:12 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 09 Feb 2000 10:46:56 -0700 From: "Mark Meredith" To: , "Roger Harrison" Cc: Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_5108C508.ED8CB993" Resent-Message-ID: <"w22QmC.A.tsF.cgao4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_5108C508.ED8CB993 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I will add your suggestion to section 6 Notes to Client Developers. To = read something like this. 6. Notes to Client Developers The use of vendorName and vendorVersion SHOULD NOT be used to discover features. It is just an informational attribute. If a client relies on a vendorVersion number then that client MUST be coded to work with later versions and not just one version and no other. If the client does not recognize the specific vendorName/vendorVersion= as=20 one it has for its 'bug workaround needed' table, then the client = MUST=20 assume that the server it is talking to is complete and correct.=20 Does this look ok? -Mark Mark Meredith Novell Inc 122 E. 1700 S. Provo UT 84606 mark_meredith@novell.com 801-861-2645 --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- >>> Mark Wahl 02/09/00 09:45AM >>> > However, every server implementation has "quirks" (also sometimes known = as=20 > bugs), which may not be known in advance of shipping the server.=20 Correct. My concern is primarily that the draft is proposing also = doing=20 feature selection with this. I don't have a problem in general with = using=20 version names and numbers for bug detection though, so long as the = client=20 behavior is specified along the lines of If the client does not recognize the specific vendor/version as one it has its 'bug workaround needed' table, then the client must assume that the=20 server it is talking to is complete and correct.=20 Mark Wahl, Directory Product Architect Innosoft International, Inc. --=_5108C508.ED8CB993 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I will add your suggestion to section 6  Notes to Client Developers. To read something like this.

6. Notes to Client Developers
 
     The use of vendorName and vendorVersion SHOULD NOT be used to
     discover features. It is just an informational attribute. If a
     client relies on a vendorVersion number then that client MUST
     be coded to work with later versions and not just one version and
     no other.
 
     If the client does not recognize the specific vendorName/vendorVersion as
     one it has for its 'bug workaround needed' table, then the client MUST
     assume that the server it is talking to is complete and correct.
 
Does this look ok?
 
-Mark
 
Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
mark_meredith@novell.com
801-861-2645
---------------------
A boat in the harbor is safe,
but that is not what boats are for.
--John A. Shed
---------------------

>>> Mark Wahl <M.Wahl@INNOSOFT.COM> 02/09/00 09:45AM >>>

> However, every server implementation has "quirks" (also sometimes known as
> bugs), which may not be known in advance of shipping the server.

Correct.  My concern is primarily that the draft is proposing also doing
feature selection with this.  I don't have a problem in general with using
version names and numbers for bug detection though, so long as the client
behavior is specified along the lines of

If the client does not recognize the specific vendor/version as one it has
its 'bug workaround needed' table, then the client must assume that the
server it is talking to is complete and correct.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.
--=_5108C508.ED8CB993-- From list@netscape.com Wed Feb 9 13:09: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 NAA13947 for ; Wed, 9 Feb 2000 13:09: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 KAA09325; Wed, 9 Feb 2000 10:05:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA06439; Wed, 9 Feb 2000 10:08:34 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 10:08:34 -0800 (PST) Message-Id: <3.0.5.32.20000209100822.00976100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 10:08:22 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: unsolicited controls (Was: I-D ACTION:draft-weltman-ldapv3-auth-response-01.txt) In-Reply-To: <200002091641.LAA09935@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"LJvB9.A.8jB.g0ao4"@glacier> 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 like to voice a general concern about unsolicited response controls. That is, controls provided by servers without the client implicit or explicit solicitating the control. I believe we should discourage unsolicited controls in responses. As the number of such controls increase, which is inevidable, clients and networks will be overloaded with unneeded information. It would prudent, IMO, to provide and encourage use of client solicatation of desired information. That is, our general protocol model is one of client request/server response. I see no overriding reason why this particular control should not be sent without solicitation. I suggest that this response control be explicitly solicited by the client via a request control. Kurt From list@netscape.com Wed Feb 9 13:11:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14077 for ; Wed, 9 Feb 2000 13:11: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 KAA23835; Wed, 9 Feb 2000 10:08:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA07629; Wed, 9 Feb 2000 10:09:58 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 10:09:58 -0800 (PST) Message-ID: <38A1ADB6.6AA56D34@netscape.com> Date: Wed, 09 Feb 2000 10:11:02 -0800 From: dboreham@netscape.com (David Boreham) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: unsolicited controls (Was: I-DACTION:draft-weltman-ldapv3-auth-response-01.txt) References: <3.0.5.32.20000209100822.00976100@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BdjbNB.A.72B.21ao4"@glacier> 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 Examples ? "Kurt D. Zeilenga" wrote: > I like to voice a general concern about unsolicited response > controls. That is, controls provided by servers without the > client implicit or explicit solicitating the control. > > I believe we should discourage unsolicited controls in responses. > > As the number of such controls increase, which is inevidable, > clients and networks will be overloaded with unneeded information. > It would prudent, IMO, to provide and encourage use of client > solicatation of desired information. That is, our general > protocol model is one of client request/server response. I > see no overriding reason why this particular control should > not be sent without solicitation. > > I suggest that this response control be explicitly solicited > by the client via a request control. > > Kurt From list@netscape.com Wed Feb 9 13:54: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 NAA16856 for ; Wed, 9 Feb 2000 13:54: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 KAA17886; Wed, 9 Feb 2000 10:49:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA13553; Wed, 9 Feb 2000 10:53:23 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 10:53:23 -0800 (PST) Message-Id: <3.0.5.32.20000209105319.009804f0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 10:53:19 -0800 To: dboreham@netscape.com (David Boreham) From: "Kurt D. Zeilenga" Subject: Re: unsolicited controls (Was: I-DACTION:draft-weltman-ldapv3-auth-response-01.txt) Cc: ietf-ldapext@netscape.com In-Reply-To: <38A1ADB6.6AA56D34@netscape.com> References: <3.0.5.32.20000209100822.00976100@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"_-1YhB.A.dTD.iebo4"@glacier> 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:11 AM 2/9/00 -0800, David Boreham wrote: > >Examples ? draft-weltman-ldapv3-auth-response-01.txt draft-behera-ldap-password-policy-00.txt I feel the client should be required to take some explicit action before the returns any response not described by the core specifications. This act may be an explicit request control, a control upon bind enabling the behavior for the "session", an extended operation enabling the behavior, or some other form of solicitation. I feel a server should not respond with controls and/or extended responses not detailed by the core specifications without such solicitation. That is, the client should 1) discover what protocol extensions are supported by the server 2) enable desired extensions A server should: 1) published supported extensions 2) disable all extensions until enabled by the client From list@netscape.com Wed Feb 9 14:07: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 OAA17650 for ; Wed, 9 Feb 2000 14:07:11 -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 LAA21062; Wed, 9 Feb 2000 11:02:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA20921; Wed, 9 Feb 2000 10:58:55 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 10:58:55 -0800 (PST) Message-Id: <3.0.5.32.20000209105851.00973570@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 10:58:51 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Security Considerations in draft-weltman-ldapv3-auth-response-01.txt In-Reply-To: <200002091641.LAA09935@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"H80p_D.A.6FF.tjbo4"@glacier> 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 suggest noting explicitly in Security Considerations that the control is not protected by the SASL privacy or integrity protection negotiated by the BIND process returning this control. A client requiring such protection must rely on independent services, such as TLS or IPSEC, or use some operation after negotiating SASL protection services. Because of this consideration, I can see the need for an extended operation to obtain authorization information post BIND. BTW, what's the intended track of this document? I suggest adding a note to the draft indicating your intent. From list@netscape.com Wed Feb 9 14:13:10 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17873 for ; Wed, 9 Feb 2000 14:13:09 -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 LAA22419; Wed, 9 Feb 2000 11:09:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA29686; Wed, 9 Feb 2000 11:12:38 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:12:38 -0800 (PST) Message-ID: <38A1BBFB.A0F93C05@netscape.com> Date: Wed, 09 Feb 2000 11:11:55 -0800 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: Security Considerations indraft-weltman-ldapv3-auth-response-01.txt References: <3.0.5.32.20000209105851.00973570@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ra91r.A.kPH.lwbo4"@glacier> 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 Per previous messages: I originally proposed something more along the lines of what you have suggested - a control or extended operation which could be issued at any time to query the authentication identity of a connection. Mark Wahl had a strong argument at the time (a year ago) for why it would be better to have an unsolicited control returned on bind. I don't remember what that strong argument was... Maybe Mark can add to this discussion. "Kurt D. Zeilenga" wrote: > I suggest noting explicitly in Security Considerations that the > control is not protected by the SASL privacy or integrity > protection negotiated by the BIND process returning this control. > A client requiring such protection must rely on independent > services, such as TLS or IPSEC, or use some operation after > negotiating SASL protection services. That could be added, but note that the information being returned in the control is not a password, but just the identity (DN) of the authenticated connection. > > > Because of this consideration, I can see the need for an extended > operation to obtain authorization information post BIND. > > BTW, what's the intended track of this document? I suggest > adding a note to the draft indicating your intent. It depends a little on the interest among participants on this list. Thanks, Rob From list@netscape.com Wed Feb 9 14:27:38 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18819 for ; Wed, 9 Feb 2000 14:27: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 LAA25054; Wed, 9 Feb 2000 11:22:30 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA07521; Wed, 9 Feb 2000 11:26:00 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:26:00 -0800 (PST) Message-Id: <3.0.5.32.20000209112555.00968970@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 11:25:55 -0800 To: rweltman@netscape.com (Rob Weltman) From: "Kurt D. Zeilenga" Subject: Re: Security Considerations indraft-weltman-ldapv3-auth-response-01.txt Cc: ietf-ldapext@netscape.com In-Reply-To: <38A1BBFB.A0F93C05@netscape.com> References: <3.0.5.32.20000209105851.00973570@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"9w-aYB.A.I1B.H9bo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:11 AM 2/9/00 -0800, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> I suggest noting explicitly in Security Considerations that the >> control is not protected by the SASL privacy or integrity >> protection negotiated by the BIND process returning this control. >> A client requiring such protection must rely on independent >> services, such as TLS or IPSEC, or use some operation after >> negotiating SASL protection services. > That could be added, but note that the information being returned in the control is not a password, but just the identity (DN) of the authenticated connection. I am specifically concerned that the DN returned may be modified in transit or by man in the middle and the client may assume incorrectly that the information is protected by services negotiated during the bind operation. I believe any specification of a control passed in a Bind Request or Response should have a explicit security consideration statement that control is not protected by services which the Bind may or may not negotiate. From list@netscape.com Wed Feb 9 14:27:53 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18839 for ; Wed, 9 Feb 2000 14:27:50 -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 LAA25595; Wed, 9 Feb 2000 11:23:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA08267; Wed, 9 Feb 2000 11:26:44 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:26:44 -0800 (PST) Message-ID: <38A1BF2C.AFDD7A32@netscape.com> Date: Wed, 09 Feb 2000 14:25:32 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: Security Considerations indraft-weltman-ldapv3-auth-response-01.txt References: <3.0.5.32.20000209105851.00973570@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"QmT7G.A.2AC.z9bo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > BTW, what's the intended track of this document? I suggest > adding a note to the draft indicating your intent. Good point. You raised this before but we neglected to address it. I think this should be a standards track document, i.e., if a server is going to return authentication information this is how it should do it (subject to revision and debate about issues such as whether the client must request the information, etc. of course). My point is that we should have one way of returning this information so that if a server or client needs this feature they can count on it being implemented in just one way from a protocol perspective. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Wed Feb 9 14:30:37 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18997 for ; Wed, 9 Feb 2000 14:30:34 -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 LAA10745; Wed, 9 Feb 2000 11:27:33 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA10821; Wed, 9 Feb 2000 11:29:17 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:29:17 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, Mark Wahl Date: Wed, 9 Feb 2000 19:26:37 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: <3.0.5.32.20000209084941.00939140@infidel.boolean.net> References: <7078.950102645@threadgill.austin.innosoft.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"xTD8EC.A.zoC.MAco4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Mark, Kurt I think I have an answer to the problem(s) being posed by Kurt. The model as it stands is OK if a server only masters one naming context. Everything works fine. All the entries in the NC and the rootDSE can contain the subschemaSubentry attribute which points to the single subschema subentry. The problem arises once we have multiple NCs in a server. The subschemaSubentry attribute can still be single valued and exist in each entry in each NC and point to the correct subschema subentry. However, the attribute in the root DSE no longer works, for two reasons. Firstly it is supposed to be single valued (as Kurt pointed out) and now it needs to have multiple values. Secondly, (again as Kurt pointed out) there is no way for the user to know from the multivalued attribute in the rootDSE which value points to which subschema subentry for which NC. THis of course is not a problem for the entries within the NC, as they only still need a single pointer to their one and only subschema subentry. Thus I conclude that the model is broken for multiple naming contexts, and that the subschemaSubentry attribute in the rootDSE needs to be replaced by a multivalued attribute, having two components - the context prefix of an NC (an LDAP DN), and the pointer to the subschemaSubentry. Do you agree with this analysis? David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Feb 9 14:31:46 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19120 for ; Wed, 9 Feb 2000 14:31: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 LAA11472; Wed, 9 Feb 2000 11:29:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA13011; Wed, 9 Feb 2000 11:31:09 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:31:09 -0800 (PST) Message-ID: <38A1C055.C82ABF09@netscape.com> Date: Wed, 09 Feb 2000 11:30:29 -0800 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: Security Considerationsindraft-weltman-ldapv3-auth-response-01.txt References: <3.0.5.32.20000209105851.00973570@infidel.boolean.net> <3.0.5.32.20000209112555.00968970@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VfI_DB.A.xKD.7Bco4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > At 11:11 AM 2/9/00 -0800, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> I suggest noting explicitly in Security Considerations that the > >> control is not protected by the SASL privacy or integrity > >> protection negotiated by the BIND process returning this control. > >> A client requiring such protection must rely on independent > >> services, such as TLS or IPSEC, or use some operation after > >> negotiating SASL protection services. > > That could be added, but note that the information being returned in the control is not a password, but just the identity (DN) of the authenticated connection. > > I am specifically concerned that the DN returned may be modified > in transit or by man in the middle and the client may assume > incorrectly that the information is protected by services > negotiated during the bind operation. > > I believe any specification of a control passed in a Bind > Request or Response should have a explicit security consideration > statement that control is not protected by services which the > Bind may or may not negotiate. I see. Thanks for pointing that out. The response is returned before any session protection takes effect, so it is more exposed than any other data-carrying LDAP response. Rob From list@netscape.com Wed Feb 9 14:53: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 OAA20123 for ; Wed, 9 Feb 2000 14:53: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 LAA16780; Wed, 9 Feb 2000 11:50:28 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA21972; Wed, 9 Feb 2000 11:42:14 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:42:14 -0800 (PST) Message-ID: <38A1C2CD.ED72039D@netscape.com> Date: Wed, 09 Feb 2000 14:41:01 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark Wahl , ietf-ldapext@netscape.com Subject: Re: substring matching rules References: <7416.950102811@threadgill.austin.innosoft.com> <3.0.5.32.20000209090759.0097bc80@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"b8GCvD.A.FXF.UMco4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I don't have access to all of the right standard documents here, but I suspect that the NumericString syntax is compatible with DirectoryString. Not true for bitString or octetString... in fact, X.521 includes this definition: octetStringSubstringsMatch MATCHING-RULE ::= { SYNTAX OctetSubstringAssertion ID id-mr-octetStringSubstringsMatch } OctetSubstringAssertion ::= SEQUENCE OF CHOICE { initial [0] OCTET STRING, any [1] OCTET STRING, final [2] OCTET STRING } -- at most one initial and one final component which is very similar in concept to your bitStringSubstringsMatch example. It would be nice to add some text about all of this to RFC2252-bis when it is created. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? "Kurt D. Zeilenga" wrote: > > So, if I want to define a bitString substring matching rule > where each asserted component is a bitString, I should define > a bitStringSubstrings (assertion) syntax and than use this as > the syntax of asserted values of bitStringSubstringsMatch? > > Okay, so why? > > ( 2.5.13.10 NAME 'numericStringSubstringsMatch' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) > > This says that each asserted substring component is of > directoryString syntax. I would think each asserted substring > component should be of numericString syntax. From list@netscape.com Wed Feb 9 14:59: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 OAA20451 for ; Wed, 9 Feb 2000 14:59: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 LAA17596; Wed, 9 Feb 2000 11:56:35 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA00556; Wed, 9 Feb 2000 11:58:20 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 11:58:20 -0800 (PST) Message-Id: <3.0.5.32.20000209115809.00970b70@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 11:58:09 -0800 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC2251: RootDSE subschemasubentry issue Cc: ietf-ldapext@netscape.com, Mark Wahl In-Reply-To: References: <3.0.5.32.20000209084941.00939140@infidel.boolean.net> <7078.950102645@threadgill.austin.innosoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"n5RuIC.A.aI.abco4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:26 PM 2/9/00 -0000, David Chadwick wrote: >Do you agree with this analysis? Yes. The next questions are: What other attributes published in RootDSE are naming context specific? I've seen a lot of proposals (including my own) which suggest attributes for publishing capabilities. It's likely that some of these are not server specific, but are naming context specific. From the design perpective, I see different ways of providing naming context specific information: 1) add new attributes which provide the context and the capability as combined value. (Ie: 1A) dn: (root dse) subschemasubentries: dc=openldap,dc=org $ ( cn=subschema $ cn=openldap-subschema ) subschemasubentries: dc=example,dc=com $ cn=subschema ... or: 1B) dn: (root dse) subschemasubentries: dc=openldap,dc=org $ cn=subschema subschemasubentries: dc=openldap,dc=org $ cn=opendlap-subschema subschemasubentries: dc=example,dc=com $ cn=subschema 2) provide an attribute which lists naming contexts AND a provides a DN of an entry (or subentry) which contains attributes describing the naming context specific capabilities. dn: (root dse) namingContextCapabilities: dc=openldap,dc=org $ cn=openldap namingContextCapabilities: dc=example,dc=com $ cn=example dn: cn=openldap subschemasubentries: cn=subschema subschemasubentries: cn=openldap-subschema dn: cn=example subschemasubentires: cn=subschema Comments? From list@netscape.com Wed Feb 9 16:37: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 QAA24510 for ; Wed, 9 Feb 2000 16:36:59 -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 NAA16111; Wed, 9 Feb 2000 13:32:12 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA12279; Wed, 9 Feb 2000 13:35:41 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 13:35:41 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 09 Feb 2000 14:34:46 -0700 From: "Steven Merrill" To: "<" Subject: java-api-asynch-ext-04, Sec 4.1.8 search Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"THJwRB.A.K_C.s2do4"@glacier> 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 QAA24510 For the second search method definition shouldn't an LDAPSearchConstraints object be specified instead of LDAPConstraints? Downcasting the LDAPConstraints to an LDAPSearchContraints object would be dangerous. Steve Merrill Novell, Inc. From list@netscape.com Wed Feb 9 17:27:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25851 for ; Wed, 9 Feb 2000 17:27: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 OAA09321; Wed, 9 Feb 2000 14:25:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA04092; Wed, 9 Feb 2000 14:26:57 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 14:26:57 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 09 Feb 2000 15:26:38 -0700 From: "Jim Sermersheim" To: , Cc: , Subject: Re: substring matching rules Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"WHNv-D.A.o_.wmeo4"@glacier> 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 RAA25851 We still need two separate substrings matching rules (Ech). Either that, or the MatchingRuleDescription needs to allow for two syntaxes, one being the syntax used for the matchValue of an extensibleMatch, and the other used for the substrings value of a normal (not extensible) filter. Jim >>> Mark C Smith 2/9/00 12:42:46 PM >>> I don't have access to all of the right standard documents here, but I suspect that the NumericString syntax is compatible with DirectoryString. Not true for bitString or octetString... in fact, X.521 includes this definition: octetStringSubstringsMatch MATCHING-RULE ::= { SYNTAX OctetSubstringAssertion ID id-mr-octetStringSubstringsMatch } OctetSubstringAssertion ::= SEQUENCE OF CHOICE { initial [0] OCTET STRING, any [1] OCTET STRING, final [2] OCTET STRING } -- at most one initial and one final component which is very similar in concept to your bitStringSubstringsMatch example. It would be nice to add some text about all of this to RFC2252-bis when it is created. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? "Kurt D. Zeilenga" wrote: > > So, if I want to define a bitString substring matching rule > where each asserted component is a bitString, I should define > a bitStringSubstrings (assertion) syntax and than use this as > the syntax of asserted values of bitStringSubstringsMatch? > > Okay, so why? > > ( 2.5.13.10 NAME 'numericStringSubstringsMatch' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) > > This says that each asserted substring component is of > directoryString syntax. I would think each asserted substring > component should be of numericString syntax. From list@netscape.com Wed Feb 9 18:16: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 SAA26674 for ; Wed, 9 Feb 2000 18:16:07 -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 PAA16924; Wed, 9 Feb 2000 15:13:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA03499; Wed, 9 Feb 2000 15:14:53 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 15:14:53 -0800 (PST) Message-Id: <3.0.5.32.20000209151440.0096f350@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 15:14:40 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: unsolicited controls (Was: I-DACTION:draft-weltman-ldapv3-auth-response-01.txt) In-Reply-To: <3.0.5.32.20000209105319.009804f0@infidel.boolean.net> References: <38A1ADB6.6AA56D34@netscape.com> <3.0.5.32.20000209100822.00976100@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"aliCFB.A.O1.qTfo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com RFC 2251, 4.4 (unsolicited notifications) says: It [an unsolicited notification] is used to signal an extraordinary condition in the server or in the connection between the client and the server I believe the same should apply to unsolicited controls: An unsolicited response control is used to signal an extraordinary condition with the operation. That is, the fact that an identity is authorized is by a operation bind is quite ordinary and hence a client shouldn't be notified of the identity unless explicitly requested. Kurt At 10:53 AM 2/9/00 -0800, Kurt D. Zeilenga wrote: >At 10:11 AM 2/9/00 -0800, David Boreham wrote: >> >>Examples ? > >draft-weltman-ldapv3-auth-response-01.txt >draft-behera-ldap-password-policy-00.txt > >I feel the client should be required to take some explicit >action before the returns any response not described by >the core specifications. This act may be an explicit >request control, a control upon bind enabling the behavior >for the "session", an extended operation enabling the behavior, >or some other form of solicitation. > >I feel a server should not respond with controls and/or >extended responses not detailed by the core specifications >without such solicitation. > >That is, the client should > 1) discover what protocol extensions are supported by the server > 2) enable desired extensions > >A server should: > 1) published supported extensions > 2) disable all extensions until enabled by the client > > > From list@netscape.com Wed Feb 9 21:04: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 VAA29667 for ; Wed, 9 Feb 2000 21:04:50 -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 SAA11396; Wed, 9 Feb 2000 18:02:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA16483; Wed, 9 Feb 2000 18:04:07 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 18:04:07 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 09 Feb 2000 19:03:44 -0700 From: "Jim Sermersheim" To: , Subject: Re: unsolicited controls (Was: I-DACTION:draft-weltman-ldapv3-auth-response-01.txt) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"gTS0n.A.RBE.Wyho4"@glacier> 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 VAA29667 Given this definition, what constitutes extraordinary? Is an expired password an extraordinary condition? Unless we can define the meaning of extraordinary, I'd rather just decide to allow unsolicited response controls or not. >>> "Kurt D. Zeilenga" 2/9/00 4:15:26 PM >>> RFC 2251, 4.4 (unsolicited notifications) says: It [an unsolicited notification] is used to signal an extraordinary condition in the server or in the connection between the client and the server I believe the same should apply to unsolicited controls: An unsolicited response control is used to signal an extraordinary condition with the operation. That is, the fact that an identity is authorized is by a operation bind is quite ordinary and hence a client shouldn't be notified of the identity unless explicitly requested. Kurt At 10:53 AM 2/9/00 -0800, Kurt D. Zeilenga wrote: >At 10:11 AM 2/9/00 -0800, David Boreham wrote: >> >>Examples ? > >draft-weltman-ldapv3-auth-response-01.txt >draft-behera-ldap-password-policy-00.txt > >I feel the client should be required to take some explicit >action before the returns any response not described by >the core specifications. This act may be an explicit >request control, a control upon bind enabling the behavior >for the "session", an extended operation enabling the behavior, >or some other form of solicitation. > >I feel a server should not respond with controls and/or >extended responses not detailed by the core specifications >without such solicitation. > >That is, the client should > 1) discover what protocol extensions are supported by the server > 2) enable desired extensions > >A server should: > 1) published supported extensions > 2) disable all extensions until enabled by the client > > > From list@netscape.com Wed Feb 9 22:43:14 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02518 for ; Wed, 9 Feb 2000 22:43:13 -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 TAA04727; Wed, 9 Feb 2000 19:38:21 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA11959; Wed, 9 Feb 2000 19:41:51 -0800 (PST) Resent-Date: Wed, 9 Feb 2000 19:41:51 -0800 (PST) Message-Id: <3.0.5.32.20000209194141.00977940@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 19:41:41 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: unsolicited controls (Was: I-DACTION:draft-weltman-ldapv3-auth-response-01.txt) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Omsc8B.A.l6C.-Njo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Is their a compelling reason to not negotiate these elective features? I believe it is unwise not to negotiate elective features. At 07:03 PM 2/9/00 -0700, Jim Sermersheim wrote: >Given this definition, what constitutes extraordinary? Good question. Ask? Is the importance of the notification such that most applications would be modified to recognize it and do something reasonable because of it? If the answer is no, than it's not extraordinary. > Is an expired password an extraordinary condition? Per my above definition, no. In the case of password policy, I'd suggest a bind control that the client could use to tell the server, "I recognize password policy controls/responses". This is a form of solicitation. > Unless we can define the meaning of extraordinary, > I'd rather just decide to allow unsolicited response controls or not. Even though I am hard pressed at the moment to find a control extraordinary enough that application developers would be compelled to update their codes to recognize it, I would hate to disallow unsolicited response controls completely as I believe that the recommended use of unsolicited controls should be comparable to unsolicited responses. Kurt From list@netscape.com Thu Feb 10 08:12: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 IAA21880 for ; Thu, 10 Feb 2000 08:12:22 -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 FAA23535; Thu, 10 Feb 2000 05:09:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA16784; Thu, 10 Feb 2000 05:11:09 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 05:11:09 -0800 (PST) From: hahnt@us.ibm.com Importance: Normal Subject: Re: RFC2251: RootDSE subschemasubentry issue To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999 Message-ID: Date: Thu, 10 Feb 2000 08:08:42 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.2b (Intl)|7 January 2000) at 10/02/2000 08:11:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"9Des1.A.-FE.rjro4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Greetings, I believe that this was discussed on the mailing list about 6 months ago. At that time, the general direction seemed to be that the rootDSE entry would contain an additional attribute: subschemasubentries which would be defined to have distinguishedName syntax. And while this does not provide the detailed mapping (offered in Kurt's response), of associating namingContext values with subschemasubentries values, it also does not introduce another attribute value format that needs to be parsed. The X.500 specifications give some guidance on the placement of subschemasubentry values, namely they are to be placed "just below" the namingContext and should have object class: top, subentry, subschemasubentry. So, I would add a fourth option for the rootDSE: namingContexts: ou=Sales, o=Widgets namingContexts: ou=Development, o=Widgets subschemasubentries: cn=schema, ou=Sales, o=Widgets subschemasubentries: cn=schema, ou=Development, o=Widgets Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From list@netscape.com Thu Feb 10 09:09: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 JAA25395 for ; Thu, 10 Feb 2000 09:08:59 -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 GAA27608; Thu, 10 Feb 2000 06:06:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA26717; Thu, 10 Feb 2000 06:07:50 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 06:07:50 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com Subject: RE: RFC2251: RootDSE subschemasubentry issue Date: Thu, 10 Feb 2000 09:08:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Pie4JD.A.JhG.1Yso4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Instead of inventing new attributes or syntaxes, why not just say that the subschema for a naming context can be discovered by reading the subschemaSubentry attribute in the naming context? From list@netscape.com Thu Feb 10 09:25: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 JAA26521 for ; Thu, 10 Feb 2000 09:25:09 -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 GAA28788; Thu, 10 Feb 2000 06:22:07 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA29705; Thu, 10 Feb 2000 06:23:53 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 06:23:53 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, Mark Wahl Date: Thu, 10 Feb 2000 14:22:17 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: <3.0.5.32.20000209115809.00970b70@infidel.boolean.net> References: X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"4DAPcC.A.3PH.4nso4"@glacier> 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 > At 07:26 PM 2/9/00 -0000, David Chadwick wrote: > >Do you agree with this analysis? > > Yes. Good, we are making progress towards resolution. > > The next questions are: > > What other attributes published in RootDSE are naming > context specific? The question should actually be wider than this I believe. i.e. What attributes are NC specific and what attributes are server specific and what attributes are Management Domain specific, since i) a Man Domain can comprise many servers ii) a server can hold many NCs iii) a server can hold many Man Domains. So we really need placeholders for all of these. It seems to me like the rootDSE should hold server specific attributes, a subentry under the NC context prefix should hold NC specific attributes (this is in line with the LDUP group I believe), and a subentry under an Admin Point should hold Man Domain specific attributes (this is in line with X.500(93)). What do you think? > > I've seen a lot of proposals (including my own) which > suggest attributes for publishing capabilities. It's > likely that some of these are not server specific, > but are naming context specific. agreed > > From the design perpective, I see different ways of > providing naming context specific information: > > 1) add new attributes which provide the context > and the capability as combined value. (Ie: > 1A) dn: (root dse) > subschemasubentries: dc=openldap,dc=org $ > ( cn=subschema $ cn=openldap-subschema ) > subschemasubentries: dc=example,dc=com $ cn=subschema > ... > > or: > 1B) dn: (root dse) > subschemasubentries: dc=openldap,dc=org $ cn=subschema > subschemasubentries: dc=openldap,dc=org $ cn=opendlap-subschema > subschemasubentries: dc=example,dc=com $ cn=subschema > > 2) provide an attribute which lists naming contexts > AND a provides a DN of an entry (or subentry) which > contains attributes describing the naming context > specific capabilities. Or, an attribute which lists NCs and have subentries under the NCs, so that no pointer is needed in the rootDSE. > > dn: (root dse) > namingContextCapabilities: dc=openldap,dc=org $ cn=openldap > namingContextCapabilities: dc=example,dc=com $ cn=example > > dn: cn=openldap > subschemasubentries: cn=subschema > subschemasubentries: cn=openldap-subschema Why would you have 2 subschemasubentries for 1 NC? I think only one is needed (this is mandatory at the moment I believe) David > > dn: cn=example > subschemasubentires: cn=subschema > > > Comments? > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Feb 10 10:04:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29164 for ; Thu, 10 Feb 2000 10:04: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 GAA12703; Thu, 10 Feb 2000 06:59:26 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA09490; Thu, 10 Feb 2000 07:02:58 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 07:02:58 -0800 (PST) Message-ID: From: "Mcauliffe, Kristin" To: ietf-ldapext@netscape.com Subject: Question on Extensible Match Filter Date: Thu, 10 Feb 2000 10:02:34 -0500 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Tbx8VB.A.AUC.hMto4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I am working on LDAP v3 Search filters and cannot seem to get a return from the DS servers (Netscape, Novell NDS and MS AD) that I am testing using the Extensible Match string. I am following the definition identified in RFC2254 and those identified in Chapter 3 of "Understanding and Deploying LDAP DS" (and the examples). I have used both the assertion syntax and the value syntax. The results received are: Bind operation successful. ldap_search_s: Protocol error ldap_search_s: additional info: Bad search filter Any guidance would be appreciated. ===================================== Kristin McAuliffe Center for Information Technology Standards DISA mcaulifk@ftm.disa.mil ===================================== From list@netscape.com Thu Feb 10 12:06:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04283 for ; Thu, 10 Feb 2000 12:06: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 JAA25474; Thu, 10 Feb 2000 09:02:13 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA17784; Thu, 10 Feb 2000 09:05:43 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:05:43 -0800 (PST) Date: Thu, 10 Feb 2000 17:27:44 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: ietf-ldapext@netscape.com cc: Jeff.Hodges@stanford.edu, RLBob Morgan , Mark Wahl Subject: Re: Please publish this I-D: draft-ietf-ldapext-ldapv3-tls-06.txt Message-ID: <2734229.3159192464@[192.168.111.25]> In-Reply-To: <200002101627.IAA01306@breakaway.Stanford.EDU> X-Mailer: Mulberry/2.0.0b9 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Resent-Message-ID: <"7IVVPD.A.WVE.m_uo4"@glacier> 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 --On 2000-02-10 08.27 -0800, Jeff.Hodges@stanford.edu wrote: > We'd appreciate it if you could carry the below version of the doc > forward into the RFC process. Thanks, Send it to internet-drafts@ietf.org, and let me know when the I-D is announced on the IETF-announce list. Patrik From list@netscape.com Thu Feb 10 12:18: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 MAA04615 for ; Thu, 10 Feb 2000 12:18: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 JAA27754; Thu, 10 Feb 2000 09:14:03 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA24629; Thu, 10 Feb 2000 09:17:34 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:17:34 -0800 (PST) Message-ID: <017E033801420200@mailgate.netconnect.co.uk> In-Reply-To: <2734229%.3159192464@mailgate.netconnect.co.uk> Date: Thu, 10 Feb 2000 17:16:00 +0000 From: John Storry Sender: John Storry Organization: NetConnect Ltd To: ietf-ldapext@netscape.com Subject: Please remove from mailing list Importance: High X-SMF-Hop-Count: 2 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailer: Connect2-SMTP 4.32 MHS/SMF to SMTP Gateway Resent-Message-ID: <"93XNdC.A.SAG.sKvo4"@glacier> 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 Could you please remove the following: dnesbitt@netconnect.co.uk from your mailing list ASAP as this user is no longer employed by this company. Many thanks ===== Original Message from ietf-ldapext @ netscape.com at 10/02/00 16:27 >--On 2000-02-10 08.27 -0800, Jeff.Hodges@stanford.edu wrote: > >> We'd appreciate it if you could carry the below version of the doc >> forward into the RFC process. Thanks, > >Send it to internet-drafts@ietf.org, and let me know when the I-D is >announced on the IETF-announce list. > > Patrik John Storry Internal Systems Engineer NetConnect Ltd Integration Training for Messaging, Security Directory Systems Phone:+44 (0) 1223 423 523 Fax:+44 (0) 1223 420 655 http://www.netconnect.co.uk/ CONFIDENTIALITY NOTICE: This e-mail contains confidential information which is intended only for use by the recipient (s) named above. If you have received this communication in error, please notify the sender immediately via e-mail and return the entire message. Thank you for your assistance. From list@netscape.com Thu Feb 10 12:18:29 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04630 for ; Thu, 10 Feb 2000 12:18:23 -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 JAA20154; Thu, 10 Feb 2000 09:16:02 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA25016; Thu, 10 Feb 2000 09:17:47 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:17:47 -0800 (PST) Message-Id: <200002101717.JAA01460@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Please publish this I-D: draft-ietf-ldapext-ldapv3-tls-06.txt To: internet-drafts@ietf.org cc: jhodges@oblix.com, RLBob Morgan , Mark Wahl , LDAP extensions From: jhodges@oblix.com Reply-to: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_5686075430" Date: Thu, 10 Feb 2000 09:17:11 -0800 Sender: hodges@Wind.Stanford.EDU Resent-Message-ID: <"cwB78C.A.sFG.4Kvo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multipart MIME message. --==_Exmh_5686075430 Content-Type: text/plain; charset=us-ascii This revision of draft-ietf-ldapext-ldapv3-tls has only minor editorial changes, plus a clarification at the end of section 4.6 as a result of Security Area review. The extraneous section 6 fragment was removed (we'd moved that entire section to draft-ietf-ldapext-authmeth-04), and remaining sections renumbered. JeffH --==_Exmh_5686075430 Content-Type: text/plain ; name="draft-ietf-ldapext-ldapv3-tls-06.txt"; charset=us-ascii Content-Description: draft-ietf-ldapext-ldapv3-tls-06.txt Content-Disposition: attachment; filename="draft-ietf-ldapext-ldapv3-tls-06.txt" LDAPEXT Working Group Jeff Hodges, Oblix Inc. INTERNET-DRAFT RL "Bob" Morgan, Univ of Washington Intended Category: Mark Wahl, Innosoft International, Inc. Standards Track February, 2000 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com This document expires in July 2000. 1. Abstract This document defines the "Start Transport Layer Security (TLS) Opera- tion" for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- ment in an LDAP association and is defined in terms of an LDAP extended request. Hodges, Morgan, Wahl [Page 1] I-D LDAPv3: Extension for Transport Layer Security February 2000 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [ReqsKeywords]. 3. The Start TLS Request This section describes the Start TLS extended request and extended response themselves: how to form the request, the form of the response, and enumerates the various result codes the client MUST be prepared to handle. The section following this one then describes how to sequence an overall Start TLS Operation. 3.1. Requesting TLS Establishment A client may perform a Start TLS operation by transmitting an LDAP PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the Start TLS operation: 1.3.6.1.4.1.1466.20037 An LDAP ExtendedRequest is defined as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } A Start TLS extended request is formed by setting the requestName field to the OID string given above. The requestValue field is absent. The client MUST NOT send any PDUs on this connection following this request until it receives a Start TLS extended response. When a Start TLS extended request is made, the server MUST return an LDAP PDU containing a Start TLS extended response. An LDAP Exten- dedResponse is defined as follows: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, response [11] OCTET STRING OPTIONAL } A Start TLS extended response MUST contain a responseName field which MUST be set to the same string as that in the responseName field present in the Start TLS extended request. The response field is absent. The server MUST set the resultCode field to either success or one of the Hodges, Morgan, Wahl [Page 2] I-D LDAPv3: Extension for Transport Layer Security February 2000 other values outlined in section 3.3. 3.2. "Success" Response If the ExtendedResponse contains a resultCode of success, this indicates that the server is willing and able to negotiate TLS. Refer to section 4, below, for details. 3.3. Response other than "success" If the ExtendedResponse contains a resultCode other than success, this indicates that the server is unwilling or unable to negotiate TLS. If the Start TLS extended request was not successful, the resultCode will be one of: operationsError (operations sequencing incorrect; e.g. TLS already established) protocolError (TLS not supported or incorrect PDU structure) referral (this server doesn't do TLS, try this one) unavailable (e.g. some major problem with TLS, or server is shutting down) The server MUST return operationsError if the client violates any of the Start TLS extended operation sequencing requirements described in sec- tion 4, below. If the server does not support TLS (whether by design or by current con- figuration), it MUST set the resultCode to protocolError (see section 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual referral value in the LDAP Result if it returns a resultCode of refer- ral. The client's current session is unaffected if the server does not support TLS. The client MAY proceed with any LDAP operation, or it MAY close the connection. The server MUST return unavailable if it supports TLS but cannot estab- lish a TLS connection for some reason, e.g. the certificate server not responding, it cannot contact its TLS implementation, or if the server is in process of shutting down. The client MAY retry the StartTLS opera- tion, or it MAY proceed with any other LDAP operation, or it MAY close the connection. 4. Sequencing of the Start TLS Operation This section describes the overall procedures clients and servers MUST Hodges, Morgan, Wahl [Page 3] I-D LDAPv3: Extension for Transport Layer Security February 2000 follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the LDAP association includ- ing discovery of resultant security level and assertion of the client's authorization identity. Note that the precise effects, on a client's authorzation identity, of establishing TLS on an LDAP association are described in detail in sec- tion 7. 4.1. Requesting to Start TLS on an LDAP Association The client MAY send the Start TLS extended request at any time after establishing an LDAP association, except that in the following cases the client MUST NOT send a Start TLS extended request: - if TLS is currently established on the connection, or - during a multi-stage SASL negotiation, or - if there are any LDAP operations outstanding on the connection. The result of violating any of these requirements is a resultCode of operationsError, as described above in section 3.3. The client MAY have already perfomed a Bind operation when it sends a Start TLS request, or the client might have not yet bound. If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server MUST reject that request with a confidentialityRequired or strongAuthRequired result. The client MAY send a Start TLS extended request, or it MAY choose to close the connection. 4.2. Starting TLS The server will return an extended response with the resultCode of suc- cess if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable. In the successful case, the client, which has ceased to transfer LDAP requests on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to ini- tiate TLS negotiation [TLS]. 4.3. TLS Version Negotiation Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. Please refer to that Hodges, Morgan, Wahl [Page 4] I-D LDAPv3: Extension for Transport Layer Security February 2000 document for details. 4.4. Discovery of Resultant Security Level After a TLS connection is established on an LDAP association, both par- ties MUST individually decide whether or not to continue based on the privacy level achieved. Ascertaining the TLS connection's privacy level is implementation dependent, and accomplished by communicating with one's respective local TLS implementation. If the client or server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD gracefully close the TLS connection immediately after the TLS negotiation has com- pleted (see sections 5 and 7.2, below). The client MAY attempt to Start TLS again, or MAY send an unbind request, or send any other LDAP request. 4.5. Assertion of Client's Authorization Identity The client MAY, upon receipt of a Start TLS extended response indicating success, assert that a specific authorization identity be utilized in determining the client's authorization status. The client accomplishes this via an LDAP Bind request specifying a SASL mechanism of "EXTERNAL" [SASL]. See section 7, below. 4.6. Server Identity Check The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. If a subjectAltName extension of type dNSName is present, it SHOULD be used as the source of the server's identity. Matching is performed according to these rules: - The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name. - If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. - Matching is case-insensitive. Hodges, Morgan, Wahl [Page 5] I-D LDAPv3: Extension for Transport Layer Security February 2000 - The "*" wildcard character is allowed. - If present, it applies only to the left-most name component. E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is con- sidered acceptable. If the hostname does not match the dNSName-based identity in the certi- ficate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating hat the server's identity is suspect. Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information. 4.7. Refresh of Server Capabilities Information The client MUST refresh any cached server capabilities information (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon TLS ses- sion establishment. This is necessary to protect against active- intermediary attacks which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY adver- tise different capabilities after TLS establishment. 5. Closing a TLS Connection 5.1. Graceful Closure Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact. Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete, or explicitly abandon them [LDAPv3]. After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the reciept of the alert, MAY send and receive LDAP PDUs. The other party, if it receives a closure alert, MUST immediately Hodges, Morgan, Wahl [Page 6] I-D LDAPv3: Extension for Transport Layer Security February 2000 transmit a TLS closure alert. It will subequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs. 5.2. Abrupt Closure Either the client or server MAY abruptly close the entire LDAP associa- tion and any TLS connection established on it by dropping the underlying TCP connection. A server MAY beforehand send the client a Notice of Disconnection [LDAPv3] in this case. 6. Effects of TLS on a Client's Authorization Identity This section describes the effects on a client's authorization identity brought about by establishing TLS on an LDAP association. The default effects are described first, and next the facilities for client asser- tion of authorization identity are discussed including error conditions. Lastly, the effects of closing the TLS connection are described. Authorization identities and related concepts are defined in [AuthMeth]. 6.1. TLS Connection Establishment Effects 6.1.1. Default Effects Upon establishment of the TLS connection onto the LDAP association, any previously established authentication and authorization identities MUST remain in force, including anonymous state. This holds even in the case where the server requests client authentication via TLS -- e.g. requests the client to supply its certificate during TLS negotiation (see [TLS]). 6.1.2. Client Assertion of Authorization Identity A client MAY either implicitly request that its LDAP authorization iden- tity be derived from its authenticated TLS credentials or it MAY expli- citly provide an authorization identity and assert that it be used in combination with its authenticated TLS credentials. The former is known as an implicit assertion, and the latter as an explicit assertion. 6.1.2.1. Implicit Assertion An implicit authorization identity assertion is accomplished after TLS establishment by invoking a Bind request of the SASL form using the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include the optional credentials octet string (found within the SaslCredentials sequence in the Bind Request). The server will derive the client's authorization identity from the authentication identity supplied in the client's TLS credentials (typically a public key certificate) according to local policy. The underlying mechanics of how this is accomplished Hodges, Morgan, Wahl [Page 7] I-D LDAPv3: Extension for Transport Layer Security February 2000 are implementation specific. 6.1.2.2. Explicit Assertion An explicit authorization identity assertion is accomplished after TLS establishment by invoking a Bind request of the SASL form using the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the creden- tials octet string. This string MUST be constructed as documented in section 11 of [AuthMeth]. 6.1.2.3. Error Conditions For either form of assertion, the server MUST verify that the client's authentication identity as supplied in its TLS credentials is permitted to be mapped to the asserted authorization identity. The server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized. The LDAP association's authentication identity and authorization identity (if any) which were in effect after TLS establishment but prior to making the Bind request, MUST remain in force. Additionally, with either form of assertion, if a TLS session has not been established between the client and server prior to making the SASL EXTERNAL Bind request and there is no other external source of authenti- cation credentials (e.g. IP-level security RFC 1825), or if, during the process of establishing the TLS session, the server did not request the client's authentication credentials, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication. Any authentication identity and authorization identity, as well as TLS connection, which were in effect prior to making the Bind request, MUST remain in force. 6.2. TLS Connection Closure Effects Closure of the TLS connection MUST cause the LDAP association to move to an anonymous authentication and authorization state regardless of the state established over TLS and regardless of the authentication and authorization state prior to TLS connection establishment. 7. Security Considerations The goals of using the TLS protocol with LDAP are to ensure connection confidentiality and integrity, and to optionally provide for authentica- tion. TLS expressly provides these capabilities, as described in [TLS]. All security gained via use of the Start TLS operation is gained by the use of TLS itself. The Start TLS operation, on its own, does not provide any additional security. Hodges, Morgan, Wahl [Page 8] I-D LDAPv3: Extension for Transport Layer Security February 2000 The use of TLS does not provide or ensure for confidentiality and/or non-repudiation of the data housed by an LDAP-based directory server. Nor does it secure the data from inspection by the server administra- tors. Once established, TLS only provides for and ensures confidential- ity and integrity of the operations and data in transit over the LDAP association, and only if the implementations on the client and server support and negotiate it. The level of security provided though the use of TLS depends directly on both the quality of the TLS implementation used and the style of usage of that implementation. Additionally, an active-intermediary attacker can remove the Start TLS extended operation from the supportedExtension attribute of the root DSE. Therefore, both parties SHOULD independently ascertain and consent to the security level achieved once TLS is esta- blished and before begining use of the TLS connection. For example, the security level of the TLS connection might have been negotiated down to plaintext. Clients SHOULD either warn the user when the security level achieved does not provide confidentiality and/or integrity protection, or be con- figurable to refuse to proceed without an acceptable level of security. Client and server implementors SHOULD take measures to ensure proper protection of credentials and other confidential data where such meas- ures are not otherwise provided by the TLS implementation. Server implementors SHOULD allow for server administrators to elect whether and when connection confidentiality and/or integrity is required, as well as elect whether and when client authentication via TLS is required. 8. Acknowledgements The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their contri- butions to this document. 9. References [AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authenti- cation Methods for LDAP". INTERNET-DRAFT, Work In Pro- gress. draft-ietf-ldapext-authmeth-04.txt [LDAPv3] M. Wahl, S. Kille and T. Howes. "Lightweight Directory Access Protocol (v3)". RFC 2251. [ReqsKeywords] Scott Bradner. "Key Words for use in RFCs to Indicate Requirement Levels". RFC 2119. Hodges, Morgan, Wahl [Page 9] I-D LDAPv3: Extension for Transport Layer Security February 2000 [SASL] J. Myers. "Simple Authentication and Security Layer (SASL)". RFC 2222. [TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.0". RFC 2246. 10. Authors' Addresses Jeff Hodges Oblix, Inc. 18922 Forge Drive Cupertino, CA 95014 USA Phone: +1-408-861-6656 EMail: JHodges@oblix.com RL "Bob" Morgan Computing and Communications University of Washington Seattle, WA USA Phone: +1-206-221-3307 EMail: rlmorgan@washington.edu Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA Phone: +1 626 919 3600 EMail: Mark.Wahl@innosoft.com ----------------------------------- 11. Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any intel- lectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with Hodges, Morgan, Wahl [Page 10] I-D LDAPv3: Extension for Transport Layer Security February 2000 respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this stan- dard. Please address the information to the IETF Executive Director. 12. Copyright Notice and Disclaimer Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hodges, Morgan, Wahl [Page 11] --==_Exmh_5686075430-- From list@netscape.com Thu Feb 10 12:32: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 MAA05157 for ; Thu, 10 Feb 2000 12:32:22 -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 JAA22703; Thu, 10 Feb 2000 09:29:50 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA01012; Thu, 10 Feb 2000 09:31:35 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:31:35 -0800 (PST) Message-Id: <3.0.5.32.20000210093128.00984100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 09:31:28 -0800 To: "Mcauliffe, Kristin" From: "Kurt D. Zeilenga" Subject: Re: Question on Extensible Match Filter Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"VOZJKD.A.iP.2Xvo4"@glacier> 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:02 AM 2/10/00 -0500, Mcauliffe, Kristin wrote: >I am working on LDAP v3 Search filters and cannot seem to get a return from >the DS servers (Netscape, Novell NDS and MS AD) that I am testing using the >Extensible Match string. I suggest you request help on a forum specific to the implementation of LDAPv3 you are using. >I am following the definition identified in >RFC2254 and those identified in Chapter 3 of "Understanding and Deploying >LDAP DS" (and the examples). I have used both the assertion syntax and the >value syntax. > >The results received are: > >Bind operation successful. >ldap_search_s: Protocol error >ldap_search_s: additional info: Bad search filter Looks like you sent the filter to an LDAPv2 server. An LDAPv3 should not have returned a protocol error just because it doesn't recognize extended search filter or other filter details. RFC 2251: A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. If an attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter is not recognized by the server, a matching rule id in the extensibleMatch is not recognized by the server, the assertion value cannot be parsed, or the type of filtering requested is not implemented, then the filter is Undefined. I suggest contacting your server vendor. Be sure to provide the exact search filter specified and other detail likely to assist the vendor in helping you. Kurt From list@netscape.com Thu Feb 10 12:44:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05459 for ; Thu, 10 Feb 2000 12:44:29 -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 JAA02283; Thu, 10 Feb 2000 09:39:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA07790; Thu, 10 Feb 2000 09:43:18 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:43:18 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Thu, 10 Feb 2000 09:43:42 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: IETF ldapext WG Subject: LDAP subtree search with zero-length DN for baseObject? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"5F18tD.A.Q5B.0ivo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com RFC 2251 says, in section 3.4: An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter "(objectClass=*)", however they are subject to access control restrictions. The root DSE MUST NOT be included if the client performs a subtree search starting from the root. It isn't clear to me, though, what the expected result should be from a subtree search where the baseObject is the zero-length DN. It mustn't include the root DSE info, but what should it include? Should this mean "the subtree rooted at root of the global DIT"? Presumably, if so, in existing cases this would typically fail since the DSA doesn't know how to contact a DSA for "the root". Or can a DSA interpret it as "search all the naming contexts you have locally?" By experiment I find that servers I've tried this on report "no such object". Thanks, - RL "Bob" From list@netscape.com Thu Feb 10 12:49:53 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05579 for ; Thu, 10 Feb 2000 12:49: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 JAA26615; Thu, 10 Feb 2000 09:46:42 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA12347; Thu, 10 Feb 2000 09:48:23 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:48:23 -0800 (PST) Message-ID: <90B308416283D311978B0090272BF7F503C1DA@mail.availnetworks.com> From: Ron Carter To: IETF ldapext WG Subject: RE: Notification: Inbound Mail Failure Date: Thu, 10 Feb 2000 12:47:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF73EE.F141B810" Resent-Message-ID: <"rj6pd.A.RAD.mnvo4"@glacier> 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_01BF73EE.F141B810 Content-Type: text/plain; charset="iso-8859-1" This user is no longer with our company. Please remove him from your list. Ron Carter Network Administrator Avail Networks 305 E. Eisenhower pkwy. Ann Arbor, MI 48108 (734) 332-5578 rcarter@availnetworks.com -----Original Message----- From: Ron Carter Sent: Thursday, February 10, 2000 12:43 PM To: Ron Carter Subject: Notification: Inbound Mail Failure The following recipients did not receive the attached mail. Reasons are listed with each recipient: rich@nei.com MSEXCH:IMS:avail:site-1:AVAIL-EXC 0 (000C05A6) Unknown Recipient The message that caused this notification was: ------_=_NextPart_001_01BF73EE.F141B810 Content-Type: text/html; charset="iso-8859-1" RE: Notification: Inbound Mail Failure

This user is no longer with our company. Please remove him from your list.

Ron Carter
Network Administrator
Avail Networks
305 E. Eisenhower pkwy.
Ann Arbor, MI   48108
(734) 332-5578
rcarter@availnetworks.com


-----Original Message-----
From: Ron Carter
Sent: Thursday, February 10, 2000 12:43 PM
To: Ron Carter
Subject: Notification: Inbound Mail Failure


The following recipients did not receive the attached mail. Reasons are listed with each recipient:

<rich@nei.com> rich@nei.com
        MSEXCH:IMS:avail:site-1:AVAIL-EXC 0 (000C05A6) Unknown Recipient

The message that caused this notification was:

 

------_=_NextPart_001_01BF73EE.F141B810-- From list@netscape.com Thu Feb 10 12:56:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05769 for ; Thu, 10 Feb 2000 12:56: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 JAA28232; Thu, 10 Feb 2000 09:53:27 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA17168; Thu, 10 Feb 2000 09:55:12 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:55:12 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 10 Feb 2000 10:54:57 -0700 From: "Jim Sermersheim" To: , Subject: Re: LDAP subtree search with zero-length DN for baseObject? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"HxA5_B.A.-LE.Auvo4"@glacier> 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 MAA05769 Our server follows the "search all the naming contexts you have locally" model which I think is reasonable. Jim >>> "RL 'Bob' Morgan" 2/10/00 10:43:42 AM >>> RFC 2251 says, in section 3.4: An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter "(objectClass=*)", however they are subject to access control restrictions. The root DSE MUST NOT be included if the client performs a subtree search starting from the root. It isn't clear to me, though, what the expected result should be from a subtree search where the baseObject is the zero-length DN. It mustn't include the root DSE info, but what should it include? Should this mean "the subtree rooted at root of the global DIT"? Presumably, if so, in existing cases this would typically fail since the DSA doesn't know how to contact a DSA for "the root". Or can a DSA interpret it as "search all the naming contexts you have locally?" By experiment I find that servers I've tried this on report "no such object". Thanks, - RL "Bob" From list@netscape.com Thu Feb 10 13:08: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 NAA06188 for ; Thu, 10 Feb 2000 13:08: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 KAA08082; Thu, 10 Feb 2000 10:04:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA23636; Thu, 10 Feb 2000 10:07:35 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:07:35 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 10 Feb 2000 11:07:14 -0700 From: "Jim Sermersheim" To: , , , Subject: Re: RFC2251: RootDSE subschemasubentry issue Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"zpo8mB.A.7wF.m5vo4"@glacier> 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 NAA06188 >>> "David Chadwick" 2/10/00 7:24:12 AM >>> >So we really need placeholders for all of these. >It seems to me like the rootDSE should hold server specific >attributes, a subentry under the NC context prefix should hold NC >specific attributes (this is in line with the LDUP group I believe), and >a subentry under an Admin Point should hold Man Domain specific >attributes (this is in line with X.500(93)). > >What do you think? >Or, an attribute which lists NCs and have subentries under the NCs, >so that no pointer is needed in the rootDSE. This makes sense to me. The current model of listing the DN's of all known subschema subentries is confusing because of the "decoupled from NCs" problems already discussed. As long as a client can discover the NCs, it can discover the entire set of subschema subentries. Jim From list@netscape.com Thu Feb 10 13:13:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06313 for ; Thu, 10 Feb 2000 13:13: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 KAA09531; Thu, 10 Feb 2000 10:09:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA27737; Thu, 10 Feb 2000 10:12:42 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:12:42 -0800 (PST) Message-Id: <3.0.5.32.20000210101238.009a0100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 10:12:38 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: draft-ietf-ldapext-ldapv3-tls-06.txt Cc: jhodges@oblix.com, RLBob Morgan , Mark Wahl , LDAP extensions In-Reply-To: <200002101717.JAA01460@breakaway.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"2hirQC.A.HxG.Z-vo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Jeff, I have only significant concern. In 6.1.2: [Upon failure of BIND SASL/EXTERNAL...] The LDAP association's authentication identity and authorization identity (if any) which were in effect after TLS establishment but prior to making the Bind request, MUST remain in force. This is inconsistent with RFC 2251 prescribed behavior: Clients MAY send multiple bind requests on a connection to change their credentials. ... Authentication from earlier binds are subsequently ignored, and so if the bind fails, the connection will be treated as anonymous. I can find no compelling reasoning why BIND failure whilst TLS is enabled should have special behavior. I believe this an unnecessary complication. I believe there are many good reasons why this BIND behavior should be consistent without regard to TLS (or IPSEC or whatever). Reasons: simplicity of specification, implementation, and use. The general rule for security is simplicity. Why the complication? From list@netscape.com Thu Feb 10 13:20: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 NAA06591 for ; Thu, 10 Feb 2000 13:20:36 -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 KAA03976; Thu, 10 Feb 2000 10:18:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA02411; Thu, 10 Feb 2000 10:19:56 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:19:56 -0800 (PST) Date: Thu, 10 Feb 2000 12:18:50 -0600 From: Mark Wahl Subject: Re: LDAP subtree search with zero-length DN for baseObject? In-reply-to: "Your message of Thu, 10 Feb 2000 09:43:42 PST." Sender: Mark.Wahl@INNOSOFT.COM To: "RL 'Bob' Morgan" Cc: IETF ldapext WG Message-id: <3425.950206730@threadgill.austin.innosoft.com> Resent-Message-ID: <"1x8DKC.A.Xl.LFwo4"@glacier> 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 can tell you what at least one implementation does in the case of a search that is not baseObject and the base name is zero length: 1) If the server is configured to hold ALL naming contexts immediately subordinate to the root (it is a top level server), then it searches each of these naming contexts that are immediately subordinate to the root, and any subordinate contexts as normal. 2) If the server is configured with a superior reference, then it returns a referral. 3) Otherwise it returns an error such as noSuchObject. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Thu Feb 10 13:20:43 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06601 for ; Thu, 10 Feb 2000 13:20:41 -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 KAA10903; Thu, 10 Feb 2000 10:16:32 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA02521; Thu, 10 Feb 2000 10:20:02 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:20:02 -0800 (PST) Message-Id: <3.0.5.32.20000210101955.00990950@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 10:19:55 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LDAP subtree search with zero-length DN for baseObject? Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"VevoP.A.0m.RFwo4"@glacier> 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:54 AM 2/10/00 -0700, Jim Sermersheim wrote: >Our server follows the "search all the naming contexts you have locally" model which I think is reasonable. Our server returns noSuchObject (or superior referral) unless the server is configured to be a global root server (experimental only). From list@netscape.com Thu Feb 10 13:22: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 NAA06654 for ; Thu, 10 Feb 2000 13:22:45 -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 KAA11764; Thu, 10 Feb 2000 10:18:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA05274; Thu, 10 Feb 2000 10:21:53 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:21:53 -0800 (PST) Date: Thu, 10 Feb 2000 12:20:45 -0600 From: Mark Wahl Subject: Re: RFC2251: RootDSE subschemasubentry issue In-reply-to: "Your message of Thu, 10 Feb 2000 11:07:14 MST." Sender: Mark.Wahl@INNOSOFT.COM To: Jim Sermersheim Cc: ietf-ldapext@netscape.com, Kurt@OpenLDAP.org, d.w.chadwick@salford.ac.uk Message-id: <3678.950206845@threadgill.austin.innosoft.com> Resent-Message-ID: <"W4ygPD.A.ISB.AHwo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > As long as a client can discover the NCs, it can discover the entire > set of subschema subentries. This doesn't work where there are subschema administrative areas inside of naming contexts. You put the subschema subentry below the subschema admin point, not below the naming context prefix. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Thu Feb 10 13:35: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 NAA07034 for ; Thu, 10 Feb 2000 13:35: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 KAA14018; Thu, 10 Feb 2000 10:29:57 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA12379; Thu, 10 Feb 2000 10:33:29 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:33:29 -0800 (PST) Date: Thu, 10 Feb 2000 12:33:17 -0600 From: Andy Coulbeck Subject: Re: RFC2251: RootDSE subschemasubentry issue Sender: Andy.Coulbeck@INNOSOFT.COM To: Jim Sermersheim Cc: M.Wahl@INNOSOFT.COM, ietf-ldapext@netscape.com, Kurt@OpenLDAP.org, d.w.chadwick@salford.ac.uk Message-id: <38A3046D.FBC7D91D@innosoft.com> Organization: Innosoft International Inc. MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: fr, en References: Resent-Message-ID: <"UuDmUB.A.vAD.3Rwo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > > >>> "David Chadwick" 2/10/00 7:24:12 AM >>> > > >So we really need placeholders for all of these. > >It seems to me like the rootDSE should hold server specific > >attributes, a subentry under the NC context prefix should hold NC > >specific attributes (this is in line with the LDUP group I believe), and > >a subentry under an Admin Point should hold Man Domain specific > >attributes (this is in line with X.500(93)). > > > >What do you think? > > > > >Or, an attribute which lists NCs and have subentries under the NCs, > >so that no pointer is needed in the rootDSE. > > This makes sense to me. The current model of listing the DN's of all known subschema subentries is confusing because of the "decoupled from NCs" problems already discussed. As long as a client can discover the NCs, it can discover the entire set of subschema subentries. > > Jim As Thomas Salter has already pointed out, the subschema subentry associated with a given naming context can be found by reading the naming context entry. The root DSE already contains the set of naming contexts. Therefore the current model is not broken. Also, in the current model, a server may have several naming contexts referring to a single subschema subentry. This would not be possible if subschema subentries were assumed to be under the naming context. From list@netscape.com Thu Feb 10 13:38:19 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07156 for ; Thu, 10 Feb 2000 13:38: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 KAA10030; Thu, 10 Feb 2000 10:35:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA15874; Thu, 10 Feb 2000 10:37:39 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 10:37:39 -0800 (PST) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <38A3056D.64A8167@netscape.com> Date: Thu, 10 Feb 2000 13:37:33 -0500 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: John Storry , John Storry CC: ietf-ldapext@netscape.com Subject: Re: Please remove from mailing list References: <017E033801420200@mailgate.netconnect.co.uk> Content-Type: multipart/mixed; boundary="------------7977908668D4FCB925CFF188" Resent-Message-ID: <"JuSG7D.A.d3D.xVwo4"@glacier> 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. --------------7977908668D4FCB925CFF188 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Storry wrote: > > Could you please remove the following: > > dnesbitt@netconnect.co.uk from your mailing list ASAP as this user is no > longer employed by this company. Please, please do not send "unsubscribe" and other administrative requests to the entire LDAPEXT mailing list! See: http://www.ietf.org/html.charters/ldapext-charter.html for list information. Or just try the nearly universal Internet convention of sending administrative requests to -request, i.e., mailto:ietf-ldapext-REQUEST@netscape.com Thanks. I won't repeat this again soon, so I hope everyone is paying attention. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? --------------7977908668D4FCB925CFF188 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from aka.mcom.com ([205.217.237.180]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FPQ6TK00.S2Q for ; Thu, 10 Feb 2000 09:48:56 -0800 Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA13086 for mcs; Thu, 10 Feb 2000 09:48:56 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 09:48:56 -0800 (PST) Message-ID: <90B308416283D311978B0090272BF7F503C1DA@mail.availnetworks.com> From: Ron Carter To: IETF ldapext WG Subject: RE: Notification: Inbound Mail Failure Date: Thu, 10 Feb 2000 12:47:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF73EE.F141B810" Resent-Message-ID: <"rj6pd.A.RAD.mnvo4"@glacier> 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_01BF73EE.F141B810 Content-Type: text/plain; charset="iso-8859-1" This user is no longer with our company. Please remove him from your list. Ron Carter Network Administrator Avail Networks 305 E. Eisenhower pkwy. Ann Arbor, MI 48108 (734) 332-5578 rcarter@availnetworks.com -----Original Message----- From: Ron Carter Sent: Thursday, February 10, 2000 12:43 PM To: Ron Carter Subject: Notification: Inbound Mail Failure The following recipients did not receive the attached mail. Reasons are listed with each recipient: rich@nei.com MSEXCH:IMS:avail:site-1:AVAIL-EXC 0 (000C05A6) Unknown Recipient The message that caused this notification was: ------_=_NextPart_001_01BF73EE.F141B810 Content-Type: text/html; charset="iso-8859-1" RE: Notification: Inbound Mail Failure

This user is no longer with our company. Please remove him from your list.

Ron Carter
Network Administrator
Avail Networks
305 E. Eisenhower pkwy.
Ann Arbor, MI   48108
(734) 332-5578
rcarter@availnetworks.com


-----Original Message-----
From: Ron Carter
Sent: Thursday, February 10, 2000 12:43 PM
To: Ron Carter
Subject: Notification: Inbound Mail Failure


The following recipients did not receive the attached mail. Reasons are listed with each recipient:

<rich@nei.com> rich@nei.com
        MSEXCH:IMS:avail:site-1:AVAIL-EXC 0 (000C05A6) Unknown Recipient

The message that caused this notification was:

 

------_=_NextPart_001_01BF73EE.F141B810-- --------------7977908668D4FCB925CFF188-- From list@netscape.com Thu Feb 10 14:01: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 OAA07688 for ; Thu, 10 Feb 2000 14:01: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 KAA14406; Thu, 10 Feb 2000 10:59:28 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA29470; Thu, 10 Feb 2000 11:01:14 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 11:01:14 -0800 (PST) Message-Id: <3.0.5.32.20000210110056.00991ad0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 11:00:56 -0800 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: RFC2251: RootDSE subschemasubentry issue Cc: ietf-ldapext@netscape.com, Mark Wahl In-Reply-To: References: <3.0.5.32.20000209115809.00970b70@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"6nrhXB.A.KMH.5rwo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 02:22 PM 2/10/00 -0000, David Chadwick wrote: > >> At 07:26 PM 2/9/00 -0000, David Chadwick wrote: >> >Do you agree with this analysis? >> >> Yes. > >Good, we are making progress towards resolution. > >> >> The next questions are: >> >> What other attributes published in RootDSE are naming >> context specific? > >The question should actually be wider than this I believe. i.e. What >attributes are NC specific and what attributes are server specific >and what attributes are Management Domain specific, since > >i) a Man Domain can comprise many servers >ii) a server can hold many NCs >iii) a server can hold many Man Domains. Yes... >It seems to me like the rootDSE should hold server specific >attributes, a subentry under the NC context prefix should hold NC >specific attributes (this is in line with the LDUP group I believe), and >a subentry under an Admin Point should hold Man Domain specific >attributes (this is in line with X.500(93)). > >What do you think? Might be workable... [see below] > >> From the design perpective, I see different ways of >> providing naming context specific information: >> >> 1) add new attributes which provide the context >> and the capability as combined value. (Ie: >> 1A) dn: (root dse) >> subschemasubentries: dc=openldap,dc=org $ >> ( cn=subschema $ cn=openldap-subschema ) >> subschemasubentries: dc=example,dc=com $ cn=subschema >> ... >> >> or: >> 1B) dn: (root dse) >> subschemasubentries: dc=openldap,dc=org $ cn=subschema >> subschemasubentries: dc=openldap,dc=org $ cn=opendlap-subschema >> subschemasubentries: dc=example,dc=com $ cn=subschema >> >> 2) provide an attribute which lists naming contexts >> AND a provides a DN of an entry (or subentry) which >> contains attributes describing the naming context >> specific capabilities. > >Or, an attribute which lists NCs and have subentries under the NCs, >so that no pointer is needed in the rootDSE. I would like to have attribute type in the NC who's value named the entry (or subentry) so as to avoid hardcoding the DN of the subentry. So, I'd like a pointer... but the pointer can be in the NC. If in the RootDSE, then it needs to contain both the DN of the namingContext and the DN of the subentry. >Why would you have 2 subschemasubentries for 1 NC? Separate subschema administrative areas within the NC. [See Mark Wahl's comment] From list@netscape.com Thu Feb 10 14:12: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 OAA07992 for ; Thu, 10 Feb 2000 14:12:39 -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 LAA22434; Thu, 10 Feb 2000 11:08:17 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA06447; Thu, 10 Feb 2000 11:11:48 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 11:11:48 -0800 (PST) Sender: kristian@netscape.com (John Kristian) Message-ID: <38A30D72.BEEEC837@netscape.com> Date: Thu, 10 Feb 2000 11:11:46 -0800 From: John Kristian Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: "Mcauliffe Kristin" CC: ietf-ldapext@netscape.com Subject: Re: Question on Extensible Match Filter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"E5-LXD.A.dkB.z1wo4"@glacier> 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 Your query is somewhat off-topic here. A better forum would be snews://secnews.netscape.com/netscape.server.directory or news://news.mozilla.org/netscape.public.mozilla.directory See also http://help.netscape.com/products/server/directory/index.html "Mcauliffe, Kristin" wrote: > I ... cannot seem to get a return from the DS servers (Netscape, Novell NDS > and MS AD) that I am testing using the Extensible Match string. http://home.netscape.com/eng/server/directory/4.1/admin/find.htm#1041100 might be helpful. From list@netscape.com Thu Feb 10 15:38: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 PAA09999 for ; Thu, 10 Feb 2000 15:38: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 MAA00319; Thu, 10 Feb 2000 12:35:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA11588; Thu, 10 Feb 2000 12:37:15 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 12:37:15 -0800 (PST) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <38A32174.6E0ECA06@netscape.com> Date: Thu, 10 Feb 2000 15:37:08 -0500 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Mark Meredith CC: M.Wahl@INNOSOFT.COM, Roger Harrison , ietf-ldapext@netscape.com Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uDo-iC.A.y0C.6Fyo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Mark Meredith wrote: > I will add your suggestion to section 6 Notes to Client Developers. To read > something like this. > > 6. Notes to Client Developers > > The use of vendorName and vendorVersion SHOULD NOT be used to > discover features. It is just an informational attribute. If a > client relies on a vendorVersion number then that client MUST > be coded to work with later versions and not just one version and > no other. > > If the client does not recognize the specific vendorName/vendorVersion as > one it has for its 'bug workaround needed' table, then the client MUST > assume that the server it is talking to is complete and correct. > > Does this look ok? I think this text is an improvement. But the "Overview" text also implies that these attributes should be used for discovering some features: 3. Overview The root DSE query is a mechanism used by clients to find out what controls, extensions, etc. is available from a given LDAP server. It is useful to be able to query an LDAP server to determine the vendor of that server and see what version of that vendor's code is currently installed. Since vendors can implement X- options for attributes, classes, and syntaxes (described in section 4 of [RFC2251] and section 4 of [RFC2252] ) that may or may not be published, this would allow users or applications to be able to determine if these features are available from a given server. I feel strongly that this document should consistently say that the vendorName and vendorVersion attribute values must only be used to work around bugs and shortcomings of a server and for purely informational (e.g., display) purposes. If others agree, the overview should be revised as well. If there are X- options that are adding real value to subschema values, let's start a discussion about them (and a document if appropriate). I suspect there are, given that several vendors (including iPlanet/Sun/netscape) are using various X- options today in their products. Also, the format for vendorVersion should be more fully specified. It is specified as an integer. But what if I need to publish version 4.11? I suggest making the value "version multiplied times 100" or using a string format. I also wonder if there should be a vendorProductName attribute as well, given that some vendors produce more than one product that processes LDAP requests. I suppose the vendorName field can be overloaded for that purpose, e.g., vendorName: OpenLDAP / slapd vendorName: OpenLDAP / ldapd ... but a separate attribute might be better. A minor formatting comment: the draft includes at least two non-ASCII characters (one in the "Overview" section and one in the "Author's Addresses" section). I think both were intended to be apostrophes ('). -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Thu Feb 10 15:54:38 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10403 for ; Thu, 10 Feb 2000 15: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 MAA06249; Thu, 10 Feb 2000 12:47:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA15928; Thu, 10 Feb 2000 12:51:11 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 12:51:11 -0800 (PST) Message-Id: <3.0.5.32.20000210125106.00926100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 12:51:06 -0800 To: Mark Smith From: "Kurt D. Zeilenga" Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt Cc: Mark Meredith , M.Wahl@INNOSOFT.COM, Roger Harrison , ietf-ldapext@netscape.com In-Reply-To: <38A32174.6E0ECA06@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"XkXAs.A.W4D.-Syo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:37 PM 2/10/00 -0500, Mark Smith wrote: >Also, the format for vendorVersion should be more fully specified. I disagree. Since you state that this should be for display purposes and/or for working around known bugs specific to this version, the only match that makes sense is EQUALITY. I suggest the values of this attribute type have syntax DirectoryString and that an equality rule of CaseExactMatch be provided. No ordering or substrings match, IMO, should be provided these would promote uses beyond that which is intended. (this doesn't disallow some vendor from support such via extended search filters) >I also wonder if there should be a vendorProductName attribute as well, >given that some vendors produce more than one product that processes >LDAP requests. Or some products might be comprised of software from multiple vendors... many server implementations support plugin architectures after all. In many cases, the vendor providing the core implementation is not the primary vendor providing the end "product". This is a rat hole. From list@netscape.com Thu Feb 10 16:40:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11269 for ; Thu, 10 Feb 2000 16:40: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 NAA15096; Thu, 10 Feb 2000 13:35:38 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA05398; Thu, 10 Feb 2000 13:39:08 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 13:39:08 -0800 (PST) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <38A32FF7.D37AC34B@netscape.com> Date: Thu, 10 Feb 2000 16:39:03 -0500 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Mark Meredith , M.Wahl@INNOSOFT.COM, Roger Harrison , ietf-ldapext@netscape.com Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt References: <3.0.5.32.20000210125106.00926100@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6_wG8.A.DUB.7_yo4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 03:37 PM 2/10/00 -0500, Mark Smith wrote: > >Also, the format for vendorVersion should be more fully specified. > > I disagree. Since you state that this should be for > display purposes and/or for working around known bugs specific > to this version, the only match that makes sense is EQUALITY. > I suggest the values of this attribute type have syntax DirectoryString > and that an equality rule of CaseExactMatch be provided. No > ordering or substrings match, IMO, should be provided these > would promote uses beyond that which is intended. (this doesn't > disallow some vendor from support such via extended search filters) But your comment seems to be in conflict with this text from the document: > 6. Notes to Client Developers > > The use of vendorName and vendorVersion SHOULD NOT be used to > discover features. It is just an informational attribute. If a > client relies on a vendorVersion number then that client MUST > be coded to work with later versions and not just one version and > no other. I'd be happy to see the last sentence removed. Clients that rely on this attribute do so at their own risk and they should code the behavior that they think is best for them. This draft can't stipulate that an older client will work correctly with a newer server which, for example, includes a bug fix that introduces incompatibilities with older clients. > > >I also wonder if there should be a vendorProductName attribute as well, > >given that some vendors produce more than one product that processes > >LDAP requests. > > Or some products might be comprised of software from multiple vendors... > many server implementations support plugin architectures after all. > In many cases, the vendor providing the core implementation is not > the primary vendor providing the end "product". This is a rat hole. Good point. I agree. So we might as well just stick with one value (vendorName). -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Thu Feb 10 18:07: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 SAA12688 for ; Thu, 10 Feb 2000 18:07:39 -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 PAA23686; Thu, 10 Feb 2000 15:04:46 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA14884; Thu, 10 Feb 2000 15:06:31 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 15:06:31 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: Jim Sermersheim , Andy Coulbeck Date: Thu, 10 Feb 2000 23:04:29 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk CC: M.Wahl@INNOSOFT.COM, ietf-ldapext@netscape.com, Kurt@OpenLDAP.org, d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: <38A3046D.FBC7D91D@innosoft.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"ojl5jC.A.OoD.1R0o4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > As Thomas Salter has already pointed out, the subschema subentry > associated with a given naming context can be found by reading the > naming context entry. This is true. >The root DSE already contains the set of naming > contexts. Therefore the current model is not broken. . Not broken in that way, but it still is, in that a single valued attribute is required to hold multiple values >Also, in the > current model, a server may have several naming contexts referring to > a single subschema subentry. This would not be possible if subschema > subentries were assumed to be under the naming context. I dealt with this one by saying that in this case the subschema subentry would be below the administrative point for the domain, if they are all in the same management domain (In fact this is the model the NHS are using in the UK). Hope that helps David > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Feb 10 18:08:26 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12689 for ; Thu, 10 Feb 2000 18:07:39 -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 PAA05750; Thu, 10 Feb 2000 15:03:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA14926; Thu, 10 Feb 2000 15:06:32 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 15:06:32 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, Mark Wahl Date: Thu, 10 Feb 2000 23:04:27 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: <3.0.5.32.20000210110056.00991ad0@infidel.boolean.net> References: X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"8xAQuB.A.roD.3R0o4"@glacier> 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 > >Why would you have 2 subschemasubentries for 1 NC? > > Separate subschema administrative areas within the NC. > [See Mark Wahl's comment] > I proposed solving this problem by having separate subschema subentries below each administrative point (ala X.500), then we still can retain single valued attributes. This is what I understood Mark was also proposing. Since the NC will probably be (but not necessarily) an administrative point anyway, then it will usually have a subschema subentry below it. For the few (rare?) cases where the NC is not an admin point (e.g. an orgs DIT is distributed across 2 servers and thus 2 NCs, but both are controlled by the same subschema) X.500 proposes having one subentry beneath the upper NC, and this would be replicated into the subordinate server. LDAP servers could choose instead to hold a copy of this subschema subentry beneath the subordinate NC context prefix if you wished to, or you could go with the X.500 model). I dont object to you also holding a pointer in the NC, holding the DN of the subschemasubentry directly beneath it, if you want to, although it only adds minor efficiency gains since the subentry is immediately subordinate to the NC context prefix entry anyway. David > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Thu Feb 10 18:23:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12849 for ; Thu, 10 Feb 2000 18:23: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 PAA08868; Thu, 10 Feb 2000 15:18:45 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA22063; Thu, 10 Feb 2000 15:22:13 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 15:22:13 -0800 (PST) Message-Id: <3.0.5.32.20000210152203.00986150@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Feb 2000 15:22:03 -0800 To: Mark Smith From: "Kurt D. Zeilenga" Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt Cc: Mark Meredith , M.Wahl@INNOSOFT.COM, Roger Harrison , ietf-ldapext@netscape.com In-Reply-To: <38A32FF7.D37AC34B@netscape.com> References: <3.0.5.32.20000210125106.00926100@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"rlSd8D.A.aYF.kg0o4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My basic option on this proposal as a whole: I think implementations that needs such specific vendor/version information are fundamentally broken. That is, a client should be liberal enough to workaround any reasonable non-strict behavior of the servers (and vice versa). Clients SHOULD NOT be modified to support servers who's behavior is not reasonable (and vice versa). As such, I can only support such attributes if their use is is restricted to DISPLAY PURPOSES ONLY. At 04:39 PM 2/10/00 -0500, Mark Smith wrote: >But your comment seems to be in conflict with this text from the >document: That might be true. My point is that if the intent is to work around bugs in a specific version, then only an equality test for specific versions (known by the client to have bugs) is needed. All other versions should be considered to properly implement specifications. > >> 6. Notes to Client Developers >> >> The use of vendorName and vendorVersion SHOULD NOT be used to >> discover features. It is just an informational attribute. If a >> client relies on a vendorVersion number then that client MUST >> be coded to work with later versions and not just one version and >> no other. >Clients that rely on this attribute do so at their own risk I concur with this statement. >and they should code the behavior that they think is best for them. >This draft can't stipulate that an >older client will work correctly with a newer server which, for example, >includes a bug fix that introduces incompatibilities with older clients. Right... so next folks will ask that we extend the protocol so that servers will know the vendorName/vendorVersion of CLIENTS so servers can adapt to clients. One-off workarounds lead to future inoperability problems. > > > >> >> >I also wonder if there should be a vendorProductName attribute as well, >> >given that some vendors produce more than one product that processes >> >LDAP requests. >> >> Or some products might be comprised of software from multiple vendors... >> many server implementations support plugin architectures after all. >> In many cases, the vendor providing the core implementation is not >> the primary vendor providing the end "product". This is a rat hole. > >Good point. I agree. So we might as well just stick with one value >(vendorName). Again, who's the vendor? Is the implementor core server the vendor? Is the packager who screwed their build the vendor? Is the implementor of the buggy syntax plugin the vendor? Is the OS vendor who shipped a buggy support library? Is the support contractor the vendor? This is a rat hole. From list@netscape.com Thu Feb 10 18:33:44 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12955 for ; Thu, 10 Feb 2000 18:33: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 PAA28089; Thu, 10 Feb 2000 15:30:55 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA28545; Thu, 10 Feb 2000 15:32:41 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 15:32:41 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Thu, 10 Feb 2000 16:33:11 -0700 (MST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: Jim Sermersheim cc: ietf-ldapext@netscape.com Subject: Re: LDAP subtree search with zero-length DN for baseObject? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"s3J3t.A.V9G.Xq0o4"@glacier> 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 Thu, 10 Feb 2000, Jim Sermersheim wrote: > Our server follows the "search all the naming contexts you have > locally" model which I think is reasonable. So, in the terms Mark and Kurt use, a Novell directory always acts like a top-level or global-root server? - RL "Bob" From list@netscape.com Thu Feb 10 19:20: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 TAA13282 for ; Thu, 10 Feb 2000 19:20: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 QAA04451; Thu, 10 Feb 2000 16:17:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA20390; Thu, 10 Feb 2000 16:19:21 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 16:19:21 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Thu, 10 Feb 2000 16:19:53 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: IETF ldapext WG Subject: proposed mods to draft-ietf-ldapext-locate-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"7FImQB.A.U-E.IW1o4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here are modifications I propose to draft-ietf-ldapext-locate-01.txt, based on my note of 20 Jan 2000, and some other stuff. - RL "Bob" --- [ This section 2 replaces the current section 2. ] 2. Introduction The LDAPv3 protocol [1] is designed to be a lightweight access protocol for directory services supporting X.500 models. As a distributed directory service, the complete set of directory information (known as the Directory Information Base) is spread across many different servers. Hence there is the need to determine, when initiating or processing a request, which servers hold the relevant information. In LDAP, the Search, Modify, Add, Delete, ModifyDN, and Compare operations all specify a Distinguished Name (DN) on which the operation is performed. A client, or a server acting on behalf of a client, must be able to determine the server(s) that hold the naming context containing that DN, since that server (or one of that set of servers) must receive and process the request. This determination process is called "server location". To support dynamic distributed operation, the information needed to support server location must be available via lookups done at request processing time, rather than, for example, as static data configured into each client or server. It is possible to maintain the information needed to support server location in the directory itself, and X.500 directory deployments typically do so. In practice, however, this only permits location of servers within a limited X.500-connected set. LDAP-specific methods of maintaining server location information in the directory have not yet been standardized. This document defines an alternative method of managing server location information using the Domain Name System. This method takes advantage of the global deployment of the DNS, by allowing LDAP server location information for any existing DNS domain to be published by creating the records described below. A full discussion of the benefits and drawbacks of the various directory location and naming methods is beyond the scope of this document. RFC 2247 defines an algorithm for mapping DNS domain names into DNs. This document defines the inverse mapping, from DNs to DNS domain names, based on the RFC 2247 conventions, for use in this server location method. The server location method described in this document is only defined for DNs that can be so mapped, i.e., those DNs that are based on domain names. In practice this is reasonable because many objects of interest are named with domain names, and use of domain-name-based DNs is becoming common. === [ This is a new section. ] N. Mapping Distinguished Names into Domain Names This section defines a method of converting a DN into a DNS domain name for use in the server location method described below. Some DNs cannot be converted into a domain name. The output domain name is initially empty. For each RDN component of the DN, beginning with the first, if the attribute type is "DC", then the attribute value is used as a domain name component (label). The first such value becomes the most significant (i.e., rightmost) domain name component, and successive values occupy less significant positions (i.e., extending leftward), in order. If the attribute type is not "DC", then processing stops. If the first RDN component of the DN is not of type "DC" then the DN cannot be converted to a domain name. [ At first I wrote that the conversion should include converting the RDN attribute value to a string as per RFC 2253, but upon reflection I think it should just use the bits, since of course DNS can in theory handle binary labels just as well as X.500 can. I'm not a charset expert so I don't know if in reality an IA5 RDN value will just drop in and become a nice ASCII DNS name. I think, though, that RFC 2247 is deficient in that it assumes that a DNS name being converted into a DN will always be just ASCII/IA5 strings. ] === Mods to items in the current section 3: 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. I think this is too loose about the relationship between the info on the LDAP server and the name of the SRV record used to locate it. So change the last bit to: where is always "ldap", and is a protocol that can be either "udp" or "tcp". is the domain name formed by converting the DN of a naming context mastered by the LDAP Server into a domain name using the algorithm in section N. Also: Presence of such records enables clients to find the LDAP servers using standard DNS query [3]. I think it's worthwhile to write down the algorithm in detail, hence follow this with: A client (or server) seeking an LDAP server for a particular DN converts that DN to a domain name using the algorithm of section N, does a SRV record query using the DNS name formed as described above: _ldap._tcp. and interprets the response as described in [6] to determine a host (or hosts) to contact. This continues with: As an example, a client that searches for an LDAP server in the example.net domain that supports TCP protocol But the LDAP client, for purposes of this document, starts with a DN, not a domain name, so make this: As an example, a client that searches for an LDAP server for the DN "dc=example,dc=net" that supports the TCP protocol ... From list@netscape.com Thu Feb 10 21:37:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14632 for ; Thu, 10 Feb 2000 21:37:18 -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 SAA05242; Thu, 10 Feb 2000 18:32:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA09923; Thu, 10 Feb 2000 18:36:02 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 18:36:02 -0800 (PST) Message-ID: From: Gil Kirkpatrick To: "'d.w.chadwick@salford.ac.uk'" , "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, Mark Wahl Subject: RE: RFC2251: RootDSE subschemasubentry issue Date: Thu, 10 Feb 2000 19:33:06 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Resent-Message-ID: <"FPkKyD.A.paC.QW3o4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com David, Why does the rootDSE need to contain subschemaSubentrys for each NC hosted by the server? Why is not sufficient to maintain the subschemaSubentrys in the NCs themselves? -gil Gil Kirkpatrick Director of Engineering Netpro > -----Original Message----- > From: David Chadwick [SMTP:d.w.chadwick@salford.ac.uk] > Sent: Wednesday, February 09, 2000 12:27 PM > To: Kurt D. Zeilenga; ietf-ldapext@netscape.com; Mark Wahl > Subject: Re: RFC2251: RootDSE subschemasubentry issue > > Mark, Kurt > > I think I have an answer to the problem(s) being posed by Kurt. > > The model as it stands is OK if a server only masters one naming > context. Everything works fine. All the entries in the NC and the > rootDSE can contain the subschemaSubentry attribute which points > to the single subschema subentry. > > The problem arises once we have multiple NCs in a server. The > subschemaSubentry attribute can still be single valued and exist in > each entry in each NC and point to the correct subschema > subentry. However, the attribute in the root DSE no longer works, for > two reasons. > > Firstly it is supposed to be single valued (as Kurt pointed out) and > now it needs to have multiple values. > > Secondly, (again as Kurt pointed out) there is no way for the user to > know from the multivalued attribute in the rootDSE which value > points to which subschema subentry for which NC. THis of course is > not a problem for the entries within the NC, as they only still need a > single pointer to their one and only subschema subentry. > > Thus I conclude that the model is broken for multiple naming > contexts, and that the subschemaSubentry attribute in the rootDSE > needs to be replaced by a multivalued attribute, having two > components - the context prefix of an NC (an LDAP DN), and the > pointer to the subschemaSubentry. > > Do you agree with this analysis? > > David > > *************************************************** > > David Chadwick > IS Institute, University of Salford, Salford M5 4WT > Tel +44 161 295 5351 Fax +44 161 745 8169 > Mobile +44 790 167 0359 > Email D.W.Chadwick@salford.ac.uk > Home Page http://www.salford.ac.uk/its024/chadwick.htm > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string MLJ9-DU5T-HV8J > > *************************************************** From list@netscape.com Thu Feb 10 23:24: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 XAA17732 for ; Thu, 10 Feb 2000 23:24: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 UAA28075; Thu, 10 Feb 2000 20:21:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id UAA04532; Thu, 10 Feb 2000 20:23:34 -0800 (PST) Resent-Date: Thu, 10 Feb 2000 20:23:34 -0800 (PST) From: "Peter Strong" To: "Kurt D. Zeilenga" , Mark Smith Cc: Mark Meredith , "M.Wahl" , Roger Harrison , ietf-ldapext Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Date: Thu, 10 Feb 2000 23:25:58 -0500 Message-ID: <001a01bf7448$185f2860$3750fb8d@net-pstrong.corpnorth.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.20000210152203.00986150@infidel.boolean.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Message-ID: <"Z0RXrB.A.iGB.F74o4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, February 10, 2000 6:22 PM > To: Mark Smith > Cc: Mark Meredith; M.Wahl@INNOSOFT.COM; Roger Harrison; > ietf-ldapext@netscape.com > Subject: Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt > > > My basic option on this proposal as a whole: > > I think implementations that needs such specific vendor/version > information are fundamentally broken. My basic opinion is that you are not living in the real world! I challenge you to modify the schema of a Netscape directory server, a Novell directory server and an MS Active Directory server without knowing the type of server to which you are connected. When we install our products against different directory implementations, we need to know the vendor - they all have quirks and irregularities that make such things as schema modification tricky. It would be ideal if this weren't the case, but it is, and probably always will be. > That is, a client should > be liberal enough to workaround any reasonable non-strict behavior > of the servers (and vice versa). Clients SHOULD NOT be modified > to support servers who's behavior is not reasonable (and vice > versa). For most basic operations, clients shouldn't experience difficulties. However, for things like schema modification, access control specification, creation of new naming roots or subtrees, I know that significant differences exist and that these differences won't go away any time soon. > As such, I can only support such attributes if their use is > is restricted to DISPLAY PURPOSES ONLY. Again, I have to disagree - we'll have to use this information to make appropriate choices in how to deal with particular server implementations. If we screw something up while doing this, well, that's our fault. But at least these small scraps of information give us a small chance of overcoming implementation descrepancies. > At 04:39 PM 2/10/00 -0500, Mark Smith wrote: > >But your comment seems to be in conflict with this text from the > >document: > > That might be true. My point is that if the intent is to > work around bugs in a specific version, then only an equality > test for specific versions (known by the client to have bugs) > is needed. All other versions should be considered to properly > implement specifications. Actually, the instances that I mentioned above don't appear to bugs. They appear to be cases where vendors have knowingly strayed from the standards (for whatever reason). More than likely, they haven't made these decisions without reason, and, when confronted about it, will likely indicate that they will "probably fix it in a future release". Yeah, right! In the mean time, I have to get product out the door. > > > >> 6. Notes to Client Developers > >> > >> The use of vendorName and vendorVersion SHOULD NOT be used to > >> discover features. It is just an informational attribute. If a > >> client relies on a vendorVersion number then that client MUST > >> be coded to work with later versions and not just one version and > >> no other. > > >Clients that rely on this attribute do so at their own risk > > I concur with this statement. > As do I. > >and they should code the behavior that they think is best for them. > > >This draft can't stipulate that an > >older client will work correctly with a newer server which, for example, > >includes a bug fix that introduces incompatibilities with older clients. > > Right... so next folks will ask that we extend the protocol > so that servers will know the vendorName/vendorVersion of > CLIENTS so servers can adapt to clients. > > One-off workarounds lead to future inoperability problems. Yes, but lack of any workaround leads to products that don't work AT ALL! We will always have interoperability problems. That's not being pessimistic, that's being realistic. I'm all for promoting as much interoperability and adherence to standards as possible, but I'm under no delusions that we'll ever achieve 100% interoperability for all directory implementations all the time. > > > > > > > >> > >> >I also wonder if there should be a vendorProductName > attribute as well, > >> >given that some vendors produce more than one product that processes > >> >LDAP requests. > >> > >> Or some products might be comprised of software from multiple > vendors... > >> many server implementations support plugin architectures after all. > >> In many cases, the vendor providing the core implementation is not > >> the primary vendor providing the end "product". This is a rat hole. > > > >Good point. I agree. So we might as well just stick with one value > >(vendorName). > Sounds fine. > Again, who's the vendor? Is the implementor core server the vendor? > Is the packager who screwed their build the vendor? Is the > implementor of the buggy syntax plugin the vendor? Is the OS > vendor who shipped a buggy support library? Is the support > contractor the vendor? > > This is a rat hole. > The only rat hole appears to be the argument against having a couple of simple attributes available to the poor bastards who have to actually build products on top of directory technology as it exists today! Regards, Peter ------------------------------------------------------------------------ Peter Strong Software Architect Nortel Networks - Optivity Policy Services (OPS) and NetID pestrong@nortelnetworks.com (613) 831-6615 From list@netscape.com Fri Feb 11 06:33: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 GAA03828 for ; Fri, 11 Feb 2000 06:33: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 DAA03987; Fri, 11 Feb 2000 03:28:17 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA10680; Fri, 11 Feb 2000 03:31:48 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 03:31:48 -0800 (PST) Message-Id: <200002111131.GAA03779@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-ldapv3-tls-06.txt Date: Fri, 11 Feb 2000 06:31:40 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"d57ARB.A.mmC.jM_o4"@glacier> 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 : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security Author(s) : J. Hodges, B. Morgan, M. Wahl Filename : draft-ietf-ldapext-ldapv3-tls-06.txt Pages : 11 Date : 10-Feb-00 This document defines the 'Start Transport Layer Security (TLS) Opera- tion' for LDAP [LDAPv3, TLS]. This operation provides for TLS establish- ment in an LDAP association and is defined in terms of an LDAP extended request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-tls-06.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-ldapv3-tls-06.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-ldapv3-tls-06.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: <20000210122219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldapv3-tls-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldapv3-tls-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000210122219.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Fri Feb 11 09:37:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09973 for ; Fri, 11 Feb 2000 09:37: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 GAA14696; Fri, 11 Feb 2000 06:32:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA11600; Fri, 11 Feb 2000 06:36:01 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 06:36:01 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Date: Fri, 11 Feb 2000 09:37:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"5_-JUD.A.90C.Q5Bp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I agree that clients need to determine what server they are talking to. It wasn't that long ago that servers didn't even agree on the character set. In V2 you could find servers using UTF8, T.61 and Latin-1. Granted that problem should be solved by now, but there are still many ambiguities in the RFCs and probably a number of "a server MAY ... " clauses that are not otherwise resolvable. These attributes are easy to implement and allow client writers to solve real world problems. From list@netscape.com Fri Feb 11 10:50:29 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12151 for ; Fri, 11 Feb 2000 10:50: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 HAA08780; Fri, 11 Feb 2000 07:47:11 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA04917; Fri, 11 Feb 2000 07:48:57 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 07:48:57 -0800 (PST) Message-ID: <38A4158C.102DDB73@netscape.com> Date: Fri, 11 Feb 2000 08:58:36 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Subject: Re: RFC2251: RootDSE subschemasubentry issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9jNPEB.A.jMB.o9Cp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit David Chadwick wrote: > > > As Thomas Salter has already pointed out, the subschema subentry > > associated with a given naming context can be found by reading the > > naming context entry. > > This is true. > > >The root DSE already contains the set of naming > > contexts. Therefore the current model is not broken. > > . Not broken in that way, but it still is, in that a single valued attribute > is required to hold multiple values I'd really prefer we choose the simple solution to this problem: change the subschemasubentry attribute to multivalued, but stipulate that it can only have one value when it appears outside the rootDSE. Does that solve the problem at hand? > > >Also, in the > > current model, a server may have several naming contexts referring to > > a single subschema subentry. This would not be possible if subschema > > subentries were assumed to be under the naming context. > > I dealt with this one by saying that in this case the subschema > subentry would be below the administrative point for the domain, if > they are all in the same management domain (In fact this is the > model the NHS are using in the UK). But as far as I know LDAPv3 doesn't require that servers support administrative domains at all. Some servers do, some do not. Also, what if the naming contexts are disjoint yet all share the same schema? That is a very common situation today. -- Mark Smith iPlanet Directory Architect / Sun-Netscape Alliance My words are my own, not my employer's. Got LDAP? From list@netscape.com Fri Feb 11 12:00:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14458 for ; Fri, 11 Feb 2000 12:00:07 -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 IAA18117; Fri, 11 Feb 2000 08:57:12 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA28622; Fri, 11 Feb 2000 08:58:59 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 08:58:59 -0800 (PST) Message-Id: <3.0.5.32.20000211085848.009b4dd0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 11 Feb 2000 08:58:48 -0800 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: RFC2251: RootDSE subschemasubentry issue Cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com In-Reply-To: <38A4158C.102DDB73@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"kJavuD.A.8-G.S_Dp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:58 AM 2/11/00 -0500, Mark C Smith wrote: >David Chadwick wrote: >> >> > As Thomas Salter has already pointed out, the subschema subentry >> > associated with a given naming context can be found by reading the >> > naming context entry. >> >> This is true. >> >> >The root DSE already contains the set of naming >> > contexts. Therefore the current model is not broken. >> >> . Not broken in that way, but it still is, in that a single valued attribute >> is required to hold multiple values > >I'd really prefer we choose the simple solution to this problem: >change the subschemasubentry attribute to multivalued, but stipulate >that it can only have one value when it appears outside the rootDSE. Sounds simple... but one cannot generally redefine an attribute type, one must introduce a replacement attribute type. >Does that solve the problem at hand? No, because the client doesn't which subset of entries may be controlled by a given value. Additional information is needed, such as a DN indicing the subtree of applicability, to make the information generally useful. > >> >> >Also, in the >> > current model, a server may have several naming contexts referring to >> > a single subschema subentry. This would not be possible if subschema >> > subentries were assumed to be under the naming context. >> >> I dealt with this one by saying that in this case the subschema >> subentry would be below the administrative point for the domain, if >> they are all in the same management domain (In fact this is the >> model the NHS are using in the UK). > >But as far as I know LDAPv3 doesn't require that servers support >administrative domains at all. Some servers do, some do not. Also, >what if the naming contexts are disjoint yet all share the same schema? >That is a very common situation today. I agree this is common and the information model should support sharing of subschema across multiple naming contexts. I suggest we don't adopt a means which "hardcodes" the name and/or location of subschema subentries so as to maintain the greatest amount of flexibility possible. From list@netscape.com Fri Feb 11 12:02:42 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14654 for ; Fri, 11 Feb 2000 12:02:36 -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 IAA00505; Fri, 11 Feb 2000 08:57:32 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA00290; Fri, 11 Feb 2000 09:01:06 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 09:01:06 -0800 (PST) Message-Id: <3.0.5.32.20000211090053.00925c90@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 11 Feb 2000 09:00:53 -0800 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Cc: ietf-ldapext In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"PfDVBC.A.PE.RBEp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:37 AM 2/11/00 -0500, Salter, Thomas A wrote: >These attributes are easy to implement and allow client writers to solve >real world problems. If clients are allowed to derive their behavior from these attributes than servers must be allowed to spoof their values to obtain desired behavior. Kurt From list@netscape.com Fri Feb 11 12:22:00 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15091 for ; Fri, 11 Feb 2000 12:21: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 JAA02862; Fri, 11 Feb 2000 09:17:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA09889; Fri, 11 Feb 2000 09:20:41 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 09:20:41 -0800 (PST) Message-Id: <3.0.5.32.20000211092029.00995960@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 11 Feb 2000 09:20:29 -0800 To: "Mark Meredith" From: "Kurt D. Zeilenga" Subject: draft-mmeredith-rootdse-vendor-info-01.txt Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"W590QC.A.9ZC.oTEp4"@glacier> 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:46 AM 2/9/00 -0700, Mark Meredith wrote: >The use of vendorName and vendorVersion SHOULD NOT be used to >discover features. It is just an informational attribute. Mark, I believe you should clarify the intented use of these attributes. I recommend you state your intent in your abstract, or add a "Background and Intended Use" section. Then rework rest of document to be consistent with this intent. In particular, you state that may be used discover X- features in the overview. And in the security section: The vendorName and vendorVersion attributes are provided only as an aid to help client implementers assess what features may or may not exist in a given server implementation. This in inconsistent with Section 6. If this section is consistent with your intent, I suggest the following wording be added someone early on in the document: Attributes defined by this specification are intended for informational purposes only and SHOULD NOT be used for feature discovery. You also note that you intend that these attributes be used to allow clients to workaround implementation bugs based upon vendor specific information. Though I believe it quite appropriate to encourage clients to be "liberal in what they accept", I believe we must be very careful not to encourage one peer to violate the specification because they assume the other has. We must be very careful in the wording which allows any non-informational use of these attributes. Kurt From list@netscape.com Fri Feb 11 14:56:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18359 for ; Fri, 11 Feb 2000 14:56:02 -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 LAA01657; Fri, 11 Feb 2000 11:51:18 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA28622; Fri, 11 Feb 2000 11:54:35 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 11:54:35 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 11 Feb 2000 12:54:03 -0700 From: "Mark Meredith" To: Cc: Subject: Re: draft-mmeredith-rootdse-vendor-info-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"5nrZfC.A.6-G.6jGp4"@glacier> 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 OAA18359 Kurt, I am taking all of the responses and rewriting alot of the draft, I will try to get a new revision out today or Monday. Thanks to all of you for your input. -Mark >>> "Kurt D. Zeilenga" 02/11/00 10:20AM >>> At 10:46 AM 2/9/00 -0700, Mark Meredith wrote: >The use of vendorName and vendorVersion SHOULD NOT be used to >discover features. It is just an informational attribute. Mark, I believe you should clarify the intented use of these attributes. I recommend you state your intent in your abstract, or add a "Background and Intended Use" section. Then rework rest of document to be consistent with this intent. In particular, you state that may be used discover X- features in the overview. And in the security section: The vendorName and vendorVersion attributes are provided only as an aid to help client implementers assess what features may or may not exist in a given server implementation. This in inconsistent with Section 6. If this section is consistent with your intent, I suggest the following wording be added someone early on in the document: Attributes defined by this specification are intended for informational purposes only and SHOULD NOT be used for feature discovery. You also note that you intend that these attributes be used to allow clients to workaround implementation bugs based upon vendor specific information. Though I believe it quite appropriate to encourage clients to be "liberal in what they accept", I believe we must be very careful not to encourage one peer to violate the specification because they assume the other has. We must be very careful in the wording which allows any non-informational use of these attributes. Kurt From list@netscape.com Fri Feb 11 18:29:25 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26028 for ; Fri, 11 Feb 2000 18:29: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 PAA16970; Fri, 11 Feb 2000 15:26:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA26300; Fri, 11 Feb 2000 15:28:10 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 15:28:10 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 11 Feb 2000 16:27:38 -0700 From: "Mark Meredith" To: "<" Cc: "<" Subject: Please publish draft-mmeredith-rootdse-vendor-info-02.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_80D911EE.8EEFD8E6" Resent-Message-ID: <"RfuJiB.A.gaG.JsJp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_80D911EE.8EEFD8E6 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish - this refelcts the changes via feedback on draft-mmeredith-= rootdse-vendor-info-01.txt Please review this draft and submit comments. -Mark Mark Meredith Novell Inc 122 E. 1700 S. Provo UT 84606 mark_meredith@novell.com 801-861-2645 --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- --=_80D911EE.8EEFD8E6 Content-Type: text/plain Content-Disposition: attachment; filename="draft-mmeredith-rootdse-vendor-info-02.txt" Individual Submission to the LDAPExt Working Group Mark Meredith Internet Draft Novell Inc. Document: draft-mmeredith-rootdse-vendor-info-02.txt February 11, 2000 Category: Proposed Standard Storing Vendor Information in the LDAP root DSE 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 made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list ietf-ldapext@netscape.com or the author. 1. Abstract This document specifies two LDAP attributes, vendorName and vendorVersion that MAY be included in the root DSE to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of [RFC-2251]. The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2219] 3. Overview LDAP clients discover server-specific data--such as available controls, extensions, etc.-- by reading the root DSE. See section 3.4 of [RFC-2251] for details. M. Meredith Expires June-2000 1 LDAP root DSE to display vendor information December 1999 For display, information, and limited function discovery, it is desirable to be able to query an LDAP server to determine the vendor name of that server and also to see what version of that vendor's code is currently installed. 3.1 Function discovery There are many ways in which a particular version of a vendor's LDAP server implementation may be functionally incomplete, or may contain software anomalies. It is impossible to identify every known shortcoming of an LDAP server with the given set of server data advertisement attributes. Furthermore, often times, the anomalies of an implementation are not found until after the implementation has been distributed, deployed, and is in use. The attributes defined in this document MAY be used by client implementations in order to identify a particular server implementation so that it can 'work around' such anomalies. The attributes defined in this document MUST NOT be used to gather information related to supported features of an LDAP implementation. All LDAP features, mechanisms, and capabilities--if advertised--MUST be advertised through other mechanisms, preferably advertisement mechanisms defined in concert with said features, mechanisms, and capabilities. 4. Attribute Types These attributes are an addition to the Server-specific Data Requirements defined in section 3.4 of [RFC-2251]. The associated syntaxes are defined in section 4 of [RFC-2252]. Servers MAY restrict access to vendorName or vendorVersion and clients MUST NOT expect these attributes to be available. 4.1 vendorName This attribute contains a single string, which represents the name of the LDAP server implementer. All LDAP server implementations SHOULD maintain a vendorName, which is generally the name of the company that wrote the LDAP Server code like "Novell, Inc." ( 2.16.840.1.113719.1.27.4.43 NAME 'vendorName' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE USAGE dSAOperation ) 4.2 vendorVersion This attribute contains a string which represents the version of the LDAP server implementation. M. Meredith Expires June-2000 2 LDAP root DSE to display vendor information December 1999 All LDAP server implementations SHOULD maintain a vendorVersion. Note that this value is typically a release value--comprised of a string and/or a string of numbers--used by the developer of the LDAP server product (as opposed to the supportedLDAPVersion, which specifies the version of the LDAP protocol supported by this server). This is single-valued so that it will only have one version value. ( 2.16.840.1.113719.1.27.4.44 NAME 'vendorVersion' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION SINGLE-VALUE USAGE dSAOperation ) 5. Notes to Server Implementers Server implementers may consider tying the vendorVersion attribute value to the build mechanism so that it is automatically updated when the version value changes. 6. Notes to Client Developers As mentioned in section 3.1, the use of vendorName and vendorVersion MUST NOT be used to discover features. Client implementations SHOULD be written in such a way as to accept any value in the vendorName and vendorVersion attributes. If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct. The client SHOULD work with implementations that do not publish these attributes. 7. Security Considerations The vendorName and vendorVersion attributes are provided only as display or informational mechanisms, or as anomaly identifying mechanisms. Client and application implementers must consider that the existence of a given value in the vendorName or vendorVersion attribute is no guarantee that the server was actually built by the asserted vendor or that its version is the asserted version and should act accordingly. Server implementers should be aware that this information could be used to exploit a security hole a server provides either by feature or flaw. 8. References RFC-2219 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 RFC-2026 M. Meredith Expires June-2000 3 LDAP root DSE to display vendor information December 1999 Bradner, S., "The Internet Standards Process—Revision 3", BCP 9, RFC 2026, October 1996. RFC-2251 Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997 RFC-2252 Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997 9. Acknowledgments The author would like to thank the generous input and review by individuals at Novell including but not limited to Jim Sermersheim, Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong, Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers. 10. Author's Addresses Mark Meredith Novell Inc. 122 E. 1700 S. Provo, UT 84606 Phone: 801-861-2645 Email: mark_meredith@novell.com Full Copyright Statement Copyright (c) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. M. Meredith Expires June-2000 4 --=_80D911EE.8EEFD8E6-- From list@netscape.com Fri Feb 11 19:24: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 TAA27166 for ; Fri, 11 Feb 2000 19:24: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 QAA05525; Fri, 11 Feb 2000 16:20:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA16917; Fri, 11 Feb 2000 16:23:37 -0800 (PST) Resent-Date: Fri, 11 Feb 2000 16:23:37 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 11 Feb 2000 17:23:24 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: LDAP subtree search with zero-length DN for baseObject? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"lKohv.A.DIE.HgKp4"@glacier> 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 TAA27166 Yes. An NDS directory always has a naming context rooted at the root of the tree. Any NDS server either holds this root NC or it has a superior reference. If the server holds the root NC, it will begin the search at the root, returning referrals as needed. If the server does not hold the root NC, it will return a referral. (this is a better and more accurate description of what NDS does than what I said earlier) Jim >>> "RL 'Bob' Morgan" 2/10/00 4:33:11 PM >>> On Thu, 10 Feb 2000, Jim Sermersheim wrote: > Our server follows the "search all the naming contexts you have > locally" model which I think is reasonable. So, in the terms Mark and Kurt use, a Novell directory always acts like a top-level or global-root server? - RL "Bob" From list@netscape.com Sat Feb 12 08:58:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22367 for ; Sat, 12 Feb 2000 08:58:50 -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 FAA00901; Sat, 12 Feb 2000 05:55:45 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA21736; Sat, 12 Feb 2000 05:57:32 -0800 (PST) Resent-Date: Sat, 12 Feb 2000 05:57:32 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Date: Sat, 12 Feb 2000 13:57:15 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: <3.0.5.32.20000211085848.009b4dd0@infidel.boolean.net> References: <38A4158C.102DDB73@netscape.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"Scj4XD.A.WTF.LbWp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > >I'd really prefer we choose the simple solution to this problem: > >change the subschemasubentry attribute to multivalued, but stipulate > >that it can only have one value when it appears outside the rootDSE. > > Sounds simple... but one cannot generally redefine an attribute > type, one must introduce a replacement attribute type. > I agree with Kurt on this. > >Does that solve the problem at hand? > > No, because the client doesn't which subset of entries may > be controlled by a given value. Additional information > is needed, such as a DN indicing the subtree of applicability, > to make the information generally useful. > This is true if the subentries can be held anywhere. The alternative is to have a defined set of positions for them (as X.500 and LDUP have done). In the latter case, pointers are not essential (but may be an aid to efficiency). > > >But as far as I know LDAPv3 doesn't require that servers support > >administrative domains at all. Some servers do, some do not. Also, Administrative domains always exist. (Someone has to administer the DIT subtrees). So a product that supports this element of reality is better than one that does not > >what if the naming contexts are disjoint yet all share the same > >schema? That is a very common situation today. > > I agree this is common and the information model should support > sharing of subschema across multiple naming contexts. I suggest we > don't adopt a means which "hardcodes" the name and/or location of > subschema subentries so as to maintain the greatest amount of > flexibility possible. > > This is arguing for pointers rather than fixed positions. Basically you pays your money and takes your choice. I dont have a strong preference for either. But once the decision is made then the model has to be made to fully support it. We are currently in the position where the model does not fully support fixed positions or pointers, without some modification to it. And it is quite complex given the multiple combinations you can have of administrative domains and naming contexts. David David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sat Feb 12 08:58: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 IAA22377 for ; Sat, 12 Feb 2000 08:58: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 FAA01109; Sat, 12 Feb 2000 05:56:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA22068; Sat, 12 Feb 2000 05:57:51 -0800 (PST) Resent-Date: Sat, 12 Feb 2000 05:57:51 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com, Mark Wahl , Gil Kirkpatrick Date: Sat, 12 Feb 2000 13:57:14 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: RFC2251: RootDSE subschemasubentry issue Reply-to: d.w.chadwick@salford.ac.uk Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"12XYQ.A.NYF.ebWp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Thu, 10 Feb 2000 18:36:03 -0800 (PST) From: Gil Kirkpatrick To: "'d.w.chadwick@salford.ac.uk'" , "Kurt D. Zeilenga" , ietf-ldapext@netscape.com, Mark Wahl Subject: RE: RFC2251: RootDSE subschemasubentry issue Date sent: Thu, 10 Feb 2000 19:33:06 -0700 Forwarded by: ietf-ldapext@netscape.com > David, > > Why does the rootDSE need to contain subschemaSubentrys for each NC > hosted by the server? Why is not sufficient to maintain the > subschemaSubentrys in the NCs themselves? > The original reason (if I remember correctly) was because the subschema subentries could be held anywhere in the DIT by an LDAP server, and not necessarily within the NCs. Thus pointers to them were needed, and the rootDSE was the obvious place to put a pointer that everyone would know how to get at. It was the LDUP group that first defined subentries beneath the NC context prefix, and this came way after the LDAP RFCs were published. I dont know if this has yet been widely accepted as a way of stroring subschema entries or not. If not, then pointers are still needed to the entries, where ever they may be in the NC. David > -gil > > Gil Kirkpatrick > Director of Engineering > Netpro > > > > -----Original Message----- > > From: David Chadwick [SMTP:d.w.chadwick@salford.ac.uk] > > Sent: Wednesday, February 09, 2000 12:27 PM > > To: Kurt D. Zeilenga; ietf-ldapext@netscape.com; Mark Wahl > > Subject: Re: RFC2251: RootDSE subschemasubentry issue > > > > Mark, Kurt > > > > I think I have an answer to the problem(s) being posed by Kurt. > > > > The model as it stands is OK if a server only masters one naming > > context. Everything works fine. All the entries in the NC and the > > rootDSE can contain the subschemaSubentry attribute which points to > > the single subschema subentry. > > > > The problem arises once we have multiple NCs in a server. The > > subschemaSubentry attribute can still be single valued and exist in > > each entry in each NC and point to the correct subschema subentry. > > However, the attribute in the root DSE no longer works, for two > > reasons. > > > > Firstly it is supposed to be single valued (as Kurt pointed out) and > > now it needs to have multiple values. > > > > Secondly, (again as Kurt pointed out) there is no way for the user > > to know from the multivalued attribute in the rootDSE which value > > points to which subschema subentry for which NC. THis of course is > > not a problem for the entries within the NC, as they only still need > > a single pointer to their one and only subschema subentry. > > > > Thus I conclude that the model is broken for multiple naming > > contexts, and that the subschemaSubentry attribute in the rootDSE > > needs to be replaced by a multivalued attribute, having two > > components - the context prefix of an NC (an LDAP DN), and the > > pointer to the subschemaSubentry. > > > > Do you agree with this analysis? > > > > David > > > > *************************************************** > > > > David Chadwick > > IS Institute, University of Salford, Salford M5 4WT > > Tel +44 161 295 5351 Fax +44 161 745 8169 > > Mobile +44 790 167 0359 > > Email D.W.Chadwick@salford.ac.uk > > Home Page http://www.salford.ac.uk/its024/chadwick.htm > > Understanding X.500 http://www.salford.ac.uk/its024/X500.htm > > X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm > > Entrust key validation string MLJ9-DU5T-HV8J > > > > *************************************************** > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Sun Feb 13 08:42: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 IAA09393 for ; Sun, 13 Feb 2000 08:42: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 FAA17067; Sun, 13 Feb 2000 05:38:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA08041; Sun, 13 Feb 2000 05:40:24 -0800 (PST) Resent-Date: Sun, 13 Feb 2000 05:40:24 -0800 (PST) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer david.siemens.de) Message-ID: <38A6B370.EADDB9CC@icn.siemens.de> Date: Sun, 13 Feb 2000 14:36:48 +0100 From: Helmut Volpers Organization: Siemens X-Mailer: Mozilla 4.6 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 To: "RL 'Bob' Morgan" CC: IETF ldapext WG Subject: Re: LDAP subtree search with zero-length DN for baseObject? References: Content-Type: multipart/mixed; boundary="------------F6BA5C4DFDF4CA69BE4275F1" Resent-Message-ID: <"toq0cB.A.X9B.FRrp4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Dies ist eine mehrteilige Nachricht im MIME-Format. --------------F6BA5C4DFDF4CA69BE4275F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have seen a lot of simple clients which doesn't read the root to get information about the server. They make a subtree search with root as base object and they can live with a result which doesn't include the root but all the local entries in the server which match the filter. So for a standalone server you can configure ROOT as CP in our DSA and you can use root as base in every search. The root is only returned in a base-level search (read). In all the other cases we use the modell that the name resolution is finished and "search all the naming contexts you have locally" plus referralls to all the references the server holds. Can all your LDAP enabled applications can work with "noSuchObject" for a search with ROOT as BaseObject ? Helmut RL 'Bob' Morgan schrieb: > > RFC 2251 says, in section 3.4: > > An LDAP server MUST provide information about itself and other > information that is specific to each server. This is represented as > a group of attributes located in the root DSE (DSA-Specific Entry), > which is named with the zero-length LDAPDN. These attributes are > retrievable if a client performs a base object search of the root > with filter "(objectClass=*)", however they are subject to access > control restrictions. The root DSE MUST NOT be included if the > client performs a subtree search starting from the root. > > It isn't clear to me, though, what the expected result should be from a > subtree search where the baseObject is the zero-length DN. It mustn't > include the root DSE info, but what should it include? Should this mean > "the subtree rooted at root of the global DIT"? Presumably, if so, in > existing cases this would typically fail since the DSA doesn't know how to > contact a DSA for "the root". Or can a DSA interpret it as "search all > the naming contexts you have locally?" By experiment I find that servers > I've tried this on report "no such object". > > Thanks, > > - RL "Bob" --------------F6BA5C4DFDF4CA69BE4275F1 Content-Type: text/x-vcard; charset=us-ascii; name="helmut.volpers.vcf" Content-Description: Visitenkarte für Helmut Volpers Content-Disposition: attachment; filename="helmut.volpers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Volpers;Helmut tel;fax:+49-89-636-45860 tel;work:+49-89-636-46713 x-mozilla-html:FALSE url:http://www.siemens.com/bus-com org:Siemens AG adr:;;;Munich;;81730;Germany version:2.1 email;internet:Helmut.Volpers@icn.siemens.de title:Directory Server Architect fn:Helmut Volpers end:vcard --------------F6BA5C4DFDF4CA69BE4275F1-- From list@netscape.com Sun Feb 13 20:08: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 UAA14975 for ; Sun, 13 Feb 2000 20:08: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 RAA10877; Sun, 13 Feb 2000 17:05:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA02965; Sun, 13 Feb 2000 17:07:35 -0800 (PST) Resent-Date: Sun, 13 Feb 2000 17:07:35 -0800 (PST) From: s.scott5349@belgium.com Date: Sun, 13 Feb 2000 17:07:30 -0800 (PST) Message-Id: <200002140107.RAA13467@xwing.netscape.com> To: any5one@gte.net Subject: No Suit No Commute! Wk from Home! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"zEPTOC.A.2t.WV1p4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com LOOKING FOR GEMS! It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income! Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme? If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need. Call NOW our TOLL FREE, PRE-RECORDED Message: 1-800-320-9895 ext. 2375 We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you. You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now! The call is FREE, and there is absolutely no obligation, So what have you got to lose? Call Toll Free 1-800-320-9895 ext. 2375 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 reply to this email with remove in the subject. Thank you! From list@netscape.com Mon Feb 14 10:19:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14177 for ; Mon, 14 Feb 2000 10:19: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 HAA08153; Mon, 14 Feb 2000 07:14:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA28805; Mon, 14 Feb 2000 07:18:27 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 07:18:27 -0800 (PST) Message-ID: <604BBD28BC0AD311AE760008C7B2721D2E5797@exchange03.jhancock.com> From: "Buonora, Peter" To: "'ietf-ldapext@netscape.com'" Subject: FW: LDAP in a 24x7 NAS environment? Date: Mon, 14 Feb 2000 10:18:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: <"EEZgtC.A.xBH.9yBq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hello, Here at John Hancock we are in the process of moving to the new version of NAS which requires LDAP registry. There is no clear way to make this architecture work in a 24x7 environment since NAS requires reads and writes while Netscape Directory 4.x server does not support Multi-Mastering. I know that someone else must have faced these issues already and any help at all would be greatly appreciated. (We would prefer to avoid HA failover type solutions) We do have a platinum support contract, but Tech support has not been a great help as of yet.. Thanks, Peter Buonora Web Infrastructure Architect John Hancock 617-572-5130 From list@netscape.com Mon Feb 14 11:43: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 LAA16676 for ; Mon, 14 Feb 2000 11:43:04 -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 IAA05484; Mon, 14 Feb 2000 08:39:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA23870; Mon, 14 Feb 2000 08:41:37 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 08:41:37 -0800 (PST) Message-Id: <3.0.5.32.20000214084123.0096f7e0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 14 Feb 2000 08:41:23 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: RFC2251: unbind Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"v5tf8B.A.s0F.BBDq4"@glacier> 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 seems that some folks are confused about the function of unbind. We've likely have all heard the "don't I need to unbind before rebinding" enquiry. Some have even noted that the disconnection requirements are MAY, not MUSTs. Some have any stated that some servers do not terminate the connection upon receipt of an unbind request. It seems that some implementors don't take "The function of the Unbind Operation is to terminate a protocol session" as an absolute. I would suggest that the paragraph following this sentence for clarification: A client SHALL NOT submit further requests after sending an unbind request. A client SHOULD terminate the underlying TCP session after making the unbind request. A server SHALL NOT process nor respond to further requests received after an unbind requests. A server SHOULD terminate the underlying TCP session after receiving the unbind request. From list@netscape.com Mon Feb 14 11:52: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 LAA17067 for ; Mon, 14 Feb 2000 11:52: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 IAA19172; Mon, 14 Feb 2000 08:47:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA00549; Mon, 14 Feb 2000 08:51:37 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 08:51:37 -0800 (PST) Message-ID: <38A832D2.6857F054@netscape.com> Date: Mon, 14 Feb 2000 08:52:35 -0800 From: dboreham@netscape.com (David Boreham) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: RFC2251: unbind References: <3.0.5.32.20000214084123.0096f7e0@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"rmMPD.A.TI.YKDq4"@glacier> 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 FWIW the Netscape/iPlanet server closes the connection immediately it sees an unbind. The Netscape SDK also closes the connection immediately after sending the unbind PDU. This, of course, leads to many interesting race conditions in the server code, but I think it complies with your clarified requirements. "Kurt D. Zeilenga" wrote: > It seems that some folks are confused about the function of > unbind. We've likely have all heard the "don't I need to unbind > before rebinding" enquiry. Some have even noted that the > disconnection requirements are MAY, not MUSTs. Some have any > stated that some servers do not terminate the connection upon > receipt of an unbind request. > > It seems that some implementors don't take "The function of the > Unbind Operation is to terminate a protocol session" as an absolute. > > I would suggest that the paragraph following this sentence > for clarification: > A client SHALL NOT submit further requests after > sending an unbind request. A client SHOULD terminate > the underlying TCP session after making the unbind > request. > A server SHALL NOT process nor respond to further > requests received after an unbind requests. A > server SHOULD terminate the underlying TCP session > after receiving the unbind request. > > From list@netscape.com Mon Feb 14 16:50:15 2000 Received: 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 QAA24692 for ; Mon, 14 Feb 2000 16:50:09 -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 NAA29376; Mon, 14 Feb 2000 13:46:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA27814; Mon, 14 Feb 2000 13:48:33 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 13:48:33 -0800 (PST) Message-Id: <3.0.5.32.20000214134825.0092dcd0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 14 Feb 2000 13:48:25 -0800 To: mark_meredith@novell.com From: "Kurt D. Zeilenga" Subject: Vendor Info Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"-k1_5.A._xG.wgHq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Mark, Section 4. What is the intent of this statement: These attributes are an addition to the Server-specific Data Requirements defined in section 3.4 of [RFC-2251]. Do you mean to imply that servers MUST provide these values? You later say SHOULD maintain these attributes types. As noted previously, I believe the publication of these attributes should be elective. That is, a server MAY provide these attributes. Section 5. If a server supports these attribute types, the values should be overwritable by configuration. This allows a server to "spoof" clients to obtain desired behavior. Section 6. A client must not assume that all servers advertising a particular version string behave in a like manner. The apparent flaw may only be exhibited in a subset of the servers advertising a particular version. This may be due to any number of environmental factors. Clients should not attempt fuzzy matching. They must only enable workarounds when the server presents a vendor strings known to evident of specific flaws. They must assume that all unknown vendor strings behavior per standard track specifications. Kurt From list@netscape.com Mon Feb 14 17:21:06 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25396 for ; Mon, 14 Feb 2000 17:21: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 OAA09122; Mon, 14 Feb 2000 14:16:21 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA13082; Mon, 14 Feb 2000 14:19:59 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 14:19:59 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Date: Mon, 14 Feb 2000 17:19:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ehQ3tB.A.IMD.O-Hq4"@glacier> 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 just noticed that the EQUALITY matching rule for these attributes in caseExactIA5Match, but the syntaxes are now DirectoryString. This led me back to RFC2252 which includes the definition for caseIgnoreMatch (borrowed from X.520), but not caseExactMatch. What happened to: ( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) And now that I've started down this path, what about: caseExactOrderingMatch, caseExactSubstringsMatch, numericStringOrderingMatch, telephoneNumberOrderingMatch, and a whole lot more that X.520 defines? Are these assumed to be inherited from X.520, but not included in the "Servers SHOULD be capable ... " clause? Or is this the complete list that other RFCs may reference? To get back to the subject, can vendor info draft include "EQUALITY 2.5.13.5" in the attribute definitions, or must it also define caseExactMatch. From list@netscape.com Mon Feb 14 17:42:06 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25756 for ; Mon, 14 Feb 2000 17:42: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 OAA12728; Mon, 14 Feb 2000 14:37:13 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA23095; Mon, 14 Feb 2000 14:40:51 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 14:40:51 -0800 (PST) Message-Id: <3.0.5.32.20000214144047.0094c830@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 14 Feb 2000 14:40:47 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: RFC2251: unbind In-Reply-To: <3.0.5.32.20000214084123.0096f7e0@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"ZS3uhC.A.joF.yRIq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:41 AM 2/14/00 -0800, Kurt D. Zeilenga wrote: >It seems that some folks are confused about the function of >unbind. We've likely have all heard the "don't I need to unbind >before rebinding" enquiry. Some have even noted that the >disconnection requirements are MAY, not MUSTs. Some have any >stated that some servers do not terminate the connection upon >receipt of an unbind request. > >It seems that some implementors don't take "The function of the >Unbind Operation is to terminate a protocol session" as an absolute. > >I would suggest that the paragraph following this sentence >for clarification: > A client SHALL NOT submit further requests after > sending an unbind request. A client SHOULD terminate > the underlying TCP session after making the unbind > request. > A server SHALL NOT process nor respond to further > requests received after an unbind requests. A > server SHOULD terminate the underlying TCP session > after receiving the unbind request. Note that the existing paragraph allows the client to wait for the server to initiate the TCP shutdown AND allows the server to wait for the client to initiate the TCP shutdown. There really should be at least one SHALL detailing who must shutdown the connection and when. I revise my suggestion: The client SHALL terminate the underlying connection after submitting an unbind request. The server SHALL terminate the underlying connection upon receipt of an unbind request. Comments? From list@netscape.com Mon Feb 14 18:45:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26557 for ; Mon, 14 Feb 2000 18:45:50 -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 PAA18340; Mon, 14 Feb 2000 15:42:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA20645; Mon, 14 Feb 2000 15:44:45 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 15:44:45 -0800 (PST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: moore@cs.utk.edu Resent-Message-ID: <"MufV9B.A.NCF.rNJq4"@glacier> 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 has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore From list@netscape.com Mon Feb 14 20:56:34 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29566 for ; Mon, 14 Feb 2000 20:56:34 -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 RAA08977; Mon, 14 Feb 2000 17:53:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA13714; Mon, 14 Feb 2000 17:55:22 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 17:55:22 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 14 Feb 2000 18:54:56 -0700 From: "Jim Sermersheim" To: , Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"v-GE_B.A.AWD.JILq4"@glacier> 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 UAA29566 I think Mark's intention was to change the EQUALITY matching rule to caseIgnoreMatch when he changed the syntax but it slipped by. OTOH, if he *did* want caseExactMatch, I think it would be confusing to reference it without it being formally defined somewhere (in LDAP land). I also think it would be a little funky to define it in this document. It seems like it should be grouped with the others you mention in some other place. Jim >>> "Salter, Thomas A" 2/14/00 3:20:21 PM >>> I just noticed that the EQUALITY matching rule for these attributes in caseExactIA5Match, but the syntaxes are now DirectoryString. This led me back to RFC2252 which includes the definition for caseIgnoreMatch (borrowed from X.520), but not caseExactMatch. What happened to: ( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) And now that I've started down this path, what about: caseExactOrderingMatch, caseExactSubstringsMatch, numericStringOrderingMatch, telephoneNumberOrderingMatch, and a whole lot more that X.520 defines? Are these assumed to be inherited from X.520, but not included in the "Servers SHOULD be capable ... " clause? Or is this the complete list that other RFCs may reference? To get back to the subject, can vendor info draft include "EQUALITY 2.5.13.5" in the attribute definitions, or must it also define caseExactMatch. From list@netscape.com Mon Feb 14 21:13: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 VAA00228 for ; Mon, 14 Feb 2000 21:13: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 SAA11543; Mon, 14 Feb 2000 18:10:55 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA20180; Mon, 14 Feb 2000 18:12:46 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 18:12:46 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 14 Feb 2000 19:12:29 -0700 From: "Jim Sermersheim" To: "Mark Meredith" , Cc: Subject: Re: Vendor Info Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"pZrbtC.A.C7E.dYLq4"@glacier> 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 VAA00228 >>> "Kurt D. Zeilenga" 2/14/00 2:48:50 PM >>> >What is the intent of this statement: > These attributes are an addition to the Server-specific Data > Requirements defined in section 3.4 of [RFC-2251]. > >Do you mean to imply that servers MUST provide these values? You >later say SHOULD maintain these attributes types. As noted previously, >I believe the publication of these attributes should be elective. >That is, a server MAY provide these attributes. I think the intention was to simply point out that these are attributes in the root DSE, much like those found in section 3.4 of RFC 2251. I don't think there's any implication that these are mandatory. >Section 5. > >If a server supports these attribute types, the values should >be overwritable by configuration. This allows a server to >"spoof" clients to obtain desired behavior. Are you requesting that this wording be added to the draft? If so, why? Perhaps your should should've been a shouldn't? >Section 6. > >A client must not assume that all servers advertising a particular >version string behave in a like manner. The apparent flaw may >only be exhibited in a subset of the servers advertising a >particular version. This may be due to any number of environmental >factors. Good point. >Clients should not attempt fuzzy matching. They must only >enable workarounds when the server presents a vendor strings >known to evident of specific flaws. While this may be good advise, I don't see it as a requirement. If a client writer knows that versions 5.0 thru 5.x all exhibited a certain bug, and it was fixed in 6.0, it's reasonable for them to assume that a version substring of 5. will exhibit the bug. > They must assume that all >unknown vendor strings behavior per standard track specifications. Are you requesting that this wording be included in addition to, or in lieu of: "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct."? Jim From list@netscape.com Mon Feb 14 22:04:36 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02401 for ; Mon, 14 Feb 2000 22:04:36 -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 SAA13687; Mon, 14 Feb 2000 18:59:46 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id TAA04125; Mon, 14 Feb 2000 19:03:26 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 19:03:26 -0800 (PST) Message-Id: <3.0.5.32.20000214190315.00953100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 14 Feb 2000 19:03:15 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Vendor Info Cc: "Mark Meredith" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"bpIiW.A.LAB.9HMq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:12 PM 2/14/00 -0700, Jim Sermersheim wrote: >>Section 5. >> >>If a server supports these attribute types, the values should >>be overwritable by configuration. This allows a server to >>"spoof" clients to obtain desired behavior. > >Are you requesting that this wording be added to the draft? If so, why? Perhaps your should should've been a shouldn't? I suggest using wording similiar to that found in the RFC 2616 (HTTP 1.1): Server implementors are encouraged to make the values of these attributes configurable options. Note, they encourage suggest for security reasons. Though quite valid, I suggest it primarily for interoperability. I've already seen folks hack OpenLDAP to spoof other servers so that they could use some client which inappropriately depended provided vendor information. [In believe the vendor ended up hacking their own server to spoof the old version so that their client would work]. >>Clients should not attempt fuzzy matching. They must only >>enable workarounds when the server presents a vendor strings >>known to evident of specific flaws. > >While this may be good advise, I don't see it as a requirement. If a client writer knows that versions 5.0 thru 5.x all exhibited a certain bug, and it was fixed in 6.0, it's reasonable for them to assume that a version substring of 5. will exhibit the bug. No, because the vendor may, even after producing 6.0, produce a 5.y which fixes the behavior. This sometimes occurs because a large customer of the vendor specifically requests a patch for the older version and the vendor complies. It is not uncommon for a vendor to support and revise multiple versions for significant time. >> They must assume that all >>unknown vendor strings behavior per standard track specifications. > >Are you requesting that this wording be included in addition to, or in lieu of: "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct."? I would prefer to clarify the term "recognize". From list@netscape.com Tue Feb 15 01:08:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07407 for ; Tue, 15 Feb 2000 01:08: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 WAA27946; Mon, 14 Feb 2000 22:05:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA10789; Mon, 14 Feb 2000 22:06:50 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 22:06:50 -0800 (PST) Message-Id: <3.0.5.32.20000214215708.00936dc0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 14 Feb 2000 21:57:08 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: ACL model comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"4A4F7B.A.ToC.5zOq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Though I haven't had time to do a full review, I can offer a few comments: Section 6.3 The 'aci' attribute is defined as a user, not operational, attribute type. Besides being appropriate in terms of usage, this would allow this attribute type in any and all object classes. If usage is left as user, you'd likely have to define an auxiliary objectclass to allow mix in or replace 'top' or something. The EQUALITY matching rule should be specific to the ACI Syntax and able to determine that that two strings, not equal by caseExactMatch, yet same per the ACI syntax. For example: aci: 1.2.3.4#subtree#grant;r;cn#group#cn=Dept XYZ aci: 1.2.3.5#subtree#grant;r;2.5.4.3#group#cn=Dept XYZ (cn == 2.5.4.3) Section 6.3.1 LDAP Operations (Modify/delete) Deleting the last ACI value from an entry is not the same as deleting the ACI from the entry. This seems to imply behavior inconsistent with RFC 2251, 4.6. It is possible for an entry to contain an ACI with no values. An attribute type, if instatiated, must have values. Though you state not storage means, I believe it important to follow the basic LDAP information model to ensure the information is representatable by the protocol and interchange formats. Section 6.4.2 Replace works similarly to all other attributes. This implies that other modifications do not work similiarly to all other attributes. I believe that all modifications should be consistent with the defined semantics of Modify operation. 6.5 VendorACI Like 'aci', it should be operational. Also, it should have a matching rule defined which understands how to match strings of vendor ACI syntax. Defining this seems problematic, but could be be defined, I guess, in generic terms. Howeer, if the directory contains vendorACIs from multiple vendors, you have a problem. But these problems exist even as presently defined. I suggest not defining this and just stating that vendors can define their own attribute types to contain Access Control Information. They'll like do this anyways. From list@netscape.com Tue Feb 15 01:11: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 BAA07725 for ; Tue, 15 Feb 2000 01:11:29 -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 WAA24396; Mon, 14 Feb 2000 22:06:40 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA12017; Mon, 14 Feb 2000 22:10:20 -0800 (PST) Resent-Date: Mon, 14 Feb 2000 22:10:20 -0800 (PST) From: jobs@agnet.com.au To: jobs@agnet.com.au Subject: HOT OPENINGS IN AUSTIN, TEXAS!!! Date: Mon, 14 Feb 2000 21:19:12 +0100 Message-ID: <20000214201416598.AAH148.247@ip5.margate.fl.pub-ip.PSI.NET> Resent-Message-ID: <"1gEtJB.A.f7C.L3Oq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com ************************************* ************************************* HOT JOB OPENINGS IN AUSTIN, TEXAS ************************************* ************************************* Exciting opportunities have just opened up in Austin, Texas. If you are thinking of making a career change or know of anyone else who might be interested, please forward these excellent opportunities to them. _________________________________________________________ Web Developers are needed with strong knowledge of HTML, JAVAscript, Perl, CGI methodology, Unix, and Sun Solaris. Salaries up to $90,000 No contractors accepted on this position. ************************************* _________________________________________________________ Several JAVA Programmers also needed to develop & deploy a web-based integrated work flow management & sales tool for mid range products. Salaries up to $90,000. Contractors will be paid $48.00 per hour. ************************************* _________________________________________________________ Sr. JAVA Developer needed to work on fast growing web enabled private line networking products. Will work as part of a highly skilled team. JAVA plus solid development methodology, Enterprise JAVA Beans (EJB), and BEA's Web Logic EJB Server needed. Salaries up to $90,000 or $48.00 per hour. ************************************* _________________________________________________________ C++/JAVA Programmers needed to work on 8-10 member team within a Linux environment. Expert knowledge of Linux/Unix/AIX needed. Salaries up to $68,000. Contractors paid up to $38.00 per hour. ************************************* _________________________________________________________ AIX Support Delivery Technical Specialists needed. Shell scripting/programming in an AIX/UNIX environment (Perl or C) needed. _________________________________________________________ OS/2 Technical Support. Must be able to travel to client sites when needed. Must also have some OS/2 LAN Manager. Salaries up to $78,338. Contractors will be paid $45.00 per hour. ************************************* _________________________________________________________ Instructional Designer/Developer needed to design and help with course development. Will develop and coordinate training and develop course material on the company's products and sales. Any experience with JAVA, JAVA Beans will be a plus. This is a contractor postion only and will pay up to $30.00 per hour. ************************************* _________________________________________________________ Visual C++ Developers needed as part of a development team for a telecommunications company. Will perform all phases of the development life cycle. Must have Visual C++, MFC, Object Oriented Design and SQL. Salaries up to $50,000 or $26.00 per hour. ************************************* _________________________________________________________ Software Test Engineers needed to help design, develop, code and execute functional test plans. Salaries are open. _________________________________________________________ Disk Drive Engineer needed to provide world wide product engineering support for a variety of disk drivers on the RS/6000. Salary up to $50,000 or $30.00 per hour. ************************************* _________________________________________________________ Device Driver Developers needed to perform new development and technical Level 2.5/3.0 support of the AIX operating system. Salary up to $73,000 or $40.00 per hour. ************************************* _________________________________________________________ AIX Kernel Developers to perform support and serviceability using AIX, Virtual Memory Manager, Unix Configuration, Unix Security, Printer Device Drivers. Will pay up to $68,000 or $38.00 per hour. ************************************* AIX Performance Testers also needed. _________________________________________________________ SQL Server DBA's needed for three projects. Salaries up to $47,000 or $26.00 per hour. ************************************* _________________________________________________________ DB2 Database Manager needed to develop and manage a database for partner commerce/servers. Will be responsible for database backup and recovery procedures. Will access security and database integrity. Salary up to $93,596 or $51.00 per hour. ************************************* _________________________________________________________ ADABAS DBA needed for a short term contract. Must have ADASMP. Will pay top dollar to find the right person. ************************************* _________________________________________________________ QA Manager needed to Manage Test group. Salary up to $72,000 or $40.00 per hour. ************************************* _________________________________________________________ _________________________________________________________ For detailed information on these and other openings please CONTACT us at our toll free =============================== =============================== DP West Incorporated Professional Recruiting and Services 1-888-664-2388 or 623-374-0030 =============================== =============================== _________________________________________________________ _________________________________________________________ Note: This mail has been directed to computer professionals seeking employment. It is not intended to be spam mail. We have received your reference from fellow business partners. If you do not want to receive this mail in the future please let us know the e-mail ID this message was received at and any aliases and we will take you off our list. We appreciate your patience and regret the inconvenience. From list@netscape.com Tue Feb 15 06:35:29 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22378 for ; Tue, 15 Feb 2000 06:35: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 DAA15812; Tue, 15 Feb 2000 03:32:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA06268; Tue, 15 Feb 2000 03:34:21 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 03:34:21 -0800 (PST) Message-Id: <200002151134.GAA22224@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-zeilenga-ldap-authpasswd-01.txt Date: Tue, 15 Feb 2000 06:34:15 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"OVaUP.A.qhB.8mTq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Authentication Password Attribute Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-authpasswd-01.txt Pages : 8 Date : 14-Feb-00 This document describes schema for storing authentication passwords in a LDAP [RFC2251] directory. The document provides schema definitions for authPassword and related schema definitions. The authPassword is intended to used instead of clear text password storage mechanisms such as userPassword [RFC2256] to support simple bind operations. The attribute may be used to store SASL [RFC2222] authentication passwords in entries of a directory. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authpasswd-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-zeilenga-ldap-authpasswd-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-zeilenga-ldap-authpasswd-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: <20000214115223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-authpasswd-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-authpasswd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000214115223.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Feb 15 09:18:20 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02949 for ; Tue, 15 Feb 2000 09:18: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 GAA25509; Tue, 15 Feb 2000 06:15:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA02139; Tue, 15 Feb 2000 06:17:11 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 06:17:11 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com Subject: RE: RFC2251: unbind Date: Tue, 15 Feb 2000 09:17:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"T6GZFC.A.Jh.m_Vq4"@glacier> 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'd prefer a protocol where only one side could initiate the normal shutdown. In this case the server should do that as a response to the unbind. The client should close in response to server-initiated close. This would eliminate the various race conditions that exist otherwise and make it easier to tell normal conditions from error conditions. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, February 14, 2000 5:41 PM > To: ietf-ldapext@netscape.com > Subject: Re: RFC2251: unbind > > > At 08:41 AM 2/14/00 -0800, Kurt D. Zeilenga wrote: > >It seems that some folks are confused about the function of > >unbind. We've likely have all heard the "don't I need to unbind > >before rebinding" enquiry. Some have even noted that the > >disconnection requirements are MAY, not MUSTs. Some have any > >stated that some servers do not terminate the connection upon > >receipt of an unbind request. > > > >It seems that some implementors don't take "The function of the > >Unbind Operation is to terminate a protocol session" as an absolute. > > > >I would suggest that the paragraph following this sentence > >for clarification: > > A client SHALL NOT submit further requests after > > sending an unbind request. A client SHOULD terminate > > the underlying TCP session after making the unbind > > request. > > A server SHALL NOT process nor respond to further > > requests received after an unbind requests. A > > server SHOULD terminate the underlying TCP session > > after receiving the unbind request. > > Note that the existing paragraph allows the client to wait > for the server to initiate the TCP shutdown AND allows the > server to wait for the client to initiate the TCP shutdown. > There really should be at least one SHALL detailing who > must shutdown the connection and when. > > I revise my suggestion: > The client SHALL terminate the underlying connection > after submitting an unbind request. > > The server SHALL terminate the underlying connection > upon receipt of an unbind request. > > Comments? > From list@netscape.com Tue Feb 15 13:46:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18111 for ; Tue, 15 Feb 2000 13:46:31 -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 KAA20108; Tue, 15 Feb 2000 10:42:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA15633; Tue, 15 Feb 2000 10:45:26 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 10:45:26 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 15 Feb 2000 11:44:57 -0700 From: "Mark Meredith" To: , , Subject: RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"052tvD.A.lxD.C7Zq4"@glacier> 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 NAA18111 I will make the EQUALITY be a caseIgnoreMatch, I had looked for caseExact but did not find it, so I used the caseExactIA5Match. After thinking about it, it would probably be better to use the caseIgnoreMatch. -Mark >>> "Jim Sermersheim" 02/14/00 06:55PM >>> I think Mark's intention was to change the EQUALITY matching rule to caseIgnoreMatch when he changed the syntax but it slipped by. OTOH, if he *did* want caseExactMatch, I think it would be confusing to reference it without it being formally defined somewhere (in LDAP land). I also think it would be a little funky to define it in this document. It seems like it should be grouped with the others you mention in some other place. Jim >>> "Salter, Thomas A" 2/14/00 3:20:21 PM >>> I just noticed that the EQUALITY matching rule for these attributes in caseExactIA5Match, but the syntaxes are now DirectoryString. This led me back to RFC2252 which includes the definition for caseIgnoreMatch (borrowed from X.520), but not caseExactMatch. What happened to: ( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) And now that I've started down this path, what about: caseExactOrderingMatch, caseExactSubstringsMatch, numericStringOrderingMatch, telephoneNumberOrderingMatch, and a whole lot more that X.520 defines? Are these assumed to be inherited from X.520, but not included in the "Servers SHOULD be capable ... " clause? Or is this the complete list that other RFCs may reference? To get back to the subject, can vendor info draft include "EQUALITY 2.5.13.5" in the attribute definitions, or must it also define caseExactMatch. From list@netscape.com Tue Feb 15 13:57: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 NAA18466 for ; Tue, 15 Feb 2000 13:57:07 -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 KAA05474; Tue, 15 Feb 2000 10:50:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA21090; Tue, 15 Feb 2000 10:52:22 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 10:52:22 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 15 Feb 2000 11:51:57 -0700 From: "Mark Meredith" To: "Jim Sermersheim" , Cc: Subject: Re: Vendor Info Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"haHjDC.A.PJF.mBaq4"@glacier> 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 NAA18466 I had intended these to only be set by the developer of the server on compile time. I feel that if you are able to change the values then there is really not any better than not having the values, I would like to have some confidence that the information if provided is accurate according to what the developer put there is valid. As for changing the wording . "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, ..." What word would you recomend to clarify recognize? Or how would you re-word it to take recognize out or make it more solid (clear). -Mark >>> "Kurt D. Zeilenga" 02/14/00 08:03PM >>> At 07:12 PM 2/14/00 -0700, Jim Sermersheim wrote: >>Section 5. >> >>If a server supports these attribute types, the values should >>be overwritable by configuration. This allows a server to >>"spoof" clients to obtain desired behavior. > >Are you requesting that this wording be added to the draft? If so, why? Perhaps your should should've been a shouldn't? I suggest using wording similiar to that found in the RFC 2616 (HTTP 1.1): Server implementors are encouraged to make the values of these attributes configurable options. Note, they encourage suggest for security reasons. Though quite valid, I suggest it primarily for interoperability. I've already seen folks hack OpenLDAP to spoof other servers so that they could use some client which inappropriately depended provided vendor information. [In believe the vendor ended up hacking their own server to spoof the old version so that their client would work]. >>Clients should not attempt fuzzy matching. They must only >>enable workarounds when the server presents a vendor strings >>known to evident of specific flaws. > >While this may be good advise, I don't see it as a requirement. If a client writer knows that versions 5.0 thru 5.x all exhibited a certain bug, and it was fixed in 6.0, it's reasonable for them to assume that a version substring of 5. will exhibit the bug. No, because the vendor may, even after producing 6.0, produce a 5.y which fixes the behavior. This sometimes occurs because a large customer of the vendor specifically requests a patch for the older version and the vendor complies. It is not uncommon for a vendor to support and revise multiple versions for significant time. >> They must assume that all >>unknown vendor strings behavior per standard track specifications. > >Are you requesting that this wording be included in addition to, or in lieu of: "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct."? I would prefer to clarify the term "recognize". From list@netscape.com Tue Feb 15 16:13:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22967 for ; Tue, 15 Feb 2000 16:13: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 NAA12041; Tue, 15 Feb 2000 13:08:33 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA09048; Tue, 15 Feb 2000 13:12:14 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 13:12:14 -0800 (PST) Message-Id: <3.0.5.32.20000215131206.0092fbd0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Feb 2000 13:12:06 -0800 To: "Mark Meredith" From: "Kurt D. Zeilenga" Subject: Re: Vendor Info Cc: "Jim Sermersheim" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"KurfqC.A.GNC.sEcq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:51 AM 2/15/00 -0700, Mark Meredith wrote: >I had intended these to only be set by the developer of the server on compile time. I feel that if you are able to change the values then there is really not any better than not having the values, I would like to have some confidence that the information if provided is accurate according to what the developer put there is valid. You have already dismissed the accuracy of the provided information: Client and application implementers must consider that the existence of a given value in the vendorName or vendorVersion attribute is no guarantee that the server was actually built by the asserted vendor or that its version is the asserted version and should act accordingly. You'll note that most web servers have the HTTP product tags defaults generated as part of their build system, but allow the local administrator to override these values. This gives the flexibility to the local administrator which is where it should be. >As for changing the wording . "If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, ..." >What word would you recomend to clarify recognize? Or how would you re-word it to take recognize out or make it more solid (clear). Something like: If the vendor string does not exactly match vendor information known to flawed, the client MUST NOT alter its behavior. The client SHOULD NOT use "fuzzy" or "wildcard" matching of vendor information to determine its behavior. From list@netscape.com Tue Feb 15 16:29: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 QAA23340 for ; Tue, 15 Feb 2000 16:29: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 NAA14912; Tue, 15 Feb 2000 13:24:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA19401; Tue, 15 Feb 2000 13:27:55 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 13:27:55 -0800 (PST) Reply-To: From: "Bob Joslin" To: Cc: Subject: Comments on draft-zeilenga-ldap-authpasswd-01.txt Date: Tue, 15 Feb 2000 13:27:50 -0800 Message-ID: <008e01bf77f8$d976cea0$a6820d0f@cup.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Resent-Message-ID: <"-zX3xD.A.2uE.aTcq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi Kurt, I have a few comments and questions about your draft. I appreciate your efforts to standardize this area. 3. Background and Intended Use The authPassword attribute type is intended to be used to store hashed password values for authentication purposes. The attribute type supports multiple storage schemes and provides an equality matching rule which allows clients to assert that a clear text password "matches" one of the attribute's values. Storage schemes may make use of one-way hashing and encryption. The attribute may be used by LDAP servers to implement simple bind and SASL [RFC 2222] user/password mechanisms such as DIGEST-MD5 [DIGEST- MD5]. I may be a bit green in understanding DIGEST-MD5, but why would having an already-hashed password help an LDAP server implement DIGEST-MD5 SASL binds? Doesn't DIGEST-MD5 authentication require the server to generate a nonce each time a bind is performed? Thus, how is having a pre-hashed value useful? 4.1. authPasswordSyntax ( authPasswordSyntaxOID DESC 'authentication password syntax' ) Values of this syntax are encoded according to the following BNF: authPasswordValue = scheme "$" [ info ] "$" hashedValue scheme = info = hashedValue = where scheme describes the hash mechanism, info is a scheme specific, and hashedValue is the hashed value. The info field is often a salt. If the authPasswordSyntax requires a hashedValue, why not change the name of the attribute to "hashPassword" instead of "authPassword?" I would think "hashPassword" would be a more descriptive name. Besides, if I'm not mistaken, the "authPassword" could not be used to perform DIGEST-MD5 authentication anyway. (Please correct me if I don't understand this.) 5. Schemes This section describes the "MD5", "SHA1", and "SASL/DIGEST-MD5". Other schemes may be defined by other documents. Schemes starting with string "SASL/" indicate association with a SASL mechanism. Schemes which are not described by standard track documents SHOULD be named with a leading "X-" or, if associated with a SASL mechanism, "SASL/X-" to indicate they are a private or implementation specific extension. Scheme names are case insensitive. As Mark Smith pointed out, you omitted "crypt". I reviewed your reply but still think we would like to see your draft mention "crypt." We work on a project that implements RFC 2307. Many of our customers would like to be able to have a chose of security mechanisms, balancing that with the functionality and security they receive. Having a standard mention this would increase the likelihood they'd have that choice. Thanks. Bob Joslin Hewlett-Packard bobj@cup.hp.com From list@netscape.com Tue Feb 15 16:39:53 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23925 for ; Tue, 15 Feb 2000 16:39: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 NAA16332; Tue, 15 Feb 2000 13:34:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA25025; Tue, 15 Feb 2000 13:38:24 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 13:38:24 -0800 (PST) Date: Tue, 15 Feb 2000 15:37:38 -0600 From: Mark Wahl Subject: Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt In-reply-to: "Your message of Tue, 15 Feb 2000 13:27:50 PST." <008e01bf77f8$d976cea0$a6820d0f@cup.hp.com> Sender: Mark.Wahl@INNOSOFT.COM To: bobj@cup.hp.com Cc: kurt@openldap.org, ietf-ldapext@netscape.com Message-id: <26451.950650658@threadgill.austin.innosoft.com> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"iENJ8.A.vGG.Pdcq4"@glacier> 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 may be a bit green in understanding DIGEST-MD5, but why would having an > already-hashed password help an LDAP server implement DIGEST-MD5 SASL binds? > Doesn't DIGEST-MD5 authentication require the server to generate a nonce > each time a bind is performed? Thus, how is having a pre-hashed value > useful? You might want to take a look at draft-wahl-ldap-digest-example-00.txt, which describes how one vendor implements DIGEST-MD5 with hashed passwords. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Tue Feb 15 17:14:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25550 for ; Tue, 15 Feb 2000 17:14: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 OAA08359; Tue, 15 Feb 2000 14:12:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA15524; Tue, 15 Feb 2000 14:14:01 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 14:14:01 -0800 (PST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Tue, 15 Feb 2000 14:14:39 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: LDAP extensions Subject: draft-ietf-ldapext-ldapv3-tls-06.txt proposed change In-Reply-To: <3.0.5.32.20000210101238.009a0100@infidel.boolean.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"F1TCCC.A.SyD.o-cq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com As Kurt has pointed out (and first pointed out back in November), there is a difference between RFC 2251 and draft-ietf-ldapext-ldapv3-tls-06.txt on the question of what the client authentication/authorization state should be after a failed bind attempt. 2251 (last paragraph of 4.2.1) says: Clients MAY send multiple bind requests on a connection to change their credentials. A subsequent bind process has the effect of abandoning all operations outstanding on the connection. (This simplifies server implementation.) Authentication from earlier binds are subsequently ignored, and so if the bind fails, the connection will be treated as anonymous. Call this the "revert-to-anonymous" approach. Whereas ldapv3-tls-06 (first paragraph of 6.1.2.3) says: For either form of assertion, the server MUST verify that the client's authentication identity as supplied in its TLS credentials is permitted to be mapped to the asserted authorization identity. The server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized. The LDAP association's authentication identity and authorization identity (if any) which were in effect after TLS establishment but prior to making the Bind request, MUST remain in force. Call this the "leave-as-is" approach. (The same language appears in the second paragraph too.) The intention never was to have different behavior for different kinds of binds. Some of us (Jeff and Bob) think that the leave-as-is approach is the right thing to do for all failed binds, since it's more intuitive (to us), consistent with other practice (eg "su" on UNIX), and produces a cleaner state diagram. However, upon reflection these arguments don't seem compelling enough to change the behavior that is in RFC 2251, especially at this point when a revised 2251 isn't even on the table. We do think it's worthy of discussion when 2251 is revised, though. We also don't want this issue to hold up the issuance of the set of security docs (draft-ietf-ldapext-authmeth-04.txt, draft-ietf-ldapext-ldapv3-tls-06, draft-leach-digest-sasl-05.txt) which this WG has been working on for over two years, and which will remove the IESG warning from the front of RFCs 2251-56. These docs have already been through WG and IETF last calls, and IESG review, and are very close to going to RFC. So, we propose that section 6.1.2.3 in draft-ietf-ldapext-ldapv3-tls-06 be changed to reflect the revert-to-anonymous approach; new text is appended to this message. This is a small but substantive change which will require a new (-07) version of the ldapv3-tls draft. Rather than go through another full last call we suggest waiting a week from today for comments on this change, then telling the Area Directors to go forward with ldapv3-tls-07 for publication. Comments, please. - RL "Bob" Morgan Jeff Hodges Mark Wahl --- 6.1.2.3. Error Conditions For either form of assertion, the server MUST verify that the client's authentication identity as supplied in its TLS credentials is permitted to be mapped to the asserted authorization identity. The server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized. Additionally, with either form of assertion, if a TLS session has not been established between the client and server prior to making the SASL EXTERNAL Bind request and there is no other external source of authenti- cation credentials (e.g. IP-level security RFC 1825), or if, during the process of establishing the TLS session, the server did not request the client's authentication credentials, the SASL EXTERNAL bind MUST fail with a result code of inappropriateAuthentication. After the above Bind operation failures, any client authentication and authorization state of the LDAP association is lost, so the LDAP association is in an anonymous state after the failure. TLS connection state is unaffected, though a server MAY end the TLS connection, via a TLS close_notify message, based on the Bind failure (as it MAY at any time). From list@netscape.com Tue Feb 15 18:33:05 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27500 for ; Tue, 15 Feb 2000 18:33: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 PAA20204; Tue, 15 Feb 2000 15:30:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA24722; Tue, 15 Feb 2000 15:31:59 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 15:31:59 -0800 (PST) Message-Id: <3.0.5.32.20000215153127.0096ce40@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Feb 2000 15:31:27 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt Cc: In-Reply-To: <008e01bf77f8$d976cea0$a6820d0f@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Bs1q4D.A._BG.uHeq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:27 PM 2/15/00 -0800, Bob Joslin wrote: >I may be a bit green in understanding DIGEST-MD5, but why would having an >already-hashed password help an LDAP server implement DIGEST-MD5 SASL binds? DIGEST-MD5 is designed such that servers need not store the clear text password; they may store a derived value instead. The authPassword draft describes how this derived value (with other information useful in implementing the mechanism) may be stored in the directory. See DIGEST-MD5, Section 3.9. >As Mark Smith pointed out, you omitted "crypt". I reviewed your reply but >still think we would like to see your draft mention "crypt." This document is intended for the standard track. Inclusion of a crypt scheme, IMO, is incompatible with this intent for reasons previously stated. I beleive it appropriate to handle introduction of a crypt scheme as an extension described by a separate document not on the standard track. From list@netscape.com Tue Feb 15 21:15: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 VAA00734 for ; Tue, 15 Feb 2000 21:15: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 SAA27998; Tue, 15 Feb 2000 18:10:57 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA21802; Tue, 15 Feb 2000 18:14:38 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 18:14:38 -0800 (PST) Message-Id: <3.0.5.32.20000215181413.00928980@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Feb 2000 18:14:13 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: Comments on draft-zeilenga-ldap-authpasswd-01.txt Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"DXUmY.A.YUF.Nggq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:28 PM 2/15/00 -0800, Bob Joslin wrote: >I noticed you omitted the reply on the suggestion for changing the name of >the attribute to hashPassword? I assume you disagree with the suggestion? I overlooked this suggestion. See my comments below. >4.1. authPasswordSyntax > > ( authPasswordSyntaxOID > DESC 'authentication password syntax' ) > > Values of this syntax are encoded according to the following BNF: > > authPasswordValue = scheme "$" [ info ] "$" hashedValue > scheme = > info = > hashedValue = > > where scheme describes the hash mechanism, info is a scheme specific, > and hashedValue is the hashed value. The info field is often a salt. > >If the authPasswordSyntax requires a hashedValue, why not change the name >of the attribute to "hashPassword" instead of "authPassword?" I intended to reword the section to not use the term "hash" but to say the value stored a scheme specific. The intent is for this attribute to be capable of support a wide variety of storage schemes used to support authentication via user passwords. >I would think "hashPassword" would be a more descriptive name. The primary usage of the attribute type is to support password authentication mechanisms, hence the name "authPassword." From list@netscape.com Wed Feb 16 01:45:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10020 for ; Wed, 16 Feb 2000 01:45: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 WAA16910; Tue, 15 Feb 2000 22:40:26 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA27520; Tue, 15 Feb 2000 22:44:06 -0800 (PST) Resent-Date: Tue, 15 Feb 2000 22:44:06 -0800 (PST) From: tgmd957@aol.com Date: Tue, 15 Feb 2000 22:44:02 -0800 (PST) Message-Id: <200002160644.WAA01491@xwing.netscape.com> To: 45645@aol.com Subject: Confidential ! Resent-Message-ID: <"PxnKv.A.utG.0ckq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-212-465-3248 Call 24 hours a day, 7 days a week, including Sundays and holidays. rem- member556@excite.com From list@netscape.com Wed Feb 16 10:23: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 KAA01747 for ; Wed, 16 Feb 2000 10:23: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 HAA06356; Wed, 16 Feb 2000 07:20:32 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA03131; Wed, 16 Feb 2000 07:22:05 -0800 (PST) Resent-Date: Wed, 16 Feb 2000 07:22:05 -0800 (PST) Message-ID: <38AAC04E.3814D36B@netscape.com> Date: Wed, 16 Feb 2000 10:20:46 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "RL 'Bob' Morgan" CC: LDAP extensions Subject: Re: draft-ietf-ldapext-ldapv3-tls-06.txt proposed change References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jtlh1D.A.pw.cCsq4"@glacier> 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 support your proposal. We definitely need to specify consistent behavior in the face of failed binds (thanks to Kurt for noticing the discrepancy). I think it is too late to change LDAPv3's behavior (as specified in 2251) since clients likely exist that rely on the "revert-to-anonymous" behavior it specifies... but that is an argument for another later day. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? RL 'Bob' Morgan wrote: > > As Kurt has pointed out (and first pointed out back in November), > there is a difference between RFC 2251 and > draft-ietf-ldapext-ldapv3-tls-06.txt on the question of what the client > authentication/authorization state should be after a failed bind > attempt. 2251 (last paragraph of 4.2.1) says: > > Clients MAY send multiple bind requests on a connection to change > their credentials. A subsequent bind process has the effect of > abandoning all operations outstanding on the connection. (This > simplifies server implementation.) Authentication from earlier binds > are subsequently ignored, and so if the bind fails, the connection > will be treated as anonymous. > > Call this the "revert-to-anonymous" approach. Whereas ldapv3-tls-06 > (first paragraph of 6.1.2.3) says: > > For either form of assertion, the server MUST verify that the client's > authentication identity as supplied in its TLS credentials is permitted > to be mapped to the asserted authorization identity. The server MUST > reject the Bind operation with an invalidCredentials resultCode in the > Bind response if the client is not so authorized. The LDAP association's > authentication identity and authorization identity (if any) which were > in effect after TLS establishment but prior to making the Bind request, > MUST remain in force. > > Call this the "leave-as-is" approach. (The same language appears in > the second paragraph too.) > > The intention never was to have different behavior for different kinds > of binds. Some of us (Jeff and Bob) think that the leave-as-is > approach is the right thing to do for all failed binds, since it's > more intuitive (to us), consistent with other practice (eg "su" on > UNIX), and produces a cleaner state diagram. However, upon reflection > these arguments don't seem compelling enough to change the behavior > that is in RFC 2251, especially at this point when a revised 2251 > isn't even on the table. We do think it's worthy of discussion when > 2251 is revised, though. > > We also don't want this issue to hold up the issuance of the set of > security docs (draft-ietf-ldapext-authmeth-04.txt, > draft-ietf-ldapext-ldapv3-tls-06, draft-leach-digest-sasl-05.txt) > which this WG has been working on for over two years, and which will > remove the IESG warning from the front of RFCs 2251-56. These docs > have already been through WG and IETF last calls, and IESG review, and > are very close to going to RFC. > > So, we propose that section 6.1.2.3 in draft-ietf-ldapext-ldapv3-tls-06 > be changed to reflect the revert-to-anonymous approach; new text is > appended to this message. > > This is a small but substantive change which will require a new (-07) > version of the ldapv3-tls draft. Rather than go through another full > last call we suggest waiting a week from today for comments on this > change, then telling the Area Directors to go forward with > ldapv3-tls-07 for publication. > > Comments, please. > > - RL "Bob" Morgan > Jeff Hodges > Mark Wahl > > --- > > 6.1.2.3. Error Conditions > > For either form of assertion, the server MUST verify that the client's > authentication identity as supplied in its TLS credentials is permitted > to be mapped to the asserted authorization identity. The server MUST > reject the Bind operation with an invalidCredentials resultCode in the > Bind response if the client is not so authorized. > > Additionally, with either form of assertion, if a TLS session has not > been established between the client and server prior to making the SASL > EXTERNAL Bind request and there is no other external source of authenti- > cation credentials (e.g. IP-level security RFC 1825), or if, during the > process of establishing the TLS session, the server did not request the > client's authentication credentials, the SASL EXTERNAL bind MUST fail > with a result code of inappropriateAuthentication. > > After the above Bind operation failures, any client authentication > and authorization state of the LDAP association is lost, so the LDAP > association is in an anonymous state after the failure. TLS > connection state is unaffected, though a server MAY end the TLS > connection, via a TLS close_notify message, based on the Bind > failure (as it MAY at any time). From list@netscape.com Wed Feb 16 12:20:15 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07064 for ; Wed, 16 Feb 2000 12:20:12 -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 JAA29514; Wed, 16 Feb 2000 09:15:33 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA14583; Wed, 16 Feb 2000 09:19:15 -0800 (PST) Resent-Date: Wed, 16 Feb 2000 09:19:15 -0800 (PST) Message-Id: <3.0.5.32.20000216091841.00998100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 16 Feb 2000 09:18:41 -0800 To: "RL 'Bob' Morgan" From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldapext-ldapv3-tls-06.txt proposed change Cc: LDAP extensions In-Reply-To: References: <3.0.5.32.20000210101238.009a0100@infidel.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Ck3ZKC.A.hjD.Swtq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Bob, Jeff, MarkW, The suggested change to the TLS draft appears to be fine. Note that the AuthMeth draft will need a similar change (last sentence of section 10). Though I too would like to see these drafts progressed quickly, we must not be too hasty. As you noted, the change is "substantive." As such, I believe it prudent to have yet another WG last call. I also believe it quite likely that the IESG will require another IETF wide last call because the documents were revised multiple times, including a number of "substantive" changes, multiple subsequent WG last calls were made after the IETF wide last call, and just the fact that the previous IETF wide call completed some time ago. Kurt From list@netscape.com Wed Feb 16 12:28:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07374 for ; Wed, 16 Feb 2000 12:28: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 JAA01073; Wed, 16 Feb 2000 09:23:38 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA18233; Wed, 16 Feb 2000 09:27:15 -0800 (PST) Resent-Date: Wed, 16 Feb 2000 09:27:15 -0800 (PST) Date: Wed, 16 Feb 2000 11:26:27 -0600 From: Mark Wahl Subject: Re: draft-ietf-ldapext-ldapv3-tls-06.txt proposed change In-reply-to: "Your message of Wed, 16 Feb 2000 09:18:41 PST." <3.0.5.32.20000216091841.00998100@infidel.boolean.net> Sender: Mark.Wahl@INNOSOFT.COM To: "Kurt D. Zeilenga" Cc: "RL 'Bob' Morgan" , LDAP extensions Message-id: <28806.950721987@threadgill.austin.innosoft.com> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"3tboHD.A.WcE.x3tq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Once the LDAPEXT review is done, the Apps Area Directors will let us know what to do next with the draft. I'll let the list know what the result is. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 16 13:08: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 NAA08711 for ; Wed, 16 Feb 2000 13:07: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 KAA29428; Wed, 16 Feb 2000 10:04:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA07717; Wed, 16 Feb 2000 10:06:36 -0800 (PST) Resent-Date: Wed, 16 Feb 2000 10:06:36 -0800 (PST) Message-Id: <3.0.5.32.20000216100620.0096c200@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 16 Feb 2000 10:06:20 -0800 To: "Salter, Thomas A" From: "Kurt D. Zeilenga" Subject: RE: RFC2251: unbind Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"A9ovB.A.-3B.qcuq4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:17 AM 2/15/00 -0500, Salter, Thomas A wrote: >I'd prefer a protocol where only one side could initiate the normal >shutdown. From the LDAP perspective, this is what we have. The client initiates normal shutdown by issuing an unbind request. The problem is that specification doesn't not mandate a particular action after sending or receiving an unbind request. >In this case the server should do that as a response to the >unbind. That response, IMO, should be to terminate the underlying TCP session. >The client should close in response to server-initiated close. I believe it appropriate for the client to close the connection as well. The server can determine if the shutdown was ordered or not by receipt of the unbind request. >This would eliminate the various race conditions that exist otherwise and >make it easier to tell normal conditions from error conditions. I believe the race conditions that were noted have to do with handling of outstanding requests on the server side. Shutdown when multiple outstanding operations are being processed is a bit tricky but quite managable. I believe the basic protocol is fine. I think the problem is just a matter of specification. The specification should describe an "LDAP Session" and how it relates to the underlying transport protocol. The document should describe how a LDAP Session is initiated (by establishment of the underlying transport protocol) and how an LDAP Session is terminated (by shutdown of the underlying transport protocol). It should be careful not to imply that bind initiates a protocol session and that unbind does not un-do a bind. > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Monday, February 14, 2000 5:41 PM > > To: ietf-ldapext@netscape.com > > Subject: Re: RFC2251: unbind > > > > > > At 08:41 AM 2/14/00 -0800, Kurt D. Zeilenga wrote: > > >It seems that some folks are confused about the function of > > >unbind. We've likely have all heard the "don't I need to unbind > > >before rebinding" enquiry. Some have even noted that the > > >disconnection requirements are MAY, not MUSTs. Some have any > > >stated that some servers do not terminate the connection upon > > >receipt of an unbind request. > > > > > >It seems that some implementors don't take "The function of the > > >Unbind Operation is to terminate a protocol session" as an absolute. > > > > > >I would suggest that the paragraph following this sentence > > >for clarification: > > > A client SHALL NOT submit further requests after > > > sending an unbind request. A client SHOULD terminate > > > the underlying TCP session after making the unbind > > > request. > > > A server SHALL NOT process nor respond to further > > > requests received after an unbind requests. A > > > server SHOULD terminate the underlying TCP session > > > after receiving the unbind request. > > > > Note that the existing paragraph allows the client to wait > > for the server to initiate the TCP shutdown AND allows the > > server to wait for the client to initiate the TCP shutdown. > > There really should be at least one SHALL detailing who > > must shutdown the connection and when. > > > > I revise my suggestion: > > The client SHALL terminate the underlying connection > > after submitting an unbind request. > > > > The server SHALL terminate the underlying connection > > upon receipt of an unbind request. > > > > Comments? > > > > From list@netscape.com Thu Feb 17 11:26:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17101 for ; Thu, 17 Feb 2000 11:26: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 IAA10531; Thu, 17 Feb 2000 08:20:12 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA24330; Thu, 17 Feb 2000 08:23:47 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 08:23:47 -0800 (PST) Message-Id: <200002171623.LAA17018@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ldapext@netscape.com From: The IESG Subject: Document Action: Access Control Requirements for LDAP to Informational Date: Thu, 17 Feb 2000 11:23:17 -0500 Sender: scoya@cnri.reston.va.us Resent-Message-ID: <"1bIbu.A.47F.RCCr4"@glacier> 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 approved the Internet-Draft 'Access Control Requirements for LDAP' as an Informational RFC. This document is the product of the LDAP Extension Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom. From list@netscape.com Thu Feb 17 14:38:19 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22780 for ; Thu, 17 Feb 2000 14:38: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 LAA08489; Thu, 17 Feb 2000 11:33:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA11390; Thu, 17 Feb 2000 11:07:51 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 11:07:51 -0800 (PST) Message-ID: <38AC46BA.71EA48A4@netscape.com> Date: Thu, 17 Feb 2000 14:06:34 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: ACL model comments References: <3.0.5.32.20000214215708.00936dc0@infidel.boolean.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"h82yW.A.8wC.FcEr4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > Though I haven't had time to do a full review, I can offer > a few comments: > > Section 6.3 > > The 'aci' attribute is defined as a user, not operational, > attribute type. Besides being appropriate in terms of usage, > this would allow this attribute type in any and all > object classes. If usage is left as user, you'd likely > have to define an auxiliary objectclass to allow mix in > or replace 'top' or something. I agree that the attribute type used to store access control information should be operational. X.500's various access control attribute types are defined with "USAGE directoryOperation" which seems right to me. I would also like to see us choose a different name for the attribute type. An attribute called 'aci' has been used in the Netscape/iPlanet Directory Server for several years now to hold proprietary access control information. See: http://home.netscape.com/eng/server/directory/schema/attribu4.htm#1717762 I admit that 'aci' was not a good name for Netscape to use, but I suggest we use a name like 'ldapACI' for the new standard scheme to avoid confusion (unless someone else is already using that name too!). -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Thu Feb 17 15:25:27 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23625 for ; Thu, 17 Feb 2000 15:25:26 -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 MAA14428; Thu, 17 Feb 2000 12:20:28 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA18249; Thu, 17 Feb 2000 12:24:12 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 12:24:12 -0800 (PST) Message-Id: <200002172023.PAA23598@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ldapext@netscape.com From: The IESG Subject: Protocol Action: Authentication Methods for LDAP to Proposed Standard Date: Thu, 17 Feb 2000 15:23:43 -0500 Sender: scoya@cnri.reston.va.us Resent-Message-ID: <"d21i7.A.3cE.qjFr4"@glacier> 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 approved publication of the following Internet-Drafts as Proposed Standards: o Authentication Methods for LDAP o Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security o Using Digest Authentication as a SASL Mechanism These documents are the product of the LDAP Extension Working Group. The IESG contact persons are Keith Moore and Patrik Faltstrom. Technical Summary These documents add basic security mechanisms to the LDAPv3 protocol. They define the use of SASL mechanisms and TLS together with LDAPv3, as well as the usage of HTTP Digest as one SASL mechanism. Working Group Summary The path the working group followed until landing at SASL and TLS as the final mechanisms was long and winding. When SASL was up on the table though, the choices were quite easy, and consensus was easy to get. Protocol Quality The spec is reviewed by Patrik Faltstrom. Note to the RFC-Editor: In the draft-leach-digest-sasl-03.txt document, please see that the intro to the I-D boilerplate is deleted (together with the I-D boilerplate). The document has been discussed in a working group, even though it has not been part of the wg charter (there is though a normative reference to this document from a wg one). The wg in question (LDAPEXT) do have consensus over this document. The text that should explicitely be removed from the I-D is the beginning of the document, reading: THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT. IT DOES NOT REPRESENT THE CONSENSUS OF ANY WORKING GROUP. In draft-ietf-ldapext-authmeth, please change the text of the last paragraph of section 6 as follows: --- OLD TEXT If a SASL security layer is negotiated, the client MUST discard all information about the server fetched prior to SASL. In particular, if the client is configured to support multiple SASL mechanisms, it SHOULD fetch supportedSASLMechanisms both before and after the SASL security layer is negotiated and verify that the value has not changed after the SASL security layer was negotiated. This detects active attacks which remove supported SASL mechanisms from the supportedSASLMechanisms list. --- END --- NEW TEXT If a SASL security layer is negotiated, the client MUST discard all information about the server fetched prior to SASL. In particular, if the client is configured to support multiple SASL mechanisms, it SHOULD fetch supportedSASLMechanisms both before and after the SASL security layer is negotiated and verify that the value has not changed after the SASL security layer was negotiated. This detects active attacks which remove supported SASL mechanisms from the supportedSASLMechanisms list, and allows the client to ensure that it is using the best mechanism supported by both client and server (additionally, this is a SHOULD to allow for environments where the supported SASL mechanisms list is provided to the client through a different trusted source, e.g. as part of a digitally signed object). --- END From list@netscape.com Thu Feb 17 17:22:11 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26290 for ; Thu, 17 Feb 2000 17:22:09 -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 OAA28499; Thu, 17 Feb 2000 14:17:18 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA00410; Thu, 17 Feb 2000 14:21:03 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 14:21:03 -0800 (PST) Message-ID: <38AC7458.9BB98D4E@us.oracle.com> Date: Thu, 17 Feb 2000 14:21:13 -0800 From: Saurabh Shrivastava Reply-To: sshrivas@us.oracle.com Organization: Oracle Corp. X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: Named Referrals in LDAP Directories Content-Type: multipart/mixed; boundary="------------B4815A596AF99D24508E8037" Resent-Message-ID: <"Bd2XSD.A.6F.NRHr4"@glacier> 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. --------------B4815A596AF99D24508E8037 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit As per Section 5.1.1.3 of this draft (Search with one level scope)
    'For search operations, once the base object has been found and determined not to contain a ref attribute, the search may progress. Any entries matching the filter and scope of the search that do NOT contain a ref attribute are returned to the client normally as described in  [RFC2251]. Any entries matching the filter and one level scope that do contain a ref attribute must be returned as referrals as described here.'

The later part of the above paragraph states that  'Any entries matching the filter and one level scope that contain a ref attribute'.  Here, an entry containing the ref attribute may not match with the filter specified in the one level search operation even though it is present in the scope of the search. In this case should the ldap server, return a referral as the referral entry is in the scope of the search even though the filter does not match? The same issues arises in section 5.1.1.4 of the draft.

I would really appreciate any clarification on the above issue.

Thanks in advance for all your help.

Regards,

Saurabh Shrivastava --------------B4815A596AF99D24508E8037 Content-Type: text/x-vcard; charset=us-ascii; name="sshrivas.vcf" Content-Description: Card for Saurabh Shrivastava Content-Disposition: attachment; filename="sshrivas.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shrivastava;Saurabh tel;work:650-506-6815 x-mozilla-html:TRUE org:Oracle Corporation version:2.1 email;internet:sshrivas@us.oracle.com title:Sr. Member of Technical staff adr;quoted-printable:;;500 Oracle Parkway=0D=0A6OP643;Redwood Shores;CA;94404;USA x-mozilla-cpt:;0 fn:Saurabh Shrivastava end:vcard --------------B4815A596AF99D24508E8037-- From list@netscape.com Thu Feb 17 20:45:08 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28942 for ; Thu, 17 Feb 2000 20:45: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 RAA14608; Thu, 17 Feb 2000 17:42:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA10578; Thu, 17 Feb 2000 17:44:03 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 17:44:03 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 17 Feb 2000 18:43:40 -0700 From: "Jim Sermersheim" To: Subject: Comments on draft-zeilenga-ldap-authpasswd-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"L08S3.A.MkC.hPKr4"@glacier> 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 UAA28942 First a minor consistency issue: Section 3 says "The attribute may be used by LDAP servers to implement simple bind and SASL ..." Section 7 says "This document describes how authentication information to support simple password authentication ..." (Section 7 is missing and SASL ...) Then I've got some questions regarding implementation details. The wording of the first sentence of Section 6 is a bit confusing: "Servers MAY restrict schemes used to support a particular authentication process but SHOULD use all values of those schemes." What does "use all values of those schemes" mean? I'm guessing that it should read "use all values of those schemes which are supported", but I'm not sure. It would also help to qualify the word use. The authPassword attribute is defined as multi-valued. Then there is an indication of what makes up the set of values: "The values of this abbribute[SIC] are derived from the user's password per the indicated scheme". The implication (based on the singularity of the word password) is that though this attribute may hold many values, each value is a different representation (different hash) of a _single_ password. If this is the case, I'm reading a lot into the draft that isn't there yet. If it's not the case, and the intent is that this attribute can hold an arbitrary number of different passwords, there are security holes that need to be talked about in the Security Considerations section. I don't want to go down both paths in this message. I'll wait for the reply as to the intent of allowing multiple values first. How is the attribute populated? It's a user attribute which leads me to believe that the client is responsible to populate/update it. If so, the client would (should) have to populate/re-populate each value in the attribute, right? It seems like this could be achieved in a much more secure and consistent way if there was a server side mechanism for creating and updating values of this attribute. Jim From list@netscape.com Fri Feb 18 00:31:37 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03746 for ; Fri, 18 Feb 2000 00:31: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 VAA00858; Thu, 17 Feb 2000 21:28:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA28108; Thu, 17 Feb 2000 21:30:12 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 21:30:12 -0800 (PST) Message-Id: <3.0.5.32.20000217213001.0094d450@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 17 Feb 2000 21:30:01 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1XCE7.A.62G.jjNr4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:43 PM 2/17/00 -0700, Jim Sermersheim wrote: >First a minor consistency issue: >Section 3 says "The attribute may be used by LDAP servers to implement simple bind and SASL ..." >Section 7 says "This document describes how authentication information to support simple password authentication ... The intent is to allow the attribute to be used to support password based authentication, whether simple bind, SASL, or whatever. I'll attempt to clarify in next draft. > >Then I've got some questions regarding implementation details. > >The wording of the first sentence of Section 6 is a bit confusing: "Servers MAY restrict schemes used to support a particular authentication process but SHOULD use all values of those schemes." What does "use all values of those schemes" mean? I'm guessing that it should read "use all values of those schemes which are supported", but I'm not sure. It would also help to qualify the word use. The intent is that an authentication process which uses X, Y, and Z schemes should use all values of scheme X, Y, and Z. I'll try to clarify this as well. >The authPassword attribute is defined as multi-valued. Then there is an indication of what makes up the set of values: "The values of this abbribute[SIC] are derived from the user's password per the indicated scheme". The implication (based on the singularity of the word password) is that though this attribute may hold many values, each value is a different representation (different hash) of a _single_ password. If this is the case, I'm reading a lot into the draft that isn't there yet. If it's not the case, and the intent is that this attribute can hold an arbitrary number of different passwords, there are security holes that need to be talked about in the Security Considerations section. I intended was the later, user's password(s), I'll add some clarification and a security consideration. It's my intent is that this attribute be used instead of userPassword, userPassword allows multiple values. >How is the attribute populated? It's a user attribute which leads me to believe that the client is responsible to populate/update it. Yes. The attribute type implies no special behavior. It's my intention that mechanisms would be introduced (in other drafts) to provide additional behavior. >If so, the client would (should) have to populate/re-populate each value in the attribute, right? Yes... or use a separated defined mechanism. Note, it is intended that password change be initiated by a client acting on behalf of the user (or the directory admin). >It seems like this could be achieved in a much more secure and consistent way if there was a server side mechanism for creating and updating values of this attribute. I personally favor use of an extended operation to provide clients with consistent behavior irregardless of the storage used for passwords. I've introduced such in my passwd-exop draft, it may be used with userPassword, authPassword, and/or external password storage. Security, of course, is based on a number of factors. I generally recommend the clear separation of private/secret and public data. I prefer (when using password based authentication) external password storage like that provided by independent SASL service providors). From list@netscape.com Fri Feb 18 01:04: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 BAA04429 for ; Fri, 18 Feb 2000 01:04: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 VAA07986; Thu, 17 Feb 2000 21:59:13 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA04345; Thu, 17 Feb 2000 22:02:58 -0800 (PST) Resent-Date: Thu, 17 Feb 2000 22:02:58 -0800 (PST) Message-Id: <3.0.5.32.20000217220450.00927780@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 17 Feb 2000 22:04:50 -0800 To: ietf-ldapext@netscape.com From: Bruce Greenblatt Subject: Re: draft-mmeredith-rootdse-vendor-info-02.txt Cc: mark_meredith@novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"O0Dv3D.A.lDB.RCOr4"@glacier> 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 blunt, I don't believe that there is much use for this draft. The information that it proposes to add to the Root DSE is already published is already available from SNMP if the LDAP server conforms to RFC 2248. The applVersion field of the MIB is useful here. I think that this draft should just point to RFC 2248 (and perhaps 2605) and explain where the vendor information should be placed. These are already standards track documents, and have places to put the information that this draft defines. (Just my $0.02 worth) Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Fri Feb 18 09:11:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23566 for ; Fri, 18 Feb 2000 09:11: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 GAA02437; Fri, 18 Feb 2000 06:08:41 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA26437; Fri, 18 Feb 2000 06:10:32 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 06:10:32 -0800 (PST) From: "Peter Strong" To: Bruce Greenblatt , ietf-ldapext Cc: mark_meredith Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt Date: Fri, 18 Feb 2000 09:13:02 -0500 Message-ID: <001201bf7a1a$449a6250$3750fb8d@net-pstrong.corpnorth.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <3.0.5.32.20000217220450.00927780@pop.walltech.com> Resent-Message-ID: <"QAH6bD.A.tcG.WLVr4"@glacier> 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 > -----Original Message----- > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] > Sent: Friday, February 18, 2000 1:05 AM > To: ietf-ldapext@netscape.com > Cc: mark_meredith@novell.com > Subject: Re: draft-mmeredith-rootdse-vendor-info-02.txt > > > To be blunt, I don't believe that there is much use for this draft. For those of us who attempt to build applications that work with multiple directory implementations, this information is very useful. > The information that it proposes to add to the Root DSE is already > published is > already available from SNMP if the LDAP server conforms to RFC 2248. The > applVersion field of the MIB is useful here. I think that this draft > should just point to RFC 2248 (and perhaps 2605) and explain where the > vendor information should be placed. These are already standards track > documents, and have places to put the information that this draft defines. > (Just my $0.02 worth) The products we build are LDAP clients, not SNMP clients. This information should be available via LDAP. > > Bruce > ============================================== > Bruce Greenblatt, Ph. D. > Directory Tools and Application Services, Inc. > http://www.directory-applications.com > ------------------------------------------------------------------------ Peter Strong Software Architect Nortel Networks - Optivity Policy Services (OPS) and NetID pestrong@nortelnetworks.com (613) 831-6615 From list@netscape.com Fri Feb 18 11:32:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26499 for ; Fri, 18 Feb 2000 11:32: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 IAA19813; Fri, 18 Feb 2000 08:27:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA08712; Fri, 18 Feb 2000 08:31:08 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 08:31:08 -0800 (PST) Message-Id: <3.0.5.32.20000218083612.0092ad30@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 18 Feb 2000 08:36:12 -0800 To: ietf-ldapext From: Bruce Greenblatt Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt Cc: mark_meredith In-Reply-To: <001201bf7a1a$449a6250$3750fb8d@net-pstrong.corpnorth.bayne tworks.com> References: <3.0.5.32.20000217220450.00927780@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"bneL3.A.7GC.JPXr4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:13 AM 2/18/00 -0500, Peter Strong wrote: > >> >> >> To be blunt, I don't believe that there is much use for this draft. > >For those of us who attempt to build applications that work with >multiple directory implementations, this information is very useful. > The information may be useful. I never said that it wasn't. I said that it's already available someplace else. Get it from there, since that is already a standards track RFC. I don't see much point in duplicating this information. In my opinion, a good internet directory client will get information from a variety of internet servers: DNS, LDAP, SNMP, and others. >> The information that it proposes to add to the Root DSE is already >> published is >> already available from SNMP if the LDAP server conforms to RFC 2248. The >> applVersion field of the MIB is useful here. I think that this draft >> should just point to RFC 2248 (and perhaps 2605) and explain where the >> vendor information should be placed. These are already standards track >> documents, and have places to put the information that this draft defines. >> (Just my $0.02 worth) > >The products we build are LDAP clients, not SNMP clients. > >This information should be available via LDAP. > >> >> Bruce >> ============================================== >> Bruce Greenblatt, Ph. D. >> Directory Tools and Application Services, Inc. >> http://www.directory-applications.com >> > >------------------------------------------------------------------------ >Peter Strong >Software Architect >Nortel Networks - Optivity Policy Services (OPS) and NetID >pestrong@nortelnetworks.com >(613) 831-6615 > > > > > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Fri Feb 18 12:18:14 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27442 for ; Fri, 18 Feb 2000 12:18:12 -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 JAA26258; Fri, 18 Feb 2000 09:13:13 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA27405; Fri, 18 Feb 2000 09:16:53 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 09:16:53 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 18 Feb 2000 10:16:30 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"IOHqLB.A.rrG.C6Xr4"@glacier> 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 MAA27442 >>> "Kurt D. Zeilenga" 2/17/00 10:30:01 PM >>> >>The wording of the first sentence of Section 6 is a bit confusing: "Servers MAY restrict schemes used to support a particular authentication process but SHOULD use all values of those schemes." What does "use all values of those schemes" mean? I'm guessing that it should read "use all values of those schemes which are supported", but I'm not sure. It would also help to qualify the word use. > >The intent is that an authentication process which uses X, Y, and >Z schemes should use all values of scheme X, Y, and Z. So let's say a client performs a simple authentication and sends a clear text password to the server. Are you saying that if the server's authentication process uses X, Y, and Z schemes, it should hash the password with X, then challenge the result against all values of the X scheme, then apply this same process to the password using Y, and Z? If so, what has to match for authentication to happen? I could imagine: 1) all values must match, 2) one value of each scheme has to match, 3) one value of any scheme has to match. >I intended was the later, user's password(s), I'll add some >clarification and a security consideration. It's my intent >is that this attribute be used instead of userPassword, >userPassword allows multiple values. Bummer. This opens up security holes and makes the application of password policy difficult and bulky. I know userPassword allows multiple values, but I've never understood why. I'd like to understand what the reasons are before following the pattern. >>If so, the client would (should) have to populate/re-populate each value in the attribute, right? > >Yes... or use a separated defined mechanism. Note, it is >intended that password change be initiated by a client >acting on behalf of the user (or the directory admin). Then I think the draft needs something in the implementation section that talks about this. It should reflect the notion that if a client changes one value of the authPassword attribute, and not all values, it will likely screw things up--depending on the server implementation. In other words, with this draft, I see an opportunity to make the use of passwords more interoperable. I would like to see a good deal of implementation details in the draft that move us toward that end. >>It seems like this could be achieved in a much more secure >and consistent way if there was a server side mechanism for creating and updating values of this attribute. > >I personally favor use of an extended operation to provide >clients with consistent behavior irregardless of the >storage used for passwords. I've introduced such in >my passwd-exop draft, it may be used with userPassword, >authPassword, and/or external password storage. Security, >of course, is based on a number of factors. I generally >recommend the clear separation of private/secret and public >data. I prefer (when using password based authentication) >external password storage like that provided by independent >SASL service providors). Can you provide a reference to the passwd-exop draft in this draft? Jim From list@netscape.com Fri Feb 18 12:52:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28062 for ; Fri, 18 Feb 2000 12:52: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 JAA00924; Fri, 18 Feb 2000 09:46:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA12673; Fri, 18 Feb 2000 09:50:00 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 09:50:00 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 18 Feb 2000 10:49:36 -0700 From: "Sukanta Ganguly" To: Cc: "Mark Meredith" Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_560FCE2D.1A7B48DC" Resent-Message-ID: <"_MGpj.A.vFD.HZYr4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_560FCE2D.1A7B48DC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable It is very difficult and unclear at this point whether we should assume = that all Internet Directory Client are in the position to talk different = Internet protocols. Instead of assuming that the Directory Client will = talk SNMP and query the MIB for getting the vendor specific information, = why can't we state that the Directory Client queries the rootDSE for the = information and the implementation would determine whether to go to the = SNMP MIB for the information or to have the vendor specific information, = requested by Mark, within the Directory Repository. I think it will bring in more value to have the access to the information = through the rootDSE but at the same time leave the invididual implementatio= ns to handle them. We all agree, based on the emails that I have seen = flowing around related to this matter, that the information is useful so = why not provide the flexibility. Thanks Sukanta Ganguly sganguly@novell.com >>> Bruce Greenblatt 02/18/00 = 09:32AM >>> At 09:13 AM 2/18/00 -0500, Peter Strong wrote: > >> >> >> To be blunt, I don't believe that there is much use for this draft. > >For those of us who attempt to build applications that work with >multiple directory implementations, this information is very useful. > The information may be useful. I never said that it wasn't. I said that it's already available someplace else. Get it from there, since that is already a standards track RFC. I don't see much point in duplicating this information. In my opinion, a good internet directory client will get information from a variety of internet servers: DNS, LDAP, SNMP, and = others. >> The information that it proposes to add to the Root DSE is already >> published is >> already available from SNMP if the LDAP server conforms to RFC 2248. = The >> applVersion field of the MIB is useful here. I think that this draft >> should just point to RFC 2248 (and perhaps 2605) and explain where the >> vendor information should be placed. These are already standards track >> documents, and have places to put the information that this draft = defines. >> (Just my $0.02 worth) > >The products we build are LDAP clients, not SNMP clients. > >This information should be available via LDAP. > >> >> Bruce >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Bruce Greenblatt, Ph. D. >> Directory Tools and Application Services, Inc. >> http://www.directory-applications.com >> > >------------------------------------------------------------------------ >Peter Strong >Software Architect >Nortel Networks - Optivity Policy Services (OPS) and NetID >pestrong@nortelnetworks.com >(613) 831-6615 > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=_560FCE2D.1A7B48DC Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It is very difficult and unclear at this point whether we should = assume=20 that all Internet Directory Client are in the position to talk different=20= Internet protocols. Instead of assuming that the Directory Client will = talk SNMP=20 and query the MIB for getting the vendor specific information, why can't = we=20 state that the Directory Client queries the rootDSE for the information = and the=20 implementation would determine whether to go to the SNMP MIB for the = information=20 or to have the vendor specific information, requested by Mark, within = the=20 Directory Repository.
 
I think it will bring in more value to have the access to the = information=20 through the rootDSE but at the same time leave the invididual implementatio= ns to=20 handle them. We all agree, based on the emails that I have seen flowing = around=20 related to this matter, that the information is useful so why not provide = the=20 flexibility.
 
Thanks
Sukanta Ganguly
sganguly@novell.com

>>= >=20 Bruce Greenblatt <bgreenblatt@directory-applications.com> 02/18/00 = 09:32AM=20 >>>
At 09:13 AM 2/18/00 -0500, Peter Strong=20 wrote:
>
>>
>>
>> To be blunt, I don't = believe=20 that there is much use for this draft.
>
>For those of us = who=20 attempt to build applications that work with
>multiple directory=20 implementations, this information is very useful.
>

The = information=20 may be useful.  I never said that it wasn't.  I said that
it's= =20 already available someplace else.  Get it from there, since that=20 is
already a standards track RFC.  I don't see much point in = duplicating=20 this
information.  In my opinion, a good internet directory client = will=20 get
information from a variety of internet servers: DNS, LDAP, SNMP, = and=20 others.

>> The information that it proposes to add to the = Root DSE=20 is already
>> published is
>> already available from = SNMP if=20 the LDAP server conforms to RFC 2248.  The
>> applVersion = field of=20 the MIB is useful here.  I think that this draft
>> should = just=20 point to RFC 2248 (and perhaps 2605) and explain where the
>> = vendor=20 information should be placed.  These are already standards=20 track
>> documents, and have places to put the information that = this=20 draft defines.
>> (Just my $0.02 worth)
>
>The = products we=20 build are LDAP clients, not SNMP clients.
>
>This information = should=20 be available via LDAP.
>
>>
>>  Bruce
>&= gt;=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>= Bruce Greenblatt, Ph.=20 D.
>> Directory Tools and Application Services, Inc.
>> = http://www.directory-applica= tions.com
>>
>
>----------------------------------= --------------------------------------
>Peter=20 Strong
>Software Architect
>Nortel Networks - Optivity = Policy=20 Services (OPS) and NetID
>pestrong@nortelnetworks.com=20 <mailto:pestrong@nortelnetworks.com>
>(613)=20 831-6615
>
>
>
>
>
>
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce=20 Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applica= tions.com

--=_560FCE2D.1A7B48DC-- From list@netscape.com Fri Feb 18 14:03:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29282 for ; Fri, 18 Feb 2000 14:03: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 LAA11950; Fri, 18 Feb 2000 11:00:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA21689; Fri, 18 Feb 2000 11:02:37 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 11:02:37 -0800 (PST) Message-Id: <3.0.5.32.20000218110224.00973cb0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 18 Feb 2000 11:02:24 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"mb0ZyB.A.jSF.MdZr4"@glacier> 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:16 AM 2/18/00 -0700, Jim Sermersheim wrote: >>The intent is that an authentication process which uses X, Y, and >>Z schemes should use all values of scheme X, Y, and Z. > >So let's say a client performs a simple authentication and sends a clear text password to the server. Are you saying that if the server's authentication process uses X, Y, and Z schemes, it should hash the password with X, then challenge the result against all values of the X scheme, then apply this same process to the password using Y, and Z? Yes. >If so, what has to match for authentication to happen? I could imagine: 1) all values must match, 2) one value of each scheme has to match, 3) one value of any scheme has to match. 3. >>I intended was the later, user's password(s), I'll add some >>clarification and a security consideration. It's my intent >>is that this attribute be used instead of userPassword, >>userPassword allows multiple values. > >Bummer. This opens up security holes and makes the application of password policy difficult and bulky. I know userPassword allows multiple values, but I've never understood why. I'd like to understand what the reasons are before following the pattern. I believe the use or not of multiple passwords for one identity is a matter of policy not storage. The storage should allow for either policy to be implemented. It's my intent for this draft to be policy neutral. >>>If so, the client would (should) have to populate/re-populate each value in the attribute, right? >> >>Yes... or use a separated defined mechanism. Note, it is >>intended that password change be initiated by a client >>acting on behalf of the user (or the directory admin). > >Then I think the draft needs something in the implementation section that talks about this. It should reflect the notion that if a client changes one value of the authPassword attribute, and not all values, it will likely screw things up--depending on the server implementation. I'll have to chew on this a bit. I will, however, try to make a note stating the clients interacting directly with this attribute should aware of how servers make use of the attribute and that this may be policy driven. >In other words, with this draft, I see an opportunity to make the use of passwords more interoperable. I would like to see a good deal of implementation details in the draft that move us toward that end. The intent of the authpassword draft is to provide a storage mechanism to promote interoperbility between servers and management clients. The storage is designed to be independent of use (and policy). The intent of the passwd-exop draft is to provide a update mechanism to promote interoperability between user clients and servers. This update may be policy driven. The mechanism is designed to independent of storage. >>>It seems like this could be achieved in a much more secure >>and consistent way if there was a server side mechanism for creating and updating values of this attribute. >> >>I personally favor use of an extended operation to provide >>clients with consistent behavior irregardless of the >>storage used for passwords. I've introduced such in >>my passwd-exop draft, it may be used with userPassword, >>authPassword, and/or external password storage. Security, >>of course, is based on a number of factors. I generally >>recommend the clear separation of private/secret and public >>data. I prefer (when using password based authentication) >>external password storage like that provided by independent >>SASL service providors). > >Can you provide a reference to the passwd-exop draft in this draft? I'll provide a reference to the passwd-exop draft in a manner which does not depend this specification upon passwd-exop (again, passwd-exop is only one of many possible mechanisms). [In the end, I hope we can pick one update mechanism. I'm hoping to implement a couple of alternatives to gain operational experience with each]. From list@netscape.com Fri Feb 18 20:18:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04710 for ; Fri, 18 Feb 2000 20:18: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 RAA25795; Fri, 18 Feb 2000 17:13:32 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA04038; Fri, 18 Feb 2000 17:17:18 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 17:17:18 -0800 (PST) From: p2tendp@jena.de Message-ID: <00001feb78e6$0000049f$00004518@mailhost.moso.de> To: Subject: 50 Get your new Home Now! Date: Fri, 18 Feb 2000 16:53:56 -0800 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: seeya_1@canada.com X-Mailer: Eudoria Pro 5.0 Resent-Message-ID: <"EaRWCB.A.d-.c8er4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please visit the web site and select remove. Or if you would like you can just relpy with REMOVE in the subject line. Be sure and include the email address's that you would like to have removed in the body of the message. Thank You. SEND EMAIL SAVE A TREE! _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ You can now 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 New Home Purchase NO INCOME VERIFICATION The most competitive interest rates. GOOD CREDIT/BAD CREDIT It doesn't matter! Even BANKRUPCY! We can find a mortgage for your NEW home too! Fill in our quick pre-qualification form and you will get competitive quotes from three lenders. When lenders compete, you win! Visit this website: http://209.185.123.179/bin/redirector.cgi?http://3499894548/%7ez-mortgage?KC0217 -Save Time -Save Money -Save Aggravation There is NEVER any fee to consumers for using this service. This is for real, not like those other ones that offer free vacations. We are a highly respected service with a very reputable background just check out are web site and you will see the difference. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please visit the web site and select remove. From list@netscape.com Fri Feb 18 23:08:36 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07668 for ; Fri, 18 Feb 2000 23:08: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 UAA07795; Fri, 18 Feb 2000 20:03:38 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id UAA17039; Fri, 18 Feb 2000 20:07:21 -0800 (PST) Resent-Date: Fri, 18 Feb 2000 20:07:21 -0800 (PST) Message-Id: <3.0.5.32.20000218200706.009214f0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 18 Feb 2000 20:07:06 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt Cc: In-Reply-To: <3.0.5.32.20000218110224.00973cb0@infidel.boolean.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"gbF2wD.A.9JE.4bhr4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:02 AM 2/18/00 -0800, Kurt D. Zeilenga wrote: >I believe the use or not of multiple passwords for one identity >is a matter of policy not storage. The storage should allow >for either policy to be implemented. It's my intent for this >draft to be policy neutral. Note that enforcement of password change policy often requires knowledge of the current and new passwords. As updates via normal LDAP operations upon authPassword use hashed values, it is not possible for the server to enforce any content based password change policy. Servers which support such policies will need to disable update via normal LDAP commands and provide separate update mechanisms which provide the necessary content (the user's current and/or new password). passwd-exop provides such a mechanism. I add a comment regarding this to the draft. Kurt From list@netscape.com Sun Feb 20 13:47: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 NAA12094 for ; Sun, 20 Feb 2000 13:47: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 KAA24009; Sun, 20 Feb 2000 10:44:27 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA01868; Sun, 20 Feb 2000 10:46:24 -0800 (PST) Resent-Date: Sun, 20 Feb 2000 10:46:24 -0800 (PST) From: zzrtptc44@officina.net Message-Id: <200002201846.KAA03784@xwing.netscape.com> To: ietf-ldapext@netscape.com Subject: Your Platinum Free Vacation and Airline Tickets" Date: Sun, 20 Feb 2000 13:50:05 -0500 X-Sender: zzrtptc44@officina.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"2R0JIB.A.6c.-ZDs4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Platinum Travel Club Would Like To Offer You A Complimentary Vacation Of A Lifetime And Two Free Airline Tickets. Please click on http://www.platinumtravelclub.com or if you can not click on the link please simply visit our website at www.platinumtravelclub.com for Details Of How To Receive This Now. Please understand that this is a one time offer and Platinum Club will not resend this offer to you again. If you do not respond and you have received this message in error we apologize for the inconvenience and we would like to confirm that you will not receive this offer or any other offer from us again. Thank You. Code P.F.C.C.52598 From list@netscape.com Mon Feb 21 01:10: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 BAA18500 for ; Mon, 21 Feb 2000 01:10: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 WAA19510; Sun, 20 Feb 2000 22:07:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA02743; Sun, 20 Feb 2000 22:08:53 -0800 (PST) Resent-Date: Sun, 20 Feb 2000 22:08:53 -0800 (PST) Message-Id: <3.0.5.32.20000220214341.00924b70@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 20 Feb 2000 21:43:41 -0800 To: internet-drafts@ietf.org From: Bruce Greenblatt Subject: draft-greenblatt-ldap-certinfo-schema-02 Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_951140621==_" Resent-Message-ID: <"KsRtbB.A.jq.zZNs4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_951140621==_ Content-Type: text/plain; charset="us-ascii" I-D editor: please replace draft-greenblatt-ldap-certinfo-schema-01 with the following draft-greenblatt-ldap-certinfo-schema-02. 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 by using real OIDs that I finally got around to allocating. Enjoy... Comments welcomed. Bruce --=====================_951140621==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="cert-type-02a.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 February 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 the certificateType structural class to indicate that an object in the directory is a specific type of certificate. Each cer- tificateType object in the directory appears directly beneath the owner of the certificate 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. All OIDs defined in this draft are rooted from: 1.3.6.1.4.1.5515 1.3.6.1.4.1 has been assigned as IANA-registered Private Enterprises, and IANA has assigned 5515 to Directory Tools and Application Services, Inc. (DTASI). 1.3.6.1.4.1.5515.1 is the root OID for LDAP object class names, and 1.3.6.1.4.1.5515.2 is the root OID for LDAP attribute type names. ( 1.3.6.1.4.1.5515.1.1 NAME 'certificateType' SUP top STRUCTURAL MUST typeName MAY ( serialNumber $ issuer $ validityNotBefore $ vallidityNo- tAfter $ subject $ subjectPublicKeyInfo) certificateExtension $ other- Info ) ) The attributes are defined as follows: ( 1.3.6.1.4.1.5515.2.1 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. Greenblatt [Page 2] Internet Draft February 2000 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. ( 1.3.6.1.4.1.5515.2.2 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. ( 1.3.6.1.4.1.5515.2.3 NAME 'issuer' SUP distinguishedName SINGLE-VALUE ) ( 1.3.6.1.4.1.5515.2.4 NAME 'validityNotBefore' EQUALITY generalized- TimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 1.3.6.1.4.1.5515.2.5 NAME 'validityNotAfter' EQUALITY generalized- TimeMatch 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. ( 1.3.6.1.4.1.5515.2.6 NAME 'subject' SUP distinguishedName SINGLE-VALUE ) ( 1.3.6.1.4.1.5515.2.7 NAME 'subjectPublicKeyInfo' EQUALITY octetString- Match 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. Greenblatt [Page 3] Internet Draft February 2000 ( 1.3.6.1.4.1.5515.2.8 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. ( 1.3.6.1.4.1.5515.2.9 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. Greenblatt [Page 4] Internet Draft February 2000 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: 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. Greenblatt [Page 5] Internet Draft February 2000 [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 6] --=====================_951140621==_ Content-Type: text/plain; charset="us-ascii" ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=====================_951140621==_-- From list@netscape.com Mon Feb 21 05:05: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 FAA02019 for ; Mon, 21 Feb 2000 05:05: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 CAA00469; Mon, 21 Feb 2000 02:02:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id CAA10181; Mon, 21 Feb 2000 02:03:58 -0800 (PST) Resent-Date: Mon, 21 Feb 2000 02:03:58 -0800 (PST) Sender: vinnie@oasis.ireland.Sun.COM Message-ID: <38B10C91.F1ABAC11@Ireland.Sun.COM> Date: Mon, 21 Feb 2000 09:59:45 +0000 From: Vincent Ryan Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ldap@umich.edu, ietf-ldapext@netscape.com Subject: LDAP presentation format? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YVbDjB.A.zeC.N2Qs4"@glacier> 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 Processing a URL typically involves presenting the results as a data stream. In the case of an LDAP URL there are several available formats for such a data stream. For example, - text/directory MIME-type http://www.ietf.org/rfc/rfc2425.txt - DSML (XML) format http://www.dsml.org - LDIF file format http://www.ietf.org/internet-drafts/draft-good-ldap-ldif-05.txt I'm seeking responses from LDAP users and implementors on the relative merits of these 3 formats. In particular, I'm interested in determining which forms are widely supported in current or planned products. Thanks in advance. From list@netscape.com Mon Feb 21 05:53: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 FAA02339 for ; Mon, 21 Feb 2000 05:53: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 CAA01219; Mon, 21 Feb 2000 02:49:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id CAA19855; Mon, 21 Feb 2000 02:52:53 -0800 (PST) Resent-Date: Mon, 21 Feb 2000 02:52:53 -0800 (PST) Message-ID: <38B119A5.48707107@surfnet.nl> Date: Mon, 21 Feb 2000 11:55:33 +0100 From: Peter Valkenburg X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Ryan CC: ldap@umich.edu, ietf-ldapext@netscape.com Subject: Re: LDAP presentation format? References: <38B10C91.F1ABAC11@Ireland.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"SbxEIC.A.91E.EkRs4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi, > I'm seeking responses from LDAP users and implementors on the relative > merits of these 3 formats. In particular, I'm interested in determining > which forms are widely supported in current or planned products. FYI: We're working with some partners on an large scale LDAP indexing solution for research and academia: http://www.desire.org/html/research/workingpapers/index.html The index system is generic, and use HTTP as an internal transport system. For query responses it uses LDIF embedded in MIME. The MIME object type has been dubbed text/ldif. (yes, something ought to be registered here) -- Peter Valkenburg SURFnet Vincent Ryan wrote: > > Processing a URL typically involves presenting the results as a data > stream. > In the case of an LDAP URL there are several available formats for such > a > data stream. For example, > > - text/directory MIME-type > http://www.ietf.org/rfc/rfc2425.txt > > - DSML (XML) format > http://www.dsml.org > > - LDIF file format > http://www.ietf.org/internet-drafts/draft-good-ldap-ldif-05.txt > > I'm seeking responses from LDAP users and implementors on the relative > merits of these 3 formats. In particular, I'm interested in determining > which forms are widely supported in current or planned products. > > Thanks in advance. From list@netscape.com Tue Feb 22 06:39:20 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08697 for ; Tue, 22 Feb 2000 06:39: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 DAA19233; Tue, 22 Feb 2000 03:34:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA13819; Tue, 22 Feb 2000 03:38:10 -0800 (PST) Resent-Date: Tue, 22 Feb 2000 03:38:10 -0800 (PST) Message-Id: <200002221137.GAA08656@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-zeilenga-ldap-passwd-exop-01.txt Date: Tue, 22 Feb 2000 06:37:53 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"HFKdVB.A.gXD.hUns4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Password Modify Extended Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-passwd-exop-01.txt Pages : 6 Date : 21-Feb-00 The integration of LDAP [RFC2251] and external authentication services has introducted non-DN authentication identities and allowed for non- directory storage of passwords. As such, mechanisms which update the directory, such as Modify operation, cannot be used to change a user's password. This document describes an LDAP extended operation to allow allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-passwd-exop-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-zeilenga-ldap-passwd-exop-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-zeilenga-ldap-passwd-exop-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: <20000221120533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-passwd-exop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-passwd-exop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000221120533.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Feb 22 06:39:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08707 for ; Tue, 22 Feb 2000 06:39:25 -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 DAA22535; Tue, 22 Feb 2000 03:36:03 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA13750; Tue, 22 Feb 2000 03:38:03 -0800 (PST) Resent-Date: Tue, 22 Feb 2000 03:38:03 -0800 (PST) Message-Id: <200002221137.GAA08642@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-zeilenga-ldap-authpasswd-02.txt Date: Tue, 22 Feb 2000 06:37:48 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"IxqTn.A.kWD.ZUns4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Authentication Password Attribute Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-authpasswd-02.txt Pages : 9 Date : 21-Feb-00 This document describes schema for storing authentication passwords in a LDAP [RFC2251] directory. The document provides schema definitions for authPassword and related schema definitions. The authPassword is intended to used instead of clear text password storage mechanisms such as userPassword [RFC2256] to support simple bind operations. The attribute may be used to store SASL [RFC2222] authentication passwords in entries of a directory. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authpasswd-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-authpasswd-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-authpasswd-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000221115946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-authpasswd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-authpasswd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000221115946.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Feb 22 10:46:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13241 for ; Tue, 22 Feb 2000 10:46:13 -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 HAA05812; Tue, 22 Feb 2000 07:41:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA28082; Tue, 22 Feb 2000 07:44:58 -0800 (PST) Resent-Date: Tue, 22 Feb 2000 07:44:58 -0800 (PST) Message-ID: <38B2AF9C.FD9965DA@netscape.com> Date: Tue, 22 Feb 2000 07:47:40 -0800 From: rweltman@netscape.com (Rob Weltman) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: Changes to Java LDAP drafts Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"H7NzZC.A.e2G.47qs4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit   The Internet Drafts on a Java LDAP API have passed two last calls in this working group, but Steven Merrill at Novell has found a number of typos and inconsistencies that I think should be fixed before this leaves the working group. A summary follows. Comments appreciated.

Thanks,
Rob
 

java-api-09

4.3.5 LDAPAttributeSet

The return type of the two getAttribute() methods should be LDAPAttribute, not LDAPAttribute[]

--

The LDAPConstraints/LDAPConstraints parameter to many methods: what is the effect of passing null?

Default constraints

--

What if null is passed for DN where a valid DN is expected?

IllegalArgumentException

--

4.28.2 add

Missing convenience method
public void add(LDAPEntry entry) throws LDAPException

--

4.28.10 read

Missing method
public LDAPEntry read(String dn, String attrs[], LDAPConstraints cons) throws LDAPException

--

4.13.6 Error Codes

Should be Result Codes (because some codes returned by the server do not indicate an error)

--

4.24 LDAPSearchResults

Should say "implements Enumeration"

--

Where are NO_ATTRS and ALL_USER_ATTRS defined?

They should be defined in LDAPv2

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

java-api-asynch-ext-04

4.1.1 abandon
id             The ID of the operation to abandon. The ID may be
                obtained from the search listener for the operation.

It should say "from the listener for the operation", because it works with response listeners as well as with search listeners.

--

4.4 public abstract class LDAPResponse extends LDAPMessage

Should not be abstract

--

There should be an asynchronous version of extendedOperation()

--

There should be an asynchronous version of rename() - the variant that takes newParentDN as parameter

--

4.1.8 search

The second signature should take LDAPSearchConstraints rather than LDAPConstraints as argument
 
  From list@netscape.com Tue Feb 22 16:05: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 QAA23125 for ; Tue, 22 Feb 2000 16:04:59 -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 MAA19142; Tue, 22 Feb 2000 12:59:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA23871; Tue, 22 Feb 2000 13:03:43 -0800 (PST) Resent-Date: Tue, 22 Feb 2000 13:03:43 -0800 (PST) Date: Tue, 22 Feb 2000 15:03:28 -0600 From: Mark Wahl Subject: Re: ACL model comments In-reply-to: "Your message of Thu, 17 Feb 2000 14:06:34 EST." <38AC46BA.71EA48A4@netscape.com> Sender: Mark.Wahl@INNOSOFT.COM To: mcs@netscape.com (Mark C Smith) Cc: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Message-id: <7009.951253408@threadgill.austin.innosoft.com> Resent-Message-ID: <"UbjR7D.A.zzF.tmvs4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > I agree that the attribute type used to store access control information > should be operational. X.500's various access control attribute types > are defined with "USAGE directoryOperation" which seems right to me. I'd agree with that. This usually indicates that it is used by the directory service itself, is replicated with user attributes (not server specific), and may be modifiable oer protocol. > I admit that 'aci' was not a good name for Netscape to use, but I > suggest we use a name like 'ldapACI' for the new standard scheme to > avoid confusion (unless someone else is already using that name too!). I've seen aci, acl, subtreeacl, searchacl, but haven't seen ldapACL yet. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Feb 23 01:20:34 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04404 for ; Wed, 23 Feb 2000 01:20: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 WAA16660; Tue, 22 Feb 2000 22:14:26 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA09430; Tue, 22 Feb 2000 22:18:21 -0800 (PST) Resent-Date: Tue, 22 Feb 2000 22:18:21 -0800 (PST) From: 41f312b8a@fzkjhss.fzk.yamanashi.ac.jp DATE: 22 Feb 00 9:59:03 PM Message-ID: SUBJECT: >>> Cell Phone User Information <<< ijhyhh Resent-Message-ID: <"PecI4D.A.uSC.ru3s4"@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 Leading Researchers From Around The World Agree That Microwave Radiation From Cell Phones Is Directly Related To Certain Types Of Brain Cancer And The Destruction Of The Human Immune System. The WASHINGTON POST reports that preliminary results from research paid for by the cellular telephone industry suggests there may be a correlation between cell phone use and cancer. ABC NEWS Brian Ross is told by leading scientist that cell phones can no longer be presumed safe. THE DAILY MAIL urges cell phone users to cut their useage as a result of a cancer alert. BBC NEWS warns that radiation from mobile phones can severely damage the human immune system. THE IRISH TIMES headlines reads that Mobil Phones are linked to brain tumors. CBS NEWS correspondent Sandra Hughes says there are 100 million cell phone users putting their lives at risk due to cancer producing microwave radiation emitted from cell phones. !!!!!!!! A REMARKABLE NEW CELL PHONE DEVICE CALLED THE !!!!!!!! WAVE SHIELD BLOCKS UP TO 99% OF THE HARMFUL RADIATION EMITTED FROM CELL PHONES Test preformed by The American Society of Testing and Materials, and the Kansai Electrical Corporation, the leading testing authority in Japan, both confirm that the WAVE SHIELD blocks up to 99% of the harmful radiation emitted from cell phones. >>> THIS NEW TECHNOLOGY WILL PROTECT YOU FROM THE HARMFUL AND <<< POTENTIALlY DEADLY RADIATION EMITTED FROM YOUR CELL PHONE The WAVE SHIELD is a small shield about the size of a nickel that attaches to the ear piece of your cell phone in seconds and is hardly noticeable. The wave shield actually looks like part of your phone once it is secured. The Wave Shield is backed up by a million dollar product liability insurance policy. You know a product works when an insurance company is willing to place a million dollar liabiliy policy on the product. JUST $19.95 plus shipping and handling A SMALL PRICE TO PAY For The Peace Of Mind Knowing You Are Protected From Deadly Microwave Radiation. To be removed from this mailing list FAX your email address to: 1 800 546 3685. TO ORDER: Sorce Code CO-1000 FILL OUT THE ORDER FORM BELOW AND FAX TO: 1 303 341 9700 Quantity______ X $19.95 per Wave Shield = $___________ Florida Residents Add 6% sales tax = $___________ Shipping and Handling: US $3.95 for the first unit and $1.50 for each additional unit. International $6.95 for the first unit and $1.50 for each additional unit = $___________ TOTAL = $___________ Email address (Type Or Print Large and Clear Below) Name_____________________________________ Address________________________________________________________ Phone____________________ Master Card____ Visa____ American Express____ Discover____ Card Number __________ - _________ - _________ - __________ Expiration Date (MM-YYYY) _______________ The name on the credit card and the billing address must exactly match that for the credit card or the order will not be processed Signature ____________________________________ Date ____________ You may also order by phone 1 800 242 0363 ext. 1407 From list@netscape.com Wed Feb 23 03:17:05 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16558 for ; Wed, 23 Feb 2000 03:17: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 AAA23280; Wed, 23 Feb 2000 00:11:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA01761; Wed, 23 Feb 2000 00:15:03 -0800 (PST) Resent-Date: Wed, 23 Feb 2000 00:15:03 -0800 (PST) From: morpheus@zyluss.com Date: Wed, 23 Feb 2000 00:14:54 -0800 (PST) Message-Id: <200002230814.AAA06034@xwing.netscape.com> Reply-To: morpheus@zyluss.com To: morpheus@zyluss.com Subject: Greatest collection of software ever made on 1 CD! Resent-Message-ID: <"3Fh5ND.A.Ua.Fc5s4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Are you tired of spending long hours on the internet downloading that new software you have been looking for? Well, there is a solution. Try out the all new "SUPER SOFTWARE CD!" This CD is compiled from the very latest and up-to-date software libraries available today. All software contained on this one CD was chosen from only the HIGHEST RATED and THE MOST POPULAR shareware/freeware titles that can be found anywhere! There is no doubt that THIS IS THE BEST SOFTWARE CD YOU WILL FIND ANYWHERE! This single CD contains well over 200 different high-quality programs and over 700 megabytes of information AND includes FREE browsing software with title indexing and top-notch evaluations of every single program that has been put on this CD. This CD contains some of the most popular software titles such as: 32bit Fax v9.12.01 Air Warrior II Acrobat Reader (32-bit) v4.05 Aquarium Screen Saver v2.5 Applet Button Factory v5.0 Atom Time v2.1b BCM Diagnostics for Win95 v1.01.02 Bikini Screen Saver Bikini Solitaire Bud Ice Screen Saver v12.13.96 Budweiser Lizards Screen Saver CDRWin v3.7d Command AntiVirus for Windows 95/98 v4.57.1 Cult v1.24 Corkboard v1.00.092 CuteFTP (32-bit) v3.5 Duke Nukem 3D v1.3d Easy Bridge v3.2 EasyZip 2000 v4.5 Elephant Walk Theme Font FX Express v2.5 Go!Zilla v3.5 Hey, Macaroni! v2.0 Holy Bible King James Version v5.1.2 HotDog Professional (32-bit) v5.5 ICQ (32-bit) v99b Microsoft Internet Explorer (Full Install) v5.0 Jedi-Knight - Dark Forces II Kama Sutra for WIndows v1.0 McAfee VirusScan for Windows 95/98 v4.0.3 Microsoft DirectX Drivers v7.0 Microsoft Windows Media Player v6.0 mIRC (32-bit) v5.61 MOPy Fish v1.9 MoreJongg v7.0 Netscape Communicator (32-bit Full Install) v4.7 Norton AntiVirus for Windows 95/98 v5.3.0.25 Norton Utilities 2000 v4.5 PKZIP for Windows (32-bit) v2.70 PKZIP for DOS v2.50 Princess Diana Tribute Screen Saver v1.0 Pro Pinball Timeshock! Quake - The Doomed Dimension v1.06 Quake II RealPlayer G2 Star Wars Episode I - Racer v1.0 Star Wars, Shadows of the Empire Swimsuit Screen Saver v1.52 Titanic Screen Saver Ulead Cool 3D v3.5 Winamp (Complete) v2.5e WinZip (32-bit) v7.0 SR-1 WinZip for Windows 3.1x v6.3 WS_FTP Professional ...................and that's just the tip of the iceberg! There is a total of 225 different top-quality programs from only the best software writers of today! Do yourself a big favor and avoid all of the hassles of downloading those lengthy and time consuming software programs! Purchase our CD and get all of todays latest and most popular software titles on one easy, convenient, power-packed, 700MB CD. Can you imagine how long it would take you to download 700MB of information at 56K? Try about 210 HOURS!!!!!!!!!! That's about 9 FULL DAYS of non-stop downloading!!!!!!! The solution is simple ---- PURCHASE THE "SUPER SOFTWARE CD" and save yourself a lot of headache! Name:_____________________________ Address:___________________________ Address:___________________________ City:______________________________ State/Province:_____________________ Country:___________________________ Number of CD's I am ordering:__________ Cost per CD: $8.95 (Payment MUST be in US funds ONLY) Shipping/Handling: $4.00 (for up to 5 CD's) (Please add $1.00 extra for each CD that exceeds quantity 5) Please make funds payable to "Morpheus Software" and send payment to: Morpheus Software P.O. Box 280207 Memphis, TN 38168-0207 USA ALL ORDERS WILL BE PROCESSED IMMEDIATELY UPON RECEIPT OF PAYMENT. THANK YOU FOR YOUR ORDER!!!!!!! From list@netscape.com Wed Feb 23 09:54:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23244 for ; Wed, 23 Feb 2000 09:54: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 GAA21510; Wed, 23 Feb 2000 06:48:56 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA18551; Wed, 23 Feb 2000 06:52:46 -0800 (PST) Resent-Date: Wed, 23 Feb 2000 06:52:46 -0800 (PST) Sender: michael@ms.inka.de Message-ID: <38B3F446.14816196@inka.de> Date: Wed, 23 Feb 2000 15:52:54 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Organization: at Home X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i586) X-Accept-Language: de, en MIME-Version: 1.0 To: Vincent Ryan Cc: ldap@umich.edu, ietf-ldapext@netscape.com Subject: Re: [ldap] LDAP presentation format? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"U9sH1C.A.khE.9Q_s4"@glacier> 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 Vincent Ryan wrote: > > - text/directory MIME-type > http://www.ietf.org/rfc/rfc2425.txt > > - DSML (XML) format > http://www.dsml.org > > - LDIF file format > http://www.ietf.org/internet-drafts/draft-good-ldap-ldif-05.txt > > I'm seeking responses from LDAP users and implementors on the relative > merits of these 3 formats. In particular, I'm interested in determining > which forms are widely supported in current or planned products. IMHO LDIF is widely used. To me text/directory looks not very handy and DSML looks very promising (XML parsers can be used, easy transformation to HTML). I will dig into that and probably implement DSML download in http://web2ldap.de/. Ciao, Michael. From list@netscape.com Thu Feb 24 02:28:42 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24053 for ; Thu, 24 Feb 2000 02:28: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 XAA07527; Wed, 23 Feb 2000 23:19:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id XAA08816; Wed, 23 Feb 2000 23:22:55 -0800 (PST) Resent-Date: Wed, 23 Feb 2000 23:22:55 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 23 Feb 2000 18:11:59 -0700 From: "Jim Sermersheim" To: Subject: matchedValues control Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"ex1DDC.A.eJC.NxNt4"@glacier> 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 CAA24053 There was a discussion last July - October around returning only the values of attributes that match the search filter. I know there were some sticky problems with complex filters, is anyone working on this (i.e. defining a control)? Jim From list@netscape.com Thu Feb 24 06:23:51 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25637 for ; Thu, 24 Feb 2000 06:23:50 -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 DAA19310; Thu, 24 Feb 2000 03:20:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA18843; Thu, 24 Feb 2000 03:22:32 -0800 (PST) Resent-Date: Thu, 24 Feb 2000 03:22:32 -0800 (PST) Sender: Sean.Mullan@Ireland.Sun.COM Message-ID: <38B51472.461ADAF1@sun.com> Date: Thu, 24 Feb 2000 11:22:26 +0000 From: Sean Mullan X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapext@netscape.com Subject: Re: matchedValues control References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FSi52C.A.FmE.3RRt4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Jim, The consensus of the group seemed to be that the MVO control was too difficult to implement with complex filters and that a different control was preferable, one which allowed you to filter the returned values after the search. David Chadwick and I (co-authors of MVO draft) were planning to write a new draft describing the new control sometime in the next month or so. --Sean Jim Sermersheim wrote: > > There was a discussion last July - October around returning only the values of attributes that match the search filter. I know there were some sticky problems with complex filters, is anyone working on this (i.e. defining a control)? > > Jim From list@netscape.com Thu Feb 24 20:35: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 UAA13978 for ; Thu, 24 Feb 2000 20:35: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 RAA27391; Thu, 24 Feb 2000 17:31:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA28273; Thu, 24 Feb 2000 17:33:42 -0800 (PST) Resent-Date: Thu, 24 Feb 2000 17:33:42 -0800 (PST) Message-Id: <3.0.5.32.20000224173135.00926b30@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 24 Feb 2000 17:31:35 -0800 To: "Sukanta Ganguly" , From: Bruce Greenblatt Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt Cc: "Mark Meredith" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"tz2OnD.A.G5G.1vdt4"@glacier> 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 understand that you don't want to look the information up in SNMP. But, why not? It's already there, and SNMP is pretty lightweight (simple even). Do we really want to duplicate this vendor information in several places? It could just as easily be added to SRV records in DNS? What about all of the other informaiton in RFC 2248 and RFC 2605? Do you want to plop that into the RootDSE as well? Bruce At 10:49 AM 2/18/00 -0700, Sukanta Ganguly wrote: > It is very difficult and unclear at this point whether we should assume >that all Internet Directory Client are in the position to talk different >Internet protocols. Instead of assuming that the Directory Client will talk >SNMP and query the MIB for getting the vendor specific information, why >can't we state that the Directory Client queries the rootDSE for the >information and the implementation would determine whether to go to the >SNMP MIB for the information or to have the vendor specific information, >requested by Mark, within the Directory Repository. I think it will >bring in more value to have the access to the information through the >rootDSE but at the same time leave the invididual implementations to >handle them. We all agree, based on the emails that I have seen flowing >around related to this matter, that the information is useful so why not >provide the flexibility. Thanks Sukanta Ganguly sganguly@novell.com > >>>><>>>> >At 09:13 AM 2/18/00 -0500, Peter Strong wrote: >> >>> >>> >>> To be blunt, I don't believe that there is much use for this draft. >> >>For those of us who attempt to build applications that work with >>multiple directory implementations, this information is very useful. >> > > I said that > Get it from there, since that is > I don't see much point in duplicating this > In my opinion, a good internet directory client will get >information from a variety of internet servers: DNS, LDAP, SNMP, and others. > >>> The information that it proposes to add to the Root DSE is already >>> published is >>> The >>> I think that this draft >>> should just point to RFC 2248 (and perhaps 2605) and explain where the >>> These are already standards track >>> documents, and have places to put the information that this draft defines. >>> (Just my $0.02 worth) >> >>The products we build are LDAP clients, not SNMP clients. >> >>This information should be available via LDAP. >> >>> >>> Bruce >>> ============================================== >>> Bruce Greenblatt, Ph. D. >>> Directory Tools and Application Services, Inc. >>> http://www.directory-applications.com >>> >> >>------------------------------------------------------------------------ >>Peter Strong >>Software Architect >>Nortel Networks - Optivity Policy Services (OPS) and NetID >><> >>(613) 831-6615 >> >> >> >> >> >> >============================================== >Bruce Greenblatt, Ph. D. >Directory Tools and Application Services, Inc. >http://www.directory-applications.com > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Fri Feb 25 06:33:37 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05159 for ; Fri, 25 Feb 2000 06:33: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 DAA09439; Fri, 25 Feb 2000 03:30:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA18841; Fri, 25 Feb 2000 03:32:24 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 03:32:24 -0800 (PST) Message-Id: <200002251132.GAA05032@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-x509-sasl-03.txt Date: Fri, 25 Feb 2000 06:32:19 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"yPdcU.A.HmE.Hhmt4"@glacier> 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 : X.509 Authentication SASL Mechanism Author(s) : S. Kille Filename : draft-ietf-ldapext-x509-sasl-03.txt Pages : 10 Date : 24-Feb-00 This document defines a SASL [1] authentication mechanism based on X.509 strong authentication [3], providing two way authentication. This mechanism is only for authentication, and has no effect on the protocol encodings and is not designed to provide integrity or confidentiality services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-x509-sasl-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-x509-sasl-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-x509-sasl-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000224111702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-x509-sasl-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-x509-sasl-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224111702.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Fri Feb 25 07:38: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 HAA06231 for ; Fri, 25 Feb 2000 07:38: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 EAA05319; Fri, 25 Feb 2000 04:33:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id EAA27238; Fri, 25 Feb 2000 04:37:09 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 04:37:09 -0800 (PST) From: HomeLoans@ns-3.fsnet.co.uk Date: Thu, 24 Feb 00 16:56:22 EST To: H0MEL0ANS@bigfoot.com Subject: Home Loans & Refinancing Available Message-ID: <> Resent-Message-ID: <"z6I42.A.UpG.0dnt4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com You can now 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 find out how much of a loan you would qualify for. Visit this website: http://3633144587/homeloan/?SP0219 (If link doesn't come right up, try again later) -Save Time -Save Money -Save Aggravation There is NEVER any fee to consumers for using this service. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From list@netscape.com Fri Feb 25 09:15: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 JAA08277 for ; Fri, 25 Feb 2000 09:15: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 GAA19049; Fri, 25 Feb 2000 06:11:51 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA14086; Fri, 25 Feb 2000 06:13:54 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 06:13:54 -0800 (PST) Message-ID: <01E1D01C12D7D211AFC70090273D20B10139D936@sothmxs06.entrust.com> From: Mike Just To: "'internet-drafts@ietf.org'" , "'LDAPExt'" Cc: "'Jim Sermersheim'" , "'Mark Smith'" , Kristianne Leclair Subject: draft-just-ldapv3-rescodes-01.txt Date: Fri, 25 Feb 2000 09:13:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF7F9A.84038EA0" Resent-Message-ID: <"uSdpxC.A.0bD.g4ot4"@glacier> 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_01BF7F9A.84038EA0 Content-Type: text/plain; charset="iso-8859-1" Please publish this second draft of our document entitled "LDAPv3 Result Codes: Definitions and Appropriate Use". Comments on this draft would be greatly appreciated. Changes from -00 include the addition of the following sections: - Sections 1.1 which describes the relationship to X.500; - Section 3 which overviews the draft contents; and - Section 6.1 which indicates the result codes applicable to all operations. In addition, there were several smaller changes. Mike Just ---------------------------------------- Abstract: The purpose of this document is to describe, in some detail, the meaning and use of the result codes used with the LDAPv3 protocol. Of particular importance are the error codes, which represent the majority of the result codes. This document provides definitions for each result code, and outlines the expected behaviour of the various operations with respect to how result codes and in particular, error conditions should be handled and which specific error code should be returned. It is hoped that this document will facilitate interoperability between clients and servers and the development of intelligent LDAP clients capable of acting upon the results received from the server. <> ------_=_NextPart_000_01BF7F9A.84038EA0 Content-Type: text/plain; name="draft-just-ldapv3-rescodes-01.txt" Content-Disposition: attachment; filename="draft-just-ldapv3-rescodes-01.txt" Content-Transfer-Encoding: quoted-printable Internet Draft Mike Just, Entrust K. Leclair, Entrust Jim Sermersheim, Novell Mark Smith, Netscape Document: February, 2000 Category: Standards Track LDAPv3 Result Codes: Definitions and Appropriate Use Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. 1. Abstract The purpose of this document is to describe, in some detail, the meaning and use of the result codes used with the LDAPv3 protocol. Of particular importance are the error codes, which represent the majority of the result codes. This document provides definitions = for each result code, and outlines the expected behaviour of the various operations with respect to how result codes and in particular, error conditions should be handled and which specific error code should be returned. It is hoped that this document will facilitate interoperability between clients and servers and the development of intelligent LDAP clients capable of acting upon the results received from the server. 1.1 Relationship to X.500 The LDAPv3 RFC [RFC2251] states that "An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface." This means that there are two types of LDAP Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 1 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 servers, those that act as a front end to an X.500 directory, and stand alone LDAP servers which use some other form of repository as the back end. Because of differences between X.500 and LDAP there may be some differences in behaviour between LDAP-only servers and LDAP servers that act as front ends to X.500 DSAs. One such difference is the definition of specific access controls for X.500. X.500 defines the discloseOnError permission, an access control parameter for which there is currently no equivalent defined for LDAP. If an LDAP server is acting as a front end to an X.500 DSA then it may return noSuchObject when the target entry is found but the client does not have permission to view or modify the entry. Unless the server implements X.500 style access controls LDAP-only servers should only return noSuchObject when the target entry is not found until such time that similar access controls are defined for LDAP only servers. Because the client may not know what sort of LDAP server it is communicating with it should not rely on the behaviour of the server in this respect. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Overview This document collects and refines the definitions and descriptions for LDAPv3 result codes, as found in a variety of sources (see Section 8). In some cases, material from these sources was absent, inadequate or ambiguous. It is the hope of this document to present consistent definitions and descriptions of LDAPv3 result codes. This document consists of two major sections facilitating = information searches based on either a particular result code, or LDAP = operation. Section 5 presents a glossary for the result codes. Firstly, each = is classified as either an erroneous or non-erroneous result. The erroneous results, or error codes, are further classified based on the types of error codes defined in X.511 [X511]. Some reclassification was performed where appropriate. For each result code, a definition, and list of operations that could return this code are given. In addition, Section 5.3 specifies error = precedence, based on error type, as given in X.511 [X511]. Section 6 describes, for each operation, the result codes that could be returned for that operation. Firstly, Section 6.1 enumerates those result codes that are applicable to all operations. Within each remaining section (which is specific to each operation), the error codes are ordered as to the precedence of their parent type, = as specified in Section 5.3. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 2 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 Also, Appendix A (Section 11) presents a simple matrix that = indicates valid operation/result code pairs in LDAPv3. 4. Table of Contents 1. Abstract........................................................1 1.1 Relationship to X.500...........................................1 2. Conventions used in this document...............................2 3. Overview........................................................2 4. Table of Contents...............................................3 5. Result Codes in LDAPv3..........................................5 5.1 Description of Non-Erroneous Result Codes.......................6 5.1.1 success(0)...................................................6 5.1.2 compareFalse(5)..............................................6 5.1.3 compareTrue(6)...............................................6 5.1.4 referral(10).................................................7 5.1.5 saslBindInProgress(14).......................................7 5.2 Description of Error Codes......................................7 5.2.1 General Error Codes..........................................7 5.2.1.1 operationsError(1).......................................7 5.2.1.2 protocolError(2).........................................8 5.2.1.3 other(80)................................................8 5.2.2 Specific Error Codes.........................................8 5.2.2.1 Attribute Problem Error Codes............................8 5.2.2.1.1 noSuchAttribute(16)...................................8 5.2.2.1.2 undefinedAttributeType(17)............................8 5.2.2.1.3 inappropriateMatching(18).............................9 5.2.2.1.4 constraintViolation(19)...............................9 5.2.2.1.5 attributeOrValueExists(20)............................9 5.2.2.1.6 invalidAttributeSyntax(21)............................9 5.2.2.2 NameProblem Error Codes..................................9 5.2.2.2.1 noSuchObject(32)......................................9 5.2.2.2.2 aliasProblem(33).....................................10 5.2.2.2.3 invalidDNSyntax(34)..................................10 5.2.2.2.4 aliasDereferencingProblem(36)........................10 5.2.2.3 SecurityProblem Error Codes.............................10 5.2.2.3.1 authMethodNotSupported(7)............................10 5.2.2.3.2 strongAuthRequired(8)................................10 5.2.2.3.3 confidentialityRequired(13)..........................11 5.2.2.3.4 inappropriateAuthentication(48)......................11 5.2.2.3.5 invalidCredentials(49)...............................11 5.2.2.3.6 insufficientAccessRights(50).........................11 5.2.2.4 ServiceProblem Error Codes..............................12 5.2.2.4.1 timeLimitExceeded(3).................................12 5.2.2.4.2 sizeLimitExceeded(4).................................12 5.2.2.4.3 adminLimitExceeded(11)...............................12 5.2.2.4.4 unavailableCriticalExtension(12).....................12 5.2.2.4.5 busy(51).............................................13 5.2.2.4.6 unavailable(52)......................................13 5.2.2.4.7 unwillingToPerform(53)...............................13 5.2.2.4.8 loopDetect(54).......................................13 5.2.2.5 UpdateProblem Error Codes...............................13 5.2.2.5.1 namingViolation(64)..................................14 Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 3 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 5.2.2.5.2 objectClassViolation(65).............................14 5.2.2.5.3 notAllowedOnNonLeaf(66)..............................14 5.2.2.5.4 notAllowedOnRDN(67)..................................14 5.2.2.5.5 entryAlreadyExists(68)...............................14 5.2.2.5.6 objectClassModsProhibited(69)........................15 5.2.2.5.7 affectsMultipleDSAs(71)..............................15 5.3 Error Precedence...............................................15 6 LDAP Operations.................................................15 6.1 Common Result Codes............................................16 6.1.1 Non-erroneous results.......................................16 6.1.2 Security Errors.............................................16 6.1.3 Service Errors..............................................16 6.1.4 General Errors..............................................17 6.2 Bind Operation Errors..........................................17 6.2.1 Non-erroneous results.......................................17 6.2.2 Name Errors.................................................17 6.2.3 Security Errors.............................................17 6.3 Search Operation Errors........................................17 6.3.1 Name Errors.................................................18 6.3.2 Attribute Errors............................................18 6.3.3 Security Errors.............................................18 6.3.4 Service Errors..............................................18 6.4 Modify Operation Errors........................................19 6.4.1 Name Errors.................................................19 6.4.2 Update Errors...............................................19 6.4.3 Attribute Errors............................................19 6.4.4 Security Errors.............................................20 6.5 Add Operation Errors...........................................20 6.5.1 Name Errors.................................................20 6.5.2 Update Errors...............................................20 6.5.3 Attribute Errors............................................20 6.5.4 Security Errors.............................................21 6.6 Delete Operation Errors........................................21 6.6.1 Name Errors.................................................21 6.6.2 Update Errors...............................................21 6.6.3 Security Errors.............................................21 6.7 ModifyDN Operation Errors......................................21 6.7.1 Name Errors.................................................22 6.7.2 Update Errors...............................................22 6.7.3 Attribute Errors............................................22 6.7.4 Security Errors.............................................23 6.8 Compare Operation Errors.......................................23 6.8.1 Name Errors.................................................23 6.8.2 Attribute Errors............................................23 6.8.3 Security Errors.............................................23 6.8.4 Example.....................................................24 6.9 Extended Operation Errors......................................24 6.10 Operations with no Server Response............................25 6.11 Unsolicited Notification......................................25 7. Security Considerations........................................25 8. References.....................................................25 9. Acknowledgments................................................26 10. Author's Addresses............................................26 11 Appendix A: Operation/Response Matrix..........................27 Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 4 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 12 Full Copyright Statement.......................................29 5. Result Codes in LDAPv3 In this section, a glossary of the result codes that may be returned from a server to a client is provided. This section is meant to provide a central, unified source for these definitions. RFC 2251 [RFC2251] and X.511 [X511] were primary sources, forming the basis for the definitions given in this section. LDAP v3 [RFC2251] defines the following result message for return from the server to the client, where =91 =91new=92 =92 indicates those codes that were not used in LDAP v2. LDAPResult ::=3D SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), -- 9 reserved -- referral (10), -- new adminLimitExceeded (11), -- new unavailableCriticalExtension (12), -- new confidentialityRequired (13), -- new saslBindInProgress (14), -- new noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), -- 22-31 unused -- noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), -- 35 reserved for undefined isLeaf -- aliasDereferencingProblem (36), -- 37-47 unused -- inappropriateAuthentication (48), invalidCredentials (49), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), -- 55-63 unused -- namingViolation (64), objectClassViolation (65), Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 5 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), objectClassModsProhibited (69), -- 70 reserved for CLDAP -- affectsMultipleDSAs (71), -- new -- 72-79 unused -- other (80) }, -- 81-90 reserved for APIs -- matchedDN LDAPDN, errorMessage LDAPString, referral [3] Referral OPTIONAL } If a client receives a result code that is not listed above, it is = to be treated as an unknown error condition. The LDAP result includes an errorMessage field, which may, at the server's option, be used to return a string containing a textual, human-readable error diagnostic. As this error diagnostic is not standardized, implementations MUST NOT rely on the values returned. If the server chooses not to return a textual diagnostic, the errorMessage field of the LDAPResult type MUST contain a zero length string. In the following subsections, definitions for each result code are provided. In addition, the operations that may return each result code are also identified. The set of all operations consists of the following: Bind; Search; Modify; Add; Delete; ModifyDN; Extended; = and Compare. 5.1 Description of Non-Erroneous Result Codes Five result codes that may be returned in LDAPResult are not used to indicate an error. These result codes are listed below. The first three codes, indicate to the client that no further action is required in order to satisfy their request. In contrast, the last two errors require further action by the client in order to complete their original operation request. 5.1.1 success(0) Applicable operations: all except for Compare. This result code does not indicate an error. It is returned when the client operation completed successfully. 5.1.2 compareFalse(5) Applicable operations: Compare. This result code does not indicate an error. It is used to indicate that the result of a Compare operation is FALSE. 5.1.3 compareTrue(6) Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 6 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 Applicable operations: Compare. This result code does not indicate an error. It is used to indicate that the result of a Compare operation is TRUE. 5.1.4 referral(10) Applicable operations: all. This result code is new in LDAPv3. Rather than indicating an error, this result code is used to indicate that the server does not hold the target entry of the request but is able to provide alternative servers that may. A set of server(s) URLs may be returned in the referral field, which the client may subsequently query to attempt = to complete their operation. 5.1.5 saslBindInProgress(14) Applicable operations: Bind. This result code is new in LDAPv3. This result code is not an error response from the server, but rather, is a request for bind continuation. The server requires the client to send a new bind request, with the same SASL mechanism, to continue the = authentication process [RFC2251, Section 4.2.3]. 5.2 Description of Error Codes General error codes (see Section 5.2.1) are typically returned only when no suitable specific error exists. Specific error codes (see Section 5.2.2) are meant to capture situations that are specific to the requested operation. 5.2.1 General Error Codes A general error code typically specifies an error condition for = which there is no suitable specific error code. If the server can return = an error, which is more specific than the following general errors, = then the specific error should be returned instead. 5.2.1.1 operationsError(1) Applicable operations: all. This error code is returned when the server encounters an internal error and is unable to respond with a more specific result code, as = a result of this internal error. This may occur, for example, if sufficient memory to handle a request cannot be allocated by the server. Note that an operationsError indicates that the server is unable to properly respond to a request, but does not indicate that the client has sent an erroneous message. For example, in the case that a Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 7 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 malformed request is received and the server does not experience an internal error, a protocol error should be returned (see Section 5.2.1.2). 5.2.1.2 protocolError(2) Applicable operations: all. A protocol error should be returned by the server when an invalid or malformed request is received from the client. This may be a request that is not recognized as an LDAP request, for example, if a nonexistent operation were specified in LDAPMessage. As well, it = may be the result of a request that is missing a required parameter, = such as a search filter in a search request. If the server can return an error, which is more specific than protocolError, then this error should be returned instead. For example if the server does not recognize the authentication method requested by the client then the error authMethodNotSupported should be returned instead of protocolError. The server may return details of the error in the error string. 5.2.1.3 other(80) Applicable operations: all. This error code should be returned only if no other error code is suitable. Use of this error code should be avoided if possible. Details of the error should be provided in the error message. 5.2.2 Specific Error Codes Specific errors are used to indicate that a particular type of error has occurred. These error types are Name, Update, Attribute, Security, and Service. 5.2.2.1 Attribute Problem Error Codes An attribute error reports a problem related to an attribute specified by the client in their request message. 5.2.2.1.1 noSuchAttribute(16) Applicable operations: Modify, Compare. This error may be returned if the attribute specified as an argument of the operation does not exist in the entry. 5.2.2.1.2 undefinedAttributeType(17) Applicable operations: Modify, Add. This error may be returned if the specified attribute is = unrecognized by the server, since it is not present in the server=92s defined schema. If the server doesn=92t recognize an attribute specified in = a Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 8 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 search request as the attribute to be returned the server should not return an error in this case - it should just return values for the requested attributes it does recognize. Note that this result code only applies to the Add and Modify operations [X.511, Section 12.4]. 5.2.2.1.3 inappropriateMatching(18) Applicable operations: Search. An attempt was made, e.g., in a filter, to use a matching rule not defined for the attribute type concerned [X511, Section 12.4]. 5.2.2.1.4 constraintViolation(19) Applicable operations: Modify, Add, ModifyDN. This error should be returned by the server if an attribute value specified by the client violates the constraints placed on the attribute as it was defined in the DSA - this may be a size constraint or a constraint on the content. 5.2.2.1.5 attributeOrValueExists(20) Applicable operations: Modify, Add. This error should be returned by the server if the value specified = by the client already exists within the attribute. 5.2.2.1.6 invalidAttributeSyntax(21) Applicable operations: Modify, Add. This error should be returned by the server if the attribute syntax for the attribute value, specified as an argument of the operation, is unrecognized or invalid. 5.2.2.2 NameProblem Error Codes A name error reports a problem related to the distinguished name provided as an argument to an operation [X511, Section 12.5]. For result codes of noSuchObject, aliasProblem, invalidDNSyntax and aliasDereferencingProblem, the matchedDN field is set to the name of the lowest entry (object or alias) in the directory that was = matched. If no aliases were dereferenced while attempting to locate the = entry, this will be a truncated form of the name provided, or if aliases were dereferenced, of the resulting name, as defined in section 12.5 of X.511 [X511]. The matchedDN field is to be set to a zero length string with all other result codes [RFC2251, Section 4.1.10]. 5.2.2.2.1 noSuchObject(32) Applicable operations: all except for Bind. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 9 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 This error should only be returned if the target object cannot be found. For example, in a search operation if the search base can not be located in the DSA the server should return noSuchObject. If, however, the search base is found but does not match the search filter, success, with no resultant objects, should be returned instead of noSuchObject. If the LDAP server is a front end for an X.500 DSA then noSuchObject may also be returned if discloseOnError is not granted for an entry and the client does not have permission to view or modify the entry. 5.2.2.2.2 aliasProblem(33) Applicable operations: Search. An alias has been dereferenced which names no object [X511, Section 12.5]. 5.2.2.2.3 invalidDNSyntax(34) Applicable operations: all. This error should be returned by the server if the DN syntax is incorrect. It should not be returned if the DN is correctly formed but represents an entry which is not permitted by the structure = rules at the DSA; in this case namingViolation should be returned instead. 5.2.2.2.4 aliasDereferencingProblem(36) Applicable operations: Search. An alias was encountered in a situation where it was not allowed or where access was denied [X511, Section 12.5]. For example, if the client does not have read permission for the aliasedObjectName attribute and its value then the error aliasDereferencingProblem should be returned. [X511, Section 7.11.1.1] 5.2.2.3 SecurityProblem Error Codes A security error reports a problem in carrying out an operation for security reasons [X511, Section 12.7]. 5.2.2.3.1 authMethodNotSupported(7) Applicable operations: Bind. This error code should be returned if the client requests, in a Bind request, an authentication method which is not supported or recognized by the server. 5.2.2.3.2 strongAuthRequired(8) Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 10 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 Applicable operations: all. This error may be returned on a bind request if the server only accepts strong authentication or it may be returned when a client attempts an operation which requires the client to be strongly authenticated - for example Delete. This result code may also be returned in an unsolicited notice of disconnection if the server detects that an established underlying security association protecting communication between the client and server has unexpectedly failed or been compromised. [RFC2251, = Section 4.4.1] 5.2.2.3.3 confidentialityRequired(13) Applicable operations: all. This error code is new in LDAPv3. This error code may be returned if the session is not protected by a protocol which provides session confidentiality. For example, if the client did not establish a TLS connection using a cipher suite which provides confidentiality of = the session before sending any other requests, and the server requires session confidentiality then the server may reject that request with a result code of confidentialityRequired. 5.2.2.3.4 inappropriateAuthentication(48) Applicable operations: Bind. This error should be returned by the server when the client has = tried to use a method of authentication that is inappropriate, that is a method of authentication which the client is unable to use = correctly. In other words, the level of security associated with the = requestor=92s credentials is inconsistent with the level of protection requested, e.g. simple credentials were supplied while strong credentials were required [X511, Section 12.7]. 5.2.2.3.5 invalidCredentials(49) Applicable operations: Bind. This error code is returned if the DN or password used in a simple bind operation is incorrect, or if the DN or password is incorrect for some other reason, e.g. the password has expired. This result code only applies to Bind operations -- it should not be returned = for other operations if the client does not have sufficient permission = to perform the requested operation - in this case the return code = should be insufficientAccessRights. 5.2.2.3.6 insufficientAccessRights(50) Applicable operations: all except for Bind. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 11 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 The requestor does not have the right to carry out the requested operation [X511, Section 12.7]. 5.2.2.4 ServiceProblem Error Codes A service error reports a problem related to the provision of the service [X511, Section 12.8]. 5.2.2.4.1 timeLimitExceeded(3) Applicable operations: all. This error should be returned when the time to perform an operation has exceeded either the time limit specified by the client (which = may only be set by the client in a search operation) or the limit specified by the server. If the time limit is exceeded on a search operation then the result is an arbitrary selection of the accumulated results [X511, Section 7.5]. Note that an arbitrary selection of results may mean that no results are returned to the client. If the LDAP server is a front end for an X.500 server, any operation that is chained may exceed the timelimit, therefore clients can expect to receive timelimitExceeded for all operations. For stand alone LDAP-Servers that do not implement chaining it is unlikely = that operations other than search operations will exceed the defined timelimit. 5.2.2.4.2 sizeLimitExceeded(4) Applicable operations: Search. This error should be returned when the number of results generated = by a search exceeds the maximum number of results specified by either the client or the server. If the size limit is exceeded then the results of a search operation will be an arbitrary selection of the accumulated results, equal in number to the size limit [X511, = Section 7.5]. 5.2.2.4.3 adminLimitExceeded(11) Applicable operations: all. This error code is new in LDAPv3. The server has reached some limit set by an administrative authority, and no partial results are available to return to the user [X511, Section 12.8]. For example, there may be an administrative limit to the number of entries a server will check when gathering potential search result candidates [Net]. 5.2.2.4.4 unavailableCriticalExtension(12) Applicable operations: all. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 12 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 This error code is new in LDAPv3. The server was unable to satisfy the request because one or more critical extensions were not available [X511, Section 12.8]. This error is returned, for example, when a control submitted with a request is marked critical but is = not recognized by a server or when such a control is not appropriate for the operation type. [RFC2251 section 4.1.12]. 5.2.2.4.5 busy(51) Applicable operations: all. This error code may be returned if the server is unable to process the client=92s request at this time. This implies that if the client retries the request shortly the server will be able to process it then. 5.2.2.4.6 unavailable(52) Applicable operations: all. This error code is returned when the server is unavailable to = process the client=92s request. This usually means that the LDAP server is shutting down [RFC2251, Section 4.2.3]. 5.2.2.4.7 unwillingToPerform(53) Applicable operations: all. This error code should be returned by the server when a client request is properly formed but which the server is unable to = complete due to server-defined restrictions. For example, the server, or = some part of it, is not prepared to execute this request, e.g. because it would lead to excessive consumption of resources or violates the policy of an Administrative Authority involved [X511, Section 12.8]. If the server is able to return a more specific error code such as adminLimitExceeded it should. This error may also be returned if the client attempts to modify attributes which can not be modified by users, e.g., operational attributes such as creatorsName or createTimestamp [X511, Section 7.12]. If appropriate, details of the error should be provided in the error message. 5.2.2.4.8 loopDetect(54) Applicable operations: all. This error may be returned by the server if it detects an alias or referral loop, and is unable to satisfy the client=92s request. 5.2.2.5 UpdateProblem Error Codes An update error reports problems related to attempts to add, delete, or modify information in the DIB [X511, Section 12.9]. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 13 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 5.2.2.5.1 namingViolation(64) Applicable operations: Add, ModifyDN. The attempted addition or modification would violate the structure rules of the DIT as defined in the directory schema and X.501. That is, it would place an entry as the subordinate of an alias entry, or in a region of the DIT not permitted to a member of its object = class, or would define an RDN for an entry to include a forbidden attribute type [X511, Section 12.9]. 5.2.2.5.2 objectClassViolation(65) Applicable operations: Modify, Add, ModifyDN. This error should be returned if the operation requested by the user would violate the objectClass requirements for the entry if carried out. On an add or modify operation this would result from trying to add an object class without a required attribute, or by trying to = add an attribute which is not permitted by the current object class set in the entry. On a modify operation this may result from trying to remove a required attribute without removing the associated = auxiliary object class, or by attempting to remove an object class while the attributes it permits are still present. 5.2.2.5.3 notAllowedOnNonLeaf(66) Applicable operations: Delete, ModifyDN. This operation should be returned if the client attempts to perform an operation which is permitted only on leaf entries - e.g., if the client attempts to delete a non-leaf entry. If the directory does not permit ModifyDN for non-leaf entries then this error may be returned if the client attempts to change the DN of a non-leaf = entry. (Note that 1988 edition X.500 servers only permitted change of the RDN of an entry's DN [X.511, Section 11.4.1]). 5.2.2.5.4 notAllowedOnRDN(67) Applicable operations: Modify. The attempted operation would affect the RDN (e.g., removal of an attribute which is a part of the RDN) [X511, Section 12.9]. If the client attempts to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name the server should return the error notAllowedOnRDN. [RFC2251, Section 4.6] 5.2.2.5.5 entryAlreadyExists(68) Applicable operations: Add, ModifyDN. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 14 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 This error should be returned by the server when the client attempts to add an entry which already exists, or if the client attempts to rename an entry with the name of an entry which exists. 5.2.2.5.6 objectClassModsProhibited(69) Applicable operations: Modify. An operation attempted to modify an object class that should not be modified, e.g., the structural object class of an entry. Some servers may not permit object class modifications, especially modifications to the structural object class since this may change the entry entirely, name forms, structure rules etc. [X.511, Section 12.9]. 5.2.2.5.7 affectsMultipleDSAs(71) Applicable operations: ModifyDN. This error code is new for LDAPv3. This error code should be = returned to indicate that the operation could not be performed since it affects more than one DSA. X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the LDAP server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs will be returned if this error occurred. In general clients MUST NOT expect to be able to perform arbitrary movements of entries and subtrees between servers [RFC2251, Section 4.9]. 5.3 Error Precedence A server MUST return only a single result code to a client. The following list specifies the precedence of errors in the case that more than one error is detected [X511]: 1. Specific Errors; i. Name Errors; ii. Update Errors; iii. Attribute Errors; iv. Security Errors; v. Service Errors; 2. General Errors. 6 LDAP Operations LDAP v3 [RFC2251] defines the following LDAPMessage for conveyance = of the intended operation request from the client to the server. LDAPMessage ::=3D SEQUENCE { messageID MessageID, protocolOp CHOICE { bindRequest BindRequest, Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 15 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, modifyRequest ModifyRequest, modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modDNRequest ModifyDNRequest, modDNResponse ModifyDNResponse, compareRequest CompareRequest, compareResponse CompareResponse, abandonRequest AbandonRequest, extendedReq ExtendedRequest, extendedResp ExtendedResponse }, controls [0] Controls OPTIONAL } MessageID ::=3D INTEGER (0 .. maxInt) maxInt INTEGER ::=3D 2147483647 -- (2^^31 - 1) - Starting in Section 6.2, behaviour regarding the return of each result code is specified for each operation. Section 6.1 indicates those result codes that are typically applicable to all operations. 6.1 Common Result Codes The following result codes are applicable to, and may be returned in response to all operations (except where stated otherwise). 6.1.1 Non-erroneous results For all but a Compare operation, a success(0) result code will be returned in the case that the requested operation succeeds; a compareTrue would be returned for a Compare operation. For each operation, the server may return referral(10), as defined in Section 5.1.4. 6.1.2 Security Errors Of the six possible security errors, two may be returned in response to every operation. These two errors are strongAuthRequired(8) and confidentialityRequired(13). 6.1.3 Service Errors All service errors, except sizeLimitExceeded(4) may be returned in response to any LDAP v3 operation. sizeLimitExceeded is only applicable to the Search operation. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 16 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 6.1.4 General Errors All general errors are applicable to all operations. The list of general errors includes operationsError, protocolError, and other. 6.2 Bind Operation Errors If the bind operation succeeds then a result code of success will be returned to the client. If the server does not hold the target entry of the request, a referral(10) may be returned. If the operation fails then the result code will be one of the following from the set of non-erroneous result, name errors, security errors, service errors, and general errors. If the server does not support the client's requested protocol version, it MUST set the resultCode to protocolError. If the client receives a BindResponse response where the resultCode was protocolError, it MUST close the connection as the server will = be unwilling to accept further operations. (This is for compatibility with earlier versions of LDAP, in which the bind was always the = first operation, and there was no negotiation.) [RFC2251, Section 5.2.3] The remaining errors listed in this section are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.2.1 Non-erroneous results In addition to success or referral, the following non-erroneous result code may be returned: saslBindInProgress: the server requires the client to send a new = bind request, with the same sasl mechanism, to continue the = authentication process, 6.2.2 Name Errors invalidDNSyntax: the DN provided does not have the correct syntax, 6.2.3 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. authMethodNotSupported: unrecognized SASL mechanism name, inappropriateAuthentication: the server requires the client which = had attempted to bind anonymously or without supplying credentials to provide some form of credentials, invalidCredentials: the wrong password was supplied or the SASL credentials could not be processed, [RFC2251, Section 4.2.3] 6.3 Search Operation Errors Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 17 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 X.500 provides three separate operations for searching the directory - Read of a single entry, List of an entry=92s children and search = of an entire sub-tree. LDAP provides a single search operation, however the X.500 operations can be simulated by using base, one-level and sub-tree scope restrictions respectively. If the Search operation succeeds then zero or more search entries will be returned followed by a search result of success. If the server does not hold the target entry of the request, a referral(10) may be returned. If the search operation fails then zero or more search entries will be returned followed by a search result containing one of the following result codes from the set of name errors, attribute errors, security errors, service errors, and general errors. The remaining errors listed in this section are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.3.1 Name Errors noSuchObject: the base object, for the search, does not exist. aliasProblem: an alias was dereferenced which named no object. invalidDNSyntax: the DN provided for the search base does not have the correct syntax, aliasDereferenceProblem: The client does not have permission for the aliasedObjectName attribute or to search the dereferenced alias object. 6.3.2 Attribute Errors inappropriateMatching: an attempt was made to use a matching rule = not defined for an attribute in the search filter. 6.3.3 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. insufficientAccessRights: The requestor does not have sufficient permissions to perform the search. 6.3.4 Service Errors In addition to the common service errors indicated in Section 6.1.3, the following service error may also be returned: sizeLimitExceeded: the number of search results exceeds the size limit specified by the client or the server. If the server has Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 18 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 defined a maximum PDU size, this error may also be returned if the size of the combined results exceeds this limit. 6.4 Modify Operation Errors The Modify operation cannot be used to remove from an entry any of its distinguished values, those values that form the entry's = relative distinguished name. An attempt to do so will result in the server returning the error notAllowedOnRDN. The Modify DN Operation described in section 5.9 is used to rename an entry. [RFC2251, Section 4.6] If the modify operation succeeds, a result code of success will be returned to the client. If the server does not hold the target entry of the request, a referral(10) may be returned. If the operation fails, the result code will be one of the following from the set of name errors, update errors, attribute errors, security errors, service errors, and general errors. The remaining errors listed in this section, are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.4.1 Name Errors noSuchObject: the target object does not exist. invalidDNSyntax: the DN provided does not have the correct syntax, 6.4.2 Update Errors objectClassViolation: An attempt was made to modify an object which is illegal according to its object class definition in the schema or DIT content rules for that object class. notAllowedOnRDN: An attempt was made to modify the object entry=92s distinguished name objectClassModsProhibited: The modification attempted to change an entry=92s object class which is not allowed. 6.4.3 Attribute Errors noSuchAttribute: the attribute to be modified does not exist in the target entry. undefinedAttributeType: The attribute specified does not exist in = the server's defined schema. constraintViolation: The modification would create an attribute = value outside the normal bounds. attributeOrValueExists: The modification would create a value which already exists within the attribute. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 19 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 invalidAttributeSyntax: The value specified doesn=92t adhere to the syntax definition for that attribute. 6.4.4 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. insufficientAccessRights: The requestor does not have sufficient permissions to modify the entry. 6.5 Add Operation Errors The superior of the entry must exist for the operation to succeed. = If not, a noSuchObject error is returned and the matchedDN field will contain the name of the lowest entry in the directory that was matched. If the add operation succeeds, a result code of success will be returned to the client. If the server does not hold the target entry of the request, a referral(10) may be returned. If the operation fails, the result code will be one of the following from the set of name errors, update errors, attribute errors, security errors, service errors, and general errors. The remaining errors listed in this section, are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.5.1 Name Errors noSuchObject: One or more superiors to the target entry do not = exist. invalidDNSyntax: the DN provided does not have the correct syntax, 6.5.2 Update Errors namingViolation: Either the target entry cannot be created under the specified superior due to DIT structure rules, or the target entry = is named by an RDN not permitted by the DIT name form rule for its object class. objectClassViolation: An attempt was made to add an entry and one of the following conditions existed: A required attribute was not specified; an attribute was specified which is not permitted by the current object class set in the entry; a structural object class value was not specified; an object class value was specified that doesn=92t exist in the schema. entryAlreadyExists: The target entry already exists. 6.5.3 Attribute Errors Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 20 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 undefinedAttributeType: The attribute specified does not exist in = the server's defined schema. constraintViolation: The attribute value falls outside the bounds specified by the attribute syntax. attributeOrValueExists: A duplicate attribute value appears in the list of attributes for the entry. invalidAttributeSyntax: The value specified doesn=92t adhere to the syntax definition for that attribute. 6.5.4 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. insufficientAccessRights: The requestor does not have sufficient permissions to either add the entry or to add one or more of the attributes specified. 6.6 Delete Operation Errors If the delete operation succeeds, a result code of success will be returned to the client. If the server does not hold the target entry of the request, a referral(10) may be returned. If the operation fails, the result code will be one of the following from the set of name errors, update errors, security errors, service errors, and general errors. The remaining errors listed in this section, are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.6.1 Name Errors noSuchObject: The target entry does not exist. invalidDNSyntax: the DN provided does not have the correct syntax, 6.6.2 Update Errors notAllowedOnNonLeaf: The target entry is not a leaf object. Only objects having no subordinate objects in the tree may be deleted. 6.6.3 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. insufficientAccessRights: The requestor does not have sufficient permissions to delete the entry. 6.7 ModifyDN Operation Errors Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 21 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 Note that X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the LDAP = server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs will be returned if this error occurred. In general clients MUST NOT expect to be able to perform arbitrary movements of entries and subtrees between servers. [RFC2251, Section 4.9] If the Modify DN operation succeeds then a result code of success will be returned to the client. If the server does not hold the target entry of the request, a referral(10) may be returned. If the operation fails then the result code will be one of the following from the set of name errors, update errors, attribute errors, security errors, service errors, and general errors. The remaining errors listed in this section, are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.7.1 Name Errors noSuchObject: the target object does not exist or a new superior object was specified that does not exist. invalidDNSyntax: the DN provided does not have the correct syntax. 6.7.2 Update Errors namingViolation: Either the target entry cannot be moved to the specified superior due to DIT structure rules, or the target entry = is named by an RDN not permitted by the DIT name form rule for its object class. objectClassViolation: The client has specified that the old RDN values should be removed from the entry (using the 'deleteOldRdn' parameter) but the removal of these values would violate the entry's schema. [RFC 2251 Section 4.9] notAllowedOnNonLeaf: If the server does not permit the ModifyDN operation on non-leaf entries this error will be returned if the client attempts to rename a non-leaf entry entryAlreadyExists: The target entry already exists. AffectsMultipleDSAs: X.500 restricts the ModifyDN operation to only affect entries that are contained within a single server. If the = LDAP server is mapped onto DAP, then this restriction will apply, and the resultCode affectsMultipleDSAs will be returned if this error occurred. In general clients MUST NOT expect to be able to perform arbitrary movements of entries and sub-trees between servers. [RFC2251, Section 4.9] 6.7.3 Attribute Errors Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 22 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 constraintViolation: The operation would create an attribute value outside the normal bounds. 6.7.4 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. insufficientAccessRights: The requestor does not have sufficient permissions to either add the entry or to add one or more of the attributes specified. 6.8 Compare Operation Errors If there exists a value within the attribute being compared that matches the purported argument and for which compare permissions is granted, the operation returns the value compareTrue in the result, otherwise, the operation returns compareFalse. [X511, Section 9.2.4] If the server does not hold the target entry of the request, a referral(10) may be returned. If the compare operation can not be completed, then the server may return one of the following results from the set of name errors, attribute errors, security errors, service errors, and general errors. The remaining errors listed in this section are operation-specific. An operation may also result in the return of any of the common errors, as listed in Section 6.1. 6.8.1 Name Errors noSuchObject: the entry to be compared does not exist in the directory. invalidDNSyntax: the DN provided for the entry to be compared does not have the correct syntax. 6.8.2 Attribute Errors noSuchAttribute: the attribute to be compared does not exist in the target entry. invalidAttributeSyntax: The value specified doesn=92t adhere to the syntax definition for that attribute. 6.8.3 Security Errors As stated in Section 6.1.2, strongAuthRequired(8) and confidentialityRequired(13) may be returned for any operation. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 23 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 insufficientAccessRights: If the client does not have read = permission for the entry to be compared, or for the attribute then insufficientAccessRights should be returned, [X511, Section 9.2.4] 6.8.4 Example The following example is included to demonstrate the expected responses for the compare operation. Given the following entry: dn: cn=3DFoo objectClass: top objectClass: person sn: bar userPassword: xyz i) Compare with userPassword=3Dxyz results in a compareTrue because = the requested value exists in the entry. ii) Compare with userPassword=3Dabc results in a compareFalse = because the entry contains a userPassword attribute but the value abc is not present. iii) Compare with telephoneNumber=3D123-456-7890 results in a noSuchAttribute. The attribute telephoneNumber is permissible in the entry based on the schema defined in the server but because it is empty it does not exist in the target entry. iv) Compare with ou=3DmyOrg results in noSuchAttribute. The = requested attribute is a recognized attribute but it is neither present nor is it valid for the target entry. v) Compare with bogusAttr=3Dabc results in noSuchAttribute. The requested attribute is not a recognized attribute nor is it present in the target entry. Note that the response for scenarios 3 through 5 is always noSuchAttribute. The semantics of the compare operation is simply =91 =91does the target entry contain the specified value?=92 =92 and so no distinction is made between a request for an unknown, invalid, or, valid but empty attribute. In all cases if the attribute is not present in the entry then the result is noSuchAttribute. 6.9 Extended Operation Errors The results returned for an extended operation vary, depending on = the particular operation. At least, the general responses that apply to every operation will certainly apply to an extended operation. The precedence of error codes, as described in Section 5.3, applies as well to any extended operation. If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code [RFC2251, Section 4.12] Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 24 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 6.10 Operations with no Server Response The LDAP v3 protocol has two client operations for which no server response is returned. Specifically, these are unbindRequest, and abandonRequest. Since no response is returned, there is no need to consider possible result codes for these operations. 6.11 Unsolicited Notification In some situations, a server may issue a =91 =91response=92 =92 to a client = for which there was no client request. This notification =91 =91is used to signal an extraordinary condition in the server or in the connection between the client and the server. The notification is of an advisory nature, and the server will not expect any response to be returned from the client.=92 =92 [RFC2251, Section 4.4] RFC 2251 [RFC2251] describes a notice of disconnection in which a protocolError, strongAuthRequired, or unavailable result code may be returned. The reader is directed there for further information. 7. Security Considerations This draft is meant to complement and enhance the coverage of result codes for LDAP v3, as described in RFC 2251 [RFC2251]. Section 7 of RFC 2251 [RFC2251] lists a number of security considerations = specific to LDAP v3. Note that in X.500 if the discloseOnError permission is not granted then many operations will return noSuchObject instead of a more specific error. As there is currently no equivalent for this permission in LDAP, LDAP-only servers should return the appropriate error code in the event of an error. 8. References [RFC2026] S. Bradner, =91 =91The Internet Standards Process - = Revision 3=92 =92, RFC 2026, October 1996. [RFC2119] S. Bradner, =91 =91Key words for use in RFCs to Indicate Requirement Levels=92 =92, RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille, =91 =91Lightweight Directory Access Protocol=92 =92, RFC 2251, December 1997. [X511] ITU-T Recommendation X.511, =91 =91The Directory: Abstract Service Definition=92 =92, 1993. [TLS] J. Hodges, R.L. Morgan, M. Wahl, =91 =91Lightweight = Directory Access Protocol (v3): Extension for Transport Layer Security=92 =92, June 1999. "work in progress" Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 25 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 [Net] Netscape Directory SDK 3.0 for C Programmer=92s Guide, Chapter 19: Result Codes. Available at Error! Bookmark not defined. 9. Acknowledgments The production of this document relied heavily on the information available from RFC 2251 [RFC2251] and ITU-T Recommendation X.511 [X511]. 10. Author's Addresses Mike Just Entrust Technologies 750 Heron Rd, Tower E Ottawa, Ontario, Canada mike.just@entrust.com Kristianne Leclair Entrust Technologies 750 Heron Rd, Tower E Ottawa, Ontario, Canada kristianne.leclair@entrust.com Jim Sermersheim Novell 122 East 1700 South Provo, Utah 84606, USA Error! Bookmark not defined. Mark Smith Netscape 501 Ellis Street Mountain View, CA 94043 Error! Bookmark not defined. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 26 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 11 Appendix A: Operation/Response Matrix Result Codes Operations B S M A D M C i e o d e o o n a d d l d m d r i e D p c f t N a h y e r e Non-erroneous results success (0) X X X X X X compareFalse (5) X compareTrue (6) X referral (10) X X X X X X X SaslBindInProgress (14) X Name errors noSuchObject (32) X X X X X X aliasProblem (33) X InvalidDNSyntax (34) X X X X X X X AliasDereferencingProblem X (36) Update errors namingViolation (64) X X objectClassViolation (65) X X X notAllowedOnNonLeaf (66) X X notAllowedonRDN (67) X entryAlreadyExists (68) X X objectClassModesProhibite X d (69) affectsMultipleDSAs (71) X Attribute errors NoSuchAttribute(16) X X UndefinedAttributeType X X (17) InappropriateMatching X (18) ConstraintViolation (19) X X X AttributeOrValueExists X X (20) InvalidAttributeSyntax X X (21) Security errors AuthMethodNotSupported X (7) StrongAuthRequired (8) X X X X X X X ConfidentialityRequred(13 X X X X X X X ) InappropriateAuthenticati X on (48) Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 27 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 InvalidCredentials (49) X InsufficientAccessRights X X X X X X (50) Service errors TimeLimitExceeded (3) X X X X X X X SizeLimitExceeded (4) X AdminLimitExceeded (11) X X X X X X X UnavailableCriticialExten X X X X X X X sion (12) busy (51) X X X X X X X unavailable (52) X X X X X X X unwillingToPerform (53) X X X X X X X loopDetect (54) X X X X X X X General errors OperationsError (1) X X X X X X X protocolError (2) X X X X X X X other (80) X X X X X X X Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 28 =0C LDAPv3 Result Codes: Definitions and Appropriate Use Feb, 2000 12 Full Copyright Statement Copyright (C) The Internet Society (Oct 1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 29 =0C ------_=_NextPart_000_01BF7F9A.84038EA0-- From list@netscape.com Fri Feb 25 12:16:04 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15007 for ; Fri, 25 Feb 2000 12:16: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 JAA29014; Fri, 25 Feb 2000 09:10:12 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA07026; Fri, 25 Feb 2000 09:14:02 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 09:14:02 -0800 (PST) Message-Id: <3.0.5.32.20000225091348.009606c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 25 Feb 2000 09:13:48 -0800 To: Mike Just From: "Kurt D. Zeilenga" Subject: Re: draft-just-ldapv3-rescodes-01.txt Cc: "'LDAPExt'" , "'Jim Sermersheim'" , "'Mark Smith'" , Kristianne Leclair In-Reply-To: <01E1D01C12D7D211AFC70090273D20B10139D936@sothmxs06.entrust .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"FRv0dD.A.gtB.Zhrt4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Mike, et. al, A few comments/questions/suggestions based upon a quick read... Internal Errors: operationsError vs other You have defined operationsError as being used to indicate internal errors? Is this actually appropriate since operationsErrors are prescribed to be returned in a number of specific situations, such as documented by bind and start tls operations. I do not believe operationsError should not be used as a catch all for "internal errors". Instead, I suggested servers return other. Precedence? Seems to imply that if multiple errors were detected, that more "specific" should be returned over less "specific" errors. I believe that the most severe error detected be returned. In particular, a protocolError should take precedence over any "specific" error. I would also note that a server is not required to detect multiple errors. It is allowed to return the first error detected. Controls No meantion of controls are made. As controls can significantly change the behavior of operations, it may be appropriate for a control to specify that a result code be returned which would normally returned by the base operation. Extended Operations I would suggest adding a sentence to your extended operation section: Extended Operations MAY return any result code (excepting 81-90). API Errors (81-90): A note stating that server MUST NOT return these result codes. From list@netscape.com Fri Feb 25 12:47:10 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15653 for ; Fri, 25 Feb 2000 12:47: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 JAA02355; Fri, 25 Feb 2000 09:42:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA17698; Fri, 25 Feb 2000 09:46:01 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 09:46:01 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 25 Feb 2000 10:45:44 -0700 From: "Mark Meredith" To: , , "Sukanta Ganguly" Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"y02wpD.A.QUE.Y_rt4"@glacier> 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 MAA15653 Bruce, I can see your point on duplication of information, but what if a site is not running SNMP, or the client being used does not support SNMP how would the information be known? If the information is in the ROOT DSE, I do not care how the information is retrieved from a ldap server stand point, the server could query SNMP or DNS ..... etc. That way the information would not be duplicated per say, but multiply viewable. Does this sound reasonable to you? What do the client developers on this list think? -Mark >>> Bruce Greenblatt 02/24/00 06:31PM >>> I understand that you don't want to look the information up in SNMP. But, why not? It's already there, and SNMP is pretty lightweight (simple even). Do we really want to duplicate this vendor information in several places? It could just as easily be added to SRV records in DNS? What about all of the other informaiton in RFC 2248 and RFC 2605? Do you want to plop that into the RootDSE as well? Bruce At 10:49 AM 2/18/00 -0700, Sukanta Ganguly wrote: > It is very difficult and unclear at this point whether we should assume >that all Internet Directory Client are in the position to talk different >Internet protocols. Instead of assuming that the Directory Client will talk >SNMP and query the MIB for getting the vendor specific information, why >can't we state that the Directory Client queries the rootDSE for the >information and the implementation would determine whether to go to the >SNMP MIB for the information or to have the vendor specific information, >requested by Mark, within the Directory Repository. I think it will >bring in more value to have the access to the information through the >rootDSE but at the same time leave the invididual implementations to >handle them. We all agree, based on the emails that I have seen flowing >around related to this matter, that the information is useful so why not >provide the flexibility. Thanks Sukanta Ganguly sganguly@novell.com > >>>><>>>> >At 09:13 AM 2/18/00 -0500, Peter Strong wrote: >> >>> >>> >>> To be blunt, I don't believe that there is much use for this draft. >> >>For those of us who attempt to build applications that work with >>multiple directory implementations, this information is very useful. >> > > I said that > Get it from there, since that is > I don't see much point in duplicating this > In my opinion, a good internet directory client will get >information from a variety of internet servers: DNS, LDAP, SNMP, and others. > >>> The information that it proposes to add to the Root DSE is already >>> published is >>> The >>> I think that this draft >>> should just point to RFC 2248 (and perhaps 2605) and explain where the >>> These are already standards track >>> documents, and have places to put the information that this draft defines. >>> (Just my $0.02 worth) >> >>The products we build are LDAP clients, not SNMP clients. >> >>This information should be available via LDAP. >> >>> >>> Bruce >>> ============================================== >>> Bruce Greenblatt, Ph. D. >>> Directory Tools and Application Services, Inc. >>> http://www.directory-applications.com >>> >> >>------------------------------------------------------------------------ >>Peter Strong >>Software Architect >>Nortel Networks - Optivity Policy Services (OPS) and NetID >><> >>(613) 831-6615 >> >> >> >> >> >> >============================================== >Bruce Greenblatt, Ph. D. >Directory Tools and Application Services, Inc. >http://www.directory-applications.com > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Fri Feb 25 12:56:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15933 for ; Fri, 25 Feb 2000 12:56:25 -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 JAA21799; Fri, 25 Feb 2000 09:52:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA22085; Fri, 25 Feb 2000 09:54:11 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 09:54:11 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 25 Feb 2000 10:53:49 -0700 From: "Sukanta Ganguly" To: , , "Mark Meredith" Subject: RE: draft-mmeredith-rootdse-vendor-info-02.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8ED70DA9.711018FE" Resent-Message-ID: <"ePP_AC.A.LYF.AHst4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_8ED70DA9.711018FE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Whether the information is stored in the rootDSE physically or the server = on getting a query on the rootDSE for the information and then re-routing = the query to the SNMP server or a DNS server should be implementation = details. Some vendor may want to implement a query re-routing mechanism to = the SNMP/DNS server for the information and some may actually store it on = the rootDSE. This would end up providing a more flexible model. Bruce, Mark and everybody else in the list, is this acceptable ?=20 Sukanta Ganguly Novell Inc (W) 801-861-5190 >>> Mark Meredith 02/25/00 10:45AM >>> Bruce, I can see your point on duplication of information, but what if a site is = not running SNMP, or the client being used does not support SNMP how would = the information be known? If the information is in the ROOT DSE, I do not care how the information = is retrieved from a ldap server stand point, the server could query SNMP = or DNS ..... etc. That way the information would not be duplicated per = say, but multiply viewable. Does this sound reasonable to you? What do the client developers on this list think? -Mark >>> Bruce Greenblatt 02/24/00 = 06:31PM >>> I understand that you don't want to look the information up in SNMP. But, why not? It's already there, and SNMP is pretty lightweight (simple = even). Do we really want to duplicate this vendor information in several places? It could just as easily be added to SRV records in DNS? What about all of the other informaiton in RFC 2248 and RFC 2605? Do you want to plop that into the RootDSE as well? Bruce At 10:49 AM 2/18/00 -0700, Sukanta Ganguly wrote: > It is very difficult and unclear at this point whether we should = assume=20 >that all Internet Directory Client are in the position to talk = different=20 >Internet protocols. Instead of assuming that the Directory Client will = talk >SNMP and query the MIB for getting the vendor specific information, why >can't we state that the Directory Client queries the rootDSE for the >information and the implementation would determine whether to go to the >SNMP MIB for the information or to have the vendor specific information, >requested by Mark, within the Directory Repository. I think it will >bring in more value to have the access to the information through the >rootDSE but at the same time leave the invididual implementations to=20 >handle them. We all agree, based on the emails that I have seen flowing >around related to this matter, that the information is useful so why not >provide the flexibility. Thanks Sukanta Ganguly sganguly@novell.com=20 > >>>><>>>> >At 09:13 AM 2/18/00 -0500, Peter Strong wrote: >> >>> >>> >>> To be blunt, I don't believe that there is much use for this draft. >> >>For those of us who attempt to build applications that work with >>multiple directory implementations, this information is very useful. >> > > I said that > Get it from there, since that is > I don't see much point in duplicating this > In my opinion, a good internet directory client will get >information from a variety of internet servers: DNS, LDAP, SNMP, and = others. > >>> The information that it proposes to add to the Root DSE is already >>> published is >>> The >>> I think that this draft >>> should just point to RFC 2248 (and perhaps 2605) and explain where = the >>> These are already standards track >>> documents, and have places to put the information that this draft defines. >>> (Just my $0.02 worth) >> >>The products we build are LDAP clients, not SNMP clients. >> >>This information should be available via LDAP. >> >>> >>> Bruce >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Bruce Greenblatt, Ph. D. >>> Directory Tools and Application Services, Inc. >>> http://www.directory-applications.com=20 >>> >> >>------------------------------------------------------------------------ >>Peter Strong >>Software Architect >>Nortel Networks - Optivity Policy Services (OPS) and NetID >><> >>(613) 831-6615 >> >> >> >> >> >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Bruce Greenblatt, Ph. D. >Directory Tools and Application Services, Inc. >http://www.directory-applications.com=20 > >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=_8ED70DA9.711018FE Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Whether the information is stored in the rootDSE physically or the = server=20 on getting a query on the rootDSE for the information and then re-routing = the=20 query to the SNMP server or a DNS server should be implementation details. = Some=20 vendor may want to implement a query re-routing mechanism to the SNMP/DNS = server=20 for the information and some may actually store it on the rootDSE. This = would=20 end up providing a more flexible model.
 
Bruce, Mark and everybody else in the list, is this acceptable = ?=20
 
Sukanta Ganguly
Novell Inc
(W) 801-861-5190

>>> Mark Meredith 02/25/00 10:45AM=20= >>>
Bruce,

I can see your point on duplication of=20 information, but what if a site is not running SNMP, or the client being = used=20 does not support SNMP how would the information be known?

If the=20 information is in the ROOT DSE, I do not care how the information is = retrieved=20 from a ldap server stand point, the server could query SNMP or DNS ..... = etc.=20 That way the information would not be duplicated per say, but multiply=20 viewable.

Does this sound reasonable to you?

What do the = client=20 developers on this list think?

-Mark

>>> Bruce = Greenblatt=20 <bgreenblatt@directory-applications.com> 02/24/00 06:31PM=20 >>>
I understand that you don't want to look the information = up in=20 SNMP.  But,
why not?  It's already there, and SNMP is = pretty=20 lightweight (simple even).
 Do we really want to duplicate this = vendor=20 information in several places?
It could just as easily be added to = SRV=20 records in DNS?  What about all of
the other informaiton in RFC = 2248 and=20 RFC 2605?  Do you want to plop that
into the RootDSE as=20 well?

Bruce

At 10:49 AM 2/18/00 -0700, Sukanta Ganguly=20 wrote:
>   It is very difficult and unclear at this = point=20 whether we should assume
>that all Internet Directory Client are in = the=20 position to talk different
>Internet protocols. Instead of assuming = that=20 the Directory Client will talk
>SNMP  and query the MIB for = getting=20 the vendor specific information, why
>can't we  state that = the=20 Directory Client queries the rootDSE for the
>information and = the =20 implementation would determine whether to go to the
>SNMP MIB for = the=20 information  or to have the vendor specific information,
>reques= ted=20 by Mark, within the  Directory Repository.   I think it=20 will
>bring in more value to have the access to the information = =20 through the
>rootDSE but at the same time leave the invididual=20 implementations to
>handle them. We all agree, based on the emails = that I=20 have seen flowing
>around  related to this matter, that the=20 information is useful so why not
>provide the =20 flexibility.   Thanks Sukanta Ganguly sganguly@novell.com=20
>
>>>><>>>>
>At 09:13 AM = 2/18/00=20 -0500, Peter Strong =20 wrote:
>>
>>>
>>>
>>> To be = blunt,=20 I don't believe  that there is much use for this=20 draft.
>>
>>For those of us who  attempt to = build=20 applications that work with
>>multiple directory  implementat= ions,=20 this information is very useful.
>>
>
>   I = said=20 that
>  Get it from there, since that  is
>  I = don't=20 see much point in duplicating  this
>  In my opinion, a = good=20 internet directory client will  get
>information from a variety = of=20 internet servers: DNS, LDAP, SNMP, and  others.
>
>>>= ; The=20 information that it proposes to add to the Root DSE  is=20 already
>>> published is
>>> =20 The
>>>  I think that this draft
>>> = should=20 just  point to RFC 2248 (and perhaps 2605) and explain where=20 the
>>>  These are already standards =20 track
>>> documents, and have places to put the information = that=20 this  draft
defines.
>>> (Just my $0.02=20 worth)
>>
>>The products we  build are LDAP = clients, not=20 SNMP clients.
>>
>>This information should  be = available=20 via LDAP.
>>
>>>
>>> =20 Bruce
>>> =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>= > Bruce Greenblatt,=20 Ph.  D.
>>> Directory Tools and Application Services,=20 Inc.
>>> http://www.directory-applications.com=20
>>>
>>
>>-----------------------------------= -------------------------------------
>>Peter =20 Strong
>>Software Architect
>>Nortel Networks - = Optivity=20 Policy  Services (OPS) and NetID
>><>
>>(613)&= nbsp;=20 831-6615
>>
>>
>>
>>
>>
>= ;>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
>Bruce =20 Greenblatt, Ph. D.
>Directory Tools and Application Services,=20 Inc.
>http://www.directory-applications.com
>
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Br= uce Greenblatt, Ph.=20 D.
Directory Tools and Application Services,=20 Inc.
http://www.directory-applications.com
--=_8ED70DA9.711018FE-- From list@netscape.com Fri Feb 25 14:15:13 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18255 for ; Fri, 25 Feb 2000 14:15:13 -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 LAA06469; Fri, 25 Feb 2000 11:12:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA29290; Fri, 25 Feb 2000 11:14:04 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 11:14:04 -0800 (PST) Sender: mcs@netscape.com (Mark C Smith) Message-ID: <38B6D477.78AD089F@netscape.com> Date: Fri, 25 Feb 2000 14:13:59 -0500 From: Mark Smith Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Mark Meredith CC: bgreenblatt@directory-applications.com, ietf-ldapext@netscape.com, Sukanta Ganguly Subject: Re: draft-mmeredith-rootdse-vendor-info-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FiKNtC.A.YJH.7Rtt4"@glacier> 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 written or helped people write dozens of LDAP clients (hundreds?) None of these clients includes SNMP client code, although they include many other protocols (SMTP, IMAP, POP, S/MIME, HTTP and many others). I conclude that most (LDAP) client applications don't have any need to speak SNMP today, and therefore we shouldn't force them to do so just to get at this information. A little redundancy doesn't seem like a bad thing in this instance. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? Mark Meredith wrote: > > Bruce, > > I can see your point on duplication of information, but what if a site is not running SNMP, or the client being used does not support SNMP how would the information be known? > > If the information is in the ROOT DSE, I do not care how the information is retrieved from a ldap server stand point, the server could query SNMP or DNS ..... etc. That way the information would not be duplicated per say, but multiply viewable. > > Does this sound reasonable to you? > > What do the client developers on this list think? > > -Mark > > >>> Bruce Greenblatt 02/24/00 06:31PM >>> > I understand that you don't want to look the information up in SNMP. But, > why not? It's already there, and SNMP is pretty lightweight (simple even). > Do we really want to duplicate this vendor information in several places? > It could just as easily be added to SRV records in DNS? What about all of > the other informaiton in RFC 2248 and RFC 2605? Do you want to plop that > into the RootDSE as well? > > Bruce > > At 10:49 AM 2/18/00 -0700, Sukanta Ganguly wrote: > > It is very difficult and unclear at this point whether we should assume > >that all Internet Directory Client are in the position to talk different > >Internet protocols. Instead of assuming that the Directory Client will talk > >SNMP and query the MIB for getting the vendor specific information, why > >can't we state that the Directory Client queries the rootDSE for the > >information and the implementation would determine whether to go to the > >SNMP MIB for the information or to have the vendor specific information, > >requested by Mark, within the Directory Repository. I think it will > >bring in more value to have the access to the information through the > >rootDSE but at the same time leave the invididual implementations to > >handle them. We all agree, based on the emails that I have seen flowing > >around related to this matter, that the information is useful so why not > >provide the flexibility. Thanks Sukanta Ganguly sganguly@novell.com > > > >>>><>>>> > >At 09:13 AM 2/18/00 -0500, Peter Strong wrote: > >> > >>> > >>> > >>> To be blunt, I don't believe that there is much use for this draft. > >> > >>For those of us who attempt to build applications that work with > >>multiple directory implementations, this information is very useful. > >> > > > > I said that > > Get it from there, since that is > > I don't see much point in duplicating this > > In my opinion, a good internet directory client will get > >information from a variety of internet servers: DNS, LDAP, SNMP, and others. > > > >>> The information that it proposes to add to the Root DSE is already > >>> published is > >>> The > >>> I think that this draft > >>> should just point to RFC 2248 (and perhaps 2605) and explain where the > >>> These are already standards track > >>> documents, and have places to put the information that this draft > defines. > >>> (Just my $0.02 worth) > >> > >>The products we build are LDAP clients, not SNMP clients. > >> > >>This information should be available via LDAP. > >> > >>> > >>> Bruce > >>> ============================================== > >>> Bruce Greenblatt, Ph. D. > >>> Directory Tools and Application Services, Inc. > >>> http://www.directory-applications.com > >>> > >> > >>------------------------------------------------------------------------ > >>Peter Strong > >>Software Architect > >>Nortel Networks - Optivity Policy Services (OPS) and NetID > >><> > >>(613) 831-6615 > >> > >> > >> > >> > >> > >> > >============================================== > >Bruce Greenblatt, Ph. D. > >Directory Tools and Application Services, Inc. > >http://www.directory-applications.com > > > > > ============================================== > Bruce Greenblatt, Ph. D. > Directory Tools and Application Services, Inc. > http://www.directory-applications.com From list@netscape.com Fri Feb 25 15:58:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20514 for ; Fri, 25 Feb 2000 15:58: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 MAA22528; Fri, 25 Feb 2000 12:55:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA03702; Fri, 25 Feb 2000 12:57:31 -0800 (PST) Resent-Date: Fri, 25 Feb 2000 12:57:31 -0800 (PST) Message-ID: <01E1D01C12D7D211AFC70090273D20B10139D93C@sothmxs06.entrust.com> From: Mike Just To: "'Kurt D. Zeilenga'" Cc: "'LDAPExt'" , "'Jim Sermersheim'" , "'Mark Smith'" , Kristianne Leclair Subject: RE: draft-just-ldapv3-rescodes-01.txt Date: Fri, 25 Feb 2000 15:57:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"K81-2B.A.k5.7yut4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi Kurt, > A few comments/questions/suggestions based upon a quick read... > Thanks for looking at the document. Comments below. > Internal Errors: operationsError vs other > You have defined operationsError as being used to indicate internal > errors? Is this actually appropriate since operationsErrors are > prescribed to be returned in a number of specific situations, such > as documented by bind and start tls operations. I do not believe > operationsError should not be used as a catch all for "internal > errors". Instead, I suggested servers return other. > Good point. Your reference to Bind is from Section 4.2.1 of RFC 2251. We'll have to investigate further to see how we should classify operationsError. > Precedence? > Seems to imply that if multiple errors were detected, that > more "specific" should be returned over less "specific" errors. > I believe that the most severe error detected be returned. > In particular, a protocolError should take precedence over any > "specific" error. > At first thought, I would suspect that a protocolError would be detected before any other condition could be checked. However, each server may decide on the order in which it will validate the success of a request, and we certainly didn't include this section to prescribe how a server should validate a request. We wanted to include the precedence section since it is in X.511. The particular example you cite results from our pigeon-holing of protocolError, which is not included in X.511, as a general error. There may be other examples though. We've never felt too strongly about a need to keep the precendence section in any case. I'll propose that we remove it unless anyone has a reason for keeping it. > I would also note that a server is not required to detect > multiple errors. It is allowed to return the first error > detected. > Yes. That's why it is phrased "in the case that more than one error is detected". In any case, as noted above, we'll likely not keep this section. > Controls > No meantion of controls are made. As controls can significantly > change the behavior of operations, it may be appropriate for a > control to specify that a result code be returned which would > normally returned by the base operation. > Right. We'll make mention of this. Since no specific controls are defined in RFC 2251, we'll just point the readers to the respective RFCs for details. > Extended Operations > I would suggest adding a sentence to your extended operation > section: Extended Operations MAY return any result code > (excepting 81-90). > > API Errors (81-90): > A note stating that server MUST NOT return these result codes. > Both of these sound fine. Mike J. From list@netscape.com Sun Feb 27 12:07:13 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09570 for ; Sun, 27 Feb 2000 12:07:13 -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 JAA17473; Sun, 27 Feb 2000 09:04:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA23624; Sun, 27 Feb 2000 09:06:03 -0800 (PST) Resent-Date: Sun, 27 Feb 2000 09:06:03 -0800 (PST) Message-Id: <3.0.5.32.20000227091107.0092a100@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 27 Feb 2000 09:11:07 -0800 To: Mark Smith , Mark Meredith From: Bruce Greenblatt Subject: Re: draft-mmeredith-rootdse-vendor-info-02.txt Cc: ietf-ldapext@netscape.com, Sukanta Ganguly In-Reply-To: <38B6D477.78AD089F@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"h-o_t.A.2wF.5lVu4"@glacier> 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 would be acceptable to me if wording similar to the following were included in the "vendor info" draft: "Server implementations conforming to this document must also support RFC 2248. In particular the strings that are stored in the vendorName and vendorVersion attribute values defined here must be also available via SNMP from the applName and applVersion fields of the applTable MIB defined in RFC 2248." Note that I'd mandate this, so that the information is duplicated rather than in place of. Does any one produce an LDAP server on a platform where there is no SNMP agent? Bruce At 02:13 PM 2/25/00 -0500, Mark Smith wrote: >I've written or helped people write dozens of LDAP clients (hundreds?) > >None of these clients includes SNMP client code, although they include >many other protocols (SMTP, IMAP, POP, S/MIME, HTTP and many others). > >I conclude that most (LDAP) client applications don't have any need to >speak SNMP today, and therefore we shouldn't force them to do so just to >get at this information. A little redundancy doesn't seem like a bad >thing in this instance. > >-- >Mark Smith >Directory Product Development / iPlanet E-Commerce Solutions >My words are my own, not my employer's. Got LDAP? > > >Mark Meredith wrote: >> >> Bruce, >> >> I can see your point on duplication of information, but what if a site is not running SNMP, or the client being used does not support SNMP how would the information be known? >> >> If the information is in the ROOT DSE, I do not care how the information is retrieved from a ldap server stand point, the server could query SNMP or DNS ..... etc. That way the information would not be duplicated per say, but multiply viewable. >> >> Does this sound reasonable to you? >> >> What do the client developers on this list think? >> >> -Mark >> >> >>> Bruce Greenblatt 02/24/00 06:31PM >>> >> I understand that you don't want to look the information up in SNMP. But, >> why not? It's already there, and SNMP is pretty lightweight (simple even). >> Do we really want to duplicate this vendor information in several places? >> It could just as easily be added to SRV records in DNS? What about all of >> the other informaiton in RFC 2248 and RFC 2605? Do you want to plop that >> into the RootDSE as well? >> >> Bruce >> >> At 10:49 AM 2/18/00 -0700, Sukanta Ganguly wrote: >> > It is very difficult and unclear at this point whether we should assume >> >that all Internet Directory Client are in the position to talk different >> >Internet protocols. Instead of assuming that the Directory Client will talk >> >SNMP and query the MIB for getting the vendor specific information, why >> >can't we state that the Directory Client queries the rootDSE for the >> >information and the implementation would determine whether to go to the >> >SNMP MIB for the information or to have the vendor specific information, >> >requested by Mark, within the Directory Repository. I think it will >> >bring in more value to have the access to the information through the >> >rootDSE but at the same time leave the invididual implementations to >> >handle them. We all agree, based on the emails that I have seen flowing >> >around related to this matter, that the information is useful so why not >> >provide the flexibility. Thanks Sukanta Ganguly sganguly@novell.com >> > >> >>>><>>>> >> >At 09:13 AM 2/18/00 -0500, Peter Strong wrote: >> >> >> >>> >> >>> >> >>> To be blunt, I don't believe that there is much use for this draft. >> >> >> >>For those of us who attempt to build applications that work with >> >>multiple directory implementations, this information is very useful. >> >> >> > >> > I said that >> > Get it from there, since that is >> > I don't see much point in duplicating this >> > In my opinion, a good internet directory client will get >> >information from a variety of internet servers: DNS, LDAP, SNMP, and others. >> > >> >>> The information that it proposes to add to the Root DSE is already >> >>> published is >> >>> The >> >>> I think that this draft >> >>> should just point to RFC 2248 (and perhaps 2605) and explain where the >> >>> These are already standards track >> >>> documents, and have places to put the information that this draft >> defines. >> >>> (Just my $0.02 worth) >> >> >> >>The products we build are LDAP clients, not SNMP clients. >> >> >> >>This information should be available via LDAP. >> >> >> >>> >> >>> Bruce >> >>> ============================================== >> >>> Bruce Greenblatt, Ph. D. >> >>> Directory Tools and Application Services, Inc. >> >>> http://www.directory-applications.com >> >>> >> >> >> >>------------------------------------------------------------------------ >> >>Peter Strong >> >>Software Architect >> >>Nortel Networks - Optivity Policy Services (OPS) and NetID >> >><> >> >>(613) 831-6615 >> >> >> >> >> >> >> >> >> >> >> >> >> >============================================== >> >Bruce Greenblatt, Ph. D. >> >Directory Tools and Application Services, Inc. >> >http://www.directory-applications.com >> > >> > >> ============================================== >> Bruce Greenblatt, Ph. D. >> Directory Tools and Application Services, Inc. >> http://www.directory-applications.com > > ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Sun Feb 27 13:21:23 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10005 for ; Sun, 27 Feb 2000 13:21:22 -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 KAA28358; Sun, 27 Feb 2000 10:16:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA03445; Sun, 27 Feb 2000 10:20:19 -0800 (PST) Resent-Date: Sun, 27 Feb 2000 10:20:19 -0800 (PST) From: bizop.foryou@belgium.com Date: Mon, 28 Feb 2000 03:16:40 +0900 (KST) Message-Id: <200002271816.DAA29081@ns.icec.or.kr> To: any5one@mail.com Subject: The Net Spy And You!! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"sXBOzC.A.j1.irWu4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com LOOKING FOR GEMS ! It Is So Simple And Easy To Earn $2,000 - $5,000 Per Week... We're searching for 10 quality individuals with integrity and the work ethic necessary to generate a positive 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 a commitment to yourself to succeed, we "GUARANTEE" that you will achieve this explosive income ! Ask yourself these easy questions: 1) Do you have a burning desire to take complete personal and financial control of your life and earn an extraordinary income by helping others to do the same? 2) Are you looking for a strong and legitimate home-based business opportunity, that is not a chain-letter scheme or multi-level marketing (MLM) ? 3) Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium ? (you are not required to do any selling.) If the answer is "YES" to ANY of these questions and you have the self-discipline to ignore the TV and other distractions for a few hours per day, then this is the opportunity for you to earn an extraordinary income and learn how to have that income grow "lightning-fast" ! Under our guidance and support you can build a highly successful business without having to attend meetings or sell people things they don't want or need. CALL NOW for our TOLL FREE, Pre-Recorded Message (800) 742-6549 Ext. 3526 We market a real product, that is high in demand and pays incredible commissions directly to you ($1,000.00 minimum) just for making the initial contacts. With our turn-key lead generation systems you will always talk to people who actually WANT to talk with you. So call now ! The call is FREE and you have absolutely nothing to lose. There is "No Risk" involved, and no obligation whatsoever. You may be qualified to earn thousands of extra dollars per month ! CALL NOW TOLL FREE (800) 742-6549 Ext. 3526 This is a once-in-a-lifetime opportunity ! Get involved now ! Don't wait for this one to go by and then regret it later. This could be the most fascinating and profitable business of your life ! Remember, you have absolutely nothing to loose and EVERYTHING to gain. PS - Serious inquiries only, please to be removed reply and enter remove in the subject. Thanks From list@netscape.com Sun Feb 27 21:01:33 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14781 for ; Sun, 27 Feb 2000 21:01: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 RAA05670; Sun, 27 Feb 2000 17:58:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA00679; Sun, 27 Feb 2000 18:00:41 -0800 (PST) Resent-Date: Sun, 27 Feb 2000 18:00:41 -0800 (PST) Message-Id: <3.0.5.32.20000227180026.00955100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 27 Feb 2000 18:00:26 -0800 To: Bruce Greenblatt From: "Kurt D. Zeilenga" Subject: Re: draft-mmeredith-rootdse-vendor-info-02.txt Cc: Mark Meredith , ietf-ldapext@netscape.com In-Reply-To: <3.0.5.32.20000227091107.0092a100@pop.walltech.com> References: <38B6D477.78AD089F@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"oI9SgC.A.VK.Ibdu4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:11 AM 2/27/00 -0800, Bruce Greenblatt wrote: >It would be acceptable to me if wording similar to the following were >included in the "vendor info" draft: > >"Server implementations conforming to this document must also support RFC >2248. In particular the strings that are stored in the vendorName and >vendorVersion attribute values defined here must be also available via SNMP >from the applName and applVersion fields of the applTable MIB defined in >RFC 2248." There should be no requirement for a implementation of LDAP to implement any other application level protocol. LDAP should be sufficient for accessing directories. >Does any one produce an LDAP server on a platform where >there is no SNMP agent? Yes. And even where there is an SNMP agent, that agent is not necessarily aware of directory services. Kurt From list@netscape.com Mon Feb 28 10:17: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 KAA11144 for ; Mon, 28 Feb 2000 10:17: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 HAA22823; Mon, 28 Feb 2000 07:12:17 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA00298; Mon, 28 Feb 2000 07:16:23 -0800 (PST) Resent-Date: Mon, 28 Feb 2000 07:16:23 -0800 (PST) From: "Ryan Moats" To: "LDAPEXT Mailing List" , "I-D Editor" Cc: "Roland Hedberg" Subject: -02 draft of taxonomy Date: Mon, 28 Feb 2000 09:15:47 -0600 Message-ID: <003c01bf81fe$b06d69a0$e3c8090a@schooner.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Resent-Message-ID: <"tB5R-D.A.5D.FFpu4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I-D Editor: Please replace draft-ietf-ldapext-ldap-taxonomy-01.txt in the repository with the following draft. Thanks. LDAPEXT: Here is the -02 draft of the LDAP taxonomy with editorial changes based on WGLC comments. The authors =====cut here Internet-Draft Ryan Moats draft-ietf-ldapext-ldap-taxonomy-02 AT&T Expires in six months Roland Hedberg Track: Informational Catalogix February 2000 A Taxonomy of Methods for LDAP Clients Finding Servers Filename: draft-ietf-ldapext-ldap-taxonomy-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract There are several different methods for a LDAP client to find a LDAP server. This draft discusses these methods and provides pointers for interested parties to learn more about implementing a particular method. 1. Introduction The Lightweight Directory Access Protocol (LDAP) [1] can be used to build "islands" of servers that are not a priori tied into a single Directory Information Tree (DIT.) Here, it is necessary to determine how a client can discover LDAP servers. This documents discusses the currently available methods and provides pointers for interested parties to learn more about implementing a particular method. This draft documents only those methods that are currently being pursued in the IETF. Other methods have been considered for this Expires 8/31/2000 [Page 1] INTERNET DRAFT LDAP Taxonomy February 2000 problem and the history of these other methods are presented in the Appendix. 2. Methods 2.1 Client Configuration The simplest method of enabling a LDAP client to discover LDAP servers is for the client administrator to configure the client with a list of known LDAP servers (and associated base objects) to send queries to. While this method has the advantage of being correct (initially), it adds the requirement that the list of initial servers be kept small and constant. Otherwise, the required client update process won't scale. 2.2 Well known DNS aliases If the DIT uses a naming scheme similar to that in RFC 2377 [2], then it is possible to build the DNS names of potential servers using well known DNS aliases, like those documented in RFC 2219 [3]. When a different naming scheme is used, it is also possible to build potential server names based on the client's fully qualified domain name or local (within the organization or country) environment. One shortcoming of this method are that it is not exact. Multiple DNS lookups and LDAP protocol operations may be necessary to find the proper LDAP server to serve the client requests. To support client roaming, it is necessary that either the RFC 2377 (or similar) naming scheme be used or that roaming be implemented through tunnels. Because this method uses DNS, it inherits all the security considerations of using DNS to discover LDAP servers: see the security consideration in [3] for more details. 2.3 Service Location Protocol If a client supports the service location protocol [4], it could use a SLP query for LDAP servers. The SLP template that is used to describe LDAP servers is presented in [5], and requires that the servers announce themselves using SLP and this template. Using this method inherits the scaling and security considerations for the service location protocol, which are documented further in [4]. Expires 8/31/2000 [Page 2] INTERNET DRAFT LDAP Taxonomy February 2000 2.4 Referrals In LDAPv3, servers can return referrals to the client if the server has knowledge of where a query might be satisfiable. Two ways of deploying referral information are deploying a LDAP knowledge server or exchanging CIP index objects [6] between servers. A LDAP knowledge server would hold cross references to possibly hundreds of other LDAP servers, so that a client would only need to know about its local LDAP server and the knowledge server. As an optimization, the local LDAP server could also act as a knowledge server. If CIP index objects are exchanged between LDAP servers, then those objects can also carry URL information for providing referrals to clients. Here, the client would only need to know about the local server. Using CIP index objects inherits the security considerations of CIP: see [6, 7, 8] for more details. In either of these cases, the local LDAP server could be determined using another of the methods discussed. 2.5 Using SRV records RFC 2052 [12] defined SRV records for DNS, which bound a host name and port to a label in the DNS. This makes it possible for a client to look up information about a supported protocol for a domain and get back a weighted list of fully qualified domain names and ports for where that protocol is supported. For more information, see [13]. 3. Implementation The Norwegian Directory Forum plans to start a service based on a central LDAP service containing contact information for every organization within Norway [10]. If an organization has more information about its sub-units, employees or functions that it wants to publish it can do so by placing this information in a publicly available LDAP server and providing the management of the central service with a pointer (URL) to this server. The TISDAG project is running a test service based on the TISDAG specification [11]. This service gathers indices from connected White Pages Service Providers using CIP Tagged Index Objects [9]. The rationale for this service is that by supplying the name of a person or a function/role to the service it will return pointers to where more information can be found about persons/functions with that name. Expires 8/31/2000 [Page 3] INTERNET DRAFT LDAP Taxonomy February 2000 The European cofunded project DESIRE (www.desire.org) is designing a system to use a LDAP server that communicates with a referral index that in turn, uses CIP Tagged Index Objects [9] and is fed by LDAP crawlers. DANTE plans to set up a European infrastructure of such referral index servers. 4. References Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites. [1] M. Wahl, T. Howes, S. Kille, Lightweight Directory Access Protocol (v3), RFC 2251, December 1997. [2] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, Naming Plan for Internet Directory-Enabled Applications, RFC 2377, September 1998. [3] M. Hamilton, R. Wright, "Use of DNS Aliases for Network Ser- vices," RFC 2219 (Also BCP 17), October 1997. [4] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Loca- tion Protocol, Version 2," RFC 2608, June 1999. [5] J. Wood, R. Tam, "The LDAP Service Type," Internet Draft (work in progress), July 1999. [6] J. Allen, M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)," RFC 2651, August 1999. [7] J. Allen, M. Mealling, "MIME Object Definitions for the Com- mon Indexing Protocol (CIP)," RFC 2652, August 1999. [8] J. Allen, P. Leach, R. Hedberg, "CIP Transport Protocols," RFC 2653, August 1999. [9] R. Hedberg, B. Greenblatt, R. Moats, M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol," RFC 2654, August 1999. [10] R. Hedberg, H. Alverstrand, "Technical Specification, The Norwegian Directory of Directories (NDD)," Internet Draft (work in progress), May 1999. [11] R. Hedberg, L. Daigle, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," Internet Draft (work in progress), February 2000. Expires 8/31/2000 [Page 4] INTERNET DRAFT LDAP Taxonomy February 2000 [12] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the loca- tion of services (DNS SRV)," RFC 2052, October 1996. [13] M. Armijo, L. Esibov, P. Leach, "Discovering LDAP Services with DNS," Internet Draft (work in progress), July 1999. 5. Author's Addresses Ryan Moats Roland Hedberg AT&T Catalogix 15621 Drexel Circle Dalsveien 53 Omaha, NE 68135 0775 Oslo USA Norway Email: jayhawk@att.com Email: roland@catalogix.ac.se Appendix A. Historical Methods A.1 Discovery The discovery approach was to use a combination of other methods pre- sented in this taxonomy along with storing either the search DN or a related URL in the DNS in some way. Using both TXT or NAPTR records in the DNS were considered. This approach requires an administrator to configure the DNS with necessary information. Further, the idea of storing standards based information (either a DN or an URL) in a DNS RR has been an extremely controversial one in the IETF. A.2 DHCP extensions Another proposed method was to use DHCP to deliver information about LDAP server to a DHCP client. This would require that such informa- tion be configured into the DHCP server and that the client use DHCP to load host configuration information. While there has been some nascent interest in this method, there has been no interest in imple- mentation of this approach. Expires 8/31/2000 [Page 5] From list@netscape.com Mon Feb 28 12:12:19 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14970 for ; Mon, 28 Feb 2000 12:12:18 -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 JAA04203; Mon, 28 Feb 2000 09:07:03 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA06765; Mon, 28 Feb 2000 09:11:05 -0800 (PST) Resent-Date: Mon, 28 Feb 2000 09:11:05 -0800 (PST) Message-ID: <5B34AF33D291D311A06D0004AC1509D7C5B98F@unity-mail.icomverse.com> From: "Vilenchik, Osnat" To: ldap@umich.edu, ietf-ldapext@netscape.com Cc: "Kessler, Dror" Subject: Netscape SDK Socket Blocking Problem? (WSAEINPROGRESS) Date: Mon, 28 Feb 2000 19:09:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Hj5VEB.A.bpB.owqu4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi > We are having problems with heavy loads on the Netscape SDK. When running > many threads (200 or so), each one issuing a search request, the socket > layer (window sockets) starts returning a WSAEINPROGRESS error to the SDK. > This indicates that the socket is blocked (full of pending data) and can > not accept data for now (the condition is temporary since soon after, the > socket gets out of the blocked mode as it sends the buffered data to the > server). > > The SDK code (as available from Mozilla, Sdk version 3) regards any error > from the socket layer on a write (send) as a cause for returning an > LDAP_SERVER_DOWN error. > > This causes a problem since although the connection is not actually down, > the Sdk says so. This results in our error recovery code being triggered, > causing all sorts of other complications. > > Question: is it really so - that once an error code (even one that > represents a temporary difficulty) is received by the Netscape Sdk code it > regards the connection is dead? > Did anyone had such an experience? Are you aware of any SDK which handles such cases? Thanx, Ossie Vilenchik Office: 972-3-7655759 Fax: 972-3-6452855 e-mail: osnat_vilenchik@icomverse.com From list@netscape.com Mon Feb 28 14:19: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 OAA17974 for ; Mon, 28 Feb 2000 14:19: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 LAA22047; Mon, 28 Feb 2000 11:15:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA12004; Mon, 28 Feb 2000 11:17:20 -0800 (PST) Resent-Date: Mon, 28 Feb 2000 11:17:20 -0800 (PST) Message-ID: <38BAC845.C786614D@whistle.com> Date: Mon, 28 Feb 2000 11:11:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: "Vilenchik, Osnat" CC: ldap@umich.edu, ietf-ldapext@netscape.com, "Kessler, Dror" Subject: Re: [ldap] Netscape SDK Socket Blocking Problem? (WSAEINPROGRESS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"vSY5KD.A.F7C.-msu4"@glacier> 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 Vilenchik, Osnat wrote: > > We are having problems with heavy loads on the Netscape > > SDK. When running many threads (200 or so), each one > > issuing a search request, the socket layer (window > > sockets) starts returning a WSAEINPROGRESS error to the > > SDK. This indicates that the socket is blocked (full > > of pending data) and can not accept data for now (the > > condition is temporary since soon after, the socket > > gets out of the blocked mode as it sends the buffered > > data to the server). This is arguably a bug in the sockets implementation; the write attempt should be blocked until it can be successfully completed by the operating system, instead of returning a "try again later, I have brain damage right now" error. Clearly, the SDK needs to work around the brain damage of the OS on which it is expected to run (unfortunate but true, I'm afraid). It's terrifically tempting to "punish" the damaged OS by spinning on the write until it can be successfully completed... moreso because it would avoid having to write a seperate retry latency mechanism to work around the OS being "too busy to take commands from you right now". Conventional "wisdom" would tell us "start another thread to hold the retry"... 8-p -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. From list@netscape.com Mon Feb 28 21:23:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25814 for ; Mon, 28 Feb 2000 21:23: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 SAA16503; Mon, 28 Feb 2000 18:18:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA07420; Mon, 28 Feb 2000 18:22:12 -0800 (PST) Resent-Date: Mon, 28 Feb 2000 18:22:12 -0800 (PST) Message-ID: <38BB2DF0.D3B7596F@us.oracle.com> Date: Mon, 28 Feb 2000 18:24:48 -0800 From: Hari Sastry X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: (no subject) Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"qZRm2.A.qzB.T1yu4"@glacier> 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 Add me. From list@netscape.com Tue Feb 29 06:27:59 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14936 for ; Tue, 29 Feb 2000 06:27:59 -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 DAA17817; Tue, 29 Feb 2000 03:22:40 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA21378; Tue, 29 Feb 2000 03:26:47 -0800 (PST) Resent-Date: Tue, 29 Feb 2000 03:26:47 -0800 (PST) Message-Id: <200002291126.GAA14849@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldap-taxonomy-02.txt Date: Tue, 29 Feb 2000 06:26:42 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"Pa3tsD.A.qNF.1z6u4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : A Taxonomoy of Methods for LDAP Clients Finding Servers Author(s) : R. Moats, R. Hedberg Filename : draft-ietf-ldapext-ldap-taxonomy-02.txt Pages : 5 Date : 28-Feb-00 There are several different methods for a LDAP client to find a LDAP server. This draft discusses these methods and provides pointers for interested parties to learn more about implementing a particular method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-taxonomy-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-ldap-taxonomy-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-ldap-taxonomy-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000228125616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-taxonomy-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-taxonomy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000228125616.I-D@ietf.org> --OtherAccess-- --NextPart--