From ldapext-bounces@ietf.org Thu Nov 02 15:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfiwi-0006Mh-7b; Thu, 02 Nov 2006 15:13:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfiwh-0006MZ-S4 for ldapext@ietf.org; Thu, 02 Nov 2006 15:13:51 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfiwc-0007YB-EZ for ldapext@ietf.org; Thu, 02 Nov 2006 15:13:51 -0500 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 kA2KD4dn008534; Thu, 2 Nov 2006 14:13:14 -0600 Message-ID: <454A512C.7000900@highlandsun.com> Date: Thu, 02 Nov 2006 12:12:28 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061029 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F07084.40201@sys-net.it> <44F32C3F.50801@redhat.com> <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> In-Reply-To: <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Kurt D. Zeilenga wrote: > 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. > This would be in lieu of defining a new control that hides/exposes the ordering prefixes? Looks like I never replied to the other post either: > 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?" For X-ORDERED 'SIBLINGS' yes, this is only intended to work on attributes that are the RDN. The actual requirement that I meant to express is that a single attribute cannot have both properties. I'll fix the language here. >> >> "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. >> That's a good point. I only envisioned using this for configuration info that doesn't change frequently and isn't changed by more than one entity. If it turns out that this is just a cute idea that's more trouble than it's worth we can just drop it, since the basic goal of preserving ordering is still generally applicable. >> 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. >> Right. Presumably if we follow Kurt's suggestion, the data cannot be imported into an unaware server since it will not support the specified syntaxes, so that problem would disappear. Using a control, such that unaware directory agents can touch the data, would seem to be inviting corruption (or at least misuse) of the data. -- -- 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 Thu Nov 02 15:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfj70-0006yw-Nf; Thu, 02 Nov 2006 15:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfj6y-0006yq-GJ for ldapext@ietf.org; Thu, 02 Nov 2006 15:24:29 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfj6x-00008x-3y for ldapext@ietf.org; Thu, 02 Nov 2006 15:24:28 -0500 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 kA2KO5Ad008743 for ; Thu, 2 Nov 2006 14:24:16 -0600 Message-ID: <454A53C1.50605@highlandsun.com> Date: Thu, 02 Nov 2006 12:23:29 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061029 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Ldapext Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F07084.40201@sys-net.it> <44F32C3F.50801@redhat.com> <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> <454A512C.7000900@highlandsun.com> In-Reply-To: <454A512C.7000900@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Chu wrote: >>> >>> "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. >>> > > That's a good point. I only envisioned using this for configuration > info that doesn't change frequently and isn't changed by more than one > entity. If it turns out that this is just a cute idea that's more > trouble than it's worth we can just drop it, since the basic goal of > preserving ordering is still generally applicable. Reconsidering that. This is no worse than multiple clients performing Modify/Replace operations concurrently. Also, it's essential to be able to specify the ordinal position when inserting new values into a list, or changing an existing value without altering its position. -- -- 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 Thu Nov 02 15:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfjFD-0007wW-NM; Thu, 02 Nov 2006 15:32:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfjFC-0007wQ-18 for ldapext@ietf.org; Thu, 02 Nov 2006 15:32:58 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfjFA-0001BV-Mt for ldapext@ietf.org; Thu, 02 Nov 2006 15:32:58 -0500 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 kA2KWPV6008904; Thu, 2 Nov 2006 14:32:33 -0600 Message-ID: <454A55B5.2030700@highlandsun.com> Date: Thu, 02 Nov 2006 12:31:49 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061029 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F07084.40201@sys-net.it> <44F32C3F.50801@redhat.com> <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> In-Reply-To: <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Kurt D. Zeilenga wrote: > 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. > > Then again, we could just sidestep all of this schema-extension hassle and just define a suite of new syntaxes: orderedInteger orderedDirectoryString orderedOctetString orderedDistinguishedName and so on. -- -- 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 Thu Nov 02 16:20:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfjxy-0003cT-UJ; Thu, 02 Nov 2006 16:19:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfjxy-0003Zn-A9 for ldapext@ietf.org; Thu, 02 Nov 2006 16:19:14 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfjxx-0006ik-2g for ldapext@ietf.org; Thu, 02 Nov 2006 16:19:14 -0500 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 kA2LIk2J004659; Thu, 2 Nov 2006 16:18:46 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kA2LIjtg000371; Thu, 2 Nov 2006 16:18:46 -0500 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.11.20060308/8.12.11) with ESMTP id kA2LIiDu001469; Thu, 2 Nov 2006 16:18:45 -0500 Message-ID: <454A60AB.2000800@redhat.com> Date: Thu, 02 Nov 2006 13:18:35 -0800 From: Pete Rowley User-Agent: Thunderbird 1.5.0.7 (X11/20060911) 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> <44F07084.40201@sys-net.it> <44F32C3F.50801@redhat.com> <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> <454A512C.7000900@highlandsun.com> <454A53C1.50605@highlandsun.com> In-Reply-To: <454A53C1.50605@highlandsun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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="===============1894828477==" Errors-To: ldapext-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1894828477== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070107070407050805000104" This is a cryptographically signed message in MIME format. --------------ms070107070407050805000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > Howard Chu wrote: >>>> >>>> "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. >>>> >> >> That's a good point. I only envisioned using this for configuration >> info that doesn't change frequently and isn't changed by more than >> one entity. If it turns out that this is just a cute idea that's more >> trouble than it's worth we can just drop it, since the basic goal of >> preserving ordering is still generally applicable. > > Reconsidering that. This is no worse than multiple clients performing > Modify/Replace operations concurrently. In those cases race conditions modify the success of the operation, not the resulting state. > Also, it's essential to be able to specify the ordinal position when > inserting new values into a list, or changing an existing value > without altering its position. > Right, but the point was it is subject to race conditions. -- Pete --------------ms070107070407050805000104 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 CSqGSIb3DQEJBTEPFw0wNjExMDIyMTE4MzVaMCMGCSqGSIb3DQEJBDEWBBSegETol2kn/uxq ouHi2kYCskx4bDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAfpIGR+elR4I9kSsebvv7j1VDAfitq81Mi2IT6Nbk3HcSnck2plx8FndVrWX+ W7N0TWP5mk2BndRSx205F+n+wq2WIzTWLNynOEfOl3fUS6a5YGNra3lqpKL2uFqMEJP0nvGe kLUTuxLN8MgD5xFjrtubpZ26n4xWro99gAcc6uPhOlc/DVwfRZEWe+fbQ9ZA+dd13w36pA3d 2iYPC5ZBY9OQU3YYbfhyh2k2YOmgU/lv/vbXIcfYU6dLA/bG8cEH5qyECM7DwE17OXJPADJh xZJlVc7LnJJfH7QEEkW6muRya2Op6dhoW2I7RDYVwayaQe2AtME+YjOivpwlbqUoJQAAAAAA AA== --------------ms070107070407050805000104-- --===============1894828477== 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 --===============1894828477==-- From ldapext-bounces@ietf.org Thu Nov 02 16:44:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkLj-00087E-O6; Thu, 02 Nov 2006 16:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkLj-00084r-24 for ldapext@ietf.org; Thu, 02 Nov 2006 16:43:47 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfkLh-0001cF-NM for ldapext@ietf.org; Thu, 02 Nov 2006 16:43:47 -0500 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 kA2LhAFt010246; Thu, 2 Nov 2006 15:43:22 -0600 Message-ID: <454A664A.6030900@highlandsun.com> Date: Thu, 02 Nov 2006 13:42:34 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061029 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Pete Rowley Subject: Re: [ldapext] Comments: draft-chu-ldap-xordered-00.txt References: <4461846B.4030105@eB2Bcom.com> <4461A24B.70203@highlandsun.com> <44F07084.40201@sys-net.it> <44F32C3F.50801@redhat.com> <7.0.1.0.0.20060828135558.02303bb8@OpenLDAP.org> <454A512C.7000900@highlandsun.com> <454A53C1.50605@highlandsun.com> <454A60AB.2000800@redhat.com> In-Reply-To: <454A60AB.2000800@redhat.com> 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@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: , Errors-To: ldapext-bounces@ietf.org Pete Rowley wrote: > Howard Chu wrote: >> Howard Chu wrote: >>>>> >>>>> "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. >>>>> >>> >>> That's a good point. I only envisioned using this for configuration >>> info that doesn't change frequently and isn't changed by more than >>> one entity. If it turns out that this is just a cute idea that's >>> more trouble than it's worth we can just drop it, since the basic >>> goal of preserving ordering is still generally applicable. >> >> Reconsidering that. This is no worse than multiple clients performing >> Modify/Replace operations concurrently. > In those cases race conditions modify the success of the operation, > not the resulting state. Not sure what you mean here. Modify/replace always succeeds (as far as each client knows) and the resulting state is determined by last-writer-wins. >> Also, it's essential to be able to specify the ordinal position when >> inserting new values into a list, or changing an existing value >> without altering its position. >> > Right, but the point was it is subject to race conditions. I guess we can punt this and recommend use of the RFC4528 assertion control on the modifications when multiple updaters may be active. E.g., assert (entryCSN=xxx) representing the entry's CSN value the last time we looked at the entry. -- -- 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 Fri Nov 03 01:58:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfszV-00019v-7J; Fri, 03 Nov 2006 01:57:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfszU-00019i-04 for ldapext@ietf.org; Fri, 03 Nov 2006 01:57:24 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfszR-0005tA-C0 for ldapext@ietf.org; Fri, 03 Nov 2006 01:57:23 -0500 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 kA36unA5021922; Fri, 3 Nov 2006 00:56:59 -0600 Message-ID: <454AE80E.6020606@highlandsun.com> Date: Thu, 02 Nov 2006 22:56:14 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061029 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Steve Trottier Subject: Re: [ldapext] Representing LDAP protocol in LDAP References: <425E68F6.4020702@highlandsun.com> <4352C613.3070908@highlandsun.com> <4354C6E9.0703.006F.0@novell.com> <43552317.3000700@highlandsun.com> <43552C4B.0703.006F.0@novell.com> In-Reply-To: <43552C4B.0703.006F.0@novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Errors-To: ldapext-bounces@ietf.org Steve Trottier wrote: > Thank you for those answers. Regarding where to put the operational > attribute with the DN of the audit container, I think either (or both) > would work. The preferred method would depend on what a client's purpose > would be in reading the audit information. If you wanted to see all > accesses or writes to a particular entry in the directory, then your > second suggestion of the attribute being available on all entries under > a naming context would be helpful because you could read the value of > the container directly from the entry of interest. If, however, your > purpose in reading the audit information was to replicate or synchronize > directory data, then you would probably just want a quick way to find > which container or containers you should poll for updates. Searching the > rootDSE for naming contexts and then the naming contexts for their audit > containers would work well in that case. Interestingly, these two > methods are very similar to the current methods of finding a > subschemasubentry, which makes sense. > I've added an operational attribute for this purpose to the draft. An updated draft is available on http://highlandsun.com/hyc/drafts; since it still depends on the xordered draft which has more changes coming I'm holding off on resubmitting it at the moment. Aside from the new operational attribute, and updating RFC references, not much has changed here. > >>>> Howard Chu 10/18/2005 10:30:15 am >>> >>>> > ... There is currently no formal mechanism to advertise the > availability of this feature. I realize that's a hole here. > -- -- 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 Thu Nov 23 17:19:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMu2-0001DP-KF; Thu, 23 Nov 2006 17:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMu1-0001D0-Av for ldapext@ietf.org; Thu, 23 Nov 2006 17:18:41 -0500 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnMty-0006LA-05 for ldapext@ietf.org; Thu, 23 Nov 2006 17:18:41 -0500 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 kANMIHwg002263; Thu, 23 Nov 2006 16:18:22 -0600 Message-ID: <45661E2D.1060303@highlandsun.com> Date: Thu, 23 Nov 2006 14:18:21 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a MIME-Version: 1.0 To: Vithalprasad Gaitonde Subject: Re: [ldapext] referencing one LDIF file from another References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: ldapext-bounces@ietf.org Vithalprasad Gaitonde wrote: > > >>> Howard Chu <_ hyc@highlandsun.com _ > > 11/23/2004 12:33:06 PM >>> > > Vithalprasad Gaitonde wrote: > > > RFC2849 doesnt seem to provide a way to include one ldif file into > > > another ldif file though it does allow referencing an external > file for > > > an attribute value. > > > Has this been considered in the past ? > > > It seems like a useful thing to have when there are dependencies > across > > > several ldif files. > > > > I agree, I would definitely have a use for this. Haven't thought about > > what the syntax should be yet. Any more plans for RFC2849? I note that the current grammar has a hole, wrt the mod-spec behavior shown in the examples. There's nothing in the RFC that says the AttributeDescriptions in the attrval-specs of a mod-spec have to match the AttributeDescription in the mod-spec. As such, the following creates a valid Modify request, even though it's clear from the examples that this is not an intended behavior: dn: dc=example,dc=com changetype: modify add: cn cn: foo sn: bar description: xyzzy Of course the AttributeDescription in the mod-spec is mostly redundant; it's only necessary when deleting all the values of an attribute. If we're going to kick out a version 2 LDIF that supports "include:" I'd also like to see something like the syntax I used in my logschema draft replacing this deficient mod-spec syntax. -- -- 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