Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12617; 5 Jul 95 13:49 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12612; 5 Jul 95 13:49 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa11996; 5 Jul 95 13:49 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Jul 1995 16:33:40 +0100 Received: from dns.johnbryce.co.il by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 5 Jul 1995 16:33:13 +0100 Received: from dns (localhost [127.0.0.1]) by dns.johnbryce.co.il (8.6.11/8.6.9) with SMTP id RAA01858 for ; Wed, 5 Jul 1995 17:36:28 +0300 Message-Id: <199507051436.RAA01858@dns.johnbryce.co.il> Date: Wed, 05 Jul 95 17:36:29 0300 X-Orig-Sender: uzi@dns.johnbryce.co.il Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: uzi X-Mailer: Mozilla 1.1N (X11; I; Linux 1.2.8 i486) MIME-Version: 1.0 To: osi-ds@cs.ucl.ac.uk Subject: x.500 data base gateways X-URL: http://web.nexor.co.uk/users/quipu/x500/x500.html Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii do you know about any products in the market who can integrate ansd synchronize data stored in relational data base and data stored in x.500 directory ?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00390; 7 Jul 95 3:53 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00386; 7 Jul 95 3:53 EDT Received: from [128.16.6.8] by CNRI.Reston.VA.US id aa00747; 7 Jul 95 3:53 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 7 Jul 1995 08:22:07 +0100 Date: Fri, 7 Jul 1995 08:22:07 +0100 X400-Originator: osi-ds-request@cs.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;haig.cs.uc.939:07.06.95.07.22.07] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 7 Jul 1995 08:22:07 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <18772.805101692@nexor.co.uk> To: panamas@paradise.ulcc.ac.uk, osi-ds@cs.ucl.ac.uk Subject: Root level prodir combined results Reply-To: prodir-support@nexor.co.uk *** N.B. The probing results below are influenced by network failures *** *See also: the WWW entry, "http://web.nexor.co.uk/users/quipu/x500/graphroot.gif" Probing from SWITCH@Zurich, SURFnet@Delft, NEXOR, Cambridge Computer Lab, ULCC, Community: internet ========== ======== No DSAs had 100.00% availability. Other DSAs: ----- ----- %Avail Organisation,DSA Attempts Average Time ------ ---------------- -------- ------------ 98.90 UNI-C, Armadillo 728 1.29 1 Invalid credentials 2 Timed out after 60 seconds 4 Connection refused 1 Connection timed out 98.76 Universitaet Wien, Rockhopper Pe... 728 2.79 6 Host is unreachable 1 Connection refused 1 Connection timed out 7 Timed out after 60 seconds 98.63 ULCC, Inca Dove 728 0.64 3 Timed out after 60 seconds 4 Connection refused 3 Connection timed out 98.49 UNINETT, Electric Eel 728 1.56 5 Connection refused 3 Connection timed out 1 Timed out after 120 seconds 2 Timed out after 60 seconds 98.35 SUNET, Andean Cat 728 1.18 2 Invalid credentials 5 Connection refused 2 Timed out after 60 seconds 3 Connection timed out 98.21 UMK, Ocelot 728 6.18 5 Timed out after 60 seconds 2 Connection refused 6 Connection timed out 98.08 SURFnet, Hornero 728 0.65 4 Timed out after 60 seconds 3 Connection refused 6 Connection timed out 98.04 Vrije Universiteit Brussel, Woolly Spider... 561 5.88 4 Connection refused 1 Invalid credentials 3 Timed out after 60 seconds 2 Connection timed out 1 Unavailable 97.39 Restena, Guppy 728 5.16 12 Timed out after 60 seconds 2 Connection refused 5 Connection timed out 2 Timed out after 120 seconds 97.06 Unknown Organisation, opaxdsa, CNRS, FR 170 1.66 2 Timed out after 60 seconds 2 Connection refused 1 Connection timed out 96.70 Unknown Organisation, opaxdsa, CNRS, FR 728 3.34 4 Connection refused 12 Timed out after 60 seconds 4 Connection timed out 4 Host is unreachable 1 Unavailable 95.75 ARNES, Proteus 729 1.43 20 Invalid credentials 5 Connection refused 2 Connection timed out 10 Timed out after 60 seconds 95.33 Victoria University of W..., Kakapo 728 3.86 14 Host is unreachable 18 Timed out after 60 seconds 2 Connection refused 4 Connection timed out 6 Invalid credentials 94.92 WIDE project, Sloth 729 4.38 15 Timed out after 60 seconds 7 Invalid credentials 9 Connection refused 10 Connection timed out 1 Unavailable 1 Host is unreachable 93.96 RedIRIS, iguana 728 2.19 7 Host is unreachable 29 Timed out after 60 seconds 5 Connection refused 5 Connection timed out 92.86 U.S. DMD, alpaca 728 2.58 38 Connection refused 14 Timed out after 60 seconds 3 Connection timed out 1 Timed out after 120 seconds 92.47 Trinity College Dublin, Irish Elk 730 3.45 6 Timed out after 60 seconds 41 Invalid credentials 14 Connection refused 3 Connection timed out 90.25 Inmarsat, Hedgehog 728 2.75 2 Unavailable 13 Timed out after 60 seconds 49 Invalid credentials 1 Connection refused 8 Connection timed out 86.87 NSTN Inc, beluga whale 731 5.70 40 Connection refused 35 Timed out after 60 seconds 3 Host is unreachable 6 Timed out after 120 seconds 4 Connection timed out 84.48 National Computer Board ..., Lion 728 10.07 49 Timed out after 60 seconds 47 Invalid credentials 6 Timed out after 120 seconds 10 Connection timed out 3 Connection refused 83.81 Australian Academic and ..., Anaconda 729 7.08 22 Timed out after 60 seconds 2 Host is unreachable 48 Invalid credentials 2 Connection refused 3 Connection timed out 1 Unavailable 82.28 SURIS, Elephant Seal 728 2.72 40 Timed out after 60 seconds 27 Invalid credentials 46 Connection refused 4 Unavailable 1 Host is unreachable 8 Connection timed out 3 Timed out after 120 seconds 80.66 RCCN Portugal, Zebu 729 13.68 104 Timed out after 60 seconds 9 Host is unreachable 2 Connection refused 7 Connection timed out 4 Timed out after 120 seconds 4 Unavailable 77.37 Foundation Of Research a..., Caretta Caretta 729 9.63 44 Timed out after 60 seconds 123 Connection refused 23 Invalid credentials 1 Unavailable 1 Timed out after 120 seconds 77.06 Matej Bel University, UA..., Tarpon 728 3.70 158 Invalid credentials 2 Connection refused 4 Connection timed out 75.00 Unknown Organisation, Dragon 728 14.02 77 Timed out after 60 seconds 44 Host is unreachable 21 Unavailable 61 Invalid credentials 2 Connection refused 5 Connection timed out 74.31 Technische Universitaet ..., Puma 728 4.89 173 Timed out after 60 seconds 2 Invalid credentials 10 Connection timed out 2 Connection refused 1 Timed out after 120 seconds 72.94 GARR-NIS, Black Widow 728 2.14 23 Timed out after 60 seconds 122 Connection refused 72 Invalid credentials 5 Timed out after 120 seconds 3 Connection timed out 71.43 GARR-NIS, Black Widow 728 4.40 35 Timed out after 60 seconds 121 Connection refused 68 Invalid credentials 8 Timed out after 120 seconds 2 Connection timed out 1 Unavailable 54.40 SWITCH, Chinchilla 728 0.76 357 Invalid credentials 2 Connection refused 1 Connection timed out 1 Timed out after 60 seconds 49.86 Unknown Organisation, Dorcan Gazelle 732 9.50 221 Timed out after 60 seconds 85 Connection refused 1 Host is unreachable 3 Unavailable 2 Timed out after 120 seconds 32 Connection timed out 41.26 North Atlantic Treaty Or..., Violaceous Trogon 732 3.76 241 Connection refused 150 Timed out after 60 seconds 18 Connection timed out 2 Timed out after 120 seconds 16.92 FUNET, Northern Pudu 733 1.39 631 Connection refused 2 Timed out after 60 seconds 1 Host is unreachable 2 Connection timed out 15.28 IIT Delhi, IN, Pelican 733 21.40 227 Timed out after 60 seconds 182 Host is unreachable 17 Connection refused 4 Unavailable 24 Connection timed out 5 Timed out after 120 seconds 7.82 Universidade Federal do ..., paca 729 2.25 674 Connection refused 13 Timed out after 60 seconds 5 Connection timed out 1 Unavailable 7.14 Prague University of Eco..., woolly opossum 728 0.25 556 Timed out after 60 seconds 2 Connection refused 102 Connection timed out 2 Unavailable 6.71 University of Zagreb - F..., Roufous Motmot 730 26.27 548 Connection refused 68 Timed out after 60 seconds 9 Host is unreachable 2 Connection timed out   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07120; 7 Jul 95 12:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07116; 7 Jul 95 12:18 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa08774; 7 Jul 95 12:18 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jul 1995 15:21:46 +0100 Received: from soochak.ncst.ernet.in by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 7 Jul 1995 15:20:04 +0100 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by soochak.ncst.ernet.in (8.6.8.1/8.6.6) with SMTP id TAA03806 for ; Fri, 7 Jul 1995 19:44:52 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA24479; Fri, 7 Jul 95 19:49:35+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA09201; Fri, 7 Jul 95 19:49:42+0530 Date: Fri, 7 Jul 95 19:49:42+0530 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gopi K Garge Message-Id: <9507071419.AA09201@ece.iisc.ernet.in> To: osi-ds@cs.ucl.ac.uk Subject: Linux Quipu.. Hello, Would anyone know of a Quipu port onto Linux (1.3.2) - binaries/sources availability ? I am referring to the Quipu distribution that goes along with ISODE-8.0. Please reply to me at gopi@ece.iisc.ernet.in Thanks --Gopi Garge ERNET Project, INDIA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00376; 14 Jul 95 3:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00372; 14 Jul 95 3:57 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa00817; 14 Jul 95 3:57 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 14 Jul 1995 08:21:44 +0100 Date: Fri, 14 Jul 1995 08:21:44 +0100 X400-Originator: osi-ds-request@cs.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;haig.cs.uc.117:14.06.95.07.21.44] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 14 Jul 1995 08:21:44 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <4119.805706467@nexor.co.uk> To: panamas@paradise.ulcc.ac.uk, osi-ds@cs.ucl.ac.uk Subject: Root level prodir combined results Reply-To: prodir-support@nexor.co.uk *** N.B. The probing results below are influenced by network failures *** *See also: the WWW entry, "http://web.nexor.co.uk/users/quipu/x500/graphroot.gif" Probing from SURFnet@Delft, SWITCH@Zurich, NEXOR, Cambridge Computer Lab, Community: internet ========== ======== No DSAs had 100.00% availability. Other DSAs: ----- ----- %Avail Organisation,DSA Attempts Average Time ------ ---------------- -------- ------------ 99.59 UNINETT, Electric Eel 488 1.64 2 Timed out after 60 seconds 99.39 SURFnet, Hornero 488 0.59 3 Timed out after 60 seconds 99.18 SUNET, Andean Cat 488 1.16 2 Timed out after 60 seconds 1 Connection timed out 1 Connection refused 99.18 UNI-C, Armadillo 488 1.14 1 Timed out after 120 seconds 2 Timed out after 60 seconds 1 Connection refused 99.18 ULCC, Inca Dove 488 0.54 3 Timed out after 60 seconds 1 Connection refused 98.77 Unknown Organisation, opaxdsa, CNRS, FR 162 1.60 1 Timed out after 60 seconds 1 Unavailable 97.95 Restena, Guppy 488 4.49 7 Invalid credentials 1 Connection timed out 1 Timed out after 120 seconds 3 Timed out after 60 seconds 97.34 Unknown Organisation, opaxdsa, CNRS, FR 488 2.21 10 Timed out after 60 seconds 1 Host is unreachable 1 Unavailable 2 Connection refused 96.72 UMK, Ocelot 488 5.12 12 Timed out after 60 seconds 1 Host is unreachable 1 Invalid credentials 1 Connection timed out 96.11 ARNES, Proteus 488 1.36 19 Invalid credentials 10 Timed out after 60 seconds 1 Connection refused 95.08 Australian Academic and ..., Anaconda 488 5.61 16 Timed out after 60 seconds 19 Invalid credentials 3 Unavailable 1 Connection timed out 1 Timed out after 120 seconds 94.88 NSTN Inc, beluga whale 488 4.86 18 Timed out after 60 seconds 8 Connection refused 1 Invalid credentials 1 Connection timed out 1 Unavailable 94.67 National Computer Board ..., Lion 488 9.95 27 Timed out after 60 seconds 2 Host is unreachable 1 Unavailable 90.78 SURIS, Elephant Seal 488 2.67 10 Connection refused 31 Invalid credentials 2 Timed out after 60 seconds 2 Unavailable 89.98 Technische Universitaet ..., Puma 489 7.18 37 Timed out after 60 seconds 2 Invalid credentials 1 Timed out after 120 seconds 1 Connection timed out 89.75 Foundation Of Research a..., Caretta Caretta 488 8.64 26 Timed out after 60 seconds 1 Host is unreachable 18 Invalid credentials 3 Timed out after 120 seconds 31 Connection refused 88.11 RedIRIS, iguana 488 2.28 5 Timed out after 60 seconds 54 Connection refused 1 Host is unreachable 86.68 U.S. DMD, alpaca 488 2.74 3 Host is unreachable 12 Timed out after 60 seconds 53 Connection refused 1 Connection timed out 84.02 FUNET, Northern Pudu 488 1.73 76 Invalid credentials 2 Timed out after 60 seconds 29 Connection refused 83.20 Universitaet Wien, Rockhopper Pe... 488 2.93 8 Connection refused 72 Invalid credentials 7 Timed out after 60 seconds 1 Connection timed out 78.89 Victoria University of W..., Kakapo 488 4.06 15 Timed out after 60 seconds 7 Connection refused 9 Host is unreachable 78 Invalid credentials 1 Timed out after 120 seconds 3 Connection timed out 77.46 Unknown Organisation, Dragon 488 14.82 8 Host is unreachable 69 Timed out after 60 seconds 12 Unavailable 3 Connection refused 37 Invalid credentials 2 Connection timed out 1 Timed out after 120 seconds 76.28 Trinity College Dublin, Irish Elk 489 2.96 8 Host is unreachable 99 Invalid credentials 9 Timed out after 60 seconds 1 Connection timed out 8 Connection refused 75.00 Vrije Universiteit Brussel, Woolly Spider... 488 6.12 3 Connection refused 38 Timed out after 60 seconds 59 Invalid credentials 1 Connection timed out 2 Timed out after 120 seconds 73.36 Matej Bel University, UA..., Tarpon 488 4.73 126 Invalid credentials 3 Timed out after 60 seconds 69.47 WIDE project, Sloth 488 5.79 21 Timed out after 60 seconds 4 Host is unreachable 125 Invalid credentials 2 Connection timed out 5 Connection refused 66.39 SWITCH, Chinchilla 488 1.14 187 Invalid credentials 3 Timed out after 60 seconds 1 Connection timed out 2 Host is unreachable 66.39 Inmarsat, Hedgehog 488 1.29 13 Timed out after 60 seconds 151 Invalid credentials 2 Connection timed out 64.55 GARR-NIS, Black Widow 488 2.90 41 Timed out after 60 seconds 2 Connection refused 152 Invalid credentials 4 Timed out after 120 seconds 64.43 Unknown Organisation, Dorcan Gazelle 492 11.43 136 Timed out after 60 seconds 6 Connection refused 2 Unavailable 27 Connection timed out 1 Timed out after 120 seconds 63.11 GARR-NIS, Black Widow 488 4.78 52 Timed out after 60 seconds 2 Connection refused 145 Invalid credentials 9 Timed out after 120 seconds 55.33 North Atlantic Treaty Or..., Violaceous Trogon 488 2.69 1 Unavailable 181 Timed out after 60 seconds 36 Connection timed out 53.78 RCCN Portugal, Zebu 489 16.48 138 Timed out after 60 seconds 9 Host is unreachable 9 Connection timed out 32.32 University of Zagreb - F..., Roufous Motmot 492 21.49 329 Connection refused 25 Timed out after 60 seconds 1 Unavailable 2 Connection timed out 13.21 IIT Delhi, IN, Pelican 492 36.32 193 Timed out after 60 seconds 143 Host is unreachable 3 Connection refused 9 Connection timed out 0.00 Universidade Federal do ..., paca 488 0.00 486 Connection refused 17 Timed out after 60 seconds 7 Connection timed out 1 Host is unreachable 0.00 Prague University of Eco..., woolly opossum 488 0.00 369 Timed out after 60 seconds 78 Connection timed out 2 Unavailable   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01704; 15 Jul 95 8:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01700; 15 Jul 95 8:19 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa04011; 15 Jul 95 8:19 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Sat, 15 Jul 1995 13:02:54 +0100 Received: from soochak.ncst.ernet.in by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 15 Jul 1995 13:02:40 +0100 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by soochak.ncst.ernet.in (8.6.8.1/8.6.6) with SMTP id RAA00465 for ; Sat, 15 Jul 1995 17:32:04 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA09550; Sat, 15 Jul 95 17:36:49+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA04929; Sat, 15 Jul 95 17:36:57+0530 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gopi K Garge Message-Id: <9507151206.AA04929@ece.iisc.ernet.in> Subject: de for Linux To: osi-ds@cs.ucl.ac.uk Date: Sat, 15 Jul 95 17:36:56 GMT+5:30 Phone: 91 80 334 0855 Request-Delivery-Notification: TRUE X-Mailer: ELM [version 2.3 PL11] Greetings, Would anyone know if "de" been ported onto Linux, yet ? May I have some information about the URLs of the ported versions sources/binaries ? Thanks in advance --Gopi Garge ERNET Project INDIA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07083; 17 Jul 95 14:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07078; 17 Jul 95 14:28 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12588; 17 Jul 95 14:28 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 1995 17:01:17 +0100 Received: from pat.uio.no by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jul 1995 17:01:02 +0100 Received: from ulrik.uio.no by pat.uio.no with local-SMTP (PP) id <11081-0@pat.uio.no>; Mon, 17 Jul 1995 18:00:47 +0200 Received: by durin.uio.no ; Mon, 17 Jul 1995 18:00:45 +0200 Date: Mon, 17 Jul 1995 18:00:45 +0200 Message-Id: <199507171600.SAA03849@durin.uio.no> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hallvard B Furuseth To: eileen@bcvms.bc.edu CC: isode@nic.ddn.mil, quipu@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk In-reply-to: <01HSZ3RGNMAU8X0SDU@bcvms.bc.edu> Subject: Re: Dish add > Reference to another DSA ('Alpaca') for 'Boston College'... > *** Update error - Already exists *** > > Any ideas what I might be doing wrong? Apparently you gave dish commands equivalent to Dish-> moveto "@c=US@st=Massachusetts@o=Boston College" Dish-> add That would try to add `Boston College', which certainly already exists. You must say Dish-> add "cn=Eileen Shepard" ..or whoever you wanted to add. (If that is not the problem, you must specify which commands you gave and which dsa you are using, otherwise we can only guess what's wrong.) Regards, Hallvard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07317; 17 Jul 95 14:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07313; 17 Jul 95 14:48 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13032; 17 Jul 95 14:48 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Jul 1995 16:19:22 +0100 Received: from bcvax1.bc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 17 Jul 1995 16:19:09 +0100 Received: from bcvms.bc.edu by bcvms.bc.edu (PMDF V4.3-9 #10960) id <01HSZ3RGNCNO8X0SDU@bcvms.bc.edu>; Mon, 17 Jul 1995 11:19:19 -0400 (EDT) Date: Mon, 17 Jul 1995 11:19:19 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: EILEEN@bcvms.bc.edu Subject: Dish add To: isode@nic.ddn.mil, quipu@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk Reply-to: eileen@bcvms.bc.edu Message-id: <01HSZ3RGNMAU8X0SDU@bcvms.bc.edu> X-VMS-To: IN%"isode@nic.ddn.mil",IN%"quipu@cs.ucl.ac.uk", IN%"osi-ds@cs.ucl.ac.uk" X-VMS-Cc: EILEEN MIME-version: 1.0 Content-transfer-encoding: 7BIT I am trying (unsuccessfully) to add a person entry to my DIT using the DISH add command. When I do so, I get the following error: Reference to another DSA ('Alpaca') for 'Boston College'... *** Update error - Already exists *** Any ideas what I might be doing wrong? Thanks in advance. Eileen Shepard Boston College   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15842; 18 Jul 95 17:55 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15838; 18 Jul 95 17:55 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa18882; 18 Jul 95 17:55 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Jul 1995 21:18:00 +0100 Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 18 Jul 1995 21:17:11 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 18 Jul 1995 16:14:55 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 18 Jul 1995 16:14:47 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 18 Jul 1995 16:14:00 -0400 Date: Tue, 18 Jul 1995 16:14:00 -0400 X400-Originator: /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.786:18.06.95.20.14.47] X400-Content-Type: P2-1984 (2) Content-Identifier: DirSync for E... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "peter (p.w.) whittaker" X-Orig-Sender: "peter (p.w.) whittaker" Message-ID: <"26791 Tue Jul 18 16:14:51 1995"@bnr.ca> To: ietf-asid@umich.edu, osi-ds@cs.ucl.ac.uk, dir.sync-l@listmail.ema.org Subject: DirSync for EMail question: what attributes to use for addresses? Various vendors are using X.500 as the "canonical" Directory in their email directory synchronization products. Various organizations are also doing this as part of internal, non-commercial, email dirsync exercises. These various dirsync tools, commercial and homegrown, take email addresses from the directories associated with various email products, and write them into the Directory. One approach would be to first translate product-specific addresses (i.e. a cc:mail address) and translate it to an SMTP or X.400 address which can be used from other email products. Questions: do any of the various schemes currently in use store the original, product-specific, address in the Directory, and, if so, what attribute types are people using to store non-RFC822 and non-X.400 addresses in the Directory? The reason for the question is this: a user has an application which obtains non-email-related information about other users from the Directory; the user is free to enter any search criteria which they believe will identify other users, including their known email addresses (for example, this could be a mail-enabled application which modifies documents based on the delivery preferences of the recipients; certain users may prefer PostScript for dumping straight to the printer rather than RTF). So, the application needs to be able to search the directory based on email address, and retrieve arbitrary information about the user identified. For the benefit of the application developer and mail users, whatever attribute(s) are used to store email addresses should be (relatively) standard, either by virtue of publication in X.500, in an RFC, or in industry consortia publications. This is in preference to using developer-defined attributes. RFC 1274 defines several attribute types for storing email addresses, notably rfc822Mailbox, textEncodedORAddress, janetMailbox, and otherMailbox. The "otherMailbox" attribute is a useful catch-all, but it has one problem: as a constructed attribute, there is no straightforward way to search for entries with such attributes (otherMailbox is a sequence of two strings; the Directory does not specify how to construct filters using constructed attributes such as sequences). pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] X.500 DS Specialist pww@entrust.com [ ] Nortel Secure Networks Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 765 3520 [__________________________] Ottawa, Canada, K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15856; 18 Jul 95 17:55 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15852; 18 Jul 95 17:55 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa18918; 18 Jul 95 17:55 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Jul 1995 22:09:25 +0100 Received: from jarrah.itd.adelaide.edu.au by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 18 Jul 1995 22:08:54 +0100 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU+NF/UA-5.28) id AA28621; Wed, 19 Jul 1995 06:37:07 +0930 Message-Id: <9507182107.AA28621@jarrah.itd.adelaide.edu.au> To: prodir-support@nexor.co.uk Cc: panamas@nameflow.dante.net, osi-ds@cs.ucl.ac.uk Subject: Re: Root level prodir combined results In-Reply-To: Your message of "Fri, 14 Jul 1995 08:21:07 +0100." <4119.805706467@nexor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Jul 1995 06:37:06 +0930 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Prior Is there some (unknown) criteria for a DSA to be listed? Bush Dog used to appear in the list but for the last few months it has gone AWOL from the list even though it is very much alive! Mark.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12669; 19 Jul 95 14:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12665; 19 Jul 95 14:11 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14660; 19 Jul 95 14:07 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 19 Jul 1995 17:25:31 +0100 Date: Wed, 19 Jul 1995 17:25:31 +0100 X400-Originator: osi-ds-request@cs.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;haig.cs.uc.005:19.06.95.16.25.31] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Wed, 19 Jul 1995 17:25:31 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alan Shepherd, NEXOR Ltd, GB" Message-ID: <"1426080966-00546-00001 950719162448Z*/I=a/S=shepherd/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> To: Mark Prior Cc: osi-ds , panamas In-Reply-To: <9507182107.AA28621@jarrah.itd.adelaide.edu.au> References: <4119.805706467@nexor.co.uk> Subject: Re: Root level prodir combined results Discarded-X400-IPMS-Extensions: iso (1) memberBody (2) gb (826) (0) (1004) (10) (1) (1) > Is there some (unknown) criteria for a DSA to be listed? Bush Dog used > to appear in the list but for the last few months it has gone AWOL > from the list even though it is very much alive! > > Mark. > Hallvard is right. Only DSAs which are listed as root DSAs now appear in the probe results. This is because I changed the probe in an attempt to prevent bit-rot setting in too greatly, but unfortunately, lack of funded resource prevents me from keeping the probing system up to date. This means that for the time being at least, probe results will continue to only contain master DSAs. This may change in the future if I find time to bring the system up to date. Alan ------------------------------------------------------------ Alan Shepherd, NEXOR, P.O. Box 132, Nottingham NG7 2UU. Phone: +44 (0) 115 952 0582 (Fax:952 0519) Email: a.shepherd@nexor.co.uk. X.400: C=GB;ADMD=CWMAIL;PRMD=NEXOR;O=NEXOR;S=Shepherd;G=Alan X.500: C=GB@o=NEXOR Ltd@cn=Alan Shepherd   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16559; 19 Jul 95 20:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16555; 19 Jul 95 20:25 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa21293; 19 Jul 95 20:25 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jul 1995 20:42:53 +0100 Received: from jarrah.itd.adelaide.edu.au by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 19 Jul 1995 20:42:40 +0100 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU+NF/UA-5.28) id AA20586; Thu, 20 Jul 1995 05:10:11 +0930 Message-Id: <9507191940.AA20586@jarrah.itd.adelaide.edu.au> To: "Alan Shepherd, NEXOR Ltd, GB" Cc: osi-ds , panamas Subject: Re: Root level prodir combined results In-Reply-To: Your message of "Wed, 19 Jul 1995 17:24:59 +0100." <"1426080966-00546-00001 950719162448Z*/I=a/S=shepherd/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jul 1995 05:10:10 +0930 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Prior > Is there some (unknown) criteria for a DSA to be listed? Bush Dog used > to appear in the list but for the last few months it has gone AWOL > from the list even though it is very much alive! > Hallvard is right. Only DSAs which are listed as root DSAs now appear in the probe results. This is because I changed the probe in an attempt to prevent bit-rot setting in too greatly, but unfortunately, lack of funded resource prevents me from keeping the probing system up to date. This means that for the time being at least, probe results will continue to only contain master DSAs. This may change in the future if I find time to bring the system up to date. Well I think this is now even more useless than before because it now doesn't give anyone any feel for the availability of the first level country/organisational entries. To know that Anaconda is not alive only tells you that you cannot modify entries directly under Australia but gives no indication that access to the information is still possible. I think that if the information is still being collected, and the slaves are still being probed, then it should be presented. If this is not viable then turn off the actual probing and conclude the "experiment". If people think this is worthwhile and you don't have time/resources then maybe someone else would volunteer to do it (assuming that the software is available to them or we return to the old probing code). Mark.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07815; 20 Jul 95 6:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07811; 20 Jul 95 6:21 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa06656; 20 Jul 95 6:21 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 1995 09:44:21 +0100 Received: from edelweb.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 1995 09:44:10 +0100 Received: from [39.11.22.233] (mac233.ietf33.nordu.net [39.11.22.233]) by edelweb.fr (8.6.10/8.6.9) with SMTP id KAA07220; Thu, 20 Jul 1995 10:43:32 +0200 X-Sender: pays@edelweb.fr Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jul 1995 10:45:12 +0200 To: osi-ds@cl.ucl.ac.uk Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul-Andre Pays Subject: Re: Root level prodir combined results Cc: "Alan Shepherd, NEXOR Ltd, GB" , osi-ds , panamas At 5:10 20/07/95, Mark Prior wrote: > >Well I think this is now even more useless than before because it now >doesn't give anyone any feel for the availability of the first level You are so right, but it seems that for years now, it has been impossible to stop this totaly useless publishing... I gave up long time ago... -- PAP _________________________________________________________________________ PAP: paul-andre.pays@gctech.edelWeb.fr tel +33 1 34 52 00 88 http://www.edelweb.fr/ fax +33 1 34 52 25 26 GC Tech "The Globe Online Technology Company" _________________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07827; 20 Jul 95 6:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07823; 20 Jul 95 6:22 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa06671; 20 Jul 95 6:22 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jul 1995 11:03:16 +0100 Received: from survis.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 20 Jul 1995 11:03:01 +0100 Received: from survis.surfnet.nl by survis.surfnet.nl with SMTP (PP); Thu, 20 Jul 1995 12:02:08 +0200 To: Mark Prior Cc: "Alan Shepherd, NEXOR Ltd, GB" , osi-ds , panamas Subject: Re: Root level prodir combined results In-reply-to: Your message of Thu, 20 Jul 1995 05:10:10 +0930. <9507191940.AA20586@jarrah.itd.adelaide.edu.au> Organisation: SURFnet bv Address: Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 305305 Telefax: +31 30 305329 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1342.806234507.1@SURFnet.nl> Date: Thu, 20 Jul 1995 12:01:47 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ton Verschuren Message-ID: <9507200622.aa06671@CNRI.Reston.VA.US> ==> From: Mark Prior > Well I think this is now even more useless than before because it now > doesn't give anyone any feel for the availability of the first level > country/organisational entries. To know that Anaconda is not alive > only tells you that you cannot modify entries directly under > Australia but gives no indication that access to the information is > still possible. In Holland we therefore probe all organisational DSA's... Ton.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07010; 21 Jul 95 5:15 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07006; 21 Jul 95 5:15 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05553; 21 Jul 95 5:15 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 21 Jul 1995 08:48:27 +0100 Date: Fri, 21 Jul 1995 08:48:27 +0100 X400-Originator: osi-ds-request@cs.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;haig.cs.uc.411:21.06.95.07.48.27] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 21 Jul 1995 08:48:27 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alan Shepherd, NEXOR Ltd, GB" Message-ID: <"1426080966-16622-00001 950721074747Z*/I=a/S=shepherd/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> Cc: osi-ds , panamas In-Reply-To: <27368.806311471@nexor.co.uk> Subject: Re: Root level prodir combined results Discarded-X400-IPMS-Extensions: iso (1) memberBody (2) gb (826) (0) (1004) (10) (1) (1) Due to popular demand, this service is being withdrawn :-) Alan ------------------------------------------------------------ Alan Shepherd, NEXOR, P.O. Box 132, Nottingham NG7 2UU. Phone: +44 (0) 115 952 0582 (Fax:952 0519) Email: a.shepherd@nexor.co.uk. X.400: C=GB;ADMD=CWMAIL;PRMD=NEXOR;O=NEXOR;S=Shepherd;G=Alan X.500: C=GB@o=NEXOR Ltd@cn=Alan Shepherd   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08140; 21 Jul 95 9:06 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08136; 21 Jul 95 9:06 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa09077; 21 Jul 95 9:06 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Jul 1995 11:10:17 +0100 Received: from jarrah.itd.adelaide.edu.au by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 21 Jul 1995 11:09:55 +0100 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU+NF/UA-5.28) id AA26645; Fri, 21 Jul 1995 19:36:54 +0930 Message-Id: <9507211006.AA26645@jarrah.itd.adelaide.edu.au> To: osi-ds , panamas , ietf-ids@umich.edu Subject: Re: Root level prodir combined results In-Reply-To: Your message of "Fri, 21 Jul 1995 08:48:27 +0100." <"1426080966-16622-00001 950721074747Z*/I=a/S=shepherd/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jul 1995 19:36:54 +0930 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Prior Due to popular demand, this service is being withdrawn :-) Well what can I say! :-) Since I think that probing is useful as long as probes provide useful information on availability of the data (not the DSAs) I suggest that if people are interested we develop a specification for such a service and then see if someone is willing to code something up to support it. I will be out of contact for the next week as I make my way home from the IETF but I would be willing to discuss this on my return. One requirement I would like to place on the service is that the data is probed from a number of locations across the global so it is less biased to the European view. I suggest that we add this as a work item to the IETF IDS working group. Mark.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08744; 21 Jul 95 10:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08740; 21 Jul 95 10:25 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10512; 21 Jul 95 10:24 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 21 Jul 1995 08:33:27 +0100 Date: Fri, 21 Jul 1995 08:33:27 +0100 X400-Originator: osi-ds-request@cs.ucl.ac.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;haig.cs.uc.331:21.06.95.07.33.27] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 21 Jul 1995 08:33:27 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <27368.806311471@nexor.co.uk> To: panamas@paradise.ulcc.ac.uk, osi-ds@cs.ucl.ac.uk Subject: Root level prodir combined results Reply-To: prodir-support@nexor.co.uk *** N.B. The probing results below are influenced by network failures *** *See also: the WWW entry, "http://web.nexor.co.uk/users/quipu/x500/graphroot.gif" Probing from NEXOR, ULCC, Cambridge Computer Lab, SWITCH@Zurich, SURFnet@Delft, Community: internet ========== ======== No DSAs had 100.00% availability. Other DSAs: ----- ----- %Avail Organisation,DSA Attempts Average Time ------ ---------------- -------- ------------ 99.72 UNINETT, Electric Eel 722 1.28 2 Connection refused 99.58 UNI-C, Armadillo 722 0.91 1 Connection refused 2 Timed out after 60 seconds 98.75 SUNET, Andean Cat 722 0.83 5 Connection refused 1 Unavailable 3 Timed out after 60 seconds 97.78 Unknown Organisation, opaxdsa, CNRS, FR 722 3.01 6 Connection refused 7 Timed out after 60 seconds 3 Host is unreachable 1 Unavailable 97.09 RedIRIS, iguana 722 2.39 22 Connection refused 1 Timed out after 60 seconds 97.09 ULCC, Inca Dove 722 0.79 6 Connection refused 6 Unavailable 1 Timed out after 120 seconds 8 Timed out after 60 seconds 96.93 Unknown Organisation, opaxdsa, CNRS, FR 163 3.46 2 Connection refused 3 Timed out after 60 seconds 96.92 Prague University of Eco..., woolly opossum 487 3.90 1 Connection timed out 1 Connection refused 2 Unavailable 8 Timed out after 60 seconds 2 Host is unreachable 1 Invalid credentials 96.68 GARR-NIS, Black Widow 722 1.93 1 Unavailable 2 Connection refused 21 Timed out after 60 seconds 28 Invalid credentials 96.12 UMK, Ocelot 722 5.46 1 Connection timed out 2 Connection refused 1 Timed out after 120 seconds 22 Timed out after 60 seconds 1 Host is unreachable 96.12 ARNES, Proteus 722 1.23 4 Connection refused 2 Host is unreachable 15 Timed out after 60 seconds 1 Unavailable 17 Invalid credentials 94.60 GARR-NIS, Black Widow 722 3.25 1 Timed out after 120 seconds 2 Connection refused 37 Timed out after 60 seconds 27 Invalid credentials 94.32 SURFnet, Hornero 722 0.43 2 Connection refused 39 Timed out after 60 seconds 94.18 Trinity College Dublin, Irish Elk 722 2.55 9 Connection refused 3 Host is unreachable 4 Timed out after 60 seconds 35 Invalid credentials 93.21 Restena, Guppy 722 2.57 1 Connection timed out 2 Connection refused 19 Timed out after 60 seconds 28 Invalid credentials 90.44 SURIS, Elephant Seal 722 3.04 40 Invalid credentials 15 Connection refused 1 Connection timed out 13 Timed out after 60 seconds 1 Host is unreachable 90.17 Technische Universitaet ..., Puma 722 2.74 2 Connection refused 4 Host is unreachable 6 Connection timed out 57 Timed out after 60 seconds 1 Unavailable 2 Invalid credentials 89.21 NSTN Inc, beluga whale 723 6.32 5 Connection timed out 4 Unavailable 2 Timed out after 120 seconds 7 Connection refused 64 Timed out after 60 seconds 88.28 Victoria University of W..., Kakapo 725 3.76 1 Connection timed out 6 Connection refused 1 Timed out after 120 seconds 21 Timed out after 60 seconds 5 Host is unreachable 61 Invalid credentials 87.81 Foundation Of Research a..., Caretta Caretta 722 9.96 3 Timed out after 120 seconds 1 Connection timed out 31 Connection refused 56 Timed out after 60 seconds 8 Host is unreachable 2 Unavailable 16 Invalid credentials 87.15 Unknown Organisation, Dorcan Gazelle 724 10.90 4 Unavailable 2 Timed out after 120 seconds 4 Connection refused 75 Timed out after 60 seconds 2 Host is unreachable 85.60 RCCN Portugal, Zebu 722 9.09 13 Connection refused 104 Timed out after 60 seconds 6 Host is unreachable 3 Unavailable 84.07 Matej Bel University, UA..., Tarpon 722 4.11 4 Connection refused 1 Connection timed out 1 Unavailable 7 Timed out after 60 seconds 102 Invalid credentials 83.96 Unknown Organisation, Dragon 723 14.45 15 Unavailable 2 Timed out after 120 seconds 4 Connection timed out 4 Connection refused 88 Timed out after 60 seconds 7 Host is unreachable 22 Invalid credentials 83.80 WIDE project, Sloth 722 5.55 9 Connection timed out 5 Unavailable 1 Timed out after 120 seconds 7 Connection refused 56 Timed out after 60 seconds 1 Host is unreachable 46 Invalid credentials 83.10 U.S. DMD, alpaca 722 3.57 26 Host is unreachable 8 Connection timed out 1 Unavailable 69 Timed out after 60 seconds 22 Connection refused 81.72 Australian Academic and ..., Anaconda 722 7.26 1 Connection timed out 1 Timed out after 120 seconds 2 Connection refused 37 Timed out after 60 seconds 4 Unavailable 1 Host is unreachable 102 Invalid credentials 80.47 National Computer Board ..., Lion 722 8.89 5 Timed out after 120 seconds 1 Unavailable 24 Host is unreachable 3 Connection timed out 32 Connection refused 80 Timed out after 60 seconds 78.01 FUNET, Northern Pudu 723 1.76 30 Connection refused 3 Timed out after 60 seconds 108 Invalid credentials 77.59 University of Zagreb - F..., Roufous Motmot 723 20.05 1 Unavailable 2 Connection timed out 127 Connection refused 53 Timed out after 60 seconds 77.42 Inmarsat, Hedgehog 722 0.98 6 Timed out after 60 seconds 1 Host is unreachable 158 Invalid credentials 54.82 Universitaet Wien, Rockhopper Pe... 726 3.32 14 Connection refused 28 Connection timed out 15 Timed out after 120 seconds 227 Timed out after 60 seconds 1 Invalid credentials 50.07 Universidade Federal do ..., paca 727 14.93 11 Connection timed out 37 Host is unreachable 178 Connection refused 94 Timed out after 60 seconds 5 Unavailable 5 Invalid credentials 45.01 SWITCH, Chinchilla 722 0.48 1 Connection refused 389 Invalid credentials 36 Timed out after 60 seconds 42.29 North Atlantic Treaty Or..., Violaceous Trogon 726 4.07 18 Timed out after 120 seconds 36 Connection timed out 353 Timed out after 60 seconds 1 Host is unreachable 1 Connection refused 1 Unavailable 41.39 Vrije Universiteit Brussel, Woolly Spider... 488 7.33 202 Connection refused 3 Timed out after 60 seconds 14 Invalid credentials 18.71 IIT Delhi, IN, Pelican 727 30.87 185 Host is unreachable 11 Connection refused 3 Timed out after 120 seconds 5 Unavailable 12 Connection timed out 251 Timed out after 60 seconds 0.00 Prague University of Eco..., woolly opossum 235 0.00 232 Timed out after 60 seconds 1 Host is unreachable 4 Connection refused 2 Unavailable   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22528; 27 Jul 95 22:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22524; 27 Jul 95 22:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:50:04 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:49:23 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16659; Thu, 27 Jul 95 15:48:42 PDT Date: 27 Jul 95 15:44 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:44 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727661 P1-Message-Id: ca*infonet*iss;9507271544101659212 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: Paul Rarey In-Reply-To: Message-Id: <950727661*wong@vancouver.osiware.bc.ca> References: <9504241917.AA24111@bluto.is.ge.com> Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Jim..., On Apr 24, 12:17, Jim Smithson wrote: > Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt >You won't find application/Bilaterally Defined. Didn't think so. I guess my concern was that the authors X400/MIME gateway appeared to be generating the Content-Type: subtype. Was hoping there could be some clarification here, or chage to x-Bilaterally Defined or something. >I'm sure the author just meant this as an example of one of the experimental >types (eg. application/X-phone). >See RFC1341 page 8 for more info. Thanks... am familiar with x- extensions for MIME tags. -- Cheers! [ psr ]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22538; 27 Jul 95 22:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22534; 27 Jul 95 22:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:45:27 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:44:20 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16601; Thu, 27 Jul 95 15:43:39 PDT Date: 27 Jul 95 15:43 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:43 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727654 P1-Message-Id: ca*infonet*iss;9507271543271659205 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: Internet-Drafts@CNRI.Reston.VA.US Message-Id: <950727654*wong@vancouver.osiware.bc.ca> Subject: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=body-part-boundary-1 --body-part-boundary-1 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the OSI Directory Services Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Connection-less Lightweight Directory Access Protocol Author(s) : A. Young Filename : draft-ietf-osids-cldap-02.txt Pages : 8 Date : 04/20/1995 The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP)[3]. In particular, it is aimed at avoiding the elapsed time that is associated with connection-oriented communication and it facilitates use of the Directory in a manner analagous to the DNS [5,6]. It is specifically targeted at simple lookup applications that require to read a small number of attribute values from a single entry. It is intended to be a complement to DAP and LDAP [4]. The protocol specification draws heavily on that of LDAP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-osids-cldap-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-osids-cldap-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-osids-cldap-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --body-part-boundary-1 Content-Type: Multipart/Alternative; Boundary="OtherAccess" --body-part-boundary-1 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-osids-cldap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-osids-cldap-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> --OtherAccess-- --body-part-boundary-1--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22548; 27 Jul 95 22:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22544; 27 Jul 95 22:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:11:28 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:06:12 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16810; Thu, 27 Jul 95 16:05:45 PDT Date: 27 Jul 95 15:46 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:46 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727706 P1-Message-Id: ca*infonet*iss;9507271546391659257 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: quipu , OSI-DS , ldap@umich.edu In-Reply-To: <9505221425.AA25319@alehouse.sware.com> Message-Id: <950727706*wong@vancouver.osiware.bc.ca> Subject: Re: Quipu's treeStructure attribute in oidtables Importance: High >Since the value of the treeStructure attribute is very static, wouldn't >it be nice if we had it in the oidtable.oc? That way, we define it >once and not every time one creates a entry of an object class that >needs a treeStructure attribute. I've been thinking about modifying >quipu to handle this as an exercise, but would like some opinions >before I go ahead. > >Does anybody have any info regarding this? TreeStructure is an out of date component of QUIPU. If you do any modifications at all you should consider implementing the structure rules as offered by X.500(93). These are stored "out of the way" in sub entries of the DIT, but have the advantage of being available to DUAs over DAP if they need to be accessed for some reason. Colin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22558; 27 Jul 95 22:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22554; 27 Jul 95 22:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:11:32 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:10:04 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16820; Thu, 27 Jul 95 16:09:19 PDT Date: 27 Jul 95 15:47 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:47 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727726 P1-Message-Id: ca*infonet*iss;9507271547391659277 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Message-Id: <950727726*wong@vancouver.osiware.bc.ca> Subject: Re: About X.500 PJ in Japan Importance: High OriginalPath: SSW @ SOFT-SWITCH @ LOTUS ExpandPersonalGroups: 0 DisplaySubject: Re: About X.500 PJ in Japan Version: 30 One possible local source of information about X.500, if you are not already aware of it, might be the: Japan Electronic Messaging Association Executive Director: Mr Yuichi Tosaki 11-10, Azabudai 1-chome Minato-ku Tokyo 106 Tel: +81 3 3583 5811 Fax: +81 3 3583 5813 X.400: g=Office; s=JEMA; o=JEMA; a=ATI; c=JP I hope this helps, Stuart McRae _______________________________[Mail message history]_______________________________ Date: Fri, 2 Jun 1995 10:31:59 +0900 Message-Id: <199506020131.KAA18320@heart.swe.ogis-ri.co.jp> To: osi-ds@cs.ucl.ac.uk Cc: kubota@swe.ogis-ri.co.jp Subject: About X.500 PJ in Japan From: kubota@swe.ogis-ri.co.jp (Natsuhiko Kubota) X-Mailer: mnews [version 1.17#4] 1994-01/27(Thu) Hellow.My name is Natsuhiko Kubota. I live in Japan. Now I am stading about X.500. But it is hard for me. Would you kindly help me? I want to knou that what project running in Japan about x.500. I must make x.500 server in my office. Please teach me who is outhority about x.500 in Japan. And I have not understood Why x.500 is useful. I use the DSN that NASA's,and I look NASA's directry. Certainly.I could get the information in NASA's address. It looks like Yellow Page.But I can not understand why this is useful. If you know How can I make x.500 server,would you kindly tell me about it. I have read some RFC.And I sent mail Mr weider. He taugut me your address. I am sorry that I am not goot at English. If you can not understand what I say.Please point out. thank you. Natsuhiko Kubota   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22568; 27 Jul 95 22:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22564; 27 Jul 95 22:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:15:15 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:14:35 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16298; Thu, 27 Jul 95 15:14:10 PDT Date: 27 Jul 95 15:11 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:11 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727332 P1-Message-Id: ca*infonet*iss;9507271511231629003 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Message-Id: <950727332*wong@vancouver.osiware.bc.ca> Subject: Re: info on X.500 Importance: High Greetings, Vincent. >> I try it here once more. > >I have a feeling that this works better. Let me have a shot at it. To be fair. I did receive a reply in comp.protocols.iso, but it was already to late to change this message (saying I didn't receive anything). Well, never mind. It's not that important. >>1: There already seems to exist an X.500 space. I can browse thru it >>using one of the public-domain X.500 dua's. (e.g. pixie, wax, wdua, >>..). > >Yes this is correct. This X.500 name space is set up during the X.500 >Directory Pilot project and nowadays DANTE tries to co-ordinate some of >this as an operational service, at least for parts of Europe. That's why my >reply :-) It's great to see at least _somebody_ still cares about international norms. (I hope X.500 doesn't end up the same way X.400 does). Are there any other directory-service-protocols 'competing' with X.500? (novell? banyan Street-talk, ...)? >>I did notice there are quite a differences between certain parts of >>the X.500 tree. Some countries (like Belgium) have very few >>organisations, each with only 1 or 2 people in it, while others (like >>Denmark) have a lot of them. > >A lot of thinks happened in the past, some country (or better >organisations) have a real emphasis on the development of X.500 (or >directories) and see the importance (like SURFnet, SWITCH, etc.) and others >are not of almost not participating. Is there a reason for that, or just 'bad PR'? >This is more a political problem and >not really technical. *Directories will not succeed without management >back-up* because it is far more than setting up a DSA. Inside belgacom, there is a kind of 'battle' between X.500 and banyan-vines street-talk. (Althou, as we use decdns now, I guess X.500 will eventually 'win'. > The only thing I have to say here is watch out with sizes! Some >countries used so-called bulk load tools to do a bulk load data, especially >some universities. Some of these parts are not maintained at all! Quantity >does not say anything about the quality. The difference between (eg.) Belgium and Denmark does is striking. >... The great goal for the future is >on one hand technical; an infrastructure build on the real standard and on >the other side organisational; having proper agreements in place and >controlling this. question: how does one 'inforce' a international standard? How do you 'punish' somebody that doesn't supply the 'quality of service' requested. (I guess, if you talk of 'organisational agreements', a minimal quality of service will be demanded. Or am I wrong?) >>Is there already a way to 'register' one-self into the X.500 space? > >This is a bigger issue than you think. At this moment there is an ad hoc >approach: as long as no one used the name you can use it. A proper solution >would be a national authority who is responsible for the name space. Mind >that some countries again are far ahead in this field and have proper >authorities controlling the name space! How this is solved within Belgium >you would have to ask Nils (cc-ed). Great! I (personally) will 'order' the (c=be, o=belgacom) part of the DIT. If belgacom wants to use that name, I'll make them pay! ;-) (BTW: that already happened with internet-names under the .com hierarchie) >>- c=be, st=west-vlaanderen, l=oostende > >There is a difference between a residential and an organigram (?) structure. In what way? I understand that (c=be, o=xxx) will usually be served by a DSA in that organisation, but who 'serves' a locality? >>I even found people, right under the 'world'-level. (?) > >There should not be any, can you tell me who? I am typing this offline, so I can't check this right-now, but they appeat to be the X.500 managers of the Countries. >>Now, did the documentation I read oversimpify things, or are that only >>'irregularities' in the X.500 space? > >I think X.500 allows you to do pretty much, however there are some >guidelines specified in RFC 1617 to keep it in control. Another rfc to read. ;-) >>If the non-existance of a hierarchy is a fact, hao does one how about >>the search such a 'database'? > >Clever user agents with good search algorithms like "de". (telnet >nameflow.dante.net, login dua) As far as I can see, 'de' is only based on the (country -> organisation) hierarchie. (country - state - locality seems to be inpossible to search). >...In the >future there could be an alternative to country nodes or even different >DITs as commercial organisations could stand up and provide these directory >services. I don't understand. Do you mean other hierarchies than (country - organisations), more DSA's on top of a 1 country (each 'serving' a number of organisations under the same country-node), or more DITs, completly seperated from eachother? >The most common thing to do is to set up a server for an >organisation and put "cn=myself" under it. A organisation with only one person under it. Isn't that a bit 'overkill'? >>3: How does X.500 handle the fact that an object can/should be at more >>places in the X.500 space? (Can it?) > >Aliasing or naming links. A short p[aper written by David Chadwick was >produced for the last NameFLOW meeting and is available on the web >. sigh. Another text to read. ;-) >>4: How does X.500 handle the fact that object can 'move'? Is there a >>mechanisme to find back an objects (say a person), after they have >>moved to another location in the X.500 tree? (say she/he went to work >>for another company, or moved to another town??) > >Yes, you could use an alias .... >Now, there are no bi-directional pointers and you will need some kind of >"search engine" to check correctness and this is virtually impossible. This >is explained by Paul Barker in X.500 >Index DSAs which could provide a solution to this problem. This reminds me of www, were there also are 'links' from on place in a document to another (part of a) document. There you have the same problem. Say, you have a document 'A' pointing to document 'B'. No problem, as long as 'B' doesn't move. In that case, A must be notified, and the link to 'B' must be modified. I've heard somewhere that 'they' (whoever that may be) are working a method to make www-links bidirectional. (to be expected at least some years from now). >Hope this helps a bit, It sure did! Cheerio! Kr. Bonne. home: kristoff.bonne@ping.be work: kristoff.bonne@is.belgacom.be (c=be, a=rtt, p=rttipc, s=bonne, g=kristoff)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22578; 27 Jul 95 22:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22574; 27 Jul 95 22:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:26:54 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:26:10 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16381; Thu, 27 Jul 95 15:25:35 PDT Date: 27 Jul 95 15:12 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:12 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727355 P1-Message-Id: ca*infonet*iss;9507271512331629026 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: panamas@nameflow.dante.net, osi-ds@cs.ucl.ac.uk In-Reply-To: <4119.805706467@nexor.co.uk> Message-Id: <950727355*wong@vancouver.osiware.bc.ca> Subject: Re: Root level prodir combined results Importance: High Is there some (unknown) criteria for a DSA to be listed? Bush Dog used to appear in the list but for the last few months it has gone AWOL from the list even though it is very much alive! Mark.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22588; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22584; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:35:40 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:34:14 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16409; Thu, 27 Jul 95 15:32:57 PDT Date: 27 Jul 95 15:13 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:13 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727368 P1-Message-Id: ca*infonet*iss;9507271513061629039 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: "Alan Shepherd, NEXOR Ltd, GB" , osi-ds , panamas In-Reply-To: <9507191940.AA20586@jarrah.itd.adelaide.edu.au> Message-Id: <950727368*wong@vancouver.osiware.bc.ca> Subject: Re: Root level prodir combined results Importance: High ==> From: Mark Prior > Well I think this is now even more useless than before because it now > doesn't give anyone any feel for the availability of the first level > country/organisational entries. To know that Anaconda is not alive > only tells you that you cannot modify entries directly under > Australia but gives no indication that access to the information is > still possible. In Holland we therefore probe all organisational DSA's... Ton.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22598; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22594; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:00:29 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:58:48 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16785; Thu, 27 Jul 95 15:58:11 PDT Date: 27 Jul 95 15:45 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:45 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727680 P1-Message-Id: ca*infonet*iss;9507271545301659231 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: /PN=NJM03-SEG-DATA0/DD.NTADDR=NJM03-SEG-DATA0#l#a#r#HWC@lotus.hc-sc.x400.gc.ca Message-Id: <950727680*wong@vancouver.osiware.bc.ca> Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Hhhhmmmm..... On Apr 24, 5:17, /DD.NTADDR=Anne_Philpott#l#a#r#HWC/G=Anne/S=Philpo wrote: > Subject: I-D ACTION:draft-ietf-osids-cldap-02.txt > -> --MIMEboundary950424081838.4734 -> Content-type: application/Bilaterally Defined -> Content-transfer-encoding: base64 -> Content-Description: body2 -> -> Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwxOTk1MDQyMDE2MDUyMy5J -> LURAQ05SSS5SZXN0b24uVkEuVVM+CgpFTkNPRElORyBtaW1lCkZJTEUgL2ludGVybmV0LWRy -> YWZ0cy9kcmFmdC1pZXRmLW9zaWRzLWNsZGFwLTAyLnR4dAo= The above base64 decodes to...: -> Content-Type: text/plain -> Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> -> -> ENCODING mime -> FILE /internet-drafts/draft-ietf-osids-cldap-02.tx I've been unable to find any reference to Content-Type: application/Bilaterally Defined. I'm using...: URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application as a reference to the known MIME types. Is there somewhere else I should be looking? -- Cheers! [ psr ]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22610; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22606; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:48:54 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:48:21 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16654; Thu, 27 Jul 95 15:47:18 PDT Date: 27 Jul 95 15:44 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:44 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727660 P1-Message-Id: ca*infonet*iss;9507271544051659211 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: jrs@jrs.is.ge.com, osi-ds@cs.ucl.ac.uk In-Reply-To: <9504240823.ZM24711@maverick.systems.DHL.com> Message-Id: <950727660*wong@vancouver.osiware.bc.ca> Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High You won't find application/Bilaterally Defined. I'm sure the author just meant this as an example of one of the experimental types (eg. application/X-phone). See RFC1341 page 8 for more info. Jim Smithson, GE DialComm *526-5864, +1 813 287 5864, FAX +1 813 287 5840 General Electric, 1715 N. Westshore Blvd., Suite 800, Tampa, FL 33607 USA GEIS QC: J.SMITHSON Internet: J.SMITHSON@geis.geis.com or jrs@is.ge.com X.400: G=JIM;S=SMITHSON;OU1=GEIS;O=QUIKCOMM;A=MARK400;C=US > I've been unable to find any reference to Content-Type: application/Bilaterally > Defined. I'm using...: > > URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application > > as a reference to the known MIME types. Is there somewhere else I should be > looking? > > > > -- > > > Cheers! > > [ psr ] >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22620; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22616; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:32:09 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:30:50 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16397; Thu, 27 Jul 95 15:30:15 PDT Date: 27 Jul 95 15:12 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:12 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727363 P1-Message-Id: ca*infonet*iss;9507271512531629034 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds , panamas In-Reply-To: <9507182107.AA28621@jarrah.itd.adelaide.edu.au> Message-Id: <950727363*wong@vancouver.osiware.bc.ca> References: <4119.805706467@nexor.co.uk> Subject: Re: Root level prodir combined results Importance: High > Is there some (unknown) criteria for a DSA to be listed? Bush Dog used > to appear in the list but for the last few months it has gone AWOL > from the list even though it is very much alive! > > Mark. > Hallvard is right. Only DSAs which are listed as root DSAs now appear in the probe results. This is because I changed the probe in an attempt to prevent bit-rot setting in too greatly, but unfortunately, lack of funded resource prevents me from keeping the probing system up to date. This means that for the time being at least, probe results will continue to only contain master DSAs. This may change in the future if I find time to bring the system up to date. Alan ------------------------------------------------------------ Alan Shepherd, NEXOR, P.O. Box 132, Nottingham NG7 2UU. Phone: +44 (0) 115 952 0582 (Fax:952 0519) Email: a.shepherd@nexor.co.uk. X.400: C=GB;ADMD=CWMAIL;PRMD=NEXOR;O=NEXOR;S=Shepherd;G=Alan X.500: C=GB@o=NEXOR Ltd@cn=Alan Shepherd   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22630; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22626; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:06:06 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:05:30 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16800; Thu, 27 Jul 95 16:04:35 PDT Date: 27 Jul 95 15:46 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:46 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727702 P1-Message-Id: ca*infonet*iss;9507271546281659253 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: rfc-editor@isi.edu, iab@isi.edu, osi-ds@cs.ucl.ac.uk Reply-To: /PN=Anne.Philpott/DD.NTADDR=Anne_Philpott#l#a#r#HWC@lotus.hc-sc.x400.gc.ca Message-Id: <950727702*wong@vancouver.osiware.bc.ca> Subject: Protocol Action: Connection-less Lightweight Directory Access Protocol to Proposed Standard Importance: High The IESG has approved the Internet-Draft "Connection-less Lightweight Directory Access Protocol" as a Proposed Standard. This work was initiated in the [now defunct] OSI Directory Services Working Group and completed by the Access and Synchronization of the Internet Directories Working Group. The IESG contact person is Harald Tveit Alvestrand. Technical Summary The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP) as specified in X.500. In particular, it is aimed at avoiding the elapsed time that is associated with connection-oriented communication and it facilitates use of the Directory in a manner analagous to the DNS. It is specifically targeted at simple lookup applications that require to read a small number of attribute values from a single entry. It is intended to be a complement to DAP and LDAP (RFC 1487). The protocol specification draws heavily on that of LDAP (RFC 1487) that has proven to be the most widely used and implemented access protocol for X.500 to date. Advice on how to implement a retransmission strategy was added after the previous IESG review. Working Group Summary Most of the debate on CLDAP focused on improvements to LDAP. There was a clear concensus on the connectionless approach. Protocol Quality The specification has been reviewed by a member of the Applications Area Directorate and by one of the Area Directors.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22641; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22637; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:58:49 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:57:57 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16772; Thu, 27 Jul 95 15:57:15 PDT Date: 27 Jul 95 15:45 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:45 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727679 P1-Message-Id: ca*infonet*iss;9507271545261659230 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: /PN=Anne.Philpott/DD.NTADDR=Anne_Philpott#l#a#r#HWC@lotus.hc-sc.x400.gc.ca Message-Id: <950727679*wong@vancouver.osiware.bc.ca> Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Hhhhmmmm..... On Apr 24, 5:17, /DD.NTADDR=Anne_Philpott#l#a#r#HWC/G=Anne/S=Philpo wrote: > Subject: I-D ACTION:draft-ietf-osids-cldap-02.txt > -> --MIMEboundary950424081838.4734 -> Content-type: application/Bilaterally Defined -> Content-transfer-encoding: base64 -> Content-Description: body2 -> -> Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwxOTk1MDQyMDE2MDUyMy5J -> LURAQ05SSS5SZXN0b24uVkEuVVM+CgpFTkNPRElORyBtaW1lCkZJTEUgL2ludGVybmV0LWRy -> YWZ0cy9kcmFmdC1pZXRmLW9zaWRzLWNsZGFwLTAyLnR4dAo= The above base64 decodes to...: -> Content-Type: text/plain -> Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> -> -> ENCODING mime -> FILE /internet-drafts/draft-ietf-osids-cldap-02.tx I've been unable to find any reference to Content-Type: application/Bilaterally Defined. I'm using...: URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application as a reference to the known MIME types. Is there somewhere else I should be looking? -- Cheers! [ psr ]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22651; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22647; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:50:58 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:50:04 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16667; Thu, 27 Jul 95 15:49:41 PDT Date: 27 Jul 95 15:44 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:44 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727662 P1-Message-Id: ca*infonet*iss;9507271544161659213 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk, quipu@cs.ucl.ac.uk Message-Id: <950727662*wong@vancouver.osiware.bc.ca> Subject: Restricted access to root DSA (Giant Tortoise) Importance: High Dear directory managers, Apologies for cross posting, but this is an important message for Directory managers. In order to phase out the Root-of-the-world DSA (the "Giant Tortoise") we announced in a previous message that access would be limited. An undocumented feature of Quipu allows us to further tighten the restrictions. The coming changes may effect a large part of the Directory starting from the 2nd of May 1995. We will be testing restricted access for the DSA "Giant Tortoise" from the 2 May until the 14 May 1995. As from 15 May 1995 access restrictions to the Giant Tortoise will be a fact. The access restrictions will have as minimal influence on the operational service as possible. The rest of this message will respectively explain what will change for directory users and what will change for Directory System Agents (DSAs). What will change for directory _USERS_? In principle directory users are NOT allowed to connect to the Giant Tortoise anymore as they should contact their local DSA. The following users will be allowed to connect to the Giant Tortoise: * the managers of the Giant Tortoise, * probes to determine availability, * and country managers to allow them to alter their country entry. On request other end users may be granted access, if this is necessary. What will change for -COUNTRY_ DSAs? (A country DSA masters the country entry) Only known country DSAs will be allowed to connect via DSP (Directory Systems Protocol) to the Giant Tortoise. * Country DSAs should hold a copy of the root EDB for further distribution to other DSAs within that country. What will change for all _OTHER_ DSAs? (non country DSAs) In principle all other DSAs should connect to their country DSA. To allow an easy transition the following DSAs will be allowed to connect: * All DSAs that currently use the Giant Tortoise as a relay DSA. * All DSAs that currently use the Giant Tortoise for replication. These DSAs will be advised to use their country DSA during the coming period. Every non-country DSA that has the quiputailor "parent" option set to Giant Tortoise is suggested to replace "Giant Tortoise" with the name of their country DSA (or other superior DSA). For instance for @c=GB@cn=Urutu Snake quiputailor was: parent "cn= Giant Tortoise" Internet=128.86.8.55 etc. is: parent "cn= Inca Dove" Internet=128.86.8.65 etc. The non-country DSAs should also replicate the root entry (EDB) from their country DSA (or other superior DSA). If there are any questions, please contact . So remember, testing will start on 2 May 1995 and full access restriction will be effective as from 15 May 1995. Regards, Vinc& _____________________________________________________________________ * * Vincent Berkhout - Application Engineer * * * Lockton House, Clarendon Road * Cambridge CB2 2BH, United Kingdom D A N T E Tel. +44 1223 302992 Fax. +44 1223 303005 _____________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22663; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22659; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:52:14 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:51:07 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16685; Thu, 27 Jul 95 15:50:22 PDT Date: 27 Jul 95 15:44 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:44 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727664 P1-Message-Id: ca*infonet*iss;9507271544221659215 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: /PN=Anne.Philpott/DD.NTADDR=Anne_Philpott#l#a#r#HWC@lotus.hc-sc.x400.gc.ca Message-Id: <950727664*wong@vancouver.osiware.bc.ca> Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Jim..., On Apr 24, 12:17, Jim Smithson wrote: > Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt >You won't find application/Bilaterally Defined. Didn't think so. I guess my concern was that the authors X400/MIME gateway appeared to be generating the Content-Type: subtype. Was hoping there could be some clarification here, or chage to x-Bilaterally Defined or something. >I'm sure the author just meant this as an example of one of the experimental >types (eg. application/X-phone). >See RFC1341 page 8 for more info. Thanks... am familiar with x- extensions for MIME tags. -- Cheers! [ psr ]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22673; 27 Jul 95 22:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22669; 27 Jul 95 22:33 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:33 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:47:02 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:46:05 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16634; Thu, 27 Jul 95 15:45:22 PDT Date: 27 Jul 95 15:43 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:43 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727658 P1-Message-Id: ca*infonet*iss;9507271543491659209 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: Paul Rarey Message-Id: <950727658*wong@vancouver.osiware.bc.ca> References: <"0424121752-I-D ACTION:draft-ietf-osids-cldap-02.txt*> Subject: Re: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Hhhhmmmm..... On Apr 24, 5:17, /DD.NTADDR=Anne_Philpott#l#a#r#HWC/G=Anne/S=Philpo wrote: > Subject: I-D ACTION:draft-ietf-osids-cldap-02.txt > -> --MIMEboundary950424081838.4734 -> Content-type: application/Bilaterally Defined -> Content-transfer-encoding: base64 -> Content-Description: body2 -> -> Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwxOTk1MDQyMDE2MDUyMy5J -> LURAQ05SSS5SZXN0b24uVkEuVVM+CgpFTkNPRElORyBtaW1lCkZJTEUgL2ludGVybmV0LWRy -> YWZ0cy9kcmFmdC1pZXRmLW9zaWRzLWNsZGFwLTAyLnR4dAo= The above base64 decodes to...: -> Content-Type: text/plain -> Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> -> -> ENCODING mime -> FILE /internet-drafts/draft-ietf-osids-cldap-02.tx I've been unable to find any reference to Content-Type: application/Bilaterally Defined. I'm using...: URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application as a reference to the known MIME types. Is there somewhere else I should be looking? -- Cheers! [ psr ]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22683; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22679; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:54:24 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:52:57 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16709; Thu, 27 Jul 95 15:52:07 PDT Date: 27 Jul 95 15:44 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:44 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727667 P1-Message-Id: ca*infonet*iss;9507271544291659218 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk, quipu@cs.ucl.ac.uk Reply-To: /PN=Anne.Philpott/DD.NTADDR=Anne_Philpott#l#a#r#HWC@lotus.hc-sc.x400.gc.ca Message-Id: <950727667*wong@vancouver.osiware.bc.ca> Subject: Restricted access to root DSA (Giant Tortoise) Importance: High Dear directory managers, Apologies for cross posting, but this is an important message for Directory managers. In order to phase out the Root-of-the-world DSA (the "Giant Tortoise") we announced in a previous message that access would be limited. An undocumented feature of Quipu allows us to further tighten the restrictions. The coming changes may effect a large part of the Directory starting from the 2nd of May 1995. We will be testing restricted access for the DSA "Giant Tortoise" from the 2 May until the 14 May 1995. As from 15 May 1995 access restrictions to the Giant Tortoise will be a fact. The access restrictions will have as minimal influence on the operational service as possible. The rest of this message will respectively explain what will change for directory users and what will change for Directory System Agents (DSAs). What will change for directory _USERS_? In principle directory users are NOT allowed to connect to the Giant Tortoise anymore as they should contact their local DSA. The following users will be allowed to connect to the Giant Tortoise: * the managers of the Giant Tortoise, * probes to determine availability, * and country managers to allow them to alter their country entry. On request other end users may be granted access, if this is necessary. What will change for -COUNTRY_ DSAs? (A country DSA masters the country entry) Only known country DSAs will be allowed to connect via DSP (Directory Systems Protocol) to the Giant Tortoise. * Country DSAs should hold a copy of the root EDB for further dist ribution to other DSAs within that country. What will change for all _OTHER_ DSAs? (non country DSAs) In principle all other DSAs should connect to their country DSA. To allow an easy transition the following DSAs will be allowed to connect: * All DSAs that currently use the Giant Tortoise as a relay DSA. * All DSAs that currently use the Giant Tortoise for replication. These DSAs will be advised to use their country DSA during the coming period. Every non-country DSA that has the quiputailor "parent" option set to Giant Tortoise is suggested to replace "Giant Tortoise" with the name of their country DSA (or other superior DSA). For instance for @c=GB@cn=Urutu Snake quiputailor was: parent "cn= Giant Tortoise" Internet=128.86.8.55 etc. is: parent "cn= Inca Dove" Internet=128.86.8.65 etc. The non-country DSAs should also replicate the root entry (EDB) from their country DSA (or other superior DSA). If there are any questions, please contact . So remember, testing will start on 2 May 1995 and full access restriction will be effective as from 15 May 1995. Regards, Vinc& _____________________________________________________________________ * * Vincent Berkhout - Application Engineer * * * Lockton House, Clarendon Road * Cambridge CB2 2BH, United Kingdom D A N T E Tel. +44 1223 302992 Fax. +44 1223 303005 _____________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22693; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22689; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:30:04 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:29:06 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16985; Thu, 27 Jul 95 16:27:43 PDT Date: 27 Jul 95 15:48 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:48 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727753 P1-Message-Id: ca*infonet*iss;95072715484816592104 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: bjjenni@somnet.sandia.gov, osi-ds@cs.ucl.ac.uk In-Reply-To: <950613131558.20201094@hss.hns.com> Message-Id: <950727753*wong@vancouver.osiware.bc.ca> Subject: Re: scenarios for Directory Synchronization Importance: High >Obviously, if a user has more that one e-mail accounts then he/she will >be represented twice in the global directory. No, this is not obvious, and certainly undesirable. In a global context, I want to be able to find a single entry for a user in a directory, and send mail to them. I do not want to be faced with two entries with similar names and have to choose. What criteria could I as a remote user base that judgement on? In simple synchronisation scenarios, having two email accounts does lead to two entries in the DIT. This is because the DIT structure is force by the LAN and post office distribution. In most organisations this leads to a false DIT structure that does not really represent the organisation in the way they want to be seen. With more complex synchronisation management tools it is possible to overlay details of the two accounts into one entry. This means you decide in advance how you want your DIT to look from an organisational perspective. The synchronisation tools can then overlay the LAN details onto the DIT defined, deciding on a per user basis, which one email address to publish, or both. This allows both LAN systems to be represented, but joint users to only be visible once. This is certainly the way I've approached synchronisation in the systems I've been involved in. Decide the DIT structure first, map the data onto it second. This also facilitates easier integration with non-LAN systems such as telephone numbers for personnel databases. Colin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22703; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22699; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:30:38 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:30:04 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16987; Thu, 27 Jul 95 16:29:21 PDT Date: 27 Jul 95 15:48 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:48 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727754 P1-Message-Id: ca*infonet*iss;95072715485116592105 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk In-Reply-To: <950614121501.20203a34@hss.hns.com> Message-Id: <950727754*wong@vancouver.osiware.bc.ca> Subject: Re: Providing a DS: re:scenarios for Directory Synchronization Importance: High >I, also, feel that Email requirements are going to >force corporations to go for X.500 directory service MUCH SOONER than >every thing else. Yes, and corporations are starting to look very closely at X.500. On the 'floor' at the recent EMA and EEMA tradeshows the talk was all about how X.500 has now arrived, particularly after the multi-vendor interworking demonstration at EEMA. Its been a long time coming but... >Further, E-mail directory service is very closely >linked with the mail gateway & Directory synchronisation products >which are build by different vendors. Different vendors for mail >gateway and Directory synchronisation products need to have a "common >vision of Directory schema". Otherwise, organisations will be stuck with >a specific vendor (just like a propietory story of legacy systems). >Hence, before an organisation starts on a directory service as >defined in Scenario-1, somehow, this piece of the puzzle has to fit >with the other corporate requirements for Directory service. One >solution is to standardize a schema for mail gateway & Direc. Synch. >requirements. There are actually two different thing here. Schema is one, and synchronisation is the other. Outside of synchronisation there are reasons to have common schema understandings between organisation, and indeed I think there is OIW work going on looking at such issues. On the synchronisation side, there need to be common agreements as to how to make data available to X.500. Such an agreement is the Directory Sync format defined by the XAPIA based upon the 1993 X.500 DISP protocol. Putting these two together, to synchronise you don't actually need schema agreements, DISP will work fine without. However, once synchronised, for an application to make use of the data you do need common schema definitions. One way to arrive at a common set of schema would be to update RFC 1274 (dated 1991) to merge in the X.500(93) schema and extend it to meet current requirements. Colin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22713; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22709; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:03:27 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:01:35 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16789; Thu, 27 Jul 95 16:01:06 PDT Date: 27 Jul 95 15:46 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:46 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727694 P1-Message-Id: ca*infonet*iss;9507271546041659245 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk In-Reply-To: <9505171427.AA10314@yoko.frec.bull.fr> Message-Id: <950727694*wong@vancouver.osiware.bc.ca> Subject: Re: Looking for an LDAP client Importance: High > From: P.Deveze@frec.bull.fr (pascal Deveze) > To: osi-ds@cs.ucl.ac.uk > We have one running version of an LDAP server on a machine that runs an X500 > product. We are now looking for an LDAP client (shareware release) on PC/Windo > and/or on X/MOTIF to complete our configuration and to propose a nice user > interface. > > Maybe some of you have judicious advice on that subject. I'll be very happy to > get information directly from experts. You might check out this web page: http://www.umich.edu/~rsug/ldap/ It contains a list of clients, among other things. We're still building the list, but it's got some stuff now. -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22723; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22719; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:28:58 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:28:05 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16393; Thu, 27 Jul 95 15:27:35 PDT Date: 27 Jul 95 15:12 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:12 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727362 P1-Message-Id: ca*infonet*iss;9507271512501629033 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds , panamas In-Reply-To: <"1426080966-00546-00001 950719162448Z*> Message-Id: <950727362*wong@vancouver.osiware.bc.ca> Subject: Re: Root level prodir combined results Importance: High > Is there some (unknown) criteria for a DSA to be listed? Bush Dog used > to appear in the list but for the last few months it has gone AWOL > from the list even though it is very much alive! > Hallvard is right. Only DSAs which are listed as root DSAs now appear in the probe results. This is because I changed the probe in an attempt to prevent bit-rot setting in too greatly, but unfortunately, lack of funded resource prevents me from keeping the probing system up to date. This means that for the time being at least, probe results will continue to only contain master DSAs. This may change in the future if I find time to bring the system up to date. Well I think this is now even more useless than before because it now doesn't give anyone any feel for the availability of the first level country/organisational entries. To know that Anaconda is not alive only tells you that you cannot modify entries directly under Australia but gives no indication that access to the information is still possible. I think that if the information is still being collected, and the slaves are still being probed, then it should be presented. If this is not viable then turn off the actual probing and conclude the "experiment". If people think this is worthwhile and you don't have time/resources then maybe someone else would volunteer to do it (assuming that the software is available to them or we return to the old probing code). Mark.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22733; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22729; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:31:43 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:30:52 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16996; Thu, 27 Jul 95 16:30:28 PDT Date: 27 Jul 95 15:48 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:48 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727755 P1-Message-Id: ca*infonet*iss;95072715485416592106 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: bjjenni@somnet.sandia.gov, osi-ds@cs.ucl.ac.uk, PGUPTA@hss.hns.com Message-Id: <950727755*wong@vancouver.osiware.bc.ca> Subject: Re: scenarios for Directory Synchronization Importance: High Hi, >| >Obviously, if a user has more that one e-mail accounts then he/she will >| >be represented twice in the global directory. >| > No, this is not obvious, and certainly undesirable. In a global > context, I want to be able to find a single entry for a user in a > directory, and send mail to them. I do not want to be faced with two > entries with similar names and have to choose. What criteria could I > as a remote user base that judgement on? > > In simple synchronisation scenarios, having two email accounts does > lead to two entries in the DIT. This is because the DIT structure is > force by the LAN and post office distribution. > > In most organisations this leads to a false DIT structure that does > not really represent the organisation in the way they want to be > seen. > > With more complex synchronisation management tools it is possible to > overlay details of the two accounts into one entry. This means you > decide in advance how you want your DIT to look from an organisational > perspective. The synchronisation tools can then overlay the LAN > details onto the DIT defined, deciding on a per user basis, which one > email address to publish, or both. This allows both LAN systems to be > represented, but joint users to only be visible once. > > This is certainly the way I've approached synchronisation in the > systems I've been involved in. Decide the DIT structure first, map the > data onto it second. This also facilitates easier integration with > non-LAN systems such as telephone numbers for personnel databases. Certainly, DIT structure will be decided first and data mapping happens onto it. I feel that we are only discussing on the approach for data mapping. Also, DIT structure will be (rather should be) of /C/O/OU/CN type PLUS some more structures involving Locality. Regarding data mapping, I proposed "Rule Based Mapping" for most of the E-mail users who have, only, one account as a normal case (of course, without notice of users with two e-mail account, two DNs will be generated). For Two email account users, There can be exception handling i.e. "Treating them seperately" on a case to case basis. Such accounts can become part of exception handling by NOT Synchronising them through normal synchronisation mechanism. This will require LESS administration overheads for maintaining Directory. In this scheme, same DN mapping with two mail boxes is done as exception handling. Certainly, in this scheme, a lot of pressure comes on defining "Rules". We need to be very flexible and friendly mechanisms of defining "Rules". This is a major challenge. However, solutions are available. I feel that, in synchronisation mechanisms having same DN mapping for two different mail boxes, administration overheads will be high. In this case, DNs are administered by an administrator for every e-mail user !!!! Also, Is this a normal scenario ???? Thanks and regards, Praveen   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22743; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22739; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:25:41 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:25:01 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16370; Thu, 27 Jul 95 15:24:25 PDT Date: 27 Jul 95 15:12 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:12 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727350 P1-Message-Id: ca*infonet*iss;9507271512231629021 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: isode@nic.ddn.mil, quipu@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk In-Reply-To: <01HSZ3RGNMAU8X0SDU@bcvms.bc.edu> Message-Id: <950727350*wong@vancouver.osiware.bc.ca> Subject: Re: Dish add Importance: High > Reference to another DSA ('Alpaca') for 'Boston College'... > *** Update error - Already exists *** > > Any ideas what I might be doing wrong? Apparently you gave dish commands equivalent to Dish-> moveto "@c=US@st=Massachusetts@o=Boston College" Dish-> add That would try to add `Boston College', which certainly already exists. You must say Dish-> add "cn=Eileen Shepard" ...or whoever you wanted to add. (If that is not the problem, you must specify which commands you gave and which dsa you are using, otherwise we can only guess what's wrong.) Regards, Hallvard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22753; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22749; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:03:29 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:02:42 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16791; Thu, 27 Jul 95 16:01:44 PDT Date: 27 Jul 95 15:46 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:46 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727696 P1-Message-Id: ca*infonet*iss;9507271546081659247 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: panamas@paradise.ulcc.ac.uk, osi-ds@cs.ucl.ac.uk, rosenqui@esltd.com, ajw@mel.dit.csiro.au In-Reply-To: <"brolga.uq:293250:950518215239"@cc.uq.oz.au> Message-Id: <950727696*wong@vancouver.osiware.bc.ca> Subject: Re: XDS based experience....... Importance: High Panos, > i am currently working in a project, which objectives are: > > a) case studies describing a DUA or DUA API written on top > of XDS being ported amongst several XDS implementations > (currently ISODE & HP Open View). I've not seen any work which tested the actual portability of XDS applications. (Or, for that matter, the portability of applications which used the related X.400 and X.700 APIs.) If anyone is aware of any I'd like to know. In practice, I'd expect some problems. First, because there hasn't been any portability testing. The XDS/XOM standards are complicated enough that individual implementors can make subtly different interpretations of the text and hence produce implementations that are not portable. The solution to this is a 'portability bakeoff' where various vendors implementations are tested. A consensus of correct behaviour will quickly develop. The 'test' applications then form valuable resource for testing correct behaviour. This approach has worked well for the Internet, but I haven't heard of it being adopted with XDS. Second, because XDS is not a complete interface to X.500. In particular, it doesn't provide access to the authentication features when binding, nor has it been extended (as far as I know) to support the 1993 standard. Various implementations will have extended XDS in a variety of ad hoc ways to support these aspects. I will have practical experience of porting an XDS application within a couple of months! > b) developing a portable DUA or DUA API (using the XDS ISODE > plattform), that can then been ported in a another > plattform (e.g HP Open View), just by compiling the own > code and the ASN.1 definitios in the new plattform. > > We are looking for the best way to develop something like this > above, without loosing the flexibility, which is provided, for example, > currently by "libdsap.a" and "libdish.a" in the ISODE plattform. > Is there people having experience with APIs written on the top of > XDS ?. > I'd be interested in any experiences poeple had. I am not sure exactly what you want to do. XDS is designed to be portable amongst many different systems and has been widely adopted by vendors. If your goal is portability, you are unlikely to be able to design an API which is more portable than XDS - simply because you would have to convince the vendors to drop XDS and support your API. So your goal cannot be (or shouldn't be) portability. Is your goal to support the Quipu API on top of XDS? That would be a useful goal. The major problems you will have (speaking from experience, see below) is that it is very unlikely that the structure of the XDS operation requests/results will map exactly into the Quipu equivalents. They will *almost* directly map, but the exceptions will drive you insane! (And mean a large number of exceptions to be handled in code.) My experience comes from working on a short project to provide a text based interface to XDS. This constructs an XDS operation request from a textual description of an X.500 operation. It also does the converse for an X.500 result or error, allows the user to extract components of the result by name, and supports cutting and pasting X.500 components. The goal is to make it easier to use X.500, and to allow more readable (and hence maintainable) application code. The method is to produce a toolkit which hides the details of using XDS (for example, memory allocation, the structures used and how they are linked together, and what the structure fields are for and how they are set). andrew waugh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22763; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22759; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:05:01 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:04:22 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16798; Thu, 27 Jul 95 16:03:48 PDT Date: 27 Jul 95 15:46 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:46 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727701 P1-Message-Id: ca*infonet*iss;9507271546251659252 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: RFC Editor , Internet Architecture Board , osi-ds@cs.ucl.ac.uk Message-Id: <950727701*wong@vancouver.osiware.bc.ca> Subject: Protocol Action: Connection-less Lightweight Directory Access Protocol to Proposed Standard Importance: High The IESG has approved the Internet-Draft "Connection-less Lightweight Directory Access Protocol" as a Proposed Standard. This work was initiated in the [now defunct] OSI Directory Services Working Group and completed by the Access and Synchronization of the Internet Directories Working Group. The IESG contact person is Harald Tveit Alvestrand. Technical Summary The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP) as specified in X.500. In particular, it is aimed at avoiding the elapsed time that is associated with connection-oriented communication and it facilitates use of the Directory in a manner analagous to the DNS. It is specifically targeted at simple lookup applications that require to read a small number of attribute values from a single entry. It is intended to be a complement to DAP and LDAP (RFC 1487). The protocol specification draws heavily on that of LDAP (RFC 1487) that has proven to be the most widely used and implemented access protocol for X.500 to date. Advice on how to implement a retransmission strategy was added after the previous IESG review. Working Group Summary Most of the debate on CLDAP focused on improvements to LDAP. There was a clear concensus on the connectionless approach. Protocol Quality The specification has been reviewed by a member of the Applications Area Directorate and by one of the Area Directors.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22773; 27 Jul 95 22:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22769; 27 Jul 95 22:34 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:11:35 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:10:45 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16822; Thu, 27 Jul 95 16:10:23 PDT Date: 27 Jul 95 15:47 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:47 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727732 P1-Message-Id: ca*infonet*iss;9507271547481659283 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Message-Id: <950727732*wong@vancouver.osiware.bc.ca> Subject: re:Directroy Synchronization Two Importance: High >In message "Directroy Synchronization Two", >'jburgh@PrimeNet.com' writes: > 1. The OU Hierarchy Issue involves Organizational Department >(OR) leveling and X.400/X.500 Naming Convention Standard development. >This is a policy related problem. I've got to make sure that the OR's >System Administrators utilize appropriate standards when they develop >Distinguished Names (DN) for the users. As I synchronize the diverse >system directories, I'll probably have to "Re-Do" some of the DNs to >make sure that they comply with X.400/SMTP-based E-Mail address formats. I'm wary of the approach you seem to be suggesting: that an OR address be mapped directly to a DN, so that the resulting DN contains a large number of RDNs. This would result in a very deep and wide DIT, which would be difficult to maintain and difficult to browse. It is generally wiser to keep the DIT relatively flat. When selecting DIT levels to organize or manage user entries, choose those which change less frequently over time, i.e. if your employees change departments frequently but remain in the same metropolitan area, use location as a means of organizing entries. The point of this exercise is to build DNs which will change infrequently; this will be especially important if user DNs are to be incorporated into X.509 certificates, as a DN change requires that a new certificate be issued, with the resulting certificate management problems. Once you've chosen a structure for the tree, simply store the OR address and other email addressing information as attributes in the user's entry; your synchronizing DUAs can search for an entry using any mail address, i.e. search filter "OR address = /c=US/admd=ATT/prmd=ACME/s=smith/g=jones", and request the other email address attributes from each entry matching that filter. This is preferable to a programmatic mapping from OR address to DN, is more flexible, and, in the long term, will be more useful as your various email clients become X.500 clients. Note also that this approach does not require that querying DUAs have special knowledge, i.e. of the mapping from OR to DN: they simply ask for the email addresses of the entry which contains a particular OR address. As a final note, you will probably be required to use some sort of unique identifier to disambiguate DNs. While this may seem a less than satisfactory way of guaranteeting unique DNs, in practice it is the only workable approach. Other solutions involve sorting users by department, location, etc., and rely on these OU or L RDN components to provide uniqueness; there are three problems with this sort of approach: Resulting DITs are constructed arbitrarily and without regard for any structure which may be useful for the organization, or which may be useful to the organization's users (i.e. DIT structure reflects X.500's lack of solution to the problem of name uniqueness). This approach does not help you when two users in the same department have the same name; this happens frequently enough to cause problems. Some organizations solve this by adding arbitrary initials to the second user's name, which leads to two problems: if two long time employees with the same name move into the same department, which one gets the "Z.", and users generally find arbitrary bureaucratic changes to their names insulting. This approach does nothing to solve the problem of DN reuse: if Joe Smith leaves the company, and another Joe Smith is hired into the same department, how does the system differentiate between them. This is especially important if the DN is used in ACLs for various protected resources. (The X.500 unique identifier purports to solve this problem and does not; I won't get into the reasons, but it has to do with a) the unique identifier being optional, and b) there being no way to communicate it in the X.500 protocols, short of reading the user's entry.) That said, incorporate some sort of unique identifier into all DNs, one which will be unique to that person, i.e. will not be reused. At BNR, we use the HRR generated employee number, so that my DN is cn=Peter Whittaker + serialNumber=1660747, l=Ottawa, o=BNR, c=CA This may seem unattractive, but it is workable and problem free (bear in mind that DNs are to human consumable, not user friendly). > 2. The Identity Evolution Issue involves standardization of DN >X.400/SMTP-based E-Mail addresses throughout the ORs. This is a policy >related problem and it requires close coordination with the Human >Relation folks in my organizaiton. Employee turnover will require >"daily" attention. The System Administrators must keep up with the >personnel changes. Employees and Supervisors are involved in this >problem too. Can you provide more information on this issue? I do not understand it from the text above. >3. The User Multiple Identity Cross-Leveling Issue involves making sure >that "Dual Hat" employees, requiring different rights and privileges >based on their particular roles, get those rights and privileges >accordingly. This involves technical and policy related problems. The >System Administrators must make sure that the "Dual Hats" obtain >specific Login Scripts with "unique" characteristics for each role. I sense that this issue is being overcomplicated: a user presents their name (and possibly their cryptographic credentials) to a system, and the system grants them the permissions associated with their name/credentials. The Directory can be used as the storehouse of permissions, i.e. you can define attributes held in each user's entry which define what permissions that user has to a particular system. On the other hand, I may simply misunderstand the problem you are trying to solve. >I've got to make sure that the "Dual Hats" understand and follow >standard procedures, without abusing their access. The DUA might be >able to handle this problem for me. The problem with expecting users to understand issues and follow procedures as you describe above is twofold: some won't, either out of ignorance, pig-headedness, or forgetfulness, and some won't because they know they can compromise the system by ignoring the procedures (deliberate maliciousness). >4. The ADUA Utilization Procedures Issue involves standardizing DN >creation, modification and deletion procedures. This involves technical >and policy related problems too. Everyone must do everything right the >first time. The System Administrators must completely understand ADUA >functionality and employees must understand their E-Mail >responsibilities. I guess I'll be developing standard operating >procedures for "New" and "Terminated" employees. I'll probably make the >supervisors responsible for ensuring that their employees coordinate >with the System Administrators. Once you have decided on a tree structure and a name uniqueness provider, building a DN is relatively straightforward. The only questions that then arise are: where are the unique identifiers generated and stored? are terminated users left in the DIT and marked terminated (and possibly hidden from all but administrative users via careful application of access control information (ACI))? who has permissions to add, modify, and remove, particular attributes, i.e. OR addresses, etc. >5. The CRL/CKL Procedures Issues involves guaranteeing confidentiality >of "sensitive" information. Some of my Users deal with "proprietary" >information. We use asynchronous (public/private) key cryptography. >We're gonna incorporate X.509 Authentication Framework Certificates to >manage our Public Key Ring. The System Administrators must issue >CRL/CKLs whenever employees with access leave the organization or lose >control of their Private Key. Employees and Supervisors are also in >this loop and the distributed directory needs to be updated readily as >employee access changes. Sounds like you need an X.500 based certificate management system. I won't comment further as anything I say might be construed as an advertisement for Entrust :->. (Though you may want to send email to entrust.sales@entrust.com, or call +1 613 765 5607 for more information....) pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] X.500 DS Specialist pww@entrust.com [ ] Nortel Secure Networks Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 765 3520 [__________________________] Ottawa, Canada, K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22786; 27 Jul 95 22:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22782; 27 Jul 95 22:35 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:35 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:40:04 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:39:07 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16429; Thu, 27 Jul 95 15:38:22 PDT Date: 27 Jul 95 15:13 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:13 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727374 P1-Message-Id: ca*infonet*iss;9507271513211629045 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds , panamas In-Reply-To: <27368.806311471@nexor.co.uk> Message-Id: <950727374*wong@vancouver.osiware.bc.ca> Subject: Re: Root level prodir combined results Importance: High Due to popular demand, this service is being withdrawn :-) Alan ------------------------------------------------------------ Alan Shepherd, NEXOR, P.O. Box 132, Nottingham NG7 2UU. Phone: +44 (0) 115 952 0582 (Fax:952 0519) Email: a.shepherd@nexor.co.uk. X.400: C=GB;ADMD=CWMAIL;PRMD=NEXOR;O=NEXOR;S=Shepherd;G=Alan X.500: C=GB@o=NEXOR Ltd@cn=Alan Shepherd   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22796; 27 Jul 95 22:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22792; 27 Jul 95 22:35 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:35 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:15:01 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:13:50 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16860; Thu, 27 Jul 95 16:13:02 PDT Date: 27 Jul 95 15:48 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:48 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727744 P1-Message-Id: ca*infonet*iss;9507271548141659295 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk In-Reply-To: <950612144700.202066a6@hss.hns.com> Message-Id: <950727744*wong@vancouver.osiware.bc.ca> Subject: Re: scenarios for Directory Synchronization Importance: High Paveen, I agree with your evaluation of Scenario-1. Scenario-2 however, I offer caution. We had to make this 'corporate' data, i.e. owned and managed by corporate, due to the descrepencies between LANs. Prior to heterogeneously operative e-mail in out corporation, many users had more than one e-mail address. Defining a 'preferred address' was very time consuming. LAN managers, were of little or no help because they couldn't help us identify the users preference. In some cases the users themselves were unsure of a preferred address because this was so well hidden via menus, auto logins, etc. Eventually is meant contacting those users with one or more account, creating a group to provide support and maintenance of the e-mail addresses, and a work around to allow users more than one e-mail address. Don't under estimate the problems associated with directory sunchronization or unique e-mail addresses. Barbara ============================================================= Barbara Jennings Sandia National Laboratory Scientific Computing Systems - Org. 13918 P.O. Box 5800 - MS 0807 Albuquerque, NM 87185-0807 USA jennings@sandia.gov Voice (505)845-8554 Fax (505)844-3075 ============================================================= > > I have beed reading the discussion on Directory Synchronisation with > lot of interest. Here, I would like to share some of my views. > I feel that we have been mixing up two scenarios (as defined below). > We need to first understand the scenario which we are talking about???? > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > SCENARIO-1 : Use of a corporate Directory service > ---------- > > Here, X.500 directory service is used as part of Global and corporate > directory service. Corporate Directory Service is used for lot of > corporate requirements, such as: > > * Personnel profiling of an employee > * For lookup of Telephone number, Fax Number, E-mail address, > common name, description etc. etc. > * For storing sensitive "secure" information such as > private and public encryption keys etc. > > * To offer white page and yellow page service for employees and > corporate network > * to provide Whois services etc. > > In fact, in this case, Directory is a very important corporate resource > and one needs to build process and procedures to maintain it very carefully. > > In this case, DNs are to be defined at the time of person joining the > organisation. DNs have to be a kind of an identity (like employee number) > of the person. Several mechanism, including directory synchronisation, > are required to be developed to maintain "Corporate directory". Clearly, > this will require a very strong commitment and awareness at the > organisational level. Also, a very simple and easy-to-use browsing > mechanisms will be required to support such a directory. > > > SCENARIO-2 : Using X.500 for e-mail address resolution in Global and > ---------- distributed manner > > This scenario is, clearly, a subset of "scenario-1". However, this > requires low commitment at organisational and corporate level. > > Here, X.500 directory DNs CAN BE generated as a "rule based approach" > from LAN / legacy Email accounts. This can become part of Directory > synchronisation mechanism. In this case, X.500 directory is used > by Email Gateways to resolve LAN / Legacy e-mail addresses to X.400 > or-address OR DN and vice versa. Also, X.500 directory will be used > by X.400 (1988) MTA and (optionally) by UA for Mail routing etc. > > In this case, X.500 directory is can only be used > as white page or yellow page service for the end-user Email accounts. > However, it will not be integrated with address lookup functionality > of LAN / Legacy E-mail systems. > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > I believe that the choice of a scenario will be a strategic decision > for the organisation and NOT ANY TECHNICAL ISSUE. Certainly, a > confidence in X.500 technology (and product chosen) is a critical > factor in making this strtegic decision. > > In fact some discussion can be done in the direction of MERITS of > each of them. > > In my view, Scenario-1 is a long term view of "Directory service" > and Scenario-2 is a short term view of the X.500 Directory. > > Thanks and regards, > > Praveen Gupta > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22811; 27 Jul 95 22:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22804; 27 Jul 95 22:35 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:35 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 00:35:53 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 00:35:16 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA17004; Thu, 27 Jul 95 16:33:45 PDT Date: 27 Jul 95 15:49 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:49 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727759 P1-Message-Id: ca*infonet*iss;95072715490116592110 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: c.robbins@nexor.co.uk, bjjenni@somnet.sandia.gov, osi-ds@cs.ucl.ac.uk In-Reply-To: <950615121237.20206c9a@hss.hns.com> Message-Id: <950727759*wong@vancouver.osiware.bc.ca> Subject: Re: scenarios for Directory Synchronization Importance: High I have just tuned into this thread. Does any one have the complete thread they could forward to me? Thanks Lawrence C. Hutson, Consultant HCI International In message <950615121237.20206c9a@hss.hns.com> you write: >Hi, > >>| >Obviously, if a user has more that one e-mail accounts then he/she will >>| >be represented twice in the global directory. >>| >> No, this is not obvious, and certainly undesirable. In a global >> context, I want to be able to find a single entry for a user in a >> directory, and send mail to them. I do not want to be faced with two >> entries with similar names and have to choose. What criteria could I >> as a remote user base that judgement on? >> >> In simple synchronisation scenarios, having two email accounts does >> lead to two entries in the DIT. This is because the DIT structure is >> force by the LAN and post office distribution. >> >> In most organisations this leads to a false DIT structure that does >> not really represent the organisation in the way they want to be >> seen. >> >> With more complex synchronisation management tools it is possible to >> overlay details of the two accounts into one entry. This means you >> decide in advance how you want your DIT to look from an organisational >> perspective. The synchronisation tools can then overlay the LAN >> details onto the DIT defined, deciding on a per user basis, which one >> email address to publish, or both. This allows both LAN systems to be >> represented, but joint users to only be visible once. >> >> This is certainly the way I've approached synchronisation in the >> systems I've been involved in. Decide the DIT structure first, map the >> data onto it second. This also facilitates easier integration with >> non-LAN systems such as telephone numbers for personnel databases. > >Certainly, DIT structure will be decided first and data mapping happens >onto it. I feel that we are only discussing on the approach for data >mapping. Also, DIT structure will be (rather should be) of /C/O/OU/CN type >PLUS some more structures involving Locality. > >Regarding data mapping, I proposed "Rule Based Mapping" for most of the >E-mail users who have, only, one account as a normal case (of course, >without notice of users with two e-mail account, two DNs will be >generated). For Two email account users, There can be exception >handling i.e. "Treating them seperately" on a case to case basis. >Such accounts can become part of exception handling by NOT >Synchronising them through normal synchronisation mechanism. >This will require LESS administration overheads for maintaining >Directory. In this scheme, same DN mapping with two mail boxes is done as >exception handling. Certainly, in this scheme, a lot of pressure comes on >defining "Rules". We need to be very flexible and friendly mechanisms >of defining "Rules". This is a major challenge. However, solutions are >available. > >I feel that, in synchronisation mechanisms having same DN mapping for >two different mail boxes, administration overheads will be high. In this >case, DNs are administered by an administrator for every e-mail user !!!! >Also, Is this a normal scenario ???? > >Thanks and regards, > >Praveen >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22827; 27 Jul 95 22:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22823; 27 Jul 95 22:35 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:35 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:37:57 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:36:50 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16415; Thu, 27 Jul 95 15:35:17 PDT Date: 27 Jul 95 15:13 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:13 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727369 P1-Message-Id: ca*infonet*iss;9507271513091629040 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: "Alan Shepherd, NEXOR Ltd, GB" , osi-ds , panamas Message-Id: <950727369*wong@vancouver.osiware.bc.ca> Subject: Re: Root level prodir combined results Importance: High At 5:10 20/07/95, Mark Prior wrote: > >Well I think this is now even more useless than before because it now >doesn't give anyone any feel for the availability of the first level You are so right, but it seems that for years now, it has been impossible to stop this totaly useless publishing... I gave up long time ago... -- PAP _________________________________________________________________________ PAP: paul-andre.pays@gctech.edelWeb.fr tel +33 1 34 52 00 88 http://www.edelweb.fr/ fax +33 1 34 52 25 26 GC Tech "The Globe Online Technology Company" _________________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22837; 27 Jul 95 22:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22833; 27 Jul 95 22:35 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:35 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Jul 1995 23:47:37 +0100 Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 27 Jul 1995 23:46:59 +0100 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16646; Thu, 27 Jul 95 15:46:22 PDT Date: 27 Jul 95 15:43 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:43 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727659 P1-Message-Id: ca*infonet*iss;9507271543561659210 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@vancouver.osiware.bc.ca Cc: osi-ds@cs.ucl.ac.uk Reply-To: /PN=Anne.Philpott/DD.NTADDR=Anne_Philpott#l#a#r#HWC@lotus.hc-sc.x400.gc.ca Message-Id: <950727659*wong@vancouver.osiware.bc.ca> Subject: I-D ACTION:draft-ietf-osids-cldap-02.txt Importance: High Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=body-part-boundary-1 --body-part-boundary-1 Content-Description: text --body-part-boundary-1 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the OSI Directory Services Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Connection-less Lightweight Directory Access Protocol Author(s) : A. Young Filename : draft-ietf-osids-cldap-02.txt Pages : 8 Date : 04/20/1995 The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP)[3]. In particular, it is aimed at avoiding the elapsed time that is associated with connection-oriented communication and it facilitates use of the Directory in a manner analagous to the DNS [5,6]. It is specifically targeted at simple lookup applications that require to read a small number of attribute values from a single entry. It is intended to be a complement to DAP and LDAP [4]. The protocol specification draws heavily on that of LDAP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-osids-cldap-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-osids-cldap-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-osids-cldap-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --body-part-boundary-1 Content-type: application/Bilaterally Defined Content-Description: body2 --body-part-boundary-1 Content-Type: text/plain Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-osids-cldap-02.txt --body-part-boundary-1 Content-type: application/Bilaterally Defined Content-Description: body3 --body-part-boundary-1 Content-Type: text/plain Content-ID: <19950420160523.I-D@CNRI.Reston.VA.US> --body-part-boundary-1 Content-Description: body4 --body-part-boundary-1 ATTACHMENT MANIFEST 1.0 =BP TYPE FILENAME RENDER 1 NOTE 2 FILE xgw2.ia5 -1 3 FILE xgw3.ia5 -1 =END --body-part-boundary-1--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14739; 28 Jul 95 13:06 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14735; 28 Jul 95 13:06 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14487; 28 Jul 95 13:06 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 28 Jul 1995 17:19:53 +0100 Received: from somnet.sandia.gov by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 28 Jul 1995 17:19:32 +0100 Received: (from bjjenni@localhost) by somnet.sandia.gov (8.6.10/8.6.10) id KAA24089; Fri, 28 Jul 1995 10:26:42 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Barbara Jennings Message-Id: <199507281626.KAA24089@somnet.sandia.gov> Subject: Re: scenarios for Directory Synchronization To: Alan Wong Date: Fri, 28 Jul 1995 10:26:42 -0600 (MDT) Cc: awon@osison.osiware.bc.ca, osi-ds@cs.ucl.ac.uk, PGUPTA@hss.hns.com In-Reply-To: <950727755*wong@vancouver.osiware.bc.ca> from "Alan Wong" at Jul 27, 95 03:48:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1979 Praveen, > > Regarding data mapping, I proposed "Rule Based Mapping" for most of the > E-mail users who have, only, one account as a normal case (of course, > without notice of users with two e-mail account, two DNs will be > generated). For Two email account users, There can be exception > handling i.e. "Treating them seperately" on a case to case basis. > Such accounts can become part of exception handling by NOT > Synchronising them through normal synchronisation mechanism. > This will require LESS administration overheads for maintaining > Directory. A strong word of caution again Praveen - in my experience, EXCEPTION case handling require more administration and are difficult to hand over to second level support. If you intend to be 'one-deep' for support, or the only one providing the support you stand a better chance of accurate administration of the exceptions - however; even you may forget the exceptions from time to time. We do offer users two mail accounts, one for internal and one for external. This required alteration in the directory synchronization process; the internal address was sent to the mail systems focused on internal communication, and the external address is provided via RFC822 addressing in X.500. Presenting two accounts to the world is confusing. Additonally, a user may think that they prefer two accounts, until they forget to check one and find that they have missed a very important meeting. I recommend users to stay with one account. In a 'perfect' world, each organization would have only one source for e-mail provision anyway. [SOAP BOX! PERSONAL OPINION!] Barbara ============================================================= Barbara Jennings Sandia National Laboratory Scientific Computing Systems - Org. 13918 P.O. Box 5800 - MS 0807 Albuquerque, NM 87185-0807 USA jennings@sandia.gov Voice (505)845-8554 Fax (505)844-3075 =============================================================