From owner-ietf-ldup Thu Dec 4 14:38:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA00754 for ietf-ldup-bks; Thu, 4 Dec 1997 14:38:16 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA00748 for ; Thu, 4 Dec 1997 14:38:12 -0800 (PST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Thu, 4 Dec 1997 14:39:59 -0800 Message-ID: From: Chris Weider To: "'ietf-ldup@imc.org'" Cc: "'agenda@ietf.org'" Subject: LDUP BOF Date: Thu, 4 Dec 1997 14:39:53 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi gang: The LDUP BOF (LDAP Replication) will be held on Tuesday, 12/9, from 15:45 - 16:45. We will be attempting to see if we can come up with a charter consensus for working on LDAP replication in the IETF. Please read the document draft-ietf-asid-replica-req-01.txt. Although the BOF list has just been set up, please feel free to use it for discussions. See you there! Chris From owner-ietf-ldup Mon Dec 8 09:19:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA18425 for ietf-ldup-bks; Mon, 8 Dec 1997 09:19:49 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA18419 for ; Mon, 8 Dec 1997 09:19:44 -0800 (PST) Received: (qmail 16061 invoked from network); 8 Dec 1997 17:17:10 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 8 Dec 1997 17:17:10 -0000 From: Mark Wahl To: ietf-ldup@imc.org cc: Mark Wahl Subject: concurrency requirements for LDAP-based replication Date: Mon, 08 Dec 1997 11:17:09 -0600 Message-ID: <16059.881601429@folder.critical-angle.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk There are several possible approaches which this BOF could propose for how to work on replication in LDAP directories. These could range in complexity from dumping a server's directory with search requests to a LDAP-based protocol for coordination amongst multiple masters with schema negotiation. Many of the technical issues, such as access control, would be most relevant to particular forms of replication. One aspect which I believe is common to all is the requirements on LDAP directories for concurrency. As a protocol which describes the interaction between a single client and server on one connection, LDAP does not currently define the server's behavior when there is more than one client actively modifying the directory or multiple master servers. Future extensions to LDAP for providing transaction support to clients will require a clear definition of the requirements on LDAP servers in this area in order to maintain the transaction properties. Replication conventions which are transparent to servers (such as replication by a simple search) need to ensure that changes by clients do not get lost. Replication protocols will have stricter requirements, especially in a multi-master environment. I would like to propose that determining concurrency requirements for LDAP servers is a topic which belongs in a WG resulting from the LDUP BOF. The goal of this work item would then be to document these requirements in standards-track RFC, developed in conjunction with a replication conventions or protocol document. While a replication protocol document would be based on the concurrency requirements document, as well as on the replication requirements and other drafts, I suggest that it would be best developed as a separate document so that this work would be useful to the designers of LDAP transaction specifications. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-ldup Tue Dec 9 03:07:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA07774 for ietf-ldup-bks; Tue, 9 Dec 1997 03:07:41 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA07769 for ; Tue, 9 Dec 1997 03:07:35 -0800 (PST) Received: by gw.fl.dk id <26902-3>; Tue, 9 Dec 1997 12:08:44 +0100 Message-Id: <97Dec9.120844gmt+0100.26902-3@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: Tom Skovgaard Subject: Interchange formats Date: Tue, 9 Dec 1997 11:53:45 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk In Denmark, we have a particular requirement for transfer of what could be considered directory information. The telephone operators in Denmark are required to exchange telephone number information to allow for a combined telephone numbering service. This requirement also includes transfer of information to third parties having a legitimate need for numbers, e.g. providing an online or a paper directory for particular purposes. The transfer will include postal addresses. It should also reflect some organisational structure, like the hierarchy within an organisation. The problems involved are very much related to directory replication/synchronisation. We have studied several different format, among those several Danish home grow formats, the X.500 shadowing protocol and the LDIF. Work on LDIF seems to be quite dormant for the time being. The current draft is actually expired. However, I assume that the new BOF will take that up. Transfer of telenumbers is a question about transfering large amount of information, i.e. possible several milion entries in a single batch transfer. Overhead should therefore be kept at a minimum. The format we will suggest should also cope with future requirements, such as inclusion of e-mail addresses, certificates, etc. Our current suggestion is to use an optimised LDIF format. We are working on such an optimised format. What is the current thinking of the BOF? Are you planning to work on these issues? We want a standarised solution to our problem. Hope this gets to you before Washington - have a good meeting. Kind regards, Erik Andersen, Fischer & Lorenz Denmark. From owner-ietf-ldup Tue Dec 9 10:46:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA13454 for ietf-ldup-bks; Tue, 9 Dec 1997 10:46:07 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA13450 for ; Tue, 9 Dec 1997 10:46:03 -0800 (PST) Received: from korova ("port 4223"@KOROVA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQYU3CZD5C9TCXR6@INNOSOFT.COM> for ietf-ldup@imc.org; Tue, 9 Dec 1997 10:47:59 PST Date: Tue, 09 Dec 1997 10:50:14 -0800 From: Peter Coates Subject: Re: Interchange formats X-Sender: pcoates@thor To: Erik Andersen Cc: "'LDUP'" , Tom Skovgaard Message-id: <3.0.32.19971209105014.00b55440@thor> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk At 11:53 1997/12/09 +0100, Erik Andersen wrote: <<>> >Our current suggestion is to use an optimised LDIF format. We are >working on such an optimised format. > >What is the current thinking of the BOF? Are you planning to work on >these issues? We want a standarised solution to our problem. > Erik, I am interested in what you mean by optimised LDIF. We are using LDIF as a format for directory synchronization, but the delta form of LDIF is awkward both to use and to generate. Instead, we are using a form as follows To add a record, present it just as an absolute LDIF record. This means that to populate an LDAP directory, you can just "add" a file containing absolute LDIF records. To delete a record, write !DN: xxx To modify a record, put a "+" in front of the DN, and then use the modifiers + and ! in front of each attribute to mean modify or delete. For instance +DN: cn=Peter Coates; o=Innosoft +email: peter.coates@innosoft.com !fax !telephone: 818 919 3600 telephone: 626 919 3600 means: modify cn=Peter Coates modify the email attribute to be peter.coates@innosoft.com delete all fax attributes delete the telephone attribute with the value 818 919 3600 add the telephone attribute 626 919 3600 If there is a move afoot to revisit LDIF, and make it easier to use for directory synchronization, I would be interested in what others are doing, and conform. Peter From owner-ietf-ldup Tue Dec 9 16:09:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA17133 for ietf-ldup-bks; Tue, 9 Dec 1997 16:09:05 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA17129 for ; Tue, 9 Dec 1997 16:09:00 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 10 DEC 97 02:09:37 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <3.0.32.19971209105014.00b55440@thor> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Dec 1997 01:10:43 +0100 To: LDUP List From: Paul Panotzki Subject: Re: Interchange formats Sender: owner-ietf-ldup@imc.org Precedence: bulk At 19.50 +0100 97-12-09, Peter Coates wrote: >I am interested in what you mean by optimised LDIF. We are using LDIF as a >format for directory synchronization, but the delta form of LDIF is awkward >both to use and to generate. Instead, we are using a form as follows We also use LDIF to synchronize. Not incrementally yet because we find it awkward, just like you say. >To add a record, present it just as an absolute LDIF record. This means >that to populate an LDAP directory, you can just "add" a file containing >absolute LDIF records. This sounds good. >To delete a record, write > >!DN: xxx Fine. >To modify a record, put a "+" in front of the DN, and then use the >modifiers + and ! in front of each attribute to mean modify or delete. For >instance > >+DN: cn=Peter Coates; o=Innosoft >+email: peter.coates@innosoft.com >!fax >!telephone: 818 919 3600 >telephone: 626 919 3600 > >means: modify cn=Peter Coates >modify the email attribute to be peter.coates@innosoft.com >delete all fax attributes >delete the telephone attribute with the value 818 919 3600 >add the telephone attribute 626 919 3600 Hmmm, there is a problem here with the way you modify an attribute. Since "mail" is multivalued, which of the values are you modifying? Or does this mean that you implicitly delete all values and replace them by the new one? Then how do you modify with several values? Same thing goes for other multivalued attributes. >If there is a move afoot to revisit LDIF, and make it easier to use for >directory synchronization, I would be interested in what others are doing, >and conform. I agree. Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Tue Dec 9 16:47:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA17616 for ietf-ldup-bks; Tue, 9 Dec 1997 16:47:29 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA17610 for ; Tue, 9 Dec 1997 16:47:25 -0800 (PST) Received: from korova ("port 4310"@KOROVA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IQZ6O8Y3C29TD171@INNOSOFT.COM> for ietf-ldup@imc.org; Tue, 9 Dec 1997 16:48:25 PST Date: Tue, 09 Dec 1997 16:50:40 -0800 From: Peter Coates Subject: Re: Interchange formats X-Sender: pcoates@thor To: Paul Panotzki Cc: LDUP List Message-id: <3.0.32.19971209165040.00b61ba0@thor> MIME-version: 1.0 X-Mailer: Windows Eudora Pro Version 3.0 (32) Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk At 01:10 1997/12/10 +0100, Paul Panotzki wrote: >At 19.50 +0100 97-12-09, Peter Coates wrote: >>I am interested in what you mean by optimised LDIF. We are using LDIF as a >>format for directory synchronization, but the delta form of LDIF is awkward >>both to use and to generate. Instead, we are using a form as follows > >We also use LDIF to synchronize. Not incrementally yet because we find it >awkward, just like you say. > >>To add a record, present it just as an absolute LDIF record. This means >>that to populate an LDAP directory, you can just "add" a file containing >>absolute LDIF records. > >This sounds good. > >>To delete a record, write >> >>!DN: xxx > >Fine. > >>To modify a record, put a "+" in front of the DN, and then use the >>modifiers + and ! in front of each attribute to mean modify or delete. For >>instance >> >>+DN: cn=Peter Coates; o=Innosoft >>+email: peter.coates@innosoft.com >>!fax >>!telephone: 818 919 3600 >>telephone: 626 919 3600 >> >>means: modify cn=Peter Coates >>modify the email attribute to be peter.coates@innosoft.com >>delete all fax attributes >>delete the telephone attribute with the value 818 919 3600 >>add the telephone attribute 626 919 3600 > >Hmmm, there is a problem here with the way you modify an attribute. Since >"mail" is multivalued, which of the values are you modifying? Or does this >mean that you implicitly delete all values and replace them by the new one? >Then how do you modify with several values? > >Same thing goes for other multivalued attributes. > Absolutely right: our synchronization tools do not generate these modify attributes. However they are there for completeness, and map onto the LDAP modify operation. *foo: bar is equivalent to !foo foo: bar >>If there is a move afoot to revisit LDIF, and make it easier to use for >>directory synchronization, I would be interested in what others are doing, >>and conform. > >I agree. > >Best regards, >Paul > > > >----------------------------------------------------------------------- >Paul Panotzki Phone: +46 8 730 30 98 >Object Zone AB Fax: +46 8 444 61 28 >----------------------------------------------------------------------- > > > > From owner-ietf-ldup Fri Dec 12 01:51:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA03920 for ietf-ldup-bks; Fri, 12 Dec 1997 01:51:53 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA03916 for ; Fri, 12 Dec 1997 01:51:47 -0800 (PST) Received: by gw.fl.dk id <26889-2>; Fri, 12 Dec 1997 10:53:18 +0100 Message-Id: <97Dec12.105318gmt+0100.26889-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: Tom Skovgaard Subject: More on interchange formats Date: Fri, 12 Dec 1997 10:54:27 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi Peter, Paul and Gordon (and others) Thanks for your responses to my note on interchange formats. First some thoughts about an optimised LDIF format and secondly some other limitations we need to get a solution to. The aim must be to make any changes backward compatible, i.e. an implementation supporting an extended format shall also be able to support the current LDIF. I know this is going to be a little difficult. The current LDIF format could be made more compact by: - When specifying the objectClass attribute, it should only be necessary to specify the object classes from which the entry is directly derived. Any superior object classes could be implied, as the object class inheritance hierarchy should be known by the receiver. As an example, for an organizationalPerson it should not be necessary to specify the person and top object classes as well. - A multi-valued attribute could be specified on a single, possibly wrapped line with some kind of separator between values. - All non-text information, like certificates, could be transferred as an octet string instead of the base-64 encoding. We do not see a need to use e-mail for transfer of synchronisation information (this might give backward compatibility problems). - It may not be necessary to transfer the complete distinguished name for entries if entry information is transferred in some particular sequence much as it is done in the X.500 shadowing format. (However, a text oriented format does not allow for a structured data types, such as it is possible in an ASN.1 encoded string. It is therefore not possible to make it as elegant as it is done for the X.500 shadowing format.) Now to the real hard problem by giving an example: Erik Andersen, as a residential person, has two telephone numbers. One fixed telephone number with Tele Denmark and a mobile telephone number with Sonofon. Now, if Sonofon transfer its telephone number information to Tele Denmark, how will Tele Denmark be able to merge the two pieces of information into a single entry? How do we allocate distinguished names to residential persons? The only viable idea is to use social security numbers or some other unique identifiers, which would just be an alias for a social security number. People are quite sensitive with respect to use of social security numbers - the Big Brother syndrome. The current solution today in a Danish e-mail directory is to have a complete flat name space below a postal district. When a service provider today stores information about a subscriber in a directory, it gives the qualifier '1' to the first Erik Andersen he comes upon, number '2' to the next one etc. (there are plenty of them). The same Erik Andersen will get different qualifiers by different service providers, so the distinguished name is service provider specific and cannot be used for merging of information. Merging will have to be based on comparison of some key attributes. What those key attributes are, will depend on the particular situation. If a secure comparison cannot be made, a new entry will be created. I believe that there could be similar problems in an intra-organisation synchronisation where different databases or directory systems may be masters for different pieces of information. I have some ideas about how the above can be reflected in an extended "LDIF format". As Gordon suggests, I will try to draft something and put it on the exploder. I will take a few days but it should be there for pleasant Christmas reading. Kind regards, Erik From owner-ietf-ldup Fri Dec 12 17:04:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA15844 for ietf-ldup-bks; Fri, 12 Dec 1997 17:04:52 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA15840 for ; Fri, 12 Dec 1997 17:04:48 -0800 (PST) Received: from korova ("port 4946"@KOROVA.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IR3E6CCYNQ9TD78D@INNOSOFT.COM> for ietf-ldup@imc.org; Fri, 12 Dec 1997 17:06:14 PST Date: Fri, 12 Dec 1997 17:09:20 -0800 From: Peter Coates Subject: Re: More on interchange formats In-reply-to: <97Dec12.105318gmt+0100.26889-2@gw.fl.dk> X-Sender: pcoates@limpet To: Erik Andersen Cc: "'LDUP'" , Tom Skovgaard Message-id: <01IR3E6CGZP49TD78D@INNOSOFT.COM> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk At 10:54 1997/12/12 +0100, Erik Andersen wrote: >Hi Peter, Paul and Gordon (and others) > >Thanks for your responses to my note on interchange formats. > >First some thoughts about an optimised LDIF format and secondly some >other limitations we need to get a solution to. > >The aim must be to make any changes backward compatible, i.e. an >implementation supporting an extended format shall also be able to >support the current LDIF. I know this is going to be a little difficult. Is the current delta form of LDIF actually being used? Obviously the absolute form is, but I'm less certain of the delta form. > >The current LDIF format could be made more compact by: > >- When specifying the objectClass attribute, it should only be necessary >to specify the object classes from which the entry is directly derived. >Any superior object classes could be implied, as the object class >inheritance hierarchy should be known by the receiver. As an example, >for an organizationalPerson it should not be necessary to specify the >person and top object classes as well. > >- A multi-valued attribute could be specified on a single, possibly >wrapped line with some kind of separator between values. > >- All non-text information, like certificates, could be transferred as >an octet string instead of the base-64 encoding. We do not see a need to >use e-mail for transfer of synchronisation information (this might give >backward compatibility problems). We *do* use email for directory synchronization. I would prefer to be able to transport ldif unencoded, but it's not that important. We also use the format for directory information from directories other than LDAP or X.500. This means that we have taken a fairly flexible view of what is allowed. >- It may not be necessary to transfer the complete distinguished name >for entries if entry information is transferred in some particular >sequence much as it is done in the X.500 shadowing format. (However, a >text oriented format does not allow for a structured data types, such as >it is possible in an ASN.1 encoded string. It is therefore not possible >to make it as elegant as it is done for the X.500 shadowing format.) >Kind regards, Erik > From owner-ietf-ldup Sat Dec 13 04:11:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA25635 for ietf-ldup-bks; Sat, 13 Dec 1997 04:11:26 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA25624 for ; Sat, 13 Dec 1997 04:11:18 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 13 DEC 97 14:12:09 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <97Dec12.105318gmt+0100.26889-2@gw.fl.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Dec 1997 13:13:16 +0100 To: Erik Andersen From: Paul Panotzki Subject: Re: More on interchange formats Cc: "'LDUP'" , Tom Skovgaard Sender: owner-ietf-ldup@imc.org Precedence: bulk At 10.54 +0100 97-12-12, Erik Andersen wrote: >The current LDIF format could be made more compact by: > >- When specifying the objectClass attribute, it should only be necessary >to specify the object classes from which the entry is directly derived. >Any superior object classes could be implied, as the object class >inheritance hierarchy should be known by the receiver. As an example, >for an organizationalPerson it should not be necessary to specify the >person and top object classes as well. This could be OK. Although, if you're using custom object classes (like say myOrgPerson SUP person SUP top) other directories will not be able to import your LDIF file. So you should at least include an object class that is "well known". I.e "person" would be required in the my example, but top wouldn't. In your example, using organizationalPerson would be enough, as it is "well known". >- A multi-valued attribute could be specified on a single, possibly >wrapped line with some kind of separator between values. Could work. >- All non-text information, like certificates, could be transferred as >an octet string instead of the base-64 encoding. We do not see a need to >use e-mail for transfer of synchronisation information (this might give >backward compatibility problems). We're using email for transfer of LDIF files. The Common Indexing Protocol(CIPv3) can be used to transfer replication info. CIPv3 can use SMTP as transport. So this type of transport is actually quite useful, simple and fast to implement. Why not develop a binary LDIF format as well? Define an ASN.1 syntax for LDIF encoded in BER. (Could be very much like the LDAP syntax.) No-brainer to parse, and relatively compact. If someone wants to send it over SMTP, it could be encoded further to base64, uuencode, or whatever that someone preferrs. >- It may not be necessary to transfer the complete distinguished name >for entries if entry information is transferred in some particular >sequence much as it is done in the X.500 shadowing format. (However, a >text oriented format does not allow for a structured data types, such as >it is possible in an ASN.1 encoded string. It is therefore not possible >to make it as elegant as it is done for the X.500 shadowing format.) > >Now to the real hard problem by giving an example: > >Erik Andersen, as a residential person, has two telephone numbers. One >fixed telephone number with Tele Denmark and a mobile telephone number >with Sonofon. Now, if Sonofon transfer its telephone number information >to Tele Denmark, how will Tele Denmark be able to merge the two pieces >of information into a single entry? How do we allocate distinguished >names to residential persons? The only viable idea is to use social >security numbers or some other unique identifiers, which would just be >an alias for a social security number. People are quite sensitive with >respect to use of social security numbers - the Big Brother syndrome. >The current solution today in a Danish e-mail directory is to have a >complete flat name space below a postal district. When a service >provider today stores information about a subscriber in a directory, it >gives the qualifier '1' to the first Erik Andersen he comes upon, number >'2' to the next one etc. (there are plenty of them). The same Erik >Andersen will get different qualifiers by different service providers, >so the distinguished name is service provider specific and cannot be >used for merging of information. >Merging will have to be based on comparison of some key attributes. What >those key attributes are, will depend on the particular situation. If a >secure comparison cannot be made, a new entry will be created. This problem is due to the way you uniquely identify a record in LDAP/X.500. I have no idea how to solve this problem nicely (I've encountered it myself). Right now we're just using heuristics to guess which records should be merged, just like you described. Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Sat Dec 13 07:21:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA07290 for ietf-ldup-bks; Sat, 13 Dec 1997 07:21:44 -0800 (PST) Received: from folder.critical-angle.com (eden-gw.critical-angle.com [206.81.238.241]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA07283 for ; Sat, 13 Dec 1997 07:21:39 -0800 (PST) Received: (qmail 3146 invoked from network); 13 Dec 1997 15:19:11 -0000 Received: from folder.critical-angle.com (206.81.238.241) by folder.critical-angle.com with SMTP; 13 Dec 1997 15:19:11 -0000 From: Mark Wahl To: Peter Coates cc: ietf-ldup@imc.org Subject: Re: More on interchange formats In-reply-to: Your message of "Fri, 12 Dec 1997 17:09:20 PST." <01IR3E6CGZP49TD78D@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Dec 1997 09:19:10 -0600 Message-ID: <3144.882026350@folder.critical-angle.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk > Is the current delta form of LDIF actually being used? Obviously the > absolute form is, but I'm less certain of the delta form. Yes, it is used in the change log. The generation of changerecords by the LDAP server is straightforward. In draft-ietf-asid-ldif-02: There is a one-to-one correlation between LDAP operations which modify the directory (add, delete, modify, and modrdn), and the types of changerecords described below ("add", "delete", "modify", and "modrdn" or "moddn"). This correspondence is intentional, and permits a straightforward translation from LDIF changerecords to protocol operations. Mark Wahl, Enterprise Directory Integration Critical Angle Inc. From owner-ietf-ldup Mon Dec 15 05:29:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA06333 for ietf-ldup-bks; Mon, 15 Dec 1997 05:29:56 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA06327 for ; Mon, 15 Dec 1997 05:29:52 -0800 (PST) From: Bob_Huston@iris.com Received: by arista.iris.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 8525656E.004AA2B9 ; Mon, 15 Dec 1997 08:35:13 -0500 X-Lotus-FromDomain: IRIS To: ietf-ldup@imc.org Message-ID: <8525656E.004A4200.00@arista.iris.com> Date: Mon, 15 Dec 1997 08:32:16 -0500 Subject: Re: More on interchange formats Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@imc.org Precedence: bulk >>The current LDIF format could be made more compact by: >> >>- When specifying the objectClass attribute, it should only be necessary >>to specify the object classes from which the entry is directly derived. >>Any superior object classes could be implied, as the object class >>inheritance hierarchy should be known by the receiver. As an example, >>for an organizationalPerson it should not be necessary to specify the >>person and top object classes as well. >This could be OK. Although, if you're using custom object classes (like say >myOrgPerson SUP person SUP top) other directories will not be able to >import your LDIF file. So you should at least include an object class that >is "well known". I.e "person" would be required in the my example, but top >wouldn't. In your example, using organizationalPerson would be enough, as >it is "well known". This is not necessarily true. One of the main objectives to getting ldap dir synch to work will be to ensure that extended and customized schemas will be accounted for. At the recent BOF opinions were expressed along the lines of not including these non-standard schema objects severly restricts the usefullness of dir synch. If we work out a way to register your schema, then having a custom object class like myOrgPerson would be ok, all servers participating in the dir synch would have at least a base understanding of the extended object. Bob Huston Iris Associates. From owner-ietf-ldup Mon Dec 15 07:55:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA08465 for ietf-ldup-bks; Mon, 15 Dec 1997 07:55:59 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA08461 for ; Mon, 15 Dec 1997 07:55:51 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 15 DEC 97 17:56:51 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <8525656E.004A4200.00@arista.iris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Dec 1997 16:58:01 +0100 To: Bob_Huston@iris.com From: Paul Panotzki Subject: Re: More on interchange formats Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@imc.org Precedence: bulk At 14.32 +0100 97-12-15, Bob_Huston@iris.com wrote: >>>The current LDIF format could be made more compact by: >>> >>>- When specifying the objectClass attribute, it should only be necessary >>>to specify the object classes from which the entry is directly derived. >>>Any superior object classes could be implied, as the object class >>>inheritance hierarchy should be known by the receiver. As an example, >>>for an organizationalPerson it should not be necessary to specify the >>>person and top object classes as well. > >>[Paul said:] >>This could be OK. Although, if you're using custom object classes (like >say >>myOrgPerson SUP person SUP top) other directories will not be able to >>import your LDIF file. So you should at least include an object class that >>is "well known". I.e "person" would be required in the my example, but top >>wouldn't. In your example, using organizationalPerson would be enough, as >>it is "well known". > >This is not necessarily true. One of the main objectives to getting ldap >dir synch to work will be to ensure that extended and customized schemas >will be accounted for. At the recent BOF opinions were expressed along >the lines of not including these non-standard schema objects severly >restricts the usefullness of dir synch. If we work out a way to register >your schema, then having a custom object class like myOrgPerson would be >ok, >all servers participating in the dir synch would have at least a base >understanding of the extended object. I'm not sure what you mean about registration. Fine, as long as that information is available in the LDIF file itself. For instance, somewhere in the begining of the LDIF file you could have something specifying the inheritance: myOrgPerson -> organizationalPerson -> person -> top Then a directory service which doesn't know what a myOrgPerson is, could still use the data to create organizationalPerson objects, discarding/ignoring those attributes that are new in myOrgPerson Best regards, Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Mon Dec 15 07:27:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA08160 for ietf-ldup-bks; Mon, 15 Dec 1997 07:27:44 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA08155 for ; Mon, 15 Dec 1997 07:27:36 -0800 (PST) Received: by gw.fl.dk id <26886-2>; Mon, 15 Dec 1997 16:29:29 +0100 Message-Id: <97Dec15.162929gmt+0100.26886-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Cc: Tom Skovgaard Subject: Extended "LDIF" format Date: Mon, 15 Dec 1997 16:30:35 +0100 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 As promised, I have worked on a suggestion for an extension to LDIF that could fulfil our requirements. It is not complete. It needs at least some more work on uddate operations. For different notes, I have seen some concerns about the current format for updates. Updates is centainly very important to us. However, I am including the initial work for comments to get some feed back on whether I am on a completely wrong track. ------------------------------------------------------------------------ ----------------------------- This note suggests some changes to the current LDIF format to extend its usability to more areas. It should be read as a delta to the current Internet draft. The note is not in the form of an Internet draft. It is put up on the LDUP mailing list for comments. ------------------------------------------------------------------------ ----- Background and Intended Usage (addition) Different directory systems may hold different pieces of directory information about the same object. Such systems may have a requirement to update each other or to update a central directory system to merge all relevant information. In some cases it may be difficult to have a common scheme for allocating distinguished names. As an example, it may be possible to get some agreement on how a country should be structured into some hierarchy of localities. However, it is quite difficult to allocate RDNs for residential persons common for all directory system. Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file = ldif-content / ldif-changes ldif-content = ["total" 1*SEP] heading own-content [other-content] ldif-changes = ["incremental" 1*SEP] heading own-change [other-change] heading = 0,1*(["total" SPACE] version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] agreement-id = 1*safe-initval own-content = ["own" 1*SEP] ldif-attrval-record *(1*SEP ldif-attrval-record) other-content = "other" 1*SEP ldif-attrval-record *(1*SEP ldif-attrval-record) own-change = ["own" 1*SEP] ldif-change-record *(1*SEP ldif-change-record) other-change = "other" 1*SEP ldif-change-record *(1*SEP ldif-change-record) ldif-attrval-record = dn-spec SEP 1*(attrval-spec) ldif-change-record = dn-spec SEP 1*(changerecord SEP) version-spec = "version:" *SPACE version-number version-number = 1*DIGIT ; version-number MUST be "2" for the ; LDIF format described in this document. dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) / ("sup:" *SPACE dn) / "sup::" *SPACE base64-dn) dn = base64-dn = rdn = base64-rdn = attrval-spec = attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE value)) / ("::" *SPACE base64-value *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url = ; (See Note 6, below) attribute-description = charset-option = "charset=" ( "*" / charset-name ) charset-name = a character set name, as registered with IANA [10] value = 1*safe-initval *safe safe = safe-initval = base64-value = changerecord = change-add / change-delete / change-modify / change-moddn change-add = "changetype:" *SPACE "add" 1*(SEP attrval-spec) change-delete = "changetype:" *SPACE "delete" change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) mod-spec = mod-add-spec / mod-delete-spec / mod-replace-spec mod-add-spec = "add:" *SPACE attribute-description 1*(SEP attrval-spec) SEP "-" mod-delete-spec = "delete:" *SPACE attribute-description *(SEP attrval-spec) SEP "-" mod-replace-spec = "replace:" *SPACE attribute-description *(SEP attrval-spec) SEP "-" SPACE = SEP = (CR LF / LF) CR = LF = DIGIT = Agreements An agreement ID can optionally be in the first part of an LDIF file. This agreement specification can be used to give a unique identification of the scope of an information exchange. Such an agreement can be include such things as: 1) What information has to be transferred and possibly kept updated by the sender. 2) The attribute types and object classes that are part of the transport including what textual representations are going to use. In case of high-volume exchanges, the two parties can agree on an abbreviated form of textual representation. As an example "tel" could be an abbreviated form of TelephoneNumber. 3) An understanding of what information is necessary to transfer to aid in the correlation process. 4) How much of a distinguished name that needs to be transferred. As an example, the country name could have a default value. 5) How much information that is needed for the objectClass attribute. If the object class for the entry information is, say, residentialPerson, it may not be necessary also to specify the super-classes person and top. They could be implied. 6) Agreement on not to use spaces where they are optional. 6) Update frequency. Establishment of an agreement is a completely off-line activity not directly reflected in the protocol. If there is no agreement-id specified, an implied agreement is assumed. There can only be one implicit agreement between a particular sender and a particular recipient. Note on LDIF syntax and usage 1) The "total" specification indicates that all information related to the agreement should be purged and replaced by the information in the current transfer. This does not necessarily mean that current entries are deleted during the first part of this process as there may be local information or information from other agreements within those entries. 2) When doing incremental updates, a "delete" record MUST contain sufficient information to allow locating the entry in question. The delete operation only applies to the part of the entry holding information owned by the sender according to the agreement. 3) The optional "own" specification starts a block of information for which the sender is master, and which by the receiver can be added to its local database or update previously received information. As an example, a mobile telephone number allocated by a mobile telephone operator is owned by that operator and will be present in this block when this mobile operator is transmitting information to other parties. 4) The optional "other" specification starts a block of information assumed to be owed by other organisations or systems, which could include the receiver of the information. This information is primarily intended for identifying an already existing entry. As an example, a mobile operator may supply the fixed telephone number in a record, although the fixed telephone is subscribed from another operator. If there is information in this block that is currently not present at the recipient, it a local option for the receiver whether to store it or dispose of it in any other way. 5) Any attribute information placed before an "own" or an "other" specification is considered part of the "own" part. If none of the two specifications are present, all attribute information is considered "own" information. 6) The "dn" is the distinguished name of the entry. This is not a mandatory field. However, if this field is not present, the "sup" field MUST be explicitly or implicitly present. This filed MUST NOT be present if the "sup" field is present. This field shall only be used if the complete distinguished name is understood by both parties to denote the same object. As an example, the name of a reasonable seize company is assumed to be unique within a certain geographical area. This field MUST be used if the entry has subordinate entries. 7) The "sup" is the distinguished name of the superior entry. This field can only be used for leaf entries, e.g. residential persons, and it shall only be used if it not possible to establish a distinguished name that is globally recognised. When this field is present, it is assumed that the receiver of the information can from other included information, e.g. name, telephone number, postal address, etc. can determine whether the object is already present and should be updated 8) If both the "dn" and the "sup" specifications are absent, it is treated as an implicit "sup" specification being equal to the one in the previous record. Such an implicit "sup" specification is only allowed if the previous record did not have en "dn" specification. 9) For multi-valued attribute types, it is possible either to put all values on a single line or include a line for each attribute value. Differences from Version 1 of LDIF 1) It is possible in a header besides giving version information to indicate whether an LDIF file is a complete transfer of all information or whether is an updating file 2) It is possible in the header to optionally indicate an agreement ID in case two parties have several agreements on exchanging synchronization information. 3) It is possible for each record to indicate two different blocks of information. One block, where the transmitter is the master for the information and one block of information where other systems have the master role, but is information that can be used for correlation. 4) It is possible to only transfer the distinguished name of the superior of an entry in case the receiver is expected to generate the complete distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same, possibly folded line. The separator between values is a back-slash ("\") Examples of LDAP Interchange Format Example 1: A simple LDIF file with a few records sent from a mobile telephone operator to some central information service total version 2 agreement-id: op1-to-op2, ver.1 dn:dn:o=F&L,c=DK own mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 dn:cn=Tom Finkelstein,o=F&L,c=DK own mobile:+4512345678 other objcl:orgPers sn:Finkdelstein tel:+4539450999 822:tfs@fl.dk sup:loc=1815,sOpName=Copenhagen own mobile:+4520971490 other sn:Andersen gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv city:Frederiksberg tel:+4531230490 own mobile:+4587654321 other sn:Petersen gn:Peter street:Paludan Mullersvej num:5 floor:3 city:Frederiksberg tel:+4523456789 From owner-ietf-ldup Mon Dec 15 08:13:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08714 for ietf-ldup-bks; Mon, 15 Dec 1997 08:13:45 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA08710 for ; Mon, 15 Dec 1997 08:13:39 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 15 Dec 1997 09:10:57 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 15 Dec 1997 09:10:29 -0700 From: Ed Reed To: ietf-ldup@imc.org, Bob_Huston@iris.com Subject: Re: More on interchange formats Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk In the spirit of schema synchronization (;-) I'd really like to see an extended LDIF format that includes schema representation in an agreed-to meta-schema format that could be (should be/must be, whatever) prepended to any LDIF file that includes objects/attributes which are extensions beyond some agreed-to base schema. As an optimization, servers could simply reference the extensions, and provide the meta-schema representation if a response from the receiving server indicates they lack understanding of the noted extension and would like to receive the sending servers interpretation. This would kill two birds with one stone: 1) establish general use of the ldap meta-schema representation used by the listing service for real-time, interactive update operations between coooperating servers, 2) provide a means to propagate locally initiated extensions of schema among cooperating servers even in the absense of a listing in the listing server, or connectivity thereto. Not every system administrator using LDAP extended schema will know about or care about the listing service, and I'm not at all sure we want 152,328 different variations on the Employee user class registered, even if they know about the service. Extending the LDIF format to include the ability to provide the schema extension would be generally useful, no? Even as a way to dynamically extend the schema on servers which support such a thing? Ed ------------------- Ed Reed, Chief Architect Network Services Group Novell, Inc. +1 801 861 3320 >>> 12/15/1997 06:32:16 >>> >>The current LDIF format could be made more compact by: >> >>- When specifying the objectClass attribute, it should only be necessary >>to specify the object classes from which the entry is directly derived. >>Any superior object classes could be implied, as the object class >>inheritance hierarchy should be known by the receiver. As an example, >>for an organizationalPerson it should not be necessary to specify the >>person and top object classes as well. >This could be OK. Although, if you're using custom object classes (like say >myOrgPerson SUP person SUP top) other directories will not be able to >import your LDIF file. So you should at least include an object class that >is "well known". I.e "person" would be required in the my example, but top >wouldn't. In your example, using organizationalPerson would be enough, as >it is "well known". This is not necessarily true. One of the main objectives to getting ldap dir synch to work will be to ensure that extended and customized schemas will be accounted for. At the recent BOF opinions were expressed along the lines of not including these non-standard schema objects severly restricts the usefullness of dir synch. If we work out a way to register your schema, then having a custom object class like myOrgPerson would be ok, all servers participating in the dir synch would have at least a base understanding of the extended object. Bob Huston Iris Associates. From owner-ietf-ldup Mon Dec 15 08:45:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA09101 for ietf-ldup-bks; Mon, 15 Dec 1997 08:45:24 -0800 (PST) Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA09097 for ; Mon, 15 Dec 1997 08:45:18 -0800 (PST) Received: from trsvr.tr.unisys.com (trsvr.tr.unisys.com [192.63.216.7]) by bbmail1.unisys.com (8.8.5/8.8.5) with ESMTP id QAA02485 for ; Mon, 15 Dec 1997 16:47:30 GMT Received: from tr-exchange-2.tr.unisys.com by trsvr.tr.unisys.com (8.6.12/8.6.12) id QAA09008 ; Mon, 15 Dec 1997 16:47:25 GMT Received: by tr_exchange_2.tr.unisys.com with Internet Mail Service (5.0.1458.49) id ; Mon, 15 Dec 1997 11:48:22 -0500 Message-ID: <7B5973973C58D111BE4400600837760B3BCB31@tr-exchange-1.tr.unisys.com> From: "Salter, Thomas A" To: ietf-ldup@imc.org Subject: RE: More on interchange formats Date: Mon, 15 Dec 1997 11:46:28 -0500 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 Most of this definition is already done. Since Ldap V3 defines subschema objects, it falls out that there is an LDIF representation of schema information. What I think is missing is a consistent way of constraining the subschema information to pertain to a particular set of objects, as X.500 does through subtrees, or perhaps an operational attribute that links an entry to a particular subschema. > ---------- > From: Ed Reed[SMTP:ED_REED@novell.com] > Sent: Monday, December 15, 1997 11:10 AM > To: ietf-ldup@imc.org; Bob_Huston@iris.com > Subject: Re: More on interchange formats > > In the spirit of schema synchronization (;-) I'd really like to see an > extended LDIF format that includes schema representation in an > agreed-to meta-schema format that could be (should be/must be, > whatever) prepended to any LDIF file that includes objects/attributes > which are extensions beyond some agreed-to base schema. As > an optimization, servers could simply reference the extensions, and > provide the meta-schema representation if a response from the > receiving server indicates they lack understanding of the noted > extension and would like to receive the sending servers > interpretation. > > This would kill two birds with one stone: > > 1) establish general use of the ldap meta-schema representation used > by the listing service for real-time, interactive update operations > between > coooperating servers, > 2) provide a means to propagate locally initiated extensions of schema > among cooperating servers even in the absense of a listing in the > listing > server, or connectivity thereto. > > Not every system administrator using LDAP extended schema will know > about or care about the listing service, and I'm not at all sure we > want > 152,328 different variations on the Employee user class registered, > even > if they know about the service. Extending the LDIF format to include > the ability to provide the schema extension would be generally useful, > no? > Even as a way to dynamically extend the schema on servers which > support such a thing? > > Ed > > ------------------- > Ed Reed, Chief Architect > Network Services Group > Novell, Inc. > +1 801 861 3320 > > >>> 12/15/1997 06:32:16 >>> > > >>The current LDIF format could be made more compact by: > >> > >>- When specifying the objectClass attribute, it should only be > necessary > >>to specify the object classes from which the entry is directly > derived. > >>Any superior object classes could be implied, as the object class > >>inheritance hierarchy should be known by the receiver. As an > example, > >>for an organizationalPerson it should not be necessary to specify > the > >>person and top object classes as well. > > >This could be OK. Although, if you're using custom object classes > (like > say > >myOrgPerson SUP person SUP top) other directories will not be able to > >import your LDIF file. So you should at least include an object class > that > >is "well known". I.e "person" would be required in the my example, > but top > >wouldn't. In your example, using organizationalPerson would be > enough, as > >it is "well known". > > This is not necessarily true. One of the main objectives to getting > ldap > dir synch to work will be to ensure that extended and customized > schemas > will be accounted for. At the recent BOF opinions were expressed along > the lines of not including these non-standard schema objects severly > restricts the usefullness of dir synch. If we work out a way to > register > your schema, then having a custom object class like myOrgPerson would > be > ok, > all servers participating in the dir synch would have at least a base > understanding of the extended object. > > Bob Huston > Iris Associates. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-ldup Mon Dec 15 13:36:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA13175 for ietf-ldup-bks; Mon, 15 Dec 1997 13:36:16 -0800 (PST) Received: from insanus.matematik.su.se (root@insanus.matematik.su.se [130.237.198.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA13171 for ; Mon, 15 Dec 1997 13:36:11 -0800 (PST) Received: from localhost (leifj@uggla.matematik.su.se [130.237.198.17]) by insanus.matematik.su.se (8.8.8/8.6.9) with ESMTP id WAA23844; Mon, 15 Dec 1997 22:38:29 +0100 (MET) Message-Id: <199712152138.WAA23844@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+46 8 162000 X-Fax: int+46 8 6126717 X-Url: http://www.matematik.su.se To: Paul Panotzki cc: Bob_Huston@iris.com, ietf-ldup@imc.org Subject: Re: More on interchange formats In-reply-to: Your message of "Mon, 15 Dec 1997 16:58:01 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18717.882221907.1@matematik.su.se> Date: Mon, 15 Dec 1997 22:38:28 +0100 From: Leif Johansson Sender: owner-ietf-ldup@imc.org Precedence: bulk >I'm not sure what you mean about registration. Fine, as long as that >information is available in the LDIF file itself. For instance, somewhere >in the begining of the LDIF file you could have something specifying the >inheritance: I believe that registration should be taken to mean registration of the schema with the IANA schema registration service for which there is soon a wg in the ietf. Best Regards Leif Johansson Leif Johansson Phone: +46 8 164541 Department of Mathematics Fax : +46 8 6126717 Stockholm University email: leifj@matematik.su.se From owner-ietf-ldup Tue Dec 16 04:08:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA23644 for ietf-ldup-bks; Tue, 16 Dec 1997 04:08:38 -0800 (PST) Received: from ip78.129.isdn.hogia.net (ip78.129.isdn.hogia.net [195.78.129.78]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA23640 for ; Tue, 16 Dec 1997 04:08:33 -0800 (PST) Received: from [195.78.129.68] by ip78.129.isdn.hogia.net with SMTP (QuickMail Pro Server for MacOS 1.0.2a7); 16 DEC 97 14:09:33 UT X-Sender: paul@mail.objectzone.se Message-Id: In-Reply-To: <199712152138.WAA23844@insanus.matematik.su.se> References: Your message of "Mon, 15 Dec 1997 16:58:01 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Dec 1997 13:10:44 +0100 To: ietf-ldup@imc.org From: Paul Panotzki Subject: Re: More on interchange formats Sender: owner-ietf-ldup@imc.org Precedence: bulk At 22.38 +0100 97-12-15, Leif Johansson wrote: >>I'm not sure what you mean about registration. Fine, as long as that >>information is available in the LDIF file itself. For instance, somewhere >>in the begining of the LDIF file you could have something specifying the >>inheritance: > >I believe that registration should be taken to mean registration of the >schema with the IANA schema registration service for which there is soon >a wg in the ietf. That's what I'm afraid of. (The registration, that is. Not the wg.) -Paul ----------------------------------------------------------------------- Paul Panotzki Phone: +46 8 730 30 98 Object Zone AB Fax: +46 8 444 61 28 ----------------------------------------------------------------------- From owner-ietf-ldup Tue Jan 6 08:20:24 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA17201 for ietf-ldup-bks; Tue, 6 Jan 1998 08:20:24 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA17197 for ; Tue, 6 Jan 1998 08:20:18 -0800 (PST) Received: by gw.fl.dk id <26882-3>; Tue, 6 Jan 1998 17:25:04 +0100 Message-Id: <98Jan6.172504gmt+0100.26882-3@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: Extended LDIF Date: Tue, 6 Jan 1998 17:25:22 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Just before Christmas I put on the list an initial proposal for an extend the LDIF format to suit some elaborate needs. I have gotten no reactions so far. In the meantime, I have worked on the subject. I found several errors in the first proposal. The intention has been to maintain backward compatibility, i.e. a system supporting the extended format will also (if I got it right) support version 1. A system supporting the extended version could also be customized to transmit only a version 1 file. As mentioned earlier, we need a interchange format for exchanging telephone number information among telephone operators and for collection of all information in a central repository. The current LDIF does not cover our requirements and we have found no other standardised format that does. On the 15th this month we will have the first meeting on the subject. I have been charged with making a proposal for an interchange format. The action is initiated and funded by the Danish Ministry for Research and Information Technology. It is my intention, unless I am greatly discouraged by responses, to propose the included extended format possibly amended due to comments and found mistakes. As I believe that others may or will in the future experience the same requirement as we have, a standardised approached is much to desire. It will also allow vendors of LDIF products to expand into new areas. As you can gather, I do have a heavy desire for comments from experts in the field. Erik Andersen Fischer & Lorenz Telecommunications Consultency Denmark From owner-ietf-ldup Mon Jan 12 01:43:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA06002 for ietf-ldup-bks; Mon, 12 Jan 1998 01:43:39 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA05998 for ; Mon, 12 Jan 1998 01:43:28 -0800 (PST) Received: by gw.fl.dk id <26884-4>; Mon, 12 Jan 1998 10:48:58 +0100 Message-Id: <98Jan12.104858gmt+0100.26884-4@gw.fl.dk> From: Erik Andersen To: "'LDUP'" , "'Gordon Good'" Subject: FW: Extended LDIF Date: Mon, 12 Jan 1998 10:48:20 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD1F47.99D034A0" Sender: owner-ietf-ldup@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD1F47.99D034A0 Content-Type: text/plain Hi Folks, Apparently, I forgot to include the file. Sorry about that. Also, in a note Gordon has stated that records are separated by two new lines. I have not been able to gather that from the current LDIF specification, which may easily be a shortcoming of mine. This would require some small changes as indicated by temporary notes in the text. Kind regards, Erik > -----Original Message----- > From: Erik Andersen > Sent: 6. januar 1998 17:25 > To: 'LDUP' > Subject: Extended LDIF > > Just before Christmas I put on the list an initial proposal for an > extend the LDIF format to suit some elaborate needs. I have gotten no > reactions so far. In the meantime, I have worked on the subject. I > found several errors in the first proposal. > > The intention has been to maintain backward compatibility, i.e. a > system supporting the extended format will also (if I got it right) > support version 1. A system supporting the extended version could also > be customized to transmit only a version 1 file. > > As mentioned earlier, we need a interchange format for exchanging > telephone number information among telephone operators and for > collection of all information in a central repository. The current > LDIF does not cover our requirements and we have found no other > standardised format that does. > > On the 15th this month we will have the first meeting on the subject. > I have been charged with making a proposal for an interchange format. > The action is initiated and funded by the Danish Ministry for Research > and Information Technology. It is my intention, unless I am greatly > discouraged by responses, to propose the included extended format > possibly amended due to comments and found mistakes. > > As I believe that others may or will in the future experience the same > requirement as we have, a standardised approached is much to desire. > It will also allow vendors of LDIF products to expand into new areas. > > As you can gather, I do have a heavy desire for comments from experts > in the field. > > Erik Andersen > Fischer & Lorenz Telecommunications Consultency > Denmark ------ =_NextPart_000_01BD1F47.99D034A0 Content-Type: text/plain; name="LDIF_EXT.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LDIF_EXT.txt" This note suggests some changes to the current LDIF format to extend = its=20 usability to more areas. It should be read as a delta to the current = Internet=20 draft. The note is not in the form of an Internet draft. It is put up = on the=20 LDUB mailing list for comments. ------------------------------------------------------------------------= ----- Background and Intended Usage (addition) Different directory systems may hold different pieces of directory=20 information about the same object. Such systems may have a = requirement to=20 update each other or to update a central directory system to merge = all=20 relevant information. A record that is sent by one system to another may represent a = complete=20 entry by the transmitter. However, the recipient may already have=20 information about the object in question. Adding a new entry through = LDIF=20 may not actually cause creation of a new entry, but may add = information to=20 an already existing entry. In this case, the recipient will have to=20 perform correlation by different means to try to locate an existing = entry=20 corresponding to the received record. If a globally unique = distinguished=20 name is transferred, correlation is straightforward. However, if = such a=20 distinguished name is not available, additional information carried = in the=20 record may be used for this correlation. It is application dependent = what=20 information that is then necessary. A high level of correlation=20 accurateness is necessary not to corrupt the directory information. In some cases it may be difficult to have a common scheme for = allocating=20 distinguished names. As an example, it may be possible to get some=20 agreement on how a country should be structured into some hierarchy = of=20 localities. However, it is quite difficult to allocate RDNs for=20 residential persons common to all directory systems. Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file =3D ldif-content / ldif-changes ldif-content =3D ["total" 1*SEP] heading own-content [other-content] ldif-changes =3D ["incremental" 1*SEP] heading own-change [own-content] [other-content] heading =3D 0,1*(["total" SPACE] version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] agreement-id =3D 1*safe-initval own-content =3D ["own" 1*SEP]=20 ldif-attrval-record *(1*SEP = ldif-attrval-record) other-content =3D "other" 1*SEP=20 ldif-attrval-record *(1*SEP = ldif-attrval-record) own-change =3D ["own" 1*SEP]=20 ldif-change-record *(1*SEP = ldif-change-record) ldif-attrval-record =3D dn-spec SEP 1*(attrval-spec) ldif-change-record =3D dn-spec SEP 1*(changerecord SEP) version-spec =3D "version:" *SPACE version-number version-number =3D 1*DIGIT ; version-number MUST be "2" for = the ; LDIF format described in this = document. dn-spec =3D ("dn:" *SPACE dn) / ("dn::" *SPACE = base64-dn) / ("dn:" *SPACE 1*DIGIT rdn *(("," / ";") *SPACE rdn)) / ("dn::" *SPACE 1*DIGIT base64-rdn *(("," / ";") *SPACE base64-rdn )) / ("s:" *SPACE dn) / ("s::" *SPACE base64-dn) dn =3D base64-dn =3D rdn =3D base64-rdn =3D attrval-spec =3D attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE = value)) / ("::" *SPACE base64-value=20 *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url =3D ; (See Note 6, below) attribute-description =3D charset-option =3D "charset=3D" ( "*" / charset-name ) charset-name =3D a character set name, as registered with = IANA [10] value =3D 1*safe-initval *safe safe =3D safe-initval =3D base64-value =3D changerecord =3D change-add / change-delete / change-modify = / change-moddn change-add =3D "changetype:" *SPACE "add" 1*(SEP = attrval-spec) change-delete =3D "changetype:" *SPACE "delete" change-moddn =3D "changetype:" *SPACE ("modrdn" / "moddn") = SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify =3D "changetype:" *SPACE "modify" 1*(SEP = mod-spec) mod-spec =3D mod-add-spec / mod-delete-spec / = mod-replace-spec mod-add-spec =3D "add:" *(*SPACE attribute-description) 1*(SEP attrval-spec) SEP "-" mod-delete-spec =3D "delete:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" mod-replace-spec =3D "replace:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" SPACE =3D SEP =3D (CR LF / LF) CR =3D LF =3D DIGIT =3D Agreements An agreement ID can optionally be in the first part of an LDIF file. = This=20 agreement specification can be used to give a unique identification = of the=20 scope of an information exchange. Such an agreement can be include = such=20 things as: 1) What information has to be transferred and possibly kept updated = by the=20 sender. 2) The attribute types and object classes that are part of the = transport=20 including what textual representations are going to be used. In case = of=20 high-volume exchanges, the two parties can agree on an abbreviated = form of=20 textual representation. As an example "tel" could be an abbreviated = form=20 of TelephoneNumber. 3) An understanding of what information is necessary to transfer to = ensure=20 the correlation process, i.e. locating an existing entry, if any. 4) How much of a distinguished name that needs to be transferred. As = an=20 example, the country name could have a default value. 5) How much information that is needed for the objectClass = attribute. If=20 the object class for the entry information is, say, = residentialPerson, it=20 may not be necessary also to specify the super-classes person and = top.=20 They could be implied. 6) Agreement on not to use spaces where they are optional. 7) Update frequency. Establishment of an agreement is a completely off-line activity not=20 directly reflected in the protocol. If there is no agreement-id specified, an implied agreement is = assumed.=20 There can only be one implicit agreement between a particular sender = and a=20 particular recipient. Note on LDIF syntax and usage 1) The "dn:" or the "s:" specification signals the start of a new = record.=20 The end of a record is implicitly signalled by the start of a new = record=20 or by the end of file. (Temporary note: From a message from Gordon, = I understand that the records are separated by two SEP fields. I have = not been able to gather that from the current LDIF specification. It may = be my lack of understanding the Backus-Nauer notation. I prefer the = separation by two SEP fields. This note should therefore probably be deleted.) 2) The "total" specification indicates that all information related = to the=20 agreement should be purged and replaced by the information in the = current=20 transfer. This does not necessarily mean that current entries are=20 completely deleted during the first part of this process as there = may be=20 local information or information from other agreements within those=20 entries. 3) When doing incremental updates: a) Only information owned by the sender can be changed. Additional = information may be transmitted to allow identification of the = entries to=20 be changed. If the "dn:" specification is used, only the = distinguished=20 name should be supplied in addition to change or delete = specifications to=20 ensure compatibility with earlier versions. For "s:" = specifications,=20 additional information will have to be supplied to identify the = entries in=20 question. b) Records without any "changetype" specification are to be = considered as=20 new entries to be added. c) A "delete" operation only applies to the part of the entry = holding=20 information owned by the sender according to the current = agreement. 4) The optional "own" specification starts a block of information, = for=20 which the sender is the master, and which by the receiver can be = added to=20 its local database or update previously received information. As an=20 example, a mobile telephone number allocated by a mobile telephone=20 operator is owned by that operator and will be present in this block = when=20 this mobile operator is transmitting information to other parties. 5) The optional "other" specification starts a block of information=20 assumed to be owed by other organisations or systems including the=20 recipient system. This information is primarily intended for = identifying=20 an already existing entry. As an example, a mobile operator may = supply the=20 fixed telephone number in a record, although the fixed telephone is=20 subscribed from another operator. If there is information in this = block=20 that is currently not present at the recipient, it a local option = for the=20 receiver whether to store it or dispose of it in any other way. 6) Any attribute information placed before an "own" or an "other"=20 specification is considered part of the "own" part. If none of the = two=20 specifications are present, all attribute information is considered = "own"=20 information. 7) In some cases it may not be possible to denote some pieces of=20 information belonging to anyone. As an example, object class=20 specification, postal address, etc. may be considered general = information=20 maintained independently by each system. If such information is not=20 consistent across systems, correlation may not be possible. Such = general=20 information should be in the "other" block. 8) The "dn" is the distinguished name of the entry. This is not a=20 mandatory field. However, if this field is not present, the "s" = field MUST=20 be explicitly or implicitly present. This filed MUST NOT be present = if the=20 "s" field is present. This field shall only be used if the complete=20 distinguished name is understood by both parties to denote the same=20 object. As an example, the name of a reasonable seized company is = assumed=20 to be unique within a certain geographical area. This field MUST be = used=20 if the entry has subordinate entries. 9) An abbreviated form of distinguished name may be used. This = abbreviated=20 form MUST NOT be used unless the preceding record has a "dn"=20 specification. The first item on in the abbreviated specification is = a=20 level indication telling how large a part of the distinguished name = of the=20 preceding record that is inherited. The remaining items are one or = more=20 RDNs that are prefixed the inherited part to get a complete = distinguished=20 name. 10) The "s" field gives the distinguished name of the superior = entry. This=20 field can only be used for leaf entries, e.g. residential persons, = and it=20 is used if it not possible to establish a distinguished name that is = globally recognised. When this field is present, it is assumed that = the=20 recipient from other included information, e.g. name, telephone = number,=20 postal address, etc. can determine whether the object is already = present=20 and should be updated. Otherwise, if an existing entry is not found, = the=20 receiver will generate an RDN based on local algorithms to produce a = complete distinguished name. 11) If "s" field has no associated value, the value is assumed to be = the=20 same as for the preceding record. (Temporary note: This note should probably be changed to say that if there is no "s" or "dn" = specification,=20 an "s" field is assumed having the same value as in the previous = record.=20 The absence of both the "dn" and the "s" specification, is only = allowed if=20 the previous record had an explicit or implicit "s" specification.) 12) For multi-valued attribute types, it is possible either to put = all=20 values on a single line or include a line for each attribute value. 13) If the object class attribute is not included for a record in a=20 "total" transfer, the value(s) is the same as for the previous = record. Differences from Version 1 of LDIF 1) It is possible in a header beside giving version information to=20 indicate whether an LDIF file is a complete transfer of all = information or=20 whether is an updating file 2) It is possible in the header to optionally indicate an agreement = ID in=20 case two parties have several agreements on exchanging = synchronization=20 information. 3) It is possible for each record to indicate two different blocks = of=20 information. One block, where the transmitter is the master for the=20 information and one block of information where other systems have = the=20 master role, but is information that can be used for correlation. 4) It is possible to only transfer the distinguished name of the = superior=20 of an entry in case the receiver is expected to generate the = complete=20 distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same,=20 possibly folded line. The separator between values is a back-slash = ("\") Examples of LDAP Interchange Format Example 7: A simple LDIF file with a few records sent from a mobile=20 telephone operator to some central information service total version 2 agreement-id: op1-to-op2, ver.1 dn:o=3DF&L,c=3DDK own mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 =20 dn:2 cn=3DTom Finkelstein own mobile:+4512345678 other objcl:orgPers sn:Finkdelstein gn:Tom tel:+4539450999 822:tfs@fl.dk dn:2 cn=3DPer Futtesen own mobile:+4587654321 other sn:Futtesen gn:Per tel:+4539450998 822:tfs@fl.dk s:L=3D1815,ST=3DCopenhagen own mobile:+4520971490 other objcl:resPers sn:Andersen gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv city:Frederiksberg tel:+4531230490 s: own mobile:+4587654321 other sn:Petersen gn:Peter street:Paludan Mullersvej num:114 floor:3 city:Frederiksberg tel:+4523456789 Example 8: A simple LDIF file with a few update records sent from a = mobile=20 telephone operator to some central information service incremental version 2 agreement-id: op1-to-op2, ver.1 # Delete an entry. The mobile number and the name is considered = sufficient=20 # information for locating the right entry s:L=3D1815,ST=3DCopenhagen own changetype:delete mobile:+4520971490 other sn:Andersen gn:Erik # Update existing entry s: own replace: mobile:+4587654321 mobile:+4598765432 - other sn:Petersen gn:Peter # Add new entry =20 s:L=3D1864,ST=3DCopenhagen own mobile:+4534567890 other objcl:resPers sn:Frederiksen gn:John street:Grundtvigsvej num:245 floor:5 floorentity:tv city:Frederiksberg tel:+4531230490 ------ =_NextPart_000_01BD1F47.99D034A0-- From owner-ietf-ldup Mon Jan 12 02:39:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA07761 for ietf-ldup-bks; Mon, 12 Jan 1998 02:39:34 -0800 (PST) Received: from penrose.isocor.ie (penrose.isocor.ie [194.106.155.117]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA07757 for ; Mon, 12 Jan 1998 02:39:27 -0800 (PST) Received: from paradise.isocor.ie (194.106.155.200) by penrose.isocor.ie; 12 Jan 1998 10:42:45 +0000 Received: from mcbain.isocor.ie (194.106.155.229) by paradise.isocor.ie (NPlex 2.0.066); 12 Jan 1998 10:42:58 +0000 Received: by mcbain.isocor.ie with Microsoft Mail id <01BD1F46.B3D0F6B0@mcbain.isocor.ie>; Mon, 12 Jan 1998 10:41:56 -0000 Message-ID: <01BD1F46.B3D0F6B0@mcbain.isocor.ie> From: david sutton To: "'gordon.good@netscape.com'" Cc: "'ietf-ldup@imc.org'" Subject: Comments on draft-ietf-asid-changelog-01.txt Date: Mon, 12 Jan 1998 10:41:55 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD1F46.B3D0F6B0" Sender: owner-ietf-ldup@imc.org Precedence: bulk ------ =_NextPart_000_01BD1F46.B3D0F6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gordon, I was scanning through draft-ietf-asid-changelog-01.txt and have a = couple of comments: 1) Comments on 'Background and Intended Usage' "Existing replication methods used by the X.500 directory, and by certain standalone LDAP implementations (namely, the University of Michigan ldap-3.3 release) are supplier-initiated in nature. That is, a server which holds authoritative data for some directory subtree connects to another server and synchronizes the other server's copy of the data. This approach requires that a pre- arranged replication agreement exist between the two servers exchanging data. This restriction is an impediment to implementation of ad-hoc replication configurations which might be desirable in a corporate intranet." and later "We term this approach "consumer-initiated replication" to differentiate it from the existing method, which we call "supplier-initiated replication"." This is not correct as the X.500 model allows either side to initiate = the exchange (i.e. both consumer-initiated and supplier-initiated = replication are supported). The real point of comparision with X.500 is = that a pre-existing replication agreement is required before replication = can take place -- whereas the change log method doesn't require this = (subject to security considerations of course). So I'd suggest replacing: Existing replication methods used by the X.500 directory, and by certain standalone LDAP implementations (namely, the University of Michigan ldap-3.3 release) are supplier-initiated in nature. That is, a server which holds authoritative data for some directory subtree connects to another server and synchronizes the other server's copy of the data. This approach requires that a pre- arranged replication agreement exist between the two servers exchanging data. This restriction is.... with: Existing replication methods used by the X.500 directory, and by certain standalone LDAP implementations (namely, the University of Michigan ldap-3.3 release) require that a pre-arranged replication=20 agreement exist between the two servers exchanging data. = Additionally, in some standalone LDAP implementations the replication method is supplier-initiated in nature requiring that the server which holds=20 authoritative data for some directory subtree connects to another = server and synchronizes the other server's copy of the data. These = restrictions are.... and deleting the sentence We term this approach "consumer-initiated replication" to differentiate = it from the existing method, which we call "supplier-initiated = replication". completely. The phrase "consumer-initated replication" is not used = anywhere else in the draft. 2) Security Considerations In the section dealing with security it is stated: <> In fact it is equally true that the "targetDN" attribute MUST NOT be = generally readable either. It could be just as serious a security breach = for the existence of an entry to be exposed in the ChangeLogs when the = access controls for the entry itself have tight restrictions on = revealing its existence. However, it doesn't seem to make much sense to = have a readable ChangeLogEntry if the "targetDN" attribute isn't = readble. So its probably worth expanding the security considerations = section a little by replacing the first two paragraphs with these three. Security Considerations Servers implementing this scheme MUST NOT allow the ChangeLogEntry = objects to=20 be generally readable. Generally they will only be readable by = certain trusted DNs. =20 Furthermore, it is likely that there could be even stricter controls = on individual attributes within individual ChangeLogEntry objects, so that it = should not be assumed by=20 replicating clients that access to an individual ChangeLogEntry = object implies access to all of its attributes. For example the "changes" attribute = contains all modifications made to an entry, and some changes may contain sensitive data, e.g. passwords. If a server does allow read access on the "changes" or "targetDN" = attribute to a particular bound DN, then that DN should be trusted. For example, = two cooperating servers may exchange the password for some DN which is granted read access to the "changes" attribute of the changeLog. = This would allow one server to retrieve changes and apply them directly to its database. =20 ..... and so on .... ------ =_NextPart_000_01BD1F46.B3D0F6B0 Content-Type: text/x-vcard; name="David Sutton (E-mail).vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:;David Sutton;;; FN:David Sutton (E-mail) ORG:ISOCOR; TITLE:Directory Architect TEL;WORK;VOICE:+ 353 1 676 0366 TEL;WORK;FAX:+ 353 1 676 0856 ADR;WORK:;;42 - 47 Lower Mount St.;Dublin 2;;;Ireland LABEL;WORK;ENCODING=QUOTED-PRINTABLE:42 - 47 Lower Mount St.=0D=0ADublin 2, =0D=0AIreland EMAIL;PREF;INTERNET:david.sutton@isocor.com REV:19971219T110312Z END:VCARD ------ =_NextPart_000_01BD1F46.B3D0F6B0-- From owner-ietf-ldup Mon Jan 12 13:47:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA19548 for ietf-ldup-bks; Mon, 12 Jan 1998 13:47:31 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA19543 for ; Mon, 12 Jan 1998 13:47:27 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA00087 for ; Mon, 12 Jan 1998 13:51:09 -0800 (PST) Received: from netscape.com ([205.217.229.74]) by dredd.mcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA29392; Mon, 12 Jan 1998 13:51:09 -0800 Message-ID: <34BA904B.F4E7A163@netscape.com> Date: Mon, 12 Jan 1998 13:51:07 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Erik Andersen CC: "'LDUP'" Subject: Re: FW: Extended LDIF References: <98Jan12.104858gmt+0100.26885-4@gw.fl.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@imc.org Precedence: bulk Erik Andersen wrote: > Hi Folks, > > Apparently, I forgot to include the file. Sorry about that. Also, in a > note Gordon has stated that records are separated by two new lines. I > have not been able to gather that from the current LDIF specification, > which may easily be a shortcoming of mine. It's not explicitly written that way, but note that an LDIF file consists of a series of either ldif-content or ldif-changes constructs terminated by newlines. These ldif-content and ldif-changes constructs are themselves composed of records which are terminated by a newline. The end of either an ldif-content, or ldif-changes construct, then, is signaled by the two consecutive newlines which, respectively, terminate the last record in the construct, and terminate the construct itself. From owner-ietf-ldup Tue Jan 13 01:15:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA28027 for ietf-ldup-bks; Tue, 13 Jan 1998 01:15:57 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA28020 for ; Tue, 13 Jan 1998 01:15:47 -0800 (PST) Received: by gw.fl.dk id <26885-2>; Tue, 13 Jan 1998 10:21:00 +0100 Message-Id: <98Jan13.102100gmt+0100.26885-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: RE: FW: Extended LDIF Date: Tue, 13 Jan 1998 10:20:24 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi Gorden and others, I see what you mean, although I am missing a SEP at the end of ldif-attrval-record construct. I probably messed-up the whole issue of SEPs. Also, I forgot a few changes here end there. I will send a new version later today. What is the attitute. Will I be able to progress a corrected version of my proposal to LDIF extensions through the LDUP group? Kind regards, Erik > -----Original Message----- > From: ggood@netscape.com [SMTP:ggood@netscape.com] > Sent: 12. januar 1998 22:51 > To: Erik Andersen > Cc: 'LDUP' > Subject: Re: FW: Extended LDIF > > Erik Andersen wrote: > > > Hi Folks, > > > > Apparently, I forgot to include the file. Sorry about that. Also, in > a > > note Gordon has stated that records are separated by two new lines. > I > > have not been able to gather that from the current LDIF > specification, > > which may easily be a shortcoming of mine. > > It's not explicitly written that way, but note that an LDIF file > consists of a > series of either ldif-content or ldif-changes constructs terminated by > newlines. These ldif-content and ldif-changes constructs are > themselves > composed of records which are terminated by a newline. The end of > either an > ldif-content, or ldif-changes construct, then, is signaled by the two > consecutive newlines which, respectively, terminate the last record in > the > construct, and terminate the construct itself. From owner-ietf-ldup Tue Jan 13 06:10:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA04306 for ietf-ldup-bks; Tue, 13 Jan 1998 06:10:12 -0800 (PST) Received: from fl.dk (ns.fl.dk [193.88.152.146]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA04300 for ; Tue, 13 Jan 1998 06:10:04 -0800 (PST) Received: by gw.fl.dk id <26886-2>; Tue, 13 Jan 1998 15:15:39 +0100 Message-Id: <98Jan13.151539gmt+0100.26886-2@gw.fl.dk> From: Erik Andersen To: "'LDUP'" Subject: Extended LDIF format Date: Tue, 13 Jan 1998 15:15:05 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD2036.08676AC0" Sender: owner-ietf-ldup@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD2036.08676AC0 Content-Type: text/plain As promised in an earlier note, I have produced a new version of my proposal for an extended LDIF. During this process I discovered som very fatal error in my Backus-Naur specification for which I am quite ashame. I have also made a few simplifications. The result of all this is that the proposed changes do look as drastic as before. Any comments? Kind regards, Erik ------ =_NextPart_000_01BD2036.08676AC0 Content-Type: text/plain; name="LDIF_EXT.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LDIF_EXT.txt" This note suggests some changes to the current LDIF format to extend = its=20 usability to more areas. It should be read as a delta to the current = Internet=20 draft. The note is not in the form of an Internet draft. It is put up = on the=20 LDUP mailing list for comments. ------------------------------------------------------------------------= ----- Background and Intended Usage (addition) Different directory systems may hold different pieces of directory=20 information about the same object. Such systems may have a = requirement to=20 update each other or to update a central directory system to merge = all=20 relevant information. A record that is sent by one system to another may represent a = complete=20 entry by the sender. However, the recipient may already have = information=20 about the object in question. Adding a new entry through LDIF may = not=20 actually cause creation of a new entry, but may add information to = an=20 already existing entry. In this case, the recipient will have to = perform=20 correlation by different means to try to locate an existing entry=20 corresponding to the received record. If a globally unique = distinguished=20 name is transferred, correlation is straightforward. However, if = such a=20 distinguished name is not available, additional information carried = in the=20 record may be used for this correlation. It is application dependent = what=20 information that is then necessary. A high level of correlation=20 accurateness is necessary not to corrupt the directory information. In some cases it may be difficult to have a common scheme for = allocating=20 distinguished names. As an example, it may be possible to get some=20 agreement on how a country should be structured into some hierarchy = of=20 localities. However, it is quite difficult to allocate RDNs for=20 residential persons common to all directory systems. Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file =3D ldif-content / ldif-changes ldif-content =3D ["total" 1*SEP] heading = ldif-attrval-record *(1*SEP ldif-attrval-record) ldif-changes =3D ["incremental" 1*SEP] heading = ldif-change-record *(1*SEP ldif-change-record) heading =3D 0,1*(version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] agreement-id =3D 1*safe-initval ldif-attrval-record =3D dn-spec SEP 1*(attrval-spec SEP) ["other" SEP 1*(attrval-spec SEP)] ldif-change-record =3D dn-spec SEP 1*(changerecord SEP) ["own" SEP 1*(attrval-spec SEP)] ["other" SEP 1*(attrval-spec SEP)] version-spec =3D "version:" *SPACE version-number version-number =3D 1*DIGIT ; version-number MUST be "2" for = the ; LDIF format described in this = document. dn-spec =3D ("dn:" *SPACE dn) / ("dn::" *SPACE = base64-dn) / ("dn:" *SPACE 1*DIGIT rdn *(("," / ";") *SPACE rdn)) / ("dn::" *SPACE 1*DIGIT base64-rdn *(("," / ";") *SPACE base64-rdn )) / ("s:" *SPACE dn) / ("s::" *SPACE base64-dn) dn =3D base64-dn =3D rdn =3D base64-rdn =3D attrval-spec =3D attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE = value)) / ("::" *SPACE base64-value=20 *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url =3D ; (See Note 6, below) attribute-description =3D charset-option =3D "charset=3D" ( "*" / charset-name ) charset-name =3D a character set name, as registered with = IANA [10] value =3D 1*safe-initval *safe safe =3D safe-initval =3D base64-value =3D changerecord =3D change-add / change-delete / change-modify = / change-moddn change-add =3D "changetype:" *SPACE "add" 1*(SEP = attrval-spec) change-delete =3D "changetype:" *SPACE "delete" change-moddn =3D "changetype:" *SPACE ("modrdn" / "moddn") = SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify =3D "changetype:" *SPACE "modify" 1*(SEP = mod-spec) mod-spec =3D mod-add-spec / mod-delete-spec / = mod-replace-spec mod-add-spec =3D "add:" *(*SPACE attribute-description) 1*(SEP attrval-spec) SEP "-" mod-delete-spec =3D "delete:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" mod-replace-spec =3D "replace:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" SPACE =3D SEP =3D (CR LF / LF) CR =3D LF =3D DIGIT =3D Agreements An agreement ID can optionally be in the first part of an LDIF file. = This=20 agreement specification can be used to give a unique identification = of the=20 scope of an information exchange. Such an agreement can be include = such=20 things as: 1) What information has to be transferred and possibly kept updated = by the=20 sender. 2) The attribute types and object classes that are part of the = transport=20 including what textual representations that are going to be used. In = case=20 of high-volume exchanges, the two parties can agree on an = abbreviated form=20 of textual representation. As an example "tel" could be an = abbreviated=20 form of TelephoneNumber. Textual representations of attribute types = MUST=20 be unique within an agreement. Likewise for textual representation = of=20 object classes. 3) An understanding of what information is necessary to transfer to = ensure=20 the correlation process, i.e. locating an existing entry, if any. 4) How much of a distinguished name that needs to be transferred. As = an=20 example, the country name could have a default value. 5) How much information that is needed for the objectClass = attribute. If=20 the object class for the entry information is, say, = residentialPerson, it=20 may not be necessary also to specify the super-classes person and = top.=20 They could be implied. Also auxiliary object classes can be implied. = It=20 MUST be completely understood by both parties what set of object = classes=20 is behind a single object class textual specification. 6) Agreement on not to use spaces where they are optional. 7) Agreement not to use any unnecessary SEPs, i.e. consider the = 1*SEP=20 specification as equal to just SEP. 8) Agreement on only using LF for SEP. 9) Update frequency. Establishment of an agreement is a completely off-line activity not=20 directly reflected in the protocol. If there is no agreement-id specified, an implied agreement is = assumed.=20 There can only be one implicit agreement between a particular sender = and a=20 particular recipient. Note on LDIF syntax and usage 1) Some of the information in a record is "owned" by the sender, = i.e. the=20 sender is master for that information. This information is located = just=20 after the "dn" or the "s" specification, and may be the only = information=20 in a record. Additional information may be supplied in a record to = aid the=20 receiver in uniquely identifying the identity of the corresponding = entry. 2) The optional "own" specification starts a block of information, = for=20 which the sender is the master. The optional "other" specification = starts=20 a block of information assumed to be owed by other organizations or=20 systems including the recipient system. Such types of information = are=20 primarily intended for identifying an already existing entry. As an=20 example, a mobile operator may supply the fixed telephone number in = a=20 record, although the fixed telephone is subscribed from another = operator.=20 If there is information in these blocks that is currently not = present at=20 the recipient, it a local option for the recipient whether to store = it or=20 dispose of it in any other way. 3) When doing total update: a) All information related to the agreement SHOULD be purged and=20 replaced by the information in the current transfer. This does = not=20 necessarily mean that current entries are completely deleted = during=20 the first part of this process, as there may be local information = or=20 information from other agreements within those entries. b) Information following the "other" specification is only = intended=20 for entry identification. Such information MUST be included if = the "s"=20 specification is used. 4) When doing incremental update: a) Only information owned by the sender can be changed. = Additional=20 information may be transmitted to allow identification of the = entries=20 to be changed. If the "dn:" specification is used, only the=20 distinguished name SHOULD be supplied in addition to change or = delete=20 specifications to ensure compatibility with earlier versions. For = records starting with an implicit or explicit "s:" specification, = additional information MUST be supplied for entry identification. b) Records without any "changetype" specification are to be = considered=20 as new entries to be added. Such a record MAY NOT have an = explicit=20 "own" part. For records starting with an implicit or explicit = "s:"=20 specification, an "other" part MUST be supplied for entry=20 identification. c) A record with "changetype" equal to "delete" only applies to = the=20 part of the entry holding information owned by the sender = according to=20 the current agreement. For records starting with an implicit or=20 explicit "s:" specification MUST beside the delete specification = have=20 an "own" and/or an "other" part for entry identification. d) A record with "changetype" equal to "modify" and which starts = with=20 an implicit or explicit "s:" specification MUST besides the = change=20 specifications have an "own" and/or an "other" part for entry=20 identification. 5) In some cases it may not be possible to denote some pieces of=20 information belonging to anyone. As an example, object class=20 specification, postal address, etc. may be considered general = information=20 maintained independently by each system. If such information is not=20 consistent across systems, correlation may not be possible. Such = general=20 information should be in the "other" block. 6) The "dn" is the distinguished name of the entry. This is not a=20 mandatory field. However, if this field is not present, the "s" = field MUST=20 be explicitly or implicitly present. This filed MUST NOT be present = if the=20 "s" field is present. This field shall only be used if the complete=20 distinguished name is understood by both parties to denote the same=20 object. As an example, the name of a reasonable seized company is = assumed=20 to be unique within a certain geographical area. This field MUST be = used=20 if the entry has subordinate entries. 7) An abbreviated form of distinguished name may be used. This = abbreviated=20 form MAY NOT be used unless the preceding record has a "dn" = specification.=20 The first item on in the abbreviated specification is a level = indication=20 telling how large a part of the distinguished name of the preceding = record=20 that is inherited. This item MUST include the defaulted part of the=20 distinguished. AS an example, if the country name is implied, the = country=20 name component is still counted. The remaining items are one or more = RDNs=20 that are prefixed the inherited part to get a complete distinguished = name. 8) The "s" field gives the distinguished name of the superior entry. = This=20 field can only be used for leaf entries, e.g. residential persons, = and it=20 is used if it not possible to establish a distinguished name that is = globally recognized. When this field is present, it is assumed that = the=20 recipient from other included information, e.g. name, telephone = number,=20 postal address, etc. can determine whether the object is already = present=20 and should be updated. Otherwise, if an existing entry is not found, = the=20 receiver will generate an RDN based on local algorithms to produce a = complete distinguished name for its own use. 9) If there is no "s" or "dn" specification, an "s" field is assumed = having the same value as in the previous record. The absence of both = the=20 "dn" and the "s" specification is only allowed if the previous = record had=20 an explicit or implicit "s" specification. 10) For multi-valued attribute types, it is possible either to put = all=20 values on a single line or include a line for each attribute value. 11) If the object class attribute is not included for a record in a=20 "total" transfer, the value(s) is the same as for the previous = record. Differences from Version 1 of LDIF 1) It is possible in a header besides giving version information to=20 indicate whether an LDIF file is a complete transfer of all = information or=20 whether is an updating file 2) It is possible in the header to optionally indicate an agreement = ID in=20 case two parties have several agreements on exchanging = synchronization=20 information. 3) It is possible for each record to include information that is not = intended for storage by the receiver, but is aiding the receiver in=20 identifying a particular entry. 4) It is possible to only transfer the distinguished name of the = superior=20 of an entry in case the receiver is expected to generate the = complete=20 distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same,=20 possibly folded line. The separator between values is a back-slash = ("\") Examples of LDAP Interchange Format Example 7: A simple LDIF file with a few records sent from a mobile=20 telephone operator to some central information service total version 2 agreement-id: op1-to-op2, ver.1 dn:o=3DF&L,c=3DDK mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 =20 dn:2 cn=3DTom Finkelstein mobile:+4512345678 other objcl:orgPers sn:Finkdelstein gn:Tom tel:+4539450999 822:tfs@fl.dk dn:2 cn=3DPer Futtesen mobile:+4587654321 other sn:Futtesen gn:Per tel:+4539450998 822:tfs@fl.dk s:L=3DFrederiksberg C,ST=3DCopenhagen mobile:+4520971490 other objcl:resPers sn:Andersen gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv tel:+4531230490 mobile:+4587654321 other sn:Petersen gn:Peter street:Paludan Mullersvej num:114 floor:3 tel:+4523456789 Example 8: A simple LDIF file with a few update records sent from a = mobile=20 telephone operator to some central information service incremental version 2 agreement-id: op1-to-op2, ver.1 # Delete an entry. The mobile number and the name is considered = sufficient # information for locating the right entry s:L=3D1815,ST=3DCopenhagen changetype:delete own mobile:+4520971490 other sn:Andersen gn:Erik # Update existing entry replace: mobile:+4587654321 mobile:+4598765432 - other sn:Petersen gn:Peter # Add new entry s:L=3DHellerup,ST=3DCopenhagen mobile:+4534567890 other objcl:resPers sn:Frederiksen gn:John street:Grundtvigsvej num:245 floor:5 floorentity:tv tel:+4531230490 ------ =_NextPart_000_01BD2036.08676AC0-- From owner-ietf-ldup Fri Jan 16 15:56:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA08991 for ietf-ldup-bks; Fri, 16 Jan 1998 15:56:36 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA08964 for ; Fri, 16 Jan 1998 15:56:31 -0800 (PST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Fri, 16 Jan 1998 16:00:46 -0800 Message-ID: From: Chris Weider To: "'minutes@ietf.org'" , "'ietf-ldup@imc.org'" Cc: "'rweiser@novell.com'" Subject: Final minutes from LDUP Date: Fri, 16 Jan 1998 16:00:42 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk No corrections were received. Chris Minutes from the LDUP BOF, Washington, DC The agenda was as follows: 10 minutes on terminology, 30 minutes on approaches, 20 minutes on charter The intent was to define an approach on how to do LDAP replication, get a charter to form a wg, and then go forth. The group generally agreed that the focus of an LDUP working group should be on directory synchronization, rather than making server A look exactly like server B in terms of functionality, which will be impossible in an environment where vendors are providing value-add functionality on top of their servers. The first two items an LDUP working group would work on would be a requirements document and an applicability statement. There were 4 major work items identified as possibilities after that: One-way directory synchronization (dir synch), 2-way dir synch, floating single-master operations, and multi-master dir synch. 1-way dir synch is essentially the X.500 single-master, multiple slave relationship. 2-way dir synch is where you have the SAME data mastered on two servers and need to synchronize them. Floating single master is where there is only a single master server for a given set of data at any one point in time, but that server may change over time. Multi-master is directory synchronization between n servers, of which more than two can be writeable replicas of the same data. Open questions: Do we need to solve the schema synch problem to make progress on general dir synch? Do we need to solve the distributed knowledge synch problem? What about security and access control? Do we need to standardize the mechanisms for selecting which content to replicate? Do we need to standardize how the directory is initially populated (as well as reload of data)? Do we need to cover replica compare and replica diff? Additional items: Cross-realm replication Partial and fractional replication Consistency models will be covered in the applicability statement Items ruled out of scope were: Request forwarding (e.g. chaining) Index-only replication a la the Common Indexing Protocol Integration with TIP There was no consensus on which order to cover the work items. Thus this will be discussed on the list, with a draft charter to be produced by mid-January. From owner-ietf-ldup Mon Jan 26 15:32:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA11195 for ietf-ldup-bks; Mon, 26 Jan 1998 15:32:45 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA11191 for ; Mon, 26 Jan 1998 15:32:41 -0800 (PST) Received: by INET-02-IMC with Internet Mail Service (5.5.1960.3) id ; Mon, 26 Jan 1998 15:37:39 -0800 Message-ID: From: Chris Weider To: "'ietf-ldup@imc.org'" Subject: LDUP charter discussion Date: Mon, 26 Jan 1998 15:37:36 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ldup@imc.org Precedence: bulk Hi folks: From the minutes: Potential work items: 1. 1-way dir synch 2. 2-way dir synch 3. Floating single master dir synch 4. Multi-master dir synch Open questions: 5: Do we need to solve the schema synch problem to make progress on general dir synch? 6: Do we need to solve the distributed knowledge synch problem? 7: What about security and access control? 8: Do we need to standardize the mechanisms for selecting which content to replicate? 9: Do we need to standardize how the directory is initially populated (as well as reload of data)? 10: Do we need to cover replica compare and replica diff? Additional items: Cross-realm replication Partial and fractional repliation Consistency models There was a discussion at the IETF about which of the potential work items should be done. Everyone was pretty happy with 1,2, and 4. There was less consensus on 3. There was no consensus on which order these items should be done in. In any case, the first work items for the group would need to be a requirements document and an applicability statement. On the open questions, my thinking goes 5: No, as these mechanisms should be flexible enough to synch with targets other than LDAP servers 6: Yes, if we want LDAP servers to have as consistent a view of the world as possible 7: Absolutely but we're blocked on the access control standard 8: Yes 9: Yes 10: No We need a definition of 'cross-realm replication'. I'd like to see if there's some sort of consensus by the middle of next week (Feb 5). Let the games begin :^) Chris From owner-ietf-ldup Mon Jan 26 18:01:19 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA12004 for ietf-ldup-bks; Mon, 26 Jan 1998 18:01:19 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA12000 for ; Mon, 26 Jan 1998 18:01:14 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 26 Jan 1998 19:05:42 -0700 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Mon, 26 Jan 1998 19:03:34 -0700 From: "Ed Reed" To: ietf-ldup@imc.org, cweider@microsoft.com Subject: Re: LDUP charter discussion Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ietf-ldup@imc.org Precedence: bulk Let the games be engaged! I agree work should proceed on 1, 2, and 4. I've not seen requirements = for 3 in our work. 5 - YES - even if, as Chris points out below, mechanisms should be able to = synch with non-LDAP directories, I strongly believe that a formal = meta-schema needs to be agreed to, and means to express the schema of the = data being transmitted, as part of any rational synchronization scheme = (sorry for the pun!) 6 - Yes - the management of distributed knowledge, ie the various = addresses associated with superior and subordinate references in the = namespace, is the only way I know to inform LDAP servers about referrals = to be returned for non-local data. Synchronization of addresses, server = names, replica types, sparse replica and index inventories, etc. is really = needed to create a distributed LDAP service, which is what I (we?) really = want to see evolve. At the very least, let us agree on a base set of = attributes, their interpretation, access controls on whether they may be = replicated (it's not always desireable), and a way to extend the set of = attributes associated with subordinate references (for things like = inherited attribute values, access control policies, and other operational = information). 7 - Yes - Without security and access control standards, we'll only be = synchronizing public, valueless information...we're supposed to be working = towards interoperable solutions, even ones which will allow customers to = build distributed services from a mixed group of heterogeneous suppliers. = Now, that may be ambitious, and may even run counter to some technology = providers' objectives (my own company has been accused of such things in = the past, even!) - and it's a hard thing. But isn't that what the = industry is expecting? Does ANYONE want to explain to the press that LDAP = is only about address book synchronization, and not network management or = user management? Not ME! 8 - Not immediately. As long as the synchronization information is fully = self contained (see #6 above). 9 - No - only as a special case of synchronization (I got stuff and you = don't). However, SOMEONE should document and continue to develop LDIF as = a flat file representation of data to be loaded. That could as easily be = done here as other places, I guess. 10 - I mentioned these at the meeting in Washington. I suspect most folks = will have trouble debugging their directories and the interoperability = conformance of synchronization protocols with out it. "Ok, you've = completed the synch - are our two replicas really the same? Prove it!" Comments welcome! Ed ------------------- Ed Reed, Chief Architect Network Services Group Novell, Inc. +1 801 861 3320 >>> Chris Weider 01/26/98 04:37PM >>> Hi folks: From the minutes: Potential work items: 1. 1-way dir synch 2. 2-way dir synch 3. Floating single master dir synch 4. Multi-master dir synch Open questions: 5: Do we need to solve the schema synch problem to make progress on = general dir synch? 6: Do we need to solve the distributed knowledge synch problem? 7: What about security and access control? 8: Do we need to standardize the mechanisms for selecting which content to replicate? 9: Do we need to standardize how the directory is initially populated (as well as reload of data)? 10: Do we need to cover replica compare and replica diff? Additional items: Cross-realm replication Partial and fractional repliation Consistency models There was a discussion at the IETF about which of the potential work items should be done. Everyone was pretty happy with 1,2, and 4. There was less consensus on 3. There was no consensus on which order these items should = be done in. In any case, the first work items for the group would need to be = a requirements document and an applicability statement.=20 On the open questions, my thinking goes 5: No, as these mechanisms should be flexible enough to synch with targets other than LDAP servers 6: Yes, if we want LDAP servers to have as consistent a view of the world = as possible 7: Absolutely but we're blocked on the access control standard 8: Yes 9: Yes 10: No We need a definition of 'cross-realm replication'.=20 I'd like to see if there's some sort of consensus by the middle of next = week (Feb 5). Let the games begin :^) Chris From owner-ietf-ldup Sat Jan 31 14:25:03 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA03591 for ietf-ldup-bks; Sat, 31 Jan 1998 14:25:03 -0800 (PST) Received: from cupcake.cisco.com (cupcake.cisco.com [171.69.1.242]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA03584 for ; Sat, 31 Jan 1998 14:24:59 -0800 (PST) Received: from jstrassn-pc ([171.69.108.130]) by cupcake.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id OAA19402; Sat, 31 Jan 1998 14:29:42 -0800 (PST) Message-Id: <3.0.2.32.19980131142934.00abee20@cupcake.cisco.com> X-Sender: jstrassn@cupcake.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sat, 31 Jan 1998 14:29:34 -0800 To: "Ed Reed" , ietf-ldup@imc.org, cweider@microsoft.com From: "John C. Strassner" Subject: Re: LDUP charter discussion In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@imc.org Precedence: bulk I have seen requirements for 1-4. I think that the order should be as is (with the option that 3 be removed if there is a sufficient lack of interest), though i would like to go on record that in terms of need, 4 is, imho, highest. Having said that, I think that we need to at least do the work on 1 and 2 in order to be able to be in a position to do the work for 4. 5 - NO, agreeing on a formal meta-schema when we can't agree on something as simple as a person schema is hopeless. Besides, the general problem of schema synch is really hard and is fraught with many obtuse and very difficult end points. 6 - YES, I agree wi