From owner-ietf-ldup@imc.org Mon Aug 30 14:49:08 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11041 for ; Mon, 30 Aug 1999 14:49:05 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id LAA07724 for ietf-ldup-bks; Mon, 30 Aug 1999 11:04:59 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA07715 for ; Mon, 30 Aug 1999 11:04:46 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 30 Aug 1999 12:05:32 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Mon, 30 Aug 1999 11:38:27 -0600 From: "Ed Reed" To: , Subject: Info model revs... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_AEF85EFC.6C0D6C97" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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. --=_AEF85EFC.6C0D6C97 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Okay, I'm getting down to brass tacks, on this...here are some of the = realizations I've had trying to nail it down. 1) DSAs for LDAP aren't defined. (see previous note to Mark and the = list). I'll probably have to create one. 2) I've defined the lookup table for replica IDs here, anticipating that = this definition will be used in the replication protocol doc. Needed to = define it here so the description of CSNs would make sense, because 3) the only way to rationally describe the CSNs is to either a) refer to the look up table, defined above, or b) allow the RDN of the replica to be used when the lookup table = doesn't define any numeric mappings All this is necessary because I've got to define the CSN as being a fixed = length string that will be able to use CaseIgnoreString comparison rules = for equality and ordering, so we don't have to create a new syntax for = CSNs (an action item from the Oslo meeting). =20 But, even with fixed length S1 and S2 values (S and s in other descriptions= - which are we using?) in the CSN, the representation of the replica via = the lookup table (I call that a replicaNumber) must also be fixed length, = base 10 encoding, zero padded to the left. Note, however, that if the RDN = name of the replia, what I'm calling the replicaID, won't pass a CaseIgnore= String match, even if it's fixed length space padded to the right, because = CIS matching rules suppress duplicate white space in the match...so unless = the RDN is EXACTLY the same length of non-white-space characters for ALL = replicas referenced in the CSNs, the CIS match won't work. Yes, a server = can parse the string, compare each field of the string appropriately, but = that's what is called a new syntx, which servers MAY implement, but which = we'd like not to require. Bottom line, the only reliable syntax uses the lookup table, with numeric = representations for each replica referenced in the CSNs being transferred/c= ompared. The lookup table is provided by the supplier of CSN information. My notion of allowing the CSN to include the RDN of the entry is to deal = with LDAP Search operations (like READ) which are getting the information = about an entry, including it's CSNs, for administrative purposes, for = instance. In that use, it seems silly to require the definition of a = lookup table, so I provide the RDN values, instead. Does anyone care what is required when the RDN of a replica is changed? = MAY I say that reuse of RDNs is disallowed, or is that as unworkable as I = think it is? Maybe instead of RDN we should use the GUID of the replica, = instead...that would be fixed length, still long enough to benefit from = the lookup table, but easily comparible via CaseIgnoreString. Should = replicas be named by their GUID? (shudder - maybe that goes too far). Reactions, both peacable and violent, are invited. Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed, Technologist Novell Product Management +1 801 222 3944 (new number!) --=_AEF85EFC.6C0D6C97 Content-Type: text/x-vcard Content-Disposition: attachment; filename="Ed Reed.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Ed Reed TEL;WORK:801-222-3944 ORG:;Product Management TEL;PREF;FAX:TBD EMAIL;WORK;PREF;NGW:ED REED@novell.com N:Reed;Ed TITLE:Technologist ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Ed Reed=3D0A=3D ORM-A-211 X-GWUSERID:ED REED END:VCARD --=_AEF85EFC.6C0D6C97-- From owner-ietf-ldup@imc.org Mon Aug 30 14:49:56 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11059 for ; Mon, 30 Aug 1999 14:49:37 -0400 (EDT) Received: by mail.proper.com (8.9.3/8.9.3) id LAA07720 for ietf-ldup-bks; Mon, 30 Aug 1999 11:04:47 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA07714 for ; Mon, 30 Aug 1999 11:04:45 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 30 Aug 1999 12:05:32 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Mon, 30 Aug 1999 11:17:07 -0600 From: "Ed Reed" To: Cc: , , Subject: DSA and Presentation Address definitions from 2256 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_AEF85EFC.62036299" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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. --=_AEF85EFC.62036299 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark -=20 I'm trying to tie down details on the LDUP schema, and am working to = understand RFC2256... Since we'd rather not create new syntaxes for LDUP, I'm trying to avoid = defining the lDAPPresentationAddress originally envisioned...and just us a = distinguishedName to point to the DSA holding a replia from the Replia = subentry. However, 2256 defines DSA object class (section 7.14) as derived from ApplicationEnt= ity (section 7.13), which has an attribute, presentationAddress (section = 5.30) described as "This attribute contains an OSI presentation address", = and is single-valued, to boot. The syntax number is one of your assigned = numbers, it looks like. Has no one actually defined an LDAP DSA object class, yet? Shall I? It = would have a multi-valued attribute specifying URIs (or perhaps a = single-valued URI List?) for contacting the LDAP service, so that = protocol, DNS name or ip address, and socket numbers would all be defined. I don't want to do this unless it's absolutely necessary, but if no one = has done so, so far, I will. Thanks, Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed, Technologist Novell Product Management +1 801 222 3944 (new number!) --=_AEF85EFC.62036299 Content-Type: text/x-vcard Content-Disposition: attachment; filename="Ed Reed.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Ed Reed TEL;WORK:801-222-3944 ORG:;Product Management TEL;PREF;FAX:TBD EMAIL;WORK;PREF;NGW:ED REED@novell.com N:Reed;Ed TITLE:Technologist ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Ed Reed=3D0A=3D ORM-A-211 X-GWUSERID:ED REED END:VCARD --=_AEF85EFC.62036299-- From owner-ietf-ldup@imc.org Tue Aug 31 04:27:06 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04596 for ; Tue, 31 Aug 1999 04:27:05 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id AAA19554 for ietf-ldup-bks; Tue, 31 Aug 1999 00:47:14 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA19549 for ; Tue, 31 Aug 1999 00:47:06 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id ; Tue, 31 Aug 1999 17:49:09 +1000 Message-ID: From: Alan Lloyd To: "'Ed Reed'" , ldup-repl@external.cisco.com, ietf-ldup@imc.org Subject: RE: Info model revs... Date: Tue, 31 Aug 1999 17:49:07 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Re this - Thanks Ed for inviting both peaseful and violent reactions. I cannot offer either. Just my own humble personal opinions. Actually I am personally waiting to see if anyone can get this LDUP stuff to work without blowing their R&D budget... Directory companies are now saying they can support billions of entries - But why would you do that in a replicated single server system? We in fact we theoretically can do 10s of billions etc..across many, many DSAs - distributed and we can store theoretically 10s of gigabytes per attribute and thousands of attributes per entry as well .. Enough of this wonderful theory stuff. The point - is that on large scale (big entry) distributed directory service where multiple updates occur and this CSN stuff has to stay in check, etc - is there any guarantee that this LDUP protocol actually works, scales, provides integrity and commercial robustness to the directory information. - will there be a global GUID administration scheme for replica entries? Not in God's lifetime I think. Given that this CSN stuff requires look up tables or some more attributes stuck somewhere and that where a system carries millions of entries, what load factors are placed on it during replica updates and operational incident recovery.. We have come to like our Multi Master mode of working .. It was less "complex" and avoided many "overheads" :-) regards alan PS - Can those on the list who have models and prototypes on this stuff publish them. I think trying to imagine large scale distributed and replicated information systems, performing thousands of transactions a second with concurrent update collision mechanisms, - that is applied by just "a protocol" and "CSN management" is somewhat daunting. > -----Original Message----- > From: Ed Reed > Sent: Tuesday, August 31, 1999 3:38 AM > To: ldup-repl@external.cisco.com; ietf-ldup@imc.org > Subject: Info model revs... > > Okay, I'm getting down to brass tacks, on this...here are some of the > realizations I've had trying to nail it down. > > 1) DSAs for LDAP aren't defined. (see previous note to Mark and the > list). I'll probably have to create one. > 2) I've defined the lookup table for replica IDs here, anticipating > that this definition will be used in the replication protocol doc. > Needed to define it here so the description of CSNs would make sense, > because > 3) the only way to rationally describe the CSNs is to either > a) refer to the look up table, defined above, or > b) allow the RDN of the replica to be used when the lookup table > doesn't define any numeric mappings > > All this is necessary because I've got to define the CSN as being a > fixed length string that will be able to use CaseIgnoreString > comparison rules for equality and ordering, so we don't have to create > a new syntax for CSNs (an action item from the Oslo meeting). > > But, even with fixed length S1 and S2 values (S and s in other > descriptions - which are we using?) in the CSN, the representation of > the replica via the lookup table (I call that a replicaNumber) must > also be fixed length, base 10 encoding, zero padded to the left. > Note, however, that if the RDN name of the replia, what I'm calling > the replicaID, won't pass a CaseIgnoreString match, even if it's fixed > length space padded to the right, because CIS matching rules suppress > duplicate white space in the match...so unless the RDN is EXACTLY the > same length of non-white-space characters for ALL replicas referenced > in the CSNs, the CIS match won't work. Yes, a server can parse the > string, compare each field of the string appropriately, but that's > what is called a new syntx, which servers MAY implement, but which > we'd like not to require. > > Bottom line, the only reliable syntax uses the lookup table, with > numeric representations for each replica referenced in the CSNs being > transferred/compared. The lookup table is provided by the supplier of > CSN information. > > My notion of allowing the CSN to include the RDN of the entry is to > deal with LDAP Search operations (like READ) which are getting the > information about an entry, including it's CSNs, for administrative > purposes, for instance. In that use, it seems silly to require the > definition of a lookup table, so I provide the RDN values, instead. > > Does anyone care what is required when the RDN of a replica is > changed? MAY I say that reuse of RDNs is disallowed, or is that as > unworkable as I think it is? Maybe instead of RDN we should use the > GUID of the replica, instead...that would be fixed length, still long > enough to benefit from the lookup table, but easily comparible via > CaseIgnoreString. Should replicas be named by their GUID? (shudder - > maybe that goes too far). > > Reactions, both peacable and violent, are invited. > > Ed > > ================= > Ed Reed, Technologist > Novell Product Management > +1 801 222 3944 (new number!) > << File: Ed Reed.vcf >> From owner-ietf-ldup@imc.org Tue Aug 31 08:28:53 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09796 for ; Tue, 31 Aug 1999 08:28:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id EAA23719 for ietf-ldup-bks; Tue, 31 Aug 1999 04:39:53 -0700 (PDT) Received: from tea.uk.pw.com (tea.uk.pw.com [193.131.169.130]) by mail.proper.com (8.9.3/8.9.3) with SMTP id EAA23715 for ; Tue, 31 Aug 1999 04:39:51 -0700 (PDT) From: alison.b.payne@ch.pwcglobal.com Received: by tea.uk.pw.com; id MAA24348; Tue, 31 Aug 1999 12:38:16 +0100 Received: from olive.uk.pw.com(10.44.240.46) by tea.uk.pw.com via smap (4.1) id xma023451; Tue, 31 Aug 99 12:37:08 +0100 Received: from intleursmtp10.uk.pw.com by olive.uk.pw.com (PMDF V5.1-12 #U3018) with SMTP id <0FHB00MZ1UXI7R@olive.uk.pw.com>; Tue, 31 Aug 1999 12:37:19 +0100 (BST) Received: by intleursmtp10.uk.pw.com(Lotus SMTP MTA v1.2 hotfix6 (702.3 8-27-1998)) id 802567DE.003FDEF9 ; Tue, 31 Aug 1999 12:37:25 +0100 Date: Tue, 31 Aug 1999 13:36:22 +0100 Subject: Re: URP - Distinguished Not Present - New Option? To: merrells@netscape.com Cc: stevenlegg@hotmail.com, s.legg@trl.telstra.com.au, ietf-ldup@imc.org Message-id: <802567DE.003FB715.00@intleursmtp10.uk.pw.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline X-Lotus-FromDomain: EMEA-CH@INTL Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi John, Oops. The option as described below is similar if not the same in approach as Option 4 from the original list (thanks, Steve). The timestamp on the deletion flag is equivalent to keeping a deletion record for the remove, but overriding it with the earlier rename operation. This introduces the same history issue as with option 4, and which has been discussed at reasonable length. Steve's mail from 09 August 99, "Re: Delete Not Present - Options and Recommendation" describes the reasons behind the need for history through a number of examples. Regards, Alison Alison Payne 26.08.99 11:43 To: stevenlegg@hotmail.com@internet, merrells@netscape.com@internet cc: ietf-ldup@imc.org@internet Subject: Re: URP - Distinguished Not Present - New Option? (Document link not converted) Hi John, Steve, Here's a summary (below) of the modification I think you are proposing. Is this right? I believe the issue Steve raised (also below) is not a problem with this option. With this option, we have a time in the "overall ordering" after which a remove due to the delete not present flag will not take effect. The problem Steve is discussing comes up when we rely on the "real world time" of deciding when a delete not present flag will not take effect. Comments? Cheers, Alison --------------------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ---- Option (2a) Modification to Deletion-Flag approach The deletion flag is added as currently specified in the draft (ietf-legg-ldup-urp-01.txt) BUT - i. is timestamped with the value of the remove operation which caused it (currently no timestamp) - ii. is discarded when it is clear that no further operations will be received which are older than the timestamp on the deletion flag (currently the deletion flag is held until another rename removes the attribute from the name, and if this occurs, the setting of the flag determines whether the attribute remains or not) - iii. if a deletion flag exists on an entry, and an older rename operation occurs which causes the attribute to become non-distinguished, the flag will be used to determine whether the attribute is removed or stays (as in the current algorithm, but in more limited circumstances) Benefits : The RDN always reflects an administrator choice. The later remove will be overridden by the rename UNLESS another external operation occurs between these two which causes the remove to be ok. All DSAs will eventually have the same consistent state. Risks : Same risk of complexity in implementation as in option 2. Maybe a little reduced since the flag can now be discarded. The new risk below doesn't exist for this option. Steven Legg on 18.08.99 02:05:30 To: merrells@netscape.com, ietf-ldup@imc.org cc: Subject: Re: URP - Distinguished Not Present John, >From: merrells@netscape.com (John Merrells) >To: LDUP >Subject: URP - Distinguished Not Present >Date: Tue, 17 Aug 1999 14:11:37 -0700 >b) The DNP flag should have it's own CSN, and be purged independently > of the value with which it is associated. If the DNP CSN drops below > the Purge Vector, then we promote the value to be Present. In this > way we've undone the Modify-Delete, which would have been rejected, > had the operations been seen in order. I've looked at ways of purging the DNP flag but haven't found anything that works. Suppose we have some value V, which is made distinguished at one DSA at time t1, and deleted at time t2 at some other DSA. In due course both DSAs will see both updates and make V distinguished-not-present. Now suppose there is some operation at time t3 that makes V non-distinguished. What we do with V depends on whether we have purged the DNP flag (with CSN t2). Because the information to construct the Purge Vector takes time to propagate around, different DSAs will purge the DNP flag at different times. Some will have purged the flag before they see the update at time t3 and some will still have it. Therefore some DSAs will keep V and some will remove it. Not good! Having the DNP flag persist indefinitely avoids this problem. Regards, Steven ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ietf-ldup@imc.org Tue Aug 31 12:24:34 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23345 for ; Tue, 31 Aug 1999 12:24:30 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id IAA26326 for ietf-ldup-bks; Tue, 31 Aug 1999 08:31:07 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA26321 for ; Tue, 31 Aug 1999 08:31:06 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 31 Aug 1999 09:32:43 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 31 Aug 1999 09:31:51 -0600 From: "Ed Reed" To: , , "'Ed Reed'" , Subject: RE: Info model revs... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_EABC1B8B.A7C6A4E6" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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. --=_EABC1B8B.A7C6A4E6 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alan - Yes, there are companies claiming to support "billions and billions" of=20 entries in their directories (I can think of one, where I work!). Know, = clearly, that the purpose of that was to change market perceptions about a product which up to that time had been largely relegated to distributed nameservice= operations, which was its original design point, and not to the kind of=20 general purpose database that others in the market place were creating. =20 The interesting thing about the "billion user tree" which we demonstrated was that large, flat, bushy trees could now be supported on our product. Creating a tree with 8 servers and 150 million entries per server (in = fact, per container) stretched a lot of things in our product during the final shakeout period of the NDS 8 beta tests...in replication, in background processing, in the Virtual-List-View and Server-Side-Sorting LDAP controls that we had to use to reasonably access it, etc. Even distributed searches across the tree were quite acceptible for the demos and press events for which it was intended. The memory model of the b-tree datastore demonstrated that it was not memory bound or limited in performance, giving consistent search response times against indexes (which can be added and deleted as needed by our support staff - administrator managed indexes will appear in the future when we clean up the user interface) for datasets well beyond the capacity of the server main memory. But most importantly, the robust, state-based, distributed multi-master (the LDAP term) replication protocol still works nicely, with some = tweaking, on such large servers. That's the same one running on more than a=20 million deployed DSAs around the world, today. And the same one that is the basis of the LDUP replication design. So, I guess I'd have to answer your question with "yes, Alan, it works". Cheers... Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed, Technologist Novell Product Management +1 801 222 3944 (new number!) >>> Alan Lloyd 08/31/1999 01:49:07 >>> Re this - Thanks Ed for inviting both peaseful and violent reactions. I cannot offer either. Just my own humble personal opinions. Actually I am personally waiting to see if anyone can get this LDUP stuff to work without blowing their R&D budget...=20 Directory companies are now saying they can support billions of entries - But why would you do that in a replicated single server system? We in fact we theoretically can do 10s of billions etc..across many, many DSAs - distributed and we can store theoretically 10s of gigabytes per attribute and thousands of attributes per entry as well .. Enough of this wonderful theory stuff. The point - is that on large scale (big entry) distributed directory service where multiple updates occur and this CSN stuff has to stay in check, etc - is there any guarantee that this LDUP protocol actually works, scales, provides integrity and commercial robustness to the directory information. - will there be a global GUID administration scheme for replica entries? Not in God's lifetime I think. Given that this CSN stuff requires look up tables or some more attributes stuck somewhere and that where a system carries millions of entries, what load factors are placed on it during replica updates and operational incident recovery.. We have come to like our Multi Master mode of working .. It was less "complex" and avoided many "overheads" :-) regards alan PS - Can those on the list who have models and prototypes on this stuff publish them. I think trying to imagine large scale distributed and replicated information systems, performing thousands of transactions a second with concurrent update collision mechanisms, - that is applied by just "a protocol" and "CSN management" is somewhat daunting. > -----Original Message----- > From: Ed Reed=20 > Sent: Tuesday, August 31, 1999 3:38 AM > To: ldup-repl@external.cisco.com; ietf-ldup@imc.org=20 > Subject: Info model revs... >=20 > Okay, I'm getting down to brass tacks, on this...here are some of the > realizations I've had trying to nail it down. >=20 > 1) DSAs for LDAP aren't defined. (see previous note to Mark and the > list). I'll probably have to create one. > 2) I've defined the lookup table for replica IDs here, anticipating > that this definition will be used in the replication protocol doc. > Needed to define it here so the description of CSNs would make sense, > because > 3) the only way to rationally describe the CSNs is to either > a) refer to the look up table, defined above, or > b) allow the RDN of the replica to be used when the lookup table > doesn't define any numeric mappings >=20 > All this is necessary because I've got to define the CSN as being a > fixed length string that will be able to use CaseIgnoreString > comparison rules for equality and ordering, so we don't have to create > a new syntax for CSNs (an action item from the Oslo meeting). =20 >=20 > But, even with fixed length S1 and S2 values (S and s in other > descriptions - which are we using?) in the CSN, the representation of > the replica via the lookup table (I call that a replicaNumber) must > also be fixed length, base 10 encoding, zero padded to the left. > Note, however, that if the RDN name of the replia, what I'm calling > the replicaID, won't pass a CaseIgnoreString match, even if it's fixed > length space padded to the right, because CIS matching rules suppress > duplicate white space in the match...so unless the RDN is EXACTLY the > same length of non-white-space characters for ALL replicas referenced > in the CSNs, the CIS match won't work. Yes, a server can parse the > string, compare each field of the string appropriately, but that's > what is called a new syntx, which servers MAY implement, but which > we'd like not to require. >=20 > Bottom line, the only reliable syntax uses the lookup table, with > numeric representations for each replica referenced in the CSNs being > transferred/compared. The lookup table is provided by the supplier of > CSN information. >=20 > My notion of allowing the CSN to include the RDN of the entry is to > deal with LDAP Search operations (like READ) which are getting the > information about an entry, including it's CSNs, for administrative > purposes, for instance. In that use, it seems silly to require the > definition of a lookup table, so I provide the RDN values, instead. >=20 > Does anyone care what is required when the RDN of a replica is > changed? MAY I say that reuse of RDNs is disallowed, or is that as > unworkable as I think it is? Maybe instead of RDN we should use the > GUID of the replica, instead...that would be fixed length, still long > enough to benefit from the lookup table, but easily comparible via > CaseIgnoreString. Should replicas be named by their GUID? (shudder - > maybe that goes too far). >=20 > Reactions, both peacable and violent, are invited. >=20 > Ed >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Ed Reed, Technologist > Novell Product Management > +1 801 222 3944 (new number!) > << File: Ed Reed.vcf >>=20 --=_EABC1B8B.A7C6A4E6 Content-Type: text/x-vcard Content-Disposition: attachment; filename="Ed Reed.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Ed Reed TEL;WORK:801-222-3944 ORG:;Product Management TEL;PREF;FAX:TBD EMAIL;WORK;PREF;NGW:ED REED@novell.com N:Reed;Ed TITLE:Technologist ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Ed Reed=3D0A=3D ORM-A-211 X-GWUSERID:ED REED END:VCARD --=_EABC1B8B.A7C6A4E6-- From owner-ietf-ldup@imc.org Tue Aug 31 20:16:04 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04334 for ; Tue, 31 Aug 1999 20:16:03 -0400 (EDT) Received: by mail.proper.com (8.9.3/8.9.3) id QAA10969 for ietf-ldup-bks; Tue, 31 Aug 1999 16:45:51 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA10965 for ; Tue, 31 Aug 1999 16:45:50 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 31 Aug 1999 17:47:25 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 31 Aug 1999 17:47:17 -0600 From: "Ed Reed" To: , , Subject: Matching rules for UTF-8 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_6731919D.1F7E1C16" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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. --=_6731919D.1F7E1C16 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Funny what you run accross while you're writing... RFC2252 describes may matching rules, including caseIgnoreMatch and = caseExactIA5Match, but nothing that persuades me that it applies to case = exact matching for UTF-8 strings, like directoryString. The question comes up because I'm trying to use RFC2079 URI definitions, = which calls out the syntax caseExactString, which isn't defined in = RFC2252, as far as I can find. I've found myself muttering that someone = should create a registry of all these things, but have firmly bit my = tongue, lest someone think I'm in favor or resurrecting the schema = registry wg... So - is everyone happy with my using URIs, as defined in 2079, as an LDAP = alternative to presentationAddress (RFC1278 - you remember "TELEX+00728722+= RFC-1006+03+10.0.0.6", don't you?) which is what 2252 fails to define, but = uses the same name as... Mark, is caseExact what you think is needed for the URI syntax, or = caseIgnore? Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed, Technologist Novell Product Management +1 801 222 3944 (new number!) --=_6731919D.1F7E1C16 Content-Type: text/x-vcard Content-Disposition: attachment; filename="Ed Reed.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Ed Reed TEL;WORK:801-222-3944 ORG:;Product Management TEL;PREF;FAX:TBD EMAIL;WORK;PREF;NGW:ED REED@novell.com N:Reed;Ed TITLE:Technologist ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Ed Reed=3D0A=3D ORM-A-211 X-GWUSERID:ED REED END:VCARD --=_6731919D.1F7E1C16-- From owner-ietf-ldup@imc.org Tue Aug 31 20:37:19 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04542 for ; Tue, 31 Aug 1999 20:37:18 -0400 (EDT) Received: by mail.proper.com (8.9.3/8.9.3) id RAA11114 for ietf-ldup-bks; Tue, 31 Aug 1999 17:01:32 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA11110 for ; Tue, 31 Aug 1999 17:01:31 -0700 (PDT) Received: from threadgill.austin.innosoft.com ([207.8.108.5]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTP id <01JFFARHXHUU8Y5G5N@INNOSOFT.COM> for ietf-ldup@imc.org; Tue, 31 Aug 1999 17:02:40 PDT Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by austin.innosoft.com (PMDF V5.2-31 #13579) with SMTP id <0FHC006OETGF0G@austin.innosoft.com>; Tue, 31 Aug 1999 19:02:39 -0500 (CDT) Date: Tue, 31 Aug 1999 19:02:39 -0500 From: Mark Wahl Subject: Re: Matching rules for UTF-8 In-reply-to: "Your message of Tue, 31 Aug 1999 17:47:17 MDT." To: Ed Reed Cc: ietf-ldup@imc.org, ietf-ldapext@netscape.com, mcs@netscape.com Message-id: <21102.936144159@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 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The RHS of HTTP URLs are case sensitive, so a case exact match should be used. However, should it not be a caseExactIA5Match? Mark Wahl, Directory Product Architect Innosoft International, Inc. From owner-ietf-ldup@imc.org Tue Aug 31 22:29:49 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06414 for ; Tue, 31 Aug 1999 22:29:48 -0400 (EDT) Received: by mail.proper.com (8.9.3/8.9.3) id SAA17033 for ietf-ldup-bks; Tue, 31 Aug 1999 18:48:35 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id SAA17027 for ; Tue, 31 Aug 1999 18:48:34 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 31 Aug 1999 19:50:14 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 31 Aug 1999 19:49:42 -0600 From: "Ed Reed" To: , "Ed Reed" Cc: , , Subject: Re: Matching rules for UTF-8 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5305A546.1D7C1E02" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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. --=_5305A546.1D7C1E02 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable That's my conclusion, too. Shame, since the LHS is not case sensitive, = and that will probably be commonly used for presentation addresses... ldap://ldap.whatever.com:389 for instance, instead of ldap://ldap.whatever.com:389/some-ldap-search-criteria right now, I've left it caseExactIA5Match, as done in NAMEDREF, RFC2079, = and RFC2255. Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed, Technologist Novell Product Management +1 801 222 3944 (new number!) >>> Mark Wahl 08/31/1999 18:02:39 >>> The RHS of HTTP URLs are case sensitive, so a case exact match should be = used. However, should it not be a caseExactIA5Match? Mark Wahl, Directory Product Architect Innosoft International, Inc. --=_5305A546.1D7C1E02 Content-Type: text/x-vcard Content-Disposition: attachment; filename="Ed Reed.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Ed Reed TEL;WORK:801-222-3944 ORG:;Product Management TEL;PREF;FAX:TBD EMAIL;WORK;PREF;NGW:ED REED@novell.com N:Reed;Ed TITLE:Technologist ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Ed Reed=3D0A=3D ORM-A-211 X-GWUSERID:ED REED END:VCARD --=_5305A546.1D7C1E02-- From owner-ietf-ldup@imc.org Tue Aug 31 22:52:39 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07484 for ; Tue, 31 Aug 1999 22:52:38 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id SAA17791 for ietf-ldup-bks; Tue, 31 Aug 1999 18:56:58 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id SAA17785 for ; Tue, 31 Aug 1999 18:56:57 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 31 Aug 1999 19:58:37 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 31 Aug 1999 19:58:29 -0600 From: "Ed Reed" To: , Subject: Sanity check - LDAP DSA Schema Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4610B05D.B4D5B7AB" Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 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. --=_4610B05D.B4D5B7AB Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Attached is a short schema description of an LDAP directory service agent = object class (ldapDSA), that makes use of labeledURI presentation = addresses instead of OSI ones. If there's no violent opposition, I expect = to make the LDUP information model refer to these definitions (they're = broken out here from the LDUP schema for the same reason we broke out the = ldapSubEntry definition - 'cause they seem more generally useful than for = just LDUP). Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed, Technologist Novell Product Management +1 801 222 3944 (new number!) --=_4610B05D.B4D5B7AB Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-dsa-schema-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT draft-ietf-ldup-dsa-schema-00.txt Ed Reed Novell, Inc. August 29, 1999 LDAP DSA Schema 1. 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. This Internet-Draft expires on February 29, 1999. 2. Abstract This document defines an object class called ldapDSA and associated classes and attributes which MAY be used in lieu of their X.520 and X.521 definitions to describe LDAP servers (ldapDSAs). 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]. The sections below reiterate these definitions and include some additional ones. Reed [Page 1] Expires February 29, 2000=0D=0C INTERNET-DRAFT 29 August 1999 LDAP DSA Schema 3. Attribute Definitions 3.1 ldapPresentationAddress Attribute ( l.fred.l NAME 'ldapPresentationAddress' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) This attribute is used to indicate how to access a network service, application entity, etc. The ldapPresentationAddress attribute is nearly identical to that of the 'ref' attribute (2.16.840.1.113730.3.1.34) defined in [NAMEDREF], except that it is not an operational attribute. (copied from [NAMEDREF]) The ldapPresentationAddress attribute type has IA5 syntax and is case sensitive. The ref attribute is multi- valued. Values placed in the attribute MUST conform to the specification given for the labeledURI attribute defined in [RFC2079]. The labeledURI specification defines a format that is a URI, optionally followed by whitespace and a label. This document does not make use of the label portion of the syntax. Future documents MAY enable new functionality by imposing additional structure on the label portion of the syntax as it appears in the ref attribute. If the URI contained in the ref attribute refers to an LDAPv3 server, it must be in the LDAP URI format described in [RFC2255]. 4. Class Definitions 4.1 ldapApplicationEntity Class ( 1.fred.1 NAME 'ldapApplicationEntity' DESC 'LDAP Application Entity class' SUP top STRUCTURAL MUST ( ldapPresentationAddress $ cn ) MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) ) The ldapApplicationEntity class is used to identify software services and their addresses on the internet. It differs from its X.500 and [RFC2252] parallel (applicationEntity) in that the presentationAddress is replaced with the ldapPresentationAddress (defined above). Reed [Page 2] Expires February 29, 2000=0D=0C INTERNET-DRAFT 29 August 1999 LDAP DSA Schema The attribute supportedApplicationContext may have no meaning for LDAP usage, but is retained for backward compatibility with parallel definitions of this class. 4.2 ldapDSA Class ( 1.3.6.1.4.1.1466.115.121.1.?? NAME 'ldapDSA' DESC 'LDAP DSA class' SUP ldapApplicationEntity STRUCTURAL MAY ( knowledgeInformation ) ) The ldapDSA class is used to represent an LDAP directory service agent, and to provide network address information as to how to talk to it. It is derived from the LDAP version of the X.500 and [RFC2256] defined applicationEntity. The attribute knowledgeInformation may have no meaning for LDAP usage (yet), but is retained for backward compatibility with parallel definitions of this class. 5. Security Considerations The ldapDSA class will be used to represent directory service agents in LDAP, and as such, its attributes, particularly the ldapPresentationAddress of the ldapDSA, will be relied upon by client applications and other directories as contact information for the ldapDSA. Access controls to prevent unauthorized modification of ldapDSA attributes, in particular the ldapPresentationAddress, are strongly recommended. 6. References [RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC2079, January 1997 [RFC2251] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997 Reed [Page 3] Expires February 29, 2000=0D=0C INTERNET-DRAFT 29 August 1999 LDAP DSA Schema [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255, December 1997 [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997 [NAMEDREF] C. Lukas, T. Howes, M. Roszkowski, M. Smith, and M. Wahl, "Named Referrals in LDAP Directories", draft-ietf-ldapext-namedref- 00.txt, June 1999 [X.500] ITU-T Rec. X.501, "The Directory: Models", 1993 7. Copyright Notice 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 8. Acknowledgements The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this Reed [Page 4] Expires February 29, 2000=0D=0C INTERNET-DRAFT 29 August 1999 LDAP DSA Schema 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 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 standard. Please address the information to the IETF Executive Director. 9. Author's Address Edwards E. Reed Novell, Inc. 122 E 1700 S Provo, UT 84606 USA E-mail: Ed_Reed@Novell.com LDUP Mailing List: ietf-ldup@imc.org Reed [Page 5] Expires February 29, 2000=0D=0C --=_4610B05D.B4D5B7AB Content-Type: text/x-vcard Content-Disposition: attachment; filename="Ed Reed.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Ed Reed TEL;WORK:801-222-3944 ORG:;Product Management TEL;PREF;FAX:TBD EMAIL;WORK;PREF;NGW:ED REED@novell.com N:Reed;Ed TITLE:Technologist ADR;DOM;WORK;PARCEL;POSTAL:;ORM-A-211 LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Ed Reed=3D0A=3D ORM-A-211 X-GWUSERID:ED REED END:VCARD --=_4610B05D.B4D5B7AB-- From owner-ietf-ldup@imc.org Tue Aug 31 23:40:56 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08195 for ; Tue, 31 Aug 1999 23:40:56 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id UAA23446 for ietf-ldup-bks; Tue, 31 Aug 1999 20:06:13 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA23440 for ; Tue, 31 Aug 1999 20:06:12 -0700 (PDT) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA20746 for ; Tue, 31 Aug 1999 20:07:52 -0700 (PDT) Received: from netscape.com ([208.12.63.197]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FHD21400.0C5; Tue, 31 Aug 1999 20:07:52 -0700 Message-ID: <37CC985A.15CF3F61@netscape.com> Date: Tue, 31 Aug 1999 20:07:06 -0700 From: merrells@netscape.com (John Merrells) Organization: Netscape Communications X-Mailer: Mozilla 4.6 [en]C-NSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: alison.b.payne@ch.pwcglobal.com CC: stevenlegg@hotmail.com, s.legg@trl.telstra.com.au, ietf-ldup@imc.org Subject: Re: URP - Distinguished Not Present - New Option? References: <802567DE.003FB715.00@intleursmtp10.uk.pw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit alison.b.payne@ch.pwcglobal.com wrote: > > Oops. The option as described below is similar if not the same in > approach as Option 4 from the original list (thanks, Steve). The timestamp > on the deletion flag is equivalent to keeping a deletion record for the > remove, but overriding it with the earlier rename operation. This > introduces the same history issue as with option 4, and which has been > discussed at reasonable length. Steve's mail from 09 August 99, "Re: > Delete Not Present - Options and Recommendation" describes the reasons > behind the need for history through a number of examples. I think that our suggestion is slightly different from Option 4, in that between the purge point and the present time we allow the delete to go ahead if a rename (before or after) would permit it to do so, after the purge point we behave as if we ignored the delete. Going back to the example... where t# is time, u# is update, and the replicas are {A,B,C}, and the entry E has DN=u and values {u,v,w} t1, u1, A, rename entry to v t2, u2, B, delete v t3, u3, C, rename entry to w These updates can be seen in six orders... u1, u2, u3 u1, u3, u2 u2, u1, u3 u2, u3, u1 u3, u1, u2 u3, u2, u1 The behaviour of the updates on the state information stored on the values is described in pseudo code below. The updates are 'delete a value', 'make a value distinguished', and 'make a value not distinguished'. A rename operation usually makes some values distinguished and others not. Some Definitions. operation_csn: the csn of the update present_csn: the csn of a present value deleted_csn: the csn of a deleted value dnp_csn: the csn of a distinguished not present value. Note that a value will may have both a present_csn and a dnp_csn at the same time. ~~~~ rename operation ~~~~ if entry dn csn is_before operation_csn then foreach component of the old rdn call rename-make-value-not-distinguished oldrdn_component foreach component of the new rdn call rename-make-value-distinguished newrdn_component entry rdn= new rdn else // The DN doesn't change, but we reassert the existence // of the values in the new RDN. foreach component of the new rdn call rename-make-value-distinguished newrdn_component end if ~~~~ rename-make-value-distinguished ~~~~ if value deleted then if value deleted_csn is_before operation_csn then add present_csn= operation_csn add dnp_csn= deleted_csn remove deleted_csn end if else if value present then if value distinguished not present then change present_csn= operation_csn else if value present_csn is_before operation_csn then change present_csn= operation_csn end end end ~~~~ rename-make-value-non-distinguished ~~~~ if value present then if value distinguished not present then if value dnp_csn is_before operation_csn then add deleted_cn= dnp_csn remove present_csn remove dnp_csn end if end end ~~~~ delete-value ~~~~ if value deleted then if value deleted_csn is_before operation_csn then change deleted_csn= operation_csn end if else if value present then if value distinguished not present then if value dnp_csn is_before operation_csn then change dnp_csn= operation_csn end if else if value is_distinguished then add dnp_csn= operation_csn else if value present_csn is_before operation_csn then add deleted_csn= operation_csn remove present_csn end end end end ~~~~ purge ~~~~ Assume that we purge all csns stored on the value immediatly. The purge csn is the smallest csn in the update vector. When a dnp_csn is purged the value stays present. I'll now apply these rules to our sample entry, which at time zero is identical at each replica, and is composed of a dn and some values. E= {dn=u, vals=[u,v,w] } The csns on the value are of the form "value[;csn]*" where the csn can be d# for deleted, p# for present, and dnp# for distinguished not present. There's also a csn on the DN, which I'll denote with dn# The update vector is a a sequence of csn numbers, uv = [1,2,3], and the purge point (pp) is the smallest csn of the update vector. Order 1: u1, u2, u3 u1: dn=v;dn1 vals=[u,v;p1,w] uv=[1,0,0] pp=0 u2: dn=v;dn1 vals=[u,v;p1;dnp2,w] uv=[1,2,0] pp=0 u3: dn=w;dn3 vals=[u,v;d2,w;p3] uv=[1,2,3] pp=1 purge: no change Order 2: u1, u3, u2 u1: dn=v;dn1 vals=[u,v;p1,w] uv= [1,0,0] pp= 0 u3: dn=w;dn3 vals=[u,v;p1,w;p3] uv= [1,0,3] pp= 0 u2: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [1,2,3] pp= 1 purge: no change Order 3: u2, u1, u3 u2: dn=u vals=[u,v;d2,w] uv= [0,2,0] pp=0 u1: dn=v;dn1 vals=[u,v;p1;dnp2,w] uv= [1,2,0] pp=0 u3: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [1,2,3] pp=1 purge: no change Order 4: u2, u3, u1 u2: dn=u vals=[u,v;d2,w] uv= [0,2,0] pp=0 u3: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [0,2,3] pp=0 u1: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [1,2,3] pp=1 purge: no change Order 5: u3, u1, u2 u3: dn=w;dn3 vals=[u,v,w;p3] uv= [0,0,3] pp= 0 u1: dn=w;dn3 vals=[u,v;p1,w;p3] uv= [1,0,3] pp= 0 u2: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [1,2,3] pp= 1 purge: no change Order 6: u3, u2, u1 u3: dn=w;dn3 vals=[u,v,w;p3] uv= [0,0,3] pp= 0 u2: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [0,2,3] pp= 0 u1: dn=w;dn3 vals=[u,v;d2,w;p3] uv= [1,2,3] pp= 1 purge: no change So, that seems to have come out OK. All orderings resulted in the same final state for the entry. I may have made a mistake applying the rules, but hopefully someone will work through the example from first principles and get the same results. This message is now over long, but I suppose I should really consider the other time orderings of the operations... to see how purgin would affect the results. John