Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15541; 4 Aug 94 21:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15537; 4 Aug 94 21:18 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa19801; 4 Aug 94 21:18 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 01:31:52 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 01:31:41 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id UAA19840; Thu, 4 Aug 1994 20:31:32 -0400 Message-Id: <199408050031.UAA19840@terminator.rs.itd.umich.edu> To: osi-ds@cs.ucl.ac.uk Subject: Schema WG document - last call MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 04 Aug 1994 20:31:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Here is the final last call on the schema working group document. This time we really mean it ;-), meaning that if there are no comments, we will submit this to the ASID ADs as an Internet draft. The deadline on comments is next Wednesday. -- Tim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Schema document IETF X.500 Schema Working Group Tim Howes INTERNET-DRAFT University of Michigan Ken Rossen SHL Systemhouse Srinivas Sataluri AT&T Bell Laboratories Russ Wright Lawrence Berkeley Laboratory June 1994 Procedures for Formalizing, Evolving, and Maintaining the Internet X.500 Directory Schema Filename: draft-ietf-x500-schema-00.txt 1. Status of this Memo The goal of the X.500 schema working group is to specify a set of pro- cedures for reviewing, publicizing, and maintaining schema elements for use in Internet applications using OSI Directory Services (X.500). This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other docu- ments at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Direc- tories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. This Internet Draft expires December 25th, 1994. Distribution of this memo is unlimited. Comments and critiques of this document, and new or updated schema definitions should be sent to x500- schema@internic.net. Discussion about the Internet X.500 schema should be carried out on the OSI-DS mailing list (osi-ds@cs.ucl.ac.uk). 2. Abstract The IETF Schema Working Group proposes a set of procedures for IETF X.500 Schema Working Group [Page 1] INTERNET-DRAFT June 1994 reviewing, publicizing, and maintaining schema elements for use in Internet applications using OSI Directory Services (X.500). 3. Goals of the Internet Schema Procedures The goals embodied in the procedures documented in this memo are four- fold: - To identify a repository and appropriate useful formats for publi- cizing and distributing schema elements (object classes and attri- butes) to the Internet community. - To facilitate broad-based experimentation with new applications of X.500 by publicizing experimental schema elements. - To maintain a stable production schema for the Internet, including definitions both for common core of elements and application- specific subschemas - To avoid the overlap of schema element functionality where possi- ble. 4. Collection of Schema Elements The Internet Directory Schema will evolve from the status quo as represented in a forthcoming [Internet Draft | RFC] documenting the current "baseline" schema elements. This baseline is expected to include both those object classes and attributes with applicability to a wide variety of applications (the Core Schema), and certain elements arising from specific applications (subschemas), some of which have been developed in other IETF WGs. In general, within the IETF, the X.500 schema group will concern itself with evolving the Core schema while encouraging application-specific subschemas to be developed by experts in the respective applications. The schema group aims to align schema element definitions where appropriate between the Internet schema and others within the Directory community. The publicizing of the Internet schema for external consump- tion is one avenue for this, and consideration of schema elements docu- mented in external sources is another. Two such external sources are: - Standing documents of the North American Directory Forum - "F" series International Standard Profiles (ISPs) for use of the Directory, developed by the Regional Workshops (AOW, EWOS, OIW) and published in ISO/IEC 10616. IETF X.500 Schema Working Group [Page 2] INTERNET-DRAFT June 1994 5. Publication of Schema Elements The schema group recognizes short-term and long-term mechanisms for dis- tributing definitions of Internet schema elements. Both mechanisms involve the use of the InterNIC Directory and Database Services as a repository: Short-term: Element definitions will be made available for anonymous FTP from the InterNIC in ftp://ds.internic.net/pub/src/x500/schema, and via Gopher (gopher://ds.internic.net/1pub/src/x500/schema). The FTP archive will include ASN.1 definitions accompanied by text describ- ing the semantics and use of each object class or attribute. In addition, native formats for widely deployed X.500 implementations, particularly the QUIPU OID Table format, will be included where practical. Long-term: When 1993 schema publication extensions to the Directory standard are implemented widely in the Internet, these facilities will be used to distribute element definitions from the InterNIC DSA. If slow progress of deployment of schema publication extensions impedes this transition, consideration will be given to defining a 1988-compatible directory schema for interim publication of schema elements. In this case, a migration path to the 1993 format for schema publication operational attributes will be a priority. In addition to on-line publicizing of schema elements, an informational RFC documenting the Internet schema will be issued on a six-month update cycle. This RFC will reflect the state of the InterNIC schema reposi- tory at the time of publication. Subschemas defined by other IETF WGs or external groups in the Directory community but accepted by the schema group as stable will not be repro- duced in the regularly updated schema RFC. Rather, the schema RFC will contain pointers to documents produced by these other groups which include the definitions. Wherever possible, external groups will be encouraged to submit docu- ments containing their subschemas for publication as RFCs, in order to allow interested parties to derive the Internet schema entirely from a reading of the X.500 standard and selected RFCs. 6. Procedures for Expanding the Internet Schema The schema group will make available a template for submission of schema elements for publication and consideration. The template, to be defined in a later edition of this document, will request a definition for the IETF X.500 Schema Working Group [Page 3] INTERNET-DRAFT June 1994 syntax of the object class or attribute, sufficient details on the schema elements including information about the submitter, date of sub- mission, mailing-list where discussion is being held, status of the schema segment, etc. The template will be simple and will be processed to produce an ASN.1 definition for the elements. The completed template will be submitted by e-mail to the alias "x500- schema@internic.net". Advancement of an experimental schema element to production status will follow a period of experimentation and acceptance by the submitting WG, and acceptance by the schema group. In particular, authors who submit new schema elements (initially assigned experimental classification) will be expected to make a good faith effort to progress the schema using appropriate working-groups and other standards procedures towards an Internet standard. Results from the period of experimentation, schema group and WG consensus will be the basis for decisions on advancement of candidate subschemas. If it becomes apparent that there is no active experimentation with an experimental status schema element and/or no efforts to progress them as Internet standards, the schema elements may be retired after appropriate notification. In some circumstances, more than one subschema aimed at addressing the requirements of the same application may be developed. The schema group will accept and publicize such overlapping subschemas as experimental. However, only one competing schema proposal for an application will be advanced by the schema group to production status. As with decisions on advancement to production status, results from the period of experimen- tation, schema group and WG consensus will be the basis for identifying the preferred among competing subschemas. 7. Object Identifiers The schema group does not aim to align all Internet schema elements under a single OID arc. It is appropriate for other groups already hav- ing registered attributes and object classes under their own respective OID arcs to retain ownership of those definitions, and advancement of schema elements from experimental to production status does not imply a change of OID. The schema group will advance the registration process under an Internet arc for elements defined by external groups not wish- ing to maintain OIDs in the long term. 8. Security Considerations Security considerations are not discussed in this memo. IETF X.500 Schema Working Group [Page 4] INTERNET-DRAFT June 1994 9. Authors' Addresses Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943, USA (313) 747-4454 tim@umich.edu Ken Rossen SHL Systemhouse 10 Williamsville Road Hubbardston Center, MA 01452-1311 USA +1 508 928 5368 (voice) 5399 (fax) 5116 (alt fax) kenr@shl.com Srinivas R. Sataluri AT&T Bell Laboratories Room 1C-429, 101 Crawfords Corner Road P.O. Box 3030 Holmdel, NJ 07733-3030, USA (908) 949-7782 sri@qsun.att.com Russ Wright Lawrence Berkeley Laboratory 1 Cyclotron Road Mail Stop 50B-2258 Berkeley, CA 94720, USA (510) 486-6965 wright@lbl.gov This Internet Draft expires December 25th, 1994. IETF X.500 Schema Working Group [Page 5] ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00735; 5 Aug 94 5:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00731; 5 Aug 94 5:01 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01792; 5 Aug 94 5:01 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 5 Aug 1994 09:06:46 +0100 Date: Fri, 5 Aug 1994 09:06:46 +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.126:05.07.94.08.06.46] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 5 Aug 1994 09:06:46 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <13562.776071260@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/osi/x500/graphroot.gif" Probing from SWITCH@Zurich, NEXOR, Cambridge Computer Lab, ULCC, Community: internet ========== ======== No DSAs had 100.00% availability. Other DSAs: ----- ----- %Avail Organisation,DSA Attempts ------ ---------------- -------- 99.34 SWITCH, Condor 457 3 Timed out after 60 seconds 99.34 Prague University of Economics, Woolly Opossum 457 3 Timed out after 60 seconds 99.12 GARR-NIS, Black Widow 457 4 Timed out after 60 seconds 99.12 Unknown Organisation, Corncrake 457 4 Timed out after 60 seconds 99.12 Root of the World, Giant Tortoise 457 1 Unavailable 2 Timed out after 60 seconds 1 Connection refused 99.12 Computer and Automation Institute, Guinea Pig 457 1 Host is unreachable 3 Timed out after 60 seconds 99.12 Restena, Guppy 457 4 Timed out after 60 seconds 99.12 DFN, Margay 457 4 Timed out after 60 seconds 99.07 Vrije Universiteit Brussel, Woolly Spider Monkey 216 1 Timed out after 60 seconds 1 Connection refused 98.69 Unknown Organisation, Dorcan Gazelle 457 5 Timed out after 60 seconds 1 Unavailable 98.69 GB Master DSA, inca dove 457 4 Timed out after 60 seconds 1 Host is unreachable 1 Connection refused 98.47 Unknown Organisation, Andean Cat 457 3 Host is unreachable 4 Timed out after 60 seconds 98.47 GARR-NIS, Black Widow 457 7 Timed out after 60 seconds 98.47 SUNET, Hummingbird 457 3 Host is unreachable 4 Timed out after 60 seconds 98.47 Trinity College Dublin, Irish Elk 457 3 Connection refused 4 Timed out after 60 seconds 98.47 ARNES, Proteus 457 3 Host is unreachable 1 Unavailable 2 Timed out after 60 seconds 1 Connection refused 98.47 Matej Bel University, UAKOM UMB Banska Bystrica, Tarpon 457 7 Timed out after 60 seconds 98.03 FUNET, Northern Pudu 457 8 Timed out after 60 seconds 1 Host is unreachable 98.03 Technische Universitaet Chemnitz-Zwickau, Puma 457 9 Timed out after 60 seconds 98.03 WIDE project, Sloth 457 8 Timed out after 60 seconds 1 Network is unreachable 97.81 UNINETT, Boa Constrictor 457 8 Timed out after 60 seconds 2 Host is unreachable 97.81 Brussels University, Red Titi Monkey 457 6 Timed out after 60 seconds 1 Host is unreachable 2 Connection refused 1 Unavailable 97.37 UNINETT, Electric Eel 457 4 Connection refused 1 Host is unreachable 7 Timed out after 60 seconds 97.16 SWITCH, Chinchilla 458 2 Connection refused 11 Timed out after 60 seconds 97.16 Universidad Politecnica de Madrid, Cayman 457 4 Connection refused 7 Timed out after 60 seconds 2 Host is unreachable 96.72 Victoria University of Wellington, Kakapo 457 11 Timed out after 60 seconds 4 Host is unreachable 96.50 DKUUG, Axolotl 457 6 Timed out after 60 seconds 10 Connection refused 96.28 U.S. DMD, Pied Tamarin 457 11 Timed out after 60 seconds 4 Connection refused 2 Host is unreachable 96.06 Moscow State University, Bear 457 17 Timed out after 60 seconds 1 Host is unreachable 95.84 NEXOR Ltd, Vampire Bat 457 17 Host is unreachable 2 Timed out after 60 seconds 95.40 Unknown Organisation, opaxdsa, CNRS, FR 457 8 Connection refused 13 Timed out after 60 seconds 95.19 RedIRIS, iguana 457 11 Host is unreachable 11 Timed out after 60 seconds 94.31 Australian Academic and Research Network (AARNet), Bush Dog 457 21 Timed out after 60 seconds 2 Connection refused 2 Unavailable 1 Network is unreachable 91.90 FUNET, Jaguar 457 29 Connection refused 8 Timed out after 60 seconds 91.47 DENet, Armadillo 457 23 Timed out after 60 seconds 16 Connection refused 90.67 Technische Universiteit Delft, Hornero 461 34 Timed out after 60 seconds 8 Connection refused 90.59 NSTN Inc, beluga whale 457 31 Timed out after 60 seconds 12 Connection refused 87.75 Universitaet Wien, Rockhopper Penguin 457 55 Timed out after 60 seconds 1 Host is unreachable 86.46 SURIS, Elephant Seal 458 55 Invalid credentials 1 Host is unreachable 6 Timed out after 60 seconds 83.37 Foundation Of Research and Technology Hellas, Caretta Caretta 457 71 Timed out after 60 seconds 3 Unavailable 2 Connection refused 76.81 UMK, Ocelot 457 35 Host is unreachable 25 Connection refused 46 Timed out after 60 seconds 71.12 North Atlantic Treaty Organization, Violaceous Trogon 457 8 Timed out after 60 seconds 120 Connection refused 4 Host is unreachable 70.46 U.S. DMD, Fruit Bat 457 116 Connection refused 19 Timed out after 60 seconds 63.77 Inmarsat, Hedgehog 461 142 Connection refused 7 Host is unreachable 15 Timed out after 60 seconds 55.14 ULCC, Ocellated Turkey 457 204 Connection refused 1 Timed out after 60 seconds 45.20 RCCN Portugal, Zebu 458 245 Timed out after 60 seconds 1 Connection refused 42.83 Australian Academic and Research Network, Anaconda 460 247 Connection refused 11 Timed out after 60 seconds 3 Unavailable 2 Network is unreachable 41.27 U.S. DMD, Alpaca 458 236 Connection refused 21 Unavailable 12 Timed out after 60 seconds 35.15 RCCN Portugal, Zebu 458 193 Host is unreachable 88 Timed out after 60 seconds 28.20 IIT Delhi, IN, Pelican 461 186 Host is unreachable 7 Invalid credentials 32 Timed out after 60 seconds 0.00 Master DSA of KOREA, Darter 457 441 Connection refused 15 Timed out after 60 seconds 1 Network is unreachable 0.00 Universidade Federal do Rio Grande do Sul (UFRGS), paca 457 359 Connection refused 59 Host is unreachable 38 Timed out after 60 seconds 0.00 Bell-Northern Research, Pangolin 457 450 Connection refused 1 Host is unreachable 6 Timed out after 60 seconds 0.00 University of Zagreb - Faculty of Electrical Engineering, Roufous Motmot 457 456 Timed out after 60 seconds 1 Host is unreachable 0.00 Tallinn Technical University, saki 457 444 Timed out after 60 seconds 13 Host is unreachable 0.00 Nanyang Technological University, Silk Spider 457 440 Connection refused 17 Timed out after 60 seconds   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02294; 5 Aug 94 9:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02290; 5 Aug 94 9:07 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05590; 5 Aug 94 9:07 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 12:39:24 +0100 Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 12:39:16 +0100 To: osi-ds@cs.ucl.ac.uk, directory-group@jnt.ac.uk, punters@paradise.ulcc.ac.uk, quipu@cs.ucl.ac.uk Subject: Bug-fix version of PARADISE X.500 bulk-loading tools (BLT) Date: Fri, 05 Aug 94 12:39:12 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Barker Message-ID: <9408050907.aa05590@CNRI.Reston.VA.US> Greetings, Two months ago, we released an upgraded version of BLT, the PARADISE project's bulk loading tools. A number of small problems have since come to light and the code has been given a general hosing down. No additional features have been added - it is purely a bug-fix release. It is available from: ftp://cs.ucl.ac.uk/dirpilot/blt-2.1.tar.Z We have also set up a mail list for bug reporting. I have appended the substance of the announcement for release 2.0 in case any of you missed it then. Paul --------------------- BLT 2.0 ANNOUNCEMENT -------------------------- The new release of the PARADISE bulk-loading tools (BLT) is now available. They are developed as C programs and use the Quipu DAP API. The tools may be used freely by anyone - see the README file for more precise terms on availability. The tools are available from: (SEE ABOVE) These tools provide a range of bulk data loading and data management features. They allow an X.500 directory database to be managed from multiple sources, where each source masters a selected set of attributes for specified sub-trees. A mechanism is provided for merging datasets even when "entries" are named differently in the various data sources. They allow a range of policies to be used which require more/less intervention for initial/subsequent updates. They do some X.500 data integrity checking. The major changes between this version and the last version; A cookbook has been written (by John Colville) which gives an easier way of getting started with the BLT. The matching algorithm which detects correspondence between entries in different sources has been improved by being liberalised. Object class violation information from a Quipu DSA log file can be incorporated into the error buffer. Some integrity checking on DN syntax attributes. Lots and lots of bug fixes. If praise is due, please do not waste it on me, but offer it to Kevin McCarthy (and John Colville on secondment at Brunel) who have contributed the new goodies in this release. Comments to: (SEE ABOVE)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05282; 5 Aug 94 11:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05278; 5 Aug 94 11:48 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa09678; 5 Aug 94 11:48 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 16:27:47 +0100 Received: from glengoyne.isode.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 16:27:41 +0100 Received: from koko.isode.com by glengoyne.isode.com with SMTP (PP); Fri, 5 Aug 1994 16:27:28 +0100 To: Tim Howes cc: osi-ds@cs.ucl.ac.uk, ietf-asid@umich.edu Subject: Re: LDAP ModRdn problem Phone: +44 81 332 9091 In-reply-to: Your message of Fri, 05 Aug 1994 10:49:27 -0400. <199408051449.KAA27777@terminator.rs.itd.umich.edu> Date: Fri, 05 Aug 1994 16:25:50 +0100 Message-ID: <2695.776100350@isode.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Young > 1) Leave it the way it is. This, of course, has the problems > described above, which can be somewhat mitigated by adding another > of the required attributes to the entry before doing the modrdn. > But what happens in the case of a single-valued attribute? In > this case, you cannot add another value before changing the rdn, > without violating the entry's schema. > > 2) Change the choice to always keep the old rdn attributes as > normal entry attributes after the modrdn. This solves the problem > in 1), but creates a new problem involving single-valued attributes. > If the new rdn and old rdn both contain values of some single-valued > attribute, the entry's schema is violated by having both the old > and the new values in the entry after the modrdn. > > 3) Change the modrdn operation to include another bit, specifying > whether the old values should be kept or deleted. This appears to > solve the problem (in the same way it's solved in DAP). It's more > complex, though not all that much. I guess the problem with 3 is that it changes the protocol. I do not understand the implications of this for LDAP. My preference would certainly be for 3, even if the issue of changing the protocol is non-trivial as I suspect that LDAP DUAs with ModifyRDN capability are not yet widespread. Alan.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05293; 5 Aug 94 11:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05289; 5 Aug 94 11:48 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa09709; 5 Aug 94 11:48 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 15:49:45 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 15:49:38 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id KAA27777; Fri, 5 Aug 1994 10:49:27 -0400 Message-Id: <199408051449.KAA27777@terminator.rs.itd.umich.edu> To: osi-ds@cs.ucl.ac.uk cc: ietf-asid@umich.edu Subject: LDAP ModRdn problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Aug 1994 10:49:27 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes Hi guys. A while ago on the net, Martijn Koster raised an issue with the ldap modify rdn operation. The problem is that ldap states that old rdn attribute values are always deleted from the entry when the rdn is changed. This causes problems if the old rdn happens to contain a required attribute of the entry, and the new rdn does not contain that same attribute. At the Toronto ASID meeting, this problem was discussed, three potential solutions were proposed, and I promised to present them to the osi-ds (and asid) lists for discussion. Hopefully, we will be able to reach consensus on one of the three, implement it, and get out a new version the ldap protocol document if necessary. Here are the three possibilities: 1) Leave it the way it is. This, of course, has the problems described above, which can be somewhat mitigated by adding another of the required attributes to the entry before doing the modrdn. But what happens in the case of a single-valued attribute? In this case, you cannot add another value before changing the rdn, without violating the entry's schema. 2) Change the choice to always keep the old rdn attributes as normal entry attributes after the modrdn. This solves the problem in 1), but creates a new problem involving single-valued attributes. If the new rdn and old rdn both contain values of some single-valued attribute, the entry's schema is violated by having both the old and the new values in the entry after the modrdn. 3) Change the modrdn operation to include another bit, specifying whether the old values should be kept or deleted. This appears to solve the problem (in the same way it's solved in DAP). It's more complex, though not all that much. Given that both 1) and 2) lead to problems in some cases, it seems to me that the best solution is 3). The alternative is to choose 1) or 2) and just note the pathological cases in which they don't work. What do people think? -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07175; 5 Aug 94 13:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07171; 5 Aug 94 13:51 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12430; 5 Aug 94 13:51 EDT Received: from ns.Novell.COM by haig.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 17:53:16 +0100 Received: from sjf-dhub.sjf.novell.com by ns.Novell.COM (4.1/SMI-4.1) id AA00140; Fri, 5 Aug 94 10:50:57 MDT X-Nvlenv-01Date-Transferred: 05-Aug-1994 10:44:59 -0400; at Prv-Mail-Eng3.Novell X-Nvlenv-01Date-Transferred: 5-Aug-1994 8:55:55 -0400; at sjf-domain-hub.Novell X-Nvlenv-01Date-Posted: 05-Aug-1994 10:44:26 -0400; at Prv-Mail-Eng.Novell To: tim (Tim Howes) <@sjf-dhub.sjf.novell.com:tim@terminator.rs.itd.umich.edu> Message-Id: <1525253E01940070@-SMF-> Subject: Re: Schema WG document - last c Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Reed, Ed" Date: 05 Aug 94 10:47:18 EDT In-Reply-To: <1225253E01940070@-SMF-> References: <1225253E02940070@-SMF-> Cc: osi-ds <@sjf-dhub.sjf.novell.com:osi-ds@cs.ucl.ac.uk> Tim, et al - Are there plans for the Internic to include versions of the established schema (White Pages pilot, X.520, X.521, etc) in the same format as the one with which new schema are to be submitted? Will the template accomodate such constraint information as containment rules? Thanks - Ed Reed Novell Directory Services Architect   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07186; 5 Aug 94 13:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07182; 5 Aug 94 13:51 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12446; 5 Aug 94 13:51 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 18:37:12 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 18:37:03 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id NAA03043; Fri, 5 Aug 1994 13:36:47 -0400 Message-Id: <199408051736.NAA03043@terminator.rs.itd.umich.edu> To: Martijn Koster cc: osi-ds@cs.ucl.ac.uk, ietf-asid@umich.edu Subject: Re: LDAP ModRdn problem In-reply-to: Your message of "Fri, 05 Aug 1994 17:03:03 BST." <199408051603.MAA00400@terminator.rs.itd.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Aug 1994 13:36:46 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes > From: Martijn Koster > To: Tim Howes > > The alternative is to choose 1) or 2) and just note the pathological > > cases in which they don't work. > > If we have to choose I'd say 2 is far less likely to occur than 1, and > therefore a better choice. Depending on timescales for 3 it may be > worth using it as a short-term fix. I don't think it's that big of a deal (famous last words!) to implement solution 3). Speaking for our implementation, I'm sure we can do it so that the server will understand both versions for a while. It might even be the case that old servers will work with the new clients, though the servers would ignore the choice. I'd have to look into that to know for sure. How about this for the new ASN.1: ModifyRDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN } Does anybody think that doing this will be a problem, or that either solution 1) or 2) is a better way to go? Just checking... -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07196; 5 Aug 94 13:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07192; 5 Aug 94 13:51 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12462; 5 Aug 94 13:51 EDT Received: from x400gate.bnr.ca by haig.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 17:13:15 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 5 Aug 1994 12:10:07 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 5 Aug 1994 12:09:58 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 5 Aug 1994 12:09:00 -0400 Date: Fri, 5 Aug 1994 12:09: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/;bcars735.b.537:05.07.94.16.09.58] X400-Content-Type: P2-1984 (2) Content-Identifier: re:LDAP ModRd... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "peter (p.w.) whittaker" X-Orig-Sender: "peter (p.w.) whittaker" Message-ID: <"24538 Fri Aug 5 12:10:01 1994"@bnr.ca> To: tim@terminator.rs.itd.umich.edu Cc: osi-ds@cs.ucl.ac.uk, ietf-asid@umich.edu Subject: re:LDAP ModRdn problem In message "LDAP ModRdn problem", 'tim@terminator.rs.itd.umich.edu' writes: >3) Change the modrdn operation to include another bit, specifying >whether the old values should be kept or deleted. This appears to >solve the problem (in the same way it's solved in DAP). It's more >complex, though not all that much. > >Given that both 1) and 2) lead to problems in some cases, it >seems to me that the best solution is 3). The alternative is to >choose 1) or 2) and just note the pathological cases in which >they don't work. Solving the problem in as clean and compliant a way as possible is IMHO always desirable. In this case, this means option 3: do it the way DAP does it, and avoid the problems presented by other alternatives. Maintainting lists of pathological cases is always a recipe for disaster. How many more exceptions do we allow? Who manages the list? Who ensures that it is up to date, available, etc? How we make management of pathological cases foolproof? Etc. A "bad idea" (tm). IMHO, this is also the only reasonable way to proceed from a service/product point-of-view: while it is true that we are complicating the lives of developers by giving them another option to manage, we are saving administrators and users the burden of managing said lists. Better that the developer go through hoops than the user. pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] NT Secure Networks pww@bnr.ca [ ] P.O. Box 3511, Station C Ph: +1 613 765 2064 [ ] Ottawa FAX:+1 613 765 3520 [__________________________] K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07207; 5 Aug 94 13:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07203; 5 Aug 94 13:51 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12473; 5 Aug 94 13:51 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 5 Aug 1994 17:11:41 +0100 Date: Fri, 5 Aug 1994 17:11:41 +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.076:05.07.94.16.11.41] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 5 Aug 1994 17:11:40 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Martijn Koster Message-ID: <"21681 Fri Aug 5 17:03:16 1994"@nexor.co.uk> To: Tim Howes Cc: osi-ds@cs.ucl.ac.uk, ietf-asid@umich.edu In-Reply-To: <199408051449.KAA27777@terminator.rs.itd.umich.edu> Subject: Re: LDAP ModRdn problem > At the Toronto ASID meeting, this problem was discussed Thanks for adressing it... > 1) Leave it the way it is... > 2) Change the choice to always keep the old rdn attributes as > normal entry attributes after the modrdn. > 3) Change the modrdn operation to include another bit... > This appears to solve the problem (in the same way it's solved in > DAP). Well, it off-loads the problem on the LDAP user -- I wonder how many DUAs will code to cope with these problems. > Given that both 1) and 2) lead to problems in some cases, it > seems to me that the best solution is 3). Agreed. > The alternative is to choose 1) or 2) and just note the pathological > cases in which they don't work. If we have to choose I'd say 2 is far less likely to occur than 1, and therefore a better choice. Depending on timescales for 3 it may be worth using it as a short-term fix. -- Martijn __________ Internet: m.koster@nexor.co.uk X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster WWW: http://web.nexor.co.uk/mak/mak.html   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08438; 5 Aug 94 15:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08434; 5 Aug 94 15:20 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14243; 5 Aug 94 15:20 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 18:37:53 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 18:37:45 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id NAA03095; Fri, 5 Aug 1994 13:37:34 -0400 Message-Id: <199408051737.NAA03095@terminator.rs.itd.umich.edu> To: Alan Young cc: osi-ds@cs.ucl.ac.uk, ietf-asid@umich.edu Subject: Re: LDAP ModRdn problem In-reply-to: Your message of "Fri, 05 Aug 1994 16:25:50 BST." <2695.776100350@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Aug 1994 13:37:34 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes > From: Alan Young > To: Tim Howes > I guess the problem with 3 is that it changes the protocol. I do not > understand the implications of this for LDAP. My preference would > certainly be for 3, even if the issue of changing the protocol is > non-trivial as I suspect that LDAP DUAs with ModifyRDN capability are > not yet widespread. I agree. And as I said in response to Martijn's message, I don't think the changes are difficult. -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11336; 5 Aug 94 17:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11332; 5 Aug 94 17:16 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa17087; 5 Aug 94 17:16 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 21:40:09 +0100 Received: from net.lbl.gov by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 21:39:49 +0100 Received: from 131.243.64.68 by net.lbl.gov (8.6.8.1/1.43r) id NAA28388; Fri, 5 Aug 1994 13:16:06 -0700 X-Sender: wright@net.lbl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Aug 1994 13:16:11 -0800 To: "Reed, Ed" Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Russ Wright Subject: Re: Schema WG document - last call Cc: osi-ds@cs.ucl.ac.uk >Will the template accomodate such constraint information as containment >rules? [Content Rules were added to the '93 standard. They basically say what may or may not appear in an entry (this is a constraint beyond the actual object class).] Are we going to include it in our first try at the schema stuff that will be put on the Internic- No. Down the road (i.e. when people start yelling loudly enough or volunteer to do the work ;-) ) for some of the '93 stuff we'll probably have to add it. Right now it is '88 stuff. Russ   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12465; 5 Aug 94 18:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12461; 5 Aug 94 18:49 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa19139; 5 Aug 94 18:49 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 5 Aug 1994 22:37:54 +0100 Date: Fri, 5 Aug 1994 22:37:54 +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.597:05.07.94.21.37.54] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 5 Aug 1994 22:37:53 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Colin Robbins Message-ID: <"24106 Fri Aug 5 22:12:35 1994"@nexor.co.uk> To: Tim Howes Cc: osi-ds@cs.ucl.ac.uk, ietf-asid@umich.edu In-Reply-To: <199408051449.KAA27777@terminator.rs.itd.umich.edu> Subject: Re: LDAP ModRdn problem I am the end of a long slow bit of wire, so can't say as msuch as I would like at the moment. I'll try to elaborate in a few weeks time. However, I do just want to say, that before jumping in and modifying modifyRDN in LDAP, we should llok at the full set of consequences. For example, soomner or later LDAP is going to have to migrate to use X.500(93). This has "upgraded" the operation to modify DN. IF we are going to make changes, it would seem appropriate to to make sure the hooks for this new operation are in place. Sorry to be so brief, but I hope the gist of my point gets accross. Colin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12477; 5 Aug 94 18:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12473; 5 Aug 94 18:50 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa19144; 5 Aug 94 18:50 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 5 Aug 1994 22:34:21 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 5 Aug 1994 22:34:09 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id RAA12928; Fri, 5 Aug 1994 17:33:36 -0400 Message-Id: <199408052133.RAA12928@terminator.rs.itd.umich.edu> To: Colin Robbins cc: osi-ds@cs.ucl.ac.uk Subject: In-reply-to: Your message of "Fri, 05 Aug 1994 22:12:25 BST." <199408052112.RAA14036@totalrecall.rs.itd.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Aug 1994 17:33:35 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes > From: Colin Robbins > To: Tim Howes > I am the end of a long slow bit of wire, so can't say as > msuch as I would like at the moment. I'll try to elaborate in a few > weeks time. However, I do just > want to say, that before jumping > in and modifying modifyRDN in LDAP, we should llok at the full > set of consequences. For example, soomner or > later LDAP is going to have to migrate to use > X.500(93). This has "upgraded" the operation to modify DN. > IF we are going to make changes, it would seem appropriate to > to make sure the hooks for this new operation are in place. > > Sorry to be so brief, but I hope the gist of my point gets accross. Colin, your point comes through loud and clear. At the ASID meeting in Toronto there was some discussion of whether we should use this opportunity to make the necessary changes to LDAP to support the 93 DAP. At that meeting I promised to start a discussion on osi-ds about this topic. I wanted to try and keep it separate from the modrdn topic, but if that's not possible, we can discuss both at once. In any case, the questions to be answered are: 1) What changes would be needed to LDAP to support the 93 DAP extentions? 2) Should we make these changes to LDAP now? Should we try to get an 88 version done before we do this? Should we make these changes at all? Any thoughts? -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06271; 7 Aug 94 20:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06267; 7 Aug 94 20:26 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13942; 7 Aug 94 20:26 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Aug 1994 00:13:40 +0100 Via: uk.ac.salford.io; Mon, 8 Aug 1994 00:13:30 +0100 Received: from mailgate-0.salford.ac.uk by io.salford.ac.uk with SMTP (PP); Mon, 8 Aug 1994 00:15:06 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: D.W.Chadwick@iti.salford.ac.uk Date: 8 Aug 94 12:11 To: osi-ds@cs.ucl.ac.uk Subject: Re: LDAP ModRdn problem X-Mailer: University of Salford cc:Mail/SMTP gateway 1.71 Encoding: 55 TEXT Message-ID: <9408072026.aa13942@CNRI.Reston.VA.US> Message-Id: <199408051449.KAA27777@terminator.rs.itd.umich.edu> To: osi-ds@cs.ucl.ac.uk cc: ietf-asid@umich.edu Subject: LDAP ModRdn problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Aug 1994 10:49:27 -0400 From: Tim Howes Sender: osi-ds-request@cs.ucl.ac.uk Hi guys. A while ago on the net, Martijn Koster raised an issue with the ldap modify rdn operation. The problem is that ldap states that old rdn attribute values are always deleted from the entry when the rdn is changed. This causes problems if the old rdn happens to contain a required attribute of the entry, and the new rdn does not contain that same attribute. At the Toronto ASID meeting, this problem was discussed, three potential solutions were proposed, and I promised to present them to the osi-ds (and asid) lists for discussion. Hopefully, we will be able to reach consensus on one of the three, implement it, and get out a new version the ldap protocol document if necessary. Here are the three possibilities: 1) Leave it the way it is. This, of course, has the problems described above, which can be somewhat mitigated by adding another of the required attributes to the entry before doing the modrdn. But what happens in the case of a single-valued attribute? In this case, you cannot add another value before changing the rdn, without violating the entry's schema. 2) Change the choice to always keep the old rdn attributes as normal entry attributes after the modrdn. This solves the problem in 1), but creates a new problem involving single-valued attributes. If the new rdn and old rdn both contain values of some single-valued attribute, the entry's schema is violated by having both the old and the new values in the entry after the modrdn. 3) Change the modrdn operation to include another bit, specifying whether the old values should be kept or deleted. This appears to solve the problem (in the same way it's solved in DAP). It's more complex, though not all that much. Given that both 1) and 2) lead to problems in some cases, it seems to me that the best solution is 3). The alternative is to choose 1) or 2) and just note the pathological cases in which they don't work. What do people think? -- Tim No 3 is by far and away the best solution in my opinion. The original design just got it plain old wrong. David   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04817; 8 Aug 94 11:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04813; 8 Aug 94 11:27 EDT Received: from [128.16.6.8] by CNRI.Reston.VA.US id aa05704; 8 Aug 94 11:27 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Aug 1994 16:13:58 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 8 Aug 1994 16:13:46 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id LAA08174; Mon, 8 Aug 1994 11:13:37 -0400 Message-Id: <199408081513.LAA08174@terminator.rs.itd.umich.edu> To: "peter (p.w.) whittaker" cc: osi-ds@cs.ucl.ac.uk Subject: Re: LDAP and X.500(93)/(88). In-reply-to: Your message of "Mon, 08 Aug 1994 09:27:00 EDT." <"21188 Mon Aug 8 10:22:45 1994"@bnr.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 08 Aug 1994 11:13:36 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes > From: "peter (p.w.) whittaker" > To: tim@terminator.rs.itd.umich.edu > What additional work needs to be done to bring the current version of > LDAP to complete 1988 compliance? The current spec is "88 compliant", in the sense that it has all the functionality I think we want, modulo the modrdn bug and some bugs in the syntax document. What I meant was should we try to get it to standard status and then work on the 93 stuff, or should we put in the 93 stuff before pushing for standard status. -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04830; 8 Aug 94 11:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04826; 8 Aug 94 11:27 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05805; 8 Aug 94 11:27 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Aug 1994 15:25:38 +0100 Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 8 Aug 1994 15:25:32 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Aug 1994 10:23:22 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Aug 1994 10:22:38 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Aug 1994 09:27:00 -0400 Date: Mon, 8 Aug 1994 09:27: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/;bcars735.b.184:08.07.94.14.22.38] X400-Content-Type: P2-1984 (2) Content-Identifier: LDAP and X.50... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "peter (p.w.) whittaker" X-Orig-Sender: "peter (p.w.) whittaker" Message-ID: <"21188 Mon Aug 8 10:22:45 1994"@bnr.ca> To: tim@terminator.rs.itd.umich.edu Cc: osi-ds@cs.ucl.ac.uk Subject: LDAP and X.500(93)/(88). In message "", 'tim@terminator.rs.itd.umich.edu' writes: >In any case, the questions to be answered are: > > 1) What changes would be needed to LDAP to support the 93 DAP > extentions? > > 2) Should we make these changes to LDAP now? Should we try > to get an 88 version done before we do this? Should we > make these changes at all? What additional work needs to be done to bring the current version of LDAP to complete 1988 compliance? pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] NT Secure Networks pww@bnr.ca [ ] P.O. Box 3511, Station C Ph: +1 613 765 2064 [ ] Ottawa FAX:+1 613 765 3520 [__________________________] K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07365; 8 Aug 94 14:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07361; 8 Aug 94 14:04 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa26459; 8 Aug 94 14:04 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Aug 1994 16:24:37 +0100 Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 8 Aug 1994 16:24:22 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Aug 1994 11:23:25 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Aug 1994 11:21:46 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Aug 1994 10:14:00 -0400 Date: Mon, 8 Aug 1994 10: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/;bcars735.b.546:08.07.94.15.21.46] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Schema WG... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "peter (p.w.) whittaker" X-Orig-Sender: "peter (p.w.) whittaker" Message-ID: <"568 Mon Aug 8 11:21:55 1994"@bnr.ca> To: wright@lbl.gov Cc: osi-ds@cs.ucl.ac.uk, Ed_Reed@novell.com Subject: Re: Schema WG document - last call In message "Re: Schema WG document - last call", 'wright@LBL.gov' writes: >>Will the template accomodate such constraint information as containment >>rules? > >[Content Rules were added to the '93 standard. They basically say what may >or may not appear in an entry (this is a constraint beyond the actual >object class).] > >Are we going to include it in our first try at the schema stuff that will >be put on the Internic- No. Down the road (i.e. when people start yelling >loudly enough or volunteer to do the work ;-) ) for some of the '93 stuff >we'll probably have to add it. Right now it is '88 stuff. My current work has left me with the impression that as more and more organizations being to investigate X.500, they look initially at the 1993 set of recommendations, then express concern when they find that so much extant work is still stuck in 1988. From an operational point of view, the 1988 recommendations leave out far too much. In order for X.500 to be practical for commercial organizations, standard treatment of ACLs and replication is required: users who want to do more than research and testing require these services, and require than they be provided in a common way. We have been able to carry out experiments on the Internet and on the European networks only because we have been willing to do so much to get around the missing pieces, AND because so many of us are using QUIPU: we have achieved commonality of implementation by uniformity of product selection. In order for the current Internet work on X.500 to be truely meaningful and useful, it must reflect the fact that so many of the organizations now connecting to the Internet are commercial organizations who can less afford the time and resources to manage exceptional services such as non-standard replication and ACLs. As these organizations come on board, they will need the services defined in the 1993 series of recommendations. The rest of us also need these services, and would like to see them sooner rather than later. So, what do we do? We can either a) adopt 1993 replication and ACL models, and stick with 1992 schema models, or b) adopt 1993 X.500 as a whole. Option (a) trades one difficult-to-manage situation for another: instead of managing non-standard replication and ACL schemes within the framework of the 1988 recommendations, we manage back-level schema models within the framework of the 1993 recommendations. Option (b) is definitely cleaner; in the long run, it will also be less work, though the upfront effort may be more intense. This argues in favour of early and aggressive movement toward all aspects of the 1993 series. Including 1993 content rules. One counter argument that may carry some weight is the concern that certain aspects of the 1993 series have not yet been proved workable. Others more familiar with 1993 than me will have to pick up this line of thought (I'm still digesting the new, thicker series of recommendations; give me time....) pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] NT Secure Networks pww@bnr.ca [ ] P.O. Box 3511, Station C Ph: +1 613 765 2064 [ ] Ottawa FAX:+1 613 765 3520 [__________________________] K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10770; 8 Aug 94 16:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10766; 8 Aug 94 16:56 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa00322; 8 Aug 94 16:56 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Aug 1994 21:17:54 +0100 Received: from er2.rutgers.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 8 Aug 1994 21:17:42 +0100 Received: by er2.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00170; Mon, 8 Aug 94 16:17:31 EDT Date: Mon, 8 Aug 94 16:17:31 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Wing L. Mei" To: osi-ds@cs.ucl.ac.uk Subject: request Message-Id: Please add my name to your mailing list. Frederick C. Gimenez@eden.rutgers.edu Thank you in advance for your consideration. I remain, Frederick c Gimenez   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12738; 8 Aug 94 19:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12734; 8 Aug 94 19:16 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03256; 8 Aug 94 19:16 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 8 Aug 1994 23:43:56 +0100 Received: from net.lbl.gov by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 8 Aug 1994 23:43:46 +0100 Received: from 131.243.64.68 by net.lbl.gov (8.6.8.1/1.43r) id PAA09060; Mon, 8 Aug 1994 15:43:33 -0700 X-Sender: wright@net.lbl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Aug 1994 15:43:35 -0800 To: "peter (p.w.) whittaker" , wright@lbl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Russ Wright Subject: '93 X.500 (was Re: Schema WG document - last call) Cc: osi-ds@cs.ucl.ac.uk, Ed_Reed@novell.com If there were still an osi-ds WG, I'd suggest that we add the topic "transitioning to '93 X.500" to the agenda for the next meeting. I'm not sure what to suggest without an osi-ds :-(. I agree that we need to transition to the '93 replication and access control. The problem is that there isn't a publically available version that supports the '93 stuff. This makes it much more difficult to make a transition. The country level DSAs could move to '93, but what do you do about all the organization level DSAs that can't go out and purchase DSA software? I guess you could tell them that replication won't work (turn off your updates). They could then use FTP to transfer the EDB files (which would have to be generated by pulling it out of the '93 DSA). A bigger problem is how to transition away from QUIPU's knowlege model. I don't have any good answers, but I do know that we need to start worrying about this SOON. **** Is anyone ready to take it on and either move this topic into an existing working group or create a new working group? **** Russ > >My current work has left me with the impression that as more and more >organizations being to investigate X.500, they look initially at the >1993 set of recommendations, then express concern when they find that so >much extant work is still stuck in 1988. From an operational point of >view, the 1988 recommendations leave out far too much. In order for >X.500 to be practical for commercial organizations, standard treatment >of ACLs and replication is required: users who want to do more than >research and testing require these services, and require than they be >provided in a common way. > >We have been able to carry out experiments on the Internet and on the >European networks only because we have been willing to do so much to get >around the missing pieces, AND because so many of us are using QUIPU: >we have achieved commonality of implementation by uniformity of product >selection. > >In order for the current Internet work on X.500 to be truely meaningful >and useful, it must reflect the fact that so many of the organizations >now connecting to the Internet are commercial organizations who can less >afford the time and resources to manage exceptional services such as >non-standard replication and ACLs. As these organizations come on >board, they will need the services defined in the 1993 series of >recommendations. > >The rest of us also need these services, and would like to see them >sooner rather than later. > >So, what do we do? We can either a) adopt 1993 replication and ACL >models, and stick with 1992 schema models, or b) adopt 1993 X.500 as a >whole. Option (a) trades one difficult-to-manage situation for another: >instead of managing non-standard replication and ACL schemes within the >framework of the 1988 recommendations, we manage back-level schema >models within the framework of the 1993 recommendations. Option (b) is >definitely cleaner; in the long run, it will also be less work, though >the upfront effort may be more intense. > >This argues in favour of early and aggressive movement toward all >aspects of the 1993 series. Including 1993 content rules. > >One counter argument that may carry some weight is the concern that >certain aspects of the 1993 series have not yet been proved workable. >Others more familiar with 1993 than me will have to pick up this line of >thought (I'm still digesting the new, thicker series of recommendations; >give me time....) > >pww > >Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] NT Secure Networks >pww@bnr.ca [ ] P.O. Box 3511, Station C >Ph: +1 613 765 2064 [ ] Ottawa >FAX:+1 613 765 3520 [__________________________] K1Y 4H7 ---------------------------------------------------------------------------- Russ Wright Lawrence Berkeley Laboratory Mail Stop 50B-2258 Berkeley, CA 94720 510-486-6965   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02447; 9 Aug 94 8:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02443; 9 Aug 94 8:17 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa04605; 9 Aug 94 8:17 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Aug 1994 12:37:34 +0100 Via: uk.ac.salford.io; Tue, 9 Aug 1994 12:37:18 +0100 Received: from mailgate-0.salford.ac.uk by io.salford.ac.uk with SMTP (PP); Tue, 9 Aug 1994 12:38:55 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: D.W.Chadwick@iti.salford.ac.uk Date: 9 Aug 94 24:34 To: osi-ds@cs.ucl.ac.uk Subject: X.500 defects X-Mailer: University of Salford cc:Mail/SMTP gateway 1.71 Encoding: 11 TEXT Message-ID: <9408090817.aa04605@CNRI.Reston.VA.US> Following on from our discussions the other week, that were prompted by Colin's recent aquisition of defect reports, the ITU rapporteur, Rolf Exner, is now looking for an FTP server in which to publish the latest version of the Implementor's Guide, which will contain an up to date list of all the defects in both the '88 and '93 standards. Any offers may first be directed to myself, and I will relay them to Rolf for you. David   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04887; 9 Aug 94 10:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04883; 9 Aug 94 10:38 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa08573; 9 Aug 94 10:38 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 9 Aug 1994 14:11:34 +0100 Date: Tue, 9 Aug 1994 14:11:34 +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.157:09.07.94.13.11.34] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Tue, 9 Aug 1994 14:11:34 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Thomas Lenggenhager Message-ID: <13448*/S=lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: osi-ds , dsa-manager Subject: cn=Condor changed address Please note the following (minor) change of the presentation address of the Swiss backup DSA cn=Condor which was done today. old: Internet=130.59.72.10+17003 new: '0101'H/Internet=130.59.72.10+17003 It should not be necessary to do any manual intervention. The ROOT DSA knows already the new address, so with the next EDB update your DSA will be updated. Manual intervention is only necessary in case this address is stored in the dsaptailor file. Kind regards, Thomas Lenggenhager =============================================================================== SWITCH - The Swiss Academic and Research Network Thomas Lenggenhager, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland INET: lenggenhager@switch.ch | Tel: +41 1 268 1540 | Fax: +41 1 268 1568 X.400: G=thomas; S=lenggenhager; O=switch; P=switch; A=arcom; C=ch;   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04907; 9 Aug 94 10:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04903; 9 Aug 94 10:38 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa08586; 9 Aug 94 10:38 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Aug 1994 15:26:06 +0100 Received: from library.fed.gov by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 9 Aug 1994 15:25:54 +0100 Message-ID: Date: Tue, 09 Aug 94 10:28:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Manager@library.fed.gov To: osi-ds@cs.ucl.ac.uk MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII subscribe osi-ds ESSE Manager   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04919; 9 Aug 94 10:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04915; 9 Aug 94 10:39 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa08603; 9 Aug 94 10:39 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 9 Aug 1994 15:06:02 +0100 Date: Tue, 9 Aug 1994 15:06:02 +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.367:09.07.94.14.06.02] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Tue, 9 Aug 1994 15:06:02 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Hoffmeister Message-ID: <"13948 Tue Aug 9 16:07:04 1994"@dfnrelay.d400.de> To: D.W.Chadwick@iti.salford.ac.uk Cc: osi-ds@cs.ucl.ac.uk In-Reply-To: <199408091331.PAA25882@mail.Germany.EU.net> Subject: Re: X.500 defects Hi to everybody, > Following on from our discussions the other week, that were prompted by Colin's > recent aquisition of defect reports, the ITU rapporteur, Rolf Exner, is now > looking for an FTP server in which to publish the latest version of the > Implementor's Guide, which will contain an up to date list of all the defects > in both the '88 and '93 standards. > > Any offers may first be directed to myself, and I will relay them to Rolf for > you. Our archive-team showed some interest in joining the Implementor's Guide to our current collection of books available via ftp.germany.eu.net It only depends on the amount of resources required to do so. Can you tell some details about necessary disk space ? regards, Frank.Hoffmeister@Germany.EU.net === ____ === EUnet Deutschland GmbH === / / / ___ ___ _/_ === Emil-Figge-Str. 80 === /---- / / / / /___/ / === D-44227 Dortmund === /____ /___/ / / /___ / === ===== ===== Tel. +49 231 972 00 ===== Connecting Europe since 1982 ===== Fax +49 231 972 1111   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06621; 9 Aug 94 12:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06617; 9 Aug 94 12:17 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa11995; 9 Aug 94 12:17 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Aug 1994 16:12:24 +0100 Received: from technet1.shl.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 9 Aug 1994 16:12:07 +0100 Received: by technet1.shl.com (4.1/SMI-4.1.8) id AA04432; Tue, 9 Aug 94 08:06:30 PDT Date: Tue, 9 Aug 94 08:06:30 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ken Rossen Message-Id: <9408091506.AA04432@technet1.shl.com> To: D.W.Chadwick@iti.salford.ac.uk, osi-ds@cs.ucl.ac.uk Subject: Re: X.500 defects > Rolf Exner, is now looking for an FTP server in which to > publish the latest version of the Implementor's Guide, > which will contain an up to date list of all the defects > in both the '88 and '93 standards. David (Hi, Rolf!) -- The OIW DS SIG archive on nemo.ncsl.nist.gov in pub/oiw/dssig has been used for some time for exactly this purpose, although its currency has suffered greatly since Sharon Boeyen left her post as Directory Defect Editor. We have '88 defects up to #74 and IG version 7. Nonetheless, the NIST archive is reasonably widely known, and is already shadowed at a number of sites (including some in Europe and elswhere), so it probably makes sense to make that archive current rather than starting from scratch. Write me for further logistics. -- KENR@SHL.COM   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06634; 9 Aug 94 12:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06630; 9 Aug 94 12:18 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12008; 9 Aug 94 12:18 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 9 Aug 1994 15:41:53 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 9 Aug 1994 15:41:39 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id KAA15198; Tue, 9 Aug 1994 10:41:14 -0400 Message-Id: <199408091441.KAA15198@terminator.rs.itd.umich.edu> To: Russ Wright cc: "peter (p.w.) whittaker" , osi-ds@cs.ucl.ac.uk, Ed_Reed@novell.com Subject: Re: '93 X.500 (was Re: Schema WG document - last call) In-reply-to: Your message of "Mon, 08 Aug 1994 15:43:35 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 Aug 1994 10:41:14 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Howes > From: Wright@LBL.Gov (Russ Wright) > To: "peter (p.w.) whittaker" , wright@LBL.Gov > If there were still an osi-ds WG, I'd suggest that we add the topic > "transitioning to '93 X.500" to the agenda for the next meeting. I'm not > sure what to suggest without an osi-ds :-(. > > I agree that we need to transition to the '93 replication and access > control. The problem is that there isn't a publically available version > that supports the '93 stuff. This makes it much more difficult to make a > transition. The country level DSAs could move to '93, but what do you do > about all the organization level DSAs that can't go out and purchase DSA > software? I guess you could tell them that replication won't work (turn > off your updates). They could then use FTP to transfer the EDB files > (which would have to be generated by pulling it out of the '93 DSA). > > A bigger problem is how to transition away from QUIPU's knowlege model. > > I don't have any good answers, but I do know that we need to start worrying > about this SOON. > > **** Is anyone ready to take it on and either move this topic into an > existing working group or create a new working group? **** I think we need to decide just what needs to be done, and which parts are appropriate for the ietf, and which working group(s) should handle these parts. For example, a '93 replication profile for the Internet probably needs to be defined. This is certainly something for the ietf, and seems a lot like something in ASID's charter. There are other issues that are more operational, though, and probably not for the ietf at all. -- Tim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06645; 10 Aug 94 11:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06641; 10 Aug 94 11:44 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa09455; 10 Aug 94 11:44 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Aug 1994 16:03:00 +0100 Received: from rcsuna.gmr.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Aug 1994 16:02:53 +0100 Received: from earth.troy.eng.eds.com by rcsuna.gmr.com (4.1/GMR-1.2) id AA13970; Wed, 10 Aug 94 11:02:49 EDT Received: from majorca (majorca.troy.eng.eds.com) by earth.troy.eng.eds.com (4.1/AE-1.0) id AA11566; Wed, 10 Aug 94 10:02:43 EDT Date: Wed, 10 Aug 1994 10:03:49 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jason Cross X-Orig-Sender: Jason Cross Reply-To: Jason Cross Subject: mixed bag To: osi-ds , ldap Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Had a few questions in regard to quipu and ldap. Are there any stats about search times to quipu with a medium size directory, say 5,000 entries (does the depth of the tree greatly effect the search)? We would be querying on a variety of attributes. We would like to write a program to query the directory using LDAP and I was wondering if there is any code available to LDAP that would aid in writing to the protocol. Are there any Directory Users Agents out on the net with decent search capabilities. It would be preferable to have DUAs on MS-Windows. ciao, Jason Cross EDS Troy, Mi.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08536; 10 Aug 94 13:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08532; 10 Aug 94 13:50 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12905; 10 Aug 94 13:50 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Aug 1994 18:01:37 +0100 Received: from monge.brunel.ac.uk by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Aug 1994 18:01:27 +0100 Received: from babbage.brunel.ac.uk by monge.brunel.ac.uk with SMTP (PP) id <05730-0@monge.brunel.ac.uk>; Wed, 10 Aug 1994 18:01:12 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Findlay Message-Id: <12382.9408101701@babbage.brunel.ac.uk> Subject: Re: mixed bag To: jcross01@eng.eds.com Date: Wed, 10 Aug 1994 18:01:09 +0100 (BST) Cc: osi-ds@cs.ucl.ac.uk, ldap@umich.edu In-Reply-To: from "Jason Cross" at Aug 10, 94 10:03:49 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 11896 >We would like to write a program to query the directory using >LDAP and I was wondering if there is any code available to >LDAP that would aid in writing to the protocol. I suggest you pick up the Michigan LDAP libraries and example code. >Are there any Directory Users Agents out on the net with decent >search capabilities. It would be preferable to have DUAs >on MS-Windows. We have produced several at Brunel, using an advanced query engine of our own design. One of these is indeed for MS-Windows, and is called PC-Pages. I append a list of our DUAs and their characteristics. Andrew ---------------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk +44 895 203066 or +44 895 274000 x2512 | ---------------------------------------------------------------------------- X.500 products available from Brunel University =============================================== The X.500 Group at Brunel produces Directory User Interfaces for a range of platforms. The main products are: Xlu X-Windows with Athena style MXlu X-Windows with Motif style Slu Character-screen Wlu WWW gateway PC-Pages MS-Windows The first four products are for Unix systems using ISODE. PC-Pages is for MS-Windows, and exists in two forms: one for ISO DAP and one for LDAP. The Unix products are freely available. PC-Pages is available under licence. More detailed information is given below, in the format used by the IETF survey of directory products. For more information, contact x500@brunel.ac.uk ---------------------------------------------------------------------- NAME MXLU Brunel University, UK KEYWORDS DUA Connectivity, DUA Only, Free, Motif, Multiple Vendor Platforms, Needs ISODE, Source, UNIX, X Window System ABSTRACT MXLU (Motif/X LookUp) is an X.500 DUA interface for the X Window System using Motif. Ported from the Athena widgets version, MXLU can be configured for many different styles of interaction. Example configurations are provided for single window and multiple window use. MXLU implements the `User-Friendly Naming' search strategy and also has a form-filling search mode. Asynchronous directory operations are used. Full user friendly add and modify functions are provided, with the ability to tailor the modify screen to present simple subsets of the available attributes. Can also be configured as a bibliographic search tool for use with the ABDUX Project bibliographic DSAs. COMPLIANCE (applicable only for DSAs and DUAs) 88 Standard compliant: Strong authentication not yet implemented. No plans for support of the 1992 Standard. COMPATIBILITY WITH PROPOSED INTERNET STANDARDS No plans at present. INTEROPERABILITY Tested with ISODE-8.0 PILOT CONNECTIVITY DUA Connectivity: The interface is in use in the UK Academic Directory Pilot. BUGS Bugs should be reported to x500@brunel.ac.uk. CAVEATS and GENERAL LIMITATIONS Does not support modification of all known attribute syntaxes. In particular, ACLs and O/R addresses are not catered for. INTERNETWORKING ENVIRONMENT As ISODE. HARDWARE PLATFORMS Most UNIX machines. SOFTWARE PLATFORMS UNIX Motif 1.1 > ISODE/QUIPU (version 8.0 >) AVAILABILITY Sources are freely available for commercial or non-commercial use. Binaries for SunOs 4.1.3 are also available from Brunel, to simplify installation on sites that do not already use ISODE. FTP site: src.brunel.ac.uk Directory: /x500 Source code files: mxlu-1.1.tar.Z query-1.1.tar.Z Binary file: mxlubin-1.1.tar.Z Contacts. Postal Address: Andrew Findlay Computing and Media Systems Brunel University Cleveland Road Uxbridge, Middlesex UB8 3PH UK E-mail: x500@brunel.ac.uk. Fax: +44 895 252691 (Andrew Findlay) Telephone: +44 895 203066 (Andrew Findlay) ---------------------------------------------------------------------- NAME XLU Brunel University, UK KEYWORDS DUA Connectivity, DUA Only, Free, Multiple Vendor Platforms, Needs ISODE, Source, UNIX, X Window System ABSTRACT XLU (X LookUp) is an X.500 DUA interface for the X Window System. XLU can be configured for many different styles of interaction. Example configurations are provided for single window and multiple window use. XLU implements the `User-Friendly Naming' search strategy and also has a form-filling search mode. Asynchronous directory operations are used. Full user friendly add and modify functions are provided, with the ability to tailor the modify screen to present simple subsets of the available attributes. COMPLIANCE (applicable only for DSAs and DUAs) 88 Standard compliant: Strong authentication not yet implemented. No plans for support of the 1992 Standard. COMPATIBILITY WITH PROPOSED INTERNET STANDARDS No plans at present. INTEROPERABILITY [No information provided--Ed.] PILOT CONNECTIVITY DUA Connectivity: The interface is in use in the UK Academic Directory Pilot. BUGS Bugs should be reported to x500@brunel.ac.uk. CAVEATS and GENERAL LIMITATIONS [No information provided--Ed.] INTERNETWORKING ENVIRONMENT As ISODE. HARDWARE PLATFORMS Most UNIX machines. SOFTWARE PLATFORMS UNIX MIT X11R5 libraries ISODE/QUIPU (version 8.0 >) AVAILABILITY Sources are freely available for commercial or non-commercial use. Contacts. Postal Address: Andrew Findlay Computing and Media Systems Brunel University Cleveland Road Uxbridge, Middlesex UB8 3PH UK E-mail: x500@brunel.ac.uk. Fax: +44 895 32806 (Andrew Findlay) Telephone: +44 895 203066 (Andrew Findlay) DATE LAST UPDATED or CHECKED March 1st, 1993 ---------------------------------------------------------------------- NAME PC-Pages Brunel University, UK KEYWORDS DUA Connectivity, DUA Only, IBM PC, LDAP, Limited Availability, Multiple Vendor Platforms, OSI Transport, RFC-1006 ABSTRACT PC-Pages is an MS-Windows X.500 DUA interface. Features include: "Form" based searching. Also supports the User Friendly Name (UFN) specification (RFC 1484). Powerful query engine. Tailorable entry display - display only those attributes required. Integrates with the WhiteMail X.400 user agent. Hooks are provided to allow integration with other user agents. Directory browsing. Support for JPEG photo attributes. Modify directory entries. Add directory entries. Delete directory entries. Rebind to a configured DSA. Some support for configuration of DAP service parameters. Two versions of PC-Pages are currently available. One supports DAP over CONS or DAP over RFC-1006. The other supports LDAP and has a more advanced user interface including a tree-browser. A version in the form or a Windows DLL (Dynamic Link Library) is being prepared, for incorporation into other products such as mail agents. This is now on beta-test as part of a commercial supplier's mail user interface. COMPLIANCE (applicable only for DSAs and DUAs) 88 Standard compliant: Strong authentication not yet implemented. No immediate plans for support of the 1992 Standard. COMPATIBILITY WITH PROPOSED INTERNET STANDARDS INTEROPERABILITY Tested with Quipu 8.0. PILOT CONNECTIVITY DUA Connectivity: The interface is in use in the UK Academic Directory Pilot. BUGS Bugs should be reported to x500@brunel.ac.uk. CAVEATS and GENERAL LIMITATIONS Does not support display or modification of all known attribute syntaxes. In particular: ACLs cannot be displayed but they can be modified by selecting a predefined template. INTERNETWORKING ENVIRONMENT RFC1006 with TCP/IP. TP4 with CONS. A NetBIOS gateway to the previously listed protocols. LDAP using Winsock. HARDWARE PLATFORMS PC-Pages for Windows requires an IBM PC compatible with 286 or higher, 2mb+ memory. SOFTWARE PLATFORMS Windows 3.0 or 3.1 running in Standard or Enhanced mode. DAP versions need WhiteStack 1.1, from the Edinburgh University Computing Service. LDAP versions require a TCP/IP stack with the Winsock interface. AVAILABILITY Free to UK Academic Community, and to some other communities subject to certain restrictions. Available for commercial licensing. Commercial derivatives exist. Please send queries to: Postal: Andrew Findlay Computing and Media Services Brunel University Cleveland Road Uxbridge, Middlesex UB8 3PH UK E-mail: x500@brunel.ac.uk Fax: +44 895 252691 (Andrew Findlay) Telephone: +44 895 203066 (Andrew Findlay) ---------------------------------------------------------------------- NAME SLU Brunel University, UK KEYWORDS DUA Connectivity, DUA Only, Free, Multiple Vendor Platforms, Needs ISODE, Source, UNIX ABSTRACT SLU (Screen Lookup) is a full-screen character-terminal DUA for Unix systems. Features include: User-Friendly Name (UFN) searching Progress reporting Interruptable searches Browse mode History display Flexible configuration COMPLIANCE (applicable only for DSAs and DUAs) 88 Standard compliant: Strong authentication not yet implemented. No plans for support of the 1992 Standard. COMPATIBILITY WITH PROPOSED INTERNET STANDARDS No plans at present. INTEROPERABILITY Tested with ISODE-8.0 PILOT CONNECTIVITY DUA Connectivity: The interface is in use in the UK Academic Directory Pilot. BUGS Bugs should be reported to x500@brunel.ac.uk. CAVEATS and GENERAL LIMITATIONS INTERNETWORKING ENVIRONMENT As ISODE. HARDWARE PLATFORMS Most UNIX machines. SOFTWARE PLATFORMS UNIX ISODE/QUIPU (version 8.0 >) AVAILABILITY Sources are freely available for commercial or non-commercial use. FTP site: src.brunel.ac.uk Directory: /x500 Source code files: slu-1.0.tar.Z query-1.1.tar.Z Contacts. Postal Address: Andrew Findlay Computing and Media Systems Brunel University Cleveland Road Uxbridge, Middlesex UB8 3PH UK E-mail: x500@brunel.ac.uk. Fax: +44 895 252691 (Andrew Findlay) Telephone: +44 895 203066 (Andrew Findlay) ---------------------------------------------------------------------- NAME WLU Brunel University, UK KEYWORDS DUA Connectivity, DUA Only, Free, Multiple Vendor Platforms, Needs ISODE, Source, UNIX, WWW ABSTRACT WLU (Web LookUp) is a gateway between the World Wide Web and the X.500 Directory. Features include: User-Friendly Name (UFN) searching Browse mode Flexible configuration in URL Display of photo and sound attributes Hyperlinks for `See Also' and other DN attributes Can be tested by pointing your favourite WWW browser at: http://http1.brunel.ac.uk:8080/wlu.html COMPLIANCE (applicable only for DSAs and DUAs) 88 Standard compliant: Strong authentication not yet implemented. No plans for support of the 1992 Standard. COMPATIBILITY WITH PROPOSED INTERNET STANDARDS No plans at present. INTEROPERABILITY Tested with ISODE-8.0 PILOT CONNECTIVITY DUA Connectivity: The interface is in use in the UK Academic Directory Pilot. BUGS Bugs should be reported to x500@brunel.ac.uk. CAVEATS and GENERAL LIMITATIONS INTERNETWORKING ENVIRONMENT As ISODE. HARDWARE PLATFORMS Most UNIX machines. SOFTWARE PLATFORMS UNIX ISODE/QUIPU (version 8.0 >) AVAILABILITY Sources will be freely available for commercial or non-commercial use. Contacts. Postal Address: Andrew Findlay Computing and Media Systems Brunel University Cleveland Road Uxbridge, Middlesex UB8 3PH UK E-mail: x500@brunel.ac.uk. Fax: +44 895 252691 (Andrew Findlay) Telephone: +44 895 203066 (Andrew Findlay)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10336; 10 Aug 94 15:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10332; 10 Aug 94 15:12 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14757; 10 Aug 94 15:12 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Aug 1994 20:06:53 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Aug 1994 20:06:42 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id PAA16137; Wed, 10 Aug 1994 15:05:56 -0400 Message-Id: <199408101905.PAA16137@terminator.rs.itd.umich.edu> To: jcross01@eng.eds.com, osi-ds@cs.ucl.ac.uk, ldap@umich.edu Subject: Re: mixed bag In-reply-to: Your message of "Wed, 10 Aug 1994 18:01:09 BST." <12382.9408101701@babbage.brunel.ac.uk> Date: Wed, 10 Aug 1994 15:05:56 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Rothwell > >We would like to write a program to query the directory using > >LDAP and I was wondering if there is any code available to > >LDAP that would aid in writing to the protocol. > > I suggest you pick up the Michigan LDAP libraries and example code. > > >Are there any Directory Users Agents out on the net with decent > >search capabilities. It would be preferable to have DUAs > >on MS-Windows. > I just release a new version of a Windows X.500 DUA yesterday. The current version is "read only" - that is you can't make changes to any server data, just read it. Here's the announcement I sent out. From: Steve Rothwell To: wax500.announce@umich.edu Subject: WaX.500 release 1.03 announcement Date: Tue, 09 Aug 1994 14:35:51 EDT Folks, I've just released WaX.500 version 1.03. It has been extensively improved since the last release. The primary changes are the addition of a visual browser and extensive, context sensitive help. This version is still "read only", mods and additions are next on the list. To ftp this version host: terminator.rs.itd.umich.edu loc: ~ftp/x500/wax500/ files: waxr103.exe - self extracting zip file waxr103.zip - zip file contained in waxr103.exe readme - contained in both the above files If you want to be added to the announcement list, change your address, etc.; send requests to wax500.announce-request@umich.edu. Report bugs to wax500.bugs@umich.edu.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10349; 10 Aug 94 15:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10345; 10 Aug 94 15:12 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14765; 10 Aug 94 15:12 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Aug 1994 19:08:14 +0100 Received: from gw1.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Aug 1994 19:08:06 +0100 Received: from pegasus.UUCP by ig1.att.att.com id AA05047; Wed, 10 Aug 94 14:06:50 EDT Message-Id: <9408101806.AA05047@ig1.att.att.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: sant@pegasus.att.com Date: 10 Aug 94 17:58:13 GMT To: jcross01@eng.eds.com, osi-ds@cs.ucl.ac.uk, ldap@umich.edu Original-From: sant Original-Date: Wed Aug 10 13:58:13 EDT 1994 Subject: Re: mixed bag Original-To: eng.eds.com!jcross01 Original-To: osi-ds@cs.ucl.ac.uk Original-To: ldap@umich.edu In-Reply-To: your message of Wed Aug 10 10:03:49 -0400 1994 Content-Type: Text ----------------------- Begin Original Message ---------------------- Had a few questions in regard to quipu and ldap. Are there any stats about search times to quipu with a medium size directory, say 5,000 entries (does the depth of the tree greatly effect the search)? We would be querying on a variety of attributes. We would like to write a program to query the directory using LDAP and I was wondering if there is any code available to LDAP that would aid in writing to the protocol. Are there any Directory Users Agents out on the net with decent search capabilities. It would be preferable to have DUAs on MS-Windows. ciao, Jason Cross EDS Troy, Mi. ------------------------ End Original Message ----------------------- Jason, I don't know about DUAs for MS-Windows on the net. I am running 3 different DUAs with MS-Windows on my desktop. They are from, 1. Enterprise Mail Directory by Bolden James Limited 2. PC-DUA by Nexor 3. Browser by ISOCOR 1 and 2 are commercially available. I don't know about 3 . 1 and 2 uses LDAP and 3 uses DAP . 2 and 3 uses the standard Winsock 1 requires Visionware software . If you need contact information, I can provide. Sant Srinivasan sant@pegasus.att.com AT&T Easylink Services   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10361; 10 Aug 94 15:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10356; 10 Aug 94 15:12 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa14772; 10 Aug 94 15:12 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Aug 1994 19:21:54 +0100 Received: from terminator.rs.itd.umich.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 10 Aug 1994 19:21:49 +0100 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id OAA14496; Wed, 10 Aug 1994 14:20:46 -0400 Message-Id: <199408101820.OAA14496@terminator.rs.itd.umich.edu> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Smith To: jcross01@eng.eds.com cc: osi-ds@cs.ucl.ac.uk, ldap@umich.edu Subject: Re: LDAP interfaces In-reply-to: Your message of "Wed, 10 Aug 1994 10:03:49 EST" Date: Wed, 10 Aug 1994 14:20:46 -0400 X-Orig-Sender: mcs@terminator.rs.itd.umich.edu >From: jcross01@eng.eds.com > > We would like to write a program to query the directory using > LDAP and I was wondering if there is any code available to > LDAP that would aid in writing to the protocol. There are many LDAP interfaces available. To develop your own, pick up our (Univ. of Michigan) LDAP distribution from terminator.rs.itd.umich.edu in the /x500 directory. There are several gateways and clients available from there as well. If you have access to WWW, a good starting point to find a lot of useful X.500-related information is: http://www.bath.ac.uk/~ccsap/Directory/x500.html LDAP interfaces have been developed for Unix (shell and X-Windows), MS-DOS, MS-Windows, and Macintosh at least. Many of them are quite easy to use. -Mark Smith University of Michigan X.500 Directory Project   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12821; 11 Aug 94 16:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12817; 11 Aug 94 16:56 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13923; 11 Aug 94 16:56 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 11 Aug 1994 20:54:05 +0100 Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 11 Aug 1994 20:53:53 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 11 Aug 1994 15:52:39 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 11 Aug 1994 15:50:57 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 11 Aug 1994 15:50:00 -0400 Date: Thu, 11 Aug 1994 15:50: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/;bcars735.b.229:11.07.94.19.50.57] X400-Content-Type: P2-1984 (2) Content-Identifier: Questions on ... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "peter (p.w.) whittaker" X-Orig-Sender: "peter (p.w.) whittaker" Message-ID: <"9262 Thu Aug 11 15:51:08 1994"@bnr.ca> To: quipu@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk Subject: Questions on searching. When searching a QUIPU DSA, with TURBO_INDEX on, and indexes built: If I build a search string with both indexed and non-indexed attributes, will all indexed attributes be considered first and then a linear search done on the short list of non-indexed attributes, OR are the attributes processed in the order given? Thanks, pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Secure Networks pww@bnr.ca [ ] Bell-Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 765 3520 [__________________________] Ottawa, Ontario, K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16257; 11 Aug 94 21:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16253; 11 Aug 94 21:15 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa19106; 11 Aug 94 21:15 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Aug 1994 01:35:49 +0100 Received: from nic.ott.hookup.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 12 Aug 1994 01:35:37 +0100 Received: from [165.154.6.200] (brw.ott.hookup.net [165.154.6.200]) by nic.ott.hookup.net (8.6.9/1.27) with SMTP id UAA21573; Thu, 11 Aug 1994 20:35:21 -0400 Message-Id: <199408120035.UAA21573@nic.ott.hookup.net> X-Sender: brw@ott.hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Aug 1994 20:36:01 -0500 To: osi-ds@cs.ucl.ac.uk Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Brian R. Williams" Subject: DSA / DUA RFP Development I am in the process of preparing a Request for Proposal / Request for Quote for DSAs and DUAs for a significant Canadian organization. It is expected that eventually there will be several (10-50 or more) DSAs serving this organization from coast-to-coast. The Directory will serve the traditional White Pages applications as well as serve as a directory for network component information, documentation information, and a variety of other similar purposes. I know that most of the features we will want are found in the 1993 X.500 Recommendations (which I believe haven't yet been published, although approved) as well as a number of other 'standards' which are in process ( ISPs and other OIW proposals). I believe that there is a severe shortage of products 'compliant' with these new standards so will have to elicit commitments and promises from respondant vendors. My question: Is anyone receiving this message, willing to share his or her own recent work of a similar nature? In other words, has anyone else recently written an RFP for Directory products and is willing to grant me a copy of the work. I don't intend to plagerize, but I'd like to see how others present their requirements, and in what detail. If vendors have a stock RFP they offer their potential clients (No! They don't really do that, do they?), then I would be pleased to receive a copy. Any and all other advice, with regards to the RFP, will be accepted graciously. With regards to all, Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00462; 12 Aug 94 4:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00458; 12 Aug 94 4:03 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01029; 12 Aug 94 4:03 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 12 Aug 1994 08:22:04 +0100 Date: Fri, 12 Aug 1994 08:22:04 +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.993:12.07.94.07.22.04] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 12 Aug 1994 08:22:04 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <10191.776676072@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/osi/x500/graphroot.gif" Probing from SWITCH@Zurich, NEXOR, Cambridge Computer Lab, ULCC, Community: internet ========== ======== The following DSAs were available 100% of the time: cn=Condor Other DSAs: ----- ----- %Avail Organisation,DSA Attempts ------ ---------------- -------- 97.89 SUNET, Hummingbird 475 10 Timed out after 60 seconds 97.89 North Atlantic Treaty Organization, Violaceous Trogon 475 10 Timed out after 60 seconds 97.68 Computer and Automation Institute, Guinea Pig 475 11 Timed out after 60 seconds 97.68 Restena, Guppy 475 11 Timed out after 60 seconds 97.26 DFN, Margay 475 13 Timed out after 60 seconds 97.05 Technische Universiteit Delft, Hornero 475 4 Connection refused 10 Timed out after 60 seconds 96.84 FUNET, Northern Pudu 475 15 Timed out after 60 seconds 96.63 Trinity College Dublin, Irish Elk 475 5 Host is unreachable 11 Timed out after 60 seconds 96.63 NEXOR Ltd, Vampire Bat 475 10 Timed out after 60 seconds 6 Host is unreachable 96.42 GARR-NIS, Black Widow 475 17 Timed out after 60 seconds 96.42 Unknown Organisation, Corncrake 475 13 Timed out after 60 seconds 4 Host is unreachable 96.21 Unknown Organisation, opaxdsa, CNRS, FR 475 5 Connection refused 13 Timed out after 60 seconds 96.21 ARNES, Proteus 475 16 Timed out after 60 seconds 1 Host is unreachable 1 Connection refused 95.79 Technische Universitaet Chemnitz-Zwickau, Puma 475 19 Timed out after 60 seconds 1 Connection refused 95.58 GB Master DSA, inca dove 475 19 Timed out after 60 seconds 2 Connection refused 95.37 SWITCH, Chinchilla 475 16 Timed out after 60 seconds 6 Connection refused 94.95 DENet, Armadillo 475 4 Connection refused 6 Host is unreachable 14 Timed out after 60 seconds 94.35 Universitaet Wien, Rockhopper Penguin 478 3 Host is unreachable 21 Timed out after 60 seconds 94.32 U.S. DMD, Pied Tamarin 475 25 Timed out after 60 seconds 2 Host is unreachable 94.32 Prague University of Economics, Woolly Opossum 475 16 Timed out after 60 seconds 8 Host is unreachable 3 Connection refused 94.11 Root of the World, Giant Tortoise 475 19 Timed out after 60 seconds 9 Connection refused 94.11 Victoria University of Wellington, Kakapo 475 16 Timed out after 60 seconds 7 Connection refused 1 Host is unreachable 4 Network is unreachable 93.89 GARR-NIS, Black Widow 475 11 Host is unreachable 18 Timed out after 60 seconds 93.70 SURIS, Elephant Seal 476 17 Invalid credentials 1 Host is unreachable 10 Timed out after 60 seconds 2 Connection refused 93.68 Matej Bel University, UAKOM UMB Banska Bystrica, Tarpon 475 15 Timed out after 60 seconds 15 Host is unreachable 93.47 Australian Academic and Research Network, Anaconda 475 24 Timed out after 60 seconds 3 Connection refused 3 Network is unreachable 1 Host is unreachable 93.47 UNINETT, Electric Eel 475 7 Host is unreachable 24 Timed out after 60 seconds 93.26 Moscow State University, Bear 475 20 Timed out after 60 seconds 12 Host is unreachable 93.05 Brussels University, Red Titi Monkey 475 26 Timed out after 60 seconds 6 Connection refused 1 Unavailable 93.05 RCCN Portugal, Zebu 475 26 Timed out after 60 seconds 7 Host is unreachable 92.63 Australian Academic and Research Network (AARNet), Bush Dog 475 26 Timed out after 60 seconds 3 Host is unreachable 2 Connection refused 2 Network is unreachable 2 Unavailable 92.00 UNINETT, Boa Constrictor 475 29 Timed out after 60 seconds 9 Host is unreachable 91.16 WIDE project, Sloth 475 32 Timed out after 60 seconds 7 Host is unreachable 2 Network is unreachable 91.00 UMK, Ocelot 478 19 Host is unreachable 24 Timed out after 60 seconds 90.11 Unknown Organisation, Andean Cat 475 1 Connection refused 46 Timed out after 60 seconds 87.18 NSTN Inc, beluga whale 476 49 Timed out after 60 seconds 12 Connection refused 84.97 RedIRIS, iguana 479 25 Timed out after 60 seconds 10 Host is unreachable 33 Connection refused 84.21 ULCC, Ocellated Turkey 475 58 Connection refused 17 Timed out after 60 seconds 81.47 Foundation Of Research and Technology Hellas, Caretta Caretta 475 83 Timed out after 60 seconds 3 Unavailable 2 Connection refused 81.21 FUNET, Jaguar 479 33 Connection refused 23 Host is unreachable 21 Timed out after 60 seconds 77.05 Inmarsat, Hedgehog 475 100 Connection refused 9 Timed out after 60 seconds 76.63 Unknown Organisation, Dorcan Gazelle 475 107 Timed out after 60 seconds 3 Unavailable 1 Connection refused 76.21 U.S. DMD, Fruit Bat 475 94 Connection refused 18 Timed out after 60 seconds 1 Unavailable 66.09 Vrije Universiteit Brussel, Woolly Spider Monkey 230 71 Connection refused 7 Timed out after 60 seconds 58.92 SWITCH, Condor 314 11 Timed out after 60 seconds 117 Unavailable *** (not expecting connection for tsap/"" 1 Connection refused 58.53 Universidad Politecnica de Madrid, Cayman 475 14 Timed out after 60 seconds 183 Connection refused 52.93 DKUUG, Axolotl 478 133 Connection refused 70 Timed out after 60 seconds 3 Host is unreachable 41.84 U.S. DMD, Alpaca 478 208 Connection refused 24 Unavailable 9 Timed out after 60 seconds 36.74 Tallinn Technical University, saki 479 299 Timed out after 60 seconds 2 Host is unreachable 28.18 IIT Delhi, IN, Pelican 479 220 Host is unreachable 12 Invalid credentials 37 Timed out after 60 seconds 18 Connection refused 0.00 RCCN Portugal, Zebu 1 1 Timed out after 60 seconds 0.00 Master DSA of KOREA, Darter 475 448 Connection refused 22 Timed out after 60 seconds 2 Host is unreachable 3 Network is unreachable 0.00 Universidade Federal do Rio Grande do Sul (UFRGS), paca 475 451 Connection refused 23 Timed out after 60 seconds 1 Host is unreachable 0.00 Bell-Northern Research, Pangolin 475 453 Connection refused 20 Timed out after 60 seconds 2 Host is unreachable 0.00 University of Zagreb - Faculty of Electrical Engineering, Roufous Motmot 475 5 Host is unreachable 470 Timed out after 60 seconds 0.00 Nanyang Technological University, Silk Spider 475 446 Connection refused 21 Timed out after 60 seconds   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22052; 13 Aug 94 2:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22048; 13 Aug 94 2:12 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa26350; 13 Aug 94 2:12 EDT Received: from shark.mel.dit.CSIRO.AU by haig.cs.ucl.ac.uk with Internet SMTP id ; Sat, 13 Aug 1994 06:44:48 +0100 Received: from conger.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA21986 (5.65c/IDA-1.4.4/DIT-1.3 for osi-ds@cs.ucl.ac.uk); Sat, 13 Aug 1994 15:42:58 +1000 Message-Id: <199408130542.AA21986@shark.mel.dit.csiro.au> To: "Brian R. Williams" Cc: osi-ds@cs.ucl.ac.uk, ajw@mel.dit.csiro.au Subject: Re: DSA / DUA RFP Development In-Reply-To: Your message of "Thu, 11 Aug 1994 20:36:01 EST." <199408120035.UAA21573@nic.ott.hookup.net> Date: Sat, 13 Aug 1994 15:42:57 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Waugh > I am in the process of preparing a Request for Proposal / Request for Quote > for DSAs and DUAs for a significant Canadian organization. > I know that most of the features we will want are found in the 1993 X.500 > Recommendations (which I believe haven't yet been published, although > approved) as well as a number of other 'standards' which are in process ( > ISPs and other OIW proposals). I believe that there is a severe shortage of > products 'compliant' with these new standards so will have to elicit > commitments and promises from respondant vendors. > > My question: Is anyone receiving this message, willing to share his or her > own recent work of a similar nature? In other words, has anyone else > recently written an RFP for Directory products and is willing to grant me a > copy of the work. I don't intend to plagerize, but I'd like to see how > others present their requirements, and in what detail. While I have recently done exactly this, we did it under contract for a client, so I can't give copies out (:-(. I can, however, give you some advice. DON'T write a RFP/RFQ for X.500. Instead, write it for the purchase of a _Directory System_. I'm not having a crack at X.500 here. Rather, I am trying to emphasise that deploying a directory does not just involve purchasing DSAs and DUAs. When writing the RFP/RFQ think about the system aspects first. How is data to be entered into the system and subsequently maintained? What tools will this need? What use is to be made of this data? What tools will this require? How is the system to be distributed and managed? What tools must be provided? What machines must these tools run on? How is the directory to be networked? What response times are necessary for the different classes of users? What schema is to be used? A surprising number of the answers to these questions will not involve X.500 at all. For example, one aspect of managing a directory (or any database) is ensuring that the data can be restored after a crash - so the RFP/RFQ must have back-ups and journals (or their equivalent). Other requirements may imply non-X.500 solutions (e.g. a DUA on a small PC at the end of a thin wire might have better performance if it talked a lightweight directory protocol to a server, than the full DAP.) Of course, deep within this RFP/RFQ you will very likely start referring to X.500 to tie the various components together. Although it is not directly relevant to your need, you might be interested in a paper I gave last year on 'Where are the Network Applications?'. In it I described why I thought there were so few successful network applications. The major theme of the paper is that few network applications are deployed because of insufficient attention being paid to the system features. X.500 forms the major example in the paper - both its good points and its bad ones. The paper was heavily influenced by my experiences in helping to write an RFP/RFQ for an X.500 system. If you are interested, let me know. andrew waugh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15522; 15 Aug 94 20:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15518; 15 Aug 94 20:57 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa21831; 15 Aug 94 20:57 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 16 Aug 1994 01:32:01 +0100 Received: from shark.mel.dit.CSIRO.AU by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 16 Aug 1994 01:31:36 +0100 Received: from conger.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA23908 (5.65c/IDA-1.4.4/DIT-1.3 for osi-ds@cs.ucl.ac.uk); Tue, 16 Aug 1994 10:25:52 +1000 Message-Id: <199408160025.AA23908@shark.mel.dit.csiro.au> To: Andrew Waugh Cc: "Brian R. Williams" , osi-ds@cs.ucl.ac.uk, ajw@mel.dit.csiro.au, ajw@mel.dit.csiro.au Subject: Re: DSA / DUA RFP Development In-Reply-To: Your message of "Sat, 13 Aug 1994 15:42:57 +1000." <199408130542.AA21986@shark.mel.dit.csiro.au> Date: Tue, 16 Aug 1994 10:25:51 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Waugh > Although it is not directly relevant to your need, you might be interested > in a paper I gave last year on 'Where are the Network Applications?'. In it > I described why I thought there were so few successful network applications. > The major theme of the paper is that few network applications are deployed > because of insufficient attention being paid to the system features. X.500 > forms the major example in the paper - both its good points and its bad ones. > The paper was heavily influenced by my experiences in helping to write an > RFP/RFQ for an X.500 system. If you are interested, let me know. I have received a number of requests for this paper, so I have made it available for anonymous ftp. First, however, if you already have my document on 1993 X.500, you already have the Network Applications paper. I included it as Chapter 9; I wanted to include a chapter on what I thought were the strengths and weaknesses of X.500 and the Network Applications paper covered most of the points. If you don't have the 1993 document, you can ftp the paper from shark.mel.dit.csiro.au:staff/ajw/WatNA.ps.Z (postscript) shark.mel.dit.csiro.au:staff/ajw/WatNA.macw5.Z (mac word 5) I've used a trimmer to cut down the size of the postscript produced by the macintosh. This is the first time I have used such a beastie, and I am moderately skeptical about success (although it printed here). If anyone has any problems, could they let me know. If anyone who is interested in the paper cannot ftp, could they let me know... andrew waugh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00625; 16 Aug 94 4:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00621; 16 Aug 94 4:39 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01407; 16 Aug 94 4:39 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Tue, 16 Aug 1994 08:21:46 +0100 Received: from sapling.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 16 Aug 1994 08:21:36 +0100 X400-Received: by mta sapling.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 16 Aug 1994 09:22:11 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 16 Aug 1994 09:21:23 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 16 Aug 1994 09:21:18 +0200 Date: Tue, 16 Aug 1994 09:21:18 +0200 X400-Originator: Erik.Huizer@SURFnet.nl X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;survis.surfn:058690:940816072123] X400-Content-Type: P2-1984 (2) Content-Identifier: Booklet: (q)H... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" Message-ID: <"5872 Tue Aug 16 09:21:28 1994"@surfnet.nl> To: osi-ds@cs.ucl.ac.uk, directory-group@jnt.ac.uk, punters@paradise.ulcc.ac.uk, quipu@cs.ucl.ac.uk Cc: admin@surfnet.nl Subject: Booklet: "How to build a Directory Service" Reply-To: admin@surfnet.nl Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 HI, sorry for the duplicates, but I thought it might be of wider interest. SURFnet has recently published a FREE booklet, pompously titled: "How to build a Directory Service". The booklet intents to give an overview of the various issues that someone who wants to start a DS will encounter. It's based on the experiences in the SURFnet X.500 project so far. It covers: - Brief introduction to X.500 - Introduction to the legal issues (aimed at European law) - Infrastructure issues - Datamanagement issues (Describes three case studies) - It concludes with a set of recommendations Although this booklet is speciffically aimed at the SURFnet environment, we thought it sufficiently general to write it in English rather than Dutch. Also apart from the X.500 and infrastructure charpter the booklet is not X.500 specific and the remaining chapters apply to other protocols (WHOIS++ etc.) as well. If you would like to have copies of this book (FREE of charge), send E-mail to: admin@surfnet.nl Indicate: - how many copies you would like to receive. - The title: "How to build a Directory Service". - Your postal address Thanks, Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04875; 17 Aug 94 10:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04870; 17 Aug 94 10:26 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07099; 17 Aug 94 10:26 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 17 Aug 1994 13:24:11 +0100 Received: from gwx400a.bull.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 17 Aug 1994 13:24:02 +0100 Received: from khephren.bull.fr (gwx400b.bull.fr) by kheops.bull.fr; Wed, 17 Aug 1994 14:17:14 +0200 (MET) Received: from mybull.frmy.bull.fr by khephren.bull.fr; Wed, 17 Aug 1994 12:29:45 +0200 (MET) Received: from myster.frmy.bull.fr by mybull.frmy.bull.fr; Tue, 16 Aug 1994 15:37:00 +0200 (MET) Received: by myster.frmy.bull.fr; Tue, 16 Aug 94 15:42:38 +0200 (MET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "C.DEIGNAN" Message-Id: <9408161342.AA18114@myster.frmy.bull.fr> Subject: Info on RFC1006 implementations To: osi-ds <@kheops.bull.fr:osi-ds@cs.ucl.ac.uk> Date: Tue, 16 Aug 94 11:39:24 EET X-Mailer: ELM [version 2.3 PL8] X-Orig-Sender: C.Deignan@frmy.bull.fr Hi Everybody, This may be a bit of a silly question, and this is probably the wrong list to ask it on, but I "Need to Know"... A friend is writing an article about RFC1006 (OSI Transport Class 0 on top of TCP/IP), and while the name of Bull is undoubtedly going to appear, it is necessary to mention other constructors. So the question is : what implementations of RFC1006 exist? Is there an implementation inside 'osi-ds'? Are there any others? Can anyone confirm that Siemens has one? Thanks for any info Ciaran +------------------------------------------------------------------------------+ Ciaran Deignan Tel: (France) (1) 69 93 86 65 BULL SA Telecom Introduction (OSS/XS/PMU/ATS/NSTI) Office: H2 012 Bullcom: 223 86 65 Mail to: K2 036 Fax: 223 84 74 +------------------------------------------------------------------------------+ """ [o o] * \_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04885; 17 Aug 94 10:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04881; 17 Aug 94 10:26 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id ab07099; 17 Aug 94 10:26 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 17 Aug 1994 13:24:34 +0100 Received: from gwx400a.bull.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 17 Aug 1994 13:24:03 +0100 Received: from khephren.bull.fr (gwx400b.bull.fr) by kheops.bull.fr; Wed, 17 Aug 1994 14:17:20 +0200 (MET) Received: from mybull.frmy.bull.fr by khephren.bull.fr; Wed, 17 Aug 1994 12:34:07 +0200 (MET) Received: from myster.frmy.bull.fr ([129.185.216.88]) by mybull.frmy.bull.fr; Tue, 16 Aug 1994 12:32:12 +0200 (MET) Received: by myster.frmy.bull.fr; Tue, 16 Aug 94 11:39:25 +0200 (MET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "C.DEIGNAN" Message-Id: <9408160939.AA28246@myster.frmy.bull.fr> Subject: Info on RFC1006 implementations To: osi-ds <@kheops.bull.fr:osi-ds@cs.ucl.ac.uk> Date: Tue, 16 Aug 94 11:39:24 EET X-Mailer: ELM [version 2.3 PL8] Hi Everybody, This may be a bit of a silly question, and this is probably the wrong list to ask it on, but I "Need to Know"... A friend is writing an article about RFC1006 (OSI Transport Class 0 on top of TCP/IP), and while the name of Bull is undoubtedly going to appear, it is necessary to mention other constructors. So the question is : what implementations of RFC1006 exist? Is there an implementation inside 'osi-ds'? Are there any others? Can anyone confirm that Siemens has one? Thanks for any info Ciaran +------------------------------------------------------------------------------+ Ciaran Deignan Tel: (France) (1) 69 93 86 65 BULL SA Telecom Introduction (OSS/XS/PMU/ATS/NSTI) Office: H2 012 Bullcom: 223 86 65 Mail to: K2 036 Fax: 223 84 74 +------------------------------------------------------------------------------+ """ [o o] * \_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04907; 17 Aug 94 10:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04899; 17 Aug 94 10:26 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id ad07099; 17 Aug 94 10:26 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 17 Aug 1994 13:50:56 +0100 Date: Wed, 17 Aug 1994 13:50:56 +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.251:17.07.94.12.50.56] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Wed, 17 Aug 1994 13:50:56 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <"lancaster.ne:017992:940817125033*/I=a/S=shepherd/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> To: "(C.DEIGNAN)" Cc: osi-ds In-Reply-To: <9408160939.AA28246@myster.frmy.bull.fr> Subject: Re: Info on RFC1006 implementations Discarded-X400-IPMS-Extensions: iso (1) memberBody (2) gb (826) (0) (1004) (10) (1) (1) > > > > > Hi Everybody, > > This may be a bit of a silly question, and this is probably the wrong > list to ask it on, but I "Need to Know"... > > A friend is writing an article about RFC1006 (OSI Transport Class 0 on > top of TCP/IP), and while the name of Bull is undoubtedly going to > appear, it is necessary to mention other constructors. > > So the question is : what implementations of RFC1006 exist? > > Is there an implementation inside 'osi-ds'? Are there any others? > Can anyone confirm that Siemens has one? > > > Thanks for any info > > Ciaran > NEXOR use an OSI stack which may be configured to run on top of several networks and includes RFC1006 support for running on top of TCP/IP. All NEXOR OSI products may take advantage of this to use TCP/IP protocols for network communication. Products include both X.500 and X.400 systems. NEXOR supported operating systems include SUN OS 4, Solaris, HP UX, IBM AIX, SCO Unix, Data General (DGUX), and ICL DRS. Alan Shepherd ------------------------------------------------------------ Alan Shepherd, NEXOR, P.O. Box 132, Nottingham NG7 2UU. Phone: +44 (0) 602 520582 (Fax:520519) 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 aa04923; 17 Aug 94 10:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04918; 17 Aug 94 10:27 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07120; 17 Aug 94 10:27 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 17 Aug 1994 14:46:16 +0100 Via: uk.ac.nsfnet-relay; Wed, 17 Aug 1994 14:46:10 +0100 Via: uk.ac.ulcc.pluto; Wed, 17 Aug 1994 14:46:10 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Furniss Message-Id: <10386.199408171346@pluto.ulcc.ac.uk> Subject: Re: Info on RFC1006 implementations To: osi-ds@cs.ucl.ac.uk Date: Wed, 17 Aug 1994 14:45:41 +0100 (BST) Reply-to: P.Furniss@ulcc.ac.uk X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1291 Ciaran Deignan sent: > A friend is writing an article about RFC1006 (OSI Transport Class 0 on > top of TCP/IP), and while the name of Bull is undoubtedly going to > appear, it is necessary to mention other constructors. > > So the question is : what implementations of RFC1006 exist? I know it is implemented under the XTI interface in the Digital products for Ultrix and OSF on the Alpha, and in the newer releases of HP's XTI. It believe ICL offer it too. Your friend might like to mention that there are number of corrupt versions of the text of RFC1006 around (including the one in the cs.ucl.ac.uk archive). I think all the official shadows (as listed in the rfc announcements) have the correct text. There have been at least 5 different texts on the network. Your friend might also mention that the assertion that there is a limit to the TSDU size (of 7 octets less than the TPDU size) is incorrect. (Marshall agreed that the sentence should be deleted, though he may not remember a corridor conversation in Houston). (XTI has an ability to report the maximum TSDU size is - some of the implementations report this spurious limit, but do not (fortunately) enforce it. ) I have reported this error to the Transport Area Director, but she has been a bit busy. Peter Furniss   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00474; 19 Aug 94 4:09 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00470; 19 Aug 94 4:09 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01049; 19 Aug 94 4:09 EDT X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 19 Aug 1994 08:21:47 +0100 Date: Fri, 19 Aug 1994 08:21:47 +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.875:19.07.94.07.21.47] Priority: Non-Urgent DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Fri, 19 Aug 1994 08:21:47 +0100; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Shepherd Message-ID: <20170.777280871@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/osi/x500/graphroot.gif" Probing from SWITCH@Zurich, NEXOR, ULCC, Cambridge Computer Lab, Community: internet ========== ======== No DSAs had 100.00% availability. Other DSAs: ----- ----- %Avail Organisation,DSA Attempts ------ ---------------- -------- 99.60 Vrije Universiteit Brussel, Woolly Spider Monkey 249 1 Connection refused 99.60 SUNET, Hummingbird 494 2 Timed out after 60 seconds 99.59 SWITCH, Condor 493 2 Timed out after 60 seconds 99.19 Brussels University, Red Titi Monkey 494 2 Timed out after 60 seconds 2 Unavailable 98.99 FUNET, Northern Pudu 494 1 Host is unreachable 4 Timed out after 60 seconds 98.79 Tallinn Technical University, saki 494 6 Timed out after 60 seconds 98.79 Matej Bel University, UAKOM UMB Banska Bystrica, Tarpon 494 3 Host is unreachable 3 Timed out after 60 seconds 98.58 Technische Universitaet Chemnitz-Zwickau, Puma 494 7 Timed out after 60 seconds 98.18 Restena, Guppy 494 9 Timed out after 60 seconds 97.98 Unknown Organisation, Dorcan Gazelle 494 10 Timed out after 60 seconds 97.77 UNINETT, Electric Eel 494 4 Connection refused 3 Host is unreachable 4 Timed out after 60 seconds 97.57 Unknown Organisation, Corncrake 494 9 Host is unreachable 3 Timed out after 60 seconds 97.57 U.S. DMD, Pied Tamarin 494 7 Timed out after 60 seconds 3 Connection refused 2 Host is unreachable 97.57 WIDE project, Sloth 494 3 Host is unreachable 9 Timed out after 60 seconds 96.96 Moscow State University, Bear 494 9 Host is unreachable 6 Timed out after 60 seconds 96.96 UNINETT, Boa Constrictor 494 7 Timed out after 60 seconds 1 Host is unreachable 7 Connection refused 96.96 NEXOR Ltd, Vampire Bat 494 7 Connection refused 1 Host is unreachable 7 Timed out after 60 seconds 96.76 Unknown Organisation, opaxdsa, CNRS, FR 494 11 Connection refused 5 Timed out after 60 seconds 96.76 Computer and Automation Institute, Guinea Pig 494 6 Connection refused 4 Host is unreachable 6 Timed out after 60 seconds 96.76 Universitaet Wien, Rockhopper Penguin 494 13 Timed out after 60 seconds 3 Host is unreachable 96.56 U.S. DMD, Fruit Bat 494 7 Timed out after 60 seconds 8 Connection refused 2 Host is unreachable 96.36 Prague University of Economics, Woolly Opossum 494 18 Timed out after 60 seconds 96.15 DKUUG, Axolotl 494 13 Host is unreachable 1 Connection refused 5 Timed out after 60 seconds 95.95 SWITCH, Chinchilla 494 1 Connection refused 19 Timed out after 60 seconds 95.55 DFN, Margay 494 8 Host is unreachable 13 Timed out after 60 seconds 1 Connection refused 94.33 RCCN Portugal, Zebu 494 28 Timed out after 60 seconds 92.91 Australian Academic and Research Network, Anaconda 494 5 Host is unreachable 28 Timed out after 60 seconds 2 Network is unreachable 92.51 Australian Academic and Research Network (AARNet), Bush Dog 494 5 Host is unreachable 20 Timed out after 60 seconds 4 Unavailable 6 Network is unreachable 2 Connection refused 91.70 GARR-NIS, Black Widow 494 41 Timed out after 60 seconds 91.70 UMK, Ocelot 494 25 Host is unreachable 16 Timed out after 60 seconds 90.96 ULCC, Ocellated Turkey 498 45 Connection refused 89.27 GARR-NIS, Black Widow 494 33 Timed out after 60 seconds 20 Host is unreachable 87.45 ARNES, Proteus 494 8 Timed out after 60 seconds 53 Host is unreachable 1 Connection refused 86.84 GB Master DSA, inca dove 494 62 Connection refused 3 Timed out after 60 seconds 86.44 Technische Universiteit Delft, Hornero 494 55 Connection refused 10 Unavailable 2 Timed out after 60 seconds 86.06 SURIS, Elephant Seal 495 34 Invalid credentials 18 Timed out after 60 seconds 2 Host is unreachable 15 Connection refused 85.63 DENet, Armadillo 494 16 Timed out after 60 seconds 48 Connection refused 7 Host is unreachable 79.12 RedIRIS, iguana 498 34 Connection refused 40 Host is unreachable 28 Timed out after 60 seconds 76.52 Trinity College Dublin, Irish Elk 494 11 Host is unreachable 93 Connection refused 12 Timed out after 60 seconds 76.32 Root of the World, Giant Tortoise 494 116 Connection refused 1 Timed out after 60 seconds 75.91 NSTN Inc, beluga whale 494 57 Timed out after 60 seconds 61 Connection refused 1 Host is unreachable 75.51 U.S. DMD, Alpaca 494 117 Connection refused 3 Timed out after 60 seconds 1 Host is unreachable 73.08 Foundation Of Research and Technology Hellas, Caretta Caretta 494 39 Timed out after 60 seconds 93 Connection refused 1 Host is unreachable 67.00 Victoria University of Wellington, Kakapo 494 5 Host is unreachable 151 Connection refused 6 Timed out after 60 seconds 1 Network is unreachable 50.40 North Atlantic Treaty Organization, Violaceous Trogon 494 20 Timed out after 60 seconds 148 Connection refused 77 Host is unreachable 49.60 Unknown Organisation, Andean Cat 498 251 Timed out after 60 seconds 31.17 FUNET, Jaguar 494 335 Connection refused 2 Host is unreachable 3 Timed out after 60 seconds 13.25 IIT Delhi, IN, Pelican 498 167 Host is unreachable 40 Timed out after 60 seconds 13 Connection refused 5 Invalid credentials 9.84 Universidad Politecnica de Madrid, Cayman 498 374 Connection refused 38 Timed out after 60 seconds 37 Host is unreachable 8.84 Universidade Federal do Rio Grande do Sul (UFRGS), paca 498 359 Connection refused 10 Host is unreachable 32 Timed out after 60 seconds 0.00 SWITCH, Condor 1 1 Unavailable *** (not expecting connection for tsap/"" 0.00 Master DSA of KOREA, Darter 494 466 Connection refused 20 Timed out after 60 seconds 4 Host is unreachable 4 Network is unreachable 0.00 Inmarsat, Hedgehog 494 420 Connection refused 74 Timed out after 60 seconds 0.00 Bell-Northern Research, Pangolin 494 492 Connection refused 1 Timed out after 60 seconds 1 Host is unreachable 0.00 University of Zagreb - Faculty of Electrical Engineering, Roufous Motmot 494 489 Timed out after 60 seconds 5 Host is unreachable 0.00 Nanyang Technological University, Silk Spider 494 470 Connection refused 5 Timed out after 60 seconds 12 Host is unreachable   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04763; 19 Aug 94 10:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04759; 19 Aug 94 10:28 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07891; 19 Aug 94 10:28 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Aug 1994 14:37:47 +0100 Received: from gateway.mitre.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 19 Aug 1994 14:37:38 +0100 Return-Path: Received: from cutter.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA13748; Fri, 19 Aug 94 09:37:29 -0400 Date: Fri, 19 Aug 94 09:37:29 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ella P. Gardner" Full-Name: Ella P. Gardner Message-Id: <9408191337.AA13748@gateway.mitre.org> To: dssig@nist.gov Subject: ISPs/1993 Cc: epg@gateway.mitre.org, osi-ds@cs.ucl.ac.uk Here is a proposal, which Erik Andersen gave me at Southampton. We need to add consideration of it and preparation of our answer to our agenda next month. Ella ------------------------------------------ EWOS/EGDIR/94/N32 Title: ETSI TE.6/EWOS EGDIR proposal for taxonomy for the 1993 edition of the Directory Specifications To: AOW DIR-SIG OIW DIR-SIG EWOS/TA for approval Source: ETSI TE.6/EWOS EGDIR (Editor: Erik Andersen) Date: August 19, 1994 Status: This is the output of the ETSI TE.6/EWOS EGDIR June 27 - July 1, 1994 meeting. This document contains the proposal of the EWOS/ETSI group for the taxonomy for the 1993 edi-tion of the Directory Specifications. The ISPs developed for the 1988 edition of the Directory Specification will be current in parallel with the ISPs for the 1993 edition. There should therefore be no overlap between taxonomy identi-fiers for the two editions. The taxonomy identifiers as shown in this document should therefore be changed in co-operation with SGFS to avoid such an overlap. ADX and FDX are used as temporary identifier. They should be replace with whatever is assigned by SGFS. ADX1 - DUA Basic Functionality This class of profiles defines the basic behaviour of a DUA in its communication with a DSA. It does not define the DUAs interaction with the user. ADX11: DUA support of Directory Access Protocol This profile defines the behaviour of a DUA regarding the operation of the Direc-tory Access Protocol (DAP). ADX12: DUA support of Distributed Operations This profile defines the behaviour of a DUA when performing multiple interac-tions with multiple DSAs to perform a single user request. ADX2 - DSA Basic Functionality This class of profiles defines the basic behaviour of a DSA in its communication with DUAs and other DSAs. ADX21: DSA support of Directory Access This profile defines the behaviour of a DSA regarding the operation of the Direc-tory Access Protocol (DAP) when communicating with a DUA. ADX22: DSA support of Distributed Operations This profile defines the behaviour of a DSA regarding the operation of the Di-rectory Sys-tem Protocol (DSP) when communicating with another DSA, and it defines the co-or-dination of a DSA communication across several associations to perform a particu-lar distributed op-eration. ADX4 - Security Capabilities ADX41: DUA Authentication as DAP initiator This profile covers DUA specific use of authentication beyond simple unprotected password and includes use of different levels of authentication, and the use of different security infrastructures, e.g., support of hierarchical/non-hierarchical CA-structures. In addition, it covers actions by the DUA on handling (i.e., validating or not) creden-tials returned by the DSA, the use of two-way strong authentication and signed opera-tions. ADX42: DSA Authentication as DAP responder This profile covers DSA specific use of authentication beyond simple unprotected password in its communication with a DUA and includes use of different levels of authentication, and the use of different security infrastructures, e.g., support of hierar-chical/non-hierarchical CA- structures. In addition, it covers actions by the DSA on handling (i.e., validating or not) credentials sent by the DUA, the use of two-way strong authentication, procedures for distributed authenti-cation, and signed opera-tions. ADX43: DSA Authentication for DSP This profile covers the use of authentication beyond simple unprotected password for the pur-pose of mutual authentication of DSAs. It includes use of 2 x one way-strong authentication, two-way strong authentication and the use of the protocol elements (certification-path, user Certificate), (certification-path, the CA Certificates [I], for- ward) and (certification-path, the CA Certificates [I], reverse). It also includes signed DSP operations. ADX44: DSA Simple Access Control This profile covers support of Access Control Specific Administrative Areas, support of Protected Item categories, support of User Classes, and support of GrantAndDenials facilities as defined in subentries. ADX45: DSA Basic Access Control This profile covers support of Access Control Specific Administrative Areas and Inner Administrative Areas, support of Protected Item categories, support of User Classes, and support of GrantAndDenials facilities as defined in subentries as defined in suben-tries and/or entries. ADX5 - Shadowing Capabilities This class of profiles covers the protocol and functional aspects related to Directory shadowing. Op-erational and procedural aspects are covered in ADX22 and ADX62. ADX51: Shadowing using ROSE This profile covers Directory protocol aspects related to shadowing when operating over ROSE only. Both the consumer and supplier roles and the 'push' and 'pull' mod-els are cov-ered. In addition, error handling and recovery capabilities are also profiled. ADX52: Shadowing using RTSE This profile covers Directory protocol aspects related to shadowing when operating over RTSE. Both the consumer and supplier roles and the 'push' and 'pull' models are cov-ered. In addition, error handling and recovery capabilities are also profiled. ADX53: Shadowing subset This profile defines incremental set of Directory shadowing capabilities that can be pro-vided by a DSA implementation. These functional capabilities are related specifi-cally to the level of refinement supported for the definition of a unit of replication. The capabil-ity to support overlapped units of replications is also incorporated. ADX6 - Directory Administration and Management This class of profiles is aimed at regulating the policies and procedures that administrations have to be able to make the Directory work smoothly in its environment. This is achieved by de-scribing the various subjects for co- ordination within and between administrative areas and methods for the co-ordination based on derived policies. ADX61: Administrative areas This profile describes how administrative areas should set up and subdivided into manage-able portions, and ways in which the operation of the Directory and of the administrative areas are optimised through co-ordination of knowledge dis- tribution, authen-tication and access control policies, distribution of naming contexts, etc. The use of quality requirements and resulting policies shall be the basis for the co-ordina-tion proce-dures. Interaction with Directory users and information providers may also be described. ADX62: Establishment and utilisation of shadowing agreements This profile describes how the initial phase of establishing a shadowing agreement should be conducted for smooth introduction and utilisation of the shadowing itself, and in addi-tion how the organisational management of such agreements should be conducted, up and including their dissolution. ADX63: Schema administration and publication To allow smooth interworking between directory systems in different administra-tive areas, there has to be mechanism for informing others about the schema rules in use. For this to be possible, an administrative area has to administrate and publish its schema in some way. This item describes how this may be done in a regulated way. ADX7 - DOP Capabilities This class of profiles specifies the capabilities of a DSA for the optional Directory Operational Bind-ing Management Protocol (DOP) facility. DOP may be used to manage operational bindings as de-fined in ISO/IEC 9592-2 | ITU Rec. X.501. ADX71: Shadowing Operational Binding This profile specifies how DOP is used to establish, modify and terminate shadow ope-ra-tional bindings as defined in ISO/IEC 9594-9 | ITU Rec. X.525. Shadow operational bindings are an optional DSA feature used to manage the standardised aspects of shad-owing agreements. ADX72: Hierarchical Operational Binding This profile specifies how DOP is used to establish, modify and terminate hierar-chical operational bindings as defined in ISO/IEC 9594-4 | ITU Rec. X.518. Hi-erarchical op-erational bindings are an optional DSA feature used to manage the relationship and promulgate relevant information between two master DSAs holding naming contexts, one of which is immediately subordinate to the other, in which the superior DSA holds a subordinate reference to the subordinate DSA. ADX73: Non-specific Hierarchical Operational Binding This profile specifies how DOP is used to establish, modify and terminate non-specific hierarchical operational bindings as defined in ISO/IEC 9594-4 | ITU Rec. X.518. Non-specific hierarchical operational bindings are an optional DSA feature used to manage the relationship and promulgate relevant information be-tween two master DSAs holding naming contexts, one of which is immediately subordinate to the other, in which the su-perior DSA holds a non-specific subordi-nate reference to the subordi-nate DSA. FDX1 Schema FDX11: CommonJDirectoryJUse This profile covers information to be stored within the Directory that is common to a variety of applications. It specifies requirements that are applicable to implemen-ta-tions of DSAs. Additionally, these requirements may guide Directory users and ad-ministrative authorities in defining their needs for the use of the Directory. This pro-file defines the minimum capabilities that a DSA shall have to support. It does that by specifying minimum set of object classes, attribute types, name forms, structure rules, matching rules and collective attributes to be supported. FDX12: Directory system schema This profile covers information a DSA shall hold to operate properly. It includes sup-port of schema for the administrative and operational information model, schema for access control, and schema for collective attributes. It also includes consistency re-quirement among the different specifications.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05619; 22 Aug 94 12:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05615; 22 Aug 94 12:28 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa09282; 22 Aug 94 12:28 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Aug 1994 16:39:11 +0100 Received: from nic.ott.hookup.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 22 Aug 1994 16:39:03 +0100 Received: (brw@localhost) by nic.ott.hookup.net (8.6.9/1.28) id LAA07149; Mon, 22 Aug 1994 11:38:50 -0400 Date: Mon, 22 Aug 1994 11:16:00 -400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Williams Subject: Macisode-Runtime decompression To: osi-ds@cs.ucl.ac.uk cc: brw@hookup.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have retrieved macisode-runtime.sit and macisode-runtime.sit.Z from a couple of sources but have been unsuccessful in decompressing the files. Unix decompress works on the .Z files, leaving the .sit files, however I've had no no success beyond that. I assume from the .sit suffix that the compression software was Stuffit, yet Stuffit Deluxe (the most current version thereof, I believe) reports the archive to be damaged and unexpandable (I had assumed that my first attempt indicated a possible corruption during file transfer, the second copy from the same source resulted in the same failure. Retrieval of both the ..sit and ...sit.Z from another source provided files that produced the same results.) I assume that the software held within the archive is a Mac-based version of QUIPU. I'd like to experiment with it. Although I have all the tools, I'd rather not attempt to compile the applications from the available source code, hence my desire to secure the runtime version. I'd appreciate any guidance that can be offered. Have I made an erroneous assumption regarding the archival software? Is there an uncompressed version of the s/w available anywhere on the net? Other suggestions? Regards, Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08825; 22 Aug 94 16:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08821; 22 Aug 94 16:42 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa15569; 22 Aug 94 16:42 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Aug 1994 20:52:00 +0100 Received: from x400gate.bnr.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 22 Aug 1994 20:51:46 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 22 Aug 1994 15:49:54 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 22 Aug 1994 13:43:26 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 22 Aug 1994 13:10:00 -0400 Date: Mon, 22 Aug 1994 13:10: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/;bcars735.b.383:22.07.94.17.43.26] X400-Content-Type: P2-1984 (2) Content-Identifier: Warning: sbrk... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "peter (p.w.) whittaker" X-Orig-Sender: "peter (p.w.) whittaker" Message-ID: <"8367 Mon Aug 22 13:49:14 1994"@bnr.ca> To: osi-ds@cs.ucl.ac.uk, quipu@cs.ucl.ac.uk, info@isode.com Subject: Warning: sbrk() and QUIPU problems under HP-UX 9.03+. The QUIPU DSA uses "sbrk()" to track memeory usage; in some cases, an unsigned int is set to the value returned by sbrk(), viz size = (unsinged int) sbrk(0); On many platforms, this works fine, as sbrk() returns a caddr_t; on Ultrix and MIPS machines, there are known problems with this, as evidenced by the #ifdefs in the DSA code (see dsa.c). Add another known problem: under HP-UX 9.03, sbrk returns "void *", and, according to the man page, one should be wary of using this pointer, as it is not guaranteed to be word aligned, etc. We noticed this when our HP-UX DSA began crashing regularly, while reporting a stop size of 1074937856 bytes! We barely have that much disk, let alone SIMMs and swap! pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] NT Secure Networks pww@bnr.ca [ ] P.O. Box 3511, Station C Ph: +1 613 765 2064 [ ] Ottawa FAX:+1 613 765 3520 [__________________________] K1Y 4H7   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05924; 24 Aug 94 12:44 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05920; 24 Aug 94 12:44 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa11642; 24 Aug 94 12:44 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Aug 1994 14:38:22 +0100 Received: from sapling.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 24 Aug 1994 14:38:11 +0100 X400-Received: by mta sapling.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 24 Aug 1994 15:37:51 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 24 Aug 1994 15:36:55 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 24 Aug 1994 15:36:53 +0200 Date: Wed, 24 Aug 1994 15:36:53 +0200 X400-Originator: Erik.Huizer@SURFnet.nl X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;survis.surfn:103820:940824133655] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Booklet: ... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" Message-ID: <"10385 Wed Aug 24 15:37:02 1994"@surfnet.nl> To: admin@surfnet.nl Cc: osi-ds@cs.ucl.ac.uk, directory-group@jnt.ac.uk, punters@paradise.ulcc.ac.uk, quipu@cs.ucl.ac.uk In-Reply-To: <"5872 Tue Aug 16 09:21:28 1994"@surfnet.nl> Subject: Re: Booklet: "Building a Directory Service" Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 The response you gave was kinda overwhelming. In one week we send out a little over 800 booklets to about 500 people. Since you all responded so favorably I have a request to make. It would be usefull for me to get response from you on the usefullness and quality of the booklet. A short reaction on this by E-mail (to me, not to the lists!) would be appreciated. I will assemble the reactions and present them to our funders to aid them in evaluating the quality of the project deliverables. So if you can spare the time please summarise the usefullness and other comments on the booklet and forward it to me: huizer@surfnet.nl, with subjectline: Re: Booklet: "Building a Directory Service" We will also use the comments to improve and extend the booklet and publish a new version next year. Thanks, Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00985; 26 Aug 94 6:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00981; 26 Aug 94 6:22 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa02793; 26 Aug 94 6:22 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Aug 1994 10:35:15 +0100 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Aug 1994 10:35:09 +0100 Return-Path: Received: from nlc-bnc.ca by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 25 Aug 1994 20:38:11 +0100 Received: from its.nlc-bnc.ca (lanmail.nlc-bnc.ca) by NLC-BNC.CA (PMDF V4.3-7 #4756) id <01HGBXUU8GR40002XV@NLC-BNC.CA>; Thu, 25 Aug 1994 15:36:25 EDT Received: by its.nlc-bnc.ca with Microsoft Mail id <2E5D1E1E@its.nlc-bnc.ca>; Thu, 25 Aug 94 15:41:34 PDT Date: Thu, 25 Aug 1994 15:38:00 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kuny Terry Subject: Re: Booklet: "Building a Directory Service" To: osi-ds-request Message-id: <2E5D1E1E@its.nlc-bnc.ca> X-Mailer: Microsoft Mail V3.0 Content-transfer-encoding: 7BIT Encoding: 57 TEXT Resent-To: osi-ds@cs.ucl.ac.uk Resent-Date: Fri, 26 Aug 94 10:35:06 +0100 Resent-Message-ID: <19232.777893706@cs.ucl.ac.uk> Resent-From: Postmaster@cs.ucl.ac.uk Hello Erik, I enjoyed meeting you and the other IETFers in Toronto. It was a *very* interesting experience and I am hoping that I'll be able to contribute in some way in the near future. As per your request for comments about the booklet you have sent us, the following: As the Government of Canada and its various departments is beginning to implement X.500 services, your publication is timely and important. By publicizing the experiences and recommendations of SURFnet in setting up X.500 services, you have provided the entire networking community with a valuable learning opportunity. "Building a Directory Service" is a well-written, concise and yet comprehensive overview that is all too rare among technical publications. I look forward to distributing this document widely within my organization and hope that the lessons you have learned will provide officials here with insights into how we can provide effective X.500 services in the future. I hope you are able to continue to provide quality materials such as this booklet to the networking community in the future. Regards, Terry Kuny Information Technology Services National Library of Canada > >The response you gave was kinda overwhelming. In one week we send out a >little over 800 booklets to about 500 people. > >Since you all responded so favorably I have a request to make. It would be >usefull for me to get response from you on the usefullness and quality of >the booklet. A short reaction on this by E-mail (to me, not to the lists!) >would be appreciated. I will assemble the reactions and present them to our >funders to aid them in evaluating the quality of the project deliverables. > >So if you can spare the time please summarise the usefullness and other >comments on the booklet and forward it to me: huizer@surfnet.nl, with >subjectline: Re: Booklet: "Building a Directory Service" > > >We will also use the comments to improve and extend the booklet and publish >a new version next year. > >Thanks, >Erik > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02417; 26 Aug 94 11:59 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02413; 26 Aug 94 11:59 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10073; 26 Aug 94 12:00 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Aug 1994 16:09:55 +0100 Received: from gwx400a.bull.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 26 Aug 1994 16:09:41 +0100 Received: from mybull.frmy.bull.fr by kheops.bull.fr; Fri, 26 Aug 1994 17:02:29 +0200 (MET) Received: from myster.frmy.bull.fr by mybull.frmy.bull.fr; Fri, 26 Aug 1994 17:03:32 +0200 (MET) Received: by myster.frmy.bull.fr; Fri, 26 Aug 94 17:09:03 +0200 (MET) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "C.DEIGNAN" Message-Id: <9408261509.AA11903@myster.frmy.bull.fr> Subject: RFC1006 summary To: osi-ds <@kheops.bull.fr:osi-ds@cs.ucl.ac.uk> Date: Fri, 26 Aug 94 17:09:02 EET X-Mailer: ELM [version 2.3 PL8] Hello Everyone, I'm sorry about the 6 copies of my question that everybody received. I was a bit scared of sending a summary of the answers in case it got multiplied into a nuisance. However someone requested it for themselves, so I'm sending the summary to everyone. The results: ISO/DE does indeed have an RFC1006 component NEXOR use an OSI stack which includes RFC1006 (offered on a range of UNIX? operating systems) Digital's XTI offers RFC1006 functions. SNI - (Siemens Nixdorf International?) can use RFC with its X400 product and with XTI. UCOM.X range of products of Telesystemes-E3X include an OSI stack with support for RFC-1006. Someone mentioned HP and ICL as "possibles" .... Oh, and BULL, of course. Works with the OSI stack for AIX 3 and 4. All the "pure" OSI applications and all the APIs can use it. 'Till next time Ciaran +------------------------------------------------------------------------------+ Ciaran Deignan Tel: (France) (1) 69 93 86 65 BULL SA Telecom Introduction (OSS/XS/PMU/ATS/NSTI) Office: H2 012 Bullcom: 223 86 65 Mail to: K2 036 Fax: 223 84 74 +------------------------------------------------------------------------------+ """ [o o] * \_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06307; 29 Aug 94 15:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06303; 29 Aug 94 15:00 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01535; 29 Aug 94 15:00 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Mon, 29 Aug 1994 18:49:01 +0100 Received: from nic.cerf.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 29 Aug 1994 18:48:50 +0100 Received: (from amintel@localhost) by nic.cerf.net (8.6.8/8.6.6) id KAA12738 for osi-ds@cs.ucl.ac.uk; Mon, 29 Aug 1994 10:48:43 -0700 Date: Mon, 29 Aug 1994 10:48:43 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Christopher Green Message-Id: <199408291748.KAA12738@nic.cerf.net> To: osi-ds@cs.ucl.ac.uk Subject: subscribe subscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11170; 31 Aug 94 17:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11166; 31 Aug 94 17:32 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa16890; 31 Aug 94 17:32 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 31 Aug 1994 21:50:34 +0100 Received: from bcvax1.bc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 31 Aug 1994 21:50:22 +0100 Received: from bcvms.bc.edu by bcvms.bc.edu (PMDF V4.3-9 #7102) id <01HGKDNE27IO8WZILP@bcvms.bc.edu>; Wed, 31 Aug 1994 16:50:59 -0400 (EDT) Date: Wed, 31 Aug 1994 16:50:59 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: EILEEN@bcvms.bc.edu Subject: need helping putting photo in directory To: quipu@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk Reply-to: eileen@bcvms.bc.edu Message-id: <01HGKDNE5YK28WZILP@bcvms.bc.edu> X-VMS-To: 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 We are experimenting with putting jpeg photos in our x.500 database. I have the following in my entry: jpegPhoto= {FILE}/usr/users/eileen/mypic When I start the DSA, I get the following error in dsap.log: Overflow in ID in attribute file '/usr/users/eileen/mypic'. Any ideas on what I am doing wrong? Thanks. Eileen Shepard Boston College   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13895; 31 Aug 94 21:04 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13891; 31 Aug 94 21:04 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa20460; 31 Aug 94 21:04 EDT Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Sep 1994 01:10:50 +0100 Received: from lupine.nsi.nasa.gov by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 1 Sep 1994 01:10:41 +0100 Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.9/8.6.9) id UAA12652; Wed, 31 Aug 1994 20:07:29 -0400 Date: Wed, 31 Aug 1994 20:07:26 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael C. Newell" Subject: Re: need helping putting photo in directory To: EILEEN@bcvms.bc.edu cc: quipu@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk In-Reply-To: <01HGKDNE5YK28WZILP@bcvms.bc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 31 Aug 1994 EILEEN@bcvms.bc.edu wrote: > We are experimenting with putting jpeg photos in our x.500 database. I have the > following in my entry: > > jpegPhoto= {FILE}/usr/users/eileen/mypic > > When I start the DSA, I get the following error in dsap.log: > > Overflow in ID in attribute file '/usr/users/eileen/mypic'. > > Any ideas on what I am doing wrong? > You have to ASN wrap the JPEG file; I think the command is "jpeg2asn"?? It's been a while... :{) Thanks, Mike +--------------------------------------+------------------------------------+ |Mike Newell | The opinions expressed herein are | |NASA Science Internet Network Systems | my own, and do not necessarily | |Sterling Software, Inc. | reflect those of the NSI program, | |MNewell@nsipo.nasa.gov | Sterling Software, NASA, or anyone | |+1-202-434-8954 | else. | +--------------------------------------+------------------------------------+