From ldapext-bounces@ietf.org Wed Jan 5 16:35:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21119 for ; Wed, 5 Jan 2005 16:35:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmIhn-0006M6-8W; Wed, 05 Jan 2005 16:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmIXt-0005vc-1k for ldapext@megatron.ietf.org; Wed, 05 Jan 2005 16:18:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17832 for ; Wed, 5 Jan 2005 16:18:17 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmIkT-0005n6-GY for ldapext@ietf.org; Wed, 05 Jan 2005 16:31:24 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.34) id 1CmIXi-0000XM-E9 for ldapext@ietf.org; Wed, 05 Jan 2005 22:18:10 +0100 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CmIXa-0000NU-EG for ldapext@ietf.org; Wed, 05 Jan 2005 22:18:02 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.30) id 1CmIXa-0001hR-C3 for ldapext@ietf.org; Wed, 05 Jan 2005 22:18:02 +0100 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Wed, 05 Jan 2005 22:18:02 +0100 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [ldapext] Common typo: Lightweight Directory *Application* Protocol X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I've just noticed that lots of places call LDAP the Lightweight Directory *Application* Protocol instead of *Access* protocol, including: - RFC 2820 (Access Control Requirements for LDAP), - draft-ietf-ldapext-acl-model-08.txt (Access Control Model for LDAPv3), - draft-sermersheim-ldap-subordinate-scope-01.txt (Subordinate Subtree Search Scope for LDAP), - draft-sermersheim-ldap-distproc-01.txt (Distributed Procedures for LDAP Operations). -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jan 6 00:25:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26179 for ; Thu, 6 Jan 2005 00:25:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmQ5v-0001zz-Au; Thu, 06 Jan 2005 00:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmQ2w-0000SY-Cz for ldapext@megatron.ietf.org; Thu, 06 Jan 2005 00:18:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25954 for ; Thu, 6 Jan 2005 00:18:50 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmQFb-0004a2-IB for ldapext@ietf.org; Thu, 06 Jan 2005 00:32:02 -0500 Received: from gypsy.OpenLDAP.org (router.boolean.net [198.144.206.49]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j065ImCh072457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jan 2005 05:18:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.0.14.0.20050105211625.02818d20@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 05 Jan 2005 21:18:23 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Common typo: Lightweight Directory *Application* Protocol In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 01:18 PM 1/5/2005, Hallvard B Furuseth wrote: >I've just noticed that lots of places call LDAP the Lightweight >Directory *Application* Protocol instead of *Access* protocol, >including: > >- RFC 2820 (Access Control Requirements for LDAP), Please report this as errata to the RFC Editor . >- draft-ietf-ldapext-acl-model-08.txt (Access Control Model for LDAPv3), Dead. >- draft-sermersheim-ldap-subordinate-scope-01.txt > (Subordinate Subtree Search Scope for LDAP), >- draft-sermersheim-ldap-distproc-01.txt > (Distributed Procedures for LDAP Operations). I suspect Jim will address prior to progression.... Thanks, Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jan 6 07:37:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03595 for ; Thu, 6 Jan 2005 07:37:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmWoU-0001iW-HI; Thu, 06 Jan 2005 07:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmWmF-0001H3-W0 for ldapext@megatron.ietf.org; Thu, 06 Jan 2005 07:30:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03150 for ; Thu, 6 Jan 2005 07:30:07 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmWyz-0005Qb-4V for ldapext@ietf.org; Thu, 06 Jan 2005 07:43:20 -0500 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.34) id 1CmWm8-0005LJ-AS; Thu, 06 Jan 2005 13:30:00 +0100 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1CmWlz-0007Be-NJ; Thu, 06 Jan 2005 13:29:51 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.30) id 1CmWlx-0008Uj-50; Thu, 06 Jan 2005 13:29:49 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 6 Jan 2005 13:29:49 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Common typo: Lightweight Directory *Application* Protocol In-Reply-To: <6.2.0.14.0.20050105211625.02818d20@mail.openldap.org> References: <6.2.0.14.0.20050105211625.02818d20@mail.openldap.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga writes: >At 01:18 PM 1/5/2005, Hallvard B Furuseth wrote: >>I've just noticed that lots of places call LDAP the Lightweight >>Directory *Application* Protocol instead of *Access* protocol, >>including: >> >>- RFC 2820 (Access Control Requirements for LDAP), > > Please report this as errata to the RFC Editor > . Done. > (...) -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jan 6 10:45:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17199 for ; Thu, 6 Jan 2005 10:45:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZjD-0004XU-Tt; Thu, 06 Jan 2005 10:39:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZgl-0003zB-8y for ldapext@megatron.ietf.org; Thu, 06 Jan 2005 10:36:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16732 for ; Thu, 6 Jan 2005 10:36:37 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmZtV-0001ke-Rj for ldapext@ietf.org; Thu, 06 Jan 2005 10:49:53 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 06 Jan 2005 08:36:04 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.3 Date: Thu, 06 Jan 2005 08:35:27 -0700 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Common typo: Lightweight Directory *Application* Protocol Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163708791==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org 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. --===============0163708791== Content-Type: multipart/alternative; boundary="=__Part012190AF.0__=" 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. --=__Part012190AF.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Must have been daydreaming. Thanks for the catch. Jim >>> Hallvard B Furuseth 1/5/05 2:18:02 PM >>> I've just noticed that lots of places call LDAP the Lightweight Directory *Application* Protocol instead of *Access* protocol, including: - RFC 2820 (Access Control Requirements for LDAP), - draft-ietf-ldapext-acl-model-08.txt (Access Control Model for LDAPv3), - draft-sermersheim-ldap-subordinate-scope-01.txt (Subordinate Subtree Search Scope for LDAP), - draft-sermersheim-ldap-distproc-01.txt (Distributed Procedures for LDAP Operations). -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part012190AF.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Must have been daydreaming.  Thanks for the catch.
 
Jim

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.= no> 1/5/05 2:18:02 PM >>>
I've just noticed that lots of = places call LDAP the Lightweight
Directory *Application* Protocol = instead of *Access* protocol,
including:

- RFC 2820 (Access = Control Requirements for LDAP),

- draft-ietf-ldapext-acl-model-08.tx= t (Access Control Model for LDAPv3),

- draft-sermersheim-ldap-subord= inate-scope-01.txt
(Subordinate Subtree Search Scope for LDAP),

-= draft-sermersheim-ldap-distproc-01.txt
(Distributed Procedures for = LDAP Operations).

--
Hallvard

___________________________= ____________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext<= /A>
--=__Part012190AF.0__=-- --===============0163708791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0163708791==-- From ldapext-bounces@ietf.org Thu Jan 20 19:59:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02828 for ; Thu, 20 Jan 2005 19:59:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crn42-0003a1-FL; Thu, 20 Jan 2005 19:54:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crn0R-0002wj-Fj for ldapext@megatron.ietf.org; Thu, 20 Jan 2005 19:50:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02332 for ; Thu, 20 Jan 2005 19:50:24 -0500 (EST) Received: from cust3103.vic01.dataco.com.au ([202.63.62.31] helo=amos.eb2bcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrnG3-0001z8-5O for ldapext@ietf.org; Thu, 20 Jan 2005 20:06:46 -0500 Received: from [192.168.1.159] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1) (authenticated as andrew.sciberras) id 41B79F8B00003676; Fri, 21 Jan 2005 11:58:54 +1100 Message-ID: <41F0522E.3000603@eB2Bcom.com> Date: Fri, 21 Jan 2005 11:51:58 +1100 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-au, en-gb, en MIME-Version: 1.0 To: bruce.bergeson@novell.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: Quoted-Printable Cc: Ldapext Subject: [ldapext] draft-bergeson-uddi-ldap-schema-05.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@eB2Bcom.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: Quoted-Printable Hi Bruce, Just a few comments on this revision of the draft. They're mainly=20 editorial. > 3.1 businessEntity=20 > A businessEntity is represented in the directory by the attributes=20 > uddiBusinessKey, uddiAuthorizedName, uddiOperator,=20 > uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag,=20 > uddiCategoryBag, and uddiv3DigitalSignature, along with=20 > corresponding v3 keys viz. uddiv3BusinessKey, as defined in section=20 > 5. =20 I think you mean section 4. It depends if you are talking about the=20 definition of the attributes or the uddiBusinessEntity object class. If your talking about the attributes, then it should be section 4. If=20 your talking about the objectClass, then the subsequent statement in=20 this section indicating that businessEntity is defined in section 6 is=20 contradictory. > The mandatory attribute, uddiBusinessKey, contains the unique=20 > identifier for a given instance of a businessEntity.=20 The above statement implies that there is only one manitory attribute,=20 when there are actually two. I'm not sure whether the intent of the=20 statement is to talk about all manditory attributes, or just this=20 partcular one... So, I would either replace the first word "The" with=20 "A", or go on to talk abot the second mandatory attribute as well. (This applies to other references made in section 3 of this draft). > businessEntity's definition is given in Section 6. =20 I think you mean section 5. > 3.4.1 Representation in the Directory=20 > ... =20 > The mandatory attribute,=20 > uddiTModelKey, contains the unique identifier for a given instance=20 > of a tModel.=20 > =20 Again, this is not the only mandatory attribute. > 3.5.1 Representation in the Directory=20 > ... =20 > The mandatory=20 > attribute, uddiUUID, contains the unique identifier for a given=20 > instance of a publisherAssertion.=20 As above. > 4.11 uddiSortCode=20 Due to the nature of this attribute, would it be beneficial to including=20 an ordering rule? > 4.35 uddiv3DigitalSignature=20 I'm not sure whether you'd be using the directory to do comparisons of=20 such signatures, however if this is the case, then I would recommend a=20 caseExactMatch instead of the caseIgnoreMatch. Since this attribute is not single valued, it may be possible that two=20 different signatures (which differ in case) will not be able to be added=20 to the attribute since your equality matching rule ignores case. > 5.37 uddiv3EntityModificationTime=20 This should be section 4.37 > 4.39 uddiv3SubscriptionFilter > ... > ( IANA-ASSIGNED-OID.4.39 NAME 'uddiv3SubscriptionFilter'=20 > DESC 'UDDIv3 Subscription Filter=EF=BF=BD=20 replace the ? with a ' (This applies to 4.43 and 4.30 as well) Sections 4.37, 4.42, 4.45 and 4.46 use a generalizedTime syntax and a=20 caseIgnoreMatch matching rule. These should be a generalizedTimeMatch=20 matching rule. Regards, _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jan 25 17:27:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20637 for ; Tue, 25 Jan 2005 17:27:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYxV-0000rg-5E; Tue, 25 Jan 2005 17:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYme-0003RA-4L for ldapext@megatron.ietf.org; Tue, 25 Jan 2005 17:03:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16764 for ; Tue, 25 Jan 2005 17:03:33 -0500 (EST) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtZ3P-0003So-Ml for ldapext@ietf.org; Tue, 25 Jan 2005 17:20:57 -0500 Received: from sys-net.it (host40-89.pool8172.interbusiness.it [81.72.89.40]) (authenticated bits=0) by mail.sys-net.it (8.13.3/8.13.3) with ESMTP id j0PM3ESj012156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2005 23:03:14 +0100 DomainKey-Signature: a=rsa-sha1; s=mail; d=sys-net.it; c=simple; q=dns; b=fyp8tIXJ2/gGKUb9/o9GuiSaIQYteH1NdaaKHpTK9NcaCQ688wa7j06f0XkXEXNyi jb3hi2DPgQ7kh1DF5Krmg== Message-ID: <41F6C219.6080509@sys-net.it> Date: Tue, 25 Jan 2005 23:03:05 +0100 From: Pierangelo Masarati User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: [ldapext] Comments to X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, I'm currently implementing the (now expired) version 02 of in OpenLDAP based on the "chain" overlay as first implemented by Howard Chu and subsequently extended by myself. What follows is a collection of considerations that emerged from the implementation and that, perhaps owing to my lack of understanding of some details, I think require a clarification and might be useful for the continuation of the work on the draft. The comments are quite unsorted. 1. Comments 1.1. Return code renaming I suggest to change the name of "chainingRequired" into "requiresChaining" to avoid confusion and symbol clashes with the "requiresChaining" value in the "Behavior" enumeration. 1.2. Return code usage clarification I think you should clarify when the special return codes related to the control need be returned. For instance, if behavior is "chainingRequired" and the operation would return a referral that cannot be chased, I'd return "cannotChain", but for any other "Behavior" case returning a referral is acceptable, and returning a referral is not an error: lists "referral" as a non-error result code in Appendix A.1, so I don't see an application for the other error code you indicate ("chainingRequired"). I suggest you clarify your intentions. 1.3 OPTIONAL values and defaults In the draft, both "Behavior" fields are marked as OPTIONAL. My point is: what's the reason for not providing any? For instance, the "chain" overlay in OpenLDAP's slapd by default acts as if both "Behavior" were "chainingPreferred". If the control is present, but no values are given, I see no point in using the control. Unless you mean that the default behavior of the DSA may differ if the control is present or not; e.g. if no control is present, default to "referralsRequired", while if the control is present, default to "chainingPreferred" (OpenLDAP's slapd without and with the "chain" overlay), and in any case both defaults are left to the implementor. If this is the case, I suggest it is clarified. [technical note: it is not clear to me if, in case none of the values is provided, the crtls_value of the control structure should be empty or null]. 1.4 Operations. It appears from the draft that the control applies to all operations, except "abandon, unbind, and StartTLS"; the second value applies only to search continuations, and may apply to future operations. Should the presence of the second value in other operations among those already defined that do not require it be treated as an error? I think this should be clarified. 1.5 Behavior 1.5.1. "chainingPreferred" and "referralsPreferred" don't present any issue; 1.5.2. "chainingRequired" might be an issue if, in case it cannot be honored, no intermediate results should be returned at all (I'm talking about searches). In fact, unless caching all intermediate results locally upon completion, it is very likely that a referral is met after some entries/other intermediate results have already been returned. If the referral cannot be chased, the operation should be terminated and "cannotChain" be returned. I think it should be clarified if this behavior is acceptable or not. 1.5.3 "referralsRequired" should never fail, because that's the regular behavior in case no chaining capabilities are available; I don't see any issue that might prevent a DSA from returning a referral. Can you clarify why this option is ever supposed to fail? 1.6. Criticality I think the behavior should be discussed in view of the criticality of the control. Would it be correct to simply ignore the "Behavior" in case the control is not critical? It is my understanding that only the "chainingRequired" behavior may suffer from the criticality field being set when referrals cannot be chased; the other options should pose no issues. How should the behavior differ in this case based on the value of the criticality flag? 2. Few notes on the implementation. 2.1. Approach The "chain" overlay in OpenLDAP's slapd uses the LDAP backend to chase referrals in case they're being returned by the underlying backend (or at the frontend level, if used as a global overlay). Credits for both the overlay and the underlying LDAP backend essentially go to Howard Chu. 2.2. Authorization and Security As such, it can exploit the identity assertion capabilities of back-ldap to proxyAuthz the identity of the client while chasing the referral; this provides features like SASL bind, authorization policies based on pattern matching, grouping and so both at the local and at the remote site. The connection can be wrapped in a TLS layer (use ldaps:// referral URIs, or StartTLS over regular ldap:// URIs). 2.3. Relationship with other extensions Interaction with the "manageDSAit" control as described in the draft, although not intended, seems to work as described in the draft. Of course it may need further testing. 2.4. Missing features and possible development I plan to introduce: 2.4.1. authorization based on referral suffix (e.g. only chain requests rooted at ) 2.4.2. authorization based on the referral URI (host/port portion) 2.4.3. authorization based on the protocol scheme (e.g. only ldaps://) 2.4.4. authorization based on some ssf 2.4.5. to allow chaining of multiple DSAs, back-ldap's identity assertion must be modified to allow authentication identity selection based on the DSA that is being chained (now a single identity can be specified, since back-ldap is intended to contact a single URI). 2.4.6. it is not clear yet how the control could interact with further referral chasing operated at the client library's level by the LDAP backend (proxyAuthz and so). 2.4.7 there's yet no provisions to check for loops and so. 2.5. Specific numbers and #defines I'm currently using OIDs and return codes under OpenLDAP's/private space; the macros and the numbers are(from OpenLDAP's HEAD ldap.h): /* LDAP Chaining Behavior Control *//* work in progress */ /* ; * see also LDAP_REQUIRES_CHAINING, LDAP_CANNOT_CHAIN */ #ifdef LDAP_DEVEL #define LDAP_CONTROL_X_CHAINING_BEHAVIOR "1.3.6.1.4.1.4203.666.11.3" #define LDAP_CHAINING_PREFERRED 0 #define LDAP_CHAINING_REQUIRED 1 #define LDAP_REFERRALS_PREFERRED 2 #define LDAP_REFERRALS_REQUIRED 3 #endif /* for the Chaining Behavior control (consecutive result codes requested; * see ) */ #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR #define LDAP_REQUIRES_CHAINING 0x4110 #define LDAP_CANNOT_CHAIN 0x4111 #endif I hope the discussion above, and the quick overview on the current implementation and its todo list, may be of help in stabilizing and completing the draft. Sincerely, p. SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jan 28 13:10:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25645 for ; Fri, 28 Jan 2005 13:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuaU3-0005RL-PA; Fri, 28 Jan 2005 13:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuaRT-0004Xe-1J for ldapext@megatron.ietf.org; Fri, 28 Jan 2005 13:02:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24489 for ; Fri, 28 Jan 2005 13:01:55 -0500 (EST) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuaip-0003SW-ON for ldapext@ietf.org; Fri, 28 Jan 2005 13:19:56 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 28 Jan 2005 11:01:24 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Fri, 28 Jan 2005 11:01:14 -0700 From: "Bruce Bergeson" To: Subject: Re: [ldapext] draft-bergeson-uddi-ldap-schema-05.txt Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496045970==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org 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. --===============0496045970== Content-Type: multipart/alternative; boundary="=__Part5474E2FA.1__=" 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. --=__Part5474E2FA.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Andrew, Thank you for your comments on the draft. I have made the changes that you suggested. 1. changed 'section 5' to 'section 4' 2. replaced 'The' with 'a' 3. changed 'section 6' to 'section 5' 4. added 'ORDERING caseIgnoreOrderingMatch' to uddiSortCode 5. changed from 'EQUALITY caseIgnoreMatch' to 'EQUALITY caseExactMatch' for uddiv3DigitalSignature. It must be a multivalued attribute. 6. changed '5.37' to '4.37' 7. replace the ? with a ' where necessary Thanks again, Bruce Bergeson Sr. Software Engineer (801) 861-3854 Novell, Inc., a leading provider of Net business solutions www.novell.com >>> Andrew Sciberras 1/20/05 5:51:58 PM >>> Hi Bruce, Just a few comments on this revision of the draft. They're mainly editorial. > 3.1 businessEntity > A businessEntity is represented in the directory by the attributes > uddiBusinessKey, uddiAuthorizedName, uddiOperator, > uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag, > uddiCategoryBag, and uddiv3DigitalSignature, along with > corresponding v3 keys viz. uddiv3BusinessKey, as defined in section > 5. I think you mean section 4. It depends if you are talking about the definition of the attributes or the uddiBusinessEntity object class. If your talking about the attributes, then it should be section 4. If your talking about the objectClass, then the subsequent statement in this section indicating that businessEntity is defined in section 6 is contradictory. > The mandatory attribute, uddiBusinessKey, contains the unique > identifier for a given instance of a businessEntity. The above statement implies that there is only one manitory attribute, when there are actually two. I'm not sure whether the intent of the statement is to talk about all manditory attributes, or just this partcular one... So, I would either replace the first word "The" with "A", or go on to talk abot the second mandatory attribute as well. (This applies to other references made in section 3 of this draft). > businessEntity's definition is given in Section 6. I think you mean section 5. > 3.4.1 Representation in the Directory > ... > The mandatory attribute, > uddiTModelKey, contains the unique identifier for a given instance > of a tModel. > Again, this is not the only mandatory attribute. > 3.5.1 Representation in the Directory > ... > The mandatory > attribute, uddiUUID, contains the unique identifier for a given > instance of a publisherAssertion. As above. > 4.11 uddiSortCode Due to the nature of this attribute, would it be beneficial to including an ordering rule? > 4.35 uddiv3DigitalSignature I'm not sure whether you'd be using the directory to do comparisons of such signatures, however if this is the case, then I would recommend a caseExactMatch instead of the caseIgnoreMatch. Since this attribute is not single valued, it may be possible that two different signatures (which differ in case) will not be able to be added to the attribute since your equality matching rule ignores case. > 5.37 uddiv3EntityModificationTime This should be section 4.37 > 4.39 uddiv3SubscriptionFilter > ... > ( IANA-ASSIGNED-OID.4.39 NAME 'uddiv3SubscriptionFilter' > DESC 'UDDIv3 Subscription Filter? replace the ? with a ' (This applies to 4.43 and 4.30 as well) Sections 4.37, 4.42, 4.45 and 4.46 use a generalizedTime syntax and a caseIgnoreMatch matching rule. These should be a generalizedTimeMatch matching rule. Regards, _________________________________________ Andrew Sciberras eB2Bcom - Software Engineer _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part5474E2FA.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andrew,
 
Thank you for your comments on the draft.  I have made the
changes that you suggested.
 
1. changed 'section 5' to 'section 4'
2. replaced 'The' with 'a'
3. changed 'section 6' to 'section 5'
4. added 'ORDERING caseIgnoreOrderingMatch' to uddiSortCode
5. changed from 'EQUALITY caseIgnoreMatch' to 'EQUALITY caseExactMatch= ' for
        uddiv3DigitalSignature.&nbs= p; It must be a multivalued attribute.
6. changed '5.37' to '4.37'
7. replace the ? with a ' where necessary
 
Thanks again,
 
Bruce Bergeson
Sr. Software Engineer
(801) 861-3854
Novell= , Inc., a leading provider of Net business solutions
www.novell.com

>>> Andrew Sciberras = <andrew.sciberras@eB2Bcom.com> 1/20/05 5:51:58 PM >>>
Hi Bruce,

Just a few comments on this = revision of the draft. They're mainly
editorial.

> 3.1 = businessEntity
> A businessEntity is represented in the directory = by the attributes
>    uddiBusinessKey, uddiAuthorize= dName, uddiOperator,
>    uddiDiscoveryURLs, = uddiName, uddiDescription, uddiIdentifierBag,
>    = uddiCategoryBag, and uddiv3DigitalSignature, along with
>  = ;  corresponding v3 keys viz. uddiv3BusinessKey, as defined in = section
>    5. 

I think you mean = section 4. It depends if you are talking about the
definition of the = attributes or the uddiBusinessEntity object class.
If your talking = about the attributes, then it should be section 4. If
your talking = about the objectClass, then the subsequent statement in
this section = indicating that businessEntity is defined in section 6 is
contradictory= .


>    The mandatory attribute, uddiBusinessKe= y, contains the unique
>    identifier for a given = instance of a businessEntity.
The above statement implies that there = is only one manitory attribute,
when there are actually two. I'm not = sure whether the intent of the
statement is to talk about all = manditory attributes, or just this
partcular one... So, I would either = replace the first word "The" with
"A", or go on to talk abot the = second mandatory attribute as well.

(This applies to other = references made in section 3 of this draft).


>  &nb= sp; businessEntity's definition is given in Section 6. 
I think = you mean section 5.


> 3.4.1 Representation in the Directory =
> ...   
>    The mandatory = attribute,
>    uddiTModelKey, contains the unique = identifier for a given instance
>    of a tModel. =
>    
Again, this is not the only mandatory = attribute.

> 3.5.1 Representation in the Directory
> = ...   
>    The mandatory
>&nbs= p;   attribute, uddiUUID, contains the unique identifier for a = given
>    instance of a publisherAssertion.
As = above.


> 4.11 uddiSortCode
Due to the nature of this = attribute, would it be beneficial to including
an ordering rule?

> 4.35 uddiv3DigitalSignature
I'm not sure whether you'd be = using the directory to do comparisons of
such signatures, however if = this is the case, then I would recommend a
caseExactMatch instead of = the caseIgnoreMatch.
Since this attribute is not single valued, it may = be possible that two
different signatures (which differ in case) will = not be able to be added
to the attribute since your equality matching = rule ignores case.


> 5.37 uddiv3EntityModificationTime =
This should be section 4.37


> 4.39 uddiv3SubscriptionFilt= er
>  ...
> ( IANA-ASSIGNED-OID.4.39 NAME 'uddiv3Subscript= ionFilter'
>      DESC 'UDDIv3 Subscription= Filter?

replace the ? with a '
(This applies to 4.43 and 4.30 = as well)



Sections 4.37, 4.42, 4.45 and 4.46 use a generalize= dTime syntax and a
caseIgnoreMatch matching rule. These should be a = generalizedTimeMatch
matching rule.


Regards,
____________= _____________________________
Andrew Sciberras
eB2Bcom - Software = Engineer

_______________________________________________
Ldapext = mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
<= /DIV> --=__Part5474E2FA.1__=-- --===============0496045970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0496045970==--