From ldapext-bounces@ietf.org Sat Aug 26 12:05:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH0d9-0001oz-5q; Sat, 26 Aug 2006 12:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH0d7-0001ot-DG for ldapext@ietf.org; Sat, 26 Aug 2006 12:03:29 -0400 Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GH0d2-0004Nw-UT for ldapext@ietf.org; Sat, 26 Aug 2006 12:03:29 -0400 Received: from [192.168.1.199] (dossi.sys-net.it [87.28.220.33]) (authenticated bits=0) by mail.sys-net.it (8.13.5.20060308/8.13.3) with ESMTP id k7QG1b0h021905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Aug 2006 18:01:38 +0200 Message-ID: <44F07084.40201@sys-net.it> Date: Sat, 26 Aug 2006 18:02:12 +0200 From: Pierangelo Masarati User-Agent: Mail/News 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Howard Chu Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> In-Reply-To: <4461A24B.70203@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on www.sys-net.it X-SysNet-MailScanner-Information: postmaster@sys-net.it X-SysNet-MailScanner: X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Ldapext 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: , Errors-To: ldapext-bounces@ietf.org Howard, a couple of quick short comments (one is editorial: in example (3) of section 4.3 you issue a modrdn and supply a DN "olcDatabase={99}ldif,cn=config" as the newrdn field; it should likely be "olcDatabase={99}ldif" instead). The other emerged from the improper use of an X-ORDERED 'VALUES' attribute as naming attribute by an OpenLDAP user (). I think attributes with this extension could create problems when used as naming attributes in a RDN. I see two possibilities: 1) the distinguished value does not report the ordering portion (if it does, there could be confusion with X-ORDERED 'SIBLINGS', though); this approach would make data appear inconsistent to applications that do not recognize the extension, but at least would prevent the need to rename an entry if the ordering of a naming attribute changes; for example, consider an "ov" attribute with the X-ORDERED 'VALUES' extension: dn: ov=foo,dc=example,dc=com ov: {0}foo ov: {1}bar 2) the X-ORDERED 'VALUES' inhibits an attribute from being used to name an entry. I favor the second approach; that is, recommend implementors that implement the X-ORDERED 'VALUES' extension to disallow them as naming attributes, because it looks simpler and cleaner. I wouldn't go for the first approach, unless I'm missing any significant advantage. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Aug 26 18:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH71j-0006gI-P4; Sat, 26 Aug 2006 18:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH71i-0006gD-Lq for ldapext@ietf.org; Sat, 26 Aug 2006 18:53:18 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GH71d-0006Yv-Ay for ldapext@ietf.org; Sat, 26 Aug 2006 18:53:18 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id k7QMr3Xp021873; Sat, 26 Aug 2006 17:53:03 -0500 Message-ID: <44F0D0D9.7000800@highlandsun.com> Date: Sat, 26 Aug 2006 15:53:13 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060823 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Pierangelo Masarati Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F06E71.4030209@sys-net.it> In-Reply-To: <44F06E71.4030209@sys-net.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Ldapext 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: , Errors-To: ldapext-bounces@ietf.org Pierangelo Masarati wrote: > Howard, > Thanks. Agreed, X-ORDERED 'VALUES' attributes should be prohibited from use as naming attributes. I'll revise the draft shortly. > a couple of quick short comments (one is editorial: in example (3) of > section 4.3 you issue a modrdn and supply a DN > "olcDatabase={99}ldif,cn=config" as the newrdn field; it should likely > be "olcDatabase={99}ldif" instead). > > The other emerged from the improper use of an X-ORDERED 'VALUES' > attribute as naming attribute by an OpenLDAP user > (). > I think attributes with this extension could create problems when used > as naming attributes in a RDN. I see two possibilities: > > 1) the distinguished value does not report the ordering portion (if it > does, there could be confusion with X-ORDERED 'SIBLINGS', though); > this approach would make data appear inconsistent to applications that > do not recognize the extension, but at least would prevent the need to > rename an entry if the ordering of a naming attribute changes; for > example, consider an "ov" attribute with the X-ORDERED 'VALUES' > extension: > > dn: ov=foo,dc=example,dc=com > ov: {0}foo > ov: {1}bar > > 2) the X-ORDERED 'VALUES' inhibits an attribute from being used to > name an entry. > > > I favor the second approach; that is, recommend implementors that > implement the X-ORDERED 'VALUES' extension to disallow them as naming > attributes, because it looks simpler and cleaner. I wouldn't go for > the first approach, unless I'm missing any significant advantage. > > Cheers, p. > > > SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Aug 28 13:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlDE-0005ig-Ox; Mon, 28 Aug 2006 13:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlDC-0005gI-LY for ldapext@ietf.org; Mon, 28 Aug 2006 13:47:50 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHlDB-0004cX-Bo for ldapext@ietf.org; Mon, 28 Aug 2006 13:47:50 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7SHljGj031377; Mon, 28 Aug 2006 13:47:45 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7SHlj8W006456; Mon, 28 Aug 2006 13:47:45 -0400 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k7SHlhgS022766; Mon, 28 Aug 2006 13:47:44 -0400 Message-ID: <44F32C3F.50801@redhat.com> Date: Mon, 28 Aug 2006 10:47:43 -0700 From: Pete Rowley User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F07084.40201@sys-net.it> In-Reply-To: <44F07084.40201@sys-net.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Ldapext 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="===============0208370580==" Errors-To: ldapext-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0208370580== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907050504030807000605" This is a cryptographically signed message in MIME format. --------------ms010907050504030807000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Since this popped up this morning - I did a run through: "The "X-ORDERED 'SIBLINGS'" extension is used with single-valued attributes to maintain the order of all the onelevel children of a parent entry. That is, ordering will be maintained for all the child entries whose RDNs are all of the same AttributeType." Is it the intent that this is to work only on attribute values that are also the RDN? If so, why the requirement that the attributes be single valued? If not, do you mean "for example", rather than "that is?" "The ordering-prefix may also be used in Modification requests to specify which values to delete, and in which position values should be added. When processing deletions and insertions, all of the ordinals are recounted after each individual modification." I think this is unworkable in any situation where multiple clients perform operations - clearly there will be race conditions. The only way to avoid those race conditions in the delete case is to include the value, which makes the ordering element moot. I don't believe there is a reasonable method of avoiding race conditions for inserts in the current scheme. Perhaps adding a control with the values either side of the insert point would help, at least by notifying the time T2 modifier that things have changed. I also have concerns regarding the use of attribute values to store ordering information. This would likely cause issues with clients that know nothing of the extension and would make the servers that implement it non-compliant since they would store values that happen to look like they have ordinals incorrectly. Adding a control that determined when values are to be considered to have ordinals and when to return ordinals would side step any issues here. This would also help clients to know when the extension is supported or not. Note that " Since the ordering-prefix is stored with the attribute values, it will be propagated to any clients or servers that access the data." is only a benefit when all servers implement the extension, those that do not and that import the data will appear to support the extension, and therefore clients may be fooled into relying on incorrect results. Regards -- Pete --------------ms010907050504030807000605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA4MjgxNzQ3NDNaMCMGCSqGSIb3DQEJBDEWBBSoYdKF0XbJKvXl 5ig5EOKqHge1fzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAGGqud56oQhNe6KR4zG9LtPmUQyGH/dh4A5h8LXIFTLNps4i42/xe7UPltk/y 5bQ0a5sD/kg78+ayGk6jTGk4mx1qBD2lELRJPpn9DCHaaepNdmg5uAmiEvQir4Rrf+S9ncOf qHjpGLO52i5NL9PpuwqNjuWQ6kUpTER4GyXy+7ylJ/LpaCW2jcbzw15+6+iv8N8Gr6g+HDWN QrAzP/pBaqwkPn6bksIJCrz8eqq3tRvqAUGOVZTdZTTwjz1w4Vak0gpXHNAO2Trez1tNlqQf M2Sf0lwTkJGfPrzlGArMBic/REpy7yAXHNwqA3c3mU2uyp47P29zThp6KxIC4cWXDAAAAAAA AA== --------------ms010907050504030807000605-- --===============0208370580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0208370580==-- From ldapext-bounces@ietf.org Mon Aug 28 17:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoQa-0001Do-9M; Mon, 28 Aug 2006 17:13:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoPj-0000qK-Nl for ldapext@ietf.org; Mon, 28 Aug 2006 17:12:59 -0400 Received: from [2001:4f8:3:ba:2e0:18ff:fe02:efec] (helo=boole.openldap.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHoJJ-0002th-Al for ldapext@ietf.org; Mon, 28 Aug 2006 17:06:24 -0400 Received: from gypsy.OpenLDAP.org (71-80-218-136.dhcp.crcy.nv.charter.com [71.80.218.136] (may be forged)) by boole.openldap.org (8.13.6/8.13.6) with ESMTP id k7SL63pg051298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Aug 2006 21:06:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 14:05:43 -0700 To: Pete Rowley From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt In-Reply-To: <44F32C3F.50801@redhat.com> References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F07084.40201@sys-net.it> <44F32C3F.50801@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Ldapext 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: , Errors-To: ldapext-bounces@ietf.org It might be better for the schema to defined like: ( ATTRIBUTE-OID NAME 'orderedValue' EQUALITY caseIgnoreMatch SYNTAX ORDERED-VALUES-SYNTAX-OID X-ORDERED 'SIBLINGS' X-ORDERED-SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) So that to an unaware client, the syntax is something they are not familiar with. For an aware client, the ORDERED-VALUES-SYNTAX-OID is some encoding of something like: orderedValue ::= SEQUENCE { position INTEGER OPTIONAL, value OCTET STRING } where value is of the X-ORDERED-SYNTAX syntax. At 10:47 AM 8/28/2006, Pete Rowley wrote: >Since this popped up this morning - I did a run through: > >"The "X-ORDERED 'SIBLINGS'" extension is used with single-valued > > attributes to maintain the order of all the onelevel children of a > > parent entry. That is, ordering will be maintained for all the child > > entries whose RDNs are all of the same AttributeType." > >Is it the intent that this is to work only on attribute values that are also the RDN? >If so, why the requirement that the attributes be single valued? >If not, do you mean "for example", rather than "that is?" > >"The ordering-prefix may also be used in Modification requests to > > specify which values to delete, and in which position values should > be added. When processing deletions and insertions, all of the > ordinals are recounted after each individual modification." > >I think this is unworkable in any situation where multiple clients perform operations - clearly there will be race conditions. The only way to avoid those race conditions in the delete case is to include the value, which makes the ordering element moot. I don't believe there is a reasonable method of avoiding race conditions for inserts in the current scheme. Perhaps adding a control with the values either side of the insert point would help, at least by notifying the time T2 modifier that things have changed. > >I also have concerns regarding the use of attribute values to store ordering information. This would likely cause issues with clients that know nothing of the extension and would make the servers that implement it non-compliant since they would store values that happen to look like they have ordinals incorrectly. Adding a control that determined when values are to be considered to have ordinals and when to return ordinals would side step any issues here. This would also help clients to know when the extension is supported or not. > >Note that " > >Since the ordering-prefix is stored with the attribute values, it > will be propagated to any clients or servers that access the data." > > >is only a benefit when all servers implement the extension, those that do not and that import the data will appear to support the extension, and therefore clients may be fooled into relying on incorrect results. > >Regards > > > >-- >Pete > > > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext