Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29500-0@bells.cs.ucl.ac.uk>; Fri, 5 Oct 1990 17:04:46 +0100 To: ietf-osi-ds@uk.ac.ucl.cs Subject: The OSI-DS group Phone: +44-71-380-7294 Date: Fri, 05 Oct 90 17:04:46 +0100 Message-ID: <1831.655142686@UK.AC.UCL.CS> From: Steve Kille I've been gradually adding people to the list, and have been very pleased with the large amount of interest. In the next messages, I'll be sending out: - Agenda for meeting (and exact location) - Revised Scope of group - Group charter (derived from the scope to follow IETF guidelines) - Some information on obtaining a few relevent background docuemnts Looking forward to meeting you all in San Jose. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29564-0@bells.cs.ucl.ac.uk>; Fri, 5 Oct 1990 17:06:24 +0100 To: ietf-osi-ds@uk.ac.ucl.cs Subject: Charter Phone: +44-71-380-7294 Date: Fri, 05 Oct 90 17:06:21 +0100 Message-ID: <1850.655142781@UK.AC.UCL.CS> From: Steve Kille OSI X.500 (osix500) Charter Chair: Steve Kille, S.Kille@cs.ucl.ac.uk Mailing Lists: General Discussion: ietf-osi-ds@cs.ucl.ac.uk To Subscribe: ietf-osi-ds-request@cs.ucl.ac.uk Description of Working Group: This document suggests an initial scope for the IETF OSI Directory Services Working Group (OSI-DS). Brief summary of group: to be supplied after detailed suggestions have been discussed. Timeframe: need to add some timeframes and tighten objectives. Most of this is appropriate for the first meeting. Goals and Milestones: TBD X.500 does not have sufficient functionality for full deployment on the Internet. This group should identify areas where extensions are required, in co-ordination with ongoing standardisation activity. TBD The directory can be used to support a wide range of applications. It is necessary to evaluate which are important for the Internet, and what level of priority they should be given within the community. White Pages type of application is likely to be given a high priority. TBD A Schema (Naming Architecture) should be defined for the Internet. A requirement for a schema should be defined, and inputs evaluated. Various approaches to specification of Schema from a user and system standpoint should be considered, including update mechanisms. TBD There is a requirement for representation of Directory Names, as these will need to be communicated ``out of band''. An Internet approach to this should be defined. Ongoing Liaisons should be established as appropriate. In particular: RARE WG3, To harmonise work with European activities; NIST, To co-ordinate with the Directory SIG; CCITT/ ISO/IEC, To co-ordinate with ongoing standardisation. 1   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29685-0@bells.cs.ucl.ac.uk>; Fri, 5 Oct 1990 17:11:06 +0100 To: ietf-osi-ds@uk.ac.ucl.cs Subject: Background reading Phone: +44-71-380-7294 Date: Fri, 05 Oct 90 17:11:04 +0100 Message-ID: <1860.655143064@UK.AC.UCL.CS> From: Steve Kille I append information on how to get some documents which may be of interest. The ones which are relevant to the meeting are: THORN and RARE Naming Architecture - this is being revised substantially in light of piloting expereience, but this is not going to be available before the meeting (apologies) Using the OSI Directory to achieve User Friendly Naming Domains and X.500 (also available as an Internet Draft) Steve *********** The following topics may be obtained from the info-server using a request in the form: request: thorn topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: ANything you like request: thorn topic: thorn-na.txt The files are also available by NIFTP and FTAM. -------------------------------------------------- "The THORN System Naming Architecture" THORN Note UCL-63.2 UCL Research Note RN/89/48 June 1989 S.E.Kille (Editor) Abstract: This document contains the THORN System Naming Architecture for X.500. Along with a companion document on the THORN and RARE Naming architecture [UCL-64], this document obsoletes the earlier THORN Naming Architecture [UCL-45]. This document contains naming aspects specific to the THORN implementation, and also defines mappings from the earlier THORN TR 32 bases system. This document should be read as a part of the overall THORN Design. In particular, the THORN General Architecture and External Procedural Interfaces are relevant and available outside the THORN project. (plain text, troff -ms, and Postscript) thorn-na.ms thorn-na.txt thorn-na.psc -------------------------------------------------- "The THORN and RARE Naming Architecture" THORN Note UCL-64.3 UCL Research Note RN/89/47 June 1989 S.E.Kille (Editor) Abstract: This document defines an X.500 Naming Architecture, which is independent of any specific implementation. This specification is agreed for use in the RARE community, and in the THORN Project and Large Scale Pilot Exercise. The initial contents of this document were developed for the THORN project and result substantially from experience with the ECMA TR 32 based pilot exercise. This document obsoletes the user naming aspects of the earlier THORN Naming Architecture [THORN Document UCL-45.6]. THORN specific information is now contained in "The THORN System Naming Architecture" [Kille89a]. This document has evolved on the basis of input from THORN, RARE, and other groups. (plain text, troff -ms, and Postscript) rare-na.ms rare-na.txt rare-na.psc -------------------------------------------------- "An Interim Approach to use of Network Addresses" UCL Research Note RN/89/13 S.E. Kille February 1989 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer stan- dards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilis- ing the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in con- junction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses in the context of existing networks, and is agreed for use in the THORN and ISODE projects. This document is also THORN document UCL-58. (text and Postscript) nsap.txt nsap.psc -------------------------------------------------- A String encoding of Presentation Address UCL Research Note RN/89/14 S.E. Kille February 1989 Abstract: There are a number of environments where a simple string encoding of Pre- sentation Address is desirable. This specification is agreed for use in the ISODE and THORN projects, and may be of wider interest. This docu- ment is also THORN Document UCL-59. (text and Postscript) string.txt string.psc -------------------------------------------------- Domains and X.500 UCL Research Note RN/89/49 S.E. Kille June 1989 Abstract: This document considers X.500 in relation to Internet/UK Domains. A basic model of X.500 being \at the level above" is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. (text and Postscript) domain.txt domain.psc ------------------------------------------------- Using the OSI Directory to achieve User Friendly Naming UCL Research Note RN/90/29 S.E. Kille June 1990 Abstract The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: + A user oriented notation + Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. (Postscript) ufn.psc   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29505-0@bells.cs.ucl.ac.uk>; Fri, 5 Oct 1990 17:04:58 +0100 To: ietf-osi-ds@uk.ac.ucl.cs Subject: Agenda for Meeting on 11th Phone: +44-71-380-7294 Date: Fri, 05 Oct 90 17:04:57 +0100 Message-ID: <1832.655142697@UK.AC.UCL.CS> From: Steve Kille Agenda for first meeting of IETF Directory Services Group S.E. Kille 11th October Date 9:00 - 17:00 on Thursday 11th October Venue Fairmont Garden Room INTEROP 90 San Jose Convention and Cultural Center San Jose, CA A draft agenda follows. It may be altered substantially following the discussion of scope of the group. 9:00 Introduction and Welcome 9:10 Background status presentations: o X.500 Standardisation (activity update, not tutorial) o Internet X.500 Piloting (PSI Pilot) o Worldwide Piloting 9:45 Discussion of Scope and Charter of group 11:00 Coffee 11:30 Agreement of Agenda 11:40 White Pages issues. Requirements for deploying an Internet-wide pilot. This should include` Naming Architecture (Schema) Information framework for Inter- net Operation. Naming Notation Approach to representing Directory Names on the Internet. 12:30 Lunch 13:30 X.500 Extensions. Consideration of the items listed in the scope. This item should lead to an RFC which describes a technical frame- work for deployment of X.500 on the Internet. 1 15:00 Tea 15:30 Relationship of X.500 to DNS 16:00 Application use of X.500. Potential application of X.500 and general timescales should be identified. 16:40 Liaison with RARE WG3 16:50 Date and Venue of next meeting 16:55 AOB 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29550-0@bells.cs.ucl.ac.uk>; Fri, 5 Oct 1990 17:05:55 +0100 To: ietf-osi-ds@uk.ac.ucl.cs Subject: Revised Scope Phone: +44-71-380-7294 Date: Fri, 05 Oct 90 17:05:53 +0100 Message-ID: <1845.655142753@UK.AC.UCL.CS> From: Steve Kille IETF Directory Working Group: Proposed Scope (Version 2) S.E. Kille October 5, 1990 Abstract This document suggests an initial scope for the IETF OSI Directory Services Working Group (OSI-DS). It is based on an earlier version of July 1990. Brief summary of group: The OSI-DS group works on issues re- lating to X.500 deployment on the Internet. Whilst this group is not directly concenred with piloting, the focus is practical, and technical work needed as a pre-requisite to use of X.500 will be considered. Timeframe: need to add some timeframes and tighten objectives. This should be worked on at the first meeting 1 X.500 Extensions X.500 (1984) / ISO 9594 does not have sufficient functionality for full de- ployment on the Internet. This group should identify areas where extensions are required. This may lead to two things o Service requirements on implementations, to be provided by implemen- tations specific techniques. For example, this might be appropriate for access control. o Specification of Internet procedures for operation, presumably as RFCs. For example, this might be appropriate for replication Any activity should be undertaken in the light of ongoing standardisation activity. Areas which should be examined include: o Replication o Knowledge Representation o Schema Management o Access Control o Authentication o Distributed operations for partially connected DSAs o Presentation Address Handling 1 2 Application of the Directory The directory can be used to support a wide range of applications. It is necessary to evaluate which are important for the Internet, and what level of priority they should be given within the community. White Pages type of application is likely to be given a high priority. Other types of application may be pursued in a more private manner. An initial list of applications to discuss: o User Lookup (White Pages) o X.400 o Privacy Enhanced Mail o FTAM (and other OSI Applications requirint Application Entity Title to presentation address mapping) o Transport Bridging o DNS Replacement o RFC 1148/987 o Yellow pages and general searching o Library Lookup o NTP Support o Other new applications 3 Deployment 3.1 Schema A Schema (Naming Architecture) should be defined for the Internet. A requirement for a schema should be defined, and inputs evaluated. Various approaches to specification of Schema from a user and system standpoint should be considered, including update mechanisms. An RFC should be developed. The THORN and RARE Naming architecture, as used in the European Pilots and PSI WP Service should be considered as a basis for this work, and potential evolution into a joint RARE and Internet Naming Architecture considered. 3.2 User Friendly Naming There is a requirement for representation of Directory Names, as these will need to be communicated \out of band". An Internet approach to this should be defined. 2 4 Liaison Liaisons should be established as appropriate. In particular: RARE WG3 To harmonise work with European activities NIST To co-ordinate with the Directory SIG. CCITT/ISO IEC To co-ordinate with ongoing standardisation. 3   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29505-0@bells.cs.ucl.ac.uk>; Fri, 5 Oct 1990 17:04:58 +0100 To: ietf-osi-ds@uk.ac.ucl.cs Subject: Agenda for Meeting on 11th Phone: +44-71-380-7294 Date: Fri, 05 Oct 90 17:04:57 +0100 Message-ID: <1832.655142697@UK.AC.UCL.CS> From: Steve Kille Agenda for first meeting of IETF Directory Services Group S.E. Kille 11th October Date 9:00 - 17:00 on Thursday 11th October Venue Fairmont Garden Room INTEROP 90 San Jose Convention and Cultural Center San Jose, CA A draft agenda follows. It may be altered substantially following the discussion of scope of the group. 9:00 Introduction and Welcome 9:10 Background status presentations: o X.500 Standardisation (activity update, not tutorial) o Internet X.500 Piloting (PSI Pilot) o Worldwide Piloting 9:45 Discussion of Scope and Charter of group 11:00 Coffee 11:30 Agreement of Agenda 11:40 White Pages issues. Requirements for deploying an Internet-wide pilot. This should include` Naming Architecture (Schema) Information framework for Inter- net Operation. Naming Notation Approach to representing Directory Names on the Internet. 12:30 Lunch 13:30 X.500 Extensions. Consideration of the items listed in the scope. This item should lead to an RFC which describes a technical frame- work for deployment of X.500 on the Internet. 1 15:00 Tea 15:30 Relationship of X.500 to DNS 16:00 Application use of X.500. Potential application of X.500 and general timescales should be identified. 16:40 Liaison with RARE WG3 16:50 Date and Venue of next meeting 16:55 AOB 2   Return-Path: Received: from husc3.harvard.edu by bells.cs.ucl.ac.uk with SMTP inbound id <25862-0@bells.cs.ucl.ac.uk>; Mon, 8 Oct 1990 18:33:15 +0100 Date: Mon, 8 Oct 90 13:35 EDT From: Danny Padwa Subject: Please add me to the IETF-OSI-DS list To: ietf-osi-ds@uk.ac.ucl.cs X-VMS-To: IN%"ietf-osi-ds@cs.ucl.ac.uk" Please add me to the IETF-OSI-DS list. Thanks, Danny Padwa Harvard University Padwa@Husc3.Harvard.Edu   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <16714-0@bells.cs.ucl.ac.uk>; Wed, 24 Oct 1990 13:32:15 +0100 To: rare-wg3@de.dbp.gmd.xps, ietf-osi-ds@uk.ac.ucl.cs Subject: RARE WG3 and the IETF OSI DS group Phone: +44-71-380-7294 Date: Wed, 24 Oct 90 13:32:08 +0100 Message-ID: <1204.656771528@UK.AC.UCL.CS> From: Steve Kille There have been recent meetings of both RARE WG3 (Directory Subgroup) and IETF OSI DS group. As the person present at both meetings, I will try to summarise what I interpret at the common conclusion. Both groups feel that the objectives of the two groups are very similar. Essentially, this is to provide a technical framework for the deployment of X.500 directories in the research community. A merger of the two groups would make much sense, but there are pragmatic reasons (esp. travel funding) why this would not work. The following steps for close liaison will be taken. 1) Establish a strong liaison between meetings of the groups 2) The groups should work together to develop Agendas which complement each other, rather than duplicating effort 3) A common mailing list will be used. The current RARE WG3 list should remain, but only for administrative matters of concern to both of the subgroups of WG3. A new list "osi-ds" will be created, which will have the initial membership taken from the existing ietf-osi-ds list. Any RARE WG3 members not already on this list (I think that a lot of you are) should send a request to There will be aliases "ietf-osi-ds" "rare-wg3-osi-ds" (and the appropriate -request forms) It is hoped that if this collaboration is successful, then it can be used as a model for closer co-operation between other RARE Working Groups and IETF Working Groups. Steve   Return-Path: Received: from att.att.com by bells.cs.ucl.ac.uk with SMTP inbound id <390-0@bells.cs.ucl.ac.uk>; Wed, 24 Oct 1990 14:37:05 +0100 From: youbong@com.att.arch2 Date: Wed, 24 Oct 90 09:08 EDT To: att.com!cs.ucl.ac.uk!ietf-osi-ds@uk.ac.ucl.cs Subject: any e-mail? Hi, I have not received any messages since the last San Jose meeting through ietf-osi-ds e-mail distribution? Were there any messages sent out at all? Or my e-mail connection does not work? Youbong Weon-Yoon AT&T youbong@arch2.att.com (201)949-5101   Return-Path: Received: from att.att.com by bells.cs.ucl.ac.uk with SMTP inbound id <390-0@bells.cs.ucl.ac.uk>; Wed, 24 Oct 1990 14:37:05 +0100 From: youbong@com.att.arch2 Date: Wed, 24 Oct 90 09:08 EDT To: att.com!cs.ucl.ac.uk!ietf-osi-ds@uk.ac.ucl.cs Subject: any e-mail? Hi, I have not received any messages since the last San Jose meeting through ietf-osi-ds e-mail distribution? Were there any messages sent out at all? Or my e-mail connection does not work? Youbong Weon-Yoon AT&T youbong@arch2.att.com (201)949-5101   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18568-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 11:27:08 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Test - please ignore Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 11:27:05 +0000 Message-ID: <978.659100425@UK.AC.UCL.CS> From: Steve Kille   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28577-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 13:53:18 +0000 To: osi-ds@uk.ac.ucl.cs Subject: The IETF OSI-DS Working Group -- Progress Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 13:53:16 +0000 Message-ID: <1337.659109196@UK.AC.UCL.CS> From: Steve Kille This has all been very quiet, however this does not mean that nothing has happened! Bill and I are working at minutes for the October meeting, and we hope to get something to you before the Boulder Meeting. In the next three messages, I will send you: 1) A revised scope, in light of the discussions at the first meeting. Please send comments (especaially those of you at the meeting). 2) An Internet Draft on the overall strategy for the group. This document defines the reading list for the next meeting in Section 8. The references indicate existing documents, some of which will be modified into Internet Drafts. You may read these documents or wait for the revised versions. There will be no major changes. 3) An INDEX, containing directions on accessing the document archive by FTAM, FTP, NIFTP or mail. Documents include: - Items 1) and 2) (Some may prefer to pull the postscript versions) - Mail archive - The three relevant Internet Drafts (all due for revision) - A note on User Friendly naming (due to be modified and submitted as Internet draft). Fairly soon afterwards, expect to see: - Agenda for the Boulder Meeting - COSINE and Internet Naming Architecture draft I plan to have the replication documents out by the end of this week. I look forward to seeing you all in Boulder Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28698-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 13:56:24 +0000 To: osi-ds@uk.ac.ucl.cs cc: Greg Vaudreuil Subject: Building an Internet Directory using X.500 Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 13:56:20 +0000 Message-ID: <1360.659109380@UK.AC.UCL.CS> From: Steve Kille Network Working Group S.E. Kille INTERNET{DRAFT nnnn University College London November 1990 Building an Internet Directory using X.500 Status of this Memo The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET{DRAFT Building an Internet Directory November 1990 Contents 1 Introduction 1 2 Schema 2 3 Use on the Internet 2 4 Replication of Knowledge and Data 2 5 Security 3 6 Presentation of Directory Names 4 7 Relation to DNS 4 8 Documents to be produced 4 9 Security Considerations 5 10 Author's Address 5 1 Introduction There is substantial interest in establishing an OSI Directory Service on the Internet. There is pressure to establish a number of services on the Internet, including: o White Pages lookup of users. o Support for OSI Applications. o Support for X.509 Authentication for a range of application, including Privacy Enhanced Mail [Lin89]. The OSI Directory is viewed as the best basis for achieving these services, for both technical and political reasons. The OSI Directory Standards do not contain sufficient information to enable such a service to be built. Full openness and interoperabulty are a key goal, so service must not depend on private extensions or informal agreements. This document describes the missing components, and suggests a strategy for filling in the holes. Kille Page 1 INTERNET{DRAFT Building an Internet Directory November 1990 2 Schema A Directory needs to be used in the context of an Information Framework. The standard directory provides a number of a attributes and object classes to enable basic operation. It is certain that the Internet Community will have requirements for additional attributes and object classes. There is a need to establish a mechanism to register such information. Pilots in the European RARE Community and the US PSI White Pages Pilot have based their information framework on the THORN and RARE Naming Architecture [Kil89c]. It is proposed to use this architecture for the Internet Pilot, in conjunction with COSINE based piloting in Europe. A revised version of the Naming Architecture will be produced, with a mechan- sism for registration of new attributes and object classes. 3 Use on the Internet It is desirable to decouple deployment of the OSI Directory from deployment of the OSI lower layers. For this reason, it is recommended to operate the directory over TCP/IP using RFC 1006 [RC87 ] in addition to operation over OSI Network Service. This has the following implications: 1. There is a need to represent TCP/IP addresses within OSI Network Addresses. An Internet Draft, based on a paper by Kille, should be taken as a starting point for this [Kil89a]. It will be necessary to have in Internet Standard on this area. 2. It will be desirable to have a uniform method to present Network Addresses of this style. Therefore a string representation should be developed in parallel. The Internet Draft, based on a paper by Kille, should be used as a basis for this [Kil89b]. 3. This choice leads to the situation where not all DSAs can communicate directly due the different choice of lower layers. This is already a practical result of many European sites operating DSAs over X.25. There is a requirement to extend the distributed operations, so that there is no requirement for full connectivity. This issue will be dealt with in the documents to be generated according to Section 4. 4 Replication of Knowledge and Data There are a number of requirements on replication, both of data and knowl- edge information, which must be met before an Internet Directory can be deployed. It is clear that the standard cannot be used as is. Three solutions were noted: Kille Page 2 INTERNET{DRAFT Building an Internet Directory November 1990 o Wait until the 1992 standard is available o Attempt to intercept the 1992 standard, probably by specification of subset functionality based on the current working documents o Use an interim approach It is necessary to define the minimum requirements. An Internet Draft on this will be produced. Kille believes that all of the key problems have been solved by the QUIPU implementation, in a manner much simpler than that being developed by ISO and CCITT [Kil88]. The existing pilots are a reasonable demonstration of this belief. These mechanisms will be documented, and may be considered as the basis for an Internet approach to replication. Specifications of alternate interim approaches, especially approaches which intercept the emerging standardisation work, are strongly solicited. 5 Security A Directory and Security are closely related. There is no requirement for specification of any Internet specific approaches at this stage. Deployment of a directory could be based on one of: o Read only system, containing only public data and using local modi- fication. o Use of X.509 authentication, and private access control mechanisms (this will not allow open access control management, but this is not seen as a fundamental problem) [CCI88a ]. A specification on security for the Internet Directory should be devel- oped. This should specify: o Internet requirements for security in the Directory o A recommendation of how to use X.509 o Recommendation on service requirements for access control, as a hint to implementors who attempt to intercept the 1992 standard or de- velop private mechanisms o A note on security issues (authentication, policy, access control) not being addressed by the standards work, which might require future work o Requirements and recommendations for implementors (e.g., in terms of maintaining data confidentiality within an Organisation) Kille Page 3 INTERNET{DRAFT Building an Internet Directory November 1990 6 Presentation of Directory Names The standard does not specify a means to present directory names to the user. This is seen as a serious deficiency, and a standard for presenting direc- tory names should be developed. The \User Friendly Name" specification by Kille should be submitted as an Internet Draft, as a starting point for this work [Kil90]. 7 Relation to DNS It is important to establish the relationship between the proposed Internet Directory, and the existing Domain Name System. One input to this work should be the Internet Draft by Kille, to be updated before the meeting [Kil89d]. 8 Documents to be produced The following Internet Drafts will be produced, to be discussed at the Boul- der IETF Meeting. Schema Cosine and Internet Naming Architecture. P. Barker/S.E. Kille. Network Address Encoding Revise the Internet Draft [Kil89a]. S.E. Kille. Address String Encoding Revise the Internet Draft [Kil89b]. S.E. Kille. Replication Requirements S.E. Kille. Replication Solution S.E. Kille. Security P. Yee/B. Manning Directory Name Presentation Kille Relation to DNS Kille References [CCI88a] The directory | authentication framework, December 1988. CCITT Recommendation X.509. [CCI88b] The directory - overview of concepts, models and services, Decem- ber 1988. CCITT X.500 Series Recommendations. [Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5 Confer- ence on Message Handling Systems and Distributed Applications, pages 173{186. North Holland Publishing, October 1988. Kille Page 4 INTERNET{DRAFT Building an Internet Directory November 1990 [Kil89a] S.E. Kille. An interim approach to use of network addresses. Re- search Note RN/89/13, Department of Computer Science, Uni- versity College London, February 1989. Internet Draft: DRAFT- UCL-KILLE-NETWORKADDRESSES-00.PS.1. [Kil89b] S.E. Kille. A string encoding of presentation address. Research Note RN/89/14, Department of Computer Science, University College London, February 1989. Internet Draft: DRAFT-UCL- KILLE-PRESENTATIONADDRESSES-00.PS.1. [Kil89c] S.E. Kille. The THORN and RARE naming architecture. Techni- cal report, Department of Computer Science, University College London, June 1989. THORN Report UCL-64 (version 2). [Kil89d] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College Lon- don, May 1989. Also Internet Draft: DRAFT-UCL-KILLE- X500DOMAINS-00.PS. [Kil90] S.E. Kille. Using the osi directory to achieve user friendly nam- ing. Research Note RN/90/29, Department of Computer Science, University College London, February 1990. [Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail: Part 1 | Message Encipherment and Authentication Procedures. Re- quest for Comments 1113, DDN Network Information Center, SRI International, August 1989. [RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services on top of the TCP. Request for Comments 1006, DDN Network Information Center, SRI International, May 1987. 9 Security Considerations Security considerations are discussed in Section 5 of this INTERNET{DRAFT . 10 Author's Address Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 Kille Page 5 INTERNET{DRAFT Building an Internet Directory November 1990 EMail: S.Kille@CS.UCL.AC.UK Kille Page 6   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28669-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 13:55:23 +0000 To: osi-ds@uk.ac.ucl.cs Cc: Greg Vaudreuil , Megan Davies Subject: OSI-DS Scope Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 13:55:18 +0000 Message-ID: <1352.659109318@UK.AC.UCL.CS> From: Steve Kille IETF Directory Working Group Scope (Version 3) S.E. Kille November 20, 1990 Abstract This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practi- cal, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. 1 X.500 Infrastructure The major goal of this WG is to provide the technical framework for a Directory Service infrastructure on the Internet. This infrastructure should be based on the OSI Directory (X.500). It is intended that this infrastructure can be used by many applications. Whilst this WG is not directly concerned with operation of services, close liaison is expected with those groups which do operate pilots and services. X.500 (1984) / ISO 9594 does not have sufficient functionality for full de- ployment on the Internet. This group should identify areas where extensions are required. This may lead to two things o Service requirements on implementations, to be provided by implemen- tations specific techniques. For example, this might be appropriate for access control. o Specification of Internet procedures for operation. For example, this might be appropriate for replication Any activity should be undertaken in the light of ongoing standardisation activity. Areas which should be examined include: o Replication o Knowledge Representation o Schema Management 1 o Access Control o Authentication o Distributed operations for partially connected DSAs o Presentation Address Handling A Schema (Naming Architecture) should be defined for the Internet. A requirement for a schema should be defined, and inputs evaluated. Vari- ous approaches to specification of Schema from a user and system stand- point should be considered, including update mechanisms. The THORN and RARE Naming architecture, as used in the European Pilots and PSI WP Service should be considered as a basis for this work, and evolution into a joint RARE and Internet Naming Architecture considered. There is a requirement for representation of Directory Names, as these will need to be communicated \out of band". An Internet approach to this should be defined. This work will lead to a series of RFCs, which define how to provide the Internet Directory Infrastructure. It is aimed to have this in place by March 1991. 2 Application of the Directory The directory can be used to support a wide range of applications. For most applications, this will be the concern of the applications. Examples of applications which might define how to use the X.500 include: o X.400 o Key Management and Authentication for use by: + Privacy Enhanced Mail + Policy Based Routing o FTAM (and other OSI Applications requiring Application Entity Title to presentation address mapping) o RFC 1148/987 o Yellow pages and general searching o Library Lookup o NTP Support Two applications of the directory are of special interest, and will be tackled directly by the WG. 2 1. Use of the directory to provide a White Pages service, to locate users and services. This will be developed in conjunction with the basic infrastructure. 2. Relationship of the OSI Directory to the Domain Name Scheme. The group will develop a working document which examines possible inter- relationships between these two services. 3 Liaison Liaisons should be established as appropriate. In particular: RARE WG3 To harmonise work with European activities NIST To co-ordinate with the Directory SIG. CCITT/ISO IEC To co-ordinate with ongoing standardisation. North American Directory Forum To liaise with service developments in North America. 3   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <2463-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 14:26:25 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Attendance at Boulder Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 14:26:23 +0000 Message-ID: <1650.659111183@UK.AC.UCL.CS> From: Steve Kille Could you let me know if you are (likeley) to attend the OSI-DS meeting at Boulder (all or part). thanks Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3549-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 14:47:42 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Draft Agenda Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 14:47:40 +0000 Message-ID: <1741.659112460@UK.AC.UCL.CS> From: Steve Kille Please send comments or suggestions. Steve Agenda for second meeting of IETF Directory Services Group S.E. Kille 20th November Date 09:30 - 18:00: Monday 3rd December 1990 09:30 - 16:00: Monday 3rd December 1990 Venue IETF Clarion Harvest House 1345 Twenty-Eigth Street Boulder, CO 80303 Tel: (303)-443-3850 Draft agenda follows. MONDAY 9:30 o Agenda o Minutes of previous meeting o Matters arising 10:00 Liaisons o RARE WG3 o ISO/CCITT o NIST o NADF 10:30 FOX (Presentation) 11:00 COSINE P2.1 (Presentation) 11:15 Scope of group 11:30 Infrastructure strategy (Internet Draft on Building an Internent Di- rectory using X.500) 12:00 Lunch 1 13:30 Replication and related issues. If there is insufficient time, this will be continued on Tuesday afternoon. 15:30 Tea 16:00 Relationship to DNS 18:00 End TUESDAY 9:30 Names, Addresses and Identities: A Universal Name Service for a Multi-Media environment (Presentation by Gita Gopal of Bellcore). 10:00 Address String Encoding 10:45 Schema (Internet Draft: Cosine and Internet Naming Architecture) 12:00 Lunch 13:30 Security 15:15 Date and Venue of next meeting 15:20-15:30 AOB 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <7379-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 15:59:49 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Two Mondays Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 15:59:46 +0000 Message-ID: <1893.659116786@UK.AC.UCL.CS> From: Steve Kille Before everyone notices this...... The second day of the meeting is Tuesday 4th December. Steve ------- Forwarded Message From: Paul Barker To: Steve Kille Subject: Re: Draft Agenda Date: Tue, 20 Nov 90 15:57:08 +0000 I think you have goofed with the dates. > Date 09:30 - 18:00: Monday 3rd December 1990 > 09:30 - 16:00: Monday 3rd December 1990 ------- End of Forwarded Message   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28789-0@bells.cs.ucl.ac.uk>; Tue, 20 Nov 1990 13:57:41 +0000 To: osi-ds@uk.ac.ucl.cs cc: Greg Vaudreuil Subject: OSI-DS Index Phone: +44-71-380-7294 Date: Tue, 20 Nov 90 13:57:37 +0000 Message-ID: <1374.659109457@UK.AC.UCL.CS> From: Steve Kille INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 3) S.E. Kille November 20, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practi- cal, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ MINUTES OF MEETINGS ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps Building and Internet Directory using X.500 S.E. Kille November 1990 Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille UCL Research Note RN/89/13 (February 1989) DRAFT-UCL-KILLE-NETWORKADDRESSES-00.PS.1 (January 1990) Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer stan- dards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilis- ing the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in con- junction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses in the context of existing networks, and is agreed for use in the THORN and ISODE projects. This document is also THORN document UCL-58. string.ps string.txt A String encoding of Presentation Address S.E. Kille UCL Research Note RN/89/14 (February 1989) DRAFT-UCL-KILLE-PRESENTATIONADDRESSES-00.PS.1 (January 1990) Abstract: There are a number of environments where a simple string encoding of Pre- sentation Address is desirable. This specification is agreed for use in the ISODE and THORN projects, and may be of wider interest. This docu- ment is also THORN Document UCL-59. domain.ps Domains and X.500 S.E. Kille UCL Research Note RN/89/49 (June 1989) DRAFT-UCL-KILLE-X500DOMAINS-00.PS (January 1990) Abstract: This document considers X.500 in relation to Internet/UK Domains. A basic model of X.500 being \at the level above" is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. ufn.ps Using the OSI Directory to achieve User Friendly Naming UCL Research Note RN/90/29 S.E. Kille June 1990 Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: + A user oriented notation + Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. ------------------------------------------------------------------------   Return-Path: Received: from ATT.ATT.com by bells.cs.ucl.ac.uk with SMTP inbound id <12251-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 09:55:33 +0000 From: youbong@com.att.arch2 Date: Tue, 20 Nov 90 16:20 EST To: attunix!att!cs.ucl.ac.uk!S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Subject: Re: Attendance at Boulder I am planning to attend the meeting at Boulder on Dec. 3 and half day of Dec. 4. I don't have information about the meeting arrangement. Can someone share the information about -. meeting place -. meeting time -. hotel information with me? Youbong Weon-Yoon AT&T (201)949-5101   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <12398-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 10:07:26 +0000 To: youbong@com.att.arch2 cc: osi-ds@uk.ac.ucl.cs Subject: Re: Attendance at Boulder Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 20 Nov 90 16:20:00 -0500. Date: Wed, 21 Nov 90 10:07:18 +0000 Message-ID: <436.659182038@UK.AC.UCL.CS> From: Steve Kille It had not occurred to me that some of you did NOT see the IETF announcements.` Here is the IETF calling notice. I'll make sure that such announcements get` passed to this list when we have our meetings at the IETF. I note that the IETF is an open list, and some of you may wish to join. Steve From: mdavies@us.VA.Reston.NRI Subject: IETF Dec. 2-7, 1990 Boulder, CO To: ietf@edu.isi.venera Date: Fri, 19 Oct 90 18:46:35 EDT Reply-To: ietf-reg@us.VA.Reston.NRI Dear IETFers: This is the first mailing of logistics for the upcoming IETF, (December 2-7, 1990/Boulder, CO). An Agenda and Directions will follow at a la ***ter date. Please direct any questions to ietf-reg@nri.reston.va.us. Included in this mailing are the following: 1. AT-A-GLANCE: A one page write-up of pertinent information (i.e, Dates, Registration Info., Hotel, Airline, Shuttle) 2. RSVP/Proceedings Request Form The steady rise in attendance at the IETF meetings, while encouraging, prompts a reminder that the quality of these meetings (and in particular the Working Group technical *working* sessions) is dependent upon the informed, constructiv ***e participation of the individual attendees. Please come prepared. Information on the current status and progress of the individual Working Groups can be obtained in several ways: 1) Working Group objectives and notes from previous sessions are available online (send to ietf-manager@nri.reston.va.us for retrieval instructions). 2) Working Group objectives and notes from previous meetings are also reproduced in the hardcopy Proceedings (to order, send to proceedings@nri.reston.va.us). 3) Agendas and reading lists for Working Group meetings will also be posted to the respective Working Group mailing lists. LOOKING AHEAD.... The March 1991 IETF Meeting will be held at Washington University in St. Louis. Our Host for that meeting will be Gurudatta Parulkar. As discussed in previous *** IETF Plenaries, beginning with the March 1991 IETF meeting attendees will be asked to help offset some meeting costs. More information on this will be provided at a later time. Finally, future IETF Meeting sites may include Bell South (Atlanta), Ohio State University and Los Alamos National Labs. 19TH INTERNET ENGINEERING TASK FORCE AT-A-GLANCE DATE: December 2-7, 1990 HOST(S): Carol Ward - University of Colorado Don Morris - NCAR HOTEL/MEETING SITE: Clarion Harvest House 1345 Twenty-Eighth Street Boulder, CO 80302 (303) 443-3850 175 Rooms reserved (Govt. Rate) until Nov. 9 $55/single, $70/double Specify: IETF GROUP MESSAGES: Should be directed to attendees referencing "IETF Plenary" ALTERNATE ACCOM: The Golden Buff 1725 28th Avenue Boulder, CO 80301 (303) 442-7450 (800) 999-BUFF 10 Rooms reserved until Nov. 19 $57/night Specify: IETF No. 34592 MEETING ROOMS: Clarion Harvest House 7pm - 12midnight PRE-REGISTRATION: Sunday, December 2, 1990 6pm - 8pm (reception during) Clarion Harvest House Room: TBD REGISTRATION: Monday, December 3, 1990 8am - 9am Clarion Harvest House Room: outside Ballroom AIRLINE: United Airlines (special rate roundtrip only) (800) 521-4041 (US/Canada reservations) (800) 722-5243 (Hawaii/Alaska reservations) Specify: IETF MEETING GROUP #0152-N AIRPORT: Stapleton International, Denver 27 Miles from Clarion Harvest Home (o/a 40min) SHUTTLE: "Airporter" $8.50each way (pay in cash/traveler's checks) (303) 321-3222 (reservations advisable) *** (near door 6 in baggage claim are ***a) (8am-10:15pm on the hour & half h ***our) PARKING: Ample FREE parking at Hotel CLIMATE: Generally in the 50's in early December Snow a possibility (be prepared). IETF RSVP Form 19th Internet Engineering Task Force December 2-7, 1990 Boulder, Colorado Please complete the following information and email or FAX to: Megan Davies at ietf-reg@nri.reston.va.us or (703) 620-0913. ____YES, I plan to attend the IETF Meeting in Boulder and I "DO" want a copy of the PROCEEDINGS (complimentary). ____YES, I plan to attend the IETF Meeting in Boulder and I "DO NOT" want a copy of the PROCEEDINGS. ---- NO, I do not plan to attend the IETF Meeting in Boulder but I "DO" want to ORDER a copy of the PROCEEDINGS. Please mail a hard copy of this RSVP Form along with a check for $35.00 Pay/Mail To: Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091 ATTN: IETF Proceedings To insure accurate records and timely correspondence, please provide the following information: 1. Name (Mr/Dr/Ms/Prof):_______________________________ Title: _______________________________ Organization: _______________________________ _______________________________ Department: _______________________________ Street: _______________________________ _______________________________ P.O. Box/Mail Stop: _______________________________ Building/Suite: _______________________________ City/State/Zip: _______________________________ 2. Phone: _______________________________ Fax: _______________________________ E-mail: _______________________________ 3. Date of expected arrival at the hotel: __________ Date of expected departure from the hotel:__________ 4. Form of daily transportation I plan to use: Hotel Shuttle:__________________ Rental car: __________________ Other: __________________   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <12475-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 10:09:31 +0000 To: youbong@com.att.arch2 cc: osi-ds@uk.ac.ucl.cs Subject: Re: Attendance at Boulder Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 20 Nov 90 16:20:00 -0500. Date: Wed, 21 Nov 90 10:09:25 +0000 Message-ID: <460.659182165@UK.AC.UCL.CS> From: Steve Kille And here is the draft Agenda, for those who may be ointerested in other parts of the meeting Steve From: mdavies@us.VA.Reston.NRI Subject: Mailing 1 of 3: Second Draft Agenda (Boulder IETF) To: ietf@edu.isi.venera cc: mdavies@us.VA.Reston.NRI Date: Mon, 19 Nov 90 17:28:58 EST Dear IETFers, This is the SECOND draft of the Agenda and the first of two mailings to the IETF (Logistics and the Attendee list will follow in separate mailings respectively). Please remember that the quality of the Working Group technical *working* sessions is dependent upon the informed, constructive participation of the individual attendees. Please come prepared. Information on the current status and progress of the individual Working Groups can be obtained in several ways: 1) Working Group objectives and notes from previous sessions are available online (send to ietf-manager@nri.reston.va.us for retrieval instructions). 2) Working Group objectives and notes from previous meetings are also reproduced in the hardcopy Proceedings (to order, send to proceedings@nri.reston.va.us). 3) Agendas and reading lists for Working Group meetings will also be posted to the respective Working Group mailing lists. --------- Preliminary Agenda of the Nineteenth IETF (December 3-7, 1990) MONDAY, December 3 9:30-12:00 noon Morning Working Group Sessions o Character MIB (Bob Stewart/Xyplex) o Connection IP (Claudio Topolcic/BBN) o How to Write a MIB (Dave Perkins/3COM) o Interdomain Policy Routing (Martha Steenstrup/BBN) o Network Information Services Infrastructure (Dana Sitzler/Merit) o Network Printing Protocol (Glenn Trewitt/DEC) o OSI X.500 (Steve Kille/UCL) o Topology Engineering/Network Status Reports (Phill Gross/CNRI) o Reserved for Security 1:30-3:30 pm Afternoon Working Group Sessions o Benchmarking Methodology (Scott Bradner/Harvard) o Bridge MIB (Fred Baker/ACC) o Connection IP (Claudio Topolcic/BBN) o DECnet Phase IV MIB (Jonathan Saperia/DEC) o Distributed File Systems (Peter Honeyman/UMich) o Domain Name System (Philip Almquist/Consultant) o Interdomain Policy Routing (Martha Steenstrup/BBN) o Multicast Extentions to OSPF (Steve Deering/Xerox PARC) o OSI X.500 (Steve Kille/UCL) o Reserved for Security 4:00-6:00 pm Working Group Sessions o Connection IP (Claudio Topolcic/BBN) o Interdomain Policy Routing (Martha Steenstrup/BBN) o Introduction to Router Requirements (Philip Almquist/Consultant) o Network Joint Management (Gene Hastings/PSC) o Network Database (Russ Hobby/UCDavis) o OSI X.500 (Steve Kille/UCL) o PPP Extensions (Stev Knowles/FTP) o Reserved for Security 1 TUESDAY, December 4 9:00-12:00 noon Morning Working Group Sessions o Connection IP (Claudio Topolcic/BBN) o IP over Switched Megabit Data Service (George Clapp/Ameritech) o Interdomain Policy Routing (Martha Steenstrup/BBN) o OSI X.500 (Steve Kille/UCL) o Reserved for Security o Router Requirements (Philip Almquist/Consultant and James Forster/cisco Systems) o Telnet (Dave Borman/Cray Research) o Operational Statistics (Bernhard Stockman/NORDUnet and Phill Gross/CNRI) o OSI Internet Management (Brian Handspicker/DEC) 1:30-3:30 pm Afternoon Working Group Sessions o Assignment of OSI NSAP Addresses (Richard Colella/NIST) o Bridge MIB (Fred Baker/ACC) o Interdomain Policy Routing (Martha Steenstrup/BBN) o IP over Appletalk (John Veizades/Apple) o IP over Switched Megabit Data Service (George Clapp/Ameritech) o OSI X.500 (Steve Kille/UCL) o Reserved for Security o User Connectivity (Dan Long/BBN) 4:00-6:00 pm IETF Protocol and Technical Presentations 2 WEDNESDAY, December 5 9:00-12:00 noon Morning Working Group Sessions o Connection IP (Claudio Topolcic/BBN) o FDDI MIB (Jeffrey Case/UTenn) o Internet Accounting (Cyndi Mills/BBN) o Interdomain Policy Routing (Martha Steenstrup/BBN) o IP over Appletalk (John Veizades/Apple) o IP over Large Public Data Networks (George Clapp/Ameritech) o Management Services (Oscar Newkerk/DEC) o OSI X.400 (Rob Hagens/UWisc) o Router Requirements (Philip Almquist/Consultant and James Forster/cisco Systems) o User Services (Joyce Reynolds/ISI) 1:30-3:30 pm Afternoon Working Group Sessions o Connection IP (Claudio Topolcic/BBN) o Dynamic Host Configuration (Ralph Droms/Bucknell) o Interdomain Policy Routing (Martha Steenstrup/BBN) o IP over FDDI (Dave Katz/Merit) o IP over Large Public Data Networks (George Clapp/Ameritech) o Network Fax Working Group (Mark Needleman/UC) o OSI X.400 (Rob Hagens/UWisc) o Point-to-Point Protocol Extentions (Stev Knowles/FTP) o Security Policy (Rich Pethia/CERT) o Simple Network Management Protocol (Marshall Rose/PSI) o Remote LAN Monitoring (Mike Erlinger/Micro Technology, Inc.) 4:00-6:00 pm Technical Presentions o High Speed TCP (Dave Borman/Cray Research) o IP Over Switched Megabit Data Service (George Clapp/Ameritech) 3 THURSDAY, December 6 9:00-12:00 noon Morning Working Group Sessions o Border Gateway Protocol (Guy Almes/Rice) o Connection IP (Claudio Topolcic/BBN) o Internet Accounting (Cyndi Mills/BBN) o OSI General (Robert Hagens/UWISC and Ross Callon/DEC) o Resource Location Protocol -B.O.F.(John Veizades/Apple and Steve Deering/Xerox PARC) o Router Requirements (Philip Almquist/Consultant and James Forster/cisco Systems) o Site Security Policy Handbook (Joyce Reynolds/ISI and Paul Holbrook/CERT) o Eight-Bit Character Sets for SMTP (TBD) 1:30-3:30 pm High Speed Transport Presentations o Design and Implementation of a High-Speed Transport Protocol (Krishan Sabnani/AT&T) o Deterministic Transfer Protocol (Ashok Agrawala/UMD) o Axon: Host Communications Architecture for High Bandwidth Applications (Guru Parulkar/WashU) 4:00-6:00pm Open Plenary and IETF 4 FRIDAY, December 7 9:00-11:30 am Working Group Area and Selected Working Group Presentations o User Services Area (Joyce K. Reynolds/ISI) o Applications Area (Russ Hobby/UC Davis) o Internet Services Area (Noel Chiappa/Consultant) o Routing Area (Bob Hinden/BBN) o Security Area (Steve Crocker/TIS) o OSI Interoperability Area (Ross Callon/DEC and Rob Hagens/UWisc) o Operations Area (Interim - Phill Gross/CNRI) o Network Management Area (Chuck Davin/MIT) 11:30-12:00 noon Concluding Remarks (Phill Gross/CNRI) 12:15 pm Adjourn 5   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28286-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 13:43:13 +0000 To: osi-ds@uk.ac.ucl.cs cc: Greg Vaudreuil Subject: Internet Draft on Replication Requirements Phone: +44-71-380-7294 Date: Wed, 21 Nov 90 13:43:12 +0000 Message-ID: <1332.659194992@UK.AC.UCL.CS> From: Steve Kille Here is the draft on replication requirements. I will be providing one proposed solution to these requirements. Other solutions, and in particular an Intercept of the standard would be welcome. Given the timeframe, I assume that the only possible solutions would be documentation of existing work, or a specification by one of the authors of the standard. I would welcome comment from a standards expert, as to how far the current standards work addresses these requirements, and the difficulty of specifying an intercept. I would like general comment on the validity of these requirements. I regard all of these requirements as non-neotiable. There is a postscript version available in file "repl-req.ps" in the osi-ds archive at UCL. A good deal easier on the eyes. Steve Network Working Group S.E. Kille INTERNET{DRAFT nnnn University College London November 1990 Replication Requirement to provide an Internet Directory using X.500 Status of this Memo A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. This INTERNET{DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET{DRAFT Replication Requirements November 1990 1 Distributed Operation Extensions The Internet Directory will operate DSAs over TCP/IP using RFC 1006 [RC87 ]. It will need to interwork with DSAs operating over an ISO Network Service, both within and external to the pilot. 2 Alternate DSAs When a DSA Referral is returned, only the master DSA is indicated. This will lead to a single point of failure. It seems important to allow for ad- ditional references to slave copies, in order to get better availability. This needs to be solved in conjunction with the problem described in the previous section. 3 Name Allocation at the top levels There needs to be a procedure whereby a name can be allocated below the country level for use in a Directory. This may include an OSI Registration Authority or may be taking a name agreed by a Registration Authority, and verifying that it is unique within the directory. This procedure is not defined. It is at this second level of the tree where the problem becomes most intractable, as there are a reasonably small number of top levels, and third level and below can be solved by local/ad hoc means. If a decision is made to allow objects other than Countries at the top level, then the same problems will also apply at the root level, particularly with respect to registration of Organisations at the root of the DIT. 4 Knowledge Replication Knowledge information is critical to resolution of names, and performing searches. Knowledge information high up the tree needs to be widely avail- able. Consider resolving a name below \Country=US". To do this, a DSA needs to have full knowledge at this point. Many DSAs need to be able to do this, in order to give reasonable response and availability. It would be an unacceptable bottleneck to force such resolution to a single or small number of DSAs. To replicate this knowledge widely, a systematic approach to replication is needed., 5 Data Replication Searches are often made at the root and country level, and this is a vital service (e.g., an approximate match of an organisation name). Data needs to Kille Page 1 INTERNET{DRAFT Replication Requirements November 1990 be collected in such a way that this sort of searching is reasonably efficient. The usual X.500 approach of subordinate references militates against this. At a node in the DIT, subordinate references to the entries below are held. These entries will be in many DSAs, each of which needs to be accessed in order to perform the single level search. It is suggested that replication of data is necessary to achieve this. 6 Some scaling targets Most techniques for replication have scaling limits. It is suggested that any technique adopted for the Internet should allow scaling to at least the level where 10 000 Organisations could effectively participate. References [CCI88] The directory - overview of concepts, models and services, Decem- ber 1988. CCITT X.500 Series Recommendations. [Kil90] S.E. Kille. Building and internet directory using X.500, November 1990. Internet Draft: draft-ietf-osix500-directories-00.txt. [RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services on top of the TCP. Request for Comments 1006, DDN Network Information Center, SRI International, May 1987. 7 Security Considerations Security considerations are not discussed in this INTERNET{DRAFT . 8 Author's Address Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Kille Page 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4030-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 15:15:28 +0000 To: osi-ds@uk.ac.ucl.cs Subject: OSI-DS WG Charter Phone: +44-71-380-7294 Date: Wed, 21 Nov 90 15:15:23 +0000 Message-ID: <1550.659200523@UK.AC.UCL.CS> From: Steve Kille This is the modified WG Charter (also available in the archive) Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11792-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 16:42:26 +0000 to: osi-ds@uk.ac.ucl.cs Subject: OSI-DS WG Charter (take 2) Phone: +44-71-380-7294 In-reply-to: Your message of Wed, 21 Nov 90 15:15:23 +0000. <1550.659200523@UK.AC.UCL.CS> Date: Wed, 21 Nov 90 16:42:21 +0000 Message-ID: <1719.659205741@UK.AC.UCL.CS> From: Steve Kille I'll include the dcoument this time! OSI DS (osids) Charter Chair(s): Steve Kille, S.Kille@cs.ucl.ac.uk Mailing Lists: General Discussion: ietf-osi-ds@cs.ucl.ac.uk To Subscribe: ietf-osi-ds-request@cs.ucl.ac.uk Description of Working Group: The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practi- cal, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. Goals and Milestones: March 91 Definition of a Technical Framework for Provision of a Directory Infrastructure on the Internet, using X.500. This task may later be broken into subtasks. A series of RFCs will be produced. March 91 Study the relationship of the OSI Directory to the Domain Name Service. Ongoing Maintain a Shecma for the OSI Directory on the Internet Ongoing Liaisons should be established as appropriate. In particular: RARE WG3, NIST, CCITT/ISO IEC, North American Directory Forum, 1   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <11187-36@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 16:43:09 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <342-11@sun2.nsfnet-relay.ac.uk>; Wed, 21 Nov 1990 07:16:54 +0000 Received: from [192.70.139.21] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa28008; 21 Nov 90 6:07 GMT Received: from localhost by cheetah.ca.psi.com at Tue, 20 Nov 90 22:25:43 -0800. (5.61.14/XIDA-1.2.8.34) id AA15028 for osi-ds@cs.ucl.ac.uk via SMTP To: osi-ds@uk.ac.ucl.cs Cc: dist-osi-ds@com.psi.ca.cheetah Subject: please add Date: Tue, 20 Nov 90 22:25:42 -0800 Message-Id: <15026.659168742@cheetah.ca.psi.com> From: Marshall Rose dist-osi-ds@cheetah.ca.psi.com to the osi-ds list thanks, /mtr   Return-Path: Received: from GATEWAY.MITRE.org by bells.cs.ucl.ac.uk with SMTP inbound id <13321-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 17:12:41 +0000 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA20138; Wed, 21 Nov 90 12:11:42 -0500 Full-Name: Walt Lazear Message-Id: <9011211711.AA20138@gateway.mitre.org> To: Steve Kille Cc: osi-ds@uk.ac.ucl.cs, lazear@org.mitre.gateway Subject: Re: Attendance at Boulder In-Reply-To: Your message of "Tue, 20 Nov 90 14:26:23 GMT." <1650.659111183@UK.AC.UCL.CS> Date: Wed, 21 Nov 90 12:10:56 -0500 From: lazear@org.mitre.gateway I'm planning on attending the X.500 WG. Walt Lazear MITRE Corp.   Return-Path: Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13546-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 17:18:52 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Internet Draft for Naming Architecture (part 1) Date: Wed, 21 Nov 90 17:18:50 +0000 From: Paul Barker This is the first half of a draft naming architecture ... Network Working Group P. Barker INTERNET-DRAFT S.E. Kille University College London November 1990 The COSINE and Internet X.500 Naming Architecture Status of this Memo: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, the primary intention of which is to provoke comments on the updating mechanisms. Readers should concentrate their attention on these aspects of the document, although corrections to the naming architecture should also be signalled. When the updating mechanisms have been settled, a call will be made for modifications to the naming architecture. This draft document will be submitted to the RFC editor as a Barker & Kille [page 1] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . Barker & Kille [page 2] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 1. Introduction Directory Services are a fundamental requirement of both human and computer communications' systems. Human users need to be able to look up various details about other people: for example, telephone numbers, facsimile numbers and paper mail addresses. Computing systems also need Directory Services for several purposes: for example, to support address look-ups for a variety of services, and to support user-friendly naming and distribution lists in electronic mail systems. Directory Services have recently been standardised and published as the 1988 CCITT X.500 / ISO IS9594 recommendations [1]. The standard provides a good basis for the provision of real services, and a considerable amount of Directory Service piloting activity is currently underway. In the U.S., the PSI White Pages Pilot [4] has stimulated use of X.500 on the Internet. In Britain, the U.K. Academic Community Directory Pilot [5] is similarly promoting use of X.500. 2. Motivation and aims of this document In a number of areas the X.500 standard only provides a basis for services. One such area is the Directory's Naming Architecture or Schema. The standard defines a number of useful object classes, in X.521, and attribute types, in X.520. These are intended to be generally useful across a range of directory applications. However, while these standard definitions are a useful starting point, they are insufficient as a basis for a large scale pilot directory. While it is possible for directory administrators to define their own sets of additional attribute types and object classes, this is undesirable for some common attributes and objects. The same objects and attribute types would be privately defined many times over. This would result in the directory's generality being diminished as remote systems would be unable to determine the semantics of these privately defined data types. A number of useful additions to the standard definitions were made in this note's forerunner, "The THORN and RARE Naming Architecture" [2]. These have been heavily used in early X.500 piloting activities. Furthermore, both the THORN and Quipu X.500 implementations have made use of these definitions. Barker & Kille [page 3] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 Since the afore-mentioned note was issued, a number of further requirements have come to light as the volume and variety of piloting activity has increased. Yet further requirements seem likely as the scale of X.500 pilot services increases. Thus, it is argued that it is not sufficient to merely reissue an updated version of the original note. The naming architecture is a "living document" that needs procedures for: - Allowing submission of requests for new attributes and object classes to be added into the naming architecture; - Checking for the redundancy of any previously defined attribute types and object classes. This document attempts to establish procedures to allow for the continual updating of the naming architecture. Two proformas are set out for this purpose. In addition, descriptive detail is provided for the additional object classes and attribute types defined in the naming architecture. These descriptions follow the style used in X.520 and X.521. Finally, also following the style adopted in the standards documents, appendices will include the entire naming architecture. Plain text versions of the document's appendices are intended to be machine processible to allow derivation of a system's schema tables. Appendix C lists all the architectures's object classes and attribute types in their respective ASN.1 macro formats. Appendix D lists some object classes and attribute types in a more concise format. Comments are requested on whether this format is considered useful. If so, a revised version of this document will include the architecture in full in this, or a similarly brief, format. The scope and intended remit of this coordination activity should be clearly understood. - Esoteric and local, highly experimental requirements should continue to be met by private definitions. - Requirements which have support from more than one site will usually be integrated into the naming architecture. Put in other words, the tendency will be for the inclusion, as opposed to the exclusion, of useful additions to the naming architecture. - An attempt will be made to avoid duplication of object Barker & Kille [page 4] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 classes and attribute types for essentially similar real world objects. It is important to note that this version of the document is a draft, which is intended principally to provoke comments on the naming architecture updating mechanisms proposed. Corrections to the architecture should also be indicated to the authors. However, additions to the architecture should not be submitted until a call is made for such enhancements. 3. What conformance to this architecture means It is not reasonable to require that a DSA which supports this architecture has specific code to handle each of the defined syntaxes. However, the following requirements are made of a system which claims conformance to this specification: 1. A DSA shall be able to store all of the attributes and object class values specified. 2. A DUA shall be able to identify each attribute type and object class to the user, with an appropriate representation (e.g., a string). The following are desirable, but not required: 1. For a DSA to match correctly on the basis of all attribute syntaxes defined 2. For a DSA to enforce the Object Class schema implied by these definitions 3. For a DUA to correctly display the attribute values (syntaxes) defined 4. For DUAs and DSAs to maintain compatibility with a previous version of the naming architecture. 4. Requesting new object classes and attribute types This section defines a procedure for requesting new object classes and attribute types to be added to the naming Barker & Kille [page 5] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 architecture. Proformas for object classes and attribute types are specified, and examples given of how to use them. As stated earlier, it is anticipated that the naming architecture will evolve considerably over time. As X.500 is used to support a widening range of applications, there will be requirements for extensions to the naming architecture. This document proposes formalising this procedure by requiring requests for additions to the naming architecture to be submitted as completed proformas. This stipulation will greatly simplify subsequent revisions of the naming architecture. There is one qualification to the above with respect to requests for modifications to an existing object class. If a modification to an object class merely involves additional, optional attributes, the object class will be enhanced as requested. Systems are expected to be resilient to such changes to the naming architecture. However, requests to modify an object class, such that the mandatory attribute types require altering, will not be met. Instead, a new object class will be created, and the original object class expired following the scheme described in the next main section. It is anticipated that most requests for modifications to the naming architecture will be met without any need for editorial intervention. Sometimes, however, some discussion between the submitter of a request and the architecture's editor may be required. For example, the editor may have to judge the relative merits of two very similar requests and, as a result, one of the parties may not get quite what they want. In cases such as this where the submitter of a request feels aggrieved about an editorial decision, the requestor may appeal to a broader community by explaining their views to the mailing list ietf- osi-ds@cs.ucl.ac.uk. Heed will be paid to any consensus that emerges from discussions on the naming architecture on this list. If it proves that this list is used almost solely for discussions on naming architecture issues, a separate discussion list will be created. To facilitate the production of the afore-mentioned proformas, tools are included in Appendix B which will verify that a proforma has been correctly formatted. Completed proformas should be mailed to na-update@cs.ucl.ac.uk Barker & Kille [page 6] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 4.1. Object Class proforma This section gives an example, completed proforma for a new object class, alcoholic drink. A proforma for object class specified in BNF is included in Appendix A. Object Class: Alcoholic Drink Description: The Alcoholic Drink object class is used to define entries representing intoxicating beverages. ASN1OCMacro: alcoholicDrink OBJECT-CLASS SUBCLASS OF drink MUST CONTAIN { percentAlcohol} MAY CONTAIN { normalServing, hue} An object class description consists of three fields, separated by blank lines. The keywords Object Class, Description and ASN1OCMacro, and their suffixed colons, must be included exactly as above. The Object Class field should be used for a textual description of the object class. This will be at most three or four words. The Description field should contain some explanatory text about the intended use of the object class. This can run to a number of lines. The ASN1OCMacro field should follow the definition of the object class macro as specified in X.501. The above example shows the main features. There are many more examples which can studied in the section defining the Pilot Object Classes. 4.2. Attribute type proforma This section gives an example completed proforma for a new attribute type, hue (one of the attribute types in the alcoholic drink object class). Barker & Kille [page 7] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 Attribute Type: Hue Description: The Hue attribute type specifies the hue of an object. ASN1ATMacro:hue ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-hue)) ub-hue INTEGER ::= 256 An attribute type description consists of three fields, separated by blank lines. The keywords Attribute Type, Description and ASN1ATMacro, and their suffixed colons, must be included exactly as above. The Attribute Type field should be used for a textual description of the attribute type. This will be at most three or four words. The Description field should contain some explanatory text about the intended use of the attribute type. This can run to a number of lines. The ASN1ATMacro field should follow the definition of the attribute macro as specified in X.501. The above example shows some of the features. In particular, please note the format for specifying size constraints . 5. Removing "old" object classes and attribute types. It is also important that object classes and attribute types which are no longer used or useful are removed from the naming architecture. Some object classes and attribute types initially defined as pilot extensions may be included as standard definitions in future versions of the standard. In such a case, it is important that there should be a fairly rapid transition to the standard definitions. Another possibility is that newer, more specific definitions obviate the original definitions. Two things are essential. First, it is crucial that "old" Barker & Kille [page 8] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 definitions are retired as gracefully as possible. This will be achieved by maintaining the definitions to be expired as part of the naming architecture for a limited period. They will be included in the architecture along with an indication of their expiry date. Users of the architecture should ensure that they make the transition to new, alternative definitions in the interim. Second, users of the architecture must have the right to argue for the retention of definitions which they regard as necessary, there being no other definitions which closely meet their requirements. It is clearly impossible to lay down hard and fast rules on this point, as no two instances will ever be quite the same. It is intended that the refereeing on these matters will be sympathetic! As for requests for additions, an aggrieved user can "go to arbitration" by initiating a discussion on the ietf- osi-ds@cs.ucl.ac.uk mail list. 6. Object Classes 6.1. X.500 standard object classes A number of generally useful object classes are defined in X.521, and these are supported. Refer to that document for descriptions of the suggested usage of these object classes. The ASN.1 for these object classes is reproduced for completeness in Appendix C. 6.2. X.400 standard object classes A number of object classes defined in X.400 are supported. Refer to X.402 for descriptions of the usage of these object classes. The ASN.1 for these object classes is reproduced for completeness in Appendix C. 6.3. COSINE/Internet object classes This section attempts to fuse together the object classes designed for use in the COSINE and Internet pilot activities. Descriptions are given of the suggested usage of these object classes. The ASN.1 for these object classes is also reproduced in Appendix C. Barker & Kille [page 9] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 6.3.1. Pilot Object The PilotObject object class is used as a sub-class to allow some common, useful attributes to be assigned to entries of all other object classes pilotObject OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { info, photo, lastModifiedTime, lastModifiedBy} ::= {pilotObjectClass 3} 6.3.2. Pilot Person The PilotPerson object class is used as a sub-class of person, to allow the use of a number of additional attributes to be assigned to entries of object class person. Barker & Kille [page 10] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { userid, textEncodedORAddress, rfc822Mailbox, favouriteDrink, roomNumber, userClass, homePhone, homePostalAddress, secretary, personalTitle, localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, facsimileTelephoneNumber, businessCategory, title, otherMailbox, mobileTelephoneNumber, pagerTelephoneNumber} ::= {pilotObjectClass 4} 6.3.3. Account The Account object class is used to define entries representing computer accounts. The userid attribute should be used for naming entries of this object class. Barker & Kille [page 11] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 account OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userid} MAY CONTAIN { description, seeAlso, localityName, organizationName, organizationalUnitName, host} ::= {pilotObjectClass 5} 6.3.4. Document The Document object class is used to define entries which represent documents. document OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { documentIdentifier} MAY CONTAIN { commonName, description, seeAlso, localityName, organizationName, organizationalUnitName, documentTitle, documentVersion, documentAuthor, documentLocation} ::= {pilotObjectClass 6} 6.3.5. Room The Room object class is used to define entries representing rooms. The commonName attribute should be used for naming entries of this object class. Barker & Kille [page 12] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 room OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { roomNumber, description, seeAlso, telephoneNumber} ::= {pilotObjectClass 7} 6.3.6. Document Series The Document Series object class is used to define an entry which represents a series of documents (e.g. The Request For Comments papers). documentSeries OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, seeAlso, telephoneNumber, localityName, organizationName, organizationalUnitName} ::= {pilotObjectClass 9} 6.3.7. Domain The Domain object class is used to define entries which represent DNS or NRS domains. The domainComponent attribute should be used for naming entries of this object class. The usage of this object class is described in more detail in [3]. Barker & Kille [page 13] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 domain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { domainComponent} MAY CONTAIN { AssociatedName, organizationName, organizationalAttributeSet} ::= {pilotObjectClass 13} 6.3.8. RFC822 Local Part The RFC822 Local Part object class is used to define entries which represent the local part of RFC822 mail addresses. This treats this part of an RFC822 address as a domain. The usage of this object class is described in more detail in [3]. rFC822localPart OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { commonname, surname, description, seeAlso, telephoneNumber, postalAttributeSet, telecommunicationAttributeSet} ::= {pilotObjectClass 14} 6.3.9. DNS Domain The DNS Domain (Domain NameServer) object class is used to define entries for DNS domains. The usage of this object class is described in more detail in [3]. Barker & Kille [page 14] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dNSDomain OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { ARecord, MDRecord, MXRecord, NSRecord, SOARecord, CNAMERecord} ::= {pilotObjectClass 15} 6.3.10. NRS Domain The NRS Domain object class is used to define entries which represent NRS domains. The usage of this object class is described in more detail in [3]. nRSdomain OBJECT-CLASS SUBCLASS OF domain MUST CONTAIN { nRSSystemDescription} MAY CONTAIN { ForwardOnlyInformation, ReverseOnlyInformation, ForwardAndReverseInformation} ::= {pilotObjectClass 16} 6.3.11. Domain Related Object The Domain Related Object object class is used to define entries which represent DNS/NRS domains which are "equivalent" to an X.500 domain:e.g. an organisation or organisational unit. The usage of this object class is described in more detail in [3]. domainRelatedObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { AssociatedDomain} ::= {pilotObjectClass 17} Barker & Kille [page 15] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 6.3.12. Friendly Country The Friendly Country object class is used to define country entries in the DIT. The object class is used to allow friendlier naming of countries than that allowed by the object class country. The naming attribute of object class country, countryName, has to be a 2 letter string defined in ISO 3166. friendlyCountry OBJECT-CLASS SUBCLASS OF country MUST CONTAIN { friendlyCountryName} ::= {pilotObjectClass 18} 7. Attribute Types 7.1. X.500 standard attribute types A number of generally useful attribute types are defined in X.520, and these are supported. Refer to that document for descriptions of the suggested usage of these attribute types. The ASN.1 for these attribute types is reproduced for completeness in Appendix C. 7.2. X.400 standard attribute types The following standard X.400 attribute types are supported. See X.402 for full details. The ASN.1 for these attribute types is reproduced in Appendix C. 7.3. COSINE/Internet attribute types This section describes all the attribute types defined for use in the COSINE and Internet pilots. Descriptions are given as to the suggested usage of these attribute types. The ASN.1 for these attribute types is reproduced in Appendix C. 7.3.1. Userid The Userid attribute type specifies a login name on a host. Barker & Kille [page 16] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 userid ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-identifier)) ::= {pilotAttributeType 1} 7.3.2. Text Encoded O/R Address The Text Encoded O/R Address attribute type specifies a text encoding of an X.400 O/R address, as specified in RFC 987. The use of this attribute is deprecated as the attribute is intended for interim use only. textEncodedORaddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-text-encoded-or-address)) ::= {pilotAttributeType 2} 7.3.3. RFC 822 Mailbox The RFC822 Mailbox attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non- Internet order mailboxes. rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} 7.3.4. Information The Information attribute type specifies any general information pertinent to an object. It is recommended that specific usage of this attribute type is avoided, and that specific requirements are met by other (possibly additional) attribute types. Barker & Kille [page 17] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 info ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-information)) ::= {pilotAttributeType 4} 7.3.5. Favourite Drink The Favourite Drink attribute type specifies the favourite drink of an object (or person). favouriteDrink ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-favourite-drink)) ::= {pilotAttributeType 5} 7.3.6. Room Number The Room Number attribute type specifies the room number of an object. Note that the commonname attribute should be used for naming room objects. roomNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-room-number)) ::= {pilotAttributeType 6} 7.3.7. Photo The Photo attribute type specifies a "photograph" for an object. This should be encoded in G3 fax as explained in recommendation T.4. photo ATTRIBUTE WITH ATTRIBUTE-SYNTAX photo (SIZE (1 .. ub-photo)) ::= {pilotAttributeType 7} Barker & Kille [page 18] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 7.3.8. User Class The User Class attribute type specifies a category of user. Examples of user class in academia are undergraduate student, researcher, lecturer, etc. userClass ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-class)) ::= {pilotAttributeType 8} 7.3.9. Host The Host attribute type specifies a host computer. host ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-host)) ::= {pilotAttributeType 9} 7.3.10. Manager The Manager attribute type specifies the manager of an object represented by an entry. manager ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 10} 7.3.11. Document Identifier The Document Identifier attribute type specifies a unique identifier for a document. Barker & Kille [page 19] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 documentIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-identifier)) ::= {pilotAttributeType 11} 7.3.12. Document Title The Document Title attribute type specifies the title of a document. documentTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-title)) ::= {pilotAttributeType 12} 7.3.13. Document Version The Document Version attribute type specifies the version number of a document. documentVersion ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-version)) ::= {pilotAttributeType 13} 7.3.14. Document Author The Document Author attribute type specifies the distinguished name of the author of a document. documentAuthor ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 14} Barker & Kille [page 20] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 7.3.15. Document Location The Document Location attribute type specifies the location of the document original. documentLocation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-location)) ::= {pilotAttributeType 15} 7.3.16. Home Telephone Number The Home Telephone Number attribute type specifies a home telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567" homePhone ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 20} 7.3.17. Secretary The Secretary attribute type specifies the secretary of a person. The attribute value for Secretary is a distinguished name. secretary ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 21} 7.3.18. Other Mailbox The Other Mailbox attribute type specifies values for electronic mailbox types other than X.400 and rfc822. ??? something about the syntax. Barker & Kille [page 21] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 otherMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX SEQUENCE { mailboxType PrintableString, -- e.g. Telemail mailbox IA5String -- e.g. X378:Joe } ::= {pilotAttributeType 22} 7.3.19. Last Modified Time The Last Modified Time attribute type specifies the last time, in UTC time, that an entry was modified. lastModifiedTime ATTRIBUTE WITH ATTRIBUTE-SYNTAX uTCTimeSyntax ::= {pilotAttributeType 23} 7.3.20. Last Modified By The Last Modified By attribute specifies the distinguished name of the last user to modify the associated entry. lastModifiedBy ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 24} 7.3.21. Domain Component The Domain Component attribute type specifies a DNS/NRS domain. For example, "uk" or "ac". domainComponent ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax SINGLE VALUE ::= {pilotAttributeType 25} Barker & Kille [page 22] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 7.3.22. DNS ARecord The A Record attribute type specifies a type A (Address) DNS resource record [6] [7]. aRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 26} 7.3.23. MX Record The MX Record attribute type specifies a type MX (Mail Exchange) DNS resource record [6] [7]. mXRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 28} 7.3.24. NS Record The NS Record attribute type specifies an NS (Name Server) DNS resource record [6] [7]. nSRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 29} 7.3.25. SOA Record The SOA Record attribute type specifies a type SOA (Start of Authority) DNS resorce record [6] [7]. sOARecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 30} Barker & Kille [page 23] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 7.3.26. CNAME Record The CNAME Record attribute type specifies a type CNAME (Canonical Name) DNS resource record [6] [7]. cNAMERecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 31} 7.3.27. Associated Domain The Associated Domain attribute type specifies a DNS or NRS domain which is associated with an object in the DIT. For example, the entry in the DIT with a distinguished name "C=GB, O=University College London" would have an associated domain of "UCL.AC.UK. See [3] for more details of usage of this attribute. associatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 37} 7.3.28. Associated Name The Associated Name attribute type specifies an entry in the organisational DIT associated with a DNS/NRS domain. See [3] for more details of usage of this attribute. associatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 38} 7.3.29. Home postal address The Home postal address attribute type specifies a home postal address for an object. This should be limited to up to 6 lines of 30 characters each. Barker & Kille [page 24] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 homePostalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX postalAddress MATCHES FOR EQUALITY ::= {pilotAttributeType 39} 7.3.30. Personal Title The Personal Title attribute type specifies a personal title for a person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev". personalTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-personal-title)) ::= {pilotAttributeType 40} 7.3.31. Mobile Telephone Number The Mobile Telephone Number attribute type specifies a mobile telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567" mobileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 41} 7.3.32. Pager Telephone Number The Pager Telephone Number attribute type specifies a pager telephone number for an object. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567". Barker & Kille [page 25] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pagerTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 42} 7.3.33. Friendly Country Name The Friendly Country Name attribute type specifies names of countries in human readable format. The standard attribute country name must be one of the two-letter codes defined in ISO 3166. friendlyCountryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= {pilotAttributeType 43} 7.3.34. Organisational Identifier The Organisational Identifier attribute type specifies a unique identifier for a person within an organisation or organisational unit. organizationalIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-organizational-identifier)) ::= {pilotAttributeType 44} 7.4. Generally useful syntaxes caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS Barker & Kille [page 26] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 iA5StringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS -- Syntaxes to support the DNS attributes DNSRecordSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY NRSInformationSyntax ATTRIBUTE-SYNTAX NRSInformation MATCHES FOR EQUALITY NRSInformation ::= SET { [0] Context, [1] Address-space-id, routes [2] SEQUENCE OF SEQUENCE { Route-cost, Addressing-info } } 7.5. Upper bounds on length of attribute values ub-document-identifier INTEGER ::= 256 ub-document-location INTEGER ::= 256 ub-document-title INTEGER ::= 256 ub-document-version INTEGER ::= 256 ub-favourite-drink INTEGER ::= 256 ub-host INTEGER ::= 256 ub-information INTEGER ::= 2048 Barker & Kille [page 27] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 ub-organizational-identifier INTEGER ::= 256 ub-personal-title INTEGER ::= 256 ub-photo INTEGER ::= 250000 ub-rfc822-mailbox INTEGER ::= 256 ub-room-number INTEGER ::= 256 ub-text-encoded-or-address INTEGER ::= 256 ub-user-class INTEGER ::= 256 ub-user-identifier INTEGER ::= 256 8. Authors' addresses Paul Barker and Steve Kille Department of Computer Science University College London Gower Street London WC1E 6BT England Phone: +44 71-380-7366 (Barker) +44 71-380-7294 (Kille) Email: P.Barker@cs.ucl.ac.uk S.Kille@cs.ucl.ac.uk Barker & Kille [page 28] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 References [1] X.500, The Directory - overview of concepts, models and services, CCITT /ISO IS 9594 [2] S.E. Kille, The THORN and RARE X.500 Naming Architecture, in University College London, Department of Computer Science Research Note 89/48, May 1989. [3] S.E. Kille, X.500 and Domains, in University College London, Department of Computer Science Research Note 89/47, May 1989 [4] M.T. Rose, PSI/NYSERNet White Pages Pilot Project: Status Report, Technical Report 90-09-10-1, published by NYSERNet Inc, 1990 [5] J. Craigie, UK Academic Community Directory Service Pilot Project, pp. 305-310 in Computer Networks and ISDN Systems 17 (1989), published by North Holland. [6] P. Mockapetris, Domain Names - Concepts and Facilities, RFC-1034, USC Information Sciences Institute, November 1987 [7] P. Mockapetris, Domain Names - Implementation and Specification, RFC-1035, USC Information Sciences Institute, November 1987 Barker & Kille [page 29] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX A - Object Class and Attribute Type proformas These are specified in BNF. First some useful definitions, common to both proformas. EOL ::= -- the end of line character(s) BlankLine ::= -- a line consisting solely of an EOL character String ::= | anychar ::= --any character occurring in general text, excluding the end -- of line character lString ::= lowercase ::= [a-z] UString ::= uppercase ::= [A-Z] otherstring ::= | otherchar ::= | | Integer ::= | digit ::= [0-9] 1. Object Class OCProforma ::= \ ObjectClassName ::= "ObjectClass:" Description ::= "Description:" DescriptiveText ::= | Barker & Kille [page 30] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 OCMacro ::= "ASN1OCMacro:" -- The definition of ObjectClassMacro is adapted from that in X.501 ObjectClassMacro ::= "OBJECT-CLASS" \ OCName ::= SubclassOf ::= "SUBCLASS OF" Subclasses | Subclasses ::= | "," Subclass ::= MandatoryAttributes ::= "MUST CONTAIN {" "}" | OptionalAttributes ::= "MAY CONTAIN {" "}" | Attributes ::= | "," AttributeTerm ::= | Attribute ::= AttributeSet ::= 2. Attribute Type ATProforma ::= \ AttributeTypeName ::= "Attribute Type:" Description ::= "Description:" DescriptiveText ::= | ATMacro ::= "ASN1ATMacro:" -- The definition of AttributeTypeMacro is adapted from that in X.501 AttributeTypeMacro ::= "ATTRIBUTE" \ Barker & Kille [page 31] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 | ATName ::= AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice SyntaxChoice ::= | Syntax ::= Constraint ::= "(" ConstraintAlternative ")" | ConstraintAlternative ::= StringConstraint | IntegerConstraint StringConstraint ::= "SIZE" "(" SizeConstraint ")" SizeConstraint ::= SingleValue | Range SingleValue ::= Range ::= ".." IntegerConstraint ::= Range ASN1Type ::= -- one of ASN.1's base types: e.g. PrintableString, NumericString, etc. MatchTypes ::= "MATCHES FOR" Matches | Matches ::= Match | Matches Match Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING" Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | Barker & Kille [page 32] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX B - Format checking tools This section includes the source for format checking tools for the two proformas. The tools are written as Bourne shell scripts for UNIX systems. 1. Object class format checker sed 's/ *: */:/' | awk ' BEGIN { state = "initial" } /^$/ { next } /^Object Class:/ { n = index($0, ":") if (state != "initial") { print "Already got object class " oc print "Got another object class " substr($0, n+1) state = "notOK" exit 1 } oc = substr($0, n+1) state = "gotOC" next } /^Description:/ { n = index($0, ":") if (state != "gotOC") { print "Got Description: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Object Class:" else Barker & Kille [page 33] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 print "Expecting ASN1OCMacro:" state = "notOK" exit 1 } while (getline > 0) if (length($0) > 0) continue else break state = "gotDesc" next } /^ASN1OCMacro:/ { n = index($0, ":") if (state != "gotDesc") { print "Got ASN1Macro: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Object Class:" else print "Expecting Description:" state = "notOK" exit 1 } state = "OK" exit 0 } { print "Parsing has got confused on seeing line: " $0 state = "notOK" exit 1 } END { if (state == "OK") print "Input looks OK" } Barker & Kille [page 34] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 2. Attribute Type format checker sed 's/ *: */:/' | awk ' BEGIN { state = "initial" } /^$/ { next } /^Attribute Type:/ { n = index($0, ":") if (state != "initial") { print "Already got attribute type " at print "Got another attribute type " substr($0, n+1) state = "notOK" exit 1 } at = substr($0, n+1) state = "gotAT" next } /^Description:/ { n = index($0, ":") if (state != "gotAT") { print "Got Description: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Attribute Type:" else print "Expecting ASN1ATMacro:" state = "notOK" exit 1 } while (getline > 0) if (length($0) > 0) Barker & Kille [page 35] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 continue else break state = "gotDesc" next } /^ASN1ATMacro:/ { n = index($0, ":") if (state != "gotDesc") { print "Got ASN1Macro: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Attribute Type:" else print "Expecting Description:" state = "notOK" exit 1 } state = "OK" exit 0 } { print "Parsing has got confused on seeing line: " $0 state = "notOK" exit 1 } END { if (state == "OK") print "Input looks OK" } Barker & Kille [page 36]   Return-Path: Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13589-0@bells.cs.ucl.ac.uk>; Wed, 21 Nov 1990 17:20:11 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Internet Draft for Naming Architecture (part 2) Date: Wed, 21 Nov 90 17:20:07 +0000 From: Paul Barker ... and this is the second half of a draft naming architecture. The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX C - Summary of all Object Classes and Attribute Types -- Standard Object Classes top OBJECT-CLASS MUST CONTAIN { objectClass} ::= {objectClass 0} alias OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { aliasedObjectName} ::= {objectClass 1} country OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { countryName} MAY CONTAIN { description, searchGuide} ::= {objectClass 2} locality OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { description, localityName, stateOrProvinceName, searchGuide, seeAlso, streetAddress} ::= {objectClass 3} Barker & Kille [page 37] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organization OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 4} organizationalUnit OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationalUnitName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 5} person OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, surname} MAY CONTAIN { description, seeAlso, telephoneNumber, userPassword} ::= {objectClass 6} organizationalPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { localeAttributeSet, organizationalUnitName, postalAttributeSet, telecommunicationAttributeSet, title} ::= {objectClass 7} Barker & Kille [page 38] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organizationalRole OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localeAttributeSet, organizationalUnitName, postalAttributeSet, preferredDeliveryMethod, roleOccupant, seeAlso, telecommunicationAttributeSet} ::= {objectClass 8} groupOfNames OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, member} MAY CONTAIN { description, organizationName, organizationalUnitName, owner, seeAlso, businessCategory} ::= {objectClass 9} residentialPerson OBJECT-CLASS SUBCLASS OF person MUST CONTAIN { localityName} MAY CONTAIN { localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, telecommunicationAttributeSet, businessCategory} ::= {objectClass 10} Barker & Kille [page 39] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 applicationProcess OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localityName, organizationalUnitName, seeAlso} ::= {objectClass 11} applicationEntity OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, presentationAddress} MAY CONTAIN { description, localityName, organizationName, organizationalUnitName, seeAlso, supportedApplicationContext} ::= {objectClass 12} dSA OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { knowledgeInformation} ::= {objectClass 13} Barker & Kille [page 40] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 device OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localityName, organizationName, organizationalUnitName, owner, seeAlso, serialNumber} ::= {objectClass 14} strongAuthenticationUser OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userCertificate} ::= {objectClass 15} certificationAuthority OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { cACertificate, certificateRevocationList, authorityRevocationList} MAY CONTAIN { crossCertificatePair} ::= {objectClass 16} -- Standard MHS Object Classes Barker & Kille [page 41] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsDistributionList OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, mhsDLSubmitPermissions, mhsORAddresses} MAY CONTAIN { description, organizationName, organizationalUnitName, owner, seeAlso, mhsDeliverableContentTypes, mhsdeliverableEits, mhsDLMembers, mhsPreferredDeliveryMethods} ::= {mhsObjectClass 0} mhsMessageStore OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { description, owner, mhsSupportedOptionalAttributes, mhsSupportedAutomaticActions, mhsSupportedContentTypes} ::= {mhsObjectClass 1} mhsMessageTransferAgent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { description, owner, mhsDeliverableContentLength} ::= {mhsObjectClass 2} Barker & Kille [page 42] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsOrganizationalUser OBJECT-CLASS SUBCLASS OF organizationalPerson MUST CONTAIN { mhsORAddresses} MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsMessageStoreName, mhsPreferredDeliveryMethods } ::= {mhsObjectClass 3} mhsResidentialUser OBJECT-CLASS SUBCLASS OF residentialPerson MUST CONTAIN { mhsORAddresses} MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsMessageStoreName, mhsPreferredDeliveryMethods } ::= {mhsObjectClass 4} mhsUserAgent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsORAddresses, owner} ::= {mhsObjectClass 5} -- Pilot Object Classes Barker & Kille [page 43] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotObject OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { info, photo, lastModifiedTime, lastModifiedBy} ::= {pilotObjectClass 3} pilotPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { userid, textEncodedORAddress, rfc822Mailbox, favouriteDrink, roomNumber, userClass, homePhone, homePostalAddress, secretary, personalTitle, localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, facsimileTelephoneNumber, businessCategory, title, otherMailbox, mobileTelephoneNumber, pagerTelephoneNumber} ::= {pilotObjectClass 4} Barker & Kille [page 44] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 account OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userid} MAY CONTAIN { description, seeAlso, localityName, organizationName, organizationalUnitName, host} ::= {pilotObjectClass 5} document OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { documentIdentifier} MAY CONTAIN { commonName, description, seeAlso, localityName, organizationName, organizationalUnitName, documentTitle, documentVersion, documentAuthor, documentLocation} ::= {pilotObjectClass 6} room OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { roomNumber, description, seeAlso, telephoneNumber} ::= {pilotObjectClass 7} Barker & Kille [page 45] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 documentSeries OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, seeAlso, telephoneNumber, localityName, organizationName, organizationalUnitName} ::= {pilotObjectClass 9} domain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { domainComponent} MAY CONTAIN { AssociatedName, organizationName, organizationalAttributeSet} ::= {pilotObjectClass 13} rFC822localPart OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { commonname, surname, description, seeAlso, telephoneNumber, postalAttributeSet, telecommunicationAttributeSet} ::= {pilotObjectClass 14} Barker & Kille [page 46] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dNSDomain OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { ARecord, MDRecord, MXRecord, NSRecord, SOARecord, CNAMERecord} ::= {pilotObjectClass 15} nRSdomain OBJECT-CLASS SUBCLASS OF domain MUST CONTAIN { nRSSystemDescription} MAY CONTAIN { ForwardOnlyInformation, ReverseOnlyInformation, ForwardAndReverseInformation} ::= {pilotObjectClass 16} domainRelatedObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { AssociatedDomain} ::= {pilotObjectClass 17} friendlyCountry OBJECT-CLASS SUBCLASS OF country MUST CONTAIN { friendlyCountryName} ::= {pilotObjectClass 18} -- Standard Attribute Types objectClass ObjectClass ::= {attributeType 0} Barker & Kille [page 47] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 aliasedObjectName AliasedObjectName ::= {attributeType 1} knowledgeInformation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreString ::= {attributeType 2} commonName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-common-name)) ::= {attributeType 3} surname ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-surname)) ::= {attributeType 4} serialNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX printableStringSyntax (SIZE (1..ub-serial-number)) ::= {attributeType 5} countryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (1..ub-country-code)) SINGLE VALUE ::= {attributeType 6} localityName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-locality-name)) ::= {attributeType 7} stateOrProvinceName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-state-name)) ::= {attributeType 8} streetAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-street-address)) ::= {attributeType 9} Barker & Kille [page 48] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organizationName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-organization-name)) ::= {attributeType 10} organizationalUnitName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-organizational-unit-name)) ::= {attributeType 11} title ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-title)) ::= {attributeType 12} description ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-description)) ::= {attributeType 13} searchGuide ATTRIBUTE WITH ATTRIBUTE-SYNTAX Guide ::= {attributeType 14} businessCategory ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-business-category)) ::= {attributeType 15} postalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PostalAddress MATCHES FOR EQUALITY ::= {attributeType 16} postalCode ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-postal-code)) ::= {attributeType 17} postOfficeBox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-post-office-box)) ::= {attributeType 18} Barker & Kille [page 49] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 physicalDeliveryOfficeName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-physical-office-name)) ::= {attributeType 19} telephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax (SIZE (1..ub-telephone-number)) ::= {attributeType 20} telexNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX TelexNumber (SIZE (1..ub-telex)) ::= {attributeType 21} teletexTerminalIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier (SIZE (1..ub-teletex-terminal-id)) ::= {attributeType 22} facsimileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber ::= {attributeType 23} x121Address ATTRIBUTE WITH ATTRIBUTE-SYNTAX NumericString (SIZE (1..ub-x121-address)) ::= {attributeType 24} internationaliSDNNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX NumericString (SIZE (1..ub-isdn-address)) ::= {attributeType 25} registeredAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PostalAddress ::= {attributeType 26} destinationIndicator ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (1..ub-destination-indicator)) MATCHES FOR EQUALITY SUBSTRINGS ::= {attributeType 27} Barker & Kille [page 50] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 preferredDeliveryMethod ATTRIBUTE WITH ATTRIBUTE-SYNTAX deliveryMethod ::= {attributeType 28} presentationAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PresentationAddress MATCHES FOR EQUALITY ::= {attributeType 29} supportedApplicationContext ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax ::= {attributeType 30} member ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 31} owner ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 32} roleOccupant ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 33} seeAlso ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 34} userPassword ATTRIBUTE WITH ATTRIBUTE-SYNTAX Userpassword ::= {attributeType 35} userCertificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX UserCertificate ::= {attributeType 36} cACertificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX cACertificate ::= {attributeType 37} authorityRevocationList ATTRIBUTE WITH ATTRIBUTE-SYNTAX AuthorityRevocationList ::= {attributeType 38} Barker & Kille [page 51] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 certificateRevocationList ATTRIBUTE WITH ATTRIBUTE-SYNTAX CertificateRevocationList ::= {attributeType 39} crossCertificatePair ATTRIBUTE WITH ATTRIBUTE-SYNTAX CrossCertificatePair ::= {attributeType 40} -- Standard MHS Attribute Types mhsDeliverableContentLength ATTRIBUTE WITH ATTRIBUTE-SYNTAX integer ::= {mhsAttributeType 0} mhsDeliverableContentTypes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 1} mhsDeliverableEits ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 2} mhsDLMembers ATTRIBUTE WITH ATTRIBUTE-SYNTAX oRName ::= {mhsAttributeType 3} mhsDLSubmitPermissions ATTRIBUTE WITH ATTRIBUTE-SYNTAX dLSubmitPermission ::= {mhsAttributeType 4} mhsMessageStoreName ATTRIBUTE WITH ATTRIBUTE-SYNTAX dN ::= {mhsAttributeType 5} mhsORAddresses ATTRIBUTE WITH ATTRIBUTE-SYNTAX oRAddress ::= {mhsAttributeType 6} mhsPreferredDeliveryMethods ATTRIBUTE WITH ATTRIBUTE-SYNTAX deliveryMethod ::= {mhsAttributeType 7} Barker & Kille [page 52] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsSupportedAutomaticActions ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 8} mhsSupportedContentTypes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 9} mhsSupportedOptionalAttributes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 10} -- Pilot Attribute Types userid ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-identifier)) ::= {pilotAttributeType 1} textEncodedORaddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-text-encoded-or-address)) ::= {pilotAttributeType 2} rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} info ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-information)) ::= {pilotAttributeType 4} Barker & Kille [page 53] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 favouriteDrink ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-favourite-drink)) ::= {pilotAttributeType 5} roomNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-room-number)) ::= {pilotAttributeType 6} photo ATTRIBUTE WITH ATTRIBUTE-SYNTAX photo (SIZE (1 .. ub-photo)) ::= {pilotAttributeType 7} userClass ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-class)) ::= {pilotAttributeType 8} host ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-host)) ::= {pilotAttributeType 9} manager ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 10} Barker & Kille [page 54] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 documentIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-identifier)) ::= {pilotAttributeType 11} documentTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-title)) ::= {pilotAttributeType 12} documentVersion ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-version)) ::= {pilotAttributeType 13} documentAuthor ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 14} documentLocation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-location)) ::= {pilotAttributeType 15} homePhone ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 20} Barker & Kille [page 55] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 secretary ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 21} otherMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX SEQUENCE { mailboxType PrintableString, -- e.g. Telemail mailbox IA5String -- e.g. X378:Joe } ::= {pilotAttributeType 22} lastModifiedTime ATTRIBUTE WITH ATTRIBUTE-SYNTAX uTCTimeSyntax ::= {pilotAttributeType 23} lastModifiedBy ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 24} domainComponent ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax SINGLE VALUE ::= {pilotAttributeType 25} aRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 26} Barker & Kille [page 56] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mXRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 28} nSRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 29} sOARecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 30} cNAMERecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 31} associatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 37} associatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 38} homePostalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX postalAddress MATCHES FOR EQUALITY ::= {pilotAttributeType 39} Barker & Kille [page 57] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 personalTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-personal-title)) ::= {pilotAttributeType 40} mobileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 41} pagerTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 42} friendlyCountryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= {pilotAttributeType 43} organizationalIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-organizational-identifier)) ::= {pilotAttributeType 44} -- Generally useful syntaxes caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS iA5StringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS Barker & Kille [page 58] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 -- Syntaxes to support the DNS attributes DNSRecordSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY NRSInformationSyntax ATTRIBUTE-SYNTAX NRSInformation MATCHES FOR EQUALITY NRSInformation ::= SET { [0] Context, [1] Address-space-id, routes [2] SEQUENCE OF SEQUENCE { Route-cost, Addressing-info } } -- Upper bounds on length of attribute values ub-document-identifier INTEGER ::= 256 ub-document-location INTEGER ::= 256 ub-document-title INTEGER ::= 256 ub-document-version INTEGER ::= 256 ub-favourite-drink INTEGER ::= 256 ub-host INTEGER ::= 256 ub-information INTEGER ::= 2048 ub-organizational-identifier INTEGER ::= 256 ub-personal-title INTEGER ::= 256 Barker & Kille [page 59] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 ub-photo INTEGER ::= 250000 ub-rfc822-mailbox INTEGER ::= 256 ub-room-number INTEGER ::= 256 ub-text-encoded-or-address INTEGER ::= 256 ub-user-class INTEGER ::= 256 ub-user-identifier INTEGER ::= 256 Barker & Kille [page 60] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX D - Concise summary of all Object Classes and Attribute Types This appendix is included for comment on the usefulness of a more concise format for the architecture. A few examples of object classes and attribute types are given. # Object class table # # oc name : subclass of : must contain : may contain : oid # top : : objectClass: : objectClass.0 country : top : countryName : description, searchGuide : objectClass.1 pilotObject: top : : info, photo, lastModifiedTime, lastModifiedBy : \ pilotObjectClass.3 # Attribute type table # # at name : syntax : size : multi-single valued : matching : oid # # empty size field implies no SIZE clause # empty multi-single valued field implies MULTI VALUED, otherwise takes # values SINGLE or MULTI # empty matching field implies no matching clause, otherwise takes # (possibly a combination of) values EQUALITY, SUBSTRINGS, ORDERING # objectClass : objectIdentifier : : : : attributeType.0 commonName : caseIgnoreString : 64 : : : attributeType.3 countryName : PrintableString : 2 : SINGLE : : attributeType.6 homePostalAddress : postalAddress : : : EQUALITY : pilotAttributeType.39 Barker & Kille [page 61]   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <16033-0@bells.cs.ucl.ac.uk>; Thu, 22 Nov 1990 13:12:16 +0000 Return-Path: Received: from VENERA.ISI.edu by bells.cs.ucl.ac.uk with SMTP inbound id <15300-0@bells.cs.ucl.ac.uk>; Thu, 22 Nov 1990 12:33:03 +0000 Received: by venera.isi.edu (5.61/5.61+local) id ; Wed, 21 Nov 90 10:49:40 -0800 Posted-Date: Wed, 21 Nov 90 13:37:11 -0500 Received-Date: Wed, 21 Nov 90 10:49:36 -0800 Received: from NRI.RESTON.VA.US by venera.isi.edu (5.61/5.61+local) id ; Wed, 21 Nov 90 10:49:36 -0800 Received: from NRI by NRI.NRI.Reston.VA.US id aa05971; 21 Nov 90 13:37 EST To: ietf@edu.isi.venera Cc: mdavies@us.VA.Reston.NRI Subject: Mailing 3 of 3: At-A-Glance, Directions and RSVP Date: Wed, 21 Nov 90 13:37:11 -0500 From: mdavies@us.VA.Reston.NRI Message-Id: <9011211337.aa05971@NRI.NRI.Reston.VA.US> Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Thu, 22 Nov 90 13:12:15 +0000 Resent-Message-ID: <1268.659279535@UK.AC.UCL.CS> Resent-From: Steve Kille Dear IETF'rs: This is the 3rd part of the SECOND Mailing to the IETF and includes the following items: 1) At-A-Glance: Hotel/flight info., etc. 2) Directions 3) RSVP ****The Proceedings are complimentary if you attend**** Megan -------------------- 19TH INTERNET ENGINEERING TASK FORCE AT-A-GLANCE DATE: December 2-7, 1990 HOST(S): Carol Ward - University of Colorado Don Morris - NCAR HOTEL/MEETING SITE: Clarion Harvest House 1345 Twenty-Eighth Street Boulder, CO 80302 (303) 443-3850 {fax:303-443-1480} 175 Rooms reserved (Govt. Rate) until Nov. 14 $55/single, $70/double Specify: IETF GROUP MESSAGES: Should be directed to attendees referencing "IETF Plenary" ALTERNATE ACCOM: The Golden Buff 1725 28th Avenue Boulder, CO 80301 (303) 442-7450 {fax:303-442-8788} (800) 999-BUFF 10 Rooms reserved until Nov. 26 $57/night Specify: IETF No. 34592 MEETING ROOMS: Clarion Harvest House 7pm - 12midnight PRE-REGISTRATION: Sunday, December 2, 1990 6pm - 8pm (reception during) Clarion Harvest House Room: TBD REGISTRATION: Monday, December 3, 1990 8am - 9am Clarion Harvest House Room: outside Ballroom AIRLINE: United Airlines (special rate roundtrip only) (800) 521-4041 (US/Canada reservations) (800) 722-5243 (Hawaii/Alaska reservations) Specify: IETF MEETING GROUP #0152-N AIRPORT: Stapleton International, Denver 27 Miles from Clarion Harvest Home (o/a 40min) SHUTTLE: "Airporter" $8.50each way (pay in cash/traveler's checks) (303) 321-3222 (reservations advisable) (near door 6 in baggage claim area) (8am-10:15pm on the hour & half hour) PARKING: Ample FREE parking at Hotel CLIMATE: Generally in the 50's in early December Snow a possibility (be prepared). Current temp : telnet refuge.colorado.edu 451 Denver forecast: finger weather@unidata.ucar.edu DIRECTIONS FROM STAPLETON AIRPORT TO CLARION HOTEL Take Quebec NORTH to 270. 270 will hit I-25 NORTH where 36 meets I-25. Take 36 WEST to Boulder. 36 WEST becomes 28th street entering Boulder. Follow 28th around the University. The Clarion is o/a TWO BLOCKS past the University on the LEFT (just before the Safeway). DIRECTIONS TO GOLDEN BUFF Follow directions above and proceed past the Clarion (about 4 Blocks) turning left onto Canyon Street. Make an immediate right into the Golden Buff parking lot. IETF RSVP Form 19th Internet Engineering Task Force December 2-7, 1990 Boulder, Colorado Please complete the following information and email or FAX to: Megan Davies at ietf-reg@nri.reston.va.us or (703) 620-0913. ____YES, I plan to attend the IETF Meeting in Boulder and I "DO" want a COMPLIMENTARY copy of the PROCEEDINGS. ____YES, I plan to attend the IETF Meeting in Boulder and I "DO NOT" want a copy of the PROCEEDINGS. ---- NO, I do not plan to attend the IETF Meeting in Boulder but I "DO" want to ORDER a copy of the PROCEEDINGS. Please mail a hard copy of this RSVP Form along with a check for $35.00 Pay/Mail To: Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091 ATTN: IETF Proceedings To insure accurate records and timely correspondence, please provide the following information: 1. Name (Mr/Dr/Ms/Prof):_______________________________ Title: _______________________________ Organization: _______________________________ _______________________________ Department: _______________________________ Street: _______________________________ _______________________________ P.O. Box/Mail Stop: _______________________________ Building/Suite: _______________________________ City/State/Zip: _______________________________ 2. Phone: _______________________________ Fax: _______________________________ E-mail: _______________________________ 3. Date of expected arrival at the hotel: __________ Date of expected departure from the hotel:__________ 4. Form of daily transportation I plan to use: Hotel Shuttle:__________________ Rental car: __________________ Other: __________________   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17934-0@bells.cs.ucl.ac.uk>; Thu, 22 Nov 1990 14:13:26 +0000 To: osi-ds@uk.ac.ucl.cs cc: Greg Vaudreuil Subject: Interent Draft on Proposed Replication Solution Phone: +44-71-380-7294 Date: Thu, 22 Nov 90 14:13:25 +0000 Message-ID: <1557.659283205@UK.AC.UCL.CS> From: Steve Kille Here is the next internet draft. The postscript version is available from the UCL archive. Steve Network Working Group S.E. Kille INTERNET{DRAFT nnnn University College London November 1990 Replication to provide an Internet Directory using X.500: A proposed solution Status of this Memo Some requirements on extensions to X.500 are described in the INTERNET{ DRAFT [Kil90b], in order to build an Internet Directory as described in the INTERNET{DRAFT [Kil90a]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. Transition to standard approaches can be considered when the standards have reached appropriate maturity. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET{DRAFT Replication Solutions November 1990 Contents 1 Approach 1 2 Extensions to Distributed Operations 2 3 Alternate DSA 3 4 Data Model 3 5 DSA Naming 3 6 Knowledge Representation 3 7 Replication Protocol 5 8 New Application Context 6 9 Migration and Scaling 6 10 Object Identifiers 6 11 Security Considerations 7 12 Author's Address 7 List of Figures 1 Knowledge Attributes : : : : : : : : : : : : : : : : : : : : : : 4 2 Replication Protocol : : : : : : : : : : : : : : : : : : : : : : : 5 1 Approach There are a number of non-negotiable requirements which must be met before a directory can be deployed on the Internet [Kil90b]. These problems are being tackled in the standards arena, but there is currently no stable solution. One approach would be to attempt to intercept the standard. Difficulties with this would be: o Defining a coherent intercept would be awkward, and the effort would probably be better devoted to working on the standard. It is not even clear that such an intercept could be defined. Kille Page 1 INTERNET{DRAFT Replication Solutions November 1990 o The target is moving, and it is always tempting to track it, thus causing more delay. o There would be a delay involved with this approach. It would be too late to be useful for a rapid start, and sufficiently close to the timing of the final standard that many would choose not to implement it. Therefore, we choose to take a simple approach. This is a good deal simpler than the full X.500 approach, and is based on operational experience. The advantages of this approach are: o It is proven in operation. This INTERNET{DRAFT is simply docu- menting what is being done already. o There will be a minimum of delay in starting to use the approach. o The approach is simpler, and so the cost of implementation is much less. It will therefore be much more attractive to add into an imple- mentation, as it is less effort, and can be further ahead of the standard. 2 Extensions to Distributed Operations The extension to distributed operations is a simple one. It relies on the approach being taken to encode Network Addresses when the OSI Network Service is not used. This approach is described in [Kil89]. The encoding allows two Network Addresses to be examined to see if they belong to the same \community" (i.e., whether or not entities at the addresses can com- municate directly). Two presentation addresses can then be examined, in order to see if they have a common \community". Two extensions are needed: 1. When a DSA makes a chain/referral choice, it should examine the presentation addresses of the DSA to be referred to and the DSA or DUA to which a referral would be passed1.If they cannot commu- nicate directly, chaining must be used. The DSA must be able to determine the presentation address of the DSA calling it. This is not implied by the standard, but is implied by the procedures defined in this INTERNET{DRAFT . 2. If a DSA follows a referral it should check that it is able (in principle) to access one of the \communities" of the DSA it is calling. If it is not, then it should do one of the following: (a) Use a \relay DSA" to access the community ____________________________1 In the case of DUA, it may not be possible to determine the presentation add* *ress, and so chaining will have to be used except in the case where a DUA uses a comm* *unity supported by the DSA to be referred to. Kille Page 2 INTERNET{DRAFT Replication Solutions November 1990 (b) Pass the query to a DSA it would use to resolve a query higher in the DIT. This will work, provided that this DSA follows the same procedures. 3 Alternative DSAs There is a need to give information on slave copies of data. This can be done using the standard protocol, but modifying the semantics: Subordinate/Cross Reference In the standard, only one reference can be given, even though the protocol allows for several. Relax this re- striction, and define the first reference to be to the master copy. Non-specific Subordinate Reference Change the semantics of the NSSR from OR to AND { this aligns with the data model proposed below. The first reference should then be the master. 4 Data Model The X.500 data model takes the unit of operation as the entry. QUIPU chose to make the base unit as the set of sibling entries (or Entry Data Block). Knowledge information is represented within the DIT. It is proposed that this model is initially used on the Internet. It has the following advantages. o Name resolution is simplified, and performance improved. o Single level searching and listing have good performance, and are straightforward to implement. In a more general case of applying the standard, without sophisticated replication, these operations would require to access very many DSAs, and be prohibitively expensive. 5 DSA Naming All DSAs must be named in the DIT, and the master definition of the pre- sentation address stored in this entry. X.500 (including some of the exten- sion work) implies that the presentation address information is extensively replicated (manually). Care must be taken to prevent looping. This is solved by: 1. Use of a well known DSA with \root knowledge" 2. Naming DSAs to prevent deadlocks. Currently this is done by giving DSAs names high in the DIT. Kille Page 3 INTERNET{DRAFT Replication Solutions November 1990 6 Knowledge Representation Knowledge information should be represented in the DIT. It seems unrea- sonable to manage this by any other means. The information framework needed to support this is defined in Figure 1. ______________________________________________________________________ InternetDSNonLeafObject ::= OBJECTCLASS SUBCLASS OF top MUST CONTAIN fmasterDSAg MAY CONTAIN fslaveDSAg ExternalNonLeafObject ::= OBJECTCLASS SUBCLASS OF top MAY CONTAIN fSubordinateReference, CrossReference, 10 NonSpecificSubordinateReferenceg at least one MasterDSA ::= ATTRIBUTE WITH ATTRIBUTESYNTAX distinguishedNameSyntax SINGLE VALUE SlaveDSA ::= ATTRIBUTE WITH ATTRIBUTESYNTAX distinguishedNameSyntax 20 SubordinateReference ::= ATTRIBUTE WITH ATTRIBUTESYNTAX AccessPoint SINGLE VALUE CrossReference ::= ATTRIBUTE WITH ATTRIBUTESYNTAX AccessPoint SINGLE VALUE NonSpecificSubordinateReference ::= ATTRIBUTE WITH ATTRIBUTESYNTAX AccessPoint 30 AccessPoint ::= SET f aetitle [0] Name, address [2] PresentationAddress OPTIONAL g Same definition as X.500 AccessPoint, but presentation address is optional ____________________Figure_1:_Knowledge_Attributes____________________ Two object classes are defined, and some associated attributes. Where the data model of this specification is followed, there must be an entry for each sibling, which should be of one of these two object classes, InternetDSNonLeafObject This is for where the level below follows the model defined here, and there is an Entry Data Block (EDB) of the Kille Page 4 INTERNET{DRAFT Replication Solutions November 1990 sibling entries. The Entry itself contains master data. The associated attributes are: MasterDSA The name of the DSA where the master EDB is held. SlaveDSA The names of DSAs which hold slave copies of the EDB for public access. ExternalNonLeafObject This is for where the entry and levels below are mastered according to X.500. There are attributes corresponding to the standard knowledge references, which are used to resolve queries. The presentation address is optional in these attributes. If not present, it should be looked up in the DSAs own entry. For NonSpecificSubor- dinateReference, the master of the entry will be in the master EDB, For SubordinateReference or CrossReference2 the DSA which masters the EDB will \spot shadow" the entry, by reading it at intervals. This will ensure that the master EDB contains a copy of each entry. Single level searching can then be done efficiently where it is not required to access the master copy of the data. The \spot shadowing" is trans- parent to DSAs which are taking slave copies of the EDB. 7 Replication Protocol A ROS operation to support replication is defined in Figure 2. This pulls an entire copy of the EDB, with the simple optimisation that a copy is not transferred if the version is the same. This optimisation is the main reason for using a special operation, rather than placing a file in a well known location. The data is pulled. This approach is simple to implement. It is less efficient than an incremental technique. When scaling dictates that an incremental technique must be used, it is expected that a suitable standard will be available. This protocol will be used by DSAs to obtain copies of EDBs high in the tree (typically root and national EDBs). DSAs which need these copies should establish bilateral agreements to access them3. 8 New Application Context A DSA which follows these procedures will support a new ApplicationCon- text \Internet DSP" (value to be defined). This will be stored in the DSAs entry, so that support of the extensions defined here can easily be deter- mined. ____________________________2 These references are really the same. The function an value are the same. Th* *e name depends on where the reference is stored. It may be preferable to have only one* * attribute. 3QUIPU defines some attributes to register such agreements, but these are pr* *obably not appropriate for this specification. Kille Page 5 INTERNET{DRAFT Replication Solutions November 1990 ______________________________________________________________________ GetEntryDataBlock ABSTRACTOPERATION ARGUMENT GetEntryDataBlockArgument RESULT GetEntryDataBlockResult ERRORS fNameError,ServiceError,SecurityErrorg getEntryDataBlock GetEntryDataBlock ::= 10 Might be preferable to use an OBJECT IDENTIFER to an INTEGER 10 GetEntryDataBlockArgument ::= SET f entry [0] DistinguishedName, sendIfMoreRecentThan [1] EDBVersion OPTIONAL if omitted, just return version held To force send, specify old version g GetEntryDataBlockResult ::= SEQUENCE f versionHeld [0] EDBVersion 20 [1] EntryDataBlock OPTIONAL g g EDBVersion ::= UTCTime _____________________Figure_2:_Replication_Protocol___________________ 9 Migration and Scaling The major scaling limit of this approach is the non-incremental update. This will put a limit on the maximum DIT fanout which can be supported. Given an entry size of a few hundred bytes, and a maximum reasonable transfer size is a few megabytes, then the fanout limit of this approach is of order 10 000. Note that smaller organisations will tend to be registered geographically (e.g., in the US, by State), so that the limit of the number of Organisations is somewhat larger. These techniques do not preclude use of other techniques for replication. It would be quite reasonable to replicate data using this approach, and that which will be defined in X.500(92). 10 Object Identifiers A future version of this specification needs to define Object Identifiers for Application Context, Object Classes, and Attributes. Kille Page 6 INTERNET{DRAFT Replication Solutions November 1990 References [Kil89] S.E. Kille. An interim approach to use of network addresses. Re- search Note RN/89/13, Department of Computer Science, Univer- sity College London, February 1989. Internet Draft: DRAFT-UCL- KILLE-NETWORKADDRESSES-00.PS.1. [Kil90a]S.E. Kille. Building and internet directory using X.500, November 1990. Internet Draft: draft-ietf-osix500-directories-00.txt. [Kil90b]S.E. Kille. Replication requirement to provide an internet directory using X.500, November 1990. Submitted as an Internet Draft. 11 Security Considerations Security considerations are not discussed in this INTERNET{DRAFT . 12 Author's Address Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Kille Page 7   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25210-0@bells.cs.ucl.ac.uk>; Fri, 23 Nov 1990 11:35:14 +0000 To: arch2!youbong@com.att.attunix cc: osi-ds@uk.ac.ucl.cs, rare-wg3@de.dbp.gmd.xps Subject: Re: RARE WG3 and the IETF OSI DS group Phone: +44-71-380-7294 In-reply-to: Your message of Wed, 24 Oct 90 16:03:00 -0400. Date: Fri, 23 Nov 90 11:35:12 +0000 Message-ID: <977.659360112@UK.AC.UCL.CS> From: Steve Kille Youbong - I meant to reply to this a while back. I certainly do not wish to restrict this activity to the academic community. I think that this work will need both Academic and Commercial input to be successful. At the first meeting, there were more commercial than academic participants, and my mailbox suggests that this will also be true in Boulder. Do you think that this goal needs to be explicity reflected in the "Scope" document of the group? Steve >From: arch2!youbong@com.att.attunix >To: attunix!att!cs.ucl.ac.uk!S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs, rare-wg3@de.dbp.gmd.xps >Subject: Re: RARE WG3 and the IETF OSI DS group >Date: Wed, 24 Oct 90 16:03 EDT >Steve, >I agree with you that the two groups need to build >the strong relationship. The three steps you stated >are the best to achieve the close liaison. >One comment, though. >I hope you did not mean only academic community by the 'research' >community. There were quite a few people representing commercial >vendors (including me) attending the first IETF osi-ds meeting >at Interop. I interpreted that many vendors showed interest >on deployment of X.500 Directory on Internet. >Youbong Weon-Yoon >AT&T   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11318-0@bells.cs.ucl.ac.uk>; Fri, 23 Nov 1990 20:24:39 +0000 To: osi-ds@uk.ac.ucl.cs Cc: lyman@edu.merit Subject: Three more internet drafts Phone: +44-71-380-7294 Date: Fri, 23 Nov 90 20:24:37 +0000 Message-ID: <3631.659391877@UK.AC.UCL.CS> From: Steve Kille I have modified the UFN paper to be an Internet Draft. And have revised the two addressing Internet Drafts. I'm not going to fill your mailboxes again! There are some technical changes in all of the docuemnts, and so those attending the Boulder meeting should all get copies. Steve nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille November 1990 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille November 1990 Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. ------------------------------------------------------------------------ The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 27 Nov 1990 18:17:33 +0000 Date: Tue, 27 Nov 1990 18:17:33 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.643:27.10.90.18.17.33] X400-Content-Type: P2-1984 (2) Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Tue, 27 Nov 1990 18:17:33 +0000) From: Andrew Macpherson Message-ID: <9011271648.AA01785@sakura.stl.stc.co.uk> To: P.Barker@uk.ac.ucl.cs, " (Steve Kille)" Cc: A.Macpherson@uk.co.stc.stl, osi-ds@uk.ac.ucl.cs Subject: Naming Architecture Reply-To: A.Macpherson@uk.co.stc.stl Phone: +44 279 429531 x2423 Organisation: STC Technology Ltd, Harlow, Essex, GB. Paul, Steve, The schema you present looks really useful, ie I think I can use it directly to good effect. Points: pilotPerson: must we have textencodedORaddress ? It is actively not useful --- it's likely to delay people putting up real mhs attributes [cf the current Pilot ;-)] dNSDomain: Whats an MDRecord? do you mean MBRecord? --- whichever it's never defined, and if the latter, possibly redundant as the same information is in another part of the tree as rFC822localPart aliases. Also DNS can have TEXT and INFO records. --- I'm not sure where TEXT is used (hesiod I think), but we certainly have INFO in our local nameserver. (two values --- both must be present: HOSTtype and OperatingSystem) -- Regards +-----+--+-------+--+-----------+--+--+--+--------+--------+ Andrew Macpherson | | | | | | | | | | | | +--+ +--+ | +-----+ +--+ | | +-----+ +--+--+ | | | | | | | | | | | | | | +--+ +--+----+-----+ +--+ +--+ +--+ +--+-----+ | | | | | | | | | | | | +-----+--+-------------+--+-----+--------+--+-----------+--+   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17576-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 12:08:28 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Archive index Phone: +44-71-380-7294 Date: Wed, 28 Nov 90 12:08:27 +0000 Message-ID: <1349.659794107@UK.AC.UCL.CS> From: Steve Kille This is the latest index. I have updated all of the documents with their IETF Draft keys. Attendees of the Boulder meeting should check that they have all of these. Documents still to come: - Revised Agenda - Security Internet Draft (from Peter Yee) - Updated Domain/X.500 paper Steve INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 3) S.E. Kille November 20, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practi- cal, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps Building and Internet Directory using X.500 S.E. Kille November 1990 draft-ietf-osix500-directories-00.txt Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" draft-ucl-kille-networkaddresses-01.txt, ps S.E. Kille November 1990 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-01.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. domain.ps Domains and X.500 S.E. Kille UCL Research Note RN/89/49 (June 1989) Novmember 1990 Abstract: This document considers X.500 in relation to Internet/UK Domains. A basic model of X.500 being \at the level above" is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming draft-ietf-osids-friendlynaming-00.txt, ps S.E. Kille November 1990 Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. repl-req.ps repl-reg.txt Replication Requirement to provide an Internet Directory using X.500` draft-ietf-osids-replication-00.txt S.E. Kille November 1990 Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. This INTERNET-DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. na.txt na.ps P. Barker S.E. Kille draft-ietf-osids-cosinex500-00.txt November 1990 The COSINE and Internet X.500 Naming Architecture Abstract: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, the primary intention of which is to provoke comments on the updating mechanisms. Readers should concentrate their attention on these aspects of the document, although corrections to the naming architecture should also be signalled. When the updating mechanisms have been settled, a call will be made for modifications to the naming architecture. repl-sol.txt repl-sol.ps Replication to provide an Internet Directory using X.500: A proposed solution draft-ietf-osids-replsoln-00.txt, ps S.E. Kille November 1990 Abstract: Some requirements on extensions to X.500 are described in the INTERNET DRAFT [Kil90b], in order to build an Internet Directory as described in the INTERNET-DRAFT [Kil90a]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. Transition to standard approaches can be considered when the standards have reached appropriate maturity. ------------------------------------------------------------------------   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17576-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 12:08:28 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Archive index Phone: +44-71-380-7294 Date: Wed, 28 Nov 90 12:08:27 +0000 Message-ID: <1349.659794107@UK.AC.UCL.CS> From: Steve Kille This is the latest index. I have updated all of the documents with their IETF Draft keys. Attendees of the Boulder meeting should check that they have all of these. Documents still to come: - Revised Agenda - Security Internet Draft (from Peter Yee) - Updated Domain/X.500 paper Steve INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 3) S.E. Kille November 20, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practi- cal, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps Building and Internet Directory using X.500 S.E. Kille November 1990 draft-ietf-osix500-directories-00.txt Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" draft-ucl-kille-networkaddresses-01.txt, ps S.E. Kille November 1990 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-01.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. domain.ps Domains and X.500 S.E. Kille UCL Research Note RN/89/49 (June 1989) Novmember 1990 Abstract: This document considers X.500 in relation to Internet/UK Domains. A basic model of X.500 being \at the level above" is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming draft-ietf-osids-friendlynaming-00.txt, ps S.E. Kille November 1990 Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. repl-req.ps repl-reg.txt Replication Requirement to provide an Internet Directory using X.500` draft-ietf-osids-replication-00.txt S.E. Kille November 1990 Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. This INTERNET-DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. na.txt na.ps P. Barker S.E. Kille draft-ietf-osids-cosinex500-00.txt November 1990 The COSINE and Internet X.500 Naming Architecture Abstract: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, the primary intention of which is to provoke comments on the updating mechanisms. Readers should concentrate their attention on these aspects of the document, although corrections to the naming architecture should also be signalled. When the updating mechanisms have been settled, a call will be made for modifications to the naming architecture. repl-sol.txt repl-sol.ps Replication to provide an Internet Directory using X.500: A proposed solution draft-ietf-osids-replsoln-00.txt, ps S.E. Kille November 1990 Abstract: Some requirements on extensions to X.500 are described in the INTERNET DRAFT [Kil90b], in order to build an Internet Directory as described in the INTERNET-DRAFT [Kil90a]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. Transition to standard approaches can be considered when the standards have reached appropriate maturity. ------------------------------------------------------------------------   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <20511-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 13:17:06 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Agenda - revision 1 Phone: +44-71-380-7294 Date: Wed, 28 Nov 90 13:17:04 +0000 Message-ID: <1678.659798224@UK.AC.UCL.CS> From: Steve Kille Here is a modified agenda in light of comments. Note the later start time. This is to allow everyone to attend the "how to get around the IETF" session. Steve Agenda for second meeting of IETF Directory Services Group (Revision 1) S.E. Kille 28th November Date 10:00 - 18:00: Monday 3rd December 1990 09:30 - 16:00: Tuesday 4th December 1990 Venue IETF Clarion Harvest House 1345 Twenty-Eighth Street Boulder, CO 80303 Tel: (303)-443-3850 Draft agenda follows. 1 Monday 10:00 Introduction o Agenda o Minutes of previous meeting o Matters arising 10:30 Liaisons o RARE WG3 o ISO/CCITT o NIST o NADF 11:00 PSI White Pages Pilot (Presentation by Marshall Rose of PSI) 11:20 FOX (Presentation by Paul Mockapetris of DARPA | to be con- firmed) 11:40 COSINE P2.1 (Presentation by Steve Kille) 1 12:00 Lunch 13:30 Scope of group and review of Charter 13:45 Infrastructure strategy (Internet Draft: Building an Internet Direc- tory using X.500) 14:15 Replication and related issues - requirements. Discussion of general approach. (Internet Draft: Replication Requirement to provide an Internet Directory using X.500) 15:30 Tea 16:00 Relationship to DNS (Document: Domains and X.500) 18:00 End 2 Tuesday 9:30 Names, Addresses and Identities: A Universal Name Service for a Multi-Media environment (Presentation by Gita Gopal of Bellcore). 10:00 Detailed issues on replication, addressing, and distributed operation. Relevant Internet Drafts (exact scope dependent on Monday's discus- sions): o Replication to provide an Internet Directory using X.500: A pro- posed solution o An Interim Approach to use of Network Addresses o A String encoding of Presentation Address 12:00 Lunch 13:30 Schema (Internet Draft: Cosine and Internet Naming Architecture) 14:45 Security 15:15 Date and Venue of next meeting 15:20-15:30 AOB 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <1075-0@bells.cs.ucl.ac.uk>; Wed, 28 Nov 1990 16:48:43 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Stunning timing from NIST Phone: +44-71-380-7294 Date: Wed, 28 Nov 90 16:48:40 +0000 Message-ID: <2697.659810920@UK.AC.UCL.CS> From: Steve Kille From: Eva Kuiper Message-Id: <9011202227.AA15777@hpindda.cup.hp.com> Subject: FYI - OSINET interim meeting To: mhsig@edu.UCI.ICS Date: Tue, 20 Nov 90 14:27:12 PST Cc: eva@com.hp.cup.hpindda Mailer: Elm [revision: 64.9] Sender: mhsig-request@edu.uci.ics Since some of you also attend OSINET, and since my email mailing list for OSINET is quite bare, I'm sending this out as a general announcement to gain a wider audience. Please pass this on to those who are involved in X.500 testing. Thanks, Eva Kuiper HP - --------------------------------------------------------------------------- Dear OSINET X.500 Interoperability Test Suite participants: Carol Edgar has found us a room at NIST for a working meeting of the OSINET X.500 participants. The meeting will be held at NIST on December 3 and 4 in Bldg 225 room B-220 starting at 9:00 on Monday and running until noon on Tuesday. Yes, we do get to break for the evening in between! Since I will be attending other meetings and since NIST and COS are participating in the test suite planning, the East coast seemed like a good place. The rainy season is starting in California anyway, so you won't be missing much by not coming to Cupertino. Please call me at 408-447-3163 or Carol at 301-975-3613 or send me email at eva@ce.hp.com. I'd like to start planning a timeline for getting X.500 implementations on OSINET to aid in test suite development. HP is willing to provide both DSP and DAP on OSINET for test development. I'd like to know from the other participants what is available for testing our tests. I will also be providing a writeup of the previous work at the next meeting. If you send me email at the above address, I can email you a copy before then. Hope to see you in December. Eva - ---- End of forwarded message. ------- End of Forwarded Message   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9100-0@bells.cs.ucl.ac.uk>; Thu, 29 Nov 1990 18:14:22 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Minutes of first meeting Phone: +44-71-380-7294 Date: Thu, 29 Nov 90 18:13:44 +0000 Message-ID: <2666.659902424@UK.AC.UCL.CS> From: Steve Kille IETF X500 Working Group First Meeting 11 Oct 1990 San Jose Ca. Attendees: Jose J. Garcia-Luna SRI joaquin@nisc.sri.com Steve Kille UCL s.kille@cs.ucl.uc.uk Bill Manning Texas Instruments bmanning@houston.sc.ti.com Sze-Ying Wuu JvNCnet, Princeton wuu@nisc.jvnc.net Nancy Schultz JvNCnet, Princeton schultz@nisc.jvnc.net Sergio Heker JvNCnet, Princeton heker@nisc.jvnc.net Alf Hansen UW-Madison Alf.Hansen@pilot.cs.wisc.edu Einar Stefferud NMA stef@ics.uci.edu Mimi Zohar IBM-Yorktown zohar@ibm.com Ly Loi 3COM lll@3com.com David Sutton Retix davids@retix.com YouBong Weon-Yoon ATT Bell Labs youbong@att.com Ken Rossen BBN Communications kenr@bbn.com Larry Kaufman BBN Communications lkaufman@bbn.com Bill Barns MITRE barns@gateway.miter.org Sally Tarquinia MITRE sallyt@gateway.miter.org Alex Brown BNR-Ottowa alex@bnr.ca Dave Brent CDNnet brent@cdnnet.ca Ross Callon DEC callon@bigfut.enet.dec.com Barry Holroyd SUN berries@eng.sun.com Richard Colella NIST colella@osi3.ncsl.nist.gov Thomas Maslen SUN maslen@eng.sun.com Charles Wolverton Aerospace Corp ctw@aero.org Mark L. Lambert Oracle markl@us.oracle.com Naresh Kumar Touch Communications naresh@touch.com Peter Mierswa DEC ------------------ Peter Yee NASA yee@ames.arc.nasa.gov Paul Koski HP koski@hpindog.cup.hp.com Dan Brown Tektronix dib@orca.wv.tek.com Greg Minshall Novell minshall@wc.novell.com Mary Anthony Novell manthony@wc.novell.com Louisa Thomson Hughes thomson@draco.hac.com Gihan Dias UC-Davis gdias@ucdavis.edu Robert Hagens UW-Madison hagens@cs.wisc.edu Dan Molinelli TRW moline@trw.com John Quarterman TIC jsq@tic.com Greg Brown Sterling Software browner@trident.arc.nasa.gov Mylene Marquez Sterling Software mylene@trident.arc.nasa.gov Mohsen Banan Boeing Computer Svcs mbanan@atc.boeing.com Adgenda: Intro/Welcome Background status X500 standardization (activity update) Internet X500 piloting (PSI pilot?) Worldwide pilot Scope & Charter discussion Adgenda agreement White Pages issues Naming Schema Naming Notation X500 extentions Relationship of X500 to DNS Application use of X500 Liaison with RARE-WG3 Date & Venue for next meeting Background & Status: Internet X500 pilot - at this time, it is a grassroots effort, no IAB support Scope & Charter: - Group to provide a framework for x500 pilot within Internet. Revisions to proposed scope V2 include Item 1 - X500 extentions Focus on Internet procedures of operation ie RFC's Avoid areas that will become standardized, but attempt to provide "interim" solutions that will intercept the CCITT/ISO solutions. Areas of concern are: * Replication Knowledge managment Schema managment Access control Authentication - both these should have intercept code from Oct90 Ottowa meeting * Distributied Operations for partially connceted DSAs Presentation Address handling * Areas that this group might profitably address. Item 2 - Application of the directory A prioritised list of areas that pertain to Internet are: i. DNS aspects ii. Yellow Pages and general searching iii. Privacy ie X509 "holes", RFC's 1113/4/5, Policy based routing iv. RFC 1148/987 (as a BOF?) Item 3 - Deployment 3.1 Schema Review THORN/RARE naming architectures as a basis for work. Item 4 - Liaison NIST is already involved via R.Colella S.Kille will initiate RARE WG3 contacts CCITT/ISO IEC - ??? NADF - [ES] to pursue. [ES] North American Directory Group summary: misson statment: collaborate for the purpose of establishing public directory services based on CCITT X500 recommendations and accelerate their implementations in North America and stage impleentations based on CCITT X500 specs. direction statment: decide local (NA) matters and work to resolve global issues. They are a planning forum and hope to flag standards problems. membership requirments: Any ADMD (X400), or ADDMD in NA. They must be willing to work with their peers. Operations is be consenise. Work is based on paper contributions. Approx. 55 documents so far. Overriding them all is a "living" document. member list: AT&T, Ameritech, BellLabs, Bell Atlantic, Bell South, Bellcore, GEIS, IBM-CA, ITT, MCI, Infonet, PACbell, PSI, IBM, Nynex, SWbell, US Postal Service, Sprint, Teleglobe-CA, Western Union. a program plan exists with dates for completion. these dates are INTERNAL targets only and not for public consumption. (there is already some slippage) already seperated into two subgroups: 1. service definitions 2. strawman schema - M. Rose is acting as a consultant here major agreement so far: Share information regarding the location of information holding record for All DN. In other words, Any given DN has a pointer to a DSA that holds the record for that DN. This data could be cached...maybe. [RC] Who owns the records? [ES] Still open for debate, but they must share some information. The minimal set seems to be the pointer to every DN. Can a provider charge for access to data they do NOT own? The problem: There is at least one telco and ADMD in each country. North America has quite a few. They are NOT forceably constrained to cooperate and ARE forceably constrained to compeate. [BM] What about offnet registrations, ie data NOT stored in a ADMD DSA, but in a private DSA? [ES] Not part of the agreements between providers. If the data is not in an NDAF DSA, then all bets are off, since DN's do not say who owns the record. [YB] How are areas handled, ie are there multiple owners by object class? [ES] Local telcos have odd service bounderies, but if you look in a directory, it contains no locality information (who "owns" my number). The real problem is with distributed entries. [SK] X500 replication should be on a per entry basis in a formal, controlled environment. There isn't the concept, as in DNS, of something polling up the tree for information. There is a view that X500 entries are "atomic" ie one person controls the entry not parts of that entry. The problem that Steff refered to was with distributed entries where someone maintains parts of an entry and someone else maintains other parts. For example your telco may want to manage your phone number, while the email provider may want to manage the address part. It is a very real requirment but technically awkward. NDAF has discussed the distributed entry problem and is hoping for it to be solved before implementation, however some feel they ought to proceed under the assumption that there will not be distributed entries. They will have to deal with it some other way. [SK] The issue of distributed entries is actuallly where you need to manage the data that is kept in the seperate DSAs, it might be a type of access control where you have the data in one DSA controlling access to data in a seperate DSA. [ES] Yes, this sharing is kind of interesting because presisley what file systems are presented and where the data resides becomes a matter of negotiation between parties on a per entry basis. (The potential for bandwidth consumption could be enormous! - WCM) [YB] Does that mean that more than one DSA holding partial resolution of an entry? [SK] That is the model that we would like to evolve. That is not what is happening at the moment. [YB] So there is more than one pointer to multiple DSAs? [SK] You get into a mess very rapidly in that case, but that is where its at. [ES] Yes, this is an unsolved technical problem and maybe an as yet udndefined researce problem. [SK] A more general point. It is known that we are trying to be assosicated with the depolyment of a pilot on the Internet. What sort of time frame might be available that could be useful for us? Such as when a registration authority might be available or operational DSAs that could be connected to? [ES] Working on getting some things defined, like service definitions, and design stuff by the end of January 91. Although those are VERY loose dates: Mapping DIA to multiple ADMDs - Jan 91; DSA/DSP operational - Apr 30 '91; Operational Managment Jul 91; Doesn't look like anything coming up prior to the end of 91. [YB] Any time frame for a demonstration? [ES] Not that are published. [ES] I asked Marshel Rose if he had any problems implementing the schema they (NADF) were talking about in his WP project? He said it was a subset of what he is working on. That didn't take care the business of sharing information. That is still being struggled with. ATT's Al Brumstead is working on the problem. The State Department is the USA arbitratior of ISO compliance. They will be responsible to ensure that US carriers will work with international carriers implementations. They have formed a sub-committee to deal with national decisons on X400/X500 issues, specifically to provide registration service and conceivably to write the rules for interworking within the US. The CCITT study group "D" will decide on 29 Oct if they will honor the charter of the group. If it happens, the first meeting will be on Dec 17/18 after the OSI workshop at the State Dept. Scope and Charter Discussion: 1. CCITT is working on Replication/Knowledge Representation. Is it interceptable? 2. Extended information model. subtrees/shared access control/group resources 3. Access control (CDAM stage) authorization is good, but needs ACL 4. schema extention - country/org etc imbedded in the directory 5. improve search / extended attributes - search has the most problems, externalize matching rules 6. intruduction of short form names - < 2 opposing camps in CCITT [RC] #3 may move as a fast track item prior to 92, a possible push for this group [Retix] #3 and replication may get DIS status in Mar'91 per Ottowa mtg. We need to: - define pilot requirements - ad hoc or intercepted stds? - how to share schema information - publish RFCs? - X/Open - POSIX - IETF 400/500 WG meet together? FTAM, VT and other OSI services are already on the Internet What is our compatibility with other working groups? two thrusts - X500 infrastructure - X500 services Schema: [SK] There seems to be a need, if we are going to deploy a pilot on the Internet that have agreement on the things that are to go into the directory and over the past few years and with some experience, particularly with the PSI pilot and the European pilot, that you find things in the directories that are not in the standards, such as mailbox addresses, favorite drinks, and other such useful things that are not defined by the standards. What I would like to see happen out of this group is to define those things that are Internet specific. I would like to see this happen in conjunction with the RARE work. I view the right way to do it is to have an increased involment in defining the Internet architecture for directory services by groups of people who say that they want this feature and that. There needs to be a means for registration on the Internet. [YB] What services does the pilot provide, that doesn't have X400 in it? [SK] The way the architecture, perhaps I've got one copy of it, of the early version, done for RARE, dated May'89. This architecture has been adopted by the PSI pilot, so it seems to be an acceptable beginning. [xx] Since this architecture has been accepted by two organizations, (PSI & RARE), lets make it three. (IETF) [SK] To do so will require that we publish RFC's. They are a little bit strange in that while in principle they carry very little status, but once things make it into RFC status they begin to carry a surprising ammount of weight. Should we publish these activities as RFC's? One of the reasons that Paul was not prepared to release the update was because one thing we wanted was to have a standard pro-forma for submitting requests for defining object classes. This should produce the documentation of the directory structure as well as machine parsable tables. Keeping schema consistant is a pain. Ought to publish an RFC that describes registration that is self documenting and creates machine readable inputs. What things should be registered in an Internet pilot? - Review THORN documentation as a basis. It uses UK/UCL numbers as offical numbers - CRNI's Knowbot ? - SRI-NIC whois database ? Should a "well known attributes" RFC be published? Can we publish/use IAB numbers? [JGL] PSI & NIST, with Internet (Merit,SRI,etc) spoke with Dr. Mockapetris on ISI evaluation. Will use NIST implementation guidelines. Populated with whois and Merit data. Only schema for Internet, not global scope. Name Notation: Proposed syntax - Review S.Kille papers DUA formats, notation which is not distributed name ported names map to quipu. ie FTAM, X500, MHS names RDN Mapped Ported (X400 "name") ------------------------------------------------------------- C=GB Steve Kille Kille, UCL, GB O=UCL Computer Science OU=Computer Science UCL, GB CN=Steve Kille [YBong] Applications, schema etc. can be used to define strings. X500 extentions: Authentication - a draft RFC was requested on a secure pilot. access control on the directory itself? Users should modify (portions) of their own information. This area needs stds and mechanisims published. QIPU has PKS but is unavailable in US (RSA restrictions) Do we want authentication & security in our pilot? - Yes. [RC] Should have an "open" pilot, with multi-implementation representation [PY] Will draft, with help, notes on desirable characterisics of ACL (X509) and authorizations needed to join the pilot. Emphsaise searching and distributed updates. last four - hope to have available by Jan'91 - Replication - Expand QUIPU specs uses protocols has data modeling - uses sibling entries ie DECdns spot shadowing - Knowledge Representation - Distributed Operations - for X.25 ONLY DSA's per RFC 1006 - Presentation Address formats - Check the RFC's [SK] These should be used but will entertain alternatives [ES] Does that mean vendors have to implement THREE forms? Existing, QUIPU, and future CCITT specs? [AB] Schema "kludge" for replication and Knowledge representation? [SK] Yes, but.... (Replication is OK but KR is VERY busy) X500/DNS X500 and domains - draft document describing how mapping might work. There is NOT a tight linkage between X500 and DNS tree structures. At a leaf node, (CN) there can be a linkage, using extended atributes. -------------------- Action items: X500 differences/similarities note to mail list - Richard Colella NIST colella@osi3.ncsl.nist.gov Route PSI presentation - Steve Kille UCL s.kille@cs.ucl.uc.uk Route X500/DNS paper. Jan'90 RFC draft to mail list - Steve Kille UCL s.kille@cs.ucl.uc.uk Circulate calls that replace gethostbyname with X500 / QUIPU API calls Include bind load and directory formats - Alex Brown BNR-Ottowa alex@bnr.ca Liasion request for Schema strawman for the IETF X500 WG from NADF - Einar Stefferud NMA stef@ics.uci.edu Add attendees to minutes - Bill Manning Texas Instruments bmanning@houston.sc.ti.com Circulate THORN documentation to mail list prior to Ineternet draft - Steve Kille UCL s.kille@cs.ucl.uc.uk Develop a draft RFC on secure additions for Internet X500 pilot - Peter Yee NASA yee@ames.arc.nasa.gov - Bill Manning Texas Instruments bmanning@houston.sc.ti.com Note on cahing and ACL approch for use in "secure" X509 RFC - Steve Kille UCL s.kille@cs.ucl.uc.uk - Richard Colella NIST colella@osi3.ncsl.nist.gov Circulate papers on : 1. what is QUIPU? 2. draft RFC on registration issues 3. Cover memo on why X500 - Steve Kille UCL s.kille@cs.ucl.uc.uk Soft copy of Ottowa meeting notes to mail list, particularly on replication - Alex Brown BNR-Ottowa alex@bnr.ca 400-NIST document on directory services for MHS - Einar Stefferud NMA stef@ics.uci.edu Regards, Bill Manning -   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9163-0@bells.cs.ucl.ac.uk>; Thu, 29 Nov 1990 18:16:30 +0000 To: osi-ds@uk.ac.ucl.cs Subject: PSI Slides Phone: +44-71-380-7294 Date: Thu, 29 Nov 90 18:15:52 +0000 Message-ID: <2686.659902552@UK.AC.UCL.CS> From: Steve Kille I had an action to send these to the list. Coming in the next message (large) Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9180-0@bells.cs.ucl.ac.uk>; Thu, 29 Nov 1990 18:16:59 +0000 To: osi-ds@uk.ac.ucl.cs Subject: PSI Slides - Large Phone: +44-71-380-7294 Date: Thu, 29 Nov 90 18:16:18 +0000 Message-ID: <2693.659902578@UK.AC.UCL.CS> From: Steve Kille Deleted.....   Return-Path: Received: from cathedral.cerc.wvu.wvnet.edu by bells.cs.ucl.ac.uk with SMTP inbound id <20331-0@bells.cs.ucl.ac.uk>; Thu, 29 Nov 1990 20:29:58 +0000 Received: by cerc.wvu.wvnet.edu (4.1/SMI-4.0:RAL-041790) id AA00640; Thu, 29 Nov 90 15:34:22 EST From: kannan@edu.wvnet.wvu.cerc (R. Kannan) Message-Id: <9011292034.AA00640@cerc.wvu.wvnet.edu> Subject: General info .... To: S.Kille@uk.ac.ucl.cs (Steve Kille) Date: Thu, 29 Nov 90 15:34:21 EST Cc: osi-ds@uk.ac.ucl.cs, kannan@uk.ac.ucl.cs (R. Kannan) In-Reply-To: <2569.659901733@UK.AC.UCL.CS>; from "Steve Kille" at Nov 29, 90 6:02 pm X-Mailer: ELM [version 2.3 PL6] Hello there I am research scientist at the concurrent engineering research center. My area of research is distributed computing. We are currently involved in implementing a support environment for dis. computing. We have a module that serves as a GENERIC DIRECTORY Service. This service is functionally described as follows: Users can define a new types of resources. Users can register instances of these resources. Users can delete these instances. Users can lookup these instances as well. This is done transparently from anywhere in a network of computers. Thus we think that this is very similar to x.500. Our current implemenation runs on TCP/IP and DOES NOT confirm to X.500. Our goal is to migrate to x.500 either by replacing the module with some external package that does what we want or tune our module to confirm to x.500. We invite comments and suggestions from the members OSI-DS group. Please do not hesitate if you have any questions regarding our module or anything else. Thank you very much.... Kannan For LCM Group, USPOST R.Kannan Drawer 2000 CERC, West Virginia University, Morgantown, WV 26505 Phone 304-293-7536 Fax 304-293-7541 E-mail kannan@cerc.wvu.wvnet.edu   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <816-0@bells.cs.ucl.ac.uk>; Fri, 30 Nov 1990 17:53:47 +0000 To: osi-ds@uk.ac.ucl.cs Subject: One last internet draft Phone: +44-71-380-7294 Date: Fri, 30 Nov 90 17:53:40 +0000 Message-ID: <2983.659987620@UK.AC.UCL.CS> From: Steve Kille I have made the few updates I promised. Some small changes, and additional information on Application Entity Titles, and representing Networks. Available from the UCL archive now. Steve Domains and X.500 S.E. Kille Novmember 1990 Abstract: This INTERNET-DRAFT considers X.500 in relation to Internet/UK Do- mains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community.   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <8288-0@bells.cs.ucl.ac.uk>; Tue, 4 Dec 1990 12:03:17 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Tue, 4 Dec 1990 11:57:05 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 4 Dec 1990 11:58:15 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 4 Dec 1990 13:00:00 +0000 Date: Tue, 4 Dec 1990 11:57:05 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.760:04.11.90.11.58.15] X400-Content-Type: P2-1984 (2) Content-Identifier: RARE WG3 meet... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"6761 Tue Dec 4 12:58:19 1990"@surver.surfnet.nl> To: osi-ds@uk.ac.ucl.cs Subject: RARE WG3 meeting on directories X-VMS-To: IN%"osi-ds@cs.ucl.ac.uk" Comments: EARN/BITnet: HUIZER@HUTSUR51 Sender: HUIZER@nl.surfnet Hi, Sorry for the WG3 members who get this double. This is meant for our non-European friends on this list. Below you'll find the call for the january RARE WG3 meeting on Directory services. We hope that this meeting will continue on what the Colorado IETF meeting brought forth. We therefore would appreciate anyone from the US/Canada who is able (and has the funding :-() to come over and join us in this meeting. You're hereby formally invited to do so. I really hope that some people have the opportunity to come ovber so that Steve is not alone in liaising the IETF anfd RARE groups. Here's the call for the next WG3 meeting in Brussels (surprise :-) januari 1990. Please confirm your attendance to Jill Foster (Jill.Foster@newcastle.ac.uk) YOU NEED TO CONFIRM TO BE ABLE TO ENTER THE BUILDING. (which building still has to be determined, I let you know later.) ___________________________________________________________________________ Agenda for WG3 meeting Brussels januari 1990. Place to be determined. =============================================================== 8 jan Tuesday ------ 14:00 Start of Directories meeting Agree agenda Minutes and matters arising from the minutes (minutes have been distributed by Peter) Cosine P2.1 project (Presentation by Steve Kille) -What can WG3 do in the Cosine P2.1 project (Chris D. and everyone) The IETF OSI-DS group (presentation on the progress of this group Steve K.) [I suggest the following format for this: The subjects mentioned below will be first presented by Steve, after which we discuss them where necessary): discussed when necessary) -PSI pilot -draft: Building an Internet Directory using X.500 -draft: Replication Requirement to provide an Internet Directory using X.500 -Document: Domains and X.500 17:30 We give Steve a chance to get his voice back behind a Pinta - Brakspears (Steve, I'll buy you this one :-) 9 Jan Wednesday ------ 09:00 The use of X.500 and DNS for 987 data. (Strongly related to the Domains and X.500 item. There is a interesting paper on this subject by CSATA, Italy, presented at the last IFIP WG6.5 meeting in Zurich, I'll try to get hold of an electronic version for distribution.) Security (can we provide some input for WG8) The IXI listing and the use of X.500 (Christian and Steve have some ideas about this.) 10:00 Coffee if any, and demonstrations. Christian will show us something Pisaro (Christian?) Ignacio will demonstrate the VMS DUA (Ignacio?) Other suggestions are welcome. 13:00 End of directories meeting (Directly after this there will be a meeting on User Information Services) ___________________________________________________________________________ Erik Huizer (chairman WG3)   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <250-0@bells.cs.ucl.ac.uk>; Fri, 7 Dec 1990 06:55:58 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Fri, 7 Dec 1990 06:47:49 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Fri, 7 Dec 1990 06:47:46 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Fri, 7 Dec 1990 07:49:00 +0000 Date: Fri, 7 Dec 1990 06:47:46 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.765:07.11.90.06.47.46] X400-Content-Type: P2-1984 (2) Content-Identifier: CSATA paper o... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"766 Fri Dec 7 07:48:59 1990"@surver.surfnet.nl> To: osi-ds@uk.ac.ucl.cs Subject: CSATA paper on use of X.500 for rfc-987 data X-VMS-To: IN%"osi-ds@cs.ucl.ac.uk" Comments: EARN/BITnet: HUIZER@HUTSUR51 Sender: HUIZER@nl.surfnet Hi all, I promised to send the paper below around as a start-up (or rather continuation of) the discussion on the use of X.500 to store rfc-987 data. I suggest that if this topic was also discussed in Colorado this week that somebody summarises the outcome of that discussion to avoid duplication on this list. We'll certainly talk about this subject at the next WG3 meeting in Brussels. Thanks to the authors for making the paper electronically available (it's in postscript). I myself am going on a well earned holiday, so I leave you all to do the thinking on this :-) I expect to see some reactions when I get back, especially as I personally do not agree with the conclusions drawn in the paper. Erik ___________________________________________________________________________ %!PS-Adobe-2.1 %%Creator: DECwrite V1.0 %%+Copyright (c) 1989 DIGITAL EQUIPMENT CORPORATION. %%+All Rights Reserved. %%DocumentFonts: (atend) %%EndComments %%BeginProcSet DEC_WRITE 1.05 /DEC_WRITE_dict 150 dict def DEC_WRITE_dict begin/$D save def/$I 0 def/$S 0 def/$C matrix def/$R matrix def/$L matrix def/$E matrix def/beginEPS{/level0 save def/showpage{}def/EPSname exch def}def/endEPS{level0 restore}def/pat1{/px exch def/pa 8 array def 0 1 7{/py exch def/pw 4 string def 0 1 3{pw exch px py 1 getinterval putinterval}for pa py pw put}for}def/pat2{/pi exch def/cflag exch def save cflag 1 eq{eoclip}{clip}ifelse newpath{clippath pathbbox}stopped not{/ph exch def/pw exch def/py exch def/px exch def/px px 3072 div floor 3072 mul def/py py 3072 div floor 3072 mul def px py translate/pw pw px sub 3072 div floor 1 add cvi def/ph ph py sub 3072 div floor 1 add cvi def pw 3072 mul ph 3072 mul scale/pw pw 32 mul def/ph ph 32 mul def/px 0 def/py 0 def pw ph pi[pw 0 0 ph 0 0]{pa py get/px px 32 add def px pw ge{/px 0 def/py py 1 add 8 mod def}if}pi type/booleantype eq{imagemask}{image}ifelse}if restore}def/PS{/_op exch def/_np 8 string def 0 1 7{/_ii exch def/num _op _ii get def _np 7 _ii sub num -4 bitshift PX num 15 and 4 bitshift -4 bitshift PX 4 bitshift or put}for _np}def/PX{[15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0]exch get}def/FR{0.7200 0 $E defaultmatrix dtransform/yres exch def/xres exch def xres dup mul yres dup mul add sqrt}def/SU{/_sf exch def/_sa exch def/_cs exch def/_mm $C currentmatrix def/rm _sa $R rotate def/sm _cs dup $L scale def sm rm _mm _mm concatmatrix _mm concatmatrix pop 1 0 _mm dtransform/y1 exch def/x1 exch def/_vl x1 dup mul y1 dup mul add sqrt def/_fq FR _vl div def/_na y1 x1 atan def _mm 2 get _mm 1 get mul _mm 0 get _mm 3 get mul sub 0 gt{{neg}/_sf load concatprocs/_sf exch def}if _fq _na/_sf load setscreen}def/BO{/_yb exch def/_xb exch def/_bv _bs _yb _bw mul _xb 8 idiv add get def/_mk 1 7 _xb 8 mod sub bitshift def _bv _mk and 0 ne $I 1 eq xor}def/BF{DEC_WRITE_dict begin/_yy exch def/_xx exch def/_xi _xx 1 add 2 div _bp mul cvi def/_yi _yy 1 add 2 div _bp mul cvi def _xi _yi BO{/_nb _nb 1 add def 1}{/_fb _fb 1 add def 0}ifelse end}def/setpattern{/_cz exch def/_bw exch def/_bp exch def/_bs exch PS def/_nb 0 def/_fb 0 def _cz 0/BF load SU{}settransfer _fb _fb _nb add div setgray/$S 1 def}def/invertpattern{$S 0 eq{{1 exch sub}currenttransfer concatprocs settransfer}if}def/invertscreen{/$I 1 def/$S 0 def}def/revertscreen{/$I 0 def}def/setrect{/$h exch def/$w exch def/$y exch def/$x exch def newpath $x $y moveto $w $x add $y lineto $w $x add $h $y add lineto $x $h $y add lineto closepath}def/concatprocs{/_p2 exch cvlit def/_p1 exch cvlit def/_pn _p1 length _p2 length add array def _pn 0 _p1 putinterval _pn _p1 length _p2 putinterval _pn cvx}def/OF/findfont load def/findfont{dup DEC_WRITE_dict exch known{DEC_WRITE_dict exch get}if DEC_WRITE_dict/OF get exec}def mark/ISOLatin1Encoding 8#000 1 8#001{StandardEncoding exch get}for /emdash/endash 8#004 1 8#025{StandardEncoding exch get}for /quotedblleft/quotedblright 8#030 1 8#054{StandardEncoding exch get}for /minus 8#056 1 8#217 {StandardEncoding exch get}for/dotlessi 8#301 1 8#317{StandardEncoding exch get}for/space/exclamdown/cent/sterling/currency/yen/brokenbar/section /dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered /macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph /periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter /onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde /Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave /Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde /Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave /uacute/ucircumflex/udieresis/yacute/thorn/ydieresis 256 array astore def cleartomark /encodefont{findfont dup maxlength dict begin{1 index/FID ne{def}{pop pop}ifelse}forall/Encoding exch def dup/FontName exch def currentdict definefont end}def/loads{/$/ISOLatin1Encoding load def/&/encodefont load def/*/invertpattern load def/+/revertscreen load def/-/invertscreen load def/:/concatprocs load def/^/setpattern load def/~/pat1 load def/_/pat2 load def/@/setrect load def/A/arcn load def/B/ashow load def/C/curveto load def/D/def load def/E/eofill load def/F/findfont load def/G/setgray load def/H/closepath load def/I/clip load def/K/kshow load def/L/lineto load def/M/moveto load def/N/newpath load def/O/rotate load def/P/pop load def/R/grestore load def/S/gsave load def/T/translate load def/U/sub load def/V/div load def/W/widthshow load def/X/exch load def/Y/awidthshow load def/a/save load def/c/setlinecap load def/d/setdash load def/e/restore load def/f/setfont load def/g/initclip load def/h/show load def/i/setmiterlimit load def/j/setlinejoin load def/k/stroke load def/l/rlineto load def/m/rmoveto load def/n/currentfont load def/o/scalefont load def/p/currentpoint load def/r/currenttransfer load def/s/scale load def/t/setmatrix load def/u/settransfer load def/w/setlinewidth load def/x/matrix load def/y/currentmatrix load def}def end %%EndProcSet %%EndProlog %%BeginSetup DEC_WRITE_dict begin loads version cvi 23.0 gt { currentdict {dup type /arraytype eq {bind def} {pop pop} ifelse} forall} if 0.0100 0.0100 s %%EndSetup /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (1\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 5916 -1200 M /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f 526.1 0 32 (THE DIRECTORY SYSTEM: CAN IT BE USED BY AN) W 6132 -2700 M (RFC987 GATEW) h /Times-Bold-ISOLatin1 $ /Times-Bold & P /Times-Bold-ISOLatin1 F 1200 o f (AY ?) h 5916 -4800 M 5916 -6900 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f (A.Mastrolonardo, P.Pennelli, A.Pepe, D.Rotondi) h 5916 -9000 M 5412 -11100 M ( R&D Division) h 5412 -12600 M ( TECNOPOLIS CSATA Novus Ortus) h 5412 -14100 M ( Valenzano \(Bari\), Italy) h 5916 -16500 M 6132 -18000 M 320.0 0 32 (This paper reports our considerations on the possible use of the) W 6132 -19500 M 183.2 0 32 (Directory System as a support tool for the RFC987 gateways. The) W 6132 -21000 M 62.6 0 32 (above considerations were raised when designing the Visnu' system,) W 6132 -22500 M (our RFC987 gateway.) h 5916 -24600 M 15521 -26700 M /Times-Bold-ISOLatin1 F 1200 o f (IFIP MHS '90 Symposium) h 16322 -28800 M (Zurich, 3\2555 October 1990) h 5916 -30900 M 300 -33000 M /Helvetica-Bold-ISOLatin1 F 1200 o f (1. INTRODUCTION) h /Times-Roman-ISOLatin1 F 1200 o f ( ) h 300 -35100 M 46.4 0 32 (Since the introduction of the Directory Services standards [1] a great effort has been put into) W 300 -36600 M (the exploitation of its use in different application environments.) h 300 -38700 M 38.3 0 32 (This paper summarizes the discussions we had when designing our RFC987 Gateway \(called) W 300 -40200 M (Visnu' after the Hindu god of preservation\).) h 300 -42300 M 10.1 0 32 (Our goal was to use the Directory System as a support tool to manage the RFC822 <\255> X.400) W 300 -43800 M 279.1 0 32 (mapping rules needed by an RFC987 gateway in order to properly manage the address) W 300 -45300 M (conversion between the RFC822 world and the X.400 world and vice versa.) h 300 -47400 M 42.6 0 32 (Therefore, in the following, after a brief introduction to the address mapping problem for the) W 300 -48900 M 104.2 0 32 (RFC987 gateways, a set of possible uses of the Directory System is discussed, highlighting) W 300 -50400 M (the pros and cons of each Directory System use.) h 300 -52500 M 28.4 0 32 (At the end the actual solution adopted within the Visnu' gateway is described together with a) W 300 -54000 M (short description of the Visnu' gateway itself.) h 300 -56250 M 300 -57800 M /Helvetica-Bold-ISOLatin1 F 1200 o f (2. THE RFC987 GATEWAY ENVIRONMENT ) h 300 -59900 M /Times-Roman-ISOLatin1 F 1200 o f 254.1 0 32 (As described in the RFC987 document [2], an RFC987 gateway is a system capable of) W 300 -61400 M 417.5 0 32 (interconnecting an E\255mail service conforming to the RFC822 specification [3], to an) W 300 -62900 M 2.3 0 32 (X.400\(84\) service. Messages, from one E\255mail service, addressed to users on the other E\255mail) W -7560 6480 T R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (2\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f 191.8 0 32 (service are routed through the RFC987 gateway; this, acting on both the E\255mail services,) W 300 -2700 M 194.5 0 32 (provides the conversion of the services requested by the originator, the conversion of the) W 300 -4200 M 128.0 0 32 (information contained into the messages and, last but not least, the conversion of the users) W 300 -5700 M (E\255mail addresses.) h 300 -7200 M 354.9 0 32 (The RFC987 specification takes into account the possible existence of more than one) W 300 -8700 M (gateway connecting the two E\255mail services. Therefore, from a user point of view, it tries to:) h 3900 -10800 M 88.3 0 32 (\255 maximize the functionalities supported across the gateway \(i.e. the functionalities) W 5700 -12300 M 492.8 0 32 (available to the end\255users independently from the E\255mail service of their) W 5700 -13800 M (correspondents\);) h 3900 -15900 M 202.3 0 32 (\255 maintain a consistent service, independently both from the number of gateways) W 5700 -17400 M (connecting the E\255mail services and the path followed by messages;) h 3900 -19500 M 45.3 0 32 (\255 minimize the loss of functionalities also in the light of the forwarding of messages) W 5700 -21000 M (and of the possible use of different paths in the message flow between users.) h 2100 -23250 M 2100 -25550 M 2100 -27850 M 2100 -30150 M 2100 -32450 M 2100 -34750 M 2100 -37050 M 2100 -39350 M 2100 -41500 M 2100 -43600 M 6060 -43600 M 11820 -43600 M (Fig.1: The RFC987 gateway environment) h 2100 -45700 M 300 -47800 M (Fig. 1 gives an idea of the environment in which an RFC987 gateway has to operate.) h 300 -49900 M 13.5 0 32 (As a result it is necessary for all the gateways interconnecting the same E\255mail services to be) W 300 -51400 M 257.9 0 32 (coordinated so that they apply the same mapping. Therefore, generally speaking, all the) W 300 -52900 M (gateways) h /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f ( in the world ) h /Times-Roman-ISOLatin1 F 1200 o f (need to apply the same mapping.) h 300 -55000 M 227.2 0 32 (Furthermore, in general, it is impossible to avoid a transformed address having elements) W 300 -56500 M 104.6 0 32 (referring to the gateway through which the message has been routed. This is because, apart) W 300 -58000 M 168.8 0 32 (from a different structuring, an RFC822 address doesn't carry the same information as an) W 300 -59500 M (X.400 address and you can't fill the X.400 attributes with arbitrary values.) h 300 -61600 M 128.6 0 32 (At the same time it is impossible to define a mapping algorithm capable of taking into ac\255) W 300 -63100 M (count all the exceptions [4] related to the address conversion.) h -7560 6480 T R a 40 dict begin 12847 -46371 T 37007 17353 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 470 383 1 [470 0 0 -383 0 383] {I} image '~'~'~'~%g3 '~'~'~'~'~%e4@q2'$V42s2/$T4>u$TLF00001vLF0000F$SK8007xKF007$RKFE01z2!$RKFC0FzKE07F$QKF83FzKF87F$Q4"$'KFC3F$OL01FFE1$' KFE1F$NMF0000FE3$(2?$NM80000383$'KFE1F$NM007C001F$'KFC3F$MNFE07FFE01F$(2#$MNFC3FFFFC3F$(M000FFFF7$JKF87Fv1?$(M0001FFE7$J4"w3`y4:v MFC003FC7$J4#x2 x4>wLF00787$J3dx3=x4>wLFE0207$J3(xP9CC470E23C2C8FwKC007$J30xP97E3E671998C67wKE000$,42q1?$:2/xP87E7CF3393CCE7w LF0000F$*3!s3 $8KFE1FxP97E7C03393FCE7w4:q$)4"t2'$8KFE3FxP9FE7CFF393FCE7wMFC07000F$(L80000FvL80007F$7KFE3FxP9FE7E63399CCE7w MFE07F000$'LFC003FxK803F$7KFE3FxP07C0F0610C1843xM17FF000FzKF00FyKF80F$7KFE3F$/M1FFFF001zKE07Fz2#$7KFE3F$/N1FFFFE001Fy3b$'3d$7KFE3F $/2?vME001FFBFw2'$'4#$7KFE3F$/30vQFE001F3FF80FFF0F$'42$7KFE1F$/30wPE0001F80007F1F$'4:$82/$/2?wLFE001CqK1C1F$'42$830z4@0|~ 1?y2?xNE00003E000$(4#$83(xO18FFFC793C9Fy2?xNF0003FFF00$(KF81F$73dxO99FFF87399CFxKFE07xKE001v4#$(LF8007F$64#xO99FFFA7399CFxLFE007Fw KC003v4;$(LF8000F$64"xOC3FFF27399CFxLFE000Fx2'v4?$)KE001$6KF87FwOE7FFF67399CFyKF807x2/$-K803F$5KFC3FwOC3FFE67399CFz3$wKFE1F$-KF01F $5KFE07wO99FFE03399CFz4#wKFC3F$-KFE0F$6K007FvO99F3FE793C9Fz42wKFC7F$.2'$6K807FvO18F3FC3C7E3FzKF83FvKF87FyKE7C7wKFE1Fv3$$6KF07F$. KFC3Fv42w2+v,"E7NFFF01FFF9Fv3b$6KF87F$.KFE3Fv43vKFE63v("NFFF9CFFF9Fv4#$6KF87F$/2?v43vWFE738718C0E47FF9CE1F9F87FFF1$6KF87F$/2?v43 vWFE7F339CE7E33FF9CCCF9F33FFF8$64"$02?v43wL06799C("Q3FF999E79E79FFF8$63d$030v43wLF2799C("Q3FF839E79E01FFF8$62'$(1?$'30v43v MFE72799C("1?."F9NE79E7FFFF8$62/w3cx1?$'2?v43v4@,"33U98E6673FF9FCCF9F31FFFC7F$04:qL1FFE1Fw39$,2?v42v4@."87 UC470C21FF07E1E0783FFFC7F$/KFE07vLE01E3FwQ9CE1E2210C3E170Fy2?vKF87F$.4:$04#xKE03FwQ9FCCF1F39F3CC667xKFE3FvKFC7F$.4:$02?xKFC1Fw QC19E73F39F39E4F3xKFC3FvKFC3F$.4:$/4>yKFC63wMFC8073F90?9 KFC03xKF83FvKFE1F$.KF03F$.4%yKFC3CwM9C9FF3F90?9 4>y42x2/xMFCF8FC7FzKF003$.2?y4@,"3FvQ8CCC73FC7F3CE663x4#xR07FFFE31FFF8F2793FzLF0007F$,SFE7FFF0B008430FE3FCFv3B."E0,"7C L0E0F07x3$x3dvO33FFF0E7339F$'KC03F$,SF9FFFE7324CE79FE1FF3$-KF807x4#vO33FFF4E7339F$'KFC1F$,SE7FFFCFB66CE7BFF0FFD$-KE00Fx RF03FFF87FFE4E7339F$(2/$,MDFFFFCFB."E7M3BFF07FE$-KC07FxRF803FFCFFFECE7339F$(3($,MBFFFFCFF*"N37FFC3FF7F$,3hyRFC03FF87FFCCE7339F$( 3b$,T3FFFFCE1E7E637FFE0FFBF$,30zQ83FF33FFC067339F$(4#$+UFE7FFFFCF3E7F297FFF01FDFw3@$(2/zQC3FF33E7FCF2793F$(43$+4@v RFCF3E7F18FFFF803DFw2/$'KFE1FzQC3FE31E7F878FC7F$(4:$+4?vNFE73E7F9CFvK002FvKF007$'KF81Fz3d$/4:$+4?wM07C3F9CFvME001FFFEq3 zKE07Fz2' $/4:$+4?$)4>sKF80Fz2!zKFE1F$/KFC7F$*4?$*3aqL0FFC03yKFC03zKF83F$/KFC7F$*4?$*LE60001vK8007wLFE001FzKF87F$/4:$+4?$*41x4"qK7FF0q3 z42 $04:$+4?$*41x4>t2#$'43zKFE7F$(4:$)4@q2'$)4!y4:r2!$(43v3&wKFE7F$(43$(42s2/vKE1C7x3@$'K000F$)4#v11$-4#$'4>uvKF1EFx3`$'KF01F$)4%v Q39C3C442187C2E1Fz3b$'LF00001vOB0000FFFF8DFx3 $'KF03F$)4#vQ3F99E3E73E798CCFz3($'K8007wOCFF007FFFC3Fw4@$(KF01F$)43vK833C*"M3E73C9E7 z2/zKFE01xOE7FE00FFFE7Fw4?$(KF00F$)43vQF900E7F27E73F807yKFC1FzKFC0FxOF8FFE07FFE3Fw4%$(KF307$)42v09? NE7F27E73F9zKC03FzKF83FxOFE7FF87FFD1Fw3p$(KF783$)TF87FFF1998E7F8FE79CCC7yK007Fz4"zN1FFC3FFB8Fw1?$)3b$)OF83FFF43C1C0,"F8L1C1E0Fx KFE03yL01FFE1zNE3FE1FF7C7v4:$*4"$)KFE1F$-KFE3FxMF0000FE3zNFCFF1FE383v3D$*KF07F$)2'$-KFC7FxM80000383$'K1E1FwKFE1F$*KF83E$)3!$-KF87F xM007C001F$'KE03Fw4#$+KFC1C$)KC01FwKF87F$'42xNFE07FFE01F$'KFE03vKE01F$+KFE08$)KF801wK803F$'3axNFC3FFFFC3F$(r2?$-2 $*O000FFFF00003 $'2#xKF87Fv1?$(K0001$/3!$*4"rL07C07FyKF80Fx4"w3`xPF87C3E1FFC003F$.3a$)4:sL7FE01FyKE01Fx4#wUFE0300F17FF3399CCFFFF007$.3!$) RFC00F0000FFFFC003FwKF000y3dxT399CE47FF3399CCFFFFE03$.2 $)KFE01yqN03FF800003y3(xQ399CCE7FF33F9FCFv3b$-KFE00$*2#y4"t2?y30x Q3997CFFFF87F9FCFv4"$.q2#$'KFE03z3ar2/z2/xN3387CFE033."3F3@vKF07F$+4:s2'zKF803$'LF8007FzKFE1FxQ0797CFFFF33E7F3FvKF83F$*4@u3 y KF063$0KFE3FxQ339FCFFFF33CFE7FvKFC3F$*4:qvLF80007yKE0F3$0KFE3FxP399FE67FF339FCwKFE3F$*KC003xKF803yK83FB$0KFE3FwRFE1807F0FFF8781C0F w2?$*2 z3!y2'$1KFE3F$/2?$)KFE07zKF03FwKFC0F$1KFE3F$/2?$)KFC1FzKFC3FwKF83F$1KFE3F$/2?$)KF07FzKFE1FwKE07F$1KFE3F$/30$'L80FFF0$(2/w3b $2KFE1F$/30zMF80007F1$(30w3$$32/$/2?zMC00001C1$(2/vKFE0F$330$(LFE787Fx2?zM803E000F$'OFE1FFFFEFC1F$33(wKFE01wLFE7E7Fx2?zM03FFF00F$( N81FFFE703F$33dx19xKFE7FwKFE07yNFE1FFFFE1F$(M8007FE20$44#xP39FF24E0F87E7FwLFE007FxKFC3Fv3@$(M8000FE01$44"xL2FFF92,#7E3 wLFE000Fx KF07FvPDFFFCFFFE1FE7FvMFE001E07$4KF87FwL0F8092(#3 xKF807x42xO03CFFFF9FE7FwLF80207$4KFC3FwM2FFF9260("3 y3$x4#x."CFKFFF9zK0003$4 KFE07wM39FF924E("3 y4#x3dxQCF81C1F9F878388FvKE001$5K007FvM39FF924C("3 y42rKFFC7x*"OFCF9FE7F9C67vKF07F$5T807FFFFE01FF122238181Fy KE03FvK0087x*"OFCF9FE7F9CE7vKF83F$5KF07F$-LFE083Fw2/x*"OC0F9FE781CE7vKFC1F$5KF87F$-LF9FF1Fw20x*"O9CF9FE739CE7vKFE1F$5KF87F$- LC7FF1Fw,"1FwQCFCC98F9FE731CE7w2?$5KF87F$-L3FFF1FwK1FE7wQ03E1C46078188843w30$54"$-4:v30wK1FF9$.30$53d$'KFE7Fx4%v30wL1FFE7F$-30$5 2'w3&wKFE7Fx30v2?wL1FFF9F$-30$52/w11$(KFE3Fv2?wL1FFFE7$-3h$4KFE1FwS39C3C442187C2E1FFFFCwP016010860FFFFB$-3h$4KFE3Fw S3F99E3E73E798CCFFFFBwP0E6499CF07FFFC$-30$4KFE3FwK833C."E7O3E73C9E7FFF3wP1F6CD9CF47FFFExMFCF8FC7Fy30$4KFC3Fw SF900E7F27E73F807FFE7vOFC1F7CFCE743vQ7FFE31FFF8F2793Fy30$4KFC7Fw09? NE7F27E73F9v41vKF89F,"FCKE6E1vQ7FFF33FFF0E7339Fy2#$4KFC3FwS1998E7F8FE79CCC7FFDFvOF19C3CFCC6F0vQBFFF33FFF4E7339FyK003F$3KFE3Fw L43C1C0."F8N1C1E0FFFDFvYE19E7CFE52F07FFFBFFF87FFE4E7339FyK0007$3KFE3F$,4!vY839E7CFE31F83FFFBFFFCFFFECE7339FyKFC03$3KFE1F$, \DFFFF80FCE7CFF39FE1FFFBFFF87FFCCE7339Fz3b$42/$,\DFFFE00FE0F87F39FF03FFBFFF33FFC067339Fz42$42'$,MDFFFC07FySC07FBFFF33E7FCF2793Fz KF87F$33d$,LEFFFC7zSE03F7FFE31E7F878FC7FzKFC1F$34"$*N8FFFE7FF8FzLF83F7F$-KFE1F$3KF01Fx3@wOFC70FFF3FF0FvKE0C7vKFC3E$/2?$3KF803x2/w OF3FF3FFBFE1FvKF1EFvKFC3C$/30$4K003FvKF007wOCFFF8FFCF81FvKF9DFvKF83B$/30$4ME001FFFEq3 vO9FFFE7FE203FvKF8DFvKF067$/30$44>s RF80FFFFE7FFFF9FF01wKFCBFvKE19F$/3h$53aqN0FFC03FFFCv("2#wKFC3FvK827FzKFE7F$'3h$5LFE0001vL8007F9vLFE0018wKFE7Fv3"w3&wKFE7F$'30$:4"q K7FE0qK7F3FvKFE7Fv2'w11$,30$:4>tL03FFC7vKFE7Fv2?wQ39C3C442187C2E1Fy30$;4:rM01DFFFF9vNFC3FFFF01FwQ3F99E3E73E798CCFy2?$< QEF000FFFDFFFFE1FxK0E1FwK833C,"E7M3E73C9E7xKFE1F$<4!w41vKE07FvL00FE3FwQF900E7F27E73F807xKFC1F$<4!w41w3!qLFFFE1Fw09? NE7F27E73F9yKF87F$<3`w49$(2?wQ1998E7F8FE79CCC7x42$=1?w45$(2?wL43C1C0*"L1C1E0Fx3b$=3 w4=$(2/$.KFC03$=3 w4=$(3($.KF007$<4@x4?$(3$$. KE03F$<4@x4?$(4#$.4%$=4@x4?$(KF07F$-3h$=4@x4?$(KF80Fx3p$(3($=4?x4@$(KFC01x3($(2/$=OFDF858042186$)K801FvKF803$'KFC0F$=OFDF3992673CE $)KF000vL00303FzKF03F$=OFDE7DB3673DE$)4@t2'z3!$>LFBE7DF0?9 KDF7F$)4"qL078001yKFE01$>LFBE7FF0?9 KBF7F$*qMFFC00003xK000F$>PFBE70F3F31BF7F$-4"rK3FF8q1?$>PFBE79F3F94BF7F$-K0002t2!$?NFBE79F3F8C."7F$,MF80007FCs$@NFBF39F3FCE*"$, L80080FvK8007$ANFBF83E1FCE*"$*NDFFC00FC1F$E45y3 $*N8FC007FE3F$E49y3`$*N06007FFF7F$E49y3`$)LFE0003$H49y3`$)LFC003F$H49y3`y4>q L0FF001$I49y3`x4"t2!$I49y3`w4: '$IMF7FFFC03v3`wLE00003v4"q3 $HMF7FFFCE3v3`w4#yKFC1F$IMF7FFFDE7v3`vKFC03yKFE03$IMF7FFFDCFv3`vKF81Fz 3a$I49v3@v3 vKF07Fz42$I45v3@v3 v3b$'KF87F$H4=v1;vM7E03FFC3$'KFC3F$HMFBFFFE7BvM60001FC7$'KFE3F$HMFBFFFC73vq,"07$'KFC3F$H SFBFFFC03FFFE00F8003F$'KF87F$H4=xNFC0FFFE03F$'KFE07$H4=xNF87FFFF87F$'LFE001F$G4=xNF07FFFFE7F$(K8003$G4?x3aw3 $(LF8007F$F4?x3c$- KE00F$F4?x3'$-KFC07$F4?x2.x3c$)3$$F4@x2=x39$)3b$F4@wKFE1DxM3CE1E209."3830w4"$F4@wKFC3DxP3FCCF1E49F9C67wKF07F$E4@wKFC7Dx P3F9E73E49F9CE7wKF87F$F3 vKFC7BxP300073E4981CE7wKFC7F$F3 vKFC7BxP3C9FF3E4939CE7wKFE3F$F3 vKFC73xP9CCC73E4931CE7wKFE3F$F3`vKFC77x3a ,"E01D."881CwKFE3F$F4!vKFC6F$.KFE3F$F4!vKFC6F$/2?$F41vKFC1F$/2?$F41vKFE1F$.KFE3F$F49w2?$.KFE3F$F49w2/$.KFE3F$F4=vKFE07z4@0|~ 1?xKFC0F$F4?vKFCC3xO18FFFC793C9FxKFC00$FNFE7FFFF9C1xO99FFF87399CFxLFC001F$FMBFFFE7F0xO99FFFA7399CFyKF00F$FNCFFF8FF87Fw OC3FFF27399CFz2'$FNF3FF3FFC0FwOE7FFF67399CFz3d$FNFC70FFFE00wOC3FFE67399CFz4#$G30v2 wO99FFE03399CFzKF07F$I4"wO99F3FE793C9FzKF87F$I 42wO18F3FC3C7E3FzKFC7F$I42$/KFE3F$I42$/KFE3F$I3b$/KFE3F$I3($02?$HKFE0F$02?$HKFE1F$/KFE3F$HKFC3F$(1?zKFE3F$HKFC7Fw3cx1?zKFE3F$H KFC7Fw39$+KFC7F$HKF87FwQ9CE1E2210C3E170FxKF87F$H4:xQ9FCCF1F39F3CC667xKF07F$HKF87FwQC19E73F39F39E4F3x4#$IKFC7FwMFC8073F90?9 KFC03x3d$IKFC7FwM9C9FF3F90?9 4>y2'$IKFC3FwQ8CCC73FC7F3CE663wKF00F$IKFE1Fw3B(","7CL0E0F07wKC01F$IKFE0F$.3!$K3($.30$K3b$.2?$KKE03Fx1?$'KFE1F$KKF007wKFE1F$' KFC3F$KLFE007FvKE00F$'KF03F$LMC003FFFCq$'3a$M4:rL01F01FyKFE03$N3!qL1FF807yKF807$NLFC0003vK000FwLFC003F$S3aqKFFE0q$T4:t2'$U42r2#$W LFE001F'~'~'~'~'~'~'~'~'~'~'~'" end e showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (3\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f 217.8 0 32 (Therefore the RFC987 address conversion process is governed by) W /Times-Bold-ISOLatin1 $ /Times-Bold & P /Times-Bold-ISOLatin1 F 1200 o f 217.8 0 32 ( ) W /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f 217.8 0 32 (Mapping Rules,) W /Times-Roman-ISOLatin1 F 1200 o f 217.8 0 32 ( which) W 300 -2700 M (specify the representation, in the other E\255mail service, of a given E\255mail user address) h /Courier-ISOLatin1 $ /Courier & P /Courier-ISOLatin1 F 1200 o f (.) h 300 -4800 M 300 -6900 M /Courier-Bold-ISOLatin1 $ /Courier-Bold & P /Courier-Bold-ISOLatin1 F 1200 o f (3) h /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f (. THE RFC987 CONVERSION TABLES) h 300 -9000 M /Times-Roman-ISOLatin1 F 1200 o f 26.8 0 32 (In order to manage the problem mentioned at the end of last paragraph, in the RFC987 speci\255) W 300 -10500 M 42.4 0 32 (fication two Conversion Tables are defined: the first one specifying the Mapping Rules to be) W 300 -12000 M 111.4 0 32 (used when translating an X.400 address into its RFC representation; the second one for the) W 300 -13500 M (inverse operation.) h 300 -15600 M 216.2 0 32 (As already stated the various Conversion Tables used by the different RFC987 gateways) W 300 -17100 M (must be coordinated.) h 300 -18600 M 365.9 0 32 (To this end the RARE MHS Pilot Project [5] has taken the job of coordinating this) W 300 -20100 M (information in Europe. The adopted procedure is the following:) h 3900 -22200 M 260.5 0 32 (\255 each national X.400 service participating in the RARE project, defines its own) W 4980 -23700 M (Conversion Tables assuring that no rule duplication exists at the national level;) h 3900 -25800 M 20.6 0 32 (\255 the national Conversion Tables are collected together into two European Conversion) W 4980 -27300 M 198.2 0 32 (Tables. The RFC822 to X.400 table, due to the problems mentioned above, can) W 4980 -28800 M 3.3 0 32 (contain duplicated rules \(e.g. the RFC top level domain ) W /Times-Italic-ISOLatin1 F 1200 o f 3.3 0 32 (edu) W /Times-Roman-ISOLatin1 F 1200 o f 3.3 0 32 ( could be mapped by the) W 4980 -30300 M (Italian Conversion Table into:) h 4980 -31800 M 6060 -31800 M /Times-Italic-ISOLatin1 F 1200 o f (C=it; ADMD= ; PRMD=edu;) h 4980 -33300 M /Times-Roman-ISOLatin1 F 1200 o f (while the French Conversion Table could map it into:) h 4980 -34800 M 6060 -34800 M /Times-Italic-ISOLatin1 F 1200 o f (C=fr; ADMD=ATLAS; O=edu;) h 4980 -36300 M /Times-Roman-ISOLatin1 F 1200 o f (creating a duplicated mapping rule\);) h 3900 -38400 M 96.4 0 32 (\255 the European Conversion Tables are distributed to the RFC987 gateway managers,) W 4980 -39900 M 3.7 0 32 (who have to remove the duplicated rules, selecting the ones suitable for the gateway) W 4980 -41400 M (they manage;) h 3900 -43500 M (\255 these revised tables are put into operation at the same time in the various gateways.) h 300 -45600 M 336.4 0 32 (The above procedure requires time, coordinated efforts and synchronization among the) W 300 -47100 M 149.5 0 32 (gateway managers. A solution based on the Directory System can simplify that procedure,) W 300 -48600 M (perhaps assuring the same, or better, results with less efforts and a distributed management.) h 300 -50700 M 300 -52700 M /Helvetica-Bold-ISOLatin1 F 1200 o f (4. THE USE OF DIRECTORY SERVICES) h 300 -54700 M /Times-Roman-ISOLatin1 F 1200 o f 101.8 0 32 (Within the RFC987 Gateway, it is possible to take advantages from a Directory System [1]) W 300 -56200 M 57.8 0 32 (retrieval functionalities, from its distributed database design, from its standard services. So a) W 300 -57700 M 86.8 0 32 (Directory System may be a standard repository for the addresses mapping rules from X.400) W 300 -59200 M (to RFC\255822 and viceversa.) h 300 -61300 M (These two sets of mapping rules raised the problem of how to map them on the DIT.) h 300 -63400 M -7560 6480 T R S 10738 -40507 M /Courier-ISOLatin1 F 1400 o f ( ) h R S 3164 -2734 M /Courier-ISOLatin1 F 1400 o f ( ) h R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (4\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Helvetica-ISOLatin1 F 1200 o f (4.1. A First Possible DIB Arrangement) h /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f ( ) h 300 -3300 M 203.6 0 32 (In the first case we examined, the DIB could be designed so that each node has an O/R) W 300 -4800 M 107.1 0 32 (attribute as its Relative Distinguished Name \(RDN\) attribute [1] and the mapping rules, for) W 300 -6300 M (the conversion into the RFC\255822 format, as one of the attributes of the entry.) h 300 -8400 M (The following figure shows the corresponding design of the DIB:) h 3656 -10650 M 3656 -12950 M 3656 -15250 M 3656 -17550 M 3656 -19850 M 3656 -22150 M 3656 -24450 M /Courier-ISOLatin1 $ /Courier & P /Courier-ISOLatin1 F 1400 o f ( ) h 3656 -26600 M 3656 -28700 M /Times-Roman-ISOLatin1 F 1200 o f ( ) h /Times-Bold-ISOLatin1 $ /Times-Bold & P /Times-Bold-ISOLatin1 F 1200 o f ( ) h 11820 -28700 M 17580 -28700 M ( ) h /Times-Roman-ISOLatin1 F 1200 o f (Fig.2) h 3656 -30800 M /Times-Bold-ISOLatin1 F 1200 o f ( ) h /Times-Roman-ISOLatin1 F 1200 o f ( ) h 300 -32900 M 96.9 0 32 (where the X.400 attributes represents the RDN attributes and the MR attribute indicates the) W 300 -34400 M (corresponding mapping rule.) h 300 -36500 M (As an example the entry:) h 3656 -38600 M ( ) h /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f ( C=at; ADMD=ptt; PRMD=cern;) h /Times-Roman-ISOLatin1 F 1200 o f ( ) h 300 -40700 M (has to be mapped to:) h 300 -42800 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (cern) h 300 -44900 M /Times-Roman-ISOLatin1 F 1200 o f (while the mapping rule for) h 3656 -47000 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f ( C=at; ADMD= ;) h /Times-Roman-ISOLatin1 F 1200 o f ( ) h 300 -49100 M (is ) h 300 -51200 M /Times-Italic-ISOLatin1 F 1200 o f ( at) h 300 -53300 M /Times-Roman-ISOLatin1 F 1200 o f 132.9 0 32 (All the parts of the O/R address that are not included in the Distinguished Name \(DN\) [1]) W 300 -54800 M (will be processed according to the RFC987 default mapping.) h 300 -56900 M (For example, the O/R address ) h 3656 -59000 M ( C=at; ADMD=ptt; PRMD=cern; O=edua; S=mark) h 300 -61100 M (is mapped into the RFC\255822 address) h 300 -63200 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (mark@edua.cern) h -7560 6480 T R a 40 dict begin 16107 -33684 T 30966 15819 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 470 324 1 [470 0 0 -324 0 324] {I} image '~'~'~'~'~'~'~$94> )1?$P4> )1?$P4> )1?$PKFC7FyMFE3FFE3F$PKFC7FyMFE3FFE3F$PKFC7FyMFE3FFE3F$PKFC7FyMFE3FFE3F$P TFC7F17FFFC1C03FE3FFE3F$PLFC7E47vO1C93FE3FFE3F$PTFC7CE7FFFE4C93FE3FFE3F$PKFC7CvPFE4F9FFE3FFE3F$PTFC7CFFC0FE4F9FFE3FFE3F$PKFC7Cv PFCE79FFE3FFE3F$PKFC7CvPFC079FFE3FFE3F$PTFC7E67C0FCE79FFE3FFE3F$PTFC7F0FFFF8430FFE3FFE3F$PKFC7FyMFE3FFE3F$PKFC7FyMFE3FFE3F$PKFC7Fy MFE3FFE3F$PKFC7FyMFE3FFE3F$P4> 'L3FFE3F$P4> 'L3FFE3F$P4> 'L3FFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$' KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7FzLF9FE3F$PMFC78E007xLF9FE3F$PMFC7CE673xLF9FE3F$P MFC7C4673wKE0F00>? $PTFC7C4673FF80FFFE79FE3F$PMFC7CA667wMFE79FE3F$PMFC7CA60FwME079FE3F$PTFC7CE667FF80FFCE79FE3F$PMFC7CE673wMCC799E3F$PMFC784031w4$ 0<>? $PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$PKFC7F$'KFE3F$P4> )1?$P4> )1?$P4> )1?$QKE03Fy4#$SK807FyKE07F$QKFE03zKF01F $QKF00FzKFC07$QKC03F$'2!$Q2!$(KC07F$OKF807$(KF01F$OKE01F$(KFC07$O2 $*3"$NKFC03$*KE07F$MKF01F$*KF80F$MK807F$*KFE03$LKFE01$,3!$L KF80F$,KE03F$KKC03F$,KF80F$K2 $-KFE03$JKFC07$.3!$JKE01F$.KE03F$IK807F$.KF80F$HKFE03$/KFE03$HKF00F$03!$HKC03F$0KE03F$G2!$1KF80F$F KF807$1KFE03$FKE01F$23!$F2 $3KF03F$DKFC03$3KFC0F$DKF01F$42!$DK807F$4KC07F$BKFE01$5KF01F$BKF80F$5KFC07$BKC03F$62!$B3!$7KC07F$A3($3 3a (2#$74" )3 $/3a (2#$74" )3 $/3a (2#$74" )3 $/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4% $74%$(KFC7F$/3h$(4%$7TE20E071C01FFE03008047F$/PC60E071C01FFFCv1#$7TE38F339CCCFFF39249247F$/PC78F339CCCFFFCv1#$7 TE3273988CE7FF39249247F$/SC7273988CE7FF9FFFE63$7TE3273988CE60339E7F3C7F$/SC7273988CE603BFFFEE3$7TE3273994CE7FF33E7F3C7F$/ OC7273994CE7Fw4%$7TE3733994CE7FF07E7F3C7F$/OC6733994CE7Fw4%$7TE203399CCE6033FE7F3C7F$/PC603399CCE603Fv4%$7TE273339CCCFFF3FE7F3C7F $/NC673339CCCx4%$7TE020070801FFE0FC3E1C7F$/NC420070801x4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h $(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3a (2#$74" )3 $/3a (2#$74" )3 $/3a (2#$74" )3 $/3h$(4%$7 4%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$'KCFE3$74%$(KFC7F$/,"C7K003FxKCFE3$74% $(KFC7F$/MC7E7339FxKCFE3$74%$(KFC7F$/MC7E2339FwL0781E3$74%$(KFC7F$/SC7E2339FFC07FFF3CFE3$74%$(KFC7F$/MC7E5333FwLF3CFE3$74%$(KFC7F $/MC7E5307FwL03CFE3$74%$(KFC7F$/SC7E7333FFC07FE73CFE3$74%$(KFC7F$/MC7E7339FvMFE63CCE3$74%$(KFC7F$/MC7C2018FwL11E1E3$74%$(KFC7F$/3h $(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3h$(4%$74%$(KFC7F$/3a (2#$74" )3 $/3a (2#$74" )3 $/3a ( 2#$74" )3 $SLFE1FF8v3a$UPFC3FFC7FFFE03F$TPF87FFC7FFFF80F$TPF0FFFC7FFFFE03$TME1FFFE3Fv3!$TME3FFFE3FvKE03F$SMC3FFFE1FvKF80F$S3(v2?v KFE03$S2/v2?w3!$RKFE1Fv2/wKE03F$QKFC3Fv30wKF80F$QKFC7Fv30wKFE03$QKF87Fv3(x3!$Q42w3hxKE03F$P4#w3hxKF80F$P3dw4%xKFE03$P3(w4%y3!$P3(w 4%yKE03F$O2/w43yKF80F$NKFE1Fw43yKFE03$NKFC3Fw43z3!$NKF87Fw4:zKE03F$M42x4:zKF80F$M42xKF87FyKFE03$M4#xKFC7Fz3!$M3dxKFC7FzKE03F$L3(x KFC3FzKF80F$L2/xKFE3FzKFE03$KKFE1FxKFE3F$'3!$KKFE1FxKFE1F$'KE03F$JKFC3Fy2?$'KF80F$JKF87Fy2?$'KFE03$J42z2/$(3!$J4#z30$(KE03F$I3dz30 $(KF80F$I3dz3h$(KFE03$I3(z3h$)3!$I2/z3h$)KE03F$GKFE1Fz4%$)KF80F$GKFC3Fz4%$)KFE03$GKF87Fz4%$*3!$GKF87Fz43$*KE03F$F42$'43$*KF80F$F4# $'42$*KFE03$F3d$'4:$+3!$F3($'4:$+KE03F$E30$'KF87F$*KF80F$E2/$'KFC7F$*KFE03$DKFE1F$'KFC7F$+3!$DKFC3F$'KFC3F$+KE03F$CKF87F$'KFE3F$+ KF80F$C42$(KFE3F$+KFE03$C43$)2?$,3!$C4#$)2?$,KE03F$B3d$)2?$,KF80F$B3($)30$,KFE03$;42 )x +1?y3!$;42 )x +L3FFFF0 )2#$542 )x +L3FFFF0 )2#$543$(4:x2?$)MFE3FFFF0 )2#$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1 $)4%$543$(4:x2?$)MFE3FFFF1$'LF1FFE3$5SF1E03018E00FFF8380F8x\180C063803FFF8A01018C23FFFF180C063803FvLF9FFE3$5SF1F399CCE667FFE3CE78x \1CE6733999FFF23399CCE63FFFF1CE6733999FvLF9FFE3$5SF1F399CC4673FFC9CE78xa1CE673119CFFE73399CC663FFFF1CE673119CFFF0F8918E3$5 SF1F399CC467301C9CE78xa1CE673119CC067F2F9CC663FFFF1CE673119CC0667319CE3$5SF1F3399CA673FFC9CCF8x a1CCE67299CFFE7F0F99CA63FFFF1CCE67299CFFCF3399CE3$5SF1F0783CA673FF9CC1F8xa1C1E0F299CFFE7F2F83CA63FFFF1C1E0F299CFFC03399CE3$5 SF1F3F99CE6730180CCF8xa1CFE67399CC067F3999CC63FFFF1CFE67399CC04FF399CE3$5SF1F3F9CCE667FF9CCE78x a1CFE733999FFF33399CCC63FFFF1CFE733999FFE633198E3$5SF1E0F0C0400FFF080638xa183C301003FFF86010C0663FFFF183C301003FFF0788C463$543$(4: x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4: x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x +L3FFFF0 )2#$542 )x +L3FFFF0 )2#$542 )x +L3FFFF0 )2#$542 )x2?$)MFE3FFFF1$)4% $543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$'LFC7FE3$543$(4:xL1E3801$' PFE3FFFF1E3801FxLFE7FE3$5MF1E3801Fy4:xL1F399C$'PFE3FFFF1F399CFxLFE7FE3$5MF1F399CFy4:xL1F119CwP85C3C4447E3FFF."F1K19CFwMC3E24623 $5*"K19CFwL83C478xQ1F119CFC07FF3199,"E30>? 4A*"R19CFFE03FF99CC6723$5*"Q19CFFE03FFF9E3F8xL1F2999vLFE793C."E70>? NFFF1F2999FwM3CCE6723$5MF1F2999FwLF9E7F8xL1F2983vLFE7F00*"0>? NFFF1F2983FwM00CE6723$5MF1F2983FwL81E7F8xQ1F3999FC07FE7F3F*"0>? UFFF1F3999FFE03FF3FCE6723$5SF1F3999FFE03FF39E7F8xL1F399CwK3998*"0>? NFFF1F399CFwM98CC6623$5MF1F399CFwL31E7F8xM1E100C7FvM83C1C0C20>? NFFF1E100C7wMC1E23103$5MF1E100C7wL88C0F8x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$) MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$543$(4:x2?$)MFE3FFFF1$)4%$542 )x +L3FFFF1$)4%$542 )x +L3FFFF0 )2#$542 )x +L3FFFF0 )2#$P42 )2#'~'~'~'~'~&! end e showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (5\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f 52.9 0 32 (In the examples shown, a Directory System READ [1] request is sufficient to obtain the rule) W 300 -2700 M 177.5 0 32 (and no conflict arises even though two different nodes \(as shown in fig.3\) have the same) W 300 -4200 M (mapping rule.) h 300 -6300 M 44.6 0 32 (Due to the distribution of the DIB on different sites, it may be convenient to design the DIB,) W 300 -7800 M 190.3 0 32 (so that it can be divided into different subtrees \(local DIT\) each representing a particular) W 300 -9300 M (country. In the example shown in fig.3, each subtree can be stored in 'national' DSAs.) h 3656 -11550 M 3656 -13850 M 3656 -16150 M 3656 -18450 M 3656 -20750 M 3656 -23050 M 3656 -25350 M 3656 -27650 M 3656 -29950 M 3656 -32250 M /Courier-ISOLatin1 $ /Courier & P /Courier-ISOLatin1 F 1400 o f ( ) h 3656 -34550 M 2100 -36700 M 6060 -36700 M 11820 -36700 M 17580 -36700 M /Times-Roman-ISOLatin1 F 1200 o f ( Fig. 3) h 2100 -38800 M 300 -40900 M 108.8 0 32 (In this way the DIB would represent the union of all the national DITs, and so it would be) W 300 -42400 M 180.3 0 32 (possible to have a well distributed DIB management, because each gateway manager will) W 300 -43900 M (take care of all the updates of the national DIB.) h 300 -46000 M 19.7 0 32 (To actually make use of the Directory Services, with the proposed DIT, we must consider the) W 300 -47500 M 204.1 0 32 (opposite mapping: the retrieval of the rules to translate an RFC\255822 address into an O/R) W 300 -49000 M (address.) h 300 -51100 M 69.7 0 32 (With the proposed DIT, it is clear that it is not simple to obtain a unique RFC\255822 to X.400) W 300 -52600 M (mapping rule.) h 300 -54700 M 1.7 0 32 (In fact, in the case presented in figure 2, we are able to retrieve the right mapping rule related) W 300 -56200 M (to the RFC\255822 address ) h 3656 -58300 M 6060 -58300 M 11820 -58300 M /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f ( arpa) h 300 -60400 M /Times-Roman-ISOLatin1 F 1200 o f 49.4 0 32 (in the whole DIB, with a DS SEARCH[1] operation and a filter on the attribute ) W /Times-Italic-ISOLatin1 F 1200 o f 49.4 0 32 (country) W /Times-Roman-ISOLatin1 F 1200 o f 49.4 0 32 (. But) W 300 -61900 M 77.9 0 32 (the restriction of the SEARCH operation to the national subtree does not solve the problem,) W 300 -63400 M (as shown by the following example. The mapping rules for the nodes \(fig. 2\)) h -7560 6480 T R a 40 dict begin 14093 -38590 T 33555 18982 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 471 236 1 [471 0 0 -236 0 236] {I} image '~'~&$3a '1?$74> '2#$23a '1?$74> '2#$23bzKF83F$7KFC1Fz3$$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7 KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$2KC7E1vNFE381FFE3F$7LFC7F0Fv,"C0KFFE3$2KC7CCwM3A5FFE3F$7LFC7E67vME666FFE3$2 KC7CCvNFE5E7FFE3F$7LFC7E67vME667FFE3$2RC7CFFF07FE5E7FFE3F$7RFC7E7FF83FE661FFE3$2KC7CFvNFE1E7FFE3F$7LFC7E7FvME665FFE3$2 RC7CCFF07FCCE7FFE3F$7RFC7E67F83FE667FFE3$2KC7CCvNFCCE7FFE3F$7LFC7E67vME666FFE3$2KC7E1vNF8C43FFE3F$7LFC7F0Fv("KFFE3$23hzKFE3F$7 KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23a '1?$74> '2#$23a '1?$74> '2#$23a '1?$74> '2#$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7 KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7KFC7FxLE3FFE3$2LC78E03wLF9FE3F$7MFC71C07FvLF3FFE3$2LC7C499wLF9FE3F$7MFC78933FvLF3FFE3$2 LC7C499vKFC300>? $7MFC78933FvL830FE3$2RC7C283FE0FFF99FE3F$7RFC78507FC1FF3267E3$2LC7CA93vMFC19FE3F$7MFC79527FvL3207E3$2RC7CA99FE0FF999FE3F$7 RFC79533FC1FF327FE3$2LC7CE99vMF999BE3F$7MFC79D33FvL3267E3$2LC78E08vMFC0C7E3F$7MFC71C11FvL810FE3$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7 KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23hzKFE3F$7KFC7Fz4%$23a '1?$74> '2#$23a '1?$74> '2#$23a '1?$74> '2#$5KFE3F$?43$9KFE3F$?43$9KFE3F$?43 $9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$? 43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F$?43$9KFE3F $?43$9KFE3F$?43$9KFE3F$?43$44@ *2'$54" *3 $.4@ *2'$54" *3 $.4@ *2'$54" *3 $.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h $54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.NFE3E302380vNFC0C081FC7$5 NE3F8C08E03vNF02040FC7F$.4@0?9 R91267FFFFE652A5FC7$5NE3FCE64499vNF993267C7F$.UFE3E5991267FFFFE673E7FC7$5NE3F9664499vNF993267C7F$.UFE3E5990A67F83FE673E7FC7$5 UE3F9664299FE0FF990667C7F$.UFE3E1992A67FFFFE0F3E7FC7$5NE3F8664A99vNF99320FC7F$.UFE3CC992A67F83FE7F3E7FC7$5 UE3F3264A99FE0FF99327FC7F$.UFE3CC993A67FFFFE7F3E7FC7$5NE3F3264E99vNF99327FC7F$.NFE38C02380vNFC1E1C3FC7$5."E3L008E03vNF02041FC7F $.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.4@ *2'$54%$)KFC7F$.4@ *2'$54" *3 $.4@ * 2'$54" *3 $.KFE3F$)3h$54" *3 $.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$5 4%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h $54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.KFE3F$)3h$54%$)KFC7F$.4@ *2' $54" *3 $.4@ *2'$54" *3 $.4@ *2'$54" *3 $1KF07FvKF07F$;3$w3d$54"wKF83F$;2'w4"$53$wKFC0F$:KFC1FwKF07F$42'x2'$:KF83FwKF81F$3KFC1Fx3" $:KE07FwKFE0F$3KF83Fx4"$:3by2'$3KF07FxKF03F$93$y3b$33byKFC0F$8KFE0Fy4"$33$z2'$8KFC1FyKF03F$22'z3"$8KF07FyKFC1F$1KFC1Fz4"$84"zKFE0F $1KF83FzKF03F$73"$'3$$1KF07FzKFC1F$72'$'3b$13b$'KFE07$6KFE0F$'4"$13$$(3$$6KF83F$'KF83F$/KFE0F$(3a$6KF07F$'KFC1F$/KFC1F$(KF07F$53a $)2'$/KF83F$(KF81F$53$$)3$$/4"$)KFE0F$52'$)3b$/3b$*2#$4KFC1F$)KF07F$.3$$*3b$4KF83F$)KF83F$-KFE0F$*KE07F$34"$*KFC0F$-KFC1F$*KF81F$3 3b$+2'$-KF83F$*KFE0F$32#$+3$$-4"$,2#$2KFE0F$+4"$-3b$,3b$2KFC1F$+KF07F$,2'$,KE07F$1KF07F$+KF81F$+KFE0F$,KF83F$14"$,KFE0F$'42 )$( KFC1F$- )2/$(2'$'42 )w4> +3 $' )2/w3a *L07FFF0 )w4> +3 $' )2/w3a *L07FFF1w4?x4:w4> +3 $'2?$(30w3a *L07FFF1$(4:wKFC7F$)KFC7F$'2?$( 30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:w KFC7F$)KFC7F$'S1F8102380FFC607FFF8Fw3h$*PC7FFF18102380FvLF181F8wVFC70204701FE06040180207C7F$'S1FCC991267FE733FFF8FwNC7C0811C07z PC7FFF1CC991267vLF9CCF8wVFC7993224CFF339D29D9A97C7F$'S1FCC991267FCB33FFF8FwNC7E64C8933zPC7FFF1CC991267vLF2CCF8w VFC7993224CFF339F38D9F9FC7F$'S1FCC830A641CB07FFF8FwRC7E64C8933FE1C3208vUC7FFF1CC830A67F83FF2C1F8wVFC7990614C83079F385879FC7F$' S1FC1932A67FC327FFF8Fw[C7E64185320CCF98A27FFFC7FFF1C1932A67vLF0C9F8wVFC7832654CFF339F3A1979FC7F$'S1FCF992A6419933FFF8Fw `C7E0C99533FC0C19E67FFFC7FFF1CF992A67F83FE64CF8wVFC79F3254C83339F3B19F9FC7F$'S1FCF993A67F9933FFF8Fw [C7E7CC95320CF999E67FFFC7FFF1CF993A67vLE64CF8wVFC79F3274CFF339F3B99B9FC7F$'S1F8308380FF1811FFF8Fw [C7E7CC9D33FCC999E67FFFC7FFF18308380FvLC60478wOFC70610701FE,"06N119030FC7F$'2?$(30wWC7C1841C07FE1C00427FFFC7FFF1$(4:wKFC7F$) KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF0 )w4> +3 $' )2/w3h$*LC7FFF0 )w 4> +3 $' )2/w3a *L07FFF0 )w4> +3 $' )2/w3a *L07FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3a *L07FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:w KFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7FvK1FCFyKFC7F$'L1F8E03z30w."C72!$(NC7FFF1C701z4:w RFC6380FF9FFF3FFFF9vKFC7F$'L1FC499z30wLC7E24C$(NC7FFF1E24Cz4:wRFC71267F9FFF3FFFF9vKFC7F$'L1FC499vNFC323FFF8FwLC7E24CvMFE1C3208v NC7FFF1E24CvNFE191FFFF8wVFC71267F830E011C303FFFFC7F$'S1FC283FE0FFF98BFFF8Fw`C7E141FF07FCCF98A27FFFC7FFF1E141FF07FFCC5FFFF8w RFC70A0C199CF3C4999vKFC7F$'L1FCA93vKFC19v30wLC7E549vTFC0C19E67FFFC7FFF1E549vKFE0Cv4:wRFC72A4FF99CF3CC819vKFC7F$'P1FCA99FE0FF999v30 w]C7E54CFF07FCF999E67FFFC7FFF1E54CFF07FCCCv4:wRFC72A64199CF3CC9F9vKFC7F$'L1FCE99vKF999v30wLC7E74CvTFCC999E67FFFC7FFF1E74CvKFCCCv4: wVFC73A67F99CF34C999BFFFFC7F$'L1F8E08vNFC007FFF8Fw*"^047FFFFE1C00427FFFC7FFF1C7047FFFFE003FFFF8wMFC63823F,"03P884C3C7FFFFC7F$'2? $(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF1$(4:wKFC7F$)KFC7F$'2?$(30w3h$*LC7FFF0 )w KFC7F$)KFC7F$' )2/w3h$*LC7FFF0 )w4> +3 $' )2/w3a *L07FFF0 )w4> +3 $' )2/w3a *2'$.4> +3 $43a *2''~'~'~'~'~$U end e showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (6\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 13996 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f ( ) h /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f (C=AT; ) h /Times-Roman-ISOLatin1 F 1200 o f (and) h /Times-Italic-ISOLatin1 F 1200 o f ( C=AT; ADMD= ;) h 300 -3300 M /Times-Roman-ISOLatin1 F 1200 o f (are the same. So having the RFC\255822 address) h 3656 -5400 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (mark.adit.at) h 300 -7500 M /Times-Roman-ISOLatin1 F 1200 o f (it is not possible to state if the corresponding O/R address is) h 300 -9600 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (C=AT; ADMD= ; PRMD=ADIT; O=MARK;) h 300 -11700 M /Times-Roman-ISOLatin1 F 1200 o f (or) h 300 -13800 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f ( C=AT; ADMD=ADIT; PRMD=MARK;) h 300 -15900 M /Times-Roman-ISOLatin1 F 1200 o f 5.5 0 32 (due to the existence of two different entries in the DIB. So, in general, a SEARCH operation,) W 300 -17400 M 113.5 0 32 (independently from the subtree restrictions \(e.g. a country subtree\), will produce more than) W 300 -18900 M (one mapping rule, and so ambiguous situations can arise.) h 300 -21000 M 141.8 0 32 (In conclusion, while a Directory System may be a useful support for the translation of the) W 300 -22500 M 315.9 0 32 (X.400 addresses into RFC\255822 addresses, the DIB design proposed does not allow the) W 300 -24000 M 30.2 0 32 (Directory to solve the mapping on the opposite direction. Additional knowledge is needed by) W 300 -25500 M (the RFC987 gateway to resolve ambiguity in the mapping from RFC\255822 to O/R addresses.) h 300 -27600 M 85.3 0 32 (The storage and management of this additional knowledge is equivalent to have a local \(i.e.) W 300 -29100 M (in each RFC987 gateway\) RFC822 to X.400 conversion table.) h 300 -31200 M 202.1 0 32 (So we left this DIB arrangement and we started the evaluation of alternatives, which are) W 300 -32700 M (reported on the next paragraph.) h 2100 -34950 M 300 -37100 M /Helvetica-ISOLatin1 F 1200 o f (4.2. Another Possible DIB Arrangement) h 300 -39200 M /Times-Roman-ISOLatin1 F 1200 o f 30.7 0 32 (An alternative way to structure the DIT is to organize it according to the RFC\255822 addresses.) W 300 -40700 M 20.2 0 32 (This means the use of the RFC domains and subdomains as RDN, using the X.400 address as) W 300 -42200 M (node attributes. ) h 3900 -44450 M 3900 -46750 M 3900 -49050 M 3900 -51350 M 3900 -53650 M 3900 -55950 M 3900 -58250 M 300 -60400 M 6060 -60400 M 11820 -60400 M ( ) h 300 -62500 M 6060 -62500 M 11820 -62500 M ( Fig. 4) h -7560 6480 T R a 40 dict begin 16011 -66609 T 24159 16203 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 471 236 1 [471 0 0 -236 0 236] {I} image '~'~$t4@ 12#$H4@ 12#$H4@ 12#$HKFE3F$*30y4%$HKFE3F$*30y4%$HKFE3F$*30y4%$HKFE3F$*30y4%$HKFE3F$*30y4%$HKFE3Fz4%w30y4%$HOFE3F80C0E30Fv 45w30y4%$HOFE3FCE66739Fv45w30y4%$HSFE3FCE67319FFE1F1231v30y4%$HSFE3FCE6731980CCE6339v30y4%$HSFE3FCCE7329FF9E67339v30y4%$H SFE3FC1E7329FF8067339v30y4%$HSFE3FCCE7331809FE7339v30y4%$HSFE3FCE66731FFCC66331v30y4%$HSFE3F8600E19FFE0F1188v30y4%$HKFE3F$*30y4%$H KFE3F$*30y4%$HKFE3F$*30y4%$HKFE3F$*30y4%$H4@ +2/y4%$H4@ +2/y4%$H4@ +2/y4%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$H KFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HQFE3FFFFC5FFC0C03$*4%$HQFE3FFFF91FFF3C93$*4%$HRFE3FFFF39FFF3C93CF$)4%$H RFE3FFFF3F80F3F9FCF$)4%$HMFE3FFFF3vK3F9F$*4%$HMFE3FFFF3vK3F9F$*4%$HQFE3FFFF3F80F3F9F$*4%$HRFE3FFFF99FFF3F9FCF$)4%$HOFE3FFFFC3FFC ,"0F3p$)4%$HKFE3Fz3@$)4%$HKFE3Fz3`$)4%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HQFE3FFFF07038E00F$*4%$H QFE3FFFFC799CE667$*4%$HQFE3FFFF939CC4673v45$'4%$HTFE3FFFF939CC467301FFF3$'4%$HQFE3FFFF939CCA673$*4%$HQFE3FFFF399CCA673$*4%$H RFE3FFFF019CCE67301$)4%$HQFE3FFFF3999CE667v45$'4%$HQFE3FFFE10038400Fv45$'4%$HKFE3F$(4)$'4%$HKFE3F$(41$'4%$HKFE3F$04%$HKFE3F$04%$H KFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$H4@ 12#$H4@ 12#$H4@ 12#$Q4%$Z4% $Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z 4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$Z4%$X4@r1?$WLC00001$XLF8000F$YK007F$Y4%$Q4@ 12#$H4@ 12#$H4@ 12#$HKFE3F$*30y4%$H KFE3F$*30y4%$HKFE3F$*30y4%$HKFE3F$*30y4%$HKFE3F$*30y4%$HOFE3F80C0E30Fz30y4%$HOFE3FCE66739Fz30y4%$HVFE3FCE67319FFE112631E7FF8Fy4%$H VFE3FCE6731980CC49339E7FF8Fy4%$HSFE3FCCE7329FF9E49339v30y4%$HSFE3FC1E7329FF9FC9339v30y4%$HSFE3FCCE7331809FC9339v30y4%$H VFE3FCE66731FFCE49331E7FF8Fy4%$HVFE3F8600E19FFE089188E7FF8Fy4%$HKFE3F$(LCFFF8Fy4%$HKFE3F$(LDFFF8Fy4%$HKFE3F$*30y4%$H4@ +2/y4%$H4@ +2/y4%$H4@ +2/y4%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HQFE3FFFF8BFF81807$*4%$HQFE3FFFF23FFE7927$*4% $HRFE3FFFE73FFE79279F$)4%$HRFE3FFFE7F01E7F3F9F$)4%$HQFE3FFFE7FFFE7F3F$*4%$HQFE3FFFE7FFFE7F3F$*4%$HQFE3FFFE7F01E7F3F$*4%$H RFE3FFFF33FFE7F3F9F$)4%$HRFE3FFFF87FF81E1F9F$)4%$HKFE3Fz1?$)4%$HKFE3Fz3 $)4%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$H QFE3FFFF07038E00F$*4%$HQFE3FFFFC799CE667$*4%$HQFE3FFFF939CC4673v45$'4%$HTFE3FFFF939CC467301FFF3$'4%$HQFE3FFFF939CCA673$*4%$H QFE3FFFF399CCA673$*4%$HRFE3FFFF019CCE67301$)4%$HQFE3FFFF3999CE667v45$'4%$HQFE3FFFE10038400Fv45$'4%$HKFE3F$(4)$'4%$HKFE3F$(41$'4%$H KFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HKFE3F$04%$HSFE3FFFF87FFF8A38087F$(4%$HRFE3FFFF33FFF23399C$)4%$HSFE3FFFE79FFE73119CF3$( 4%$HSFE3FFFE7980E7F119CF3$(4%$HRFE3FFFE79FFE7F299C$)4%$HRFE3FFFE79FFE7F299C$)4%$HRFE3FFFE7980E7F399C$)4%$HSFE3FFFF33FFF33399CF3$( 4%$HSFE3FFFF87FFF8610C1F3$(4%$HKFE3F$'4)$(4%$HKFE3F$'41$(4%$HKFE3F$04%$HKFE3F$04%$H4@ 12#$H4@ 12#$H4@ 12#'~'~&o end e showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (7\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M 300 -3300 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f 12.0 0 32 (Also with this organization of the DIB we have to face the problem of duplicated RFC\255822 to) W 300 -4800 M (X.400 mapping rules.) h 300 -6900 M 158.0 0 32 (Therefore, we need to represent different entities with the same DistinguishedName in the) W 300 -8400 M (DIT.) h 300 -10500 M (For example, if we have the following mapping rules:) h 3900 -12600 M 6060 -12600 M (edu \255\255\255\255\255> C=IT; ADMD= ;) h 3900 -14700 M 6060 -14700 M (edu \255\255\255\255\255> C=FR; ADMD=ATLAS;) h 3900 -16800 M 6060 -16800 M (cmu.edu \255\255\255\255\255> C=IT; ADMD= ; O=CMU;) h 3900 -18900 M 6060 -18900 M (cmu.edu \255\255\255\255\255> C=FR; ADMD=ATLAS; O=CMU;) h 300 -21000 M (we need to represent the following entries in the DIT:) h 3900 -23100 M 3900 -25200 M 3900 -27450 M 3900 -29750 M 3900 -32050 M 3900 -34350 M 3900 -36650 M 3900 -38950 M 3900 -41250 M 3900 -43400 M 3900 -45500 M 3900 -47600 M ( Fig. 5) h 3900 -49700 M 300 -51800 M 43.3 0 32 (In order to solve these ambiguities, we could use some trick in the DIT design. For example,) W 300 -53300 M 103.9 0 32 (we can add one RDN to the duplicated entries to differentiate them. But, solutions like this) W 300 -54800 M 94.9 0 32 (would not allow the storing of real RFC\255822 addresses and, therefore, there would be some) W 300 -56300 M (other problems in finding them.) h 300 -58400 M 149.3 0 32 (Another possible solution is to make use of the RFC\255822 address components as RDN, as) W 300 -59900 M (before, but with multivalued attributes [1] for the X.400 address components.) h 300 -62000 M (In this way the entries in the previous picture will be represented as:) h -7560 6480 T R a 40 dict begin 17161 -50534 T 25406 20420 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 471 236 1 [471 0 0 -236 0 236] {I} image '~&t4: 12/$(4: 12/$-4: 12/$(4: 12/$-4: 12/$(4: 12/$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$* KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$'30vKFE3Fy30$(4:$'30vKFE3Fy30$-KF8FE,"03K8C3Fv3pvKFE3Fy30$( KF8FE("K8C3Fv3pvKFE3Fy30$-OF8FF3999CE7Fv3pvKFE3Fy30$(OF8FF3999CE7Fv3pvKFE3Fy30$-VF8FF399CC67FF87C48C7FFFE3Fy30$( VF8FF399CC67FF87C48C7FFFE3Fy30$-VF8FF399CC66033398CE7FFFE3Fy30$(VF8FF399CC66033398CE7FFFE3Fy30$-VF8FF339CCA7FE799CCE7FFFE3Fy30$( VF8FF339CCA7FE799CCE7FFFE3Fy30$-VF8FF079CCA7FE019CCE7FFFE3Fy30$(VF8FF079CCA7FE019CCE7FFFE3Fy30$-VF8FF339CCC6027F9CCE7FFFE3Fy30$( VF8FF339CCC6027F9CCE7FFFE3Fy30$-VF8FF3999CC7FF3198CC7FFFE3Fy30$(VF8FF3999CC7FF3198CC7FFFE3Fy30$-VF8FE1803867FF83C4623FFFE3Fy30$( VF8FE1803867FF83C4623FFFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$( 4:$*KFE3Fy30$-4: +1?y30$(4: +1?y30$-4: +1?y30$(4: +1?y30$-4: +1?y30$(4: +1?y30$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4: $130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:vNF17FF0300F$*30$( 4:vNF17FFC0203$*30$-4:vNE47FFCF24F$*30$(4:vNE47FFE7339$*30$-4:vOCE7FFCF24F3F$)30$(4:vOCE7FFE7339E7$)30$-4:vOCFE03CFE7F3F$)30$(4:v OCFE03E5F39E7$)30$-4:vNCFFFFCFE7F$*30$(4:vNCFFFFE1F33$*30$-4:vNCFFFFCFE7F$*30$(4:vNCFFFFE5F07$*30$-4:vNCFE03CFE7F$*30$(4:v NCFE03E7F33$*30$-4:vOE67FFCFE7F3F$)30$(4:vOE67FFE7F39E7$)30$-4:vMF0FFF03C."3F$)30$(4:vOF0FFFC1E18E7$)30$-4:zKFE7F$)30$(4:$'3p$) 30$-4:z4@$*30$(4:$'4!$)30$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:vNC1C0E3803F$*30$(4:v UC1C0E3803FFF838041F07C2Fw30$-4:vNF1E673999F$*30$(4:vUF1E673999FFFE39267FC798Fw30$-4:vNE4E73119CFv3p$'30$(4:v VE4E73119CFFFC99267F939CF3Fv30$-4:vQE4E73119CC07FFCF$'30$(4:vVE4E73119CC07C9F3E7F939FF3Fv30$-4:vNE4E73299CF$*30$(4:v UE4E73299CFFFC9F3E7F93C1Fw30$-4:vNCE673299CF$*30$(4:vUCE673299CFFF9CF3E7339FCFw30$-4:vOC0673399CC07$)30$(4:v UC0673399CC0780F3E73019CFw30$-4:vNCE6673999Fv3p$'30$(4:vVCE6673999FFF9CF3E73398CF3Fv30$-4:vN8400E1003Fv3p$'30$(4:v V8400E1003FFF0861C0210A1F3Fv30$-4:$)3@$'30$(4:$-KFE7Fv30$-4:$)3`$'30$(4:$-4@w30$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$- 4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4: 12/$(4: 12/$-4: 12/$(4: 12/$-4: 12/$(4: 12/$630$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$: 30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30 $?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$?30$:30$? 30$:30$?30$:30$?30$:30$?30$:30$?30$:30$=4:r$74:r$=q2'$8q2'$=LE0003F$8LE0003F$=KFC01$9KFC01$?30$:30$64: 12/$(4: 12/$-4: 12/$(4: 12/ $-4: 12/$(4: 12/$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$-4:$*KFE3Fy30$(4:$*KFE3Fy30$- 4:$*KFE3Fy30$(4:$*KFE3Fy30$-KF8FE("K8C3FyKFE3Fy30$(KF8FE("K8C3FyKFE3Fy30$-OF8FF3999CE7FyKFE3Fy30$(OF8FF3999CE7FyKFE3Fy30$- VF8FF399CC67FF84498C79FFE3Fy30$(VF8FF399CC67FF84498C79FFE3Fy30$-VF8FF399CC66033124CE79FFE3Fy30$(VF8FF399CC66033124CE79FFE3Fy30$- VF8FF339CCA7FE7924CE7FFFE3Fy30$(VF8FF339CCA7FE7924CE7FFFE3Fy30$-VF8FF079CCA7FE7F24CE7FFFE3Fy30$(VF8FF079CCA7FE7F24CE7FFFE3Fy30$- VF8FF339CCC6027F24CE7FFFE3Fy30$(VF8FF339CCC6027F24CE7FFFE3Fy30$-VF8FF3999CC7FF3924CC79FFE3Fy30$(VF8FF3999CC7FF3924CC79FFE3Fy30$- VF8FE1803867FF82246239FFE3Fy30$(VF8FE1803867FF82246239FFE3Fy30$-4:$)L3FFE3Fy30$(4:$)L3FFE3Fy30$-4:$)L7FFE3Fy30$(4:$)L7FFE3Fy30$-4: $*KFE3Fy30$(4:$*KFE3Fy30$-4: +1?y30$(4: +1?y30$-4: +1?y30$(4: +1?y30$-4: +1?y30$(4: +1?y30$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130 $(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:vNE2FFE0601F$*30$(4:vNE2FFF0080F$*30$-4:vNC8FFF9E49F$*30$(4:v NC8FFF9CCE7$*30$-4:vO9CFFF9E49E7F$)30$(4:vO9CFFF9CCE79F$)30$-4:vO9FC079FCFE7F$)30$(4:vK9FC00y| KE79F$)30$-4:vM9FFFF9FC$+30$(4:vN9FFFF87CCF$*30$-4:vM9FFFF9FC$+30$(4:vN9FFFF97C1F$*30$-4:vM9FC079FC$+30$(4:vN9FC079FCCF$*30$-4:v3m Jwqtv 3 $)30$(4:vOCCFFF9FCE79F$)30$-4:vOE1FFE0787E7F$)30$(4:vOE1FFF078639F$)30$-4:z4>$*30$(4:$'1?$)30$-4:z4?$*30$(4:$'3 $)30$-4:$130$(4: $130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:vNC1C0E3803F$*30$(4:vUC1C0E3803FFF838041F07C2Fw30$-4:vNF1E673999F$*30$(4:v UF1E673999FFFE39267FC798Fw30$-4:vNE4E73119CFv3p$'30$(4:vVE4E73119CFFFC99267F939CF3Fv30$-4:vQE4E73119CC07FFCF$'30$(4:v VE4E73119CC07C9F3E7F939FF3Fv30$-4:vNE4E73299CF$*30$(4:vUE4E73299CFFFC9F3E7F93C1Fw30$-4:vNCE673299CF$*30$(4:v UCE673299CFFF9CF3E7339FCFw30$-4:vOC0673399CC07$)30$(4:vUC0673399CC0780F3E73019CFw30$-4:vNCE6673999Fv3p$'30$(4:v VCE6673999FFF9CF3E73398CF3Fv30$-4:vN8400E1003Fv3p$'30$(4:vV8400E1003FFF0861C0210A1F3Fv30$-4:$)3@$'30$(4:$-KFE7Fv30$-4:$)3`$'30$(4: $-4@w30$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:$130$(4:$130$-4:vOE1FFFE28E021$)30$(4:vOE1FFFE28E021$) 30$-4:vOCCFFFC8CE673$)30$(4:vOCCFFFC8CE673$)30$-4:vP9E7FF9CC4673CF$(30$(4:vP9E7FF9CC4673CF$(30$-4:vP9E6039FC4673CF$(30$(4:v P9E6039FC4673CF$(30$-4:vO9E7FF9FCA673$)30$(4:vO9E7FF9FCA673$)30$-4:vO9E7FF9FCA673$)30$(4:vO9E7FF9FCA673$)30$-4:vO9E6039FCE673$)30 $(4:vO9E6039FCE673$)30$-4:vPCCFFFCCCE673CF$(30$(4:vPCCFFFCCCE673CF$(30$-4:vPE1FFFE184307CF$(30$(4:vPE1FFFE184307CF$(30$-4:$(3@$(30 $(4:$(3@$(30$-4:$(3`$(30$(4:$(3`$(30$-4:$130$(4:$130$-4:$130$(4:$130$-4: 12/$(4: 12/$-4: 12/$(4: 12/$-4: 12/$(4: 12/'~'~'~$T end e S 17161 -50534 25406 20420 @ S 100 w 0 c 0 j 2 i 0.00 G - + * k R R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (8\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 2100 -1350 M 6060 -1350 M 11820 -1350 M 2100 -3650 M 2100 -5950 M 2100 -8250 M 3900 -10550 M 6060 -10550 M 11820 -10550 M 17580 -10550 M 3900 -12850 M 6060 -12850 M 11820 -12850 M 17580 -12850 M 3900 -15150 M 6060 -15150 M 11820 -15150 M 17580 -15150 M 3900 -17450 M 3900 -19750 M 300 -21900 M 6060 -21900 M 11820 -21900 M 17580 -21900 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f (Fig. 6) h 300 -24000 M 300 -26100 M 64.5 0 32 (If we organize the DIB in this way and we make use of the Directory System access control) W 300 -27600 M 17.7 0 32 (facility [1], each gateway can have access to the right \(i.e. suitable for that gateway\) mapping) W 300 -29100 M (rules.) h 300 -31200 M (Our analysis identified the following access rights as sufficient to achieve the goal:) h 3900 -33300 M 66.2 0 32 (\255 ) W /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f 66.2 0 32 (Compare Access Right ) W /Times-Roman-ISOLatin1 F 1200 o f 66.2 0 32 (\(on all the attributes values\) granted to all gateways \(so that) W 4980 -34800 M (each gateway can search for an X.400 address\);) h 3900 -36900 M 60.9 0 32 (\255 ) W /Times-Italic-ISOLatin1 F 1200 o f 60.9 0 32 (Read Access Right ) W /Times-Roman-ISOLatin1 F 1200 o f 60.9 0 32 (only on the attributes values representing the RFC\255822 to X.400) W 4980 -38400 M (address mapping rules that gateway must use;) h 300 -40500 M 175.6 0 32 (With this arrangement it is possible to use the Directory System to identify the necessary) W 300 -42000 M (RFC\255822 to X.400 mapping rules and viceversa.) h 300 -44100 M 99.7 0 32 (As an example, let us assume a gateway has to translate an RFC\255822 address. The gateway) W 300 -45600 M 48.3 0 32 (will issue a READ operation to the Directory. This READ will have as input\255Name the RFC) W 300 -47100 M (address and it will return the attributes values which the gateway has Read Access right on.) h 300 -49200 M 71.4 0 32 (Therefore, the gateway will get only the useful values corresponding to its specific mapping) W 300 -50700 M (rule.) h 300 -52800 M 47.6 0 32 (On the other hand, if a gateway has to transform an X.400 address into an RFC\255822 address,) W 300 -54300 M 99.5 0 32 (it can issue a SEARCH operation on all the DIB. With this operation, the gateway asks the) W 300 -55800 M 83.1 0 32 (Directory to search for the nodes having, as attribute values, exactly the ones that are in the) W 300 -57300 M (X.400 address to be translated.) h 300 -59400 M 11.4 0 32 (As all gateways have Compare Access rights on all attribute values, this SEARCH will return) W 300 -60900 M (the Distinguished Names of all the nodes having the specified attribute values. ) h 300 -63000 M -7560 6480 T R a 40 dict begin 13518 -25749 T 32405 17544 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 471 236 1 [471 0 0 -236 0 236] {I} image '~'~&h4> 12'$H4> 12'$H4> 12'$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7Fz3hw2?y3h$HOFC7F0181C61Fv 4)w2?y3h$HOFC7F9CCCE73Fv4)w2?y3h$HSFC7F9CCE633FFC3E2463v2?y3h$HSFC7F9CCE6330199CC673v2?y3h$HSFC7F99CE653FF3CCE673v2?y3h$H SFC7F83CE653FF00CE673v2?y3h$HSFC7F99CE663013FCE673v2?y3h$HSFC7F9CCCE63FF98CC663v2?y3h$HSFC7F0C01C33FFC1E2311v2?y3h$HKFC7F$*2?y3h$H KFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$H4> +2?y3h$H4> +2?y3h$H4> +2?y3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H KFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HUFC7FFFF8BFF81807FF80407Fz3h$HUFC7FFFF23FFE7927FFCE673Fz3h$H UFC7FFFE73FFE79279FCE673Cz3h$HUFC7FFFE7F01E7F3F9FCBE73Cz3h$HUFC7FFFE7FFFE7F3FFFC3E67Fz3h$HTFC7FFFE7FFFE7F3FFFCBE0$'3h$H UFC7FFFE7F01E7F3FFFCFE67Fz3h$HUFC7FFFF33FFE7F3F9FCFE73Cz3h$HUFC7FFFF87FF81E1F9F83C31Cz3h$HKFC7Fz1?v4;z3h$HKFC7Fz3 v4=z3h$HKFC7F$0 3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HLFC7FFF,"E0L71C01FwQF070083E0F85FFC7$HQFC7FFFF8F339CCCFwQFC724CFF8F31FFC7$H QFC7FFFF273988CE7vRE7F9324CFF2739E7C7$H\FC7FFFF273988CE603FFE7F93E7CFF273FE7C7$HQFC7FFFF273994CE7wQF93E7CFF2783FFC7$H QFC7FFFE733994CE7wQF39E7CE673F9FFC7$HRFC7FFFE03399CCE603vQF01E7CE60339FFC7$HQFC7FFFE73339CCCFvRE7F39E7CE67319E7C7$H QFC7FFFC20070801FvRE7E10C38042143E7C7$HKFC7F$(3pzKCFC7$HKFC7F$(4!zKDFC7$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H KFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H4> 12'$H4> 12'$H4> 12'$Q3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z 3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h$Z3h $Z3h$Z3h$Z3h$Z3h$Z3h$X4>r3 $WL800003$XLF0001F$XKFE00$Z3h$Q4> 12'$H4> 12'$H4> 12'$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F $*2?y3h$HKFC7F$*2?y3h$HOFC7F0181C61Fz2?y3h$HOFC7F9CCCE73Fz2?y3h$HVFC7F9CCE633FFC224C63CFFF1Fy3h$HVFC7F9CCE633019892673CFFF1Fy3h$H SFC7F99CE653FF3C92673v2?y3h$HSFC7F83CE653FF3F92673v2?y3h$HSFC7F99CE663013F92673v2?y3h$HVFC7F9CCCE63FF9C92663CFFF1Fy3h$H VFC7F0C01C33FFC112311CFFF1Fy3h$HKFC7F$(L9FFF1Fy3h$HKFC7F$(LBFFF1Fy3h$HKFC7F$*2?y3h$H4> +2?y3h$H4> +2?y3h$H4> +2?y3h$HKFC7F$03h$H KFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HUFC7FFFF17FF0300FFF80407Fz3h$HUFC7FFFE47FFCF24FFFCE673Fz3h$H UFC7FFFCE7FFCF24F3FCE673Cz3h$HUFC7FFFCFE03CFE7F3FCBE73Cz3h$HUFC7FFFCFFFFCFE7FFFC3E67Fz3h$HTFC7FFFCFFFFCFE7FFFCBE0$'3h$H UFC7FFFCFE03CFE7FFFCFE67Fz3h$HUFC7FFFE67FFCFE7F3FCFE73Cz3h$HPFC7FFFF0FFF03C."3FL83C31Cz3h$HKFC7FyKFE7Fv4;z3h$HKFC7Fy4@w4=z3h$H KFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HLFC7FFF("L71C01Fw("O107C1F0BFFC7$HQFC7FFFF8F339CCCFwQF8E499FF1E63FFC7$H QFC7FFFF273988CE7vRE7F26499FE4E73CFC7$H\FC7FFFF273988CE603FFE7F27CF9FE4E7FCFC7$HQFC7FFFF273994CE7wQF27CF9FE4F07FFC7$H QFC7FFFE733994CE7wQE73CF9CCE7F3FFC7$HRFC7FFFE03399CCE603vQE03CF9CC0673FFC7$HQFC7FFFE73339CCCFv,"E7P3CF9CCE633CFC7$H QFC7FFFC20070801FvRE7C21870084287CFC7$HKFC7F$(3pzK9FC7$HKFC7F$(4!zKBFC7$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H MFC7FFFF0vL147010$)3h$HRFC7FFFE67FFE467339$)3h$HSFC7FFFCF3FFCE62339E7$(3h$HSFC7FFFCF301CFE2339E7$(3h$HRFC7FFFCF3FFCFE5339$)3h$H RFC7FFFCF3FFCFE5339$)3h$HRFC7FFFCF301CFE7339$)3h$HSFC7FFFE67FFE667339E7$(3h$HMFC7FFFF0vM0C2183E7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h $HKFC7F$03h$HKFC7F$03h$H4> 12'$H4> 12'$H4> 12''~'~${ end e S 13518 -25749 32405 17544 @ S 100 w 0 c 0 j 2 i 0.00 G - + * k R R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 22127 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (9\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f (For example, referring to fig.6, if a gateway has to translate the X.400 address) h 2100 -3300 M 6060 -3300 M ( ) h /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f (C=FR; ADMD=ATLAS;) h 300 -5400 M /Times-Roman-ISOLatin1 F 1200 o f 218.6 0 32 (it issues a SEARCH operation in order to find the nodes having as attributes C=FR and) W 300 -6900 M (ADMD=ATLAS. The Directory will return as output the following Distinguished Names:) h 3900 -9000 M /Times-Italic-ISOLatin1 F 1200 o f ( edu ) h /Times-Roman-ISOLatin1 F 1200 o f ( and ) h /Times-Italic-ISOLatin1 F 1200 o f (cmu.edu) h 300 -11100 M /Times-Roman-ISOLatin1 F 1200 o f (It is clear that now the problem is to choose the right RFC\255822 address.) h 300 -13200 M 91.1 0 32 (In order to solve this ambiguity we could insert, in every entry of the DIB, fictitious values) W 300 -14700 M (which act as place holders for those X.400 attributes missed in a mapping rule.) h 300 -16800 M (So the entries in Fig.6 would result:) h 2100 -19050 M 3900 -21350 M 3900 -23650 M 3900 -25950 M 3900 -28250 M 3900 -30550 M 3900 -32850 M 3900 -35000 M (Fig.7) h 3900 -37100 M ( ) h 300 -39200 M 300 -41300 M 89.1 0 32 (With this structure of entries, it is therefore possible to request a SEARCH to find the node) W 300 -42800 M (having as attributes:) h 3900 -44900 M (C=FR; ADMD=ATLAS; PRMD=?; O=?; OU1=?; OU2=?; OU3=?; OU4=?;) h 300 -47000 M (In this way the SEARCH operation will return the unique entry satisfying the condition.) h 300 -49100 M 156.6 0 32 (The previous discussion shows how this second organization of the DIB is better than the) W 300 -50600 M 195.4 0 32 (first since it allows the storage of all the useful information necessary for both kinds of) W 300 -52100 M 22.8 0 32 (address mapping. The use of the Directory allows a single, coordinated and standardized data) W 300 -53600 M (base and it provides a single set of basic services to manage this data repository.) h 300 -55700 M 335.5 0 32 (Moreover, as the Directory is a distributed application, it provides the advantage of a) W 300 -57200 M (distributed access to all information stored in the DIB.) h 300 -59300 M 326.1 0 32 (However, even if the access is distributed, it is not possible to fully benefit from the) W 300 -60800 M 482.7 0 32 (distributed management provided by Directory, because the information is stored as) W 300 -62300 M (multivalued attributes. Therefore, you need a strict cooperation to manage the DIB.) h -7560 6480 T R a 40 dict begin 22818 -45347 T 22434 20708 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 466 404 1 [466 0 0 -404 0 404] {I} image '~'~&h4> 12'$H4> 12'$H4> 12'$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7Fz3hw2?y3h$HOFC7F0181C61Fv 4)w2?y3h$HOFC7F9CCCE73Fv4)w2?y3h$HSFC7F9CCE633FFC3E2463v2?y3h$HSFC7F9CCE6330199CC673v2?y3h$HSFC7F99CE653FF3CCE673v2?y3h$H SFC7F83CE653FF00CE673v2?y3h$HSFC7F99CE663013FCE673v2?y3h$HSFC7F9CCCE63FF98CC663v2?y3h$HSFC7F0C01C33FFC1E2311v2?y3h$HKFC7F$*2?y3h$H KFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$H4> +2?y3h$H4> +2?y3h$H4> +2?y3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H UFC7FFFF8BFF81807FF80407Fz3h$HUFC7FFFF23FFE7927FFCE673Fz3h$HUFC7FFFE73FFE79279FCE673Cz3h$HUFC7FFFE7F01E7F3F9FCBE73Cz3h$H UFC7FFFE7FFFE7F3FFFC3E67Fz3h$HTFC7FFFE7FFFE7F3FFFCBE0$'3h$HUFC7FFFE7F01E7F3FFFCFE67Fz3h$HUFC7FFFF33FFE7F3F9FCFE73Cz3h$H UFC7FFFF87FF81E1F9F83C31Cz3h$HKFC7Fz1?v4;z3h$HKFC7Fz3 v4=z3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HLFC7FFF,"E0 L71C01FwQF070083E0F85FFC7$HQFC7FFFF8F339CCCFwQFC724CFF8F31FFC7$HQFC7FFFF273988CE7vRE7F9324CFF2739E7C7$H \FC7FFFF273988CE603FFE7F93E7CFF273FE7C7$HQFC7FFFF273994CE7wQF93E7CFF2783FFC7$HQFC7FFFE733994CE7wQF39E7CE673F9FFC7$H RFC7FFFE03399CCE603vQF01E7CE60339FFC7$HQFC7FFFE73339CCCFvRE7F39E7CE67319E7C7$HQFC7FFFC20070801FvRE7E10C38042143E7C7$HKFC7F$(3pz KCFC7$HKFC7F$(4!zKDFC7$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HSFC7FFFC06031C01FFF07$(3h$HSFC7FFFE73399CCCFFF33$( 3h$HTFC7FFFE733988CE7FF73E7$'3h$HTFC7FFFE733988CE603F3E7$'3h$HSFC7FFFE673394CE7FFC7$(3h$HSFC7FFFE0F0794CE7FFCF$(3h$H RFC7FFFE7F339CCE603$)3h$HTFC7FFFE7F399CCCFFFCFE7$'3h$HNFC7FFFC1E1."80M1FFFCFE7$'3h$HKFC7F$(3p$'3h$HKFC7F$(4!$'3h$HKFC7F$03h$H KFC7F$03h$HKFC7F$03h$HPFC7FFFF87FFC1F$+3h$HPFC7FFFF33FFCCF$+3h$HQFC7FFFE79FFDCF9F$*3h$HQFC7FFFE7980FCF9F$*3h$HPFC7FFFE79FFF1F$+3h $HPFC7FFFE79FFF3F$+3h$HOFC7FFFE7980F$,3h$HQFC7FFFF33FFF3F9F$*3h$HQFC7FFFF87FFF3F9F$*3h$HKFC7Fy1?$*3h$HKFC7Fy3 $*3h$HKFC7F$03h$H KFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7Fx3@$+3h$HRFC7FFFF870861FFF07$)3h$HRFC7FFFF339CF9FFF33$)3h$HSFC7FFFE799CF9FFF73E7$(3h$H SFC7FFFE799CF9E03F3E7$(3h$HRFC7FFFE799CF9FFFC7$)3h$HRFC7FFFE799CF9FFFCF$)3h$HQFC7FFFE799CF9E03$*3h$HSFC7FFFF339CF9FFFCFE7$(3h$H SFC7FFFF87C1E07FFCFE7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7FwKFE1F$+3h$H RFC7FFFF87084CFFF07$)3h$HRFC7FFFF339CCCFFF33$)3h$HNFC7FFFE799,"CFLFF73E7$(3h$HSFC7FFFE799CFCE03F3E7$(3h$HRFC7FFFE799CF9FFFC7$)3h $HRFC7FFFE799CF3FFFCF$)3h$HQFC7FFFE799CE7E03$*3h$HOFC7FFFF339CCvKCFE7$(3h$HSFC7FFFF87C1C0FFFCFE7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h $HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7FwKFE1F$+3h$HRFC7FFFF87084CFFF07$)3h$HNFC7FFFF339("KFF33$)3h$HNFC7FFFE799(" LFF73E7$(3h$HSFC7FFFE799CF1E03F3E7$(3h$HRFC7FFFE799CFDFFFC7$)3h$HNFC7FFFE799("KFFCF$)3h$HQFC7FFFE799CFCE03$*3h$H SFC7FFFF339CCCFFFCFE7$(3h$HSFC7FFFF87C1E1FFFCFE7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H KFC7F$03h$HRFC7FFFF870878FFF07$)3h$HRFC7FFFF339CF0FFF33$)3h$HSFC7FFFE799CF4FFF73E7$(3h$HSFC7FFFE799CE4E03F3E7$(3h$H RFC7FFFE799CECFFFC7$)3h$HRFC7FFFE799CCCFFFCF$)3h$HQFC7FFFE799CC0603$*3h$HNFC7FFFF339("LFFCFE7$(3h$HSFC7FFFF87C1F87FFCFE7$(3h$H KFC7F$'3p$(3h$HKFC7F$'4!$(3h$HKFC7F$03h$HKFC7F$03h$H4> 12'$H4> 12'$H4> 12'$P4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4: $Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Z4:$Y3!q2/$W42q3 $WLFE0003$YKC01F$Y4:$Z4?$R4> 12'$H4> 12'$H4> 12'$HKFC7F $*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HOFC7F0181C61Fz2?y3h$HOFC7F9CCCE73Fz2?y3h$H SFC7F9CCE633FFF089318v2?y3h$HSFC7F9CCE63301E62499Cv2?y3h$HSFC7F99CE653FFCF2499Cv2?y3h$HSFC7F83CE653FFCFE499Cv2?y3h$H SFC7F99CE66301CFE499Cv2?y3h$HSFC7F9CCCE63FFE724998v2?y3h$HVFC7F0C01C33FFF0448C47FFF1Fy3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h$HKFC7F$*2?y3h $HKFC7F$*2?y3h$H4> +2?y3h$H4> +2?y3h$H4> +2?y3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HUFC7FFFF8BFF81807FF80407Fz 3h$HUFC7FFFF23FFE7927FFCE673Fz3h$HUFC7FFFE73FFE79279FCE673Cz3h$HUFC7FFFE7F01E7F3F9FCBE73Cz3h$HUFC7FFFE7FFFE7F3FFFC3E67Fz3h$H TFC7FFFE7FFFE7F3FFFCBE0$'3h$HUFC7FFFE7F01E7F3FFFCFE67Fz3h$HUFC7FFFF33FFE7F3F9FCFE73Cz3h$HUFC7FFFF87FF81E1F9F83C31Cz3h$HKFC7Fz1?v4; z3h$HKFC7Fz3 v4=z3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HLFC7FFF."E0L71C01FwQF070083E0F85FFC7$H QFC7FFFF8F339CCCFwQFC724CFF8F31FFC7$HQFC7FFFF273988CE7vRE7F9324CFF2739E7C7$H\FC7FFFF273988CE603FFE7F93E7CFF273FE7C7$H QFC7FFFF273994CE7wQF93E7CFF2783FFC7$HQFC7FFFE733994CE7wQF39E7CE673F9FFC7$HRFC7FFFE03399CCE603vQF01E7CE60339FFC7$HQFC7FFFE73339CCCF vRE7F39E7CE67319E7C7$HQFC7FFFC20070801FvRE7E10C38042143E7C7$HKFC7F$(3pzKCFC7$HKFC7F$(4!zKDFC7$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H KFC7F$03h$HKFC7F$03h$HSFC7FFFC06031C01FFF07$(3h$HSFC7FFFE73399CCCFFF33$(3h$HTFC7FFFE733988CE7FF73E7$'3h$HTFC7FFFE733988CE603F3E7$' 3h$HSFC7FFFE673394CE7FFC7$(3h$HSFC7FFFE0F0794CE7FFCF$(3h$HRFC7FFFE7F339CCE603$)3h$HTFC7FFFE7F399CCCFFFCFE7$'3h$HNFC7FFFC1E1,"80 M1FFFCFE7$'3h$HKFC7F$(3p$'3h$HKFC7F$(4!$'3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HSFC7FFFF87FFFE28E021F$(3h$HSFC7FFFF33FFFC8CE673F$(3h $HSFC7FFFE79FFF9CC4673C$(3h$HSFC7FFFE7980F9FC4673C$(3h$HSFC7FFFE79FFF9FCA673F$(3h$HSFC7FFFE79FFF9FCA673F$(3h$H SFC7FFFE7980F9FCE673F$(3h$HSFC7FFFF33FFFCCCE673C$(3h$HSFC7FFFF87FFFE184307C$(3h$HKFC7F$'4;$(3h$HKFC7F$'4=$(3h$HKFC7F$03h$HKFC7F$0 3h$HKFC7F$03h$HKFC7F$03h$HKFC7Fx3@$+3h$HRFC7FFFF870861FFF07$)3h$HRFC7FFFF339CF9FFF33$)3h$HSFC7FFFE799CF9FFF73E7$(3h$H SFC7FFFE799CF9E03F3E7$(3h$HRFC7FFFE799CF9FFFC7$)3h$HRFC7FFFE799CF9FFFCF$)3h$HQFC7FFFE799CF9E03$*3h$HSFC7FFFF339CF9FFFCFE7$(3h$H SFC7FFFF87C1E07FFCFE7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7FwKFE1F$+3h$H RFC7FFFF87084CFFF07$)3h$HRFC7FFFF339CCCFFF33$)3h$HNFC7FFFE799."CFLFF73E7$(3h$HSFC7FFFE799CFCE03F3E7$(3h$HRFC7FFFE799CF9FFFC7$)3h $HRFC7FFFE799CF3FFFCF$)3h$HQFC7FFFE799CE7E03$*3h$HOFC7FFFF339CCvKCFE7$(3h$HSFC7FFFF87C1C0FFFCFE7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h $HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7FwKFE1F$+3h$HRFC7FFFF87084CFFF07$)3h$HNFC7FFFF339*"KFF33$)3h$HNFC7FFFE799*" LFF73E7$(3h$HSFC7FFFE799CF1E03F3E7$(3h$HRFC7FFFE799CFDFFFC7$)3h$HNFC7FFFE799*"KFFCF$)3h$HQFC7FFFE799CFCE03$*3h$H SFC7FFFF339CCCFFFCFE7$(3h$HSFC7FFFF87C1E1FFFCFE7$(3h$HKFC7F$'3p$(3h$HKFC7F$'4!$(3h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$HKFC7F$03h$H KFC7Fx3p$+3h$HRFC7FFFF870878FFF07$)3h$HRFC7FFFF339CF0FFF33$)3h$HSFC7FFFE799CF4FFF73E7$(3h$HSFC7FFFE799CE4E03F3E7$(3h$H RFC7FFFE799CECFFFC7$)3h$HRFC7FFFE799CCCFFFCF$)3h$HQFC7FFFE799CC0603$*3h$HNFC7FFFF339*"LFFCFE7$(3h$HSFC7FFFF87C1F87FFCFE7$(3h$H KFC7F$'3p$(3h$HKFC7F$'4!$(3h$HKFC7F$03h$HKFC7F$03h$H4> 12'$H4> 12'$H4@ 12''~'~'~'~'~'~%. end e S 22818 -45347 22434 20708 @ S 100 w 0 c 0 j 2 i 0.00 G - + * k R R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 21793 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (10\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f 72.7 0 32 (Finally, another problem is related to the use of the SEARCH operations on the whole DIB.) W 300 -2700 M 33.2 0 32 (This drawback can slow down significantly the gateway performances. Therefore, keeping in) W 300 -4200 M 54.4 0 32 (mind also the) W /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f 54.4 0 32 ( best match) W /Times-Roman-ISOLatin1 F 1200 o f 54.4 0 32 ( problem, described in the next paragraph, the mapping from X.400) W 300 -5700 M (to RFC\255822, although possible, can be very hard and inefficient.) h 2100 -7950 M 300 -10100 M /Helvetica-ISOLatin1 F 1200 o f (4.3. The Best Match) h 300 -12100 M /Times-Roman-ISOLatin1 F 1200 o f 46.3 0 32 (As a default mapping rules exists, not all possible addresses are represented in the DIB \(and,) W 300 -13600 M 112.6 0 32 (of course, in the Conversion Tables\). Therefore, whatever the organization of the DIB may) W 300 -15100 M 284.0 0 32 (be, it can happen that a specific address \(X.400 or RFC\) does not exist as a node \(or) W 300 -16600 M 153.7 0 32 (combination of attributes\) in the DIB. In this case, we need to find the node identifying a) W 300 -18100 M 18.9 0 32 (mapping rule, which matches the most, hierarchically highest, components of a given address) W 300 -19600 M (to be translated. This is what we call ) h /Times-Italic-ISOLatin1 F 1200 o f (best match.) h 300 -21700 M /Times-Roman-ISOLatin1 F 1200 o f (For example, if we have the RFC\255822 address) h 300 -23800 M 6060 -23800 M 11820 -23800 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (andrew.cmu.edu) h 300 -25900 M /Times-Roman-ISOLatin1 F 1200 o f (the best match, in Fig.7, is the node ) h 300 -28000 M 6060 -28000 M 11820 -28000 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (cmu..edu) h 300 -30100 M /Times-Roman-ISOLatin1 F 1200 o f (On the other hand, if we have to translate the X.400 address ) h 300 -32200 M 6060 -32200 M 11820 -32200 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (C=IT; ADMD= ; O=CSATA;) h 300 -34300 M /Times-Roman-ISOLatin1 F 1200 o f (the best match, in Fig.7, is represented by the node) h 300 -36400 M 6060 -36400 M 11820 -36400 M ( ) h /Times-Italic-ISOLatin1 F 1200 o f (edu) h 300 -38500 M /Times-Roman-ISOLatin1 F 1200 o f (We have the problem of finding the best match using the Directory operations.) h 300 -40600 M 30.8 0 32 (If we are using the starting address as Distinguished Name, we have to execute the following) W 300 -42100 M (steps:) h 3900 -44200 M 141.3 0 32 (\255 to request a READ operation to the Directory on the DIB node identified by the) W 4980 -45700 M (starting address;) h 3900 -47800 M 101.8 0 32 (\255 if this node doesn't exist, the READ operation will return a Name Error and, also,) W 4980 -49300 M 155.1 0 32 (the name of the lowest entry in the DIT that is matched. In this case we request) W 4980 -50800 M (another READ operation on this entry, looking for a mapping rule;) h 3900 -52900 M 18.3 0 32 (\255 if the entry has no mapping rule, it is necessary to issue further READ operations on) W 4980 -54400 M (the superior entries, until a mapping rule is found or no superior entry remains.) h 300 -56500 M 401.9 0 32 (If, instead, we are searching the DIB for a node having as non RDN attributes the) W 300 -58000 M 112.5 0 32 (components of the address to translate, we have to execute several SEARCH operations on) W 300 -59500 M (all the DIB in order to find the best match as a combination of attribute values.) h 300 -61600 M 363.3 0 32 (It is clear, therefore, that this process implies several READ or SEARCH operations.) W 300 -63100 M 274.0 0 32 (Moreover, if we envisage being in a distributed environment, we can conclude that the) W -7560 6480 T R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 21793 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (11\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f (operation of address mapping, using the Directory System, become very heavy and, therefore,) h 300 -2700 M (inefficient.) h 300 -4800 M 300 -6900 M /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f (5. THE VISNU' GATEWAY) h 300 -9000 M /Times-Roman-ISOLatin1 F 1200 o f 118.4 0 32 (In the future, the X.400 standard will become more and more used, not only for the public) W 300 -10500 M 41.5 0 32 (services but also in the private environment; although at the beginning it will be used mainly) W 300 -12000 M 64.4 0 32 (for the exchanges of messages with the outside. The problems we forecast for a rapid use of) W 300 -13500 M (the X.400 systems in the private environment are:) h 3900 -15600 M (\255 the X.25 networks are not widely used as internal transport systems;) h 3900 -17700 M (\255 X.400 related costs \(both hardware and software\);) h 3900 -19800 M 254.7 0 32 (\255 availability of \(inexpensive\) mail systems \(most of them based on the RFC822) W 4980 -21300 M (specification\).) h 300 -23400 M 168.3 0 32 (In CSATA we decided to develop an RFC987 gateway to speed up the transition, via the) W 300 -24900 M 415.1 0 32 (access to the X.400 services, to the new standard and to solve the problem of full) W 300 -26400 M (interconnectivity among our systems.) h 300 -28500 M 99.6 0 32 (The Visnu' gateway operates on the VAX under VMS using the PMDF [6] as E\255mail relay) W 300 -30000 M 126.9 0 32 (system on the RFC side and the DEC Message Router and DEC MRX [7] as MTA on the) W 300 -31500 M (X.400 side.) h 300 -33600 M 93.9 0 32 (The Visnu' gateway conforms to the RFC987 specification for the services and information) W 300 -35100 M 79.4 0 32 (mapping, while it conforms to the RARE MHS Minimum Profile [4] as far as the addresses) W 300 -36600 M (mapping is concerned.) h 300 -38700 M 86.4 0 32 (From a PMDF point of view the Visnu' gateway is a new ) W /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f 86.4 0 32 (PMDF channel) W /Times-Roman-ISOLatin1 F 1200 o f 86.4 0 32 (, so it is split into) W 300 -40200 M (two programs:) h 3900 -42300 M (\255 the ) h /Times-Italic-ISOLatin1 F 1200 o f (Master Program) h /Times-Roman-ISOLatin1 F 1200 o f (, which handles the outbound flow \(RFC822 to X.400\);) h 3900 -44400 M 3900 -46500 M 3900 -48600 M 3900 -50700 M 3900 -52800 M 3900 -54900 M 3900 -57000 M 3900 -59100 M 3900 -61350 M 3900 -63650 M /Courier-ISOLatin1 $ /Courier & P /Courier-ISOLatin1 F 1400 o f ( ) h /Times-Roman-ISOLatin1 F 1200 o f ( Fig.8: MASTER Program) h -7560 6480 T R a 40 dict begin 12609 -65887 T 34035 15052 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 471 265 1 [471 0 0 -265 0 265] {I} image %(4: -K0380 -1?$=4: -K0380 -1?$=4: -K0380 -1?$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$, KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$, KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$, KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3Fv4> 73 v4:$-KE38F$,KFE3Fv4> 73 v4:$-KE38F$,KFE3Fv4> 73 v4:$-KE38F$, KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3Fv KFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5 KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$- KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$, KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3Fv KFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5 KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$- KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F $'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE3850080C21FE3$' KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE3319CCE673FE3$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE3399CCE673FE3$'KFC7Fv4:$-KE38F$,KFE3FvLFC7FE0t R7FE33F97CE673FE3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tR7FE38387CCF27FE3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tR7FE3F997C1F27FE3FFt L03FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3399CCCF27FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3199CCE78FCE3FF1FxLE3FC7Fv4:$- KE38F$,KFE3FvLFC7FE3xTFC7FE343008638FCE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x LFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3C7818C003FE3FF1FxLE3FC7Fv 4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE39FE7CE673FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE39FE7C6673FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3F vLFC7FE3xTFC7FE39FE7C665FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3CFE7CA61FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE385E7CA65FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE333E7CC67FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE333E7CC67FCE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE389818641FCE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1Fx LE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3E2E1C6010FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3F vbFC7FE380C700700C7FE3C8CCE7339FE3FF1FE3801FFFE3FC7Fv4:$-KE38F$,KFE3FvbFC7FE3CE673339CC7FE39C9E63339FE3FF1FF399CFFFE3FC7Fv4:$- KE38F$,KFE3FvbFC7FE3CE623399CC7FE39F9E63339FE3FF1FF119CFFFE3FC7Fv4:$-KE38F$,KFE3FvVFC7FE3CE6233997C7FE39F9E6509? SE3FF1FF119CFFFE3FC7Fv4:$-KE38F$,KFE3FvVFC7FE3CCE533987C7FE39F9E6509? SE3FF1FF2999FFFE3FC7Fv4:$-KE38F$,KFE3FvVFC7FE3C1E533997C7FE39F9E6609? SE3FF1FF2983FFFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3CFE73399FC7FE3,"CCVE63C7E63FF1FF3999FFFE3FC7Fv4:$-KE38F$,KFE3Fv SBC7FE3CFE73339FC7FE3."E1VC33C7E63FF1FF399CFFFE3FC7Fv1x$-KE38F$,KFE3FvS9C7FE383C200707C7FE3ySE3FF1FE100C7FFE3FC7Fv18$-KE38F$, KFE3FvL8C7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv28$-KE38F$,KFE3FvL847FE3xLFC7FE0tL03FF1FxLE3FC7Fv2($-KE38F$,4@sK7FE3xLFC7FE0tL03FF1FxKE3FCs $-KE38F$,4@sK7FE3xLFC7FE0tL03FF1FxKE3FCs$-KE38F$,4@sK7FE3xKFC7F$(2?xKE3FCs$-KE38F$,KFE3FvL847FE3xKFC7F$(2?xLE3FC7Fv2($-KE38F$, KFE3FvL8C7FE3xKFC7F$(2?xLE3FC7Fv28$-KE38F$,KFE3FvL9C7FE3xKFC7F$(Q1F0318007FE3FC7Fv18$-KE38F$,KFE3FvLBC7FE3xKFC7F$( Q1FCF9C927FE3FC7Fv1x$-KE38F$,KFE3FvRFC7FE3818C003FFC7F$(Q1FCF8C927FE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3E7CE493FFC7FE0t S03FF1FCF8CF3FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3E7C6493FFC7FE0tS03FF1FCF94F3FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3E7C679FFFC7FE0t S03FF1FCF94F3FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3E7CA79FFFC7FE3ySE3FF1FCF98F3FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3E7CA79FFFC7FE3y SE3FF1FCF98F3F9E3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3E7CC79FFFC7FE3ySE3FF1F030CE1F9E3FC7Fv4:$-KE38F$,KFE3FvOFC7FE3E7CC79,"FCK7FE3y LE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvOFC7FE3818670("K7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$, KFE3FvLFC7FE3xTFC7FE3C1C0E0701FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3F1E67339CFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE3E4E73399CFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3E4E73399CFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE3E4E733999FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3CE6733983FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE3C06733999FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3CE667339CF63FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE38400E070C763FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv 4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3 yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3F170E30087E3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3E4667399CFE3FF1FxLE3FC7F v4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3CE4F3199CFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3."CFO3199CFE3FF1FxLE3FC7Fv4:$-KE38F$, KFE3FvLFC7FE3xLFC7FE3*"O329C9FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3*"O329C9FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x LFC7FE3*"O331C9FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3E666731E3F23FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tK7FE3,"F0 NE19E3F23FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tK7FE3yKE3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tK7FE3yKE3FFtL03FC7Fv4:$-KE38F$,KFE3Fv KFC7F$'4%y4%yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y 4%yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#y ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#yME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4: $-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3Fv KFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$* ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$- KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3Fv KFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$* ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$- KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3Fv KFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$*ME3FFFC7Fv4:$-KE38F$,KFE3Fv4> 73 v4:$) O8E007FFFE38F$,KFE3Fv4> 73 v4:$)OCE673FFFE38FzQFC063803807FFE3Fv4> 73 v4:$)OC4673FFFE38FzQFE733999CE7FFE3F$,4:$*4%y4:$) OC4673FFFE38FzQFE73119CCE7FFE3F$,4:$*4%y4:$)OCA667FFFE38FzQFE73119CCBFFFE3F$,4:$*4%y4:$)KCA60vKE38FzQFE67299CC3FFFE3F$,4:$*4%y4:$) OCE667FFFE38FzQFE0F299CCBFFFE3F$,4:$*4%y4:$)OCE673FFFE38FzQFE7F399CCFFFFE3F$,4:$*4%y4:$)O84031FFFE38FzQFE7F3999CFFFFE3F$,4:q3 $'4% y4:$-KE38FzQFC1E100383FFFE3F$,4:q3 $'4%y4:$-KE38F$,KFE3F$,4:q3 $'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$- KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$. KFC7F$'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$.KFC7F$'4%y4:$-KE38F$,KFE3F$.KE00F$'4"q2'v4:$-KE38F$,KFE3F$.K0001$'4"q2'v4: $-KE38F$,KFE3F$-4>q3 z4"q2'v4:$-KE38F$,KFE3F$-MF80FE03F$)3hv4: -K0380 -1?$-MF07FFC1F$)3hv4: -K0380 -1?$-MF0FFFE1F$)3hv4: -K0380 - 1?$-MF07FFC1F$)3h$MMF00FE01F$)3h$M42q2?$(KFE00$MMF300019F$(LF0001F$LMF3E00F9F$(LC00007$L45v3@$(L80FE03$L45v3@$(L07FFC1$L45v3@$( L0FFFE1$L45vN9E0E070380xL07FFC1$L45vO9F8F3399CE7FwL00FE01$L45vO9F27399CCE7Fwq2!$L45vO9F27399CCE7FwL300019$L45vN9F27399CCCxL3E00F9 $L45vN9E73399CC1xL3FFFF9$L45vN9E03399CCCxL3FFFF9$L45vO9E733399CE79wR3FFFF9E10C2FFE0607$F45vO9C2007038639wR3FFFF9F3998FFF9F33$F45v 3@$(R3FFFF9F399CFFF9F39$F45v3@$(N3FFFF9F399vK9F39$F45v3@$(R3FFFF9F39C1FFF9F39$F45v3@$(R3FFFF9F39FCFFF9F39$FMF3E00F9F$( R3FFFF9F399CFFF9F39$FMF300019F$(R3FFFF9F398CFFF9F33$F42q2?$(R3FFFF9F83A1FFE0607$FPF00FE01FFE0701yL3FFFF9$LPF07FFC1FFF339CyL3FFFF9v KF803$HPF0FFFE1FFF399CyL3FFFF9$LPF07FFC1FFF399CyL3FFFF9$LPF80FE03FFF3981yL3FFFF9$L4>qM7FFF399CyL3E00F9$MK0001vK399CyL300019$MKE00F vK339CyqN01FFF0380F$LLFE0701yP00FE01FFF99CE7$TP07FFC1FFF9CCE7$TP0FFFE1FFF9CCE7$TP07FFC1FFF9CC0F$TP80FE03FFF9CCE7$TPC00007FFF9CCE7 $TPF0001FFFF99CE7$TKFE00vLF0380F'~'~'~$W end e showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 21793 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (12\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 3900 -1200 M /Courier-ISOLatin1 $ /Courier & P /Courier-ISOLatin1 F 1200 o f 213.3 0 32 (\255 the ) W /Courier-Oblique-ISOLatin1 $ /Courier-Oblique & P /Courier-Oblique-ISOLatin1 F 1200 o f 213.3 0 32 (Slave Program) W /Courier-ISOLatin1 F 1200 o f 213.3 0 32 (, devoted to the inbound flow \(X.400) W 5700 -2700 M (to RFC822\).) h 3900 -4950 M 3900 -7250 M 3900 -9550 M 3900 -11850 M 3900 -14150 M 3900 -16450 M 3900 -18750 M 3900 -21050 M 3900 -23350 M 300 -25650 M 6060 -25650 M 11820 -25650 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f ( Fig.9: SLAVE Program) h 300 -27800 M 300 -29900 M 78.2 0 32 (Both these programs are structured in the same way: the PMDF Interface module \(see Fig.8) W 300 -31400 M 294.6 0 32 (and 9\) is used to get/pass a message from/to the PMDF; the Services and Information) W 300 -32900 M 384.2 0 32 (conversion module operates the translation of the messages according to the RFC987) W 300 -34400 M 112.7 0 32 (specifications; the Address Conversion module translates the E\255mail addresses according to) W 300 -35900 M 345.9 0 32 (the RARE Minimum Profile specification; while the Message Router Interface module) W 300 -37400 M (submits/gets messages to/from the DEC Message Router. ) h 300 -39500 M 175.2 0 32 (As you can see in Fig.8, the Master program makes use of an additional database \(Us_Id) W 300 -41000 M 162.5 0 32 (database\); this database contains the DEC Mailbus routing information [8,9,10,11,12] and,) W 300 -42500 M 133.1 0 32 (due to the lack of a documented Program Interface, it duplicates some information already) W 300 -44000 M (present within the Mailbus Distributed Directory Service.) h 2100 -46100 M 300 -47600 M /Helvetica-ISOLatin1 F 1200 o f (6) h /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f (. THE VISNU' ADDRESS CONVERSION DATABASES) h 300 -49700 M /Times-Roman-ISOLatin1 F 1200 o f 3.3 0 32 (Due to the problems outlined above about the use of the Directory System and to the lack of a) W 300 -51200 M 99.2 0 32 (true distributed solution based on the Directory System for the management of the RFC987) W 300 -52700 M (mapping rules, we decided to set up a local, non distributed, solution.) h 300 -54800 M 170.9 0 32 (A first possibility was to use directly the Conversion Tables as they are distributed \(apart) W 300 -56300 M 106.6 0 32 (from the deletion of the duplicated rules\). This solution is very inefficient both because the) W 300 -57800 M 64.6 0 32 (gateway has to parse every rule in the tables every time it needs to access them and because) W 300 -59300 M (the gateway has to scan the tables sequentially to locate the required rule.) h 300 -61400 M 190.3 0 32 (We then examined the possibility of using ISAM files to contain the tables, but also this) W 300 -62900 M (solution was very involved.) h -7560 6480 T R a 40 dict begin 13518 -29350 T 32405 16874 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 471 265 1 [471 0 0 -265 0 265] {I} image '~&&4: -K0380 -1?$=4: -K0380 -1?$=4: -K0380 -1?$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F $,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$, KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$, KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3F$=4:$-KE38F$,KFE3Fv4> 73 v4:$-KE38F$,KFE3Fv4> 73 v4:$-KE38F$,KFE3Fv4> 73 v4:$-KE38F$, KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3Fv KFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5 KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$- KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$, KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3Fv KFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5 KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$-KE38F$,KFE3FvKFC7F$5KFC7Fv4:$- KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F $'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE3850080C21FE3$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE3319CCE673FE3$'KFC7Fv4:$-KE38F$,KFE3Fv KFC7F$'PE3399CCE673FE3$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE33F97CE673FE3$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'PE38387CCF27FE3$'KFC7Fv4:$- KE38F$,KFE3FvLFC7FE0tR7FE3F997C1F27FE3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tR7FE3399CCCF27FE3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0t R7FE3199CCE78F9E3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE343008638F9E3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1Fx LE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3 xTFC7FE3C7C0C6001FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE39FF3E7339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE39FF3E3339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE39FF3E332FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE3CFF3E530FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE385F3E532FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE333F3E633FFE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE333F3E633FE63FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE389C0C320FE63FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv 4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3E2E1C6010FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3 xTFC7FE3C8CCE7339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE39C9E63339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE39F9E63339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xOFC7FE39F9E6509? LE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvKFC7F,"E3R801FFFFC7FE39F9E6509? SE3FF1C0638038063FC7Fv4:$-KE38F$,KFE3FvVFC7FE3F399CFFFFC7FE39F9E6609? SE3FF1E733999CE63FC7Fv4:$-KE38F$,KFE3FvSFC7FE3F119CFFFFC7FE3."CCVE63C7E63FF1E73119CCE63FC7Fv4:$-KE38F$,KFE3Fv SFC7FE3F119CFFFFC7FE3,"E1VC33C7E63FF1E73119CCBE3FC7Fv4:$-KE38F$,KFE3FvSBC7FE3F2999FFFFC7FE3ySE3FF1E67299CC3E3FC7Fv1x$-KE38F$, KFE3FvS9C7FE3F2983FFFFC7FE3ySE3FF1E0F299CCBE3FC7Fv18$-KE38F$,KFE3FvS8C7FE3F3999FFFFC7FE3ySE3FF1E7F399CCFE3FC7Fv28$-KE38F$,KFE3Fv S847FE3F399CFFFFC7FE0tS03FF1E7F3999CFE3FC7Fv2($-KE38F$,4@sR7FE3E100C7FFFC7FE0tR03FF1C1E100383E3FCs$-KE38F$,4@sK7FE3xLFC7FE0t L03FF1FxKE3FCs$-KE38F$,4@sK7FE3xKFC7F$(2?xKE3FCs$-KE38F$,KFE3FvL847FE3xKFC7F$(2?xLE3FC7Fv2($-KE38F$,KFE3FvL8C7FE3xKFC7F$(2?x LE3FC7Fv28$-KE38F$,KFE3FvL9C7FE3xKFC7F$(2?xLE3FC7Fv18$-KE38F$,KFE3FvLBC7FE3xKFC7F$(2?xLE3FC7Fv1x$-KE38F$,KFE3FvLFC7FE3xKFC7F$(2?x LE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3C0C6001FFC7FE0tS03FF1E063000FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3F3E7249FFC7FE0tS03FF1F9F3924FFE3FC7Fv 4:$-KE38F$,KFE3FvSFC7FE3F3E3249FFC7FE1ySC3FF1F9F1924FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3F3E33CFFFC7FE3ySE3FF1F9F19E7FFE3FC7Fv4:$- KE38F$,KFE3FvSFC7FE3F3E53CFFFC7FE3ySE3FF1F9F29E7FFE3FC7Fv4:$-KE38F$,KFE3FvSFC7FE3F3E53CFFFC7FE3ySE3FF1F9F29E7FFE3FC7Fv4:$-KE38F$, KFE3FvbFC7FE3F3E63CFFFC7FE3C1C0E0701FE3FF1F9F31E7FFE3FC7Fv4:$-KE38F$,KFE3FvbFC7FE3F3E63CFE7C7FE3F1E67339CFE3FF1F9F31E7F3E3FC7Fv4: $-KE38F$,KFE3FvbFC7FE3C0C3387E7C7FE3E4E73399CFE3FF1E0619C3F3E3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3E4E73399CFE3FF1FxLE3FC7Fv4:$- KE38F$,KFE3FvLFC7FE3xTFC7FE3E4E733999FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3CE6733983FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3Fv LFC7FE3xTFC7FE3C06733999FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3CE667339CF63FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE38400E070C763FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv 4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3 yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3yLE3FF1FxLE3FC7Fv4:$-KE38F$, KFE3FvLFC7FE3xTFC7FE3E2E1C6010FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE3C8CCE7339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3x TFC7FE39C9E63339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xTFC7FE39F9E63339FE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xOFC7FE39F9E6509? LE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xOFC7FE39F9E6509? LE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xOFC7FE39F9E6609? LE3FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3*"OE63C7E63FF1FxLE3FC7Fv4:$-KE38F$,KFE3FvLFC7FE3xLFC7FE3("OC33C7E63FF1FxLE3FC7Fv4: $-KE38F$,KFE3FvLFC7FE0tK7FE3yKE3FFtL13FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tK7FE3yKE3FFtL03FC7Fv4:$-KE38F$,KFE3FvLFC7FE0tK7FE3yKE3FFt L03FC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$, KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4%y4%$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2# $'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$'4"t2#$'KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$, KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$- KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$, KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F $(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3F vKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F $,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4: $-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3FvKFC7F$(4:$,KFC7Fv4:$-KE38F$,KFE3Fv4> 73 v4:$- KE38F$'LC7003FvKFE3Fv4> 73 v4:zNF018E00E01vKE38F$'LE7339FvKFE3Fv4> 73 v4:zNF9CCE66739vKE38F$'LE2339FvKFE3F$,4:$04:zNF9CC467339v KE38F$'LE2339FvKFE3F$,4:$04:zNF9CC46732FvKE38F$'LE5333FvKFE3F$,4:$04:zNF99CA6730FvKE38F$'LE5307FvKFE3F$,4:$04:zNF83CA6732FvKE38F$' LE7333FvKFE3F$,4:$04:zNF9FCE6733FvKE38F$'LE7339FvKFE3F$,4:$04:zNF9FCE6673FvKE38F$'LC2018FvKFE3F$,4:q3 $-4:zNF078400E0FvKE38F$, KFE3F$,4:q3 $-4:$-KE38F$,KFE3F$,4:q3 $-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F $.KFC7F$-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F$.KFC7F$-4:$-KE38F$,KFE3F$. KFC7F$-4:$-KE38F$,KFE3F$.KE00F$-4:$-KE38F$,KFE3F$.K0001$-4:$-KE38F$,KFE3F$-4>q3 $,4:$-KE38F$,KFE3F$-MF80FE03F$,4: -K0380 -1?$- MF07FFC1F$,4: -K0380 -1?$-MF0FFFE1F$,4: -K0380 -1?$-MF07FFC1F$WMF00FE01F$W42q2?$WMF300019F$WMF3E00F9F$W45v3@$W45v3@$W45v3@$W45v3@ $W45vO9FFE0E070380$R45vP9FFF8F3399CE7F$Q45vP9FFF27399CCE7F$Q45vP9FFF27399CCE7F$Q45vO9FFF27399CCC$R45vO9FFE73399CC1$R45v O9FFE03399CCC$R45vP9FFE733399CE79$Q45vP9FFC2007038639$Q45v3@$W45v3@$W45v3@$WMF3E00F9F$WMF300019F$W42q2?vK0380$SMF00FE01FvL99CE7F$R MF07FFC1FvL9CCE7F$RMF0FFFE1FvL9CCE7F$RMF07FFC1FvK9CC0$SMF80FE03FvL9CCE7F$R4>q3 vL9CCE7F$SK0001wL99CE7F$SKE00FwK0380'~'~'~$b end e S 13518 -29350 32405 16874 @ S 100 w 0 c 0 j 2 i 0.00 G - + * k R R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 21793 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (13\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 2100 -1350 M 2100 -3650 M 2100 -5950 M 2100 -8250 M 2100 -10550 M 2100 -12850 M 2100 -15150 M 2100 -17450 M 2100 -19750 M 2100 -22050 M 2100 -24350 M 2100 -26650 M 2100 -28950 M 2100 -31250 M 2100 -33550 M 2100 -35850 M 2100 -38150 M 2100 -40450 M 300 -42600 M 300 -44700 M 6060 -44700 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f ( Fig. 10: The Visnu' Addresses Conversion ordered binary trees) h 300 -46800 M 120.6 0 32 (The actual solution adopted was to set up a binary ordered tree for each of the Conversion) W 300 -48300 M (Tables. The binary trees are organized in the following way \(see Fig.10\):) h 3900 -50400 M 78.1 0 32 (\255 each node identifies a domain \(e.g. ) W /Times-Italic-ISOLatin1 $ /Times-Italic & P /Times-Italic-ISOLatin1 F 1200 o f 78.1 0 32 (EDU, CMU.EDU) W /Times-Roman-ISOLatin1 F 1200 o f 78.1 0 32 (, etc. in the RFC822 to X.400) W 4980 -51900 M 388.5 0 32 (binary tree; ) W /Times-Italic-ISOLatin1 F 1200 o f 388.5 0 32 (C=IT, C=IT;ADMD= ;, C=FR, C=FR; ADMD=ATLAS;, C=FR;) W 4980 -53400 M (ADMD=ATLAS; PRMD=INRIA;,) h /Times-Roman-ISOLatin1 F 1200 o f ( etc. on the X.400 to RFC822 binary tree\);) h 3900 -55500 M (\255 a node can contain a mapping rule, if one is defined for that domain;) h 3900 -57600 M (\255 the left subtree of a node is the set of subdomains, if they exist, of that domain;) h 3900 -59700 M (\255 the right subtree of a node are the subsequent \(in alphabetical order\) domains.) h 300 -61800 M 183.1 0 32 (When the gateway has to translate an address it goes through the appropriate binary tree,) W 300 -63300 M 62.3 0 32 (looking for the sequence of domains it has to translate, until it finds a mapping rule \(if there) W -7560 6480 T R a 40 dict begin 12272 -50017 T 39595 42759 s /bd{bind def}def /sd{string def}bd /U{0 exch getinterval def}bd /cf currentfile def /imstr 130 sd /h1 1 sd /a1 190 sd /a2 190 sd /z 380 sd /o 380 sd /z2 z 2 U /z3 z 3 U /z4 z 4 U /z5 z 5 U /z6 z 6 U /o2 o 2 U /o3 o 3 U /o4 o 4 U /o5 o 5 U /o6 o 6 U /I {codes cf read pop get exec} bd /codes [{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I}{I} {z 0 -32 S}{z 0 63 S}{z 0 158 S}{z 0 253 S}{o 0 -32 S}{o 0 63 S}{o 0 158 S}{o 0 253 S} {a1 0 -32 S}{a1 0 63 S}{a2 0 -32 S}{a2 0 63 S}{a1 -32 F}{a1 63 F}{a2 -32 F}{a2 63 F} {Nn}{N1}{h1 0 -32 C}{h1 0 95 C}{h1 0 190 C} {-32 A}{-24 A}{-16 A}{-8 A}{0}{8 A}{16 A}{24 A}{32 A}{40 A}{48 A}{56 A} {64 A}{72 A}{80 A}{88 A}{96 A}{104 A}{112 A}{120 A}{128 A}{136 A} {2 H}{3 H}{4 H}{5 H}{6 H}{7 H}{8 H}{9 H}{10 H}{11 H}{12 H}{13 H}{14 H}{15 H}{16 H}{17 H}{18 H}{19 H} {20 H}{21 H}{22 H}{23 H}{24 H}{25 H}{26 H}{27 H}{28 H}{29 H} {30 H}{31 H}{32 H}{33 H}{34 H}{35 H}{36 H}{37 H}{38 H}{39 H} z2 z3 z4 z5 z6 o2 o3 o4 o5 o6] def /H {cf imstr 0 4 -1 roll getinterval readhexstring pop} bd /A {/val exch def cf imstr readline pop dup 0 exch {val add 3 copy put pop 1 add} forall pop} bd /Nn {cf imstr readline pop} bd /N1 {cf h1 readstring pop} bd /C {cf read pop add put h1} bd /S {cf read pop add getinterval} bd /F {cf read pop add cf h1 readhexstring pop 0 get exch dofill} bd /dofill {/len exch def 2 copy 0 1 len 1 sub {exch put 2 copy} for pop pop pop 0 len getinterval} bd o 255 380 dofill pop 591 591 1 [591 0 0 -591 0 591] {I} image $t4> -2'$[4> -2'$( -2!$E4> -2'$( -2!$EKFC7F$,3h$( -2!$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$(2?$,43 $ELFC7E03w45vO00C070C7FFC7$(2?$,43$ELFC7F39w45vO9EE739EFFFC7$(2?$,43$ELFC7F3CzO9EE799EFFFC7$(L1FFE03w45vN00C07FFFF1$E XFC7F3CC313386227FF9BE799EFFFC7$(L1FFF39w45vN9CE63FFFF1$EXFC7F3C9988933313FF83E799EFFFC7$(L1FFF3CzN9EE73FFFF1$ELFC7F3C,"993@ ."33P039BE799EFFFC7$(W1FFF3CC313386227FF9BE73FFFF1$ELFC7F3C("39*"PFF9EE799EFFFC7$(W1FFF3C9988933313FF83E67FFFF1$ELFC7F3C("34*" P039EE799EFFFC7$(L1FFF3C("3@*"L039BE0v43$ELFC7F39("34*"PFF9CE738CFFFC7$(L1FFF3C("39*"OFF9FE47FFFF1$E XFC7E03C308888031FF00C07C1FFFC7$(L1FFF3C("34*"O039FE63FFFF1$EKFC7F$,3h$(L1FFF39("34*"OFF9FE71FFFF1$EKFC7F$,3h$( W1FFE03C308888031FF0FC38FFFF1$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$(2?$,43$ENFC7E1E180F$)3h$(2?$,43$ENFC7F1E3CC7$)3h$( 2?$,43$ENFC7F1E3CE7$)3h$(2?$,43$EOFC7F4D3CE79F$(3h$(2?$,43$EOFC7F4D3CCF9F$(3h$(2?$,43$ENFC7F4B3C1F$)3h$(2?$,43$ENFC7F633C8F$)3h$( 2?$,43$ENFC7F633CC7$)3h$(2?$,43$EOFC7F773CE39F$(3h$(N1FFF878603$(43$EOFC7E3618719F$(3h$(N1FFFC78F31$(43$EKFC7F$,3h$(N1FFFC78F39$( 43$EKFC7F$,3h$(O1FFFD34F39E7$'43$EKFC7F$,3h$(O1FFFD34F33E7$'43$EKFC7F$,3h$(N1FFFD2CF07$(43$EKFC7F$,3h$(N1FFFD8CF23$(43$EKFC7F$,3h $(N1FFFD8CF31$(43$EKFC7F$,3h$(O1FFFDDCF38E7$'43$EKFC7F$,3h$(O1FFF8D861C67$'43$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$'K7F1F$,43$EKFC7F$,3h $'K3F1F$,43$EPFC7FFF0BFF0C03$'3h$',"1F$,43$EPFC7FFE73FF9C93$'3h$'K0F1F$,43$EPFC7FFCFBFF9D9B$'3h$'K071F$,43$ENFC7FFCFBFF.#9Fz3e 'K031F$,43$ELFC7FFCv*#z3e 'K031F$,43$ENFC7FFCFF03*"$'3e 'K031F$,43$BOC7E3F1FC7FFCv*"$'3h$'K071F$,43$BQC7E3F1FC7FFCFB03*"$'3h$' K0F1F$,43$BQC7E3F1FC7FFE73FF*#z3h$'("$,43$ENFC7FFF07FF,"0F3@z3h$'K3F1F$,43$EKFC7Fy4!z3h$'K7F1F$,43$EKFC7Fy3`z3h$(2?$,43$EKFC7F$, 3h$(O1F85FF80603F$'43$EKFC7F$,3h$(O1F39FFCE731F$'43$EKFC7F$,3h$(O1E7DFFCF739F$'43$EKFC7F$,3h$(P1E7DFFCDF39E7Fz43$EKFC7F$,3h$( P1E7FFFC1F33E7Fz43$EKFC7F$,3h$(O1E7F81CDF07F$'43$ENFC7FFF9F01."C32!z3h$(O1E7FFFCFF23F$'43$EQFC7FFF9F9CE3C79Cz3h$(O1E7D81CFF31F$' 43$ERFC7FFF0F9E63C79E7Fy3h$(P1F39FFCFF38E7Fz43$ETFC7FFF4F9E69A79E7FFF3Fw3h$(P1F83FF87E1C67Fz43$ETFC7FFE679E69A79E7FFF3Fw3h$(2?y3 z 43$ESFC7FFEE79E69679E607Fx3h$(2?x4@$'43$ERFC7FFE079E6C679E7Fy3h$(2?$,43$ESFC7FFCF39E6C679E607Fx3h$(2?$,43$EQFC7FFDF39CEEE79Cv1?w3h $(2?$,43$EQFC7FF8E101C6C301v1?w3h$(2?$,43$EKFC7F$(3`w3h$(2?$,43$EKFC7F$(3 w3h$(2?$,43$EKFC7F$,3h$(L1FCF80,"E1R80FFFE7C021FF3F0B1 $EKFC7F$,3h$(W1FCFCE71E3CE7FFE7C933FF3E731$EKFC7F$,3h$(W1F87CF31E3CF3FFC3D9B3FE1E7B1$EKFC7F$,3h$(W1FA7CF34D3CF3FFD3F9F3FE9E3F1$E KFC7F$,3h$(Q1F33CF34D3CF3FF9."9FM3FCCF0F1$EKFC7F$,3h$(Q1F73CF34B3CF303B*"M3FDCFC71$EXFC7FF80E03878603FFC0301C31FFC7$(L1F03CF063 RCF3FF81F9F3DC0FE31$EXFC7FFCC731C78F39FFE7B9CE7BFFC7$(L1E79CF063 3p003 OCF9F3D9E6F31$EXFC7FFCE739C78F3CFFE7B9E67BFFC7$(L1EF9CE0ws RCE7FF7CF9F39BE6731$EXFC7FFCE739D34F3CFFE6F9E67BFFC7$(W1C7080E36180FFE3870E011C2071$EXFC7FFCE733D34F3CFFE0F9E67BFFC7$(2?$,43$E XFC7FFC0F07D2CF3CC0E6F9E67BFFC7$(2?$,43$EXFC7FFCFF23D8CF3CFFE7B9E67BFFC7$(2?$,43$EXFC7FFCFF31D8CF3CC0E7B9E67BFFC7$(2?$,43$E XFC7FFCFF38DDCF39FFE739CE33FFC7$(2?$,43$EXFC7FF87E1C0D8603FFC0301F07FFC7$(2?$,43$EKFC7F$,3h$(2?$,43$EKFC7F$,3h$(2?$,43$EKFC7F$,3h $(2?$,43$EKFC7F$,3h$(2?$,43$E4> -2'$(2?$,43$E4> -2'$( -2!$E4> -2'$( -2!$KKFC07$/ -2!$KKF01F$53h$RKC07F$53h$R2!$63h$QKFC07$63h$Q KF01F$63h$QKC07F$63h$Q2!$73h$PKFC07$73h$PKF01F$73h$PKC07F$73h$P2!$83h$OKFC07$83h$OKF01F$83h$OKC07F$83h$O2!$93h$NKFC07$93h$NKF01F$9 3h$NKC07F$93h$N2!$:3h$MKFC07$:3h$MKF01F$:3h$MKC07F$:3h$M2!$;3h$LKFC07$;3h$LKF01F$;3h$LKC07F$;3h$L2!$<3h$KKFC07$<3h$KKF01F$<3h$K KC07F$<3h$K2!$=3h$JKFC07$=3h$JKF01F$=3h$JKC07F$=3h$J2!$>3h$IKFC07$>3h$HL7FF01F$>3h$HL3FC07F$>3h$HK1F01$?3h$HK0C07$>LF8003F$GK001F $>LFC007F$GK007F$>KFE00$H2!$@2!$H2 $@3$$HK007F$?3h$HK003F$?41$HK001F$hK000F%M3! -w3! -KFFFC -2'$;3! -w3! -KFFFC -2'$;3! -w3! - KFFFC -2'$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;L8FE83Fw Q3FFFFC2878431FF8w30$,MF8FFFC7F$,3h$;L8FF39FwQ3FFFF9CC78E7BFF8wL8FF80FwTCFFFF87861807FF8FFFC7F$,3h$;L8FF3CFyOF3EC78E7BFF8wL8FFCE7w UCFFFFC78F3927FF8FFFC7F80w4>vOF0B00F9FFFC7$;L8FF3CC013 R86227FF3ED34E7BFF8wL8FFCF3yTFC78F3B37FF8FFFC7FCE7Fv4>vOE739EF9FFFC7$;N8FF3C99889031 P3FF3FD34E7BFF8wS8FFCF30C4CE1889FFD34,"F3Jwpwt L7FCF3FyOCFB9EF0FFFC7$;L8FF3C9."99450303 NFD2CE7BFF8wS8FFCF266224CCC4FFD34("Jwpwt W7FCF30C4CE1889FFCFB9BF4FFFC7$;L8FF3C9*"R83333FF3FD8CE7BFF8wL8FFCF2,"661|."CCK0D2C,"F3Jwpwt W7FCF266224CCC4FFCFF83E67FFC7$;L8FF3C9."99,"33003 NED8CE7BFF8wL8FFCF2."66N60CCCFFD8C,"F3Jwpwt L7FCF260fg ."CCPC0CFF9BEE7FFC7$;K8FF3,#99."33P3FF9CDDCE33FF8wL8FFCF2,"661L."CCK0D8C,"F3Jwpwt L7FCF26."66R0CCCFFCFF9EE07FFC7$;M8FE03C30,"88Q031FFC18D8707FF8wL8FFCE6*"N4CCCCFFDDC."F3Jwpwt L7FCF260fd ,"CCPC0CFB9ECF3FFC7$;30$,4:wM8FF80F0C."22O00C7F8D861E1Jwpwt K7FCE,"661d."CCPFFE739CDF3FFC7$;30$,4:w30$,PF8FFFC7F80F0C20" Q0C7FF07008E1FFC7$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w 30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$; N8FFC3C301F$(4:wN8FFC3C301F$(MF8FFFC7F$,3h$;N8FFE3C798F$(4:wN8FFE3C798F$(MF8FFFC7F,"E13!$)3h$;N8FFE3C79CF$(4:wN8FFE3C79CF$( QF8FFFC7FF1E3CC7F$(3h$;O8FFE9A79CF3F$'4:wO8FFE9A79CF3F$'QF8FFFC7FF1E3CE7F$(3h$;O8FFE9A799F3F$'4:wO8FFE9A799F3F$'QF8FFFC7FF4D3CE79 $(3h$;N8FFE96783F$(4:wN8FFE96783F$(QF8FFFC7FF4D3CCF9$(3h$;N8FFEC6791F$(4:wN8FFEC6791F$(PF8FFFC7FF4B3C1$)3h$;N8FFEC6798F$(4:v ODF8FFEC6798F$(PF8FFFC7FF633C8$)3h$;O8FFEEE79C73F$'4:vPCF8FFEEE79C73F$'QF8FFFC7FF633CC7F$(3h$;O8FFC6C30E33F$'4:vPC78FFC6C30E33F$' QF8FFFC7FF773CE39$(3h$;30$,4:vKC38F$,QF8FFFC7FE3618719$(3h$;30$,4:vKC18F$,MF8FFFC7F$,3h$;30$,4:r30$,MF8FFFC7F$,3h$;30$,4:r30$, MF8FFFC7F$,3h$;30$,4:r30$,MF8FFFC7F$,3h$;30$,4:vKC18F$,MF8FFFC7F$,3h$;30$,4:vQC38FFFF0BFF0C03FzSF8FFFC7FFF0BFF00C07Fz3h$;30$,4:v QC78FFFE73FF9C93FzSF8FFFC7FFE73FF9CE63Fz3h$;T8F0BFF0C03FF3E03878603v4:vQCF8FFFCFBFF9D9BFzSF8FFFC7FFCFBFF9EE73Fz3h$;O8E73FF9C93FF 0?9 LC78F39v4:vNDF8FFFCFBF.#F9zSF8FFFC7FFCFBFF9BE73Cz3h$;T8CFBFF9D9BFE1F3CC78F3Cv4:wM8FFFCFFF*#zNF8FFFC7FFCvL83E67Cz3h$;L8CFBFF ,"9FR9E9F3CD34F3CFFFE78wO8FFFCFF039F9$'RF8FFFC7FFCFF039BE0$'3h$;3-v("R9CCF3CD34F3CFFFE78wM8FFFCFFF*"$'NF8FFFC7FFCvL9FE47Fz3h$; L8CFF03("RFDCF3CD2CF3CC0FFF8wO8FFFCFB039F9$'SF8FFFC7FFCFB039FE63Fz3h$;3-v("OFC0F3CD8CF3Cv4:wM8FFFE73F*#zSF8FFFC7FFE73FF9FE71Cz3h$; L8CFB03("RF9E73CD8CF3CC0FFF8wM8FFFF07F."F04;zSF8FFFC7FFF07FF0FC38Cz3h$;L8E73FF("R9BE739DDCF39FFFE78w30y4?zMF8FFFC7Fy4@z3h$; L8F07FF,"0FR91C2038D8603FFFE78w30y4=zMF8FFFC7Fy4?z3h$;30x4!$'1xw30$,MF8FFFC7F$,3h$;30x3`zKFEF8w30$,MF8FFFC7F$,3h$;30$,4:w30$, MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:wQ8FFFF9F01C3C301Fy PF8FFFC7FFF9F01."C32!z3h$;L8E0380,"E1R80FFF00C070C7FFFF8wK8FFF."F9MCE3C79CFySF8FFFC7FFF9F9CE3C79Cz3h$; T8F31CC71E3CE7FF9EE739Ev4:wQ8FFFF0F9E63C79E7yTF8FFFC7FFF0F9E63C79E7Fy3h$;T8F39CE71E3CF3FF9EE799Ev4:wS8FFFF4F9E69A79E7FFF3w VF8FFFC7FFF4F9E69A79E7FFF3Fw3h$;W8F39CE74D3CF3FF9BE799EE7FFF8wS8FFFE679E69A79E7FFF3wVF8FFFC7FFE679E69A79E7FFF3Fw3h$; W8F39CCF4D3CF3FF83E799EE7FFF8wR8FFFEE79E69679E607xUF8FFFC7FFEE79E69679E607Fx3h$;T8F03C1F4B3CF3039BE799Ev4:wQ8FFFE079E6C679E7y TF8FFFC7FFE079E6C679E7Fy3h$;T8F3FC8F633CF3FF9EE799Ev4:wR8FFFCF39E6C679E607xUF8FFFC7FFCF39E6C679E607Fx3h$;T8F3FCC7633CF3039EE799Ev 4:wS8FFFDF39CEEE79CFFFF3wSF8FFFC7FFDF39CEEE79Cv1?w3h$;W8F3FCE3773CE7FF9CE738CE7FFF8wS8FFF8E101C6C301FFFF3wSF8FFFC7FF8E101C6C301v1? w3h$;W8E1F87036180FFF00C07C1E7FFF8w30$(4=wMF8FFFC7F$(3`w3h$;30$*LF7FFF8w30$(49wMF8FFFC7F$(3 w3h$;30$*LEFFFF8w30$,MF8FFFC7F$,3h$;30 $,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30 $,4:wa8FFF80E03878603FF87861807FF8FFFC7FFF07FFE1601F3Fy3h$;Q8FC1FFF850F0863Fy4:wa8FFFCC731C78F39FFC78F3927FF8FFFC7FFE73FFCE73DF3Fy 3h$;Q8F9CFFF398F1CF7Fy4:wa8FFFCE739C78F3CFFC78F3B37FF8FFFC7FFCF9FF9F73DE1Fy3h$;Q8F3E7FE7D8F1CF7Fy4:wS8FFFCE739D34F3CFFD34,"F3 Jwpwt Q7FFCF9FF9F737E9Fy3h$;Q8F3E7FE7DA69CF7Fy4:wS8FFFCE733D34F3CFFD34("Jwpwt Q7FFCF9FF9FF07CCFy3h$;Q8F3E7FE7FA69CF7Fy4:wS8FFFC0F07D2CF3CC0D2C("Jwpwt Q7FFCF9819FF37DCFy3h$;K8F3E0`g MFA59CF7Fy4:wS8FFFCFF23D8CF3CFFD8C("Jwpwt Q7FFCF9FF9FF3DC0Fy3h$;Q8F3E7FE7FB19CF7Fy4:wS8FFFCFF31D8CF3CC0D8C("Jwpwt Q7FFCF9819F73D9E7y3h$;K8F3E0`g MDB19CF7Fy4:wS8FFFCFF38DDCF39FFDDC("Jwpwt Q7FFE73FFCE739BE7y3h$;Q8F9CFFF39BB9C67Fy4:wU8FFF87E1C0D8603FF8D861E1Jwpwt M7FFF07FF."E0K11C3y3h$;P8FC1FFF831B0E0z4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$,MF8FFFC7F$,3h$;30$,4:w30$, MF8FFFC7F$,3h$;3! -w3! -KFFFC -2'$;3! -w3! -KFFFC -2'$;3! -w3! -KFFFC -2'$@KFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$G KFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$@2?$GKFE3F$?KE000$GKC001 $?KF001$GKE003$?KF803$GKF007$?KFC07$GKF80F$?KFE0F$GKFC1F$@2?$GKFE3F$@3`$H3 'IMFE3F1F8F$EMFC7E3F1F$=MFE3F1F8F$EMFC7E3F1F$=MFE3F1F8F $EMFC7E3F1F'~'~'~'~'~'~'~'~'~$l4" -1?$[4" -1?$'4> .3 $D4" -1?$'4> .3 $D4%$,KFE3F$'4> .3 $D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$' KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$DME3FFF80Fw3py KFE3F$'LFC7F80w4>$'KFC7F$DME3FFFCE7w3pyKFE3F$'MFC7FCE7Fv4>$'KFC7F$DME3FFFCF3$)KFE3F$'MFC7FCF3F$*KFC7F$DSE3FFFCF30C4CE1889E7FwKFE3F $'RFC7FCF30C4CE1889E7yKFC7F$DSE3FFFCF266224CCC4E7FwKFE3F$'RFC7FCF266224CCC4E7yKFC7F$DME3FFFCF2,"66L7CCCCFxKFE3F$'MFC7FCF260fg ."CCzKFC7F$DME3FFFCF2("L60CCCFxKFE3F$'MFC7FCF26("K0CCCzKFC7F$DME3FFFCF2("L4CCCCFxKFE3F$'MFC7FCF260fd *"zKFC7F$DME3FFFCE6("M4CCCCE7FwKFE3F$'LFC7FCE("1d*"4)yKFC7F$DNE3FFF80F0C,"22L00C67FwKFE3F$'NFC7F80F0C20" K0C67yKFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F $,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$DQE3FFFE17FFCF807FyKFE3F$'KFC7F$,KFC7F$D QE3FFFCE7FFCF927FyKFE3F$'KFC7F$,KFC7F$DQE3FFF9F7FF87B37FyKFE3F$'QFC7FF85FFE16187FzKFC7F$DOE3FFF9F7FFA7."F3yKFE3F$' PFC7FF39FFCE73C$'KFC7F$DLE3FFF9v13*"yKFE3F$'PFC7FE7DFF9F73C$'KFC7F$DPE3FFF9FE0773F3zKFE3F$'PFC7FE7DFF9F73C$'KFC7F$DLE3FFF9vK03F3z KFE3F$'PFC7FE7FFF9FF00$'KFC7F$DPE3FFF9F60679F3zKFE3F$'PFC7FE7F819FF3C$'KFC7F$DOE3FFFCE7FEF9*"yKFE3F$'PFC7FE7FFF9FF3C$'KFC7F$D QE3FFFE0FFC70E1F3yKFE3F$'PFC7FE7D819F73C$'KFC7F$D4%z4=yKFE3F$'PFC7FF39FFCE73C$'KFC7F$D4%z49yKFE3F$'QFC7FF83FFE0E187FzKFC7F$D4%$, KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3FzLFBFC7F$,KFC7F$D4%$,KFE3FzLF9FC7F$,KFC7F$D4%$,KFE3FzLF8FC7F$,KFC7F$D4%$, KFE3FzLF87C7F$,KFC7F$D4%vU3E03878603FF80E01807FE3FzLF83C7F$,KFC7F$D4%v0?9 SC78F39FFCC649927FE20 'K1C7F$,KFC7F$DXE3FFFE1F3CC78F3CFFCE6CDB37FE20 'Y0C7CF80E1E180FFFE7C07E178387847F$D XE3FFFE9F3CD34F3CFFCE7CFF3FFE20 'Y1C7CFCE71E3CE7FFE7E63CE739C78C7F$@\FE3F1F8FE3FFFCCF3CD34F3CFFCE7CFF3FFE3FzKF83C0x| YF31E3CF3FFC3E739F67CC78C7E3F1F8F$=UFE3F1F8FE3FFFDCF3CD2CF3C,"C0NFCFF3FFE3Fz4:0|z| YF34D3CF3FFD3E739F67CD34C7E3F1F8F$=\FE3F1F8FE3FFFC0F3CD8CF3CFFCFFCFF3FFE3Fz]F8FC733CF34D3CF3FF99E679FE7CD34C7E3F1F8F$A XE3FFF9E73CD8CF3CC0CFFCFF3FFE3FzZF9FC773CF34B3CF303B9E0F9FE7CD2CC7F$DXE3FFFBE739DDCF39FFCFFCFF3FFE3Fz ZFBFC703CF3633CF3FF81E479FE7CD8CC7F$DXE3FFF1C2038D8603FF87F87E1FFE3F$'YFC679CF3633CF3033CE639F67CD8CC7F$D4%$,KFE3F$' YFC6F9CE7773CE7FF7CE71CE739DDCC7F$D4%$,KFE3F$'YFC47080E36180FFE38438E0F838D847F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F $D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4% $,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$, KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$DKE3FF."E1N80FFFE7C03xKFE3F$'KFC7F$,KFC7F$D RE3FFF1E3CC7FFE7C93xKFE3F$'KFC7F$,KFC7F$DRE3FFF1E3CE7FFC3D9BxKFE3F$'KFC7F,"F0OC07FFE16187FxKFC7F$DRE3FFF4D3CE7FFD3F9FxKFE3F$' RFC7FF8F1E63FFCE73CyKFC7F$DPE3FFF4D3CCFFF9."9FxKFE3F$'RFC7FF8F1E73FF9F73CyKFC7F$DPE3FFF4B3C1F03B*"xKFE3F$'RFC7FFA69E73FF9F73Cy KFC7F$DRE3FFF633C8FFF81F9FxKFE3F$'RFC7FFA69E67FF9FF00yKFC7F$DRE3FFF633CC7033CF9FxKFE3F$'RFC7FFA59E0F819FF3CyKFC7F$D RE3FFF773CE3FF7CF9FxKFE3F$'RFC7FFB19E47FF9FF3CyKFC7F$DRE3FFE361871FE3870FxKFE3F$'RFC7FFB19E63819F73CyKFC7F$D4%$,KFE3F$' RFC7FFBB9E71FFCE73CyKFC7F$D4%$,KFE3F$'SFC7FF1B0C38FFE0E187FxKFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$' KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4%x4!$'KFE3F$'KFC7F$,KFC7F$D4%$,KFE3F$' KFC7F$,KFC7F$D4%$,KFE3F$'KFC7F$,KFC7F$D4" -1?$'KFC7F$,KFC7F$D4" -1?$'4> .3 $D4" -1?$'4> .3 $K2?$.4> .3 $K2?$42?$T2?$42?$T2?$42?$T 2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$42?$T2?$3KE000$SKE000$3 KF001$SKF001$3KF803$SKF803$3KFC07$SKFC07$3KFE0F$SKFE0F$42?$T2?$i3`'#42 -2?$[42 -2?$'4: .$E42 -2?$'4: .$E43$-2?$'4: .$E43$-2?$'4:$- 4:$E43$-2?$'4:$-4:$E43$-2?$'4:$-4:$E43$-2?$'LF8FF80w4>$'4:$E43$-2?$'MF8FFCE7Fv4>$'4:$EMF1FFFE03w45z2?$'MF8FFCF3F$*4:$E43v19w45z2? $'RF8FFCF30C4CE1889E7y4:$E43v1<$*2?$'RF8FFCF266224CCC4E7yLF8FFBF$C43vP3CC3133862279Fx2?$'MF8FFCF260fg ,"CCzLF8FFBF$C43vP3C99889333139Fx2?$'MF8FFCF26."66K0CCCzLF8FFBF$C43v1<,"993@."33y2?$'MF8FFCF260fd ,"CCz4:$E43v1<."9939,"33y2?$'LF8FFCE."661d,"CC4)y4:$E43v1<."9934,"33y2?$'NF8FF80F0C20" K0C67y4:$E43v19*"34("3@x2?$'4:$-4:$ESF1FFFE03C3088880319Fx2?$'4:$-4:$E43$-2?$'4:$-4:$E43$-2?$'4:$-4:$E43$-2?$'4:$-4:$E43$-2?$' PF8FFF0BFFC2C30$'4:$E43$-2?$'PF8FFE73FF9CE79$'4:$E43$-2?$'PF8FFCFBFF3EE79$'4:$E43$-2?$'PF8FFCFBFF3EE79$'4:$E43vN0BFFE7C03Fz2?$' PF8FFCFFFF3FE01$'4:$EQF1FFFE73FFE7C93Fz2?$'PF8FFCFF033FE79$'4:$E43Jwtsw LC3D9BFz2?$'PF8FFCFFFF3FE79$'4:$E43Jwtsw 3t."F9z2?$'PF8FFCFB033EE79$'4:$ELF1FFFCv3:*"z2?$'PF8FFE73FF9CE79$'4:$EPF1FFFCFF03B9F9$'2?$'PF8FFF07FFC1C30$'4:$ELF1FFFCvK81F9$' 2?$'4:$-4:$EPF1FFFCFB033CF9$'2?$'4:$-4:$EOF1FFFE73FF7C*"z2?$'4:$-4:$E43vN07FE3870F9z2?$'4:$-4:$E43z4?z2?$'4:$-4:$E43z4=z2?$' XF8F9F01C3C301FFFCF80FC2F070F18$E43$-2?$'4:*"UCE3C79CFFFCFCC79CE738F18$E43$-2?$'XF8F0F9E63C79E7FF87CE73ECF98F18$E43$-2?$' XF8F4F9E69A79E7FFA7CE73ECF9A698$E43$-2?$'XF8E679E69A79E7FF33CCF3FCF9A698$E43$-2?$'XF8EE79E69679E60773C1F3FCF9A598$E XF1FFF3E03878603FF80E01807FFF1F$'XF8E079E6C679E7FF03C8F3FCF9B198$EKF1FF,"F3T9C78F39FFCC649927FFF1F$' XF8CF39E6C679E60679CC73ECF9B198$EXF1FFE1F3CC78F3CFFCE6CDB37FFF1F$'XF8DF39CEEE79CFFEF9CE39CE73BB98$ETF1FFE9F3CD34F3CFFCE7CF("KFF1F $'XF88E101C6C301FFC70871C1F071B18$ETF1FFCCF3CD34F3CFFCE7CF("KFF1F$'4:$-4:$EUF1FFDCF3CD2CF3CC0C0FCFF3v2?$'3y$-4*$E UF1FFC0F3CD8CF3CFFCFFCFF3v2?$'4:$-4:$EUF1FF9E73CD8CF3CC0CFFCFF3v2?$'4:$-4:$ETF1FFBE739DDCF39FFCFFCF("KFF1F$'QF8FF80E03878603Fz4:$E XF1FF1C2038D8603FF87F87E1F3FF1F$'QF8FFCC731C78F39Fz4:$E43$+LFBFF1F$'QF8FFCE739C78F3CFz4:$E43$+LF7FF1F$'TF8FFCE739D34F3CFFFFE7Fw4: $E43$-2?$'TF8FFCE733D34F3CFFFFE7Fw4:$E43$-2?$'RF8FFC0F07D2CF3CC0Fy4:$E43$-2?$'QF8FFCFF23D8CF3CFz4*$E43$-2?$'RF8FFCFF31D8CF3CC0Fy NF8FC7E3F1F$A43$-2?$'TF8FFCFF38DDCF39FFFFE7FwNF8FC7E3F1F$A43$-2?$'TF8FF87E1C0D8603FFFFE7FwNF8FC7E3F1F$ATF1FF01C070F0C07FFF3E03w2? $'4:$)3 w4:$ETF1FF98E638F1E73FFF3F31w2?$'4:$-4:$ETF1FF9CE738F1E79FFE1F39w2?$'4:$)4=w4:$EUF1FF9CE73A69E79FFE9F39E7v2?$'4:$-4:$E UF1FF9CE67A69E79FFCCF33E7v2?$'QF8FFF07FFF3E0380z4:$ETF1FF81E0FA59E7981DCF07w2?$'NF8FFE73FFF0?9 KCE7Fy4:$ETF1FF9FE47B19E79FFC0F23w2?$'RF8FFCF9FFE1F39CE7Fy4:$ETF1FF9FE63B19E79819E731w2?$'RF8FFCF9FFE9F39CE7Fy4:$E UF1FF9FE71BB9E73FFBE738E7v2?$'QF8FFCF9FFCCF03C0z4:$EUF1FF0FC381B0C07FF1C21C67v2?$'RF8FFCF981DCF39CE7Fy4:$E43$*49v2?$' RF8FFCF9FFC0F39CE7Fy4:$E43$*41v2?$'RF8FFCF9819E739CE7Fy4:$E43$-2?$'RF8FFE73FFBE739CE7Fy4:$E43$-2?$'QF8FFF07FF1C20380z4:$E43$-2?$' 4:$-4:$E43$-2?$'4:$-4:$E43$-2?$'4:$-4:$E43$-2?$'4:$-4:$ERF1FF0F0C07FFF3E03Fy2?$'4:$-4:$EOF1FF8F1E63FF("2?y2?$'4:$-4:$E RF1FF8F1E73FFE1F39Fy2?$'4:$-4:$ERF1FFA69E73FFE9F39Fy2?$'4:vQ0F0C07FFF3E0380Fw4:$ERF1FFA69E67FFCCF33Fy2?$'4:vM8F1E63FF("K9CE7w4:$E RF1FFA59E0F81DCF07Fy2?$'4:vQ8F1E73FFE1F39CE7w4:$ERF1FFB19E47FFC0F23Fy2?$'4:vQA69E73FFE9F39CE7w4:$ERF1FFB19E63819E731Fy2?$'4:v QA69E67FFCCF03C0Fw4:$ERF1FFBB9E71FFBE738Fy2?$'4:vQA59E0F81DCF39CE7w4:$ERF1FF1B0C38FF1C21C7y2?$'4:vQB19E47FFC0F39CE7w4:$E43$-2?$'4: vQB19E63819E739CE7w4:$E43$-2?$'4:vQBB9E71FFBE739CE7w4:$E43$-2?$'4:vQ1B0C38FF1C20380Fw4:$E43$-2?$'4:$-4:$E43$-2?$'4:$-4:$E42 -2?$' 4:$-4:$E42 -2?$'4: .$E42 -2?$'4: .$[4: .'~'~&XMF1F8FC7F$fMF1F8FC7F$2LE3F1F8$QMF1F8FC7F$2LE3F1F8$gLE3F1F8'~'~'~'~'~&x end e S 12272 -50017 39595 42759 @ S 100 w 0 c 0 j 2 i 0.00 G - + * k R R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 21793 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (14\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f 173.4 0 32 (is no mapping defined for that sequence of domains, then the gateway applies the default) W 300 -2850 M (mapping\)) h /Courier-ISOLatin1 $ /Courier & P /Courier-ISOLatin1 F 1400 o f (. ) h 300 -5000 M /Times-Roman-ISOLatin1 F 1200 o f 166.3 0 32 (This kind of arrangement has the benefit of optimizing the search and of having a simple) W 300 -6500 M (algorithm for the best match, while at the same time it needs a simple structure.) h 300 -8600 M 114.5 0 32 (In order to speed up the mapping rule search, the binary trees have been realized via VMS) W 300 -10100 M (shareable images \(i.e. they are directly mapped into the process virtual address space\).) h 300 -12200 M 263.7 0 32 (Procedures are provided to parse the ASCII Conversion Tables and to update the VMS) W 300 -13700 M (shareable images. ) h 300 -15800 M 246.8 0 32 (These procedures handle also the duplicated rules, avoiding the boring task of manually) W 300 -17300 M (editing the RFC822 to X.400 conversion table.) h 300 -19400 M 300 -21500 M /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f (7. CONCLUSIONS) h 300 -23600 M /Times-Roman-ISOLatin1 F 1200 o f 114.0 0 32 (The different ways of organizing a DIB, examined in the previous sections, and the related) W 300 -25100 M 248.1 0 32 (discussion seem to come to the conclusion that we don't consider the Directory System) W 300 -26600 M 268.8 0 32 (useful for the RFC987 gateways. Furthermore the actual solution adopted in the Visnu') W 300 -28100 M (gateway would seem to support this conclusion.) h 300 -30200 M 82.9 0 32 (Anyway our feeling is that the biggest obstacle against the use of a Directory System in the) W 300 -31700 M (RFC987 gateways environment is the lack of a real, wide experimentation of its use.) h 300 -33800 M 252.2 0 32 (In fact, only such an experimentation can provide real data on which evaluate, from an) W 300 -35300 M 147.9 0 32 (operational point of view, the suitability of the Directory System to the RFC987 gateways) W 300 -36800 M 88.3 0 32 (environment and give the opportunity of appreciating the operational benefits as opposed to) W 300 -38300 M (the technical problems highlighted in this paper.) h 300 -40400 M (From this point of view our paper is just a contribution and an incentive. ) h 300 -42500 M 300 -44600 M /Helvetica-Bold-ISOLatin1 F 1200 o f (REFERENCES) h 300 -46700 M /Times-Roman-ISOLatin1 F 1200 o f ([1]) h 3240 -46700 M 129.0 0 32 (CCITT X.500, X.501, X.509, X.511, X.518, X.519, X.520, X.521 for The Directory,) W 3180 -48200 M (International Telegraph and Telephone Consultive Committee \(November 1988\).) h 300 -50300 M ([2]) h 3240 -50300 M (S.E. Kille, RFC987: Mapping between X.400 and RFC\255822 \(June 1986\).) h 300 -52400 M ([3]) h 3240 -52400 M 238.1 0 32 (D.H. Crocker, Standard of the Format of ARPA Internet Text Messages, RFC\255822) W 3180 -53900 M (\(August 1982\).) h 300 -56000 M ([4]) h 3240 -56000 M 49.8 0 32 (R. Grimm, A Minimum Profile for RFC\255987: Mapping between addresses in RFC\255822) W 3180 -57500 M (format and X.400 Standard Attributes \(September 1988\).) h 300 -59600 M ([5]) h 3240 -59600 M (A. Hansen, H. Kvernelv, RARE MHS Project Report \(ELAB\255RUNIT, May 1989\).) h 300 -61700 M ([6]) h 3240 -61700 M (N. Freed, M. Vasol, System Manager's Guide to PMDF\255822 \(July 1987\).) h 300 -63800 M ([7]) h 3240 -63800 M (Digital Equipment Corporation, Introduction to Mailbus \(April 1988\).) h -7560 6480 T R showpage $P e /$P a D g N 0 79200 T S S 7560 -1980 T N 0 G 22860 -1200 M -7560 1980 T R S 7560 -73980 T N 0 G 21793 -1200 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1200 o f (\255) h (15\255) h -7560 73980 T R R S 7560 -6480 T N 0 G 300 -1200 M /Times-Roman-ISOLatin1 $ /Times-Roman & P /Times-Roman-ISOLatin1 F 1200 o f ([8]) h 3240 -1200 M (Tecnopolis\255Csata, Visnu' 1.0 Installation Guide \(February 1990\).) h 300 -3300 M ([9]) h 3240 -3300 M (Tecnopolis\255Csata, Visnu' 1.0 Management Guide \(February 1990\).) h 300 -5400 M ([10]) h 3240 -5400 M 643.1 0 32 (A. Mastrolonardo, D. Rotondi, Il gateway VISNU', ovvero come espandere) W 3180 -6900 M 86.3 0 32 (l'interconnetivita' del DEC Mailbus \(XI National Symposium DECUS ITALIA, April) W 3180 -8400 M (1990\).) h 300 -10500 M ([11]) h 3240 -10500 M 243.8 0 32 (A. Mastrolonardo, D. Rotondi, VISNU' : a VMS RFC987 gateway \(1990 DECUS) W 3180 -12000 M (Europe Symposium, Cannes\255France September 1990\).) h 300 -14100 M ([12]) h 3240 -14100 M 5.3 0 32 (A. Mastrolonardo, D. Rotondi, Il gateway VISNU': una soluzione alla interconnessione) W 3180 -15600 M (di differenti Servizi di E\255Mail \(AICA Annual Conference, Bari\255Italy September 1990\).) h 300 -17700 M 300 -19138 M -7560 6480 T R showpage $P e $D restore %%Trailer end % DEC_WRITE_dict %%Pages: 15 %%DocumentFonts: Helvetica-ISOLatin1 %%+ Helvetica-Bold-ISOLatin1 %%+ Times-Bold-ISOLatin1 %%+ Times-Roman-ISOLatin1 %%+ Times-Italic-ISOLatin1 %%+ Courier-ISOLatin1 %%+ Courier-Bold-ISOLatin1 %%+ Courier-Oblique-ISOLatin1   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <3267-12@bells.cs.ucl.ac.uk>; Fri, 14 Dec 1990 09:08:54 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <16220-2@sun2.nsfnet-relay.ac.uk>; Thu, 13 Dec 1990 22:01:33 +0000 Received: from gateway.mitre.org by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa21763; 13 Dec 90 21:53 GMT Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA25281; Thu, 13 Dec 90 16:57:11 -0500 Full-Name: Judy R. Messing Message-Id: <9012132157.AA25281@gateway.mitre.org> To: S.Kille@uk.ac.ucl.cs Cc: osi-ds@uk.ac.ucl.cs, gomberg@org.mitre.gateway, epg@org.mitre.gateway, messing@org.mitre.gateway Subject: Conflict on X.500 Meeting Dates Date: Thu, 13 Dec 90 16:56:17 -0500 From: messing@org.mitre.gateway Steve, I have just learned that the X3T5 and all its subgroups are meeting the last week of January. In addition, the Directory group is meeting February 4-8 in Orlando, Florida. These dates were set at the Directory meeting which met during the time of the IETF. The meeting dates do not conflict with your original X.500 Working Group dates of February 12 and 13. Judy Messing MITRE   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3878-0@bells.cs.ucl.ac.uk>; Fri, 14 Dec 1990 09:22:38 +0000 To: messing@org.mitre.gateway cc: osi-ds@uk.ac.ucl.cs, gomberg@org.mitre.gateway, epg@org.mitre.gateway Subject: Re: Conflict on X.500 Meeting Dates Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 13 Dec 90 16:56:17 -0500. <9012132157.AA25281@gateway.mitre.org> Date: Fri, 14 Dec 90 09:22:30 +0000 Message-ID: <352.661166550@UK.AC.UCL.CS> From: Steve Kille Judy, Thanks for this information. In view of this, the next meeting is confirmed on 12-13 February at SRI. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11594-0@bells.cs.ucl.ac.uk>; Fri, 14 Dec 1990 12:26:40 +0000 To: osi-ds@uk.ac.ucl.cs Subject: A proposal on Directory Quality of service Phone: +44-71-380-7294 Date: Fri, 14 Dec 90 12:26:38 +0000 Message-ID: <1183.661177598@UK.AC.UCL.CS> From: Steve Kille I'd appreciate comments on the following, before I submit it as a proposal for the Cosine/Internet naming architecture. Steve Handling QOS (Quality of service) in the directory There has been a lot of problem with variable quality of data and service over the directory. These attributes are proposed for use in the overall pilot (not implementation specific). To be useful, it would be necessary to ensure that they are used throughout the pilot. They can be used in the following ways: 1) By a user as additional information 2) By a system manager to determine what course of action to take following operational problems 3) By a DSA, as a heuristic to improve distributed operation (DSA choice) 4) By a DUA, perhaps to hide experimental stuff, or to indicate the quality of data/service to the user Parameters are given encoded values to facilitate automatic processing, and string values as it is recognised that useful subtleties of service can be indicated which are useful to the end user (e.g., as to which aspects of the data can be trusted) Information associated with each DSA: DSAQuality ATTRIBUTE WITH ATTRIBUTE-SYNTAX DSAQualitySyntax SINGLE VALUE DSAQualitySyntax ::= SEQUENCE { serviceQuality ENUMERATED { experimental (0), best-effort (1), -- no guaranteed support -- aim for >90% availability pilot-service (2), -- expect >95% availability full-service }, description PrintableString OPTIONAL } Information to be associated with every non-leaf entry SingleLevelQuality ATTRIBUTE WITH ATTRIBUTE-SYNTAX DataQualitySyntax SINGLE VALUE -- Note that Subtree quality exlcudes the entries at the first level -- It summarises the quality attributes at the levels below SubtreeMaximumQuality ATTRIBUTE WITH ATTRIBUTE-SYNTAX DataQualitySyntax SINGLE VALUE -- Defaults to SingleLevelQuality SubtreeMinimumQuality ATTRIBUTE WITH ATTRIBUTE-SYNTAX DataQualitySyntax SINGLE VALUE -- Defaults to SingleLevelQuality DataQualitySyntax ::= SEQUENCE { completeness ENUMERATED { sample(0), -- small number of random entries selected(1), -- partial coverage with most significant -- values present (low in DIT) -- or implying maintained namespace -- (high in DIT) substantial(2), -- >80% coverage full(3) -- all values present }, defaultAttributeQuality AttributeQuality, attributeQuality SET OF SEQUENCE { AttributeType, AttributeQuality }, description PrintableString OPTIONAL } AttributeQuality ::= ENUMERATED { experimental(0), downloaded(1), -- if present will be reasonably -- accurate, but may be absent maintained(2), -- if there is a value, it will -- be present and reasonably -- accurate user-supplied(3) }   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11544-0@bells.cs.ucl.ac.uk>; Mon, 17 Dec 1990 16:29:48 +0000 To: Erik.Huizer@nl.surfnet cc: osi-ds@uk.ac.ucl.cs Subject: Re: RARE WG3 meeting on directories Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 04 Dec 90 11:57:05 +0000. <"6761 Tue Dec 4 12:58:19 1990"@surver.surfnet.nl> Date: Mon, 17 Dec 90 16:29:45 +0000 Message-ID: <2162.661451385@UK.AC.UCL.CS> From: Steve Kille Erik, A few points on the Agenda. Cosine P2.1 - this will be presented by David Goodman There should be a discussion of how 2.1 will evolve: - meetings - standing documents - naming architecture We should review the status of TCP/IP vs X.25(80) vs CONS vs CLNS in Europe, and see how P2.1 should relate to the existing configuration and its expected evolution. The formal view of CONS in Europe and TCP/IP in the US does not reflect reality. Liaison with other pilots (esp. AARN) I will give a brief presentation on the progress at the IETF meeting. Minutes of the meeting, and all of the output documents will be available before Christmas, and all those attending should have copies of these documents. I'd like this group to work on the Internet Drafts, as I think that it is important for this work to have a genuine and not token European involvement. If this conflicts with other aspects of the Agenda, I suggest that we continue on Wednesday afternoon in parallel with the start of information services (I'd expect that the items reserved for this session would be the most technically detailed). People interested in this item should book a late flight back on Wednesday. In general, a RARE postion wrt this activity should be formulated. Storage of 987 data. We made good progress on this at the IETF X.400 group. I hope that Rob's new drafts (the document is being spit) will be available in time for this meeting. Security - are there any input documents. There will be a relevant Internet Draft (Peter Yee). I'd like to have a view on what we are trying to achieve here. IXI Listing - my proposal is buried in the Internet Draft "Domains and X.500" Steve   Return-Path: Received: from trident.arc.nasa.gov by bells.cs.ucl.ac.uk with SMTP inbound id <27325-0@bells.cs.ucl.ac.uk>; Tue, 18 Dec 1990 16:24:20 +0000 Received: by trident.arc.nasa.gov (5.64/1.2); Tue, 18 Dec 90 08:24:21 -0800 Date: Tue, 18 Dec 90 08:24:21 -0800 From: Greg "E." Brown Message-Id: <9012181624.AA02151@trident.arc.nasa.gov> To: osi-ds@uk.ac.ucl.cs Subject: Add to list X-Lines: 8 X-Mailer: Berkeley Mail (5.2 6/85) Please add me to the mailing list. Thanks, Merry Christmas, --Greg.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29837-0@bells.cs.ucl.ac.uk>; Wed, 19 Dec 1990 16:02:51 +0000 To: Erik.Huizer@nl.surfnet cc: osi-ds@uk.ac.ucl.cs Subject: Re: RARE WG3 meeting on directories Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 04 Dec 90 11:57:05 +0000. <"6761 Tue Dec 4 12:58:19 1990"@surver.surfnet.nl> Date: Wed, 19 Dec 90 16:02:49 +0000 Message-ID: <2050.661622569@UK.AC.UCL.CS> From: Steve Kille Erik, My diary had this meeting down for 9-11, and your message suggests that it is 8-10 January. Was this an error in my note taking, or has the meeting been shifted? thanks Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6562-0@bells.cs.ucl.ac.uk>; Thu, 20 Dec 1990 12:39:28 +0000 Return-Path: <@uk.ac.mhs-relay:huizer@nl.surfnet> Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <5646-0@bells.cs.ucl.ac.uk>; Thu, 20 Dec 1990 11:54:26 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Thu, 20 Dec 1990 11:46:48 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 20 Dec 1990 11:47:40 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 20 Dec 1990 12:50:00 +0000 Date: Thu, 20 Dec 1990 11:46:48 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.343:20.11.90.11.47.40] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: RARE WG3 ... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"11344 Thu Dec 20 12:47:43 1990"@surver.surfnet.nl> To: S.Kille@uk.ac.ucl.cs Subject: Re: RARE WG3 meeting on directories X-VMS-To: IN%"S.Kille@cs.ucl.ac.uk" Comments: EARN/BITnet: HUIZER@HUTSUR51 Sender: HUIZER@nl.surfnet Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Thu, 20 Dec 90 12:39:28 +0000 Resent-Message-ID: <1168.661696768@UK.AC.UCL.CS> Resent-From: Steve Kille Hello Steve, During Erik's holiday I read his mail and I found your message: Erik shifted the meeting to 8-10 and said so in a mail to WG3. You probably missed it. For more info:please mail to Jill Foster. Cheers, Maria Heijne (also WG3) ___________________________________________________________________________ > > Erik, > > My diary had this meeting down for 9-11, and your message suggests that > it is 8-10 January. Was this an error in my note taking, or has the > meeting been shifted? > > thanks > > Steve   Return-Path: Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5739-0@bells.cs.ucl.ac.uk>; Fri, 21 Dec 1990 15:04:08 +0000 To: osi-ds@uk.ac.ucl.cs cc: gvaudre@us.VA.Reston.NRI Subject: Revised naming architecture document Date: Fri, 21 Dec 90 15:04:07 +0000 From: Paul Barker Please find a revised version of the COSINE and Internet X.500 Naming Architecture appended to this message. The revisions are smallish, but numerous. Attention is drawn to the changes between this verion and the last version by means of "change bars". PLEASE NOTE that some additions to the naming architecture are not flagged (due to unfortunate interactions between some of the filters used in processing this document). Steps have been made to sort this out for next time, but this sort of thing seems ultimately to be in the hands of the Gods ... Following from these problems, a postscript version is no longer available. 2 important changes to note: mail list change: ietf-osi-ds -> osi-ds Attribute type proforma has sprouted additional fields Happy Christmas, Paul ----------------------------------------------- Network Working Group P. Barker INTERNET-DRAFT S.E. Kille University College London November 1990 The COSINE and Internet X.500 Naming Architecture Status of this Memo: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is | a draft, and comments on the updating mechanisms are | particularly welcome. Corrections and additions to the | naming architecture should now be sent the list, as | described within. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . Barker & Kille [page 1] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 1. Introduction Directory Services are a fundamental requirement of both human and computer communications' systems. Human users need to be able to look up various details about other people: for example, telephone numbers, facsimile numbers and paper mail addresses. Computing systems also need Directory Services for several purposes: for example, to support address look-ups for a variety of services, and to support user-friendly naming and distribution lists in electronic mail systems. Directory Services have recently been standardised and published as the 1988 CCITT X.500 / ISO IS9594 recommendations [1]. The standard provides a good basis for the provision of real services, and a considerable amount of Directory Service piloting activity is currently underway. In the U.S., the PSI White Pages Pilot [4] has stimulated use of X.500 on the Internet. In Britain, the U.K. Academic Community Directory Pilot [5] is similarly promoting use of X.500. 2. Motivation and aims of this document In a number of areas the X.500 standard only provides a basis for services. One such area is the Directory's Naming Architecture or Schema. The standard defines a number of useful object classes, in X.521, and attribute types, in X.520. These are intended to be generally useful across a range of directory applications. However, while these standard definitions are a useful starting point, they are insufficient as a basis for a large scale pilot directory. While it is possible for directory administrators to define their own sets of additional attribute types and object classes, this is undesirable for some common attributes and objects. The same objects and attribute types would be privately defined many times over. This would result in the directory's generality being diminished as remote systems would be unable to determine the semantics of these privately defined data types. A number of useful additions to the standard definitions were made in this note's forerunner, "The THORN and RARE Naming Architecture" [2]. These have been heavily used in early X.500 piloting activities. Furthermore, both the THORN and Quipu X.500 implementations have made use of these definitions. Barker & Kille [page 2] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 Since the afore-mentioned note was issued, a number of further requirements have come to light as the volume and variety of piloting activity has increased. Yet further requirements seem likely as the scale of X.500 pilot services increases. Thus, it is argued that it is not sufficient to merely reissue an updated version of the original note. The naming architecture is a "living document" that needs procedures for: - Allowing submission of requests for new attributes and object classes to be added into the naming architecture; - Checking for the redundancy of any previously defined attribute types and object classes. This document attempts to establish procedures to allow for the continual updating of the naming architecture. Two proformas are set out for this purpose. In addition, descriptive detail is provided for the additional object classes and attribute types defined in the naming architecture. These descriptions follow the style used in X.520 and X.521. Finally, also following the style adopted in the standards documents, appendices will include the entire naming architecture. Plain text versions of the document's appendices are intended to be machine processible to allow derivation of a system's schema tables. Appendix C lists all the architectures's object classes and attribute types in their respective ASN.1 macro formats. Appendix D lists some object classes and attribute types in a more concise format. Comments are requested on whether this format is considered useful. If so, a revised version of this document will include the architecture in full in this, or a similarly brief, format. The scope and intended remit of this coordination activity should be clearly understood. - Esoteric and local, highly experimental requirements should continue to be met by private definitions. - Requirements which have support from more than one site will usually be integrated into the naming architecture. Put in other words, the tendency will be for the inclusion, as opposed to the exclusion, of useful additions to the naming architecture. - An attempt will be made to avoid duplication of object Barker & Kille [page 3] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 classes and attribute types for essentially similar real world objects. It is important to note that this version of the document is a draft, which is intended principally to provoke comments on the naming architecture updating mechanisms proposed. Corrections to the architecture should also be indicated to the authors. However, additions to the architecture should not be submitted until a call is made for such enhancements. 3. What conformance to this architecture means It is not reasonable to require that a DSA which supports this architecture has specific code to handle each of the defined syntaxes. However, the following requirements are made of a system which claims conformance to this specification: 1. A DSA shall be able to store all of the attributes and object class values specified. (Note that this implies | support for all the object classes and attribute types | required by strong authentication as defined in X.509.) 2. A DUA shall be able to identify each attribute type and object class to the user, with an appropriate representation (e.g., a string). | 3. These statement are qualified for large attributes | (>1kbyte). A conforming DSA does not have to store such | attributes, and a DUA does not have to display the value of | such attributes, although it must indicate the attribute's | presence. The following are desirable, but not required: 1. For a DSA to match correctly on the basis of all attribute syntaxes defined 2. For a DSA to enforce the Object Class schema implied by these definitions 3. For a DUA to correctly display the attribute values (syntaxes) defined 4. For DUAs and DSAs to maintain compatibility with a previous Barker & Kille [page 4] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 version of the naming architecture. 4. Requesting new object classes and attribute types This section defines a procedure for requesting new object classes and attribute types to be added to the naming architecture. Proformas for object classes and attribute types are specified, and examples given of how to use them. As stated earlier, it is anticipated that the naming architecture will evolve considerably over time. As X.500 is used to support a widening range of applications, there will be requirements for extensions to the naming architecture. This document proposes formalising this procedure by requiring requests for additions to the naming architecture to be submitted as completed proformas. This stipulation will greatly simplify subsequent revisions of the naming architecture. There is one qualification to the above with respect to requests for modifications to an existing object class. If a modification to an object class merely involves additional, optional attributes, the object class will be enhanced as requested. Systems are expected to be resilient to such changes to the naming architecture. However, requests to modify an object class, such that the mandatory attribute types require altering, will not be met. Instead, a new object class will be created, and the original object class expired following the scheme described in the next main section. It is anticipated that most requests for modifications to the naming architecture will be met without any need for editorial intervention. Sometimes, however, some discussion between the submitter of a request and the architecture's editor may be required. For example, the editor may have to judge the relative merits of two very similar requests and, as a result, one of the parties may not get quite what they want. In cases such as this where the submitter of a request feels aggrieved about an editorial decision, the requestor may appeal to a broader community by explaining their views to the mailing list osi- | ds@cs.ucl.ac.uk. Heed will be paid to any consensus that emerges from discussions on the naming architecture on this list. If it proves that this list is used almost solely for discussions on Barker & Kille [page 5] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 naming architecture issues, a separate discussion list will be created. To facilitate the production of the afore-mentioned proformas, tools are included in Appendix B which will verify that a proforma has been correctly formatted. Completed proformas should be mailed to na-update@cs.ucl.ac.uk 4.1. Object Class proforma This section gives an example, completed proforma for a new object class, alcoholic drink. A proforma for object class specified in BNF is included in Appendix A. Object Class: Alcoholic Drink Description: The Alcoholic Drink object class is used to define | entries representing intoxicating beverages. | ASN1OCMacro: alcoholicDrink OBJECT-CLASS SUBCLASS OF drink MUST CONTAIN { percentAlcohol} MAY CONTAIN { normalServing, hue} An object class description consists of three fields, separated by blank lines. The keywords Object Class, Description and ASN1OCMacro, and their suffixed colons, must be included exactly as above. The Object Class field should be used for a textual description of the object class. This will be at most three or four words. The Description field should contain some explanatory text about the intended use of the object class. This can run to a number of lines. The ASN1OCMacro field should follow the definition of the object Barker & Kille [page 6] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 class macro as specified in X.501. The above example shows the main features. There are many more examples which can studied in the section defining the Pilot Object Classes. 4.2. Attribute type proforma This section gives an example completed proforma for a new attribute type, hue (one of the attribute types in the alcoholic drink object class). Attribute Type: Hue Description: The Hue attribute type specifies the hue of an object. OCMust: | OCMay: alcoholicDrink | ASN1ATMacro:hue ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-hue)) ub-hue INTEGER ::= 256 An attribute type description consists of five fields, separated | by blank lines. The keywords Attribute Type, Description, | OCMust, OCMay and ASN1ATMacro, and their suffixed colons, must be included exactly as above. The Attribute Type field should be used for a textual description of the attribute type. This will be at most three or four words. The Description field should contain some explanatory text about the intended use of the attribute type. This can run to a number of lines. The OCMust field should contain a comma-separated list of object | classes for which this attribute is mandatory. | The OCMay field should contain a comma-separated list of object | Barker & Kille [page 7] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 classes for which this attribute is optional. | The ASN1ATMacro field should follow the definition of the attribute macro as specified in X.501. The above example shows some of the features. In particular, please note the format for specifying size constraints . 5. Removing "old" object classes and attribute types. It is also important that object classes and attribute types which are no longer used or useful are removed from the naming architecture. Some object classes and attribute types initially defined as pilot extensions may be included as standard definitions in future versions of the standard. In such a case, it is important that there should be a fairly rapid transition to the standard definitions. Another possibility is that newer, more specific definitions obviate the original definitions. Two things are essential. First, it is crucial that "old" definitions are retired as gracefully as possible. The intention | to retire a definition will be sent to the osi-ds@cs.ucl.ac.uk | mail list. In the absence of objections, the definition will be | marked for expiry with a given expiry date. The definition will | remain in the architecture until the expiry date. Users of the architecture should ensure that they make the transition to new, alternative definitions in the interim. Second, users of the architecture must have the right to argue for the retention of definitions which they regard as necessary, there being no other definitions which closely meet their requirements. It is clearly impossible to lay down hard and fast rules on this point, as no two instances will ever be quite the same. It is intended that the refereeing on these matters will be sympathetic! As for requests for additions, an aggrieved user can "go to arbitration" by initiating a discussion on the osi- | ds@cs.ucl.ac.uk mail list. * 6. Object Identifiers | Some additional object identifiers are defined for this | architecture. These are also reproduced in Appendix C. | Barker & Kille [page 8] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 data OBJECT IDENTIFIER ::= {ccitt 9} pss OBJECT IDENTIFIER ::= {data 2342} ucl OBJECT IDENTIFIER ::= {pss 19200300} pilot OBJECT IDENTIFIER ::= {ucl 100} pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1} pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3} pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4} 7. Object Classes 7.1. X.500 standard object classes A number of generally useful object classes are defined in X.521, and these are supported. Refer to that document for descriptions of the suggested usage of these object classes. The ASN.1 for these object classes is reproduced for completeness in Appendix C. 7.2. X.400 standard object classes A number of object classes defined in X.400 are supported. Refer to X.402 for descriptions of the usage of these object classes. The ASN.1 for these object classes is reproduced for completeness in Appendix C. 7.3. COSINE/Internet object classes This section attempts to fuse together the object classes designed for use in the COSINE and Internet pilot activities. Descriptions are given of the suggested usage of these object classes. The ASN.1 for these object classes is also reproduced in Appendix C. 7.3.1. Pilot Object The PilotObject object class is used as a sub-class to allow some common, useful attributes to be assigned to entries of all other | object classes. Barker & Kille [page 9] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotObject OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { info, photo, manager, | uniqueIdentifier, | lastModifiedTime, lastModifiedBy} ::= {pilotObjectClass 3} 7.3.2. Pilot Person The PilotPerson object class is used as a sub-class of person, to allow the use of a number of additional attributes to be assigned to entries of object class person. Barker & Kille [page 10] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { userid, textEncodedORAddress, rfc822Mailbox, favouriteDrink, roomNumber, userClass, homeTelephoneNumber, | homePostalAddress, secretary, personalTitle, localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, facsimileTelephoneNumber, businessCategory, title, janetMailbox, | otherMailbox, mobileTelephoneNumber, pagerTelephoneNumber, | organizationalStatus} | ::= {pilotObjectClass 4} 7.3.3. Account The Account object class is used to define entries representing computer accounts. The userid attribute should be used for naming entries of this object class. Barker & Kille [page 11] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 account OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userid} MAY CONTAIN { description, seeAlso, localityName, organizationName, organizationalUnitName, host} ::= {pilotObjectClass 5} 7.3.4. Document The Document object class is used to define entries which represent documents. document OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { documentIdentifier} MAY CONTAIN { commonName, description, seeAlso, localityName, organizationName, organizationalUnitName, documentTitle, documentVersion, documentAuthor, documentLocation} ::= {pilotObjectClass 6} 7.3.5. Room The Room object class is used to define entries representing rooms. The commonName attribute should be used for naming entries of this object class. Barker & Kille [page 12] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 room OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { roomNumber, description, seeAlso, telephoneNumber} ::= {pilotObjectClass 7} 7.3.6. Document Series The Document Series object class is used to define an entry which represents a series of documents (e.g. The Request For Comments papers). documentSeries OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, seeAlso, telephoneNumber, localityName, organizationName, organizationalUnitName} ::= {pilotObjectClass 9} 7.3.7. Domain The Domain object class is used to define entries which represent DNS or NRS domains. The domainComponent attribute should be used for naming entries of this object class. The usage of this object class is described in more detail in [3]. Barker & Kille [page 13] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 domain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { domainComponent} MAY CONTAIN { associatedName, | organizationName, organizationalAttributeSet} ::= {pilotObjectClass 13} 7.3.8. RFC822 Local Part The RFC822 Local Part object class is used to define entries which represent the local part of RFC822 mail addresses. This treats this part of an RFC822 address as a domain. The usage of this object class is described in more detail in [3]. rFC822localPart OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { commonName, | surname, description, seeAlso, telephoneNumber, postalAttributeSet, telecommunicationAttributeSet} ::= {pilotObjectClass 14} 7.3.9. DNS Domain The DNS Domain (Domain NameServer) object class is used to define entries for DNS domains. The usage of this object class is described in more detail in [3]. Barker & Kille [page 14] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dNSDomain OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { ARecord, MDRecord, MXRecord, NSRecord, SOARecord, CNAMERecord} ::= {pilotObjectClass 15} 7.3.10. NRS Domain The NRS Domain object class is used to define entries which represent NRS domains. The usage of this object class is described in more detail in [3]. nRSdomain OBJECT-CLASS SUBCLASS OF domain MUST CONTAIN { nRSSystemDescription} MAY CONTAIN { ForwardOnlyInformation, ReverseOnlyInformation, ForwardAndReverseInformation} ::= {pilotObjectClass 16} 7.3.11. Domain Related Object The Domain Related Object object class is used to define entries which represent DNS/NRS domains which are "equivalent" to an X.500 domain:e.g. an organisation or organisational unit. The usage of this object class is described in more detail in [3]. domainRelatedObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { associatedDomain} | ::= {pilotObjectClass 17} Barker & Kille [page 15] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 7.3.12. Friendly Country The Friendly Country object class is used to define country entries in the DIT. The object class is used to allow friendlier naming of countries than that allowed by the object class country. The naming attribute of object class country, countryName, has to be a 2 letter string defined in ISO 3166. friendlyCountry OBJECT-CLASS SUBCLASS OF country MUST CONTAIN { friendlyCountryName} ::= {pilotObjectClass 18} 7.3.13. Simple Security Object | The Simple Security Object object class is used to allow an entry | to have a userPassword attribute when an entry's principal object | classes do not allow userPassword as an attribute type. | simpleSecurityObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userPassword } ::= {pilotObjectClass 19} 8. Attribute Types 8.1. X.500 standard attribute types A number of generally useful attribute types are defined in X.520, and these are supported. Refer to that document for descriptions of the suggested usage of these attribute types. The ASN.1 for these attribute types is reproduced for completeness in Appendix C. 8.2. X.400 standard attribute types The following standard X.400 attribute types are supported. See X.402 for full details. The ASN.1 for these attribute types is reproduced in Appendix C. Barker & Kille [page 16] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3. COSINE/Internet attribute types This section describes all the attribute types defined for use in the COSINE and Internet pilots. Descriptions are given as to the suggested usage of these attribute types. The ASN.1 for these attribute types is reproduced in Appendix C. 8.3.1. Userid The Userid attribute type specifies a computer system login name. | userid ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-identifier)) ::= {pilotAttributeType 1} 8.3.2. Text Encoded O/R Address The Text Encoded O/R Address attribute type specifies a text encoding of an X.400 O/R address, as specified in RFC 987. The use of this attribute is deprecated as the attribute is intended for interim use only. textEncodedORAddress ATTRIBUTE | WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-text-encoded-or-address)) ::= {pilotAttributeType 2} 8.3.3. RFC 822 Mailbox The RFC822 Mailbox attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non- Internet order mailboxes. rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} Barker & Kille [page 17] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.4. Information The Information attribute type specifies any general information pertinent to an object. It is recommended that specific usage of this attribute type is avoided, and that specific requirements are met by other (possibly additional) attribute types. info ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-information)) ::= {pilotAttributeType 4} 8.3.5. Favourite Drink The Favourite Drink attribute type specifies the favourite drink of an object (or person). favouriteDrink ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-favourite-drink)) ::= {pilotAttributeType 5} 8.3.6. Room Number The Room Number attribute type specifies the room number of an object. Note that the commonName attribute should be used for | naming room objects. roomNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-room-number)) ::= {pilotAttributeType 6} 8.3.7. Photo The Photo attribute type specifies a "photograph" for an object. This should be encoded in G3 fax as explained in recommendation T.4. Barker & Kille [page 18] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 photo ATTRIBUTE WITH ATTRIBUTE-SYNTAX photo (SIZE (1 .. ub-photo)) ::= {pilotAttributeType 7} 8.3.8. User Class The User Class attribute type specifies a category of computer | user. The semantics placed on this attribute are for local | interpretation. Examples of current usage od this attribute in | academia are undergraduate student, researcher, lecturer, etc. | Note that the organizationalStatus attribute may now often be | preferred as it makes no distinction between computer users and | others. userClass ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-class)) ::= {pilotAttributeType 8} 8.3.9. Host The Host attribute type specifies a host computer. host ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-host)) ::= {pilotAttributeType 9} 8.3.10. Manager The Manager attribute type specifies the manager of an object represented by an entry. Barker & Kille [page 19] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 manager ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 10} 8.3.11. Document Identifier The Document Identifier attribute type specifies a unique identifier for a document. documentIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-identifier)) ::= {pilotAttributeType 11} 8.3.12. Document Title The Document Title attribute type specifies the title of a document. documentTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-title)) ::= {pilotAttributeType 12} 8.3.13. Document Version The Document Version attribute type specifies the version number of a document. documentVersion ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-version)) ::= {pilotAttributeType 13} Barker & Kille [page 20] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.14. Document Author The Document Author attribute type specifies the distinguished name of the author of a document. documentAuthor ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 14} 8.3.15. Document Location The Document Location attribute type specifies the location of the document original. documentLocation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-location)) ::= {pilotAttributeType 15} 8.3.16. Home Telephone Number The Home Telephone Number attribute type specifies a home telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567" homeTelephoneNumber ATTRIBUTE | WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 20} 8.3.17. Secretary The Secretary attribute type specifies the secretary of a person. The attribute value for Secretary is a distinguished name. Barker & Kille [page 21] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 secretary ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 21} 8.3.18. Other Mailbox The Other Mailbox attribute type specifies values for electronic mailbox types other than X.400 and rfc822. ??? something about the syntax. otherMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX SEQUENCE { mailboxType PrintableString, -- e.g. Telemail mailbox IA5String -- e.g. X378:Joe } ::= {pilotAttributeType 22} 8.3.19. Last Modified Time The Last Modified Time attribute type specifies the last time, in UTC time, that an entry was modified. Ideally, this attribute | should be maintained by the DSA. lastModifiedTime ATTRIBUTE WITH ATTRIBUTE-SYNTAX uTCTimeSyntax ::= {pilotAttributeType 23} 8.3.20. Last Modified By The Last Modified By attribute specifies the distinguished name of the last user to modify the associated entry. Ideally, this | attribute should be maintained by the DSA. lastModifiedBy ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 24} Barker & Kille [page 22] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.21. Domain Component The Domain Component attribute type specifies a DNS/NRS domain. For example, "uk" or "ac". domainComponent ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax SINGLE VALUE ::= {pilotAttributeType 25} 8.3.22. DNS ARecord The A Record attribute type specifies a type A (Address) DNS resource record [6] [7]. aRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 26} 8.3.23. MX Record The MX Record attribute type specifies a type MX (Mail Exchange) DNS resource record [6] [7]. mXRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 28} 8.3.24. NS Record The NS Record attribute type specifies an NS (Name Server) DNS resource record [6] [7]. nSRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 29} Barker & Kille [page 23] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.25. SOA Record The SOA Record attribute type specifies a type SOA (Start of Authority) DNS resorce record [6] [7]. sOARecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 30} 8.3.26. CNAME Record The CNAME Record attribute type specifies a type CNAME (Canonical Name) DNS resource record [6] [7]. cNAMERecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 31} 8.3.27. Associated Domain The Associated Domain attribute type specifies a DNS or NRS domain which is associated with an object in the DIT. For example, the entry in the DIT with a distinguished name "C=GB, O=University College London" would have an associated domain of | "UCL.AC.UK. Note that all domains should be represented in | rfc822 order. See [3] for more details of usage of this | attribute. associatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 37} 8.3.28. Associated Name The Associated Name attribute type specifies an entry in the organisational DIT associated with a DNS/NRS domain. See [3] for more details of usage of this attribute. Barker & Kille [page 24] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 associatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 38} 8.3.29. Home postal address The Home postal address attribute type specifies a home postal address for an object. This should be limited to up to 6 lines of 30 characters each. homePostalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX postalAddress MATCHES FOR EQUALITY ::= {pilotAttributeType 39} 8.3.30. Personal Title The Personal Title attribute type specifies a personal title for a person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev". personalTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-personal-title)) ::= {pilotAttributeType 40} 8.3.31. Mobile Telephone Number The Mobile Telephone Number attribute type specifies a mobile telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567" mobileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 41} Barker & Kille [page 25] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.32. Pager Telephone Number The Pager Telephone Number attribute type specifies a pager telephone number for an object. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567". pagerTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 42} 8.3.33. Friendly Country Name The Friendly Country Name attribute type specifies names of countries in human readable format. The standard attribute country name must be one of the two-letter codes defined in ISO 3166. friendlyCountryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= {pilotAttributeType 43} 8.3.34. Unique Identifier | The Unique Identifier attribute type specifies a unique | identifier for an object represented in the Directory. For a | person, this might be an institution-wide payroll number. For an | organisational unit, it might be a department code. uniqueIdentifier ATTRIBUTE | WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-unique-identifier)) | ::= {pilotAttributeType 44} 8.3.35. Organisational Status | The Organisational Status attribute type specifies a category by | which a person is often referred to in an organisation. Examples | Barker & Kille [page 26] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 of usage in academia might include undergraduate student, | researcher, lecturer, etc. | A Directory administrator should probably consider carefully the | distinctions between this and the title and userClass attributes. | organizationalStatus ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-organizational-status)) ::= {pilotAttributeType 45} 8.3.36. Janet Mailbox | The Janet Mailbox attribute type specifies an electronic mailbox | attribute following the syntax specified in the Grey Book of the | Coloured Book series. This attribute is intended for the | convenience of U.K users unfamiliar with rfc822 and little-endian | mail addresses. Entries using this attribute MUST also include | an rfc822Mailbox attribute. | janetMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-janet-mailbox)) ::= {pilotAttributeType 46} 8.4. Generally useful syntaxes caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS Barker & Kille [page 27] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 iA5StringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS -- Syntaxes to support the DNS attributes DNSRecordSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY NRSInformationSyntax ATTRIBUTE-SYNTAX NRSInformation MATCHES FOR EQUALITY NRSInformation ::= SET { [0] Context, [1] Address-space-id, routes [2] SEQUENCE OF SEQUENCE { Route-cost, Addressing-info } } 8.5. Upper bounds on length of attribute values ub-document-identifier INTEGER ::= 256 ub-document-location INTEGER ::= 256 ub-document-title INTEGER ::= 256 ub-document-version INTEGER ::= 256 ub-favourite-drink INTEGER ::= 256 ub-host INTEGER ::= 256 ub-information INTEGER ::= 2048 Barker & Kille [page 28] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 ub-unique-identifier INTEGER ::= 256 | ub-personal-title INTEGER ::= 256 ub-photo INTEGER ::= 250000 ub-rfc822-mailbox INTEGER ::= 256 ub-room-number INTEGER ::= 256 ub-text-or-address INTEGER ::= 256 | ub-user-class INTEGER ::= 256 ub-user-identifier INTEGER ::= 256 | ub-organizational-status INTEGER ::= 256 | ub-janet-mailbox INTEGER ::= 256 9. Authors' addresses Paul Barker and Steve Kille Department of Computer Science University College London Gower Street London WC1E 6BT England Phone: +44 71-380-7366 (Barker) +44 71-380-7294 (Kille) Email: P.Barker@cs.ucl.ac.uk S.Kille@cs.ucl.ac.uk Barker & Kille [page 29] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 References [1] X.500, The Directory - overview of concepts, models and services, CCITT /ISO IS 9594 [2] S.E. Kille, The THORN and RARE X.500 Naming Architecture, in University College London, Department of Computer Science Research Note 89/48, May 1989. [3] S.E. Kille, X.500 and Domains, in University College London, Department of Computer Science Research Note 89/47, May 1989 [4] M.T. Rose, PSI/NYSERNet White Pages Pilot Project: Status Report, Technical Report 90-09-10-1, published by NYSERNet Inc, 1990 [5] J. Craigie, UK Academic Community Directory Service Pilot Project, pp. 305-310 in Computer Networks and ISDN Systems 17 (1989), published by North Holland. [6] P. Mockapetris, Domain Names - Concepts and Facilities, RFC-1034, USC Information Sciences Institute, November 1987 [7] P. Mockapetris, Domain Names - Implementation and Specification, RFC-1035, USC Information Sciences Institute, November 1987 Barker & Kille [page 30] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX A - Object Class and Attribute Type proformas These are specified in BNF. First some useful definitions, common to both proformas. EOL ::= -- the end of line character(s) BlankLine ::= -- a line consisting solely of an EOL character String ::= | anychar ::= --any character occurring in general text, excluding the end -- of line character lString ::= lowercase ::= [a-z] UString ::= uppercase ::= [A-Z] otherstring ::= | otherchar ::= | | Integer ::= | digit ::= [0-9] 1. Object Class OCProforma ::= \ ObjectClassName ::= "ObjectClass:" Description ::= "Description:" DescriptiveText ::= | Barker & Kille [page 31] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 OCMacro ::= "ASN1OCMacro:" -- The definition of ObjectClassMacro is adapted from that in X.501 ObjectClassMacro ::= "OBJECT-CLASS" \ OCName ::= SubclassOf ::= "SUBCLASS OF" Subclasses | Subclasses ::= | "," Subclass ::= MandatoryAttributes ::= "MUST CONTAIN {" "}" | OptionalAttributes ::= "MAY CONTAIN {" "}" | Attributes ::= | "," AttributeTerm ::= | Attribute ::= AttributeSet ::= 2. Attribute Type ATProforma ::= \ \ | AttributeTypeName ::= "Attribute Type:" Description ::= "Description:" DescriptiveText ::= | OCMust ::= "OCMust:" | OCList ::= | "," | | Barker & Kille [page 32] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 OCMay ::= "OCMay:" | ATMacro ::= "ASN1ATMacro:" -- The definition of AttributeTypeMacro is adapted from that in X.501 AttributeTypeMacro ::= "ATTRIBUTE" \ | ATName ::= AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice SyntaxChoice ::= | Syntax ::= Constraint ::= "(" ConstraintAlternative ")" | ConstraintAlternative ::= StringConstraint | IntegerConstraint StringConstraint ::= "SIZE" "(" SizeConstraint ")" SizeConstraint ::= SingleValue | Range SingleValue ::= Range ::= ".." IntegerConstraint ::= Range ASN1Type ::= -- one of ASN.1's base types: e.g. PrintableString, NumericString, etc. MatchTypes ::= "MATCHES FOR" Matches | Matches ::= Match | Matches Match Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING" Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | Barker & Kille [page 33] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX B - Format checking tools This section includes the source for format checking tools for the two proformas. The tools are written as Bourne shell scripts for UNIX systems. 1. Object class format checker sed 's/ *: */:/' | awk ' BEGIN { state = "initial" } /^$/ { next } /^Object Class:/ { n = index($0, ":") if (state != "initial") { print "Already got object class " oc print "Got another object class " substr($0, n+1) state = "notOK" exit 1 } oc = substr($0, n+1) state = "gotOC" next } /^Description:/ { n = index($0, ":") if (state != "gotOC") { print "Got Description: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Object Class:" else Barker & Kille [page 34] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 print "Expecting ASN1OCMacro:" state = "notOK" exit 1 } while (getline > 0) if (length($0) > 0) continue else break state = "gotDesc" next } /^ASN1OCMacro:/ { n = index($0, ":") if (state != "gotDesc") { print "Got ASN1Macro: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Object Class:" else print "Expecting Description:" state = "notOK" exit 1 } state = "OK" exit 0 } { print "Parsing has got confused on seeing line: " $0 state = "notOK" exit 1 } END { if (state == "OK") print "Input looks OK" } Barker & Kille [page 35] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 2. Attribute Type format checker sed 's/ *: */:/' | awk ' BEGIN { state = "initial" } /^$/ { next } /^Attribute Type:/ { n = index($0, ":") if (state != "initial") { got = "Attribute Type:" | exit 1 } state = "gotAT" * next } /^Description:/ { n = index($0, ":") if (state != "gotAT") { got = "Description:" | exit 1 } while (getline > 0) if (length($0) > 0) continue else break state = "gotDesc" next } /^OCMust:/ { | n = index($0, ":") if (state != "gotDesc") { Barker & Kille [page 36] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 got = "OCMust:" | exit 1 } state = "gotOCMust" | next | } | /^OCMay:/ { | n = index($0, ":") | if (state != "gotOCMust") | { | got = "OCMay:" | exit 1 | } | state = "gotOCMay" | next | } | /^ASN1ATMacro:/ { | n = index($0, ":") | if (state != "gotOCMay") | { | got = "ASN1ATMacro:" | exit 1 | } | state = "OK" exit 0 } { print "Parsing has got confused on seeing line: " $0 state = "notOK" exit 1 } END { if (state == "initial") | print "Expecting Attribute Type:" | else if (state == "gotAT") | print "Expecting Description:" | else if (state == "gotDesc") | print "Expecting OCMust:" | else if (state == "gotOCMust") | print "Expecting OCMay:" | Barker & Kille [page 37] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 else if (state == "gotOCMay") | print "Expecting ASN1ATMacro:" | if (state != "OK") | print "Got " got | else | print "Input looks OK" } Barker & Kille [page 38] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX C - Summary of all Object Classes and Attribute Types * -- Some Important Object Identifiers | data OBJECT IDENTIFIER ::= {ccitt 9} pss OBJECT IDENTIFIER ::= {data 2342} ucl OBJECT IDENTIFIER ::= {pss 19200300} pilot OBJECT IDENTIFIER ::= {ucl 100} pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1} pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3} pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4} -- Standard Object Classes top OBJECT-CLASS MUST CONTAIN { objectClass} ::= {objectClass 0} alias OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { aliasedObjectName} ::= {objectClass 1} country OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { countryName} MAY CONTAIN { description, searchGuide} ::= {objectClass 2} Barker & Kille [page 39] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 locality OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { description, localityName, stateOrProvinceName, searchGuide, seeAlso, streetAddress} ::= {objectClass 3} organization OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 4} organizationalUnit OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationalUnitName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 5} person OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, surname} MAY CONTAIN { description, seeAlso, telephoneNumber, userPassword} ::= {objectClass 6} Barker & Kille [page 40] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organizationalPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { localeAttributeSet, organizationalUnitName, postalAttributeSet, telecommunicationAttributeSet, title} ::= {objectClass 7} organizationalRole OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localeAttributeSet, organizationalUnitName, postalAttributeSet, preferredDeliveryMethod, roleOccupant, seeAlso, telecommunicationAttributeSet} ::= {objectClass 8} groupOfNames OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, member} MAY CONTAIN { description, organizationName, organizationalUnitName, owner, seeAlso, businessCategory} ::= {objectClass 9} Barker & Kille [page 41] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 residentialPerson OBJECT-CLASS SUBCLASS OF person MUST CONTAIN { localityName} MAY CONTAIN { localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, telecommunicationAttributeSet, businessCategory} ::= {objectClass 10} applicationProcess OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localityName, organizationalUnitName, seeAlso} ::= {objectClass 11} applicationEntity OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, presentationAddress} MAY CONTAIN { description, localityName, organizationName, organizationalUnitName, seeAlso, supportedApplicationContext} ::= {objectClass 12} Barker & Kille [page 42] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dSA OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { knowledgeInformation} ::= {objectClass 13} device OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localityName, organizationName, organizationalUnitName, owner, seeAlso, serialNumber} ::= {objectClass 14} strongAuthenticationUser OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userCertificate} ::= {objectClass 15} certificationAuthority OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { cACertificate, certificateRevocationList, authorityRevocationList} MAY CONTAIN { crossCertificatePair} ::= {objectClass 16} -- Standard MHS Object Classes Barker & Kille [page 43] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsDistributionList OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, mhsDLSubmitPermissions, mhsORAddresses} MAY CONTAIN { description, organizationName, organizationalUnitName, owner, seeAlso, mhsDeliverableContentTypes, mhsdeliverableEits, mhsDLMembers, mhsPreferredDeliveryMethods} ::= {mhsObjectClass 0} mhsMessageStore OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { description, owner, mhsSupportedOptionalAttributes, mhsSupportedAutomaticActions, mhsSupportedContentTypes} ::= {mhsObjectClass 1} mhsMessageTransferAgent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { description, owner, mhsDeliverableContentLength} ::= {mhsObjectClass 2} Barker & Kille [page 44] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsOrganizationalUser OBJECT-CLASS SUBCLASS OF organizationalPerson MUST CONTAIN { mhsORAddresses} MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsMessageStoreName, mhsPreferredDeliveryMethods } ::= {mhsObjectClass 3} mhsResidentialUser OBJECT-CLASS SUBCLASS OF residentialPerson MUST CONTAIN { mhsORAddresses} MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsMessageStoreName, mhsPreferredDeliveryMethods } ::= {mhsObjectClass 4} mhsUserAgent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsORAddresses, owner} ::= {mhsObjectClass 5} -- Pilot Object Classes Barker & Kille [page 45] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotObject OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { info, photo, manager, | uniqueIdentifier, | lastModifiedTime, lastModifiedBy} ::= {pilotObjectClass 3} pilotPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { userid, textEncodedORAddress, rfc822Mailbox, favouriteDrink, roomNumber, userClass, homeTelephoneNumber, | homePostalAddress, secretary, personalTitle, localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, facsimileTelephoneNumber, businessCategory, title, janetMailbox, | otherMailbox, mobileTelephoneNumber, pagerTelephoneNumber, | organizationalStatus} | ::= {pilotObjectClass 4} Barker & Kille [page 46] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 account OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userid} MAY CONTAIN { description, seeAlso, localityName, organizationName, organizationalUnitName, host} ::= {pilotObjectClass 5} document OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { documentIdentifier} MAY CONTAIN { commonName, description, seeAlso, localityName, organizationName, organizationalUnitName, documentTitle, documentVersion, documentAuthor, documentLocation} ::= {pilotObjectClass 6} room OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { roomNumber, description, seeAlso, telephoneNumber} ::= {pilotObjectClass 7} Barker & Kille [page 47] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 documentSeries OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, seeAlso, telephoneNumber, localityName, organizationName, organizationalUnitName} ::= {pilotObjectClass 9} domain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { domainComponent} MAY CONTAIN { associatedName, | organizationName, organizationalAttributeSet} ::= {pilotObjectClass 13} rFC822localPart OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { commonName, | surname, description, seeAlso, telephoneNumber, postalAttributeSet, telecommunicationAttributeSet} ::= {pilotObjectClass 14} Barker & Kille [page 48] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dNSDomain OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { ARecord, MDRecord, MXRecord, NSRecord, SOARecord, CNAMERecord} ::= {pilotObjectClass 15} nRSdomain OBJECT-CLASS SUBCLASS OF domain MUST CONTAIN { nRSSystemDescription} MAY CONTAIN { ForwardOnlyInformation, ReverseOnlyInformation, ForwardAndReverseInformation} ::= {pilotObjectClass 16} domainRelatedObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { associatedDomain} | ::= {pilotObjectClass 17} friendlyCountry OBJECT-CLASS SUBCLASS OF country MUST CONTAIN { friendlyCountryName} ::= {pilotObjectClass 18} simpleSecurityObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userPassword } ::= {pilotObjectClass 19} Barker & Kille [page 49] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 -- Standard Attribute Types | objectClass ObjectClass ::= {attributeType 0} aliasedObjectName AliasedObjectName ::= {attributeType 1} knowledgeInformation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreString ::= {attributeType 2} commonName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-common-name)) ::= {attributeType 3} surname ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-surname)) ::= {attributeType 4} serialNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX printableStringSyntax (SIZE (1..ub-serial-number)) ::= {attributeType 5} countryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (1..ub-country-code)) SINGLE VALUE ::= {attributeType 6} localityName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-locality-name)) ::= {attributeType 7} stateOrProvinceName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-state-name)) ::= {attributeType 8} Barker & Kille [page 50] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 streetAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-street-address)) ::= {attributeType 9} organizationName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-organization-name)) ::= {attributeType 10} organizationalUnitName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-organizational-unit-name)) ::= {attributeType 11} title ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-title)) ::= {attributeType 12} description ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-description)) ::= {attributeType 13} searchGuide ATTRIBUTE WITH ATTRIBUTE-SYNTAX Guide ::= {attributeType 14} businessCategory ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-business-category)) ::= {attributeType 15} postalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PostalAddress MATCHES FOR EQUALITY ::= {attributeType 16} postalCode ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-postal-code)) ::= {attributeType 17} Barker & Kille [page 51] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 postOfficeBox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-post-office-box)) ::= {attributeType 18} physicalDeliveryOfficeName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-physical-office-name)) ::= {attributeType 19} telephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax (SIZE (1..ub-telephone-number)) ::= {attributeType 20} telexNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX TelexNumber (SIZE (1..ub-telex)) ::= {attributeType 21} teletexTerminalIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier (SIZE (1..ub-teletex-terminal-id)) ::= {attributeType 22} facsimileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber ::= {attributeType 23} x121Address ATTRIBUTE WITH ATTRIBUTE-SYNTAX NumericString (SIZE (1..ub-x121-address)) ::= {attributeType 24} internationaliSDNNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX NumericString (SIZE (1..ub-isdn-address)) ::= {attributeType 25} registeredAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PostalAddress ::= {attributeType 26} Barker & Kille [page 52] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 destinationIndicator ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (1..ub-destination-indicator)) MATCHES FOR EQUALITY SUBSTRINGS ::= {attributeType 27} preferredDeliveryMethod ATTRIBUTE WITH ATTRIBUTE-SYNTAX deliveryMethod ::= {attributeType 28} presentationAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PresentationAddress MATCHES FOR EQUALITY ::= {attributeType 29} supportedApplicationContext ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax ::= {attributeType 30} member ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 31} owner ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 32} roleOccupant ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 33} seeAlso ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 34} userPassword ATTRIBUTE WITH ATTRIBUTE-SYNTAX Userpassword ::= {attributeType 35} userCertificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX UserCertificate ::= {attributeType 36} Barker & Kille [page 53] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 cACertificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX cACertificate ::= {attributeType 37} authorityRevocationList ATTRIBUTE WITH ATTRIBUTE-SYNTAX AuthorityRevocationList ::= {attributeType 38} certificateRevocationList ATTRIBUTE WITH ATTRIBUTE-SYNTAX CertificateRevocationList ::= {attributeType 39} crossCertificatePair ATTRIBUTE WITH ATTRIBUTE-SYNTAX CrossCertificatePair ::= {attributeType 40} -- Standard MHS Attribute Types mhsDeliverableContentLength ATTRIBUTE WITH ATTRIBUTE-SYNTAX integer ::= {mhsAttributeType 0} mhsDeliverableContentTypes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 1} mhsDeliverableEits ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 2} mhsDLMembers ATTRIBUTE WITH ATTRIBUTE-SYNTAX oRName ::= {mhsAttributeType 3} mhsDLSubmitPermissions ATTRIBUTE WITH ATTRIBUTE-SYNTAX dLSubmitPermission ::= {mhsAttributeType 4} mhsMessageStoreName ATTRIBUTE WITH ATTRIBUTE-SYNTAX dN ::= {mhsAttributeType 5} Barker & Kille [page 54] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsORAddresses ATTRIBUTE WITH ATTRIBUTE-SYNTAX oRAddress ::= {mhsAttributeType 6} mhsPreferredDeliveryMethods ATTRIBUTE WITH ATTRIBUTE-SYNTAX deliveryMethod ::= {mhsAttributeType 7} mhsSupportedAutomaticActions ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 8} mhsSupportedContentTypes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 9} mhsSupportedOptionalAttributes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 10} -- Pilot Attribute Types userid ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-identifier)) ::= {pilotAttributeType 1} textEncodedORAddress ATTRIBUTE | WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-text-encoded-or-address)) ::= {pilotAttributeType 2} rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} Barker & Kille [page 55] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 info ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-information)) ::= {pilotAttributeType 4} favouriteDrink ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-favourite-drink)) ::= {pilotAttributeType 5} roomNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-room-number)) ::= {pilotAttributeType 6} photo ATTRIBUTE WITH ATTRIBUTE-SYNTAX photo (SIZE (1 .. ub-photo)) ::= {pilotAttributeType 7} userClass ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-class)) ::= {pilotAttributeType 8} host ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-host)) ::= {pilotAttributeType 9} Barker & Kille [page 56] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 manager ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 10} documentIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-identifier)) ::= {pilotAttributeType 11} documentTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-title)) ::= {pilotAttributeType 12} documentVersion ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-version)) ::= {pilotAttributeType 13} documentAuthor ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 14} documentLocation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-location)) ::= {pilotAttributeType 15} Barker & Kille [page 57] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 homeTelephoneNumber ATTRIBUTE | WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 20} secretary ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 21} otherMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX SEQUENCE { mailboxType PrintableString, -- e.g. Telemail mailbox IA5String -- e.g. X378:Joe } ::= {pilotAttributeType 22} lastModifiedTime ATTRIBUTE WITH ATTRIBUTE-SYNTAX uTCTimeSyntax ::= {pilotAttributeType 23} lastModifiedBy ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 24} domainComponent ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax SINGLE VALUE ::= {pilotAttributeType 25} Barker & Kille [page 58] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 aRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 26} mXRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 28} nSRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 29} sOARecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 30} cNAMERecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 31} associatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 37} associatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 38} Barker & Kille [page 59] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 homePostalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX postalAddress MATCHES FOR EQUALITY ::= {pilotAttributeType 39} personalTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-personal-title)) ::= {pilotAttributeType 40} mobileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 41} pagerTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 42} friendlyCountryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= {pilotAttributeType 43} uniqueIdentifier ATTRIBUTE | WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-unique-identifier)) | ::= {pilotAttributeType 44} Barker & Kille [page 60] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organizationalStatus ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-organizational-status)) ::= {pilotAttributeType 45} janetMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-janet-mailbox)) ::= {pilotAttributeType 46} -- Generally useful syntaxes | caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS iA5StringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS -- Syntaxes to support the DNS attributes DNSRecordSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY NRSInformationSyntax ATTRIBUTE-SYNTAX NRSInformation MATCHES FOR EQUALITY Barker & Kille [page 61] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 NRSInformation ::= SET { [0] Context, [1] Address-space-id, routes [2] SEQUENCE OF SEQUENCE { Route-cost, Addressing-info } } -- Upper bounds on length of attribute values ub-document-identifier INTEGER ::= 256 ub-document-location INTEGER ::= 256 ub-document-title INTEGER ::= 256 ub-document-version INTEGER ::= 256 ub-favourite-drink INTEGER ::= 256 ub-host INTEGER ::= 256 ub-information INTEGER ::= 2048 ub-unique-identifier INTEGER ::= 256 | ub-personal-title INTEGER ::= 256 ub-photo INTEGER ::= 250000 ub-rfc822-mailbox INTEGER ::= 256 ub-room-number INTEGER ::= 256 ub-text-or-address INTEGER ::= 256 | ub-user-class INTEGER ::= 256 Barker & Kille [page 62] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 ub-user-identifier INTEGER ::= 256 * ub-organizational-status INTEGER ::= 256 | ub-janet-mailbox INTEGER ::= 256 | Barker & Kille [page 63]   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9283-0@bells.cs.ucl.ac.uk>; Fri, 21 Dec 1990 17:50:18 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Overall DS Document Phone: +44-71-380-7294 Date: Fri, 21 Dec 90 17:50:16 +0000 Message-ID: <1588.661801816@UK.AC.UCL.CS> From: Steve Kille This is the first of the output documents from Boulder. I plan to submit it as an RFC shortly. I'm circulating the draft for comment, to ensure that I accurately refleced the changes that we agreed. I believe that I have also fixed things so that the document will print one page per page! Please send comments. Steve ------- Network Working Group S.E. Kille INTERNET--DRAFT University College London November 1990 Building an Internet Directory using X.500 Status of this Memo The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT Building an Internet Directory November 1990 1 Introduction There is substantial interest in establishing an OSI Directory Service on the Internet. There is pressure to establish a number of services on the Internet, including: o White Pages lookup of users. o Support for OSI Applications. o Support for X.509 Authentication for a range of application, including Privacy Enhanced Mail [Lin89 ]. The OSI Directory is viewed as the best basis for achieving these services, for both technical and political reasons. The OSI Directory Standards do not contain sufficient information to enable such a service to be built. Full openness and interoperability are a key goal, so service must not depend on private extensions or informal agreements. This document describes the missing components, and suggests a strategy for filling in the holes. The activity is being limited to (reasonably well) understood issues. This means that whilst we will attempt to solve a wide range of problems, that not all (potential) requirements will necessarily be met. 2 Schema A Directory needs to be used in the context of an Information Framework. The standard directory provides a number of a attributes and object classes to enable basic operation. It is certain that the Internet Community will have requirements for additional attributes and object classes. There is a need to establish a mechanism to register such information. Pilots in the European RARE Community and the US PSI White Pages Pilot have based their information framework on the THORN and RARE Naming Architecture [Kil89c ]. It is proposed to use this architecture for the Internet Pilot, in conjunction with COSINE based piloting in Europe. A revised version of the Naming Architecture will be produced, with a mechanism for registration of new attributes and object classes [KB90 ]. Kille Page 1 INTERNET--DRAFT Building an Internet Directory November 1990 3 Use on the Internet It is desirable to decouple deployment of the OSI Directory from deployment of the OSI lower layers. This pilot will not make any mandatory requirements about use of lower layers. When configuring the pilot, variations in the lower layers must be considered. The following options are possible: o Use of OSI Network Service (Connection Oriented or Connectionless). It is seen as fundamental to allow use of the OSI lower layers. o Operation over TCP/IP using RFC 1006 [RC87 ]. This is a practical requirement of deployment at very many Internet sites, and is the basis of the existing pilot. o X.25(80) will probably not be used in the infrastructure of the Internet Pilot, but is the basis of some European activities. There will be a practical need to interwork with DSAs which only support this stack. This approach has the following implications. 1. There is a need to represent TCP/IP addresses within OSI Network Addresses. An Internet Draft, based on a paper by Kille, should be taken as a starting point for this [Kil89a ]. It will be necessary to have in Internet Standard on this area. 2. It will be desirable to have a uniform method to present Network Addresses of this style. Therefore a string representation should be developed in parallel. The Internet Draft, based on a paper by Kille, should be used as a basis for this [Kil89b ]. 3. This choice leads to the situation where not all DSAs can communicate directly due the different choice of lower layers. This is already a practical result of many European sites operating DSAs over X.25. There may be a requirement to extend the distributed operations, so that there is no requirement for full connectivity. This issue will be dealt with in the documents to be generated according to Section 4. 4. When the pilot is deployed, the issue of which DSAs operate which stacks must be considered in order to achieve a coherent service. Kille Page 2 INTERNET--DRAFT Building an Internet Directory November 1990 4 Replication of Knowledge and Data There are a number of requirements on replication, both of data and knowledge information, which must be met before an Internet Directory can be deployed. It is clear that the standard cannot be used as is. Three solutions were noted: o Wait until the 1992 standard is available o Attempt to intercept the 1992 standard, probably by specification of subset functionality based on the current working documents, and in particular the CD on replication [CCI90 ]. o Use an interim approach It is necessary to define the minimum requirements. This is specified in a separate INTERNET--DRAFT [Kil90a ]. The third approach will be taken initially. It will be clearly emphasised that this is an interim approach, which will be phased out as soon as the appropriate standards are available and stable. An interim approach, based on the approach used in the QUIPU Implementation and deployed in existing pilots will be used [Kil88 ]. These are being documented in an INTERNET--DRAFT [Kil90b ]. 5 Security A Directory and Security are closely related. There is no requirement for specification of any Internet specific approaches at this stage. Deployment of a directory could be based on one of: o Read only system, containing only public data and using local modification. o Use of X.509 authentication, and private access control mechanisms (this will not allow open access control management, but this is not seen as a fundamental problem) [CCI88a ]. A specification on security for the Internet Directory should be developed. This should specify: o Internet requirements for security in the Directory o A recommendation of how to use X.509 Kille Page 3 INTERNET--DRAFT Building an Internet Directory November 1990 o Recommendation on service requirements for access control, as a hint to implementors who attempt to intercept the 1992 standard or develop private mechanisms o A note on security issues (authentication, policy, access control) not being addressed by the standards work, which might require future work o Requirements and recommendations for implementors (e.g., in terms of maintaining data confidentiality within an Organisation) 6 Presentation of Directory Names The standard does not specify a means to present directory names to the user. This is seen as a serious deficiency, and a standard for presenting directory names should be developed. The ``User Friendly Name'' specification by Kille should be submitted as an Internet Draft, as a starting point for this work [Kil90c ]. 7 Name Allocation When the directory is deployed, there will be a need to allocate the top levels of the DIT. Most aspects will need to be tackled on a national basis. This group will consider name allocations at the top of the DIT, and will look at handling of the US part of the DIT. The major aim here will be to ensure that the Internet takes an, approach aligned to that of the NADF. 8 DSA Naming and MD Structure There are some critical issues related to naming of DSAs and the structure of Directory Management Domains. It is likely that there will need to be recommendations on how to handle this. 9 Relation to DNS It is important to establish the relationship between the proposed Internet Directory, and the existing Domain Name System. One input to this work should be the Internet Draft by Kille, to be updated before the meeting [Kil89d ]. Kille Page 4 INTERNET--DRAFT Building an Internet Directory November 1990 10 Documents and Timescales The following work is being undertaken following the boulder meeting Boulder IETF Meeting. Schema Revise Cosine and Internet Naming Architecture. P. Barker/S.E. Kille [KB90 ] Network Address Encoding Revise the Internet Draft [Kil89a ]. S.E. Kille. Address String Encoding Revise the Internet Draft [Kil89b ]. S.E. Kille. Replication Requirements Revise the Internet Draft [Kil90a ]. S.E Kille. Replication Solution Revise the Internet Draft [Kil90b ]. S.E. Kille. Security Revise the tabled paper and submit as an Internet Draft. P. Yee/B. Manning Directory Name Presentation Revise the Internet Draft [Kil90c ]. S.E. Kille. Relation to DNS (Domains and X.500) Revise the Internet Draft [Kil89d ]. S.E. Kille. The changes to this document were agreed at the Boulder meeting. It is expected to progress this document to RFC Status in January 1991. The remainder of the documents will be reviewed at the meeting at SRI in February. It is intended to release all of them as RFCs following this meeting. This will allow deployment of the Interenet Directory during 1991. References [CCI88a] The directory --- authentication framework, December 1988. CCITT Recommendation X.509. [CCI88b] The directory - overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations. [CCI90] The directory --- part 9 --- replication, October 1990. ISO/IEC CD 9594-9 Ottowa ouput. Kille Page 5 INTERNET--DRAFT Building an Internet Directory November 1990 [KB90] S.E. Kille and P. Barker. he cosine and internet x.500 naming architecture, November 1990. Internet Draft: draft-ietf-osids-cosinex500-00.txt. [Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5 Conference on Message Handling Systems and Distributed Applications, pages 173--186. North Holland Publishing, October 1988. [Kil89a] S.E. Kille. An interim approach to use of network addresses. Research Note RN/89/13, Department of Computer Science, University College London, February 1989. Internet Draft: draft-ucl-kille-networkaddresses-01.txt, ps. [Kil89b] S.E. Kille. A string encoding of presentation address. Research Note RN/89/14, Department of Computer Science, University College London, February 1989. Internet Draft: draft-ucl-kille-presentationaddress-01.txt, ps. [Kil89c] S.E. Kille. The THORN and RARE naming architecture. Technical report, Department of Computer Science, University College London, June 1989. THORN Report UCL-64 (version 2). [Kil89d] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College London, May 1989. Also Internet Draft: DRAFT-UCL-KILLE-X500DOMAINS-00.PS. [Kil90a] S.E. Kille. Replication requirement to provide an internet directory using X.500, November 1990. Internet Draft: draft-ietf-osids-replication-00.txt. [Kil90b] S.E. Kille. Replication requirement to provide an internet directory using X.500: A proposed solution, November 1990. Internet Draft: draft-ietf-osids-replsoln-00.txt, ps. [Kil90c] S.E. Kille. Using the osi directory to achieve user friendly naming. Research Note RN/90/29, Department of Computer Science, University College London, February 1990. Internet Draft: draft-ietf-osids-friendlynaming-00.txt, ps. [Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail: Part 1 --- Message Encipherment and Authentication Procedures. Request for Comments 1113, DDN Network Information Center, SRI International, August 1989. Kille Page 6 INTERNET--DRAFT Building an Internet Directory November 1990 [RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services on top of the TCP. Request for Comments 1006, DDN Network Information Center, SRI International, May 1987. 11 Security Considerations Security considerations are discussed in Section 5 of this INTERNET--DRAFT . 12 Author's Address Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Kille Page 7   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9283-0@bells.cs.ucl.ac.uk>; Fri, 21 Dec 1990 17:50:18 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Overall DS Document Phone: +44-71-380-7294 Date: Fri, 21 Dec 90 17:50:16 +0000 Message-ID: <1588.661801816@UK.AC.UCL.CS> From: Steve Kille This is the first of the output documents from Boulder. I plan to submit it as an RFC shortly. I'm circulating the draft for comment, to ensure that I accurately refleced the changes that we agreed. I believe that I have also fixed things so that the document will print one page per page! Please send comments. Steve ------- Network Working Group S.E. Kille INTERNET--DRAFT University College London November 1990 Building an Internet Directory using X.500 Status of this Memo The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT Building an Internet Directory November 1990 1 Introduction There is substantial interest in establishing an OSI Directory Service on the Internet. There is pressure to establish a number of services on the Internet, including: o White Pages lookup of users. o Support for OSI Applications. o Support for X.509 Authentication for a range of application, including Privacy Enhanced Mail [Lin89 ]. The OSI Directory is viewed as the best basis for achieving these services, for both technical and political reasons. The OSI Directory Standards do not contain sufficient information to enable such a service to be built. Full openness and interoperability are a key goal, so service must not depend on private extensions or informal agreements. This document describes the missing components, and suggests a strategy for filling in the holes. The activity is being limited to (reasonably well) understood issues. This means that whilst we will attempt to solve a wide range of problems, that not all (potential) requirements will necessarily be met. 2 Schema A Directory needs to be used in the context of an Information Framework. The standard directory provides a number of a attributes and object classes to enable basic operation. It is certain that the Internet Community will have requirements for additional attributes and object classes. There is a need to establish a mechanism to register such information. Pilots in the European RARE Community and the US PSI White Pages Pilot have based their information framework on the THORN and RARE Naming Architecture [Kil89c ]. It is proposed to use this architecture for the Internet Pilot, in conjunction with COSINE based piloting in Europe. A revised version of the Naming Architecture will be produced, with a mechanism for registration of new attributes and object classes [KB90 ]. Kille Page 1 INTERNET--DRAFT Building an Internet Directory November 1990 3 Use on the Internet It is desirable to decouple deployment of the OSI Directory from deployment of the OSI lower layers. This pilot will not make any mandatory requirements about use of lower layers. When configuring the pilot, variations in the lower layers must be considered. The following options are possible: o Use of OSI Network Service (Connection Oriented or Connectionless). It is seen as fundamental to allow use of the OSI lower layers. o Operation over TCP/IP using RFC 1006 [RC87 ]. This is a practical requirement of deployment at very many Internet sites, and is the basis of the existing pilot. o X.25(80) will probably not be used in the infrastructure of the Internet Pilot, but is the basis of some European activities. There will be a practical need to interwork with DSAs which only support this stack. This approach has the following implications. 1. There is a need to represent TCP/IP addresses within OSI Network Addresses. An Internet Draft, based on a paper by Kille, should be taken as a starting point for this [Kil89a ]. It will be necessary to have in Internet Standard on this area. 2. It will be desirable to have a uniform method to present Network Addresses of this style. Therefore a string representation should be developed in parallel. The Internet Draft, based on a paper by Kille, should be used as a basis for this [Kil89b ]. 3. This choice leads to the situation where not all DSAs can communicate directly due the different choice of lower layers. This is already a practical result of many European sites operating DSAs over X.25. There may be a requirement to extend the distributed operations, so that there is no requirement for full connectivity. This issue will be dealt with in the documents to be generated according to Section 4. 4. When the pilot is deployed, the issue of which DSAs operate which stacks must be considered in order to achieve a coherent service. Kille Page 2 INTERNET--DRAFT Building an Internet Directory November 1990 4 Replication of Knowledge and Data There are a number of requirements on replication, both of data and knowledge information, which must be met before an Internet Directory can be deployed. It is clear that the standard cannot be used as is. Three solutions were noted: o Wait until the 1992 standard is available o Attempt to intercept the 1992 standard, probably by specification of subset functionality based on the current working documents, and in particular the CD on replication [CCI90 ]. o Use an interim approach It is necessary to define the minimum requirements. This is specified in a separate INTERNET--DRAFT [Kil90a ]. The third approach will be taken initially. It will be clearly emphasised that this is an interim approach, which will be phased out as soon as the appropriate standards are available and stable. An interim approach, based on the approach used in the QUIPU Implementation and deployed in existing pilots will be used [Kil88 ]. These are being documented in an INTERNET--DRAFT [Kil90b ]. 5 Security A Directory and Security are closely related. There is no requirement for specification of any Internet specific approaches at this stage. Deployment of a directory could be based on one of: o Read only system, containing only public data and using local modification. o Use of X.509 authentication, and private access control mechanisms (this will not allow open access control management, but this is not seen as a fundamental problem) [CCI88a ]. A specification on security for the Internet Directory should be developed. This should specify: o Internet requirements for security in the Directory o A recommendation of how to use X.509 Kille Page 3 INTERNET--DRAFT Building an Internet Directory November 1990 o Recommendation on service requirements for access control, as a hint to implementors who attempt to intercept the 1992 standard or develop private mechanisms o A note on security issues (authentication, policy, access control) not being addressed by the standards work, which might require future work o Requirements and recommendations for implementors (e.g., in terms of maintaining data confidentiality within an Organisation) 6 Presentation of Directory Names The standard does not specify a means to present directory names to the user. This is seen as a serious deficiency, and a standard for presenting directory names should be developed. The ``User Friendly Name'' specification by Kille should be submitted as an Internet Draft, as a starting point for this work [Kil90c ]. 7 Name Allocation When the directory is deployed, there will be a need to allocate the top levels of the DIT. Most aspects will need to be tackled on a national basis. This group will consider name allocations at the top of the DIT, and will look at handling of the US part of the DIT. The major aim here will be to ensure that the Internet takes an, approach aligned to that of the NADF. 8 DSA Naming and MD Structure There are some critical issues related to naming of DSAs and the structure of Directory Management Domains. It is likely that there will need to be recommendations on how to handle this. 9 Relation to DNS It is important to establish the relationship between the proposed Internet Directory, and the existing Domain Name System. One input to this work should be the Internet Draft by Kille, to be updated before the meeting [Kil89d ]. Kille Page 4 INTERNET--DRAFT Building an Internet Directory November 1990 10 Documents and Timescales The following work is being undertaken following the boulder meeting Boulder IETF Meeting. Schema Revise Cosine and Internet Naming Architecture. P. Barker/S.E. Kille [KB90 ] Network Address Encoding Revise the Internet Draft [Kil89a ]. S.E. Kille. Address String Encoding Revise the Internet Draft [Kil89b ]. S.E. Kille. Replication Requirements Revise the Internet Draft [Kil90a ]. S.E Kille. Replication Solution Revise the Internet Draft [Kil90b ]. S.E. Kille. Security Revise the tabled paper and submit as an Internet Draft. P. Yee/B. Manning Directory Name Presentation Revise the Internet Draft [Kil90c ]. S.E. Kille. Relation to DNS (Domains and X.500) Revise the Internet Draft [Kil89d ]. S.E. Kille. The changes to this document were agreed at the Boulder meeting. It is expected to progress this document to RFC Status in January 1991. The remainder of the documents will be reviewed at the meeting at SRI in February. It is intended to release all of them as RFCs following this meeting. This will allow deployment of the Interenet Directory during 1991. References [CCI88a] The directory --- authentication framework, December 1988. CCITT Recommendation X.509. [CCI88b] The directory - overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations. [CCI90] The directory --- part 9 --- replication, October 1990. ISO/IEC CD 9594-9 Ottowa ouput. Kille Page 5 INTERNET--DRAFT Building an Internet Directory November 1990 [KB90] S.E. Kille and P. Barker. he cosine and internet x.500 naming architecture, November 1990. Internet Draft: draft-ietf-osids-cosinex500-00.txt. [Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5 Conference on Message Handling Systems and Distributed Applications, pages 173--186. North Holland Publishing, October 1988. [Kil89a] S.E. Kille. An interim approach to use of network addresses. Research Note RN/89/13, Department of Computer Science, University College London, February 1989. Internet Draft: draft-ucl-kille-networkaddresses-01.txt, ps. [Kil89b] S.E. Kille. A string encoding of presentation address. Research Note RN/89/14, Department of Computer Science, University College London, February 1989. Internet Draft: draft-ucl-kille-presentationaddress-01.txt, ps. [Kil89c] S.E. Kille. The THORN and RARE naming architecture. Technical report, Department of Computer Science, University College London, June 1989. THORN Report UCL-64 (version 2). [Kil89d] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College London, May 1989. Also Internet Draft: DRAFT-UCL-KILLE-X500DOMAINS-00.PS. [Kil90a] S.E. Kille. Replication requirement to provide an internet directory using X.500, November 1990. Internet Draft: draft-ietf-osids-replication-00.txt. [Kil90b] S.E. Kille. Replication requirement to provide an internet directory using X.500: A proposed solution, November 1990. Internet Draft: draft-ietf-osids-replsoln-00.txt, ps. [Kil90c] S.E. Kille. Using the osi directory to achieve user friendly naming. Research Note RN/90/29, Department of Computer Science, University College London, February 1990. Internet Draft: draft-ietf-osids-friendlynaming-00.txt, ps. [Lin89] J. Linn. Privacy Enhancement for Internet Electronic Mail: Part 1 --- Message Encipherment and Authentication Procedures. Request for Comments 1113, DDN Network Information Center, SRI International, August 1989. Kille Page 6 INTERNET--DRAFT Building an Internet Directory November 1990 [RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services on top of the TCP. Request for Comments 1006, DDN Network Information Center, SRI International, May 1987. 11 Security Considerations Security considerations are discussed in Section 5 of this INTERNET--DRAFT . 12 Author's Address Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Kille Page 7   Return-Path: Received: from brunel.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <2982-0@bells.cs.ucl.ac.uk>; Mon, 31 Dec 1990 10:32:12 +0000 Received: from Sirius.brunel.ac.uk by Echo.brunel.ac.uk with SMTP (PP) id <1943-0@Echo.brunel.ac.uk>; Mon, 31 Dec 1990 10:32:07 +0000 Subject: Books on X.400 and X.500 To: osi-ds@uk.ac.ucl.cs, directory-group@uk.ac.rutherford Date: Mon, 31 Dec 90 10:32:12 BST X-Mailer: ELM [version 2.2-hd PL 10] From: Andrew.Findlay@uk.ac.brunel Original-Sender: Andrew.Findlay@uk.ac.brunel I am occasionally asked to recommend a book on X.400 and X.500 that goes a bit beyond the single chapters normally found in general networking texts. I do not know of any such books. Can anyone suggest some? Thanks Andrew -- --------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk phone: +44 895 74000 x2512 | ---------------------------------------------------------------------   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 1 Jan 1991 15:07:54 +0000 Date: Tue, 1 Jan 1991 15:07:54 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.260:01.00.91.15.07.54] X400-Content-Type: P2-1984 (2) Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Tue, 1 Jan 1991 15:07:54 +0000) From: A.Macpherson@uk.co.stc.stl Sender: A.Macpherson@uk.co.stc.stl Message-ID: <"7779 Tue Jan 1 15:08:26 1991"@stl.stc.co.uk> To: Andrew.Findlay@uk.ac.brunel Cc: osi-ds@uk.ac.ucl.cs, directory-group@uk.ac.rutherford In-Reply-To: Subject: Re: Books on X.400 and X.500 Organisation: STC Technology, London Road, HARLOW, Essex England, CM17 9NA Phone: +44 279 429531 ext 2423 Telex: 81151 stl hw g Andrew.Findlay@brunel.ac.uk writes: | I am occasionally asked to recommend a book on X.400 and X.500 that | goes a bit beyond the single chapters normally found in general | networking texts. I do not know of any such books. Can anyone suggest | some? @book{nccX400:84, Author = Paul Chilton, title = "X.400: the messaging and interconnection medium for the future", publisher = "{NCC} Blackwell", year = 1990, series = "An {NCC} Management Report", address = {"NCC Blackwell Ltd, 108 Cowley Road, Oxford OX14 13F, England"} } I found this book well written and very clear on 84, It steers well clear of alphabet soup. The treatment of the 88 standards seems to reflect a publisher's deadline which is a great pity, as I think we are all hoping to skip straight past to 88. Paul Chilton has also written a volume "Introducing X.400" When I asked that question I was recommended "OSI explained". I found it extremely heavy going. One should avoid this volume until one has a considerable background familiarity with OSI acronyms. -- A.Macpherson@stl.stc.co.uk - or - Post@stl.stc.co.uk "Quot homines, tot sententiae"   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3404-0@bells.cs.ucl.ac.uk>; Thu, 3 Jan 1991 09:05:52 +0000 Return-Path: <@uk.ac.ukc,@se.sunet.sunic:gunnar@se.tvt.p.telerand> Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <2965-0@bells.cs.ucl.ac.uk>; Thu, 27 Dec 1990 16:33:08 +0000 Received: from sunic.sunet.se by kestrel.Ukc.AC.UK via EUnet with authorised SMTP id aa27328; 27 Dec 90 16:32 GMT Received: from telerand.p.tvt.se by sunic.sunet.se (5.61+IDA/KTH/LTH/1.168) id AAsunic18736; Thu, 27 Dec 90 17:32:19 +0100 Message-Id: <9012271632.AAsunic18736@sunic.sunet.se> To: osi-ds-request@uk.ac.ucl.cs Subject: Re: A proposal on Directory Quality of service Date: Thu, 27 Dec 1990 10:31:28 +0100 From: gunnar@se.tvt.p.telerand Original-Sender: gunnar@se.tvt.p.telerand Sender: gunnar Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Thu, 03 Jan 91 09:05:51 +0000 Resent-Message-ID: <455.662893551@UK.AC.UCL.CS> Resent-From: Steve Kille Sounds like a very good idea. Personally, I think a single attribute "SubtreeQuality" would be enough. There is a risk in allowing people to specify a MIN/MAX range because lazy managers may specify ranges so broad that they become meaningless (if they expect quality to inmprove). /Gunnar   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <8472-0@bells.cs.ucl.ac.uk>; Thu, 3 Jan 1991 15:56:13 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Updated Documents Phone: +44-71-380-7294 Date: Thu, 03 Jan 91 15:56:11 +0000 Message-ID: <1989.662918171@UK.AC.UCL.CS> From: Steve Kille Let me describe progress on the various documents: Text format - with some help form Ralph Droms, some progress is being made towards printable text versions of the documents. There is still a bit of a ways to go tho. I think that all apart from the nsap.txt will be better than the last round. Whatever, I'd strongly recommend postscript form (I have fixed a problem which affectfed some postscript printers). I've not checked them all, as our printer has run out of toner, and I'm going for a train..... Directions on getting all of the documents are in the appended index. Minutes - I have two pices from the two secretaries, which I will edit soon. Strategy - Updated version was circulated before christmas. I will submit this as an RFC at the end of the week. Scope of group - Document updated. I hope that this can now be put to bed. X.500 + Domains - I will update this following further study of the text vs binary encoidng issue. Presentation Address Syntax - no changes needed Naming Architecture - updated. Available as internet draft. The following documents have been updated. Noteworthy changes are indicated. Replication Requirements - updated Replication Solution - updated. Largest change is the modified protocol. User Friendly Naming - updated. Note extensions to the BNF Network Address Structure - updated Would those coming to Brussels please make sure to bring copies of the versions to be discussed. Steve INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 4) S.E. Kille December 22, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS minutes-1-oct90.txt 1st Meeting, San Jose, Oct 90 ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps Building and Internet Directory using X.500 S.E. Kille December 1990 Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille January 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-01.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. domain.ps domain.txt Domains and X.500 S.E. Kille Novmember 1990 Abstract: This INTERNET-DRAFT considers X.500 in relation to Internet/UK Do- mains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille January 1991 Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. repl-req.ps repl-req.txt Replication Requirement to provide an Internet Directory using X.500 S.E. Kille January 1991 Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90 ]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This INTERNET--DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. na.txt P. Barker S.E. Kille December 1990 The COSINE and Internet X.500 Naming Architecture draft-ietf-osids-cosinex500-01.txt Abstract: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is | a draft, and comments on the updating mechanisms are | particularly welcome. Corrections and additions to the | naming architecture should now be sent the list, as | described within. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . repl-sol.txt repl-sol.ps Replication to provide an Internet Directory using X.500 S.E. Kille January 1991 Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point. ------------------------------------------------------------------------   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1222-0@bells.cs.ucl.ac.uk>; Mon, 7 Jan 1991 07:48:33 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Mon, 7 Jan 1991 07:39:15 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 7 Jan 1991 07:39:46 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 7 Jan 1991 08:43:00 +0000 Date: Mon, 7 Jan 1991 07:39:15 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.958:07.00.91.07.39.46] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: Books on ... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"3959 Mon Jan 7 08:39:50 1991"@surver.surfnet.nl> To: Andrew.Findlay@uk.ac.brunel, osi-ds@uk.ac.ucl.cs Subject: RE: Books on X.400 and X.500 X-VMS-To: IN%"Andrew.Findlay@brunel.ac.uk" Comments: EARN/BITnet: HUIZER@HUTSUR51 Sender: HUIZER@nl.surfnet > I am occasionally asked to recommend a book on X.400 and X.500 that > goes a bit beyond the single chapters normally found in general > networking texts. I do not know of any such books. Can anyone suggest > some? The book I personally find very enlightning is: "Datenkommunikation und elektronische post", B.Plattner, G.Lanz, H. Lubich, M.Mueller, T. Walter. Addison-Wesley Publishing Company 1990. ISBN: 3-89319-166-6. Unfortunately you'll have to brush up on your German. I heard from one of the authors however that Addison Wesley is considering an English translation. Maybe Cuno Lanz, also on the osi-ds list can give you some info about this. Erik Huizer   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9228-0@bells.cs.ucl.ac.uk>; Mon, 7 Jan 1991 10:25:10 +0000 To: osi-ds@uk.ac.ucl.cs Subject: WG3 Agenda Phone: +44-71-380-7294 Date: Mon, 07 Jan 91 10:25:03 +0000 Message-ID: <508.663243903@UK.AC.UCL.CS> From: Steve Kille I'm sending this to the osi-ds list, as I gahter not all WG3 members are receiving mail on the administrative list. Steve ------- Forwarded Message From: HUIZER@nl.surfnet To: RARE-WG3@de.dbp.gmd.XPS Subject: WG3 revised agenda Date: Sat, 5 Jan 1991 03:25:22 +0100 Received: from HEARNVAX.nic.SURFnet.nl by DEARN (Mailer R2.07) with BSMTP id 6037; Fri, 04 Jan 91 16:58:26 CET Received: from SURVER.SURFNET.NL by HEARNVAX.nic.SURFnet.nl; Fri, 4 Jan 91 16:45 MET Received: from surfnet.nl by surver.surfnet.nl with SMTP (PP) id <1624-0@surver.surfnet.nl>; Fri, 4 Jan 1991 16:35:26 +0100 Date: Fri, 4 Jan 91 16:38 MET From: Erik.Huizer@SURFNET.NL Subject: WG3 revised agenda Sender: "Erik Huizer - SURFnet B.V. - Network Development" To: Rare WG3 , Steve Kille Message-id: X-Envelope-to: rare-wg3@xps.gmd.DBP.DE X-VMS-To: WG3 Comments: EARN/BITnet: HUIZER@HUTSUR51 I got some info from Steve which leeds to a slight change of agenda for the DS part. Place of meeting: Room S10 Berlaymont Building (That's one of those soundproof interrogation rooms in the cellar of the Main CEC building, the one direct beside the Underground Station Schumann. DS people notice that Steve has gathered an enormous amount of writing for you to read BEFORE the meeting. All of the Documents can be gotten from the UCL distribution service (see mail from Steve). I noticed that he has not had time yet to update all of the documents, but most are there. What I miss is the minutes from the last IETF OSI-DS meeting in Boulder, and the latest version of Rob Hagens RFC on 987 data in DNS. Please get the rest of the Docs and come prepared. See you in Brussels. Erik ___________________________________________________________________________ Agenda for WG3 meeting Brussels januari 1990. Place to be determined. =============================================================== 8 jan Tuesday ------ 14:00 Start of Directories meeting Agree agenda Minutes and matters arising from the minutes (minutes have been distributed by Peter) Cosine P2.1 project (Presentation byDave Goodman) -What can WG3 do in the Cosine P2.1 project (Chris D. and everyone) - meetings - standing documents - naming architecture (revised document by Steve and P. Barker: "The COSINE and Internet X.500 Naming Architecture") - CONS versus CLNS in P2.1 - Liason with other projects (WPP/AARN) The IETF OSI-DS group (presentation on the progress of this group Steve K.) [I suggest the following format for this: The subjects mentioned below will be first presented by Steve, after which we discuss them where necessary): discussed when necessary) -draft: Building an Internet Directory using X.500 (read it!) -draft: Replication Requirement to provide an Internet Directory using X.500 (read it!) -Document: Domains and X.500 (latest version should be available shortly) 17:30 We give Steve a chance to get his voice back behind a Pinta - Brakspears (Steve, I'll buy you this one :-) 9 Jan Wednesday ------ 09:00 The use of X.500 and DNS for 987 data. (Strongly related to the Domains and X.500 item. There is a interesting paper on this subject by CSATA, Italy, presented at the last IFIP WG6.5 meeting in Zurich, I'll try to get hold of an electronic version for distribution.) I hope to get Rob Hagens paper on this before tuesday. Security (can we provide some input for WG8) The IXI listing and the use of X.500 (Christian and Steve have some ideas about this.) It is burried in Steve's draft "Domains and X.500" 10:00 Coffee if any, and demonstrations. Ignacio will demonstrate the VMS DUA (Ignacio?) Other suggestions are welcome. 09 Jan Still the same day that is. - ------- 11:00 Start of plenary session. matters arising from minutes WG3 workplan report from the REC/WGC meeting (Jill F. and Chris D.) report from Chris D. on the general status of the Cosine projects Mailing lists status WG3 publicity (a.o. Blois) Eastern European representatives AOB Date and place next meeting (april 16-18, 1990) 13:00 Time for food and more Demo's 09 Jan Still the same day ------- 2:00 WG3 Info Services Subgroup Meeting (if necessary due to time constraints the DS group will continue in parallel with the Info services group) 5:30 End of business for day 10 Jan (Thursday that is) ------- 9:00 WG3 Info Services Subgroup Meeting 12:30 Close of meeting I include the mail from Jill Foster on the agenda for the Info services subgroup: ___________________________________________________________________________ Info. Services Subgroup Agenda items: ------------------------------------ 0. Agreement on agenda and welcome representative from EUROMATH (as the Danish representative). 1. Minutes of last meeting 2. Matters arising not covered below 3. EIS-Project: Status Report (Chris Duxbury) Monitoring of the Pilot Project by WG3 4. EIS-Project: a presentation by the contractor (well we can hope!) 5. International User Group Support: COSINE P3 Activity Plan and Status report: Chris Duxbury Supporting paper on IUGP Feedback from the COSINE User Forum: Jill Foster 6. Liaison: with national information services/ user support groups Information on services provided (the questionnaire!) 7. Liaison: with North American information services/ user support groups 8. Short report on EUROMATH. 9. Status of National Activities (all) and EARNInfo (Dominique Dumas) 10. AOB 11. Dates and format of next meeting Please update a status report on your national networking information and user group support initiatives, and circulate it by electronic mail at least one week before the meeting. These status reports will be used as the basis of the on-line information which will be made available to anyone who wishes to access it (initially from Switch, but eventually from the EIS). I would also like you all to bring some examples of your national network documentation: posters, newsletters, initial user help documents etc. I believe we've made some very good progress during 1990. Here's to improved collaboration during 1991. Jill ___________________________________________________________________________ Any additional agenda items can be suggested to either Jill or me, See you there, Erik ------- End of Forwarded Message   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3229-0@bells.cs.ucl.ac.uk>; Mon, 7 Jan 1991 16:14:00 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Updated overall strategy document Phone: +44-71-380-7294 Date: Mon, 07 Jan 91 16:13:59 +0000 Message-ID: <2623.663264839@UK.AC.UCL.CS> From: Steve Kille I received no comments on the draft I circulated to this list. I have made a few small editorial changes to the version I distributed to the list. The final version is in the usual place (text (readable!) and postscript versions). I am submitting this as an RFC, and I hope that this will be released very shortly. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6891-0@bells.cs.ucl.ac.uk>; Mon, 7 Jan 1991 16:35:58 +0000 To: hagens@edu.wisc.cs cc: callon@com.dec.enet.bigfut, osi-ds@uk.ac.ucl.cs Subject: Re: need summary of X.500 Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 13 Dec 90 17:20:50 -0600. <9012132320.AA26097@janeb.cs.wisc.edu> Date: Mon, 07 Jan 91 16:35:49 +0000 Message-ID: <2684.663266149@UK.AC.UCL.CS> From: Steve Kille Rob/Ross, Let me try to answer your questions. I'm ccing the osi-ds list, as others might have very different views. My focus has been on 6-12 month timescales, with the broader goals not really stated. Definition of the broader goals should not just be left to one individual. However, I will start the ball rolling by giving my views of where this activity is leading in a four year timescale: a) A directory infrastructure used by all Internet members, which interworks with non-Internet X.500 services. It should be used for: - lookup of users and related white pages services such as commitee support - support of management of the internet infrastructure - support of all OSI Applications on the Internet - Support of Internet Security activities (X.519) Use of X.500 directory should be a mandatory requirement for all Internet sites. A transition plan from DNS to X.500 should be in place. This gives a scaling target of order of millions or tens of millions of entries. b) Where X.500 is now: A pilot which spans 13 countries, with about 400 organisations and 350 000 entries. Most usage is related to lookup of "people entries". c) Initial step is a full Internet X.500 pilot. A service will be evolved from the pilot, based on experience. There are two thrusts. The first is technical, and being undertaken by the WG. This will give the specification needed to build an effective open pilot. The second is operational, and is based on the PSI activities and the FOX project. Steve >From: hagens@edu.wisc.cs >To: S.Kille@uk.ac.ucl.cs >Steve, Ross and I are putting together an OSI area plan. This is due >wednesday. Could you send me a brief summary of > a) where you want X.500 to be in 4 years > b) where it is today (pilots, etc) > c) how to get there (major steps, etc) >I think alot of this is already written in your charter/other drafts. >I need it in ascii. >Thanks, >Rob & Ross (looking over my shoulder)   Return-Path: Received: from CCV1.BBN.com by bells.cs.ucl.ac.uk with SMTP inbound id <28440-0@bells.cs.ucl.ac.uk>; Tue, 8 Jan 1991 15:16:04 +0000 To: Steve Kille cc: hagens@edu.wisc.cs, callon@com.dec.enet.bigfut, osi-ds@uk.ac.ucl.cs, crocker@com.tis Subject: Re: need summary of X.500 In-reply-to: Your message of Mon, 07 Jan 91 16:35:49 +0000. <2684.663266149@UK.AC.UCL.CS> X-Zippy: Remember, in 2039, MOUSSE & PASTA will be available ONLY by prescription!! Date: Tue, 08 Jan 91 10:15:44 -0500 From: Ken Rossen Steve, Rob, Ross, A minor correction to Steve's contribution to the OSI area plan: Steve's answer to (a) ("What should Internet X.500 be in 4 years") .... a) A directory infrastructure used by all Internet members, which interworks with non-Internet X.500 services. It should be used for: - lookup of users and related white pages services such as commitee support - support of management of the internet infrastructure - support of all OSI Applications on the Internet - Support of Internet Security activities (X.519) .... was generally fine. However, the fourth bullet: - Should say X.509 (not X.519) - Could say "access to public-key certificates (per X.509) in support of Internet security activities" if you wish to be more specific, but is okay as is. -- KENR@BBN.COM   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22625-0@bells.cs.ucl.ac.uk>; Thu, 10 Jan 1991 14:52:04 +0000 To: osi-ds@uk.ac.ucl.cs, Megan Davies Subject: Minutes Phone: +44-71-380-7294 Date: Thu, 10 Jan 91 14:52:00 +0000 Message-ID: <3024.663519120@UK.AC.UCL.CS> From: Steve Kille Deleted...   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22596-0@bells.cs.ucl.ac.uk>; Thu, 10 Jan 1991 14:51:28 +0000 To: osi-ds@uk.ac.ucl.cs cc: Megan Davies Subject: Draft minutes of the Boulder meeting Phone: +44-71-380-7294 Date: Thu, 10 Jan 91 14:51:27 +0000 Message-ID: <3017.663519087@UK.AC.UCL.CS> From: Steve Kille Thanks to Richard Colella and Peter Whittaker for their good work here. Draft minutes follow in the next message (postscript only). I will revise on the basis of comments. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11870-0@bells.cs.ucl.ac.uk>; Fri, 11 Jan 1991 11:52:57 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Text Versions Phone: +44-71-380-7294 Date: Fri, 11 Jan 91 11:52:53 +0000 Message-ID: <1279.663594773@UK.AC.UCL.CS> From: Steve Kille Thanks to Ralph Droms, I can now produce decent text versions of my documents. I've installed new versions of the text forms of UFN, Network Address, and Presentation Address documents at UCL. There are no other changes. I'll send a text version of the DRAFT minutes in the next message. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11898-0@bells.cs.ucl.ac.uk>; Fri, 11 Jan 1991 11:53:29 +0000 To: osi-ds@uk.ac.ucl.cs, Megan Davies Subject: Text version of the draft minute Phone: +44-71-380-7294 Date: Fri, 11 Jan 91 11:53:28 +0000 Message-ID: <1285.663594808@UK.AC.UCL.CS> From: Steve Kille Minutes of the Second IETF Directory Services (OSI-DS) Working Group December 3-4, 1990 Boulder, Colorado Richard Colella Peter Whittaker Steve Kille NIST BNR UCL January 11, 1991 1 1 Attendees S.K. Steve Kille UCL s.kille@cs.ucl.ac.uk MTR Marshall Rose PSI mrose@psi.com R.C. Ross Callon DEC callon@bigfut.enet.dec.com P.M. Peter Mierswa DEC mierswa@smaug.enet.dec.com D.O. David Oran DEC oran@oran.enet.dec.com H.J. Harold Jones DEC hjones@nac.dec.com L.C. Lida Carrier Apple lida@apple.com M.M. Marilyn Martin UBC martin@netcom.ubc.ca K.A. Karl Auerbach Sun karl@eng.sun.com G.M. Greg Minshall Novell minshall@wc.novell.com D.M. Dan Molinelli TRW moline@trw.com P.Y. Peter Yee NASA yee@ames.arc.nasa.gov P.K. Paul Koski H/P koski@hpindeg.cup.hp.com R.W. Russ Wright LBL wright@lbl.gov DPZ David Paul Zimmerman Rutgers dpz@dimncs.rutgers.edu M.G. Martin Gross DCS gross@polaris.dca.hil RCo Richard Colella NIST collela@osi3.ncsl.nist.gov PVM Paul Mockapetris DARPA pvm@darpa.mil J.H. Juha Heinanen FUNET jh@funet.fi J.M. Jim Mostek Cray Research mostek@cray.com T.S. Theresa Senn Cray Research tcs@cray.com PWW Peter Whittaker BNR pww@bnr.ca I.H. Ian Hamilton BNR ianh@bnr.ca YBW You-Bong Weon-Youn ATT youbong@arch2.att.com H.S. Harvey Shapiro Nardac shapiro@wnyase.nardac-dc.navy.mil C.C. Curtis Cox Nardac ccox@wnyosi.nardac-dc.navy.mil J.M. Judy Messing Mitre messing@gateway.mitre.com G.G. Gita Gopal Bellcore gita@bellcore.com SYW Sze-Ying Wuu Bellcore sywuu@thumper.bellcore.com K.S. Karen Sollins MIT sollins@lcs.mit.edu D.B. Dave Brent CDNNet brent@cdnnet.ca JGL Jose Garcia Luna SRI garcia@sri.com M.K. Mark Knopper Merit mak@merit.edu D.W. Dan Wintringham -- danw@oar.net T.E. Tom Easterday Ohio State tom@nisca.acc.ohio-state.edu V.C. Vinton Cerf NRI vcerf@nri.reston.va.us A.H. Alf Hansen UofWisconsin alf.hansen@pilot.cs.wisc.edu K.F. Karen Frisa CMU karen.frisa@andrew.cmu.edu L.W. Linda Winkler -- b32357@anlvm.ctd.anl.gov 2 2 Introduction The meeting was opened by the Chair, Steve Kille (UCL). Introductions were made and minute-takers were solicited. The proposed agenda was approved and the meeting proceeded accordingly. 2.1 Minutes of Previous Meeting The minutes of the San Jose meeting were approved with minor changes. 2.2 Matters Arising 2.2.1 Document Distribution A number of attendees had problems with document distribution. These fell into four categories: o ASCII documents were formatted for A4 size paper, which is inconvenient for those in the U.S. o the ASCII versions of the documents were somewhat idiosyncratic in format -- Steve pointed out that the primary form of documents he generates is PostScript and was not intending to spend significant amounts of time reworking the ASCII versions, o a number of people could not print the PostScript versions of the papers retrieved from NRI -- Steve said that this problem was easily correctable and would take care of it, and, o a few people remarked about late distribution of documents and a consequent lack of time to obtain and review them prior to the meeting. 2.2.2 Statement of Objectives/Scope/History Steve spent a few minutes reviewing the objectives, scope, and history of the group for those who were not at San Jose. He emphasised that the DSWG was chartered to develop a technical 3 framework for an X.500 deployment, but was not intent on being the instrument for deployment. 2.2.3 Introduction of Documents Steve briefly introduced each of the documents that were input to the meeting: o Replication Requirement to Provide an Internet Directory Using X.500. S.E.Kille. o Replication to provide an Internet Directory using X.500: A Proposed Solution. S.E.Kille. o IETF Directory Working Group Scope (Version 3). S.E.Kille. o The COSINE and Internet X.500 Naming Architecture. P.Barker and S.E.Kille. o Building an Internet Directory using X.500. S.E.Kille. o An Interim Approach to use of Network Addresses. S.E.Kille. o A String Encoding of Presentation Addresses. S.E.Kille. o Using the OSI Directory to achieve User Friendly Naming. S.E.Kille. 3 Liaisons 3.1 NADF -- Marshall Rose (PSI) The North American Directory Forum is a consortium of service providers and potential service providers of public X.400 and X.500 services. The NADF has as its focus the North American market. However, they realise the need for international connections, possibly through multi-lateral agreements. Their raison d'etre is to figure out how to share proprietary information, required to provide a seamless service, without compromising their business interests. The NADF has had four meetings to date. Their next meeting is in March, 1991. Stable technical proposals addressing some of the NADF members' concerns will probably be made in March, but the 4 consensus process makes actual timeliness for agreements uncertain. The primary contact for the NADF is Don Casey (Western Union). To provide continuity, a standing chair, Ted Meyer (Rapport), has been retained. 3.2 OIW Dir SIG -- You-Bong Weon-Yoon (ATT) The OSI Implementors' Workshop (OIW) produces multi-vendor agreements based on OSI standards. The Directory Special Interest Group (Dir SIG) produces agreements on the X.500/ISO 9594 standard. Current work in the SIG is in developing international standard profiles (ISPs) through coordination with the two other regional OSI workshops, EWOS in Europe and AOW in the Pacific rim area. Beginning in the December, 1990 meeting, the SIG will begin developing multi-vendor implementation agreements on replication, access control, and distributed operations (the latter will be coordinated with the OSINET work on interoperability test development). 3.3 RARE WG3 -- Steve Kille (UCL) RARE WG3 has two subgroups of interest: a user information area and a group working on directories. The Directory group has an analogous function in Europe to this WG of the IETF. The next meeting of RARE WG3 is January 17-18 in Brussels. 3.4 ISO/CCITT Meeting in Ottawa -- Steve Kille (UCL) Steve summarised the current work in Directory standardisation as it stood after the Ottawa meeting. The main areas of interest were in: o extensions to the information model in the areas of schema (e.g., publication) and operational attributes (i.e., those associated with a subtree, such as access control defaults), o abstract services -- e.g., paged results (does not deal with collating), o matching rules -- will be user-extensible, rather more formally defined than today, and bound to attribute syntax, 5 o replication -- now a CD (Committee Draft -- what used to be a DP); defines incremental shadowing, among other paradigms, o distributed entries -- large and complex document, not well organized and difficult to comprehend. CCITT is intent on seeing this in 1992, but it is not believed to even be a Work Item in IEC, o short-form names -- some support is expected in 1992, though not necessarily a good technical solution, o migration from '88 to '92 X.500 -- a document is available on this, o access control -- work is progressing, but the editor recently resigned. A new editor has taken over and the access control documents have been reissued on a second PDAM ballot (Proposed Draft Amendment -- used to be PDAD). 4 PSI White Pages Pilot Presentation -- Marshall Rose (PSI) Information is available as PSI TR 90-05-10-1 and PSI TR 90-09-10-1 from info@psi.com. Marshall provided an overview of the PSI WP Pilot. As a digression, he described an alternative name registration scheme based on the existing civilian naming infrastructure for states, counties, cites, etc. Some questions remain. This will likely come onto the agenda at the next meeting. 5 FOX -- Paul Mockapetris (DARPA) Paul briefly discussed the Field Operational X.500 (FOX) project that DARPA is funding. It is based on a pair of meetings that occurred two years ago which resulted in RFC 1107. There are four participants: o ISI -- main contractor and responsible for project oversight, o NYSERNet/PSI, o Merit, and, o SRI. 6 The objectives are twofold: 1) get X.500 closer to operational status, and, 2) demonstrate interoperability among multiple X.500 implementations. SRI will use the NIST implementation and investigate supporting some of their traditional roles, such as registration. Merit is considering using X.500 to publish network numbers. PSI will be cooperating in interoperability testing with the NIST implementation and another implementation (as yet undecided). 6 Cosine Pilot Directory Service -- Steve Kille (UCL) The slides of this talk are available from UCL. Mail to info-server@cs.ucl.ac.uk. 7 Scope of Group and Review of Charter Fundamentally, there were no significant disagreements about what the scope and charter documents say. There were two specific decisions made: o the scope should specifically state that the aim of the group is to align with the base standards and profiles on the extensions when these become available, and, o the charter will be collapsed into the scope document. 8 Infrastructure Strategy The document Building an Internet Directory Using X.500 was discussed. The substance of the discussions was: o the document needs a caveat that this approach will not necessarily address everyone's X.500 needs, o need to address the issue of name allocation at the top levels of the naming tree, o need to do a better job of naming DSAs, rather than just having them named high up in the tree (which is awkward), o under the section on replication of knowledge and data, add that an intercept strategy could be defined by others (e.g., the OIW Dir SIG), not necessarily by this WG, 7 o in Section 3.3, the sentence that begins, ``There is a requirement to extend...'' will be amended to read, ``There may be a requirement to extend...'' There was general agreement on the contents of the document and folks felt that it should move forward. Steve proposed that the target should be to have it become an RFC in one to six months. 9 Replication Requirements and Scheme A number of issues arose during the discussion of replication: o lower-layer stacks -- combinations of LL stacks should be allowed even thought this results in less-than full interconnectivity of DSAs. However, guidance should be given on the desirability of having increasingly richer connectivity as one moves higher up in the tree; o remove Section 3 of requirements document -- this is either a trivial or intractable problem; in either case, no statement is needed o Section 5 of requirements -- there was some confusion about what this section meant. Steve agreed to rewrite it in words similar to those he used in explaining it; o Section 6 of requirements -- the new scaling target will be 100,000 non-leaf entries, given that this is at least an order of magnitude greater than what we think is really required; o replication approach -- after some discussion of the appropriate approach to take to replication --- a non-standard scheme such as that in QUIPU, an intercept strategy, or wait for the standard. The general discussion was inconclusive. A subgroup, consisting of those most active in the overall disucssions was formed (DO, PM, PK, GM, SK) to look at the problems, and in particular the issues of migration. The consensus of the off-line discussion was that the best approach, all things considered, was to use a scheme based on that described in the replication proposed solution document. This was agreed to by the rest of the WG. Also agreed was that a replication scheme based on the standards work will be adopted when available. The interim nature of the solution should be emphasised. It was noted that DUA/DSA interaction is not affected. 8 10 Domains and X.500 There was some discussion on how to represent domain names (i.e., the attributes) in the X.500 DIT: octet strings or IA5 strings. There seemed to be some confusion about what the implications of this are. Steve said that he would talk to Paul Mockapetris off-line and figure out what the issues really are. There was some lengthy discussion on the utility of storing DNS information in the DIT. Steve agreed to make the minor changes to the document suggested by the discussion. Otherwise, he will progress the document as an RFC pretty much as is. 11 Day 2 Gita Gopal of Bellcore gave a presentation on a Bellcore research project studying methods of providing support for distributed entries in a heterogeneous multi-server, multi-protocol, multi-media, multi-context environment. The Bellcore method is based on a central LDB, or Linking Data Base, which contains one entry per person keyed on a unique PID (personal identifier). Each entry contains references to all known DBs holding information about the particular individual, as well as the protocol information necessary to access those databases (i.e. J. Foobar, Widget Inc, X.500 DSA, RFC1006 address, etc...). The chief goal of this project is to allow users to access any and all information about individuals maintained by various DBs using only information from a particular DB. For example, given a DN for a person's business entry (i.e. an organizationalPerson), a user would be able to send mail to that person's home by telling a UA to check the LDB and use the business DN to find a residential OR address. The use of aliases in an X.500 DIB was suggested as an alternative method of achieving the same results, but was rejected as being inapplicable to distributed entries. The LDB solves the distributed entry problem by considering the person as the essential element rather then focusing on the entries themselves. Contexts are supported using a dynamic schema. Users are expected to have some knowledge of the context from which they are searching (the example of having to know what a telephone number is, and what 9 equipment it can be used with, before being able to make use of it, was raised as analogous to the LDB scheme). There are several outstanding issues that require further research: the LDB only links entries for people - certain simplifying assumptions have been made based on this - the capability for handling the more complex interactions and interlinkages that might arise when linking information about machines, applications, or organizations; security has not been thoroughly explored, nor have access controls; the "publishability" of PIDs needs further investigation - are these to be used exclusively as internal pointers, or has more general "personal access (i.e. phone) numbers"?; management and generation of unique PIDs, and the administrative problems involved. 12 User Friendly Naming Discussion then turned to Steve Kille's paper on User Friendly Naming. The goals of this paper are the provision of: an improved method of transmitting names, and better handling of purported name lookup. The Result Of The Discussion Was That Steve Would Revise The Paper To Reflect The Issues And Concerns Raised By The Wg, And Present It Again At The Next Meeting. Among the issues raised were: tuning the algorithm to handle changes in DNs; at the moment, a change to a previously resolved DN makes that earlier resolution useless (the user would have to go through the process of resolving a purported name each time a DN changed). the addition of "yet another" syntax, and the related issue of other work in the field, specifically the OSF work. It was decided that the paper would reference and track the OSF work. Yew-Bong referred to the work Al Grimstad of Bellcore, which was submitted to CCITT SG VII as a corporate position on User Friendly Naming. Current SG work should also be tracked. The X.500 SG is unlikely to provide a standard until 1996: should this method be submitted for SG VII consideration? Moving from one machine to another: is it reasonable to expect the same syntax to work under different architectures (i.e. VM and Unix, where, for example, the meaning of `"' to the command line 10 interpreter is vastly different (quote on Unix, escape character on VM). The related issue of allowing a user to "tune" their environment: different machines (under the control of different organizations) might have different "correct" behaviour. User customisation might hide or expose these differences, and make searching more difficult. Vinton Cerf and Peter Mierswa suggested that User Friendly Names are inappropriate as an "exchange format": only DNs should be relied upon, and communicated between users. In addition, V.C. suggested that "guessability" was less important than exactness. Paul Mockapetris raised the question of the "Monte Carlo" method of name resolution: users guess at a name and receive a list of possibilities; they continue guessing until they get the DN they want or need. The user interface should allow this behaviour. The current model does not handle deep DITs very well; more work is needed in this area. It would help if the top two or three levels had "non-obscure" names. wild card searches (especially leading wild cards) need further investigation. multiple occurrences of the same string in a DN (i.e. as both a county and a city) must be underlined to the user. DNs should always be returned when resolved - should users be able to build dependencies on purported names? care must be taken when stripping RDNs for "displayability". 13 Replication Solutions Steve introduced this section by noting that several documents bear directly on this subject, notably the proposed RFCs on Presentation Address Representation and Network Address Representation. It was decided that these would be dealt with first. 13.1 Network Addressing Steve's summary of the problem, and the solution offered in his paper: If you look at an OSI address from a DIT, you get a presentation address, which works fine with an OSI network service, but does not work with RFC1006 or X.25( 80) addresses, owing to the lack of an OSI network server for these address formats. This document 11 provides a method, using Telex addresses, to map non-OSI addresses onto OSI addresses. It is ugly, but it is functional, and requires no extensions to current protocol. The OSF Towers solution allows you slice different protocols in and out at any particular layer, allowing you a choice of transport and network addresses. It is a better and more elegant solution, but it requires extension to X.500(88). This is unacceptable, in my view. Ideally, I would like to push OSI/CCITT into adopting OSF Towers for 1992; we could move to it at that time. Until then, however, we would be better off going with an interim solution that does not require protocol extensions, but that allows full inter-connectivity. After a brief discussion to clarify the reasons for adopting this method over the Towers method, it was agreed that this would be accepted as the OSI-DS WG official recommendation on network addressing, but that it would be explicitly noted as an interim solution only. Among the concerns raised were: OSF Towers and this method are both "hacks", the former as it requires extensions, the latter as it uses the UCL Telex number as the basis of network addresses. Steve's method is less of a hack, though. This method does not guarantee 100% success: if a DUA cannot interpret the Telex number, then it will not be able to contact the specified entity. Steve admits that this method does not give 100% success, but since it uses current protocols rather than extensions, it will offer a better success rate than Towers. 13.2 Presentation Addresses Steve: this document must be taken in concurrence with the Network Addressing document: it provides for better handling of dotted decimal encodings, and provides an extension to presentation address handling (`/' changed to `+') to bring our work in line with ISO 8348 (X.213). P.M. This is an extension to the standard? S.K. Yes. 12 G.M. Is there a need to represent a presentation address that specifies an IP address that is not an RFC1006 address? S.K. I hope not, but we need to be able to specify IP addresses that are not on the Internet, such as local LANs. After minimal discussion, it was agreed that this document should proceed in parallel with the Network Addressing paper. 13.3 Replication Solutions Steve provided an overview of the current proposal: Sec. 1: Benefits of the approach: it has been proven in operation; owing to its current use, there will be minimal effort involved in moving to it as a pilot standard; the approach is simpler and easier to implement than the current standards approach. Sec. 2 Enhancement of Distributed Operations to provide better handling of referrals and chaining (an extension to the standard). This approach is closely tied to the previously reviewed papers on network and presentation addresses. It uses the concept of a "community" (coded into the presentation address) to allow a D SA to decide if a DUA and another DSA can in fact communicate directly. Sec. 3 Extend the semantics of X.500 so that DSAs can deal more intelligently with Subordinate, Cross, and Non-Specific Subordinate, References. Sec. 4 The replication data model: replication of all sibling entries rather than subtrees, or specific entries. Sec. 5 Improved DSA naming: placing DSA names in a well known DSA with root knowledge; placing DSA names in the higher (closer to the root) portions of the DIT. Sec. 6 Definitions of objects necessary to represent knowledge information in the DIT (rather than having DSAs maintain it as a "local matter"). Sec.7 Definition of a simple replication protocol: data propagation in a star-like fashion. Sec.8 Definition of the "Internet DSP" Application Context to allow 13 for easier identification of Internet extensions. Sec. 9 Scaling limits and migration strategy. Sec. 10 Reserved for future definitions of application contexts, object classes, and attributes necessary for replication The Result Of The Discussion Was That Steve Would Revise The Paper To Reflect The Issues And Concerns Raised By The Wg, And Present It Again At The Next Meeting. In addition, Steve introduced the ASN.1 required to allow QUIPU to transfers replicated EDBs in pieces, rather than single units. This extension will be available in the next release. Steve also suggested that it would be appropriate to write a paper on how to structure the DIT to achieve high performance and high reliability using current replication methodologies. He took this as an action item for himself. This document could then be put forward as a statement of administrative guidelines on DSA naming, and DIT structure. Issues raised: scaling: the paper quotes 10000 units as the upper level of scalability. Steve noted that this refers to fan-out, not number of entries, as the unit of replication is a single level, and not an entry or subtree. Steve also noted that QUIPU would be extended to allow incremental updates of replicated data using an MHS. Since the master DSA would always be reachable, there would be no problem in using MHS to transfer EDBs while using replicated data to lookup the appropriate MHS address. DSA-DUA communities. The paper as presented did not properly described how a DS A decides whether or not a DUA and another DSA can communicate directly. Steve indicated that he would rephrase Section 2 to reflect the fact that PSAP communities are used to make this decision, not actual physical connections. V.C. asked whether access controls were replicated. Steve answered that private agreements must be used to maintain ACLs on replicated data, and that an open environment would be publicly readable. ACs are stripped during replication as they are a private matter: only published schema get transferred. P.M. questioned the Section 3 use of NSSRs: the changing of NSSR semantics from AND to OR would mean that multiple DSAs could not hold different "chunks" of superior entries. Steve indicated that 14 he would place a clear warning about this in the document. Expiry dates on information. Two separate issues were identified: caching and replication. It was determined that caching requires a TTL mechanism, but that replication can use a simpler approach, such as having a slave make regular "pulls" from the master. P.M. noted that applications must be built to expect stale data (X.500 makes no guarantees about data freshness), and that obtaining authoritative data is an application problem. It was decided that the unit of replication would be delivered with an advisory refresh date. 14 Naming Architecture Registration Steve: In order to build useful applications, we need to extend the Naming Architecture as supplied in the standard. This paper describes the formal administrative support for the creation of new elements in the architecture. The aim of this session is to discuss and define the registration and maintenance methodologies (currently UCL maintains pilot architecture for both the Internet and COSINE). UCL would maintain ownership of this document until the end of the COSINE project in December of 1992. It is hoped that this work will have been incorporated by the standards bodies by that time. The document defines an arbitration method for deciding what does and does not become part of the naming architecture: the editor has discretionary powers to include, exclude, or modify, as needed, subject to appeals to the OSI-DS WG mailing list, or arbitration from RARE and the OSI-DS WG. After a brief discussion, it was agreed that this document could be issued (with minor revisions) as the first RFC of the DS series, and that it would be updated every 3-6 months. Issues raised: Size of entries in a DIT: concern focused primarily on the size of the photo attribute. After some discussion, Steve indicated that he would reword the document to indicate that participating DSAs can store entries at their discretion, but that if they choose to store entries of a given type, they must agree to store the published attribute maximum sizes. PWW, MK, and ?? mentioned concerns with certain object classes and attribute types listed in the paper. After gentle chiding from SK, they agreed to test the procedure by submitting complete ASN.1 proformas for the additions they were concerned with. 15 Steve indicated that he would make an arbitrary decision whether or not to include the appendices Unix shells for Naming Architecture Maintenance. They were considered useful, but not for everyone. 15 Security Considerations Peter Yee: this paper identifies some of the security issues that must be addressed when planning a security policy for the Internet pilot. Steve Kille: We must distinguish between X.500 as a user and as a provider of security for the pilot. As a provider, we can use X.509 in a very straightforward fashion. As a user of security services, we have a more interesting issue. Unlike replication, we can work entirely within the standards. We need to prepare notes identifying the organizational issues involved, and documenting methods addressing these issues. There are three main areas of concern: authentication, access control, and remot e updates. After considerable discussion, it was agreed that Peter Yee should revise and re submit his document for consideration at the next meeting. Steve Kille asked for volunteers to do the "voluminous legwork" required to research and resolve the open items in this area, but there were no volunteers. Issues raised: Remote management. There was considerable disagreement over the issue of simple authentication as adequate security for remote management. PEM representatatives and proponents of strong authentication felt that simple authentication was not appropriate, as it would be too easy for an outsider to remove or modify certificates, or keys. One proposed solution that was partially acceptable is the requirement that DSAs be able to store X.509 information (certificate lists, public and private keys, certificates), and that DSAs using simple authentication or no authentication would not allow remote updates. Searchability. Several participants indicated that without some form of access control, they would not open their DSAs to the Internet, as they did not want to allow "DSA dumping". It was generally accepted that authentication (simple or strong) or 16 "skinny pipes" on searches would be acceptable. Steve Kille has since proposed a method of limiting searches and lists to the OSI-DS WG mailing list. Applications that require X.509. There was some debate over whether or not the number of applications requiring strong authentication would actually increase if it were provided. More research is needed, as this is a "chicken or egg" situation: do the applications cry out for X.509, or does X.509 invite new applications? The relationship between the OSI-DS WG and RSADSI/PKP. It was suggested that perhaps the IETF or the IAB could negotiate an Internet wide RSA licence with the relevant bodies. More liason work and research is needed. 16 Next Meeting SRI offered to host the next meeting in California, Feb. 12-13. Steve will issue a preliminary agenda in the near future. 17 AOB Standard APIs. It was agreed that the IETF should adopt a standard API for the pilot. X/OPEN and XDS were mentioned. This item will be discussed further at the next meeting. The Canadian X.500/Library Project. Dave Brent asked if the WG should look into this. Stev asked for volunteers to propose an RFC on the subject. This will be discussed at the next meeting. 17   Return-Path: Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <946-0@bells.cs.ucl.ac.uk>; Mon, 14 Jan 1991 15:19:33 +0000 To: gvaudre@us.VA.Reston.NRI cc: osi-ds@uk.ac.ucl.cs Subject: Minor changes to X.500 naming architecture Date: Mon, 14 Jan 91 15:19:29 +0000 From: Paul Barker A few (minor) changes have been made to the naming architecture document following the recent meeting of RARE WG3. The differences with the previous version are highlighted by change-bars. Paul ------------------------------------------------------------------- Network Working Group P. Barker INTERNET-DRAFT S.E. Kille University College London December 1990 The COSINE and Internet X.500 Naming Architecture Status of this Memo: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, and comments on the updating mechanisms are particularly welcome. Corrections and additions to the naming architecture should now be sent the list, as described within. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . Barker & Kille [page 1] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 1. Introduction Directory Services are a fundamental requirement of both human and computer communications' systems. Human users need to be able to look up various details about other people: for example, telephone numbers, facsimile numbers and paper mail addresses. Computing systems also need Directory Services for several purposes: for example, to support address look-ups for a variety of services, and to support user-friendly naming and distribution lists in electronic mail systems. Directory Services have recently been standardised and published as the 1988 CCITT X.500 / ISO IS9594 recommendations [1]. The standard provides a good basis for the provision of real services, and a considerable amount of Directory Service piloting activity is currently underway. In the U.S., the PSI White Pages Pilot [4] has stimulated use of X.500 on the Internet. In Britain, the U.K. Academic Community Directory Pilot [5] is similarly promoting use of X.500. 2. Motivation and aims of this document In a number of areas the X.500 standard only provides a basis for services. One such area is the Directory's Naming Architecture or Schema. The standard defines a number of useful object classes, in X.521, and attribute types, in X.520. These are intended to be generally useful across a range of directory applications. However, while these standard definitions are a useful starting point, they are insufficient as a basis for a large scale pilot directory. While it is possible for directory administrators to define their own sets of additional attribute types and object classes, this is undesirable for some common attributes and objects. The same objects and attribute types would be privately defined many times over. This would result in the directory's generality being diminished as remote systems would be unable to determine the semantics of these privately defined data types. A number of useful additions to the standard definitions were made in this note's forerunner, "The THORN and RARE Naming Architecture" [2]. These have been heavily used in early X.500 piloting activities. Furthermore, both the THORN and Quipu X.500 implementations have made use of these definitions. Barker & Kille [page 2] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 Since the afore-mentioned note was issued, a number of further requirements have come to light as the volume and variety of piloting activity has increased. Yet further requirements seem likely as the scale of X.500 pilot services increases. Thus, it is argued that it is not sufficient to merely reissue an updated version of the original note. The naming architecture is a "living document" that needs procedures for: - Allowing submission of requests for new attributes and object classes to be added into the naming architecture; - Checking for the redundancy of any previously defined attribute types and object classes. This document attempts to establish procedures to allow for the continual updating of the naming architecture. Two proformas are set out for this purpose. In addition, descriptive detail is provided for the additional object classes and attribute types defined in the naming architecture. These descriptions follow the style used in X.520 and X.521. Finally, also following the style adopted in the standards documents, appendices will include the entire naming architecture. Plain text versions of the document's appendices are intended to be machine processible to allow derivation of a system's schema tables. Appendix C lists all the architectures's object classes and attribute types in their respective ASN.1 macro formats. | The scope and intended remit of this coordination activity should be clearly understood. - Esoteric and local, highly experimental requirements should continue to be met by private definitions. - Requirements which have support from more than one site will usually be integrated into the naming architecture. Put in other words, the tendency will be for the inclusion, as opposed to the exclusion, of useful additions to the naming architecture. - An attempt will be made to avoid duplication of object classes and attribute types for essentially similar real world objects. It is important to note that this version of the document is a Barker & Kille [page 3] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 draft, which is intended principally to provoke comments on the naming architecture updating mechanisms proposed. Corrections to the architecture should also be indicated to the authors. However, additions to the architecture should not be submitted until a call is made for such enhancements. 3. What conformance to this architecture means It is not reasonable to require that a DSA which supports this architecture has specific code to handle each of the defined syntaxes. However, the following requirements are made of a system which claims conformance to this specification: 1. A DSA shall be able to store all of the attributes and object class values specified. (Note that this implies support for all the object classes and attribute types required by strong authentication as defined in X.509.) 2. A DUA shall be able to identify each attribute type and object class to the user, with an appropriate representation (e.g., a string). 3. These statement are qualified for large attributes (>1kbyte). A conforming DSA does not have to store such attributes, and a DUA does not have to display the value of such attributes, although it must indicate the attribute's presence. The following are desirable, but not required: 1. For a DSA to match correctly on the basis of all attribute syntaxes defined 2. For a DSA to enforce the Object Class schema implied by these definitions 3. For a DUA to correctly display the attribute values (syntaxes) defined 4. For DUAs and DSAs to maintain compatibility with a previous version of the naming architecture. Barker & Kille [page 4] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 4. Requesting new object classes and attribute types This section defines a procedure for requesting new object classes and attribute types to be added to the naming architecture. Proformas for object classes and attribute types are specified, and examples given of how to use them. As stated earlier, it is anticipated that the naming architecture will evolve considerably over time. As X.500 is used to support a widening range of applications, there will be requirements for extensions to the naming architecture. This document proposes formalising this procedure by requiring requests for additions to the naming architecture to be submitted as completed proformas. This stipulation will greatly simplify subsequent revisions of the naming architecture. There is one qualification to the above with respect to requests for modifications to an existing object class. If a modification to an object class merely involves additional, optional attributes, the object class will be enhanced as requested. Systems are expected to be resilient to such changes to the naming architecture. However, requests to modify an object class, such that the mandatory attribute types require altering, will not be met. Instead, a new object class will be created, and the original object class expired following the scheme described in the next main section. It is anticipated that most requests for modifications to the naming architecture will be met without any need for editorial intervention. Sometimes, however, some discussion between the submitter of a request and the architecture's editor may be required. For example, the editor may have to judge the relative merits of two very similar requests and, as a result, one of the parties may not get quite what they want. In cases such as this where the submitter of a request feels aggrieved about an editorial decision, the requestor may appeal to a broader community by explaining their views to the mailing list osi- ds@cs.ucl.ac.uk. Heed will be paid to any consensus that emerges from discussions on the naming architecture on this list. If it proves that this list is used almost solely for discussions on naming architecture issues, a separate discussion list will be created. To facilitate the production of the afore-mentioned proformas, Barker & Kille [page 5] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 tools are included in Appendix B which will verify that a proforma has been correctly formatted. Completed proformas should be mailed to na-update@cs.ucl.ac.uk 4.1. Object Class proforma This section gives an example, completed proforma for a new object class, alcoholic drink. A proforma for object class specified in BNF is included in Appendix A. Object Class: Alcoholic Drink Description: The Alcoholic Drink object class is used to define entries representing intoxicating beverages. ASN1OCMacro: alcoholicDrink OBJECT-CLASS SUBCLASS OF drink MUST CONTAIN { percentAlcohol} MAY CONTAIN { normalServing, hue} An object class description consists of three fields, separated by blank lines. The keywords Object Class, Description and ASN1OCMacro, and their suffixed colons, must be included exactly as above. The Object Class field should be used for a textual description of the object class. This will be at most three or four words. The Description field should contain some explanatory text about the intended use of the object class. This can run to a number of lines. The ASN1OCMacro field should follow the definition of the object class macro as specified in X.501. The above example shows the main features. There are many more examples which can studied in the section defining the Pilot Object Classes. Barker & Kille [page 6] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 4.2. Attribute type proforma This section gives an example completed proforma for a new attribute type, hue (one of the attribute types in the alcoholic drink object class). Attribute Type: Hue Description: The Hue attribute type specifies the hue of an object. OCMust: OCMay: alcoholicDrink ASN1ATMacro:hue ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-hue)) ub-hue INTEGER ::= 256 An attribute type description consists of five fields, separated by blank lines. The keywords Attribute Type, Description, OCMust, OCMay and ASN1ATMacro, and their suffixed colons, must be included exactly as above. The Attribute Type field should be used for a textual description of the attribute type. This will be at most three or four words. The Description field should contain some explanatory text about the intended use of the attribute type. This can run to a number of lines. The OCMust field should contain a comma-separated list of object classes for which this attribute is mandatory. The OCMay field should contain a comma-separated list of object classes for which this attribute is optional. The ASN1ATMacro field should follow the definition of the attribute macro as specified in X.501. The above example shows Barker & Kille [page 7] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 some of the features. In particular, please note the format for specifying size constraints . 5. Removing "old" object classes and attribute types. It is also important that object classes and attribute types which are no longer used or useful are removed from the naming architecture. Some object classes and attribute types initially defined as pilot extensions may be included as standard definitions in future versions of the standard. In such a case, it is important that there should be a fairly rapid transition to the standard definitions. Another possibility is that newer, more specific definitions obviate the original definitions. Two things are essential. First, it is crucial that "old" definitions are retired as gracefully as possible. The intention to retire a definition will be sent to the osi-ds@cs.ucl.ac.uk mail list. In the absence of objections, the definition will be marked for expiry with a given expiry date. The definition will remain in the architecture until the expiry date. Users of the architecture should ensure that they make the transition to new, alternative definitions in the interim. Second, users of the architecture must have the right to argue for the retention of definitions which they regard as necessary, there being no other definitions which closely meet their requirements. It is clearly impossible to lay down hard and fast rules on this point, as no two instances will ever be quite the same. It is intended that the refereeing on these matters will be sympathetic! As for requests for additions, an aggrieved user can "go to arbitration" by initiating a discussion on the osi- ds@cs.ucl.ac.uk mail list. 6. Object Identifiers Some additional object identifiers are defined for this architecture. These are also reproduced in Appendix C. Barker & Kille [page 8] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 data OBJECT IDENTIFIER ::= {ccitt 9} pss OBJECT IDENTIFIER ::= {data 2342} ucl OBJECT IDENTIFIER ::= {pss 19200300} pilot OBJECT IDENTIFIER ::= {ucl 100} pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1} pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3} pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4} 7. Object Classes 7.1. X.500 standard object classes A number of generally useful object classes are defined in X.521, and these are supported. Refer to that document for descriptions of the suggested usage of these object classes. The ASN.1 for these object classes is reproduced for completeness in Appendix C. 7.2. X.400 standard object classes A number of object classes defined in X.400 are supported. Refer to X.402 for descriptions of the usage of these object classes. The ASN.1 for these object classes is reproduced for completeness in Appendix C. 7.3. COSINE/Internet object classes This section attempts to fuse together the object classes designed for use in the COSINE and Internet pilot activities. Descriptions are given of the suggested usage of these object classes. The ASN.1 for these object classes is also reproduced in Appendix C. 7.3.1. Pilot Object The PilotObject object class is used as a sub-class to allow some common, useful attributes to be assigned to entries of all other object classes. Barker & Kille [page 9] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotObject OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { info, photo, manager, uniqueIdentifier, lastModifiedTime, lastModifiedBy} ::= {pilotObjectClass 3} 7.3.2. Pilot Person The PilotPerson object class is used as a sub-class of person, to allow the use of a number of additional attributes to be assigned to entries of object class person. Barker & Kille [page 10] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { userid, textEncodedORAddress, rfc822Mailbox, favouriteDrink, roomNumber, userClass, homeTelephoneNumber, homePostalAddress, secretary, personalTitle, localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, facsimileTelephoneNumber, businessCategory, title, janetMailbox, otherMailbox, mobileTelephoneNumber, pagerTelephoneNumber, organizationalStatus} ::= {pilotObjectClass 4} 7.3.3. Account The Account object class is used to define entries representing computer accounts. The userid attribute should be used for naming entries of this object class. Barker & Kille [page 11] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 account OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userid} MAY CONTAIN { description, seeAlso, localityName, organizationName, organizationalUnitName, host} ::= {pilotObjectClass 5} 7.3.4. Document The Document object class is used to define entries which represent documents. document OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { documentIdentifier} MAY CONTAIN { commonName, description, seeAlso, localityName, organizationName, organizationalUnitName, documentTitle, documentVersion, documentAuthor, documentLocation} ::= {pilotObjectClass 6} 7.3.5. Room The Room object class is used to define entries representing rooms. The commonName attribute should be used for naming entries of this object class. Barker & Kille [page 12] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 room OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { roomNumber, description, seeAlso, telephoneNumber} ::= {pilotObjectClass 7} 7.3.6. Document Series The Document Series object class is used to define an entry which represents a series of documents (e.g. The Request For Comments papers). documentSeries OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, seeAlso, telephoneNumber, localityName, organizationName, organizationalUnitName} ::= {pilotObjectClass 9} 7.3.7. Domain The Domain object class is used to define entries which represent DNS or NRS domains. The domainComponent attribute should be used for naming entries of this object class. The usage of this object class is described in more detail in [3]. Barker & Kille [page 13] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 domain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { domainComponent} MAY CONTAIN { associatedName, organizationName, organizationalAttributeSet} ::= {pilotObjectClass 13} 7.3.8. RFC822 Local Part The RFC822 Local Part object class is used to define entries which represent the local part of RFC822 mail addresses. This treats this part of an RFC822 address as a domain. The usage of this object class is described in more detail in [3]. rFC822localPart OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { commonName, surname, description, seeAlso, telephoneNumber, postalAttributeSet, telecommunicationAttributeSet} ::= {pilotObjectClass 14} 7.3.9. DNS Domain The DNS Domain (Domain NameServer) object class is used to define entries for DNS domains. The usage of this object class is described in more detail in [3]. Barker & Kille [page 14] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dNSDomain OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { ARecord, MDRecord, MXRecord, NSRecord, SOARecord, CNAMERecord} ::= {pilotObjectClass 15} 7.3.10. NRS Domain The NRS Domain object class is used to define entries which represent NRS domains. The usage of this object class is described in more detail in [3]. nRSdomain OBJECT-CLASS SUBCLASS OF domain MUST CONTAIN { nRSSystemDescription} MAY CONTAIN { ForwardOnlyInformation, ReverseOnlyInformation, ForwardAndReverseInformation} ::= {pilotObjectClass 16} 7.3.11. Domain Related Object The Domain Related Object object class is used to define entries which represent DNS/NRS domains which are "equivalent" to an X.500 domain:e.g. an organisation or organisational unit. The usage of this object class is described in more detail in [3]. domainRelatedObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { associatedDomain} ::= {pilotObjectClass 17} Barker & Kille [page 15] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 7.3.12. Friendly Country The Friendly Country object class is used to define country entries in the DIT. The object class is used to allow friendlier naming of countries than that allowed by the object class country. The naming attribute of object class country, countryName, has to be a 2 letter string defined in ISO 3166. friendlyCountry OBJECT-CLASS SUBCLASS OF country MUST CONTAIN { friendlyCountryName} ::= {pilotObjectClass 18} 7.3.13. Simple Security Object The Simple Security Object object class is used to allow an entry to have a userPassword attribute when an entry's principal object classes do not allow userPassword as an attribute type. simpleSecurityObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userPassword } ::= {pilotObjectClass 19} 8. Attribute Types 8.1. X.500 standard attribute types A number of generally useful attribute types are defined in X.520, and these are supported. Refer to that document for descriptions of the suggested usage of these attribute types. The ASN.1 for these attribute types is reproduced for completeness in Appendix C. 8.2. X.400 standard attribute types The standard X.400 attribute types are supported. See X.402 for | full details. The ASN.1 for these attribute types is reproduced in Appendix C. Barker & Kille [page 16] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3. COSINE/Internet attribute types This section describes all the attribute types defined for use in the COSINE and Internet pilots. Descriptions are given as to the suggested usage of these attribute types. The ASN.1 for these attribute types is reproduced in Appendix C. 8.3.1. Userid The Userid attribute type specifies a computer system login name. userid ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-identifier)) ::= {pilotAttributeType 1} 8.3.2. Text Encoded O/R Address The Text Encoded O/R Address attribute type specifies a text encoding of an X.400 O/R address, as specified in RFC 987. The use of this attribute is deprecated as the attribute is intended | for interim use only. This attribute will be the first candidate | for the attribute expiry mechanisms! textEncodedORAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-text-encoded-or-address)) ::= {pilotAttributeType 2} 8.3.3. RFC 822 Mailbox The RFC822 Mailbox attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822. Note that this attribute should not be used for greybook or other non- Internet order mailboxes. Barker & Kille [page 17] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} 8.3.4. Information The Information attribute type specifies any general information pertinent to an object. It is recommended that specific usage of this attribute type is avoided, and that specific requirements are met by other (possibly additional) attribute types. info ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-information)) ::= {pilotAttributeType 4} 8.3.5. Favourite Drink The Favourite Drink attribute type specifies the favourite drink of an object (or person). favouriteDrink ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-favourite-drink)) ::= {pilotAttributeType 5} 8.3.6. Room Number The Room Number attribute type specifies the room number of an object. Note that the commonName attribute should be used for naming room objects. Barker & Kille [page 18] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 roomNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-room-number)) ::= {pilotAttributeType 6} 8.3.7. Photo The Photo attribute type specifies a "photograph" for an object. This should be encoded in G3 fax as explained in recommendation T.4. photo ATTRIBUTE WITH ATTRIBUTE-SYNTAX photo (SIZE (1 .. ub-photo)) ::= {pilotAttributeType 7} 8.3.8. User Class The User Class attribute type specifies a category of computer user. The semantics placed on this attribute are for local interpretation. Examples of current usage od this attribute in academia are undergraduate student, researcher, lecturer, etc. Note that the organizationalStatus attribute may now often be preferred as it makes no distinction between computer users and others. userClass ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-class)) ::= {pilotAttributeType 8} 8.3.9. Host The Host attribute type specifies a host computer. Barker & Kille [page 19] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 host ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-host)) ::= {pilotAttributeType 9} 8.3.10. Manager The Manager attribute type specifies the manager of an object represented by an entry. manager ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 10} 8.3.11. Document Identifier The Document Identifier attribute type specifies a unique identifier for a document. documentIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-identifier)) ::= {pilotAttributeType 11} 8.3.12. Document Title The Document Title attribute type specifies the title of a document. documentTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-title)) ::= {pilotAttributeType 12} Barker & Kille [page 20] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.13. Document Version The Document Version attribute type specifies the version number of a document. documentVersion ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-version)) ::= {pilotAttributeType 13} 8.3.14. Document Author The Document Author attribute type specifies the distinguished name of the author of a document. documentAuthor ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 14} 8.3.15. Document Location The Document Location attribute type specifies the location of the document original. documentLocation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-location)) ::= {pilotAttributeType 15} 8.3.16. Home Telephone Number The Home Telephone Number attribute type specifies a home telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567" Barker & Kille [page 21] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 homeTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 20} 8.3.17. Secretary The Secretary attribute type specifies the secretary of a person. The attribute value for Secretary is a distinguished name. secretary ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 21} 8.3.18. Other Mailbox The Other Mailbox attribute type specifies values for electronic mailbox types other than X.400 and rfc822. ??? something about the syntax. otherMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX SEQUENCE { mailboxType PrintableString, -- e.g. Telemail mailbox IA5String -- e.g. X378:Joe } ::= {pilotAttributeType 22} 8.3.19. Last Modified Time The Last Modified Time attribute type specifies the last time, in UTC time, that an entry was modified. Ideally, this attribute should be maintained by the DSA. lastModifiedTime ATTRIBUTE WITH ATTRIBUTE-SYNTAX uTCTimeSyntax ::= {pilotAttributeType 23} Barker & Kille [page 22] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.20. Last Modified By The Last Modified By attribute specifies the distinguished name of the last user to modify the associated entry. Ideally, this attribute should be maintained by the DSA. lastModifiedBy ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 24} 8.3.21. Domain Component The Domain Component attribute type specifies a DNS/NRS domain. For example, "uk" or "ac". domainComponent ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax SINGLE VALUE ::= {pilotAttributeType 25} 8.3.22. DNS ARecord The A Record attribute type specifies a type A (Address) DNS resource record [6] [7]. aRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 26} 8.3.23. MX Record The MX Record attribute type specifies a type MX (Mail Exchange) DNS resource record [6] [7]. mXRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 28} Barker & Kille [page 23] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.24. NS Record The NS Record attribute type specifies an NS (Name Server) DNS resource record [6] [7]. nSRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 29} 8.3.25. SOA Record The SOA Record attribute type specifies a type SOA (Start of Authority) DNS resorce record [6] [7]. sOARecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 30} 8.3.26. CNAME Record The CNAME Record attribute type specifies a type CNAME (Canonical Name) DNS resource record [6] [7]. cNAMERecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 31} 8.3.27. Associated Domain The Associated Domain attribute type specifies a DNS or NRS domain which is associated with an object in the DIT. For example, the entry in the DIT with a distinguished name "C=GB, O=University College London" would have an associated domain of "UCL.AC.UK. Note that all domains should be represented in rfc822 order. See [3] for more details of usage of this attribute. Barker & Kille [page 24] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 associatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 37} 8.3.28. Associated Name The Associated Name attribute type specifies an entry in the organisational DIT associated with a DNS/NRS domain. See [3] for more details of usage of this attribute. associatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 38} 8.3.29. Home postal address The Home postal address attribute type specifies a home postal address for an object. This should be limited to up to 6 lines of 30 characters each. homePostalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX postalAddress MATCHES FOR EQUALITY ::= {pilotAttributeType 39} 8.3.30. Personal Title The Personal Title attribute type specifies a personal title for a person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev". personalTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-personal-title)) ::= {pilotAttributeType 40} Barker & Kille [page 25] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.3.31. Mobile Telephone Number The Mobile Telephone Number attribute type specifies a mobile telephone number associated with a person. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567" mobileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 41} 8.3.32. Pager Telephone Number The Pager Telephone Number attribute type specifies a pager telephone number for an object. Attribute values should follow the agreed format for international telephone numbers:i.e. "+44 71 123 4567". pagerTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 42} 8.3.33. Friendly Country Name The Friendly Country Name attribute type specifies names of countries in human readable format. The standard attribute country name must be one of the two-letter codes defined in ISO 3166. friendlyCountryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= {pilotAttributeType 43} 8.3.34. Unique Identifier The Unique Identifier attribute type specifies a unique identifier for an object represented in the Directory. For a person, this might be an institution-wide payroll number. For an Barker & Kille [page 26] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organisational unit, it might be a department code. uniqueIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-unique-identifier)) ::= {pilotAttributeType 44} 8.3.35. Organisational Status The Organisational Status attribute type specifies a category by which a person is often referred to in an organisation. Examples of usage in academia might include undergraduate student, researcher, lecturer, etc. A Directory administrator should probably consider carefully the distinctions between this and the title and userClass attributes. organizationalStatus ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-organizational-status)) ::= {pilotAttributeType 45} 8.3.36. Janet Mailbox The Janet Mailbox attribute type specifies an electronic mailbox attribute following the syntax specified in the Grey Book of the Coloured Book series. This attribute is intended for the convenience of U.K users unfamiliar with rfc822 and little-endian mail addresses. Entries using this attribute MUST also include an rfc822Mailbox attribute. janetMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-janet-mailbox)) ::= {pilotAttributeType 46} Barker & Kille [page 27] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 8.4. Generally useful syntaxes caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS iA5StringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS -- Syntaxes to support the DNS attributes DNSRecordSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY NRSInformationSyntax ATTRIBUTE-SYNTAX NRSInformation MATCHES FOR EQUALITY NRSInformation ::= SET { [0] Context, [1] Address-space-id, routes [2] SEQUENCE OF SEQUENCE { Route-cost, Addressing-info } } 8.5. Upper bounds on length of attribute values ub-document-identifier INTEGER ::= 256 ub-document-location INTEGER ::= 256 ub-document-title INTEGER ::= 256 Barker & Kille [page 28] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 ub-document-version INTEGER ::= 256 ub-favourite-drink INTEGER ::= 256 ub-host INTEGER ::= 256 ub-information INTEGER ::= 2048 ub-unique-identifier INTEGER ::= 256 ub-personal-title INTEGER ::= 256 ub-photo INTEGER ::= 250000 ub-rfc822-mailbox INTEGER ::= 256 ub-room-number INTEGER ::= 256 ub-text-or-address INTEGER ::= 256 ub-user-class INTEGER ::= 256 ub-user-identifier INTEGER ::= 256 ub-organizational-status INTEGER ::= 256 ub-janet-mailbox INTEGER ::= 256 9. Authors' addresses Barker & Kille [page 29] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 Paul Barker and Steve Kille Department of Computer Science University College London Gower Street London WC1E 6BT England Phone: +44 71-380-7366 (Barker) +44 71-380-7294 (Kille) Email: P.Barker@cs.ucl.ac.uk S.Kille@cs.ucl.ac.uk References [1] X.500, The Directory - overview of concepts, models and services, CCITT /ISO IS 9594 [2] S.E. Kille, The THORN and RARE X.500 Naming Architecture, in University College London, Department of Computer Science Research Note 89/48, May 1989. [3] S.E. Kille, X.500 and Domains, in University College London, Department of Computer Science Research Note 89/47, May 1989 [4] M.T. Rose, PSI/NYSERNet White Pages Pilot Project: Status Report, Technical Report 90-09-10-1, published by NYSERNet Inc, 1990 [5] J. Craigie, UK Academic Community Directory Service Pilot Project, pp. 305-310 in Computer Networks and ISDN Systems 17 (1989), published by North Holland. [6] P. Mockapetris, Domain Names - Concepts and Facilities, RFC-1034, USC Information Sciences Institute, November 1987 Barker & Kille [page 30] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 [7] P. Mockapetris, Domain Names - Implementation and Specification, RFC-1035, USC Information Sciences Institute, November 1987 Barker & Kille [page 31] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX A - Object Class and Attribute Type proformas These are specified in BNF. First some useful definitions, common to both proformas. EOL ::= -- the end of line character(s) BlankLine ::= -- a line consisting solely of an EOL character String ::= | anychar ::= --any character occurring in general text, excluding the end -- of line character lString ::= lowercase ::= [a-z] UString ::= uppercase ::= [A-Z] otherstring ::= | otherchar ::= | | Integer ::= | digit ::= [0-9] 1. Object Class OCProforma ::= \ ObjectClassName ::= "ObjectClass:" Description ::= "Description:" DescriptiveText ::= | Barker & Kille [page 32] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 OCMacro ::= "ASN1OCMacro:" -- The definition of ObjectClassMacro is adapted from that in X.501 ObjectClassMacro ::= "OBJECT-CLASS" \ OCName ::= SubclassOf ::= "SUBCLASS OF" Subclasses | Subclasses ::= | "," Subclass ::= MandatoryAttributes ::= "MUST CONTAIN {" "}" | OptionalAttributes ::= "MAY CONTAIN {" "}" | Attributes ::= | "," AttributeTerm ::= | Attribute ::= AttributeSet ::= 2. Attribute Type ATProforma ::= \ \ AttributeTypeName ::= "Attribute Type:" Description ::= "Description:" DescriptiveText ::= | OCMust ::= "OCMust:" OCList ::= | "," | Barker & Kille [page 33] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 OCMay ::= "OCMay:" ATMacro ::= "ASN1ATMacro:" -- The definition of AttributeTypeMacro is adapted from that in X.501 AttributeTypeMacro ::= "ATTRIBUTE" \ | ATName ::= AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice SyntaxChoice ::= | Syntax ::= Constraint ::= "(" ConstraintAlternative ")" | ConstraintAlternative ::= StringConstraint | IntegerConstraint StringConstraint ::= "SIZE" "(" SizeConstraint ")" SizeConstraint ::= SingleValue | Range SingleValue ::= Range ::= ".." IntegerConstraint ::= Range ASN1Type ::= -- one of ASN.1's base types: e.g. PrintableString, NumericString, etc. MatchTypes ::= "MATCHES FOR" Matches | Matches ::= Match | Matches Match Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING" Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | Barker & Kille [page 34] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX B - Format checking tools This section includes the source for format checking tools for the two proformas. The tools are written as Bourne shell scripts for UNIX systems. 1. Object class format checker sed 's/ *: */:/' | awk ' BEGIN { state = "initial" } /^$/ { next } /^Object Class:/ { n = index($0, ":") if (state != "initial") { print "Already got object class " oc print "Got another object class " substr($0, n+1) state = "notOK" exit 1 } oc = substr($0, n+1) state = "gotOC" next } /^Description:/ { n = index($0, ":") if (state != "gotOC") { print "Got Description: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Object Class:" else Barker & Kille [page 35] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 print "Expecting ASN1OCMacro:" state = "notOK" exit 1 } while (getline > 0) if (length($0) > 0) continue else break state = "gotDesc" next } /^ASN1OCMacro:/ { n = index($0, ":") if (state != "gotDesc") { print "Got ASN1Macro: " substr($0, n+1) for (i = 0; i < 2 && getline > 0; i++) print $0 print "..." if (state == "initial") print "Expecting Object Class:" else print "Expecting Description:" state = "notOK" exit 1 } state = "OK" exit 0 } { print "Parsing has got confused on seeing line: " $0 state = "notOK" exit 1 } END { if (state == "OK") print "Input looks OK" } Barker & Kille [page 36] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 2. Attribute Type format checker sed 's/ *: */:/' | awk ' BEGIN { state = "initial" } /^$/ { next } /^Attribute Type:/ { n = index($0, ":") if (state != "initial") { got = "Attribute Type:" exit 1 } state = "gotAT" next } /^Description:/ { n = index($0, ":") if (state != "gotAT") { got = "Description:" exit 1 } while (getline > 0) if (length($0) > 0) continue else break state = "gotDesc" next } /^OCMust:/ { n = index($0, ":") if (state != "gotDesc") { Barker & Kille [page 37] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 got = "OCMust:" exit 1 } state = "gotOCMust" next } /^OCMay:/ { n = index($0, ":") if (state != "gotOCMust") { got = "OCMay:" exit 1 } state = "gotOCMay" next } /^ASN1ATMacro:/ { n = index($0, ":") if (state != "gotOCMay") { got = "ASN1ATMacro:" exit 1 } state = "OK" exit 0 } { print "Parsing has got confused on seeing line: " $0 state = "notOK" exit 1 } END { if (state == "initial") print "Expecting Attribute Type:" else if (state == "gotAT") print "Expecting Description:" else if (state == "gotDesc") print "Expecting OCMust:" else if (state == "gotOCMust") print "Expecting OCMay:" Barker & Kille [page 38] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 else if (state == "gotOCMay") print "Expecting ASN1ATMacro:" if (state != "OK") print "Got " got else print "Input looks OK" } Barker & Kille [page 39] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 APPENDIX C - Summary of all Object Classes and Attribute Types -- Some Important Object Identifiers data OBJECT IDENTIFIER ::= {ccitt 9} pss OBJECT IDENTIFIER ::= {data 2342} ucl OBJECT IDENTIFIER ::= {pss 19200300} pilot OBJECT IDENTIFIER ::= {ucl 100} pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1} pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3} pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4} -- Standard Object Classes top OBJECT-CLASS MUST CONTAIN { objectClass} ::= {objectClass 0} alias OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { aliasedObjectName} ::= {objectClass 1} country OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { countryName} MAY CONTAIN { description, searchGuide} ::= {objectClass 2} Barker & Kille [page 40] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 locality OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { description, localityName, stateOrProvinceName, searchGuide, seeAlso, streetAddress} ::= {objectClass 3} organization OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 4} organizationalUnit OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationalUnitName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 5} person OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, surname} MAY CONTAIN { description, seeAlso, telephoneNumber, userPassword} ::= {objectClass 6} Barker & Kille [page 41] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organizationalPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { localeAttributeSet, organizationalUnitName, postalAttributeSet, telecommunicationAttributeSet, title} ::= {objectClass 7} organizationalRole OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localeAttributeSet, organizationalUnitName, postalAttributeSet, preferredDeliveryMethod, roleOccupant, seeAlso, telecommunicationAttributeSet} ::= {objectClass 8} groupOfNames OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, member} MAY CONTAIN { description, organizationName, organizationalUnitName, owner, seeAlso, businessCategory} ::= {objectClass 9} Barker & Kille [page 42] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 residentialPerson OBJECT-CLASS SUBCLASS OF person MUST CONTAIN { localityName} MAY CONTAIN { localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, telecommunicationAttributeSet, businessCategory} ::= {objectClass 10} applicationProcess OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localityName, organizationalUnitName, seeAlso} ::= {objectClass 11} applicationEntity OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, presentationAddress} MAY CONTAIN { description, localityName, organizationName, organizationalUnitName, seeAlso, supportedApplicationContext} ::= {objectClass 12} Barker & Kille [page 43] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dSA OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { knowledgeInformation} ::= {objectClass 13} device OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, localityName, organizationName, organizationalUnitName, owner, seeAlso, serialNumber} ::= {objectClass 14} strongAuthenticationUser OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userCertificate} ::= {objectClass 15} certificationAuthority OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { cACertificate, certificateRevocationList, authorityRevocationList} MAY CONTAIN { crossCertificatePair} ::= {objectClass 16} -- Standard MHS Object Classes Barker & Kille [page 44] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsDistributionList OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName, mhsDLSubmitPermissions, mhsORAddresses} MAY CONTAIN { description, organizationName, organizationalUnitName, owner, seeAlso, mhsDeliverableContentTypes, mhsdeliverableEits, mhsDLMembers, mhsPreferredDeliveryMethods} ::= {mhsObjectClass 0} mhsMessageStore OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { description, owner, mhsSupportedOptionalAttributes, mhsSupportedAutomaticActions, mhsSupportedContentTypes} ::= {mhsObjectClass 1} mhsMessageTransferAgent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { description, owner, mhsDeliverableContentLength} ::= {mhsObjectClass 2} Barker & Kille [page 45] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsOrganizationalUser OBJECT-CLASS SUBCLASS OF organizationalPerson MUST CONTAIN { mhsORAddresses} MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsMessageStoreName, mhsPreferredDeliveryMethods } ::= {mhsObjectClass 3} mhsResidentialUser OBJECT-CLASS SUBCLASS OF residentialPerson MUST CONTAIN { mhsORAddresses} MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsMessageStoreName, mhsPreferredDeliveryMethods } ::= {mhsObjectClass 4} mhsUserAgent OBJECT-CLASS SUBCLASS OF applicationEntity MAY CONTAIN { mhsDeliverableContentLength, mhsDeliverableContentTypes, mhsDeliverableEits, mhsORAddresses, owner} ::= {mhsObjectClass 5} -- Pilot Object Classes Barker & Kille [page 46] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 pilotObject OBJECT-CLASS SUBCLASS OF top MAY CONTAIN { info, photo, manager, uniqueIdentifier, lastModifiedTime, lastModifiedBy} ::= {pilotObjectClass 3} pilotPerson OBJECT-CLASS SUBCLASS OF person MAY CONTAIN { userid, textEncodedORAddress, rfc822Mailbox, favouriteDrink, roomNumber, userClass, homeTelephoneNumber, homePostalAddress, secretary, personalTitle, localeAttributeSet, postalAttributeSet, preferredDeliveryMethod, facsimileTelephoneNumber, businessCategory, title, janetMailbox, otherMailbox, mobileTelephoneNumber, pagerTelephoneNumber, organizationalStatus} ::= {pilotObjectClass 4} Barker & Kille [page 47] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 account OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userid} MAY CONTAIN { description, seeAlso, localityName, organizationName, organizationalUnitName, host} ::= {pilotObjectClass 5} document OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { documentIdentifier} MAY CONTAIN { commonName, description, seeAlso, localityName, organizationName, organizationalUnitName, documentTitle, documentVersion, documentAuthor, documentLocation} ::= {pilotObjectClass 6} room OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { roomNumber, description, seeAlso, telephoneNumber} ::= {pilotObjectClass 7} Barker & Kille [page 48] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 documentSeries OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { commonName} MAY CONTAIN { description, seeAlso, telephoneNumber, localityName, organizationName, organizationalUnitName} ::= {pilotObjectClass 9} domain OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { domainComponent} MAY CONTAIN { associatedName, organizationName, organizationalAttributeSet} ::= {pilotObjectClass 13} rFC822localPart OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { commonName, surname, description, seeAlso, telephoneNumber, postalAttributeSet, telecommunicationAttributeSet} ::= {pilotObjectClass 14} Barker & Kille [page 49] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 dNSDomain OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { ARecord, MDRecord, MXRecord, NSRecord, SOARecord, CNAMERecord} ::= {pilotObjectClass 15} nRSdomain OBJECT-CLASS SUBCLASS OF domain MUST CONTAIN { nRSSystemDescription} MAY CONTAIN { ForwardOnlyInformation, ReverseOnlyInformation, ForwardAndReverseInformation} ::= {pilotObjectClass 16} domainRelatedObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { associatedDomain} ::= {pilotObjectClass 17} friendlyCountry OBJECT-CLASS SUBCLASS OF country MUST CONTAIN { friendlyCountryName} ::= {pilotObjectClass 18} simpleSecurityObject OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { userPassword } ::= {pilotObjectClass 19} Barker & Kille [page 50] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 -- Standard Attribute Types objectClass ObjectClass ::= {attributeType 0} aliasedObjectName AliasedObjectName ::= {attributeType 1} knowledgeInformation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreString ::= {attributeType 2} commonName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-common-name)) ::= {attributeType 3} surname ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-surname)) ::= {attributeType 4} serialNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX printableStringSyntax (SIZE (1..ub-serial-number)) ::= {attributeType 5} countryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (1..ub-country-code)) SINGLE VALUE ::= {attributeType 6} localityName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-locality-name)) ::= {attributeType 7} stateOrProvinceName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-state-name)) ::= {attributeType 8} Barker & Kille [page 51] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 streetAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-street-address)) ::= {attributeType 9} organizationName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-organization-name)) ::= {attributeType 10} organizationalUnitName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-organizational-unit-name)) ::= {attributeType 11} title ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-title)) ::= {attributeType 12} description ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-description)) ::= {attributeType 13} searchGuide ATTRIBUTE WITH ATTRIBUTE-SYNTAX Guide ::= {attributeType 14} businessCategory ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-business-category)) ::= {attributeType 15} postalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PostalAddress MATCHES FOR EQUALITY ::= {attributeType 16} postalCode ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-postal-code)) ::= {attributeType 17} Barker & Kille [page 52] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 postOfficeBox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-post-office-box)) ::= {attributeType 18} physicalDeliveryOfficeName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..ub-physical-office-name)) ::= {attributeType 19} telephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax (SIZE (1..ub-telephone-number)) ::= {attributeType 20} telexNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX TelexNumber (SIZE (1..ub-telex)) ::= {attributeType 21} teletexTerminalIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier (SIZE (1..ub-teletex-terminal-id)) ::= {attributeType 22} facsimileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber ::= {attributeType 23} x121Address ATTRIBUTE WITH ATTRIBUTE-SYNTAX NumericString (SIZE (1..ub-x121-address)) ::= {attributeType 24} internationaliSDNNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX NumericString (SIZE (1..ub-isdn-address)) ::= {attributeType 25} registeredAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PostalAddress ::= {attributeType 26} Barker & Kille [page 53] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 destinationIndicator ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (1..ub-destination-indicator)) MATCHES FOR EQUALITY SUBSTRINGS ::= {attributeType 27} preferredDeliveryMethod ATTRIBUTE WITH ATTRIBUTE-SYNTAX deliveryMethod ::= {attributeType 28} presentationAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX PresentationAddress MATCHES FOR EQUALITY ::= {attributeType 29} supportedApplicationContext ATTRIBUTE WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax ::= {attributeType 30} member ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 31} owner ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 32} roleOccupant ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 33} seeAlso ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {attributeType 34} userPassword ATTRIBUTE WITH ATTRIBUTE-SYNTAX Userpassword ::= {attributeType 35} userCertificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX UserCertificate ::= {attributeType 36} Barker & Kille [page 54] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 cACertificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX cACertificate ::= {attributeType 37} authorityRevocationList ATTRIBUTE WITH ATTRIBUTE-SYNTAX AuthorityRevocationList ::= {attributeType 38} certificateRevocationList ATTRIBUTE WITH ATTRIBUTE-SYNTAX CertificateRevocationList ::= {attributeType 39} crossCertificatePair ATTRIBUTE WITH ATTRIBUTE-SYNTAX CrossCertificatePair ::= {attributeType 40} -- Standard MHS Attribute Types mhsDeliverableContentLength ATTRIBUTE WITH ATTRIBUTE-SYNTAX integer ::= {mhsAttributeType 0} mhsDeliverableContentTypes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 1} mhsDeliverableEits ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 2} mhsDLMembers ATTRIBUTE WITH ATTRIBUTE-SYNTAX oRName ::= {mhsAttributeType 3} mhsDLSubmitPermissions ATTRIBUTE WITH ATTRIBUTE-SYNTAX dLSubmitPermission ::= {mhsAttributeType 4} mhsMessageStoreName ATTRIBUTE WITH ATTRIBUTE-SYNTAX dN ::= {mhsAttributeType 5} Barker & Kille [page 55] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 mhsORAddresses ATTRIBUTE WITH ATTRIBUTE-SYNTAX oRAddress ::= {mhsAttributeType 6} mhsPreferredDeliveryMethods ATTRIBUTE WITH ATTRIBUTE-SYNTAX deliveryMethod ::= {mhsAttributeType 7} mhsSupportedAutomaticActions ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 8} mhsSupportedContentTypes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 9} mhsSupportedOptionalAttributes ATTRIBUTE WITH ATTRIBUTE-SYNTAX oID ::= {mhsAttributeType 10} -- Pilot Attribute Types userid ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-identifier)) ::= {pilotAttributeType 1} textEncodedORAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-text-encoded-or-address)) ::= {pilotAttributeType 2} rfc822Mailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-rfc822-mailbox)) ::= {pilotAttributeType 3} Barker & Kille [page 56] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 info ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-information)) ::= {pilotAttributeType 4} favouriteDrink ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-favourite-drink)) ::= {pilotAttributeType 5} roomNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-room-number)) ::= {pilotAttributeType 6} photo ATTRIBUTE WITH ATTRIBUTE-SYNTAX photo (SIZE (1 .. ub-photo)) ::= {pilotAttributeType 7} userClass ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-user-class)) ::= {pilotAttributeType 8} host ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-host)) ::= {pilotAttributeType 9} Barker & Kille [page 57] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 manager ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 10} documentIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-identifier)) ::= {pilotAttributeType 11} documentTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-title)) ::= {pilotAttributeType 12} documentVersion ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-version)) ::= {pilotAttributeType 13} documentAuthor ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 14} documentLocation ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-document-location)) ::= {pilotAttributeType 15} Barker & Kille [page 58] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 homeTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 20} secretary ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 21} otherMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX SEQUENCE { mailboxType PrintableString, -- e.g. Telemail mailbox IA5String -- e.g. X378:Joe } ::= {pilotAttributeType 22} lastModifiedTime ATTRIBUTE WITH ATTRIBUTE-SYNTAX uTCTimeSyntax ::= {pilotAttributeType 23} lastModifiedBy ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 24} domainComponent ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax SINGLE VALUE ::= {pilotAttributeType 25} Barker & Kille [page 59] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 aRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 26} mXRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 28} nSRecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 29} sOARecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX DNSRecordSyntax ::= {pilotAttributeType 30} cNAMERecord ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 31} associatedDomain ATTRIBUTE WITH ATTRIBUTE-SYNTAX iA5StringSyntax ::= {pilotAttributeType 37} associatedName ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax ::= {pilotAttributeType 38} Barker & Kille [page 60] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 homePostalAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX postalAddress MATCHES FOR EQUALITY ::= {pilotAttributeType 39} personalTitle ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-personal-title)) ::= {pilotAttributeType 40} mobileTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 41} pagerTelephoneNumber ATTRIBUTE WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax ::= {pilotAttributeType 42} friendlyCountryName ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= {pilotAttributeType 43} uniqueIdentifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-unique-identifier)) ::= {pilotAttributeType 44} Barker & Kille [page 61] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 organizationalStatus ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-organizational-status)) ::= {pilotAttributeType 45} janetMailbox ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseIgnoreIA5StringSyntax (SIZE (1 .. ub-janet-mailbox)) ::= {pilotAttributeType 46} -- Generally useful syntaxes caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS iA5StringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS -- Syntaxes to support the DNS attributes DNSRecordSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY NRSInformationSyntax ATTRIBUTE-SYNTAX NRSInformation MATCHES FOR EQUALITY Barker & Kille [page 62] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 NRSInformation ::= SET { [0] Context, [1] Address-space-id, routes [2] SEQUENCE OF SEQUENCE { Route-cost, Addressing-info } } -- Upper bounds on length of attribute values ub-document-identifier INTEGER ::= 256 ub-document-location INTEGER ::= 256 ub-document-title INTEGER ::= 256 ub-document-version INTEGER ::= 256 ub-favourite-drink INTEGER ::= 256 ub-host INTEGER ::= 256 ub-information INTEGER ::= 2048 ub-unique-identifier INTEGER ::= 256 ub-personal-title INTEGER ::= 256 ub-photo INTEGER ::= 250000 ub-rfc822-mailbox INTEGER ::= 256 ub-room-number INTEGER ::= 256 ub-text-or-address INTEGER ::= 256 ub-user-class INTEGER ::= 256 Barker & Kille [page 63] The COSINE and Internet X.500 Naming Architecture DRAFT Version 1.0 ub-user-identifier INTEGER ::= 256 ub-organizational-status INTEGER ::= 256 ub-janet-mailbox INTEGER ::= 256 Barker & Kille [page 64]   Return-Path: Received: from WS10.NISC.SRI.com by bells.cs.ucl.ac.uk with SMTP inbound id <28737-0@bells.cs.ucl.ac.uk>; Wed, 16 Jan 1991 19:09:57 +0000 Received: by ws10.nisc.sri.com (5.64/SRI-NISC1.1) id AA07324; Wed, 16 Jan 91 11:09:38 -0800 Message-Id: <9101161909.AA07324@ws10.nisc.sri.com> To: osi-ds@uk.ac.ucl.cs Cc: joaquin@com.SRI.NISC, meo@com.SRI.NISC, rlang@com.SRI.NISC Subject: February Directory Working Group Meeting Date: Wed, 16 Jan 91 11:09:36 PST From: Ruth Lang Folks: SRI International is pleased to host the next IETF Directory Services Working Group meeting on February 12-13, 1991. Below you will find information regarding local accommodations and transportation. Steve Kille will be posting an agenda for the meeting in the near future. In order to speed the sign-in procedure which must proceed your entrance into the meeting, please RSVP to rlang@nisc.sri.com with the following information: - Your name - Name and address of the company you're representing - Country of your citizenship As a convenience for the group, we have set aside a block of rooms at the Holiday Inn in Palo Alto. The block of rooms will be released and the discount rate (quoted below) will expire on January 28, 1991. After this date, the standard rates apply. Government rates are available any time on a limited basis. Please note that we WILL NOT handle reservations for any of the following hotels. There are no special rates for attendees of the osi-ds meeting, however, most hotels will make their corporate rate available if SRI is mentioned and reservations are made at least one week in advance (note exception above for Holiday Inn). SRI makes no representation regarding the hotels/motels listed below. All prices are subject to change (increase, most likely) without notice. If you have any questions, please contact me. Ruth Lang (415) 859-5608 rlang@nisc.sri.com -------------------------------------------------------------------- LOCAL TRANSPORTATION Car rental services are available at San Francisco (SFO) and San Jose (SJC) airports, and at several locations in Palo Alto. Associated Limo (415) 856-4141 SFO-Menlo Park or Palo Alto; SJC-Palo Alto one-way: $25.20 per person (share ride) $57.75 private car SJC-Menlo Park one-way: $28.30 per person (share ride) $63.00 private car They prefer 24 hour advance reservation. Yellow Cab (415) 368-9999 Approximate cost $35.00 one-way. Airport Connection 1-800-AIRPORT (US only) $13.00 one-way from/to SFO. $29 one-way from/to SJC. Flight information is required with your advance reservation. DIRECTIONS TO SRI INTERNATIONAL Address: SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 Route 101 - southbound from San Francisco direction Take Marsh Road - Atherton turnoff and go approximately one (1) mile. Turn left onto Middlefield Road and go one (1) mile to Ravenswood Ave. Turn right. Route 101 - northbound from San Jose direction Take Willow Road - Menlo Park turnoff and go approximately one (1) mile to Middlefield Road. Turn right on Middlefield and go approximately 1/2 mile to Ravenswood Ave. Turn left. Route 280 - southbound from San Francisco direction Take Sand Hill Road Menlo Park turnoff; go approximately 2 miles to intersection with Santa Cruz Avenue; turn left onto Santa Cruz Avenue and follow Santa Cruz to El Camino Real (Santa Cruz makes a right turn before getting to El Camino); right on El Camino and left at first traffic light (Ravenswood Avenue). Route 280 - northbound from San Jose direction Take Alpine Road - Menlo Park turnoff; bear right and follow Alpine Road to intersection with Sand Hill Road and Santa Cruz Avenue; follow Santa Cruz all the way to El Camino Real (Santa Cruz makes a right turn before getting to El Camino); right on El Camino and left at first traffic light (Ravenswood Avenue). On Ravenswood Avenue, go to the Main Entrance which is marked by a sign. Park in the visitors' parking area and enter the Main Entrance of Building A. A receptionist will sign you in and direct you to Conference Room B. HOTELS/MOTELS IN THE PALO ALTO/MENLO PARK AREA Notes: Rates quoted below do not include taxes. Mention SRI to get discount rates. Holiday Inn minimum rate expires on January 28, 1991. Minimum Rate Government Rate Single/Double Single/Double Holiday Inn 94/104 69/79 625 El Camino Real Palo Alto, CA 94301 (415) 328-2800 Mermaid Inn Motel 44/50 727 El Camino Real Menlo Park, CA 94025 (415) 323-9481 Menlo Motor Lodge 42/44 1315 El Camino Real Menlo Park, CA 94025 (415) 326-7530 The Red Cottage 49/60 45/56 1704 El Camino Real Menlo Park, CA 94025 (415) 326-9010 Riviera Motor Lodge 44/48 15 El Camino Real Menlo Park, CA 94025 (415) 321-8772 Stanford Park Hotel 125/125 100 El Camino Real Menlo Park, CA 94025 (415) 322-1234   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9623-0@bells.cs.ucl.ac.uk>; Fri, 18 Jan 1991 10:25:58 +0000 To: osi-ds@uk.ac.ucl.cs Cc: Greg Vaudreuil , Megan Davies , G B Reilly Subject: Problems with the osi-ds postscript Phone: +44-71-380-7294 Date: Fri, 18 Jan 91 10:25:52 +0000 Message-ID: <1140.664194352@UK.AC.UCL.CS> From: Steve Kille Brendan Reilly found that one of the installed postscript files had been corrupted. (draft-ucl-kille-x500domains-01.ps file from the NNSC at BBN). The files contain the string "- -" on many lines. Could someone check to make sure that this file gets fixed, and if the problem is in other files? These have almost certainly been caused by RFC 934 quoting, probably by passing on the file by forwarding it using a mail interface such as MH. Could someone fix the file in question, and check to see if any others are affected? I guess that there may be a need to look at the intallation procedures for postscript Internet Drafts. Note: this problem definitely does NOT affect the files at UCL. Steve   Return-Path: Received: from NRI.RESTON.VA.us by bells.cs.ucl.ac.uk with SMTP inbound id <25899-0@bells.cs.ucl.ac.uk>; Mon, 21 Jan 1991 20:04:00 +0000 Received: from NRI by NRI.NRI.Reston.VA.US id aa02148; 21 Jan 91 15:03 EST To: Steve Kille cc: osi-ds@uk.ac.ucl.cs, Greg Vaudreuil , Megan Davies , G B Reilly , mdavies@us.VA.Reston.NRI Subject: Re: Problems with the osi-ds postscript In-reply-to: Your message of Fri, 18 Jan 91 10:25:52 +0000. <1140.664194352@UK.AC.UCL.CS> Date: Mon, 21 Jan 91 15:03:05 -0500 From: Megan Davies Message-ID: <9101211503.aa02148@NRI.NRI.Reston.VA.US> Steve, The corrected version of draft-ucl-kille-x500domains-01.ps will be posted to the shadow directories tonight and should be available tomorrow. I have checked the other internet drafts and they seem fine. Megan   Return-Path: Received: from earn-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <11538-0@bells.cs.ucl.ac.uk>; Tue, 22 Jan 1991 17:37:20 +0000 Received: from UKACRL by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 4377; Tue, 22 Jan 91 17:38:06 GMT Received: from BNR.CA by UKACRL.BITNET (Mailer R2.07) with BSMTP id 9064; Tue, 22 Jan 91 17:37:06 GM Received: by BNR (Mailer R2.04) id 4550; Tue, 22 Jan 91 12:28:22 EST Date: 22 Jan 91 12:26:00 EST To: osi-ds@uk.ac.ucl.cs, quipu@uk.ac.ucl.cs From: Peter (P.W.) Whittaker Subject: Using X.500 for YellowPages Sender: Peter (P.W.) Whittaker I've been researching usage and performance metrics for various types of directory/lookup facilities used within BNR, including YellowPages, in order to learn what sort of DSA performance would be needed if we were to cut all such software over to X.500 today (I'm not saying I'm going to :->). In order to make the metrics realistic, I've got to get a better idea of how other directory/lookup applications would use X.500. To that end, are any of you X.500 pioneers using X.500 to simulate/replace YellowPages? If so, are you replacing the YPClients, YPServers, or both (one attractive scenario is to keep vanilla YPClients in order to maintain vendor support for the clients, but to "hybridize" and X.500/YPserver). Please send replies, comments, queries, et. al., directly to me. I will post a summary of there are sufficient results and interest (out of curiosity, could you tell me which of the two mailing lists you read this in: quipu or osi-ds? Thanks). Peter Whittaker [%%%%%%%%%%%%%%%%%%%%%%%%%%] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6596-0@bells.cs.ucl.ac.uk>; Wed, 23 Jan 1991 09:01:55 +0000 To: osi-ds@uk.ac.ucl.cs cc: osiawd@edu.wisc.cs Subject: Recent Interent Drafts announced Phone: +44-71-380-7294 Date: Wed, 23 Jan 91 09:01:54 +0000 Message-ID: <622.664621314@UK.AC.UCL.CS> From: Steve Kille For those of you on the IETF list, I just want to clarify the two Internet Drafts just announced: draft-ucl-kille-presentationaddress-02.txt (A String encoding of Presentation Address) This is the november document (v-01), with the text form updated so that it will print on normal lineprinters (i.e., no techincal or editorial changes) draft-ietf-osix500-directories-01.txt (Building and Internet Directory using X.500) This is the version sent to the osi-ds list before Christmas, and with minor edits sumitted as an RFC on Jan 3rd. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19583-0@bells.cs.ucl.ac.uk>; Wed, 23 Jan 1991 10:21:28 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Meeting at SRI on 12/13 Feb Phone: +44-71-380-7294 Date: Wed, 23 Jan 91 10:21:27 +0000 Message-ID: <1110.664626087@UK.AC.UCL.CS> From: Steve Kille I was asked if there was any intention to cancell this meeting in view of the Gulf crisis. I intend that this meeting will go ahead as planned, unless I get a very strong indication that many critical people cannot attend for this reason, or if the situation changes significantly. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5065-0@bells.cs.ucl.ac.uk>; Fri, 25 Jan 1991 08:31:03 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Attendance at the Feb 12-13 meeting Phone: +44-71-380-7294 Date: Fri, 25 Jan 91 08:31:03 +0000 Message-ID: <256.664792263@UK.AC.UCL.CS> From: Steve Kille Could you let me know if you plan to attend? thanks Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <20144-0@bells.cs.ucl.ac.uk>; Fri, 25 Jan 1991 13:55:59 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Meetings of the WG Phone: +44-71-380-7294 Date: Fri, 25 Jan 91 13:55:58 +0000 Message-ID: <1925.664811758@UK.AC.UCL.CS> From: Steve Kille Some of you have assumed that there will be a WG meeting at the IETF in March. I was not planning to hold a WG meeting in St Louis, as it is only a month after the SRI meeting. This dcisions might be reversed, but it would be on the basis of work done at the SRI meeting, not because of discussion on this list. If there was a meeting at St Louis, it would likely be for half a day. The main work will go on at SRI. Summary: if you care about this WG, come to SRI. Steve   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <13277-5@bells.cs.ucl.ac.uk>; Sun, 27 Jan 1991 17:46:10 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Sat, 26 Jan 1991 21:57:30 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Sat, 26 Jan 1991 21:55:58 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Sat, 26 Jan 1991 22:52:00 +0000 Date: Sat, 26 Jan 1991 21:55:58 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.022:26.00.91.21.55.58] X400-Content-Type: P2-1984 (2) Content-Identifier: RE: Draft Age... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"3023 Sat Jan 26 22:56:01 1991"@surver.surfnet.nl> To: S.Kille@uk.ac.ucl.cs, "RARE (038) IETF OSI-DS wg" Subject: RE: Draft Agenda X-VMS-To: IN%"S.Kille@cs.ucl.ac.uk" Comments: EARN/BITnet: HUIZER@HUTSUR51 Sender: HUIZER@nl.surfnet Steve, > 16:30 Security (Discussion of Peter Yee's revised document) Where can I get this? > 9:00 Progress of operational pilots (FOX, PSI, Paradise (used to be > COSINE P2.1)) Could you or Dave enlighten me asap on this Paradise. I'm having a talk on WG3 and Cosine P2.1 on Monday, and I would like to report the latest developments. Certainly if it concerns the name of the project. Last remark: Shouldn't we try to make a start on discussing your paper on reliability. I intend to discuss this at the next WG3. Erik   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <13208-170@bells.cs.ucl.ac.uk>; Sun, 27 Jan 1991 18:07:08 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <23642-28@sun2.nsfnet-relay.ac.uk>; Sat, 26 Jan 1991 01:37:56 +0000 Received: from [192.33.33.110] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa11668; 26 Jan 91 0:52 GMT Received: by ws10.nisc.sri.com (5.64/SRI-NISC1.1) id AA00427; Fri, 25 Jan 91 15:06:59 -0800 Message-Id: <9101252306.AA00427@ws10.nisc.sri.com> To: Steve Kille Cc: osi-ds@uk.ac.ucl.cs, rlang@com.SRI.NISC Subject: Re: Draft Agenda In-Reply-To: Your message of "Fri, 25 Jan 91 17:20:56 GMT." <2585.664824056@UK.AC.UCL.CS> Date: Fri, 25 Jan 91 15:06:57 PST From: Ruth Lang Sender: rlang@com.sri.nisc Steve, The subject of adopting a standard API for the pilot was raised under AOB at the last meeting. Can a discussion on this topic be squeezed into the schedule? Ruth Lang   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3957-0@bells.cs.ucl.ac.uk>; Mon, 28 Jan 1991 09:39:25 +0000 To: Ruth Lang cc: osi-ds@uk.ac.ucl.cs Subject: Re: Draft Agenda Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 25 Jan 91 15:06:57 -0800. <9101252306.AA00427@ws10.nisc.sri.com> Date: Mon, 28 Jan 91 09:39:22 +0000 Message-ID: <409.665055562@UK.AC.UCL.CS> From: Steve Kille I'll add this to the Agenda. Steve >From: Ruth Lang >To: Steve Kille >Subject: Re: Draft Agenda >Date: Fri, 25 Jan 91 15:06:57 PST > >Steve, >The subject of adopting a standard API for the pilot was raised >under AOB at the last meeting. Can a discussion on this topic >be squeezed into the schedule? >Ruth Lang   Return-Path: Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11639-0@bells.cs.ucl.ac.uk>; Mon, 28 Jan 1991 11:46:40 +0000 To: Erik.Huizer@nl.surfnet cc: S.Kille@uk.ac.ucl.cs, "RARE (038) IETF OSI-DS wg" Subject: Re: Draft Agenda In-reply-to: Your message of Sat, 26 Jan 91 21:55:58 +0000. <"3023 Sat Jan 26 22:56:01 1991"@surver.surfnet.nl> Date: Mon, 28 Jan 91 11:46:38 +0000 From: D.Goodman@uk.ac.ucl.cs Erik >> 9:00 Progress of operational pilots (FOX, PSI, Paradise (used to be >> COSINE P2.1)) > Could you or Dave enlighten me asap on this Paradise. I'm having a talk on > WG3 and Cosine P2.1 on Monday, and I would like to report the latest > developments. Certainly if it concerns the name of the project. As a result of the outline discussion at the WG3 meeting in Brussels on an acronym for COSINE P2.2, COSINE P2.1 felt the urge to present itself with its own glorious naming schema and, following the well-established traditions of DG XIII projects in the Computer Science Department at UCL, decided (by default as much as any overwhelming clamouring) at a project meeting last week on the following: Piloting A ReseArchers DIrectory Service In Europe Hence, PARADISE. And, POPS for PARADISE Operations etc. How extensively we use the name remains to be seen but the possibilities are intriguing. For example, the Tree of Knowledge in the Garden ... A user's guide called "Stranger in Paradise" ... Best heavenly wishes David   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11295-0@bells.cs.ucl.ac.uk>; Mon, 28 Jan 1991 11:29:34 +0000 To: Erik.Huizer@nl.surfnet cc: "RARE (038) IETF OSI-DS wg" Subject: Re: Draft Agenda Phone: +44-71-380-7294 In-reply-to: Your message of Sat, 26 Jan 91 21:55:58 +0000. <"3023 Sat Jan 26 22:56:01 1991"@surver.surfnet.nl> Date: Mon, 28 Jan 91 11:29:28 +0000 Message-ID: <1126.665062168@UK.AC.UCL.CS> From: Steve Kille >From: Erik.Huizer@nl.surfnet >To: S.Kille@uk.ac.ucl.cs, "RARE (038) IETF OSI-DS wg" >Subject: RE: Draft Agenda >Date: Sat, 26 Jan 1991 21:55:58 +0000 >Comments: EARN/BITnet: HUIZER@HUTSUR51 >Steve, >> 16:30 Security (Discussion of Peter Yee's revised document) >Where can I get this? I hope that Peter will be circulating this with plenty of time for discussion on the net! >Last remark: >Shouldn't we try to make a start on discussing your paper on reliability. I >intend to discuss this at the next WG3. Well - I sent out a note on relibilty/quality of service (including a suggestion as to how we might go about improving things) and asked if anyone thought that it was a good idea/worth pursuing. I got zero response, and so stacked it. Clearly something needs to happen in this area. Is it worth recirculating my note? Is someone prepared to do some work to evolve this into a project agreement? Does anyone else have any good ideas? If I get some indication of interest, I'll add this to the agenda. >Erik Steve   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <22576-0@bells.cs.ucl.ac.uk>; Mon, 28 Jan 1991 14:56:14 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Mon, 28 Jan 1991 14:55:01 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 28 Jan 1991 14:20:39 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 28 Jan 1991 15:16:00 +0000 Date: Mon, 28 Jan 1991 14:20:39 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.704:28.00.91.14.20.39] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Draft Age... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"4705 Mon Jan 28 15:20:43 1991"@surver.surfnet.nl> To: D.Goodman@uk.ac.ucl.cs, "RARE (038) IETF OSI-DS wg" Subject: Re: Draft Agenda X-VMS-To: IN%"D.Goodman@cs.ucl.ac.uk" Comments: EARN/BITnet: HUIZER@HUTSUR51 Sender: HUIZER@nl.surfnet David, > How extensively we use the name remains to be seen but the possibilities are > intriguing. For example, the Tree of Knowledge in the Garden ... A user's > guide called "Stranger in Paradise" ... Hmm, The first connections my mind makes are less encouriging: I hope we get to see more of the project then just "Paradise by the dashboard light" and I certainly hope that Milton was wrong in chosing his title Paradise Lost. I wonder where the Appel is hiding: Anti Personal and Private Entities League Anyway it is hard to imagine a Paradise in London :-) Erik   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <283-0@bells.cs.ucl.ac.uk>; Tue, 29 Jan 1991 12:32:45 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Liaison from NIST OIW Phone: +44-71-380-7294 Date: Tue, 29 Jan 91 12:32:42 +0000 Message-ID: <1422.665152362@UK.AC.UCL.CS> From: Steve Kille I have received the following liaison from the NIST OIW. We can discuss a response from the group at the SRI meeting. I will send a personal comment in just a minute. Others are welcome to do the same. Steve ------- Forwarded Message From: scain@com.hp.cup.hpindeg To: att!cs.ucl.ac.uk!S.Kille@uk.ac.ucl.cs, att!arch2!youbong@com.hp.cos.h p-lsd Date: Mon, 28 Jan 91 13:36:47 PST I am forwarding this letter to you on behalf of You-Bong Weon-Yoon. Please forward the following message to the members of the DIrectory Service Group you are chairing for hte IETF. This letter was approved by the DIrectory Service SIG at the December, 1990 meeting in Gaithersburg, MD. - ------------------------------------- Date: January 28, 1991 From:OIW DIrectory Service SIG To: IETF Directory Service Group The Directory Service SIG of the OIW recognizes the work the IETF is completing on introducing a X.500 Directory Service in the Internet. The SIG wants to inform the IETF Directory Service Group of its intentions on having Implementation Agreements on Replication & Access Control completed by December, 1991. With this in mind, the SIG wants to make sure the IETF's requirements for Replication & Access Control are incorporated in the Implementation Agreements. In addition, the SIG would like the IETF Directory Group to help the Directory Service SIG complete these Agreements on Replication & Access Control by actively reviewing the Directory Service SIG's work and providing comments. Sincerely, You-Bong Weon-Yoon Chair, OIW Directory Service SIG ------- End of Forwarded Message   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <1001-0@bells.cs.ucl.ac.uk>; Tue, 29 Jan 1991 12:59:21 +0000 To: youbong@com.att.arch2 cc: dssig@com.sri.nisc, osi-ds@uk.ac.ucl.cs, scain@com.hp.cup.hpindeg Phone: +44-71-380-7294 In-reply-to: Your message of Mon, 28 Jan 91 13:36:47 -0800. <9101282136.AA00907@hpindeg.cup.hp.com> Date: Tue, 29 Jan 91 12:59:14 +0000 Message-ID: <1477.665153954@UK.AC.UCL.CS> From: Steve Kille You-Bong, Thank you for your positive liaison. Let me make a few informal comments as chair of the IETF WG, both to you and to members of your SIG. I expect that we will send you a more formal reply following our next meeting. I am glad to hear that you are undertaking this task, and that you are taking the Internet requirements in to account. We would be happy to discuss these with you if clarification is needed. We have a working document on requirements for replication, and I expect that our working document on security will lead to a number of requirements on access control. I will be happy to make your documents available to the WG. We do not have a paper distribution, so to enable effective comment you should supply text or postscript versions of any documents. I can place these in the WG's document archive. The decision to spend effort on actively reviewing these documents is clearly up to the group as a whole, but it is appropriate for the group to do and I would expect that we will be happy to take this on. The OSI-DS group is an open group. We have a mailing list, which covers both the Internet IETF WG and the Directory Subgroup of RARE WG3 (European). All members of DSSIG are invited to join this list. Send to to be added. There is an archive of documents which can be accessed by a variety of means. I append the latest index. Our next meeting is a SRI (Bay Area) on February 12-13th. I gather that at least one person from the DSSIG will be present. Any others who can find time to attend will be welcome. regards Steve INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 4) S.E. Kille December 22, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS minutes-1-oct90.txt 1st Meeting, San Jose, Oct 90 ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps Building and Internet Directory using X.500 S.E. Kille December 1990 draft-ietf-osix500-directories-01.txt Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b ]. This document summarises the strategy established by the working group, and describes a number of RFCs which will be written in order to establish the technical framework. nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille draft-ucl-kille-networkaddresses-02.txt, .ps January 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-02.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. domain.ps domain.txt Domains and X.500 S.E. Kille Novmember 1990 Abstract: This INTERNET-DRAFT considers X.500 in relation to Internet/UK Do- mains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille January 1991 draft-ietf-osids-friendlynaming-01.txt, .ps Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. repl-req.ps repl-req.txt Replication Requirement to provide an Internet Directory using X.500 S.E. Kille January 1991 draft-ietf-osids-replication-01.txt, .ps Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90 ]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This INTERNET--DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. na.txt P. Barker S.E. Kille January 1991 draft-ietf-osids-cosinex500-02.txt The COSINE and Internet X.500 Naming Architecture Abstract: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, and comments on the updating mechanisms are particularly welcome. Corrections and additions to the naming architecture should now be sent the list, as described within. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . repl-sol.txt repl-sol.ps Replication to provide an Internet Directory using X.500 S.E. Kille January 1991 draft-ietf-osids-friendlynaming-01.txt, .ps Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point. ------------------------------------------------------------------------   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <8628-0@bells.cs.ucl.ac.uk>; Tue, 29 Jan 1991 15:26:08 +0000 Received: from terminator.cc.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA24547; Tue, 29 Jan 91 10:25:51 -0500 Message-Id: <9101291525.AA24547@terminator.cc.umich.edu> To: Steve Kille Cc: osi-ds@uk.ac.ucl.cs Subject: Re: Liaison from NIST OIW In-Reply-To: Your message of "Tue, 29 Jan 91 12:32:42 GMT." <1422.665152362@UK.AC.UCL.CS> Date: Tue, 29 Jan 91 10:25:48 -0500 From: Tim Howes > Date: January 28, 1991 > From:OIW DIrectory Service SIG > To: IETF Directory Service Group > > The Directory Service SIG of the OIW recognizes the work the IETF > is completing on introducing a X.500 Directory Service in the > Internet. > > The SIG wants to inform the IETF Directory Service Group of its > intentions on having Implementation Agreements on Replication & Access > Control completed by December, 1991. With this in mind, the SIG wants to > make sure the IETF's requirements for Replication & Access Control are > incorporated in the Implementation Agreements. > > In addition, the SIG would like the IETF Directory Group to help the > Directory Service SIG complete these Agreements on Replication & > Access Control by actively reviewing the Directory Service SIG's work > and providing comments. I'd like to see a little more work done on replication by the ietf ds wg. The current plan of staying with Quipu's method of replication does not have me too excited, since it is not adequate for our needs. From what I've seen of the standards committee working document on this, a subset of what they're proposing shouldn't be too hard to add to Quipu. I guess I might even volunteer for something... I have no idea what the implementation agreements state. I look forward to hearing about this at the next meeting. -- Tim   Return-Path: Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13636-0@bells.cs.ucl.ac.uk>; Tue, 29 Jan 1991 17:08:13 +0000 To: Erik.Huizer@nl.surfnet cc: D.Goodman@uk.ac.ucl.cs, "RARE (038) IETF OSI-DS wg" Subject: Re: Draft Agenda In-reply-to: Your message of Mon, 28 Jan 91 14:20:39 +0000. <"4705 Mon Jan 28 15:20:43 1991"@surver.surfnet.nl> Date: Tue, 29 Jan 91 17:08:11 +0000 From: D.Goodman@uk.ac.ucl.cs Erik >> How extensively we use the name remains to be seen but the possibilities are >> intriguing. For example, the Tree of Knowledge in the Garden ... A user's >> guide called "Stranger in Paradise" ... > Hmm, The first connections my mind makes are less encouriging: > I hope we get to see more of the project then just "Paradise by the > dashboard light" and I certainly hope that Milton was wrong in choosing his > title Paradise Lost. Points taken! However this project will get nowhere if we don't think positively; and what about Milton's sequel "Paradise Regained"? Hmmm > I wonder where the Appel is hiding: > Anti Personal and Private Entities League Possibly: A Personal, Private Leaf Entry? > Anyway it is hard to imagine a Paradise in London :-) There is a dubious nightclub called Heaven but otherwise undoubtedly true and one of several good reasons for holding meetings in exotic locations. David   Return-Path: Received: from earn-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <8845-0@bells.cs.ucl.ac.uk>; Wed, 30 Jan 1991 19:09:18 +0000 Received: from UKACRL by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 6638; Wed, 30 Jan 91 19:09:43 GMT Received: from BNR.CA by UKACRL.BITNET (Mailer R2.07) with BSMTP id 7025; Wed, 30 Jan 91 19:09:42 GM Received: by BNR (Mailer R2.04) id 8209; Wed, 30 Jan 91 14:05:30 EST Date: 30 Jan 91 13:57:00 EST To: ietf-osi-x400@edu.WISC.CS, osi-ds@uk.ac.ucl.cs From: Peter (P.W.) Whittaker Subject: X/OPEN API Sender: Peter (P.W.) Whittaker The IETF X.500 qroup has expressed interest in the adoption of an API standard for the Internet X.500 trials. Since the X/OPEN X.400 and X.500 APIs share an Object Management component, and this topic might be of interest to both X.400 and X.500 IETFers,I have sent this message to both lists. The adoption of a standard API would seem destined to make the lives of X.500 and X.400 application writers much eaiser, but may complicate the lives of API implementors beyond belief. The reason for this is the apparent "looseness" of the OM specifications. The X/OPEN specifications require the application programmer (i.e. DUA builder) to first create a "workspace", which will be used to manipulate and store information passed to X.500 or X.400 API. The APIs themselves are well defined, as are the routines used for accessing the "workspace", but the workspace internals are left the X.OPEN implementor. The X/OPEN documents would seem to imply that the workspace is application dependent, i.e. that you might end up with as many OMs as you have APIs (one X.400 specific OM, one X.500 specific OM, etc....). In fact, you might end up with several OMs per X.xxx, as you might have several OEM APIs (i.e. each OEM's implementation of the API would have its own OM). The advantage of this is that it allows considerable experimentation and tailoring of OMs to suit various X.xxx implementations, various platforms, etc.... The disadvantages are: 1) APIs might develop dependencies on internal hooks into OM code, 2) each implementation of X.xxx requires its own OM, and 3) X.400 and X.500 (to name two possible X.xxx - there may be more! - users of the X/OPEN OM) cannot necessarily share the same OM. 1) should not be a problem - but let's be realistic. If people can see through your OM and find a better way of manipulating its internals, they'll do it. Telling them not to doesn't seem to be in the spirit of Internet pilots. 2) if users of QUIPU develop an X/OPEN compliant API, they might not be able to share it with non-QUIPU users participating in the pilot - why should each site have to reinvent the wheel? Furthermore, if any particular implementation of X.x00 changes "too much" from release to release, the OM may have to change, and that might entail a significant amount of work - perhaps enough to justify not using X/OPEN at all. 3) this seems to defeat the idea of a common OM altogether - why have a common OM if X.400 and X.500 require different OMs? Please note that we've just started playing with the X/OPEN specifications; any comments, criticisms, or compliments are welcome. Peter Whittaker [%%%%%%%%%%%%%%%%%%%%%%%%%%] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7   Return-Path: Received: from att.att.com by bells.cs.ucl.ac.uk with SMTP inbound id <26766-0@bells.cs.ucl.ac.uk>; Thu, 31 Jan 1991 22:34:52 +0000 From: morgano@com.att.ihlpa Date: Thu, 31 Jan 91 15:55 CST Original-From: ihlpa!morgano (Lisa M Connelly +1 708 979 6832) To: osi-ds@uk.ac.ucl.cs Subject: DNS/X.500 software Does anyone know of commercially available software that interfaces X.500 servers with the DNS? (just interested in its existence, doesn't matter what platform it supports) Thanks, lisa.m.connelly@ih.att.com   Return-Path: Received: from att.att.com by bells.cs.ucl.ac.uk with SMTP inbound id <16468-0@bells.cs.ucl.ac.uk>; Fri, 1 Feb 1991 00:30:44 +0000 From: youbong@com.att.arch2 Date: Thu, 31 Jan 91 17:10 EST To: osi-ds@uk.ac.ucl.cs Cc: dssig@com.sri.nisc Subject: clarification on the OIW letter IETF OSI-DS members, I would like to clarify one point regarding the liaison letter that OIW Directory Service SIG sent out. Clarification: Implementation Agreements on Replication and Access Control that the SIG plans to complete by December, 1991 will be based on DIS and DAM versions of the Directory Standards. Youbong Weon-Yoon Chair, OIW Directory Service SIG ------------------------------------- Date: January 28, 1991 From:OIW DIrectory Service SIG To: IETF Directory Service Group The Directory Service SIG of the OIW recognizes the work the IETF is completing on introducing a X.500 Directory Service in the Internet. The SIG wants to inform the IETF Directory Service Group of its intentions on having Implementation Agreements on Replication & Access Control completed by December, 1991. With this in mind, the SIG wants to make sure the IETF's requirements for Replication & Access Control are incorporated in the Implementation Agreements. In addition, the SIG would like the IETF Directory Group to help the Directory Service SIG complete these Agreements on Replication & Access Control by actively reviewing the Directory Service SIG's work and providing comments. Sincerely, You-Bong Weon-Yoon Chair, OIW Directory Service SIG   Return-Path: Received: from earn-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <8297-0@bells.cs.ucl.ac.uk>; Fri, 1 Feb 1991 15:44:03 +0000 Received: from UKACRL by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 8050; Fri, 01 Feb 91 15:40:33 GMT Received: from BNR.CA by UKACRL.BITNET (Mailer R2.07) with BSMTP id 2029; Fri, 01 Feb 91 15:40:31 GM Received: by BNR (Mailer R2.04) id 2213; Fri, 01 Feb 91 10:36:32 EST Date: 1 Feb 91 10:27:00 EST To: osi-ds@uk.ac.ucl.cs From: Peter (P.W.) Whittaker Subject: OIW liason & Replication Sender: Peter (P.W.) Whittaker I have an opportunity to express the IETF OSI-DS WG's concerns with the current status of the Replication to a CCITT representative. I would appreciate receiving your comments vis a vis the status of the Replication work by the afternoon of Monday, February 4, 1991. While comments concerning any facet of the Replication work are welcome, please focus on those "shortcomings" identified at the Boulder meeting, i.e. lack of checkpointing during a push or pull, lack of epoch setting, possible conflicts between overlapping areas of replication, and the concern that the method, as currently proposed, is a 2-party methodology applied to an n-party reality. Other possible areas of concern are knowledge representation, incremental replication, etc.... Please bear in my mind that time is of the essence (i.e. flames > /dev/null). Thank you, Peter Whittaker [%%%%%%%%%%%%%%%%%%%%%%%%%%] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <23507-0@bells.cs.ucl.ac.uk>; Tue, 5 Feb 1991 12:09:03 +0000 To: osi-ds@uk.ac.ucl.cs cc: Mark Knopper , Chris Weider Subject: Use of the directory for site contacts Phone: +44-71-380-7294 Date: Tue, 05 Feb 91 12:09:00 +0000 Message-ID: <893.665755740@UK.AC.UCL.CS> From: Steve Kille The Merit people are doing some interesting work on use of X.500, which I think is of quite a bit of interest to this WG. Mark Knopper is going to talk about this at the SRI meeting. We can examine how this relates to other aspects of piloting. Steve Expanding the Scope of X.500: Experimental Internet Site Contacts Data Base Chris Weider, Merit 1. Introduction X.500 is a protocol which resides in the Application Layer of the OSI protocol suite, and defines a global network directory. It is a distributed, heirarchically structured directory with these features: * Decentralized Maintenance: Each site running such a Directory is responsible ONLY for its local part of the Directory, so updates and maintenance can be done instantly. * Authoritative Local Information: Since each site is responsible only for local information, backups need only be kept locally. * Structured Directory Information: Since each site resides in a specified location in the global heirarchy, Directory searches are made much more efficient. 2. How X.500 works The abstract X.500 server contains two pieces: a Directory User Agent (DUA) and a Directory Service Agent (DSA). The worldwide collection of DSAs form a vast distributed directory, and the fact that the DSAs are hierarchically ordered allows each DSA to contact all the others without maintaining huge location tables. The DUA acts as an interface between the user and the DSAs. The DUA, when handed a request by a user, contacts the "nearest" DSA. If that DSA does not have the requested information, but suspects that another DSA may contain the information, a referral/chaining process is initiated to allow the information to be obtained from other DSA(s). To the user, it looks as if the entire global directory resides locally. 3. The White Pages Project Implementation of X.500 There are a number of pilot directory projects in the internet community, and notably PSI is supporting a White Pages Project for the USA. The White Pages Project is based on the ISODE (Marshall Rose) and QUIPU (University College London) software, and is fairly widely used as a directory of organizations and people. It is based on X.500 and has several user agent programs. Merit joined the White Pages Project in 1990, and now operates three parts of the Directory Information Tree: 1) a directory of Merit Computer Network staff members, 2) a directory of the customers of Sprintmail in support of the Sprintmail X.400/Internet gateway, and 3) a Site Contacts directory for the internet. 4. Merit adds Internet Site Contact Info In cooperation with the SRI-NIC, some of the information on network infrastructure for the internet kept in the "whois" database has now been entered in the X.500 Directory. This has been done on a prototype basis, and it is expected that further work will be done in this area. Currently the network-contacts and autonomous system information have been entered and are available under the @o=Internet@ou=Site Contacts position in the White Pages Project Directory. The network-contacts and autonomous system information is updated from the NIC master files weekly. Merit has also created an expanded user interface that allows access to this Site Contact and AS information via X.500. 5. Merit helps You get X.500 access Since configuring and maintaining a DSA is quite a chore, Merit will assist you in getting access to X.500 by showing you how to set up a DUA which can speak to Merit's DSA, and through that, to the global DSA. Merit will assist you in this by providing: a) Directions to set up ISODE and QUIPU. b) A user group and mailing list for discussion of advances and problems. c) The specialized user interface to access Merit's new information. 6. How to set up ISODE and QUIPU. To access Merit's DSA, you will need to start your own DUA. To do this, please determine whether your organization is currently running ISODE and QUIPU, and follow the instructions below. If you have any difficulties with the installation procedures, please contact clw@merit.edu. a) Running both ISODE and QUIPU If you are currently running both ISODE and QUIPU, you probably already have a DSA running, and all you need to know is that Merit's branch of the Directory tree is @c=us@o=Merit Computer Network, and that the site contact information is in the @o=Internet@ou=Site Contacts branch of the tree. There are some programs available for anonymous ftp from merit.edu to aid in searches through the Site Contacts information. The guide to the labyrinth is in a READ.ME file in the directory pub/x500. b) Running ISODE only If you are running ISODE but not QUIPU, you will need to issue the following instuctions from the topmost ISODE directory as the superuser: > ./make once-only all-quipu > ./make inst-quipu These commands will probably take a while to execute. After they have finished, you'll need to > find . -name dsaptailor -print and then cd to the directory in which dsaptailor resides. You'll then need to edit the dsaptailor file and make the following additions: find the line: # the level-1 DSA and add underneath it the line dsa_address "white-nosed-saki" '0101'H/Internet=35.1.1.42+17003 which tells your DUA that Merit's DSA resides at 35.1.1.42 on port 17003. Then find the line local_DIT "c=US" and edit it to read local_DIT "c=US@o=Merit Computer Network" which tells the DUA which part of the Directory you're starting in. After you have made these changes, run dish(1c) by typing > dish -c "white-nosed-saki" The documentation to all for all of these programs and many more are available for anonymous FTP from merit.edu. In addition, the documentation and special user interfaces created by Merit are also available for anonymous FTP from the same location. c) Running neither ISODE nor QUIPU The ISODE installation documents are in a 'tar'ed postscript file available for anonymous ftp from merit.edu. FTP that file, untar it, and print it out, and then follow the instructions in Chapter 2, "Installation and Configuration". Then, after everything is installed and looks happy, find the dsaptailor file and edit it as detailed in section 6b above. The documentation and special user interfaces created by Merit are also available for anonymous FTP from the same location. 7. System requirements ISODE runs on many hardware platforms. The source files and binarys will take up approximately 50 Mbytes of space, so be sure to install it in a machine with a fair amount of free space. 8. Questions and Problems The mailing list for the User's Group is x500-group@merit.edu. To be added to this list, send your request to x500-group-request@merit.edu. We'll be glad to share our experiences with x500 with this group, and assist where we can. For problems with the ISODE system software, contact Bug-ISODE@NISC.NYSER.NET. 9. How to get this great offering For more information on this great offering, or to get started, contact Chris Weider at clw@merit.edu. Mail daemons are standing by. ------- End of Forwarded Message   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17753-0@bells.cs.ucl.ac.uk>; Thu, 7 Feb 1991 11:53:05 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Agenda for the SRI Meeting Phone: +44-71-380-7294 Date: Thu, 07 Feb 91 11:53:00 +0000 Message-ID: <952.665927580@UK.AC.UCL.CS> From: Steve Kille Agenda for third meeting of IETF Directory Services Group (Revision 1) S.E. Kille February 7, 1991 Date 9:00 -- 18:00: Tuesday 12th February 1991 9:00 -- 15:00: Wednesday 13th February 1991 Venue SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 Draft agenda follows. 1 Tuesday 9:00 Introduction o Agenda o Minutes of previous meeting o Matters arising 9:30 Liaisons o RARE WG3 o ISO/CCITT o NIST o NADF 1 10:00 Replication and related issues -- requirements. Internet Drafts: o Replication Requirement to provide an Internet Directory using X.500 o Replication to provide an Internet Directory using X.500: A proposed solution o An Interim Approach to use of Network Addresses o A String encoding of Presentation Address This may continue after lunch if needed. 12:00 Lunch 13:30 APIs for the Pilot 13:45 User Friendly Naming (Internet Draft: Using the OSI Directory to achieve User Friendly Naming) 15:00 Relationship to DNS (Internet Draft: Domains and X.500) 16:00 Representation of Networks, operational information and associated information in the directory: o Presentation of Merit Work (Mark Knopper) o Relationship to "Domains and X.500" draft 17:15 DSA Naming and related issues (Proposed I-D; DSA Naming) 18:00 End 2 Wednesday 9:00 Progress of operational pilots (FOX, PSI, Paradise (used to be COSINE P2.1)) 9:45 Monthly reports on pilot progress 10:00 Schema (Internet Draft: Cosine and Internet Naming Architecture) 11:00 Naming Guidelines for the Internet and Cosine Project (Proposed I-D: Naming Guidelines for Directory Pilots) 12:00 Lunch 2 13:00 Naming for the Internet Pilot (MTR. NADF Naming Guidelines Document) 14:15 Security (Discussion of Peter Yee's revised document) 14:45 Date and Venue of next meeting 14:50 -- 15:00 AOB 3   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17519-0@bells.cs.ucl.ac.uk>; Thu, 7 Feb 1991 11:50:30 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Documents for the Meeting Next week Phone: +44-71-380-7294 Date: Thu, 07 Feb 91 11:50:23 +0000 Message-ID: <920.665927423@UK.AC.UCL.CS> From: Steve Kille I'll give a summary of documents. I append the WG Index, so which contains information on how to retrieve documents. All of the new documents, except Marshall's are in this archive in both text and postscript forms. I'll send round a revised agenda in just a minute. This incorporates a number of changes and suggestion. Domains and X.500 I finally made the updates to this. This has been submitted as an I-D (revised). I have added a number of examples and clarifications. I have been through RFC 1034 and 1035, and sorted out detailed alignment. I have added an appendix as to how we might deploy an effective experiment on this work. Overall plan of the IETF Working Group on OSI Directories (OSI-DS) to build an Internet Directory using X.500 This document used to be called "Building and Internet Directory using X.500". It has undergone editing to be acceptable as an RFC (The process was finally started a few days ago, and a number of changes were asked for). In particular, reference to I-Ds have been removed, and any implication that this is a strategy document. There are no technical changes. A proposed strategy for deploying an OSI Internet Directory It was requested that a strategy document be written. This is beyond the scope of this WG. I have written a draft. I dont't think that we should get too caught up in this, but we should discuss how this might be progressed and what should be in a document. Naming Guidelines for Directory Pilots This suggests a number of naming guidelines which we should adopt for the global pilot, and as national choices. This is a proposed I-D. NADF Contribution on a naming scheme Marshall Rose has sent me a postcript copy of this, which I will circulate to the list (I've been asked not to put it in the archive). This suggests a structure for names under C=US. DSA Naming This looks at the problem of naming DSAs. There are a number of awkward issues, which we will need to tackle. This is a proposed I-D. Peter Yee has promised me an updated version of the Security document. I'm sure that he will send this to you soon! Please do make sure you read all of the contributions before the meeting. I look forward to seeing you all at SRI Steve INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 4) S.E. Kille December 22, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS minutes-1-oct90.txt 1st Meeting, San Jose, Oct 90 ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps A proposed strategy for deploying an OSI Internet Directory S.E. Kille February 1991 Abstract: This document is a first cut at describing an overall strategy for deploying an OSI Directory on the Internet. This is a draft document, and does not carry any implications of agreement on policy. goals.txt goals.ps Overall plan of the IETF Working Group on OSI Directories (OSI-DS) to build an Internet Directory using X.500 S.E. Kille February 1991 Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b]. This document summarises the plan established by the working group to achieve this, and describes a number of RFCs which the working group will write in order to establish the technical framework. This document has now been submitted as an RFC nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille draft-ucl-kille-networkaddresses-02.txt, .ps January 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-02.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. domain.ps domain.txt Domains and X.500 S.E. Kille February 1991 Abstract: This INTERNET--DRAFT considers X.500 in relation to Internet and UK Domains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille January 1991 draft-ietf-osids-friendlynaming-01.txt, .ps Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. repl-req.ps repl-req.txt Replication Requirement to provide an Internet Directory using X.500 S.E. Kille January 1991 draft-ietf-osids-replication-01.txt, .ps Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90 ]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This INTERNET--DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. na.txt P. Barker S.E. Kille January 1991 draft-ietf-osids-cosinex500-02.txt The COSINE and Internet X.500 Naming Architecture Abstract: This document suggests an X.500 Directory Naming Architecture, or Schema, for use in the COSINE and Internet X.500 pilots. The architecture is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processible version of the architecture. This document also proposes a mechanism for allowing the naming architecture to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, and comments on the updating mechanisms are particularly welcome. Corrections and additions to the naming architecture should now be sent the list, as described within. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . repl-sol.txt repl-sol.ps Replication to provide an Internet Directory using X.500 S.E. Kille January 1991 draft-ietf-osids-friendlynaming-01.txt, .ps Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point. structure.ps structure.txt P. Barker S.E. Kille February 1991 Naming Guidelines for Directory Pilots Abstract: Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. dsanaming.ps dsanaming.txt DSA Naming S.E. Kille February 1991 Abstract: This INTERNET--DRAFT describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot. I believe this note to be an important step forward, as it begins to evolve a clear model of a Directory Management Domain. ------------------------------------------------------------------------   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18067-0@bells.cs.ucl.ac.uk>; Thu, 7 Feb 1991 11:57:50 +0000 Return-Path: Received: from cheetah.ca.psi.com by bells.cs.ucl.ac.uk with SMTP inbound id <4342-0@bells.cs.ucl.ac.uk>; Wed, 6 Feb 1991 17:54:35 +0000 Received: from localhost by cheetah.ca.psi.com at Wed, 6 Feb 91 08:43:16 -0800. (5.61.14/XIDA-1.2.8.34) id AA08535 for S.Kille@cs.ucl.ac.uk via SMTP To: Steve Kille Subject: Re: NADF papers for the OSI-DS meeting In-Reply-To: Your message of Wed, 06 Feb 91 16:26:16 +0000. <1576.665857576@UK.AC.UCL.CS> Date: Wed, 06 Feb 91 08:43:14 -0800 Message-Id: <8533.665858594@cheetah.ca.psi.com> From: Marshall Rose Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Thu, 07 Feb 91 11:57:45 +0000 Resent-Message-ID: <1007.665927865@UK.AC.UCL.CS> Resent-From: Steve Kille Here is the current version. You can send it to the list. Just don't put it up for ftp somewhere... I will bring copies for the meeting. /mtr /////// %! /TeXDict 200 dict def TeXDict begin /Resolution 300 def /Inch {Resolution mul} def /Mtrx 6 array def /@letter { letter initmatrix 72 Resolution div dup neg scale 1.0333 Inch 10.0166 Inch neg translate Mtrx currentmatrix pop } def /@note { note initmatrix 72 Resolution div dup neg scale 1.0333 Inch 10.0166 Inch neg translate Mtrx currentmatrix pop } def /@landscape { letter initmatrix 90 rotate 72 Resolution div dup neg scale 1 Inch 1.0333 Inch translate Mtrx currentmatrix pop } def /@legal { legal initmatrix 72 Resolution div dup neg scale 0.9833 Inch 12.933 Inch neg translate Mtrx currentmatrix pop } def /@manualfeed { statusdict /manualfeed true put } def /@copies { /#copies exch def } def /@newfont { /newname exch def pop newname 7 dict def newname load begin /FontType 3 def /FontMatrix [1 0 0 -1 0 0] def /FontBBox [0 0 1 1] def /BitMaps 128 array def /BuildChar {CharBuilder} def /Encoding 128 array def 0 1 127 {Encoding exch /.undef put} for end newname newname load definefont pop } def /ch-image {ch-data 0 get} def /ch-width {ch-data 1 get} def /ch-height {ch-data 2 get} def /ch-xoff {ch-data 3 get} def /ch-yoff {ch-data 4 get} def /ch-tfmw {ch-data 5 get} def /CharBuilder { /ch-code exch def /font-dict exch def /ch-data font-dict /BitMaps get ch-code get def ch-data null eq not { ch-tfmw 0 ch-xoff neg ch-yoff neg ch-width ch-xoff sub ch-height ch-yoff sub setcachedevice ch-width ch-height true [1 0 0 1 ch-xoff ch-yoff] {ch-image} imagemask } if } def /@sf { cvn cvx exec setfont } def /@dc { /ch-code exch def dup 0 get length 2 lt { pop [ <00> 1 1 0 0 8.00 ] } if /ch-data exch def currentfont /BitMaps get ch-code ch-data put currentfont /Encoding get ch-code dup ( ) cvs cvn put } def /@bop0 { } def /@bop1 { pop erasepage initgraphics Mtrx setmatrix /SaveImage save def() pop 0 0 moveto 1 setlinejoin } def /@eop { showpage SaveImage restore() pop } def /@start { @letter } def /@end { end } def /p { moveto } def /r { 0 rmoveto } def /l { lineto } def /rl { rlineto } def /rc { rcurveto } def /np { /SaveX currentpoint /SaveY exch def def newpath } def /st { stroke SaveX SaveY moveto } def /f { fill SaveX SaveY moveto } def /s { show } def /c { c-string exch 0 exch put c-string show } def /c-string ( ) def /ru { /dy exch neg def /dx exch def /x currentpoint /y exch def def newpath x y moveto dx 0 rlineto 0 dy rlineto dx neg 0 rlineto closepath fill x y moveto } def /ellipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix matrix currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix } def /@SpecialDefaults { /hs 8.5 Inch def /vs 11 Inch def /ho 0 def /vo 0 def /hsc 1 def /vsc 1 def /CLIP false def } def /@hsize {/hs exch def /CLIP true def} def /@vsize {/vs exch def /CLIP true def} def /@hoffset {/ho exch def} def /@voffset {/vo excl def} def /@hscale {/hsc exch def} def /@vscale {/vsc exch def} def /@setclipper { hsc vsc scale CLIP { newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto closepath clip } if } def /@beginspecial { gsave /SpecialSave save def currentpoint transform initgraphics itransform translate @SpecialDefaults @MacSetUp } def /@setspecial { MacDrwgs {md begin /pxt ho def /pyt vo neg def end} {ho vo translate @setclipper} ifelse } def /@endspecial { SpecialSave restore grestore } def /MacDrwgs false def /@MacSetUp { userdict /md known { userdict /md get type /dicttype eq { /MacDrwgs true def md begin /psu /psu load { /letter {} def /note {} def /legal {} def statusdict /waittimeout 300 put /page {pop} def /pyt vo neg def /pxt ho def } concatprocs def /od /od load { @setclipper } concatprocs def end } if } if } def /concatprocs { /p2 exch cvlit def /p1 exch cvlit def /p p1 length p2 length add array def p 0 p1 putinterval p p1 length p2 putinterval p cvx } def end TeXDict begin @start %%Title: naming.dvi %%Creator: dvi2ps %%EndProlog 1 @bop0 [ 432 ] /cmbx10.432 @newfont (cmbx10.432) @sf [ 48 41 -2 0 51.970] 65 @dc [<00003FF800000003FFFF0000000FFFFFC000003FF007E00000FF8000F80001FE00003C0003FC00001E0007F000000E000FF0 000007001FE0000007001FE0000003803FC0000003803FC0000003807FC0000003807F80000000007F8000000000FF800000 0000FF8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF8000000000 7F80000000007F80000003807FC0000003803FC0000003803FC0000007801FE0000007801FE0000007800FF000000F8007F0 00001F8003FC00003F8001FE00007F8000FF8001FF80003FF007DF80000FFFFF87800003FFFE038000003FF00180> 48 41 -4 0 49.646] 67 @dc [<003FE00001FFFC0007F07F000FC01F801F800FC03F800FE03F800FE07F0007F07F0007F0FF0007F8FF0007F8FF0007F8FF00 07F8FF0007F8FF0007F8FF0007F8FF0007F87F0007F07F0007F07F0007F03F0007E03F800FE01F800FC00FC01F8003F07E00 01FFFC00003FE000> 32 27 -2 0 34.370] 111 @dc [ 40 27 -3 0 38.189] 110 @dc [<001F8000FFC001F86003F87003F03807F03807F03807F03807F03807F03807F03807F00007F00007F00007F00007F00007F0 0007F00007F00007F00007F00007F00007F00007F000FFFFF0FFFFF01FFFF007F00003F00003F00001F00000F00000F00000 F000007000007000007000007000> 24 38 -1 0 26.732] 116 @dc [ 32 27 -2 0 28.310] 114 @dc [ 16 43 -3 0 19.094] 105 @dc [<0E01FC00000F07FF80000F9E07E0000FF803F0000FF001F8000FE000FC000FE000FE000FE0007F000FE0007F000FE0007F00 0FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F000FE0007F000FE0007F00 0FE000FE000FE000FC000FF000F8000FF801F0000FFE07E0000FE7FF80000FE1FE00000FE00000000FE00000000FE0000000 0FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE0000000FFE0000000 FFE0000000FFE0000000> 40 42 -2 0 38.189] 98 @dc [<003FC3FF8001FFF3FF8003F03BFF8007E00FF80007E007F8000FE007F8000FE003F8000FE003F8000FE003F8000FE003F800 0FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F800 0FE003F8000FE003F8000FE003F8000FE003F800FFE03FF800FFE03FF800FFE03FF800> 40 27 -3 0 38.189] 117 @dc [<01FC03FC0FFF0FFC3F839FFC7F00DF807E007F80FE003F80FE003F80FE003F80FE003F807F003F803F003F803F803F800FE0 3F8007FC3F8000FFFF80000FFF8000003F8000003F8000003F8007003F800F803F801FC03F001FC07E001FC07E000F81F800 07FFF00001FF8000> 32 27 -2 0 33.415] 97 @dc [ 48 41 -3 0 53.797] 78 @dc [ 56 27 -3 0 57.283] 109 @dc [<007FF00003FFFE000FC01F801F0007C03C0001E07C0001F0F80000F8F80000F8F80000F8F80000F87C0001F83E0007F01FFF FFF007FFFFE00FFFFFC01FFFFF801FFFFF003FFFF8003E0000003C000000380000003800000018FF80001FFFE0000FC1F800 1F80FC001F007C003F007E007F007F007F007F007F007F007F007F007F007F007F007F003F007E101F007C381F80FC7C0FC1 FE7C03FFE7F800FF81F0> 32 40 -2 13 34.370] 103 @dc [ 32 41 -4 0 38.189] 83 @dc [<001FE00000FFFC0003F01E0007E007000FC003801F8001C03F8001C07F8000007F0000007F000000FF000000FF000000FF00 0000FF000000FF000000FF000000FF0000007F0000007F0000007F800E003F801F001F803F800FC03F8007E03F8003F01F00 00FFFE00001FF800> 32 27 -2 0 30.551] 99 @dc [ 40 42 -3 0 38.189] 104 @dc [<001FF00000FFFE0003F81F0007E003800FC001C01F8000E03F8000E07F0000007F0000007F000000FF000000FF000000FF00 0000FFFFFFE0FFFFFFE0FF0007E0FF0007E07F0007E07F0007C07F000FC03F800FC01F800F800F801F8007C01F0003F07E00 01FFF800003FE000> 32 27 -2 0 31.506] 101 @dc [ 329 ] /cmbx10.329 @newfont (cmbx10.329) @sf [ 32 31 -2 0 32.890] 70 @dc [<00FF8007FFE00F80701E00183E00187C00007C0000FC0000FC0000FC0000FFFFF8FFFFF8FC00F87C00F87C00F03E00F01E01 E00F83C007FF8001FE00> 24 20 -1 0 23.958] 101 @dc [<181F80001C7FE0001EC1F8001F807C001F007C001F003E001F003E001F003F001F003F001F003F001F003F001F003F001F00 3F001F003E001F003E001F007E001F807C001FE0F8001F7FF0001F1FC0001F0000001F0000001F0000001F0000001F000000 1F0000001F0000001F0000001F0000001F000000FF000000FF000000> 32 32 -2 0 29.040] 98 @dc [ 24 20 -2 0 21.527] 114 @dc [<03F8FF0007FCFF000F06F8001F01F8001F01F8001F00F8001F00F8001F00F8001F00F8001F00F8001F00F8001F00F8001F00 F8001F00F8001F00F8001F00F8001F00F8001F00F800FF07F800FF07F800> 32 20 -3 0 29.040] 117 @dc [<0FE07E3FF8FE7E0DE0FC05E0F803E0F803E0F803E07C03E03C03E01F03E007FBE0007FE00003E00C03E03F03E03F03E03F07 C03F0F801FFF0007FC00> 24 20 -1 0 25.410] 97 @dc [<1E0000007F800000E1C00000C0E00000FC600000FC300000783000000018000000180000001C0000001C0000003E0000003E 0000007F0000007F000000FF800000F9800001F9C00001F0C00001F0C00003E0600003E0600007C0300007C030000F801800 0F8018001F001C00FFE07F80FFE07F80> 32 29 -1 9 27.588] 121 @dc [<01FE0007FF800F07C01E03E03E01F03C01F07C01F87C01F87C01F8FC01F8FC01F8FC01F8FC01F8FE01F0FE01F0FD03E0FDFF C0FCFF00FC10007C00007C01E07C03F03E03F01E03F01F03F00F81E007E0E001FFC0003F00> 24 29 -2 0 26.136] 54 @dc [<2000700018000C000E0006000600030003003B007F00FF00FF00FE007C003800> 16 16 -4 9 14.520] 44 @dc [ 24 29 -4 0 26.136] 49 @dc [<07F0001FFC00381F003C07807E07C07E03E07E03E07E01F03C01F00001F00041F807F9F81FFDF83E05F87C03F87C03F8FC01 F8FC01F8FC01F8FC01F8FC01F0FC01F0FC01F07C01E07C03E03E03C01F07800FFF0001FC00> 24 29 -2 0 26.136] 57 @dc [ 24 20 -2 0 20.618] 115 @dc [<01FF0007FFC01F83F03E00F83E00F87C007C7C007CFC007EFC007EFC007EFC007EFC007EFC007E7C007C7C007C3E00F83E00 F81F83F007FFC001FF00> 24 20 -1 0 26.136] 111 @dc [<01FC0007FF001F81C03F00C03E00607E00007C0000FC0000FC0000FC0000FC0000FC0000FC00007C03007C0FC03E0FC03E0F C01F0FC007FF8001FE00> 24 20 -2 0 23.232] 99 @dc [<387CFEFEFE7C38000000000000387CFEFEFE7C38> 8 20 -4 0 14.520] 58 @dc [ 48 31 -2 0 49.620] 77 @dc [ 32 32 -3 0 29.040] 104 @dc [ 16 32 -2 0 14.520] 108 @dc [<03FFFFC003FFFFC00007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007 E0000007E0000007E0000007E0000007E0000007E0000007E000C007E006C007E006C007E006C007E006E007E00E6007E00C 6007E00C7007E01C7C07E07C7FFFFFFC7FFFFFFC> 32 30 -2 0 36.362] 84 @dc [<387CFEFEFE7C38> 8 7 -4 0 14.520] 46 @dc [ 40 31 -2 0 39.203] 82 @dc [ 32 31 -2 0 35.731] 80 @dc [<3FFC003FFC0007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C0 0007C000FFFC00FFFC0007C00007C00007C00007C00007C00007C3C007C7E003C7E003E7E001F3E000FFC0001F80> 24 32 -1 0 15.972] 102 @dc [ 40 20 -3 0 43.559] 109 @dc [ 32 20 -3 0 29.040] 110 @dc [<81FF00E7FFC0FE01E0F80070E00078E00038C0003CC0003CC0003C00003C00007C0000FC0007F800FFF807FFF00FFFF01FFF C03FFF807FFE007FC000FC0000F80000F00018F00018F000387000387000783800F81E03F80FFF3803FC08> 24 31 -3 0 29.040] 83 @dc [<01F003F807CC0F860F860F860F860F860F800F800F800F800F800F800F800F800F800F80FFFCFFFC3F800F80078003800380 0380018001800180> 16 29 -1 0 20.328] 116 @dc [ 24 31 -2 0 19.823] 73 @dc [ 16 33 -2 0 14.520] 105 @dc [<03F8FF000FFEFF001F07F8003E01F8007E00F8007C00F8007C00F800FC00F800FC00F800FC00F800FC00F800FC00F800FC00 F8007C00F8007C00F8007E00F8003E01F8001F83F8000FFEF80001F8F8000000F8000000F8000000F8000000F8000000F800 0000F8000000F8000000F8000000F8000000F8000007F8000007F800> 32 32 -2 0 29.040] 100 @dc [ 32 31 -2 0 34.342] 69 @dc [ 40 31 -2 0 39.519] 65 @dc [<3FF9FFE0003FF9FFE00007C03E000007C03E000007C03E000007C03E000007C03E000007C03E000007C03E000007C03E0000 07C03E000007C03E000007C03E000007C03E000007C03E000007C03E000007C03E000007C03E0000FFFFFFF000FFFFFFF000 07C03E000007C03E000007C03E000007C03E000007C03E000007C07E0F0007C0FE1F8003E0FE1F8001E0FF1F8000F87F8F80 007FF3FF00000FE0FE00> 40 32 0 0 30.492] 11 @dc [ 40 31 -2 0 40.908] 78 @dc [<0030018000007803C000007803C000007803C00000FC07E00000FC07E00001F60FB00001F60F300001F60F300003E31E1800 03E31E180007C1BE0C0007C1BC0C0007C1BC0C000F80F806000F80F806001F00F803001F00F00300FFE7FE1FE0FFE7FE1FE0> 40 20 -1 0 37.751] 119 @dc [ 32 32 -2 0 27.588] 107 @dc [<01FF000FFFE03F01F878003C78003CF0001EF0001EF0001E70003E3C007C1FFFFC07FFF80FFFF01FFF801C00001800001800 0009FC000FFF000F07801E03C03E03E03E03E03E03E03E03E03E03E01E03DE0F079E07FFFE01FC3C> 24 30 -1 10 26.136] 103 @dc [<0018007000E001C00380038007000E000E001E001C003C003C007800780078007800F800F000F000F000F000F000F000F000 F000F000F80078007800780078003C003C001C001E000E000E0007000380038001C000E000700018> 16 45 -3 11 20.328] 40 @dc [ 16 45 -3 11 20.328] 41 @dc (cmbx10.432) @sf [<7FFFFE7FFFFE7FFFFE00FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE 0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE00F8FE00FF FE00FFFE0007FE00007E00001E00000E00> 24 39 -5 0 34.370] 49 @dc [<007FFFFFE000007FFFFFE000007FFFFFE00000003FC0000000003FC0000000003FC0000000003FC0000000003FC000000000 3FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0 000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC0000000003FC00000 E0003FC000E0E0003FC000E0E0003FC000E0E0003FC000E0E0003FC000E0F0003FC001E0F0003FC001E070003FC001C07800 3FC003C078003FC003C07E003FC007C07F803FC03FC07FFFFFFFFFC07FFFFFFFFFC07FFFFFFFFFC0> 48 40 -2 0 47.819] 84 @dc [<0FC00000003FE00000007C78000000FE3C000000FE1E000000FE0E000000FE0F0000007C0700000038078000000003800000 00038000000001C000000001C000000003E000000003E000000007F000000007F00000000FF80000000FF80000000FF80000 001FDC0000001FDC0000003FDE0000003F8E0000007F8F0000007F070000007F07000000FE03800000FE03800001FC01C000 01FC01C00003FC01E00003F800E00007F800F00007F000700007F0007000FFFE03FF80FFFE03FF80FFFE03FF80> 40 39 -1 12 36.280] 121 @dc [ 40 41 -3 0 46.989] 80 @dc [ 16 42 -3 0 19.094] 108 @dc [ 329 ] /cmr10.329 @newfont (cmr10.329) @sf [<000FC0000070380001C0040003800200070001000E0000801E0000801C0000403C0000407C0000407C00004078000000F800 0000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F8000000780000407C0000407C0000403C0000C0 1C0000C01E0000C00E0001C0070003C0038005C001C009C0007030C0000FC040> 32 33 -3 1 32.828] 67 @dc [<01F800070E001C03803801C03801C07000E07000E0F000F0F000F0F000F0F000F0F000F0F000F07000E07000E03801C03801 C01C0380070E0001F800> 24 20 -1 0 22.727] 111 @dc [ 40 20 -1 0 37.878] 109 @dc [ 24 29 -1 9 25.252] 112 @dc [<01F1FC030DC00603C00E03C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01 C00E01C0FE1FC00E01C0> 24 20 -1 0 25.252] 117 @dc [<01E0031006100E080E080E080E080E080E000E000E000E000E000E000E000E000E000E000E00FFF83E000E000E0006000600 020002000200> 16 28 -1 0 17.676] 116 @dc [<01F8000706000C0100180080380080700000700000F00000F00000F00000FFFF80F00380F003807003807007003807003807 001C0E000E1C0003F000> 24 20 -1 0 20.202] 101 @dc [ 16 20 -1 0 17.803] 114 @dc [ 24 20 -1 0 25.252] 110 @dc [<004008000060180000E01C0000E01C0000F03C0001D03A0001D0320003C8730003887100038861000704E0800704C0800707 C0800E03C0400E0380400E0380401C0380201C0300603C078070FF9FE1FC> 32 20 -1 0 32.828] 119 @dc [ 24 32 -1 0 23.989] 107 @dc [<8F80D060E030C018C01880188018803800700FF03FE07F807800E000C010C010C010403030701F90> 16 20 -2 0 17.929] 115 @dc [<7FF0000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700 00070000070000FFF000070000070000070000070000070000070000070000070600038F00018F0000C600007C00> 24 32 0 0 13.889] 102 @dc [ 24 32 -1 0 25.252] 104 @dc [ 329 ] /cmti10.329 @newfont (cmti10.329) @sf [<1C003300310070803080388038401C001C001C000E000E000E008700470043004380230033000E0000000000000000000000 0000000001C001E001E000C0> 16 31 -4 0 13.939] 105 @dc [<3001C07003303803103807083803083803881C03841C01C01C01C01C01C00E00E00E00E00E00E08E00E04700704700704780 604740602630C01C0F80> 24 20 -4 0 25.555] 110 @dc [<3C0000660000F300007B000031800001800001C00001C00000C00000E00000E00000E00000E0000070000070000070000070 00007000007000003800003800003800003800003800001C00001C00001C00001C0001FFE0000E00000E00000E00000E0000 0E0000070000070000071800033C00033C00019C000078> 24 41 2 9 13.939] 102 @dc [<3000007000003800003800003800003800001C00001C00001C00001C00000E00000E00000E00008E00004703004707804787 804783802661001C1E00> 24 20 -4 0 19.166] 114 @dc [<0F0700308C80705C40703C40F01C40F01C40F00E20F00E00F00E00F00E007807007807007807003807003C03801C03800E03 800707800389C000F180> 24 20 -4 0 23.232] 97 @dc [<1F8000206000401000E00800F00C00F00C00700E00000E00003E0003FC0007F8000FF0000F80000C00000C06000C07000C03 0006010003020000FC00> 24 20 -3 0 18.585] 115 @dc [<1E003100708070807040704038203800380038001C001C001C001C000E000E000E000E000700FFF007000700038003800380 038001C00180> 16 28 -4 0 15.101] 116 @dc [<07C3800C26401C1E20180E20180E201C0E201C07101C07001C07001C07000E03800E03800E03808703804701C04301C04381 C02301C03300E00E00C0> 24 20 -4 0 24.393] 117 @dc [<07C000183800300400700200700100F00000F00000F00000F00000F000007800007800007800003C02001C07001E07800E07 8003008001C100007E00> 24 20 -4 0 20.908] 99 @dc [<07C000183800380400700200700100700000F00000F00000F00000F000007C00007BF000780C003802003C01001C01000E01 0007010001C200007C00> 24 20 -4 0 20.908] 101 @dc (cmr10.329) @sf [<083E000CC3000D01C00F00E00E00E00E00700E00700E00780E00780E00780E00780E00780E00780E00700E00700E00E00F00 E00F01C00EC3800E3E000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0000FE00000E0000> 24 32 -1 0 25.252] 98 @dc [<3C0000620000F10000F08000F0800000400000400000400000200000200000700000700000700000E80000E80001EC0001C4 0001C4000382000382000382000701000701000E00800E00800E00801C00C01E01E0FF83F8> 24 29 -1 9 23.989] 121 @dc [ 16 31 0 0 12.626] 105 @dc [<03F0000E0C001C0200380100380100700000700000F00000F00000F00000F00000F00000F00000700000700000380C00381E 001C1E000E0C0003F800> 24 20 -2 0 20.202] 99 @dc [ 16 2 -1 -9 15.151] 45 @dc [<70F8F8F870> 8 5 -4 0 12.626] 46 @dc [ 32 31 -2 0 29.671] 70 @dc [ 24 20 0 0 23.989] 120 @dc [<0F83C0386720781E10F01E10F00E10F00E10F00E10780E00380E001E0E00078E0000FE00000E00000E00000E00300E00781C 007818003030001FE000> 24 20 -2 0 22.727] 97 @dc [ 16 32 0 0 12.626] 108 @dc [<40201010080804040474FCFCF870> 8 14 -4 9 12.626] 44 @dc [<00200000700000700000700000E80000E80001EC0001C40001C4000382000382000382000701000701000E00800E00800E00 801C00C01E01E0FF83F8> 24 20 -1 0 23.989] 118 @dc [<7FE3FF0007007000070070000700700007007000070070000700700007007000070070000700700007007000070070000700 7000070070000700700007007000070070000700700007007000FFFFFF800700700007007000070070000700700007007000 07007000070070000300F0300380F87801C0787800F06E30001F83E0> 32 32 0 0 26.515] 11 @dc [<03E3F80E1B801C0780380780380380700380700380F00380F00380F00380F00380F00380F003807003807003803803803803 801C0780061B8003E380000380000380000380000380000380000380000380000380000380000380003F80000380> 24 32 -2 0 25.252] 100 @dc [<03FC001C03803000C0600060C00030C00030C00030C000306000703001E00FFFC01FFF803FFE003000003000002000002000 0033E0001E38001C1C00380E00780F00780F00780F00780F00780F00380E001C1C300E3C3003E3300000E0> 24 31 -1 10 22.727] 103 @dc [ 16 31 -1 0 16.414] 73 @dc [<3F006180F0C0F060607000700070007000700070007000700070007000700070007000700070007000700070007000700070 007000F007F0007000000000000000000000000000E001F001F001F000E0> 16 40 2 9 13.889] 106 @dc [ 32 31 -2 0 34.090] 72 @dc [<07FFFE00001F8000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F 0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000800F0010800F0010800F0010800F0010 C00F0030400F0020400F0020600F0060780F01E07FFFFFE0> 32 31 -2 0 32.828] 84 @dc [ 32 31 -2 0 34.721] 68 @dc [ 24 20 -1 0 20.202] 122 @dc [<001F800000F0F00001C0380007801E000F000F000E0007001E0007803C0003C03C0003C07C0003E07C0003E0780001E0F800 01F0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0780001E0780001E07C0003E03C0003C0 3C0003C01E0007800E0007000F000F0007801E0001C0380000F0F000001F8000> 32 33 -3 1 35.353] 79 @dc [<81F800CE0C00F00600E00300C00380C001808001C08001C08001C08001C00001C00003C00003C0000780001F8003FF000FFE 001FFC003FF0007F0000780000F00000F00000E00080E00080E00080E001806001806001803003801007800C198007E080> 24 33 -3 1 25.252] 83 @dc [<000FC000003820000070180000E0080001C0040001C002000380020003800200078001000780010007800100078001000780 0100078001000780010007800100078001000780010007800100078001000780010007800100078001000780010007800100 07800100078001000780010007800100078003800FC007C0FFFC3FF8> 32 32 -2 1 34.090] 85 @dc [ 32 32 -1 0 34.090] 65 @dc [ 40 31 -2 0 41.666] 77 @dc (cmti10.329) @sf [<1F000031C00060E000607000E03800E03C00E01C00E01E00E01E00E01E00700F00700F00700F00700F00380F00380F003C0E 003A0E001D0C001CF0001C00001C00000E00000E00000E00000E00000700000700000700000700003F8000078000> 24 32 -5 0 20.908] 98 @dc [<07C000187000301800700E00700F00F00700F00780F003C0F003C0F003C07801E07801E07801E03C01E01C01E01E01C00E01 C003018001C300007C00> 24 20 -4 0 23.232] 111 @dc [<3C00000062000000F3000000798000003180000001C0000001C0000000C0000000E0000000E0038000E0064000E00E200070 0E2000700E2000700E2000700710007007000038070000380700003803800038038000380380001C0380001C01C0001C01C0 001C01C0001C01C0000E00E000FFFFE0000E0000000E0000000E000000070000000700000007000000070030000380780003 8078000180380000E01000003FE0> 32 41 2 9 25.555] 12 @dc [<0F0700308C80705C40703C40F01C40F01C40F00E20F00E00F00E00F00E007807007807007807003807003C03801C03800E03 800707800389C000F1C00001C00001C00000E00000E00000E00000E00000700000700000700000700003F8000078> 24 32 -4 0 23.232] 100 @dc (cmr10.329) @sf [ 32 31 -2 0 30.934] 80 @dc [<000003E0FFFC0F100FC01E0807803E0407807E0407807C0407807C0007807C0007807C000780780007807800078078000780 70000780F0000780E0000781C00007FF80000780F0000780780007803C0007801E0007801E0007801F0007801F0007801F00 07801F0007801E0007801E0007803C00078078000F80F000FFFF8000> 32 32 -2 1 33.459] 82 @dc [<0020004000800100020006000C000C00180018003000300030007000600060006000E000E000E000E000E000E000E000E000 E000E000E000E0006000600060007000300030003000180018000C000C00060002000100008000400020> 16 46 -3 12 17.676] 40 @dc [ 32 31 -2 0 32.196] 66 @dc [<800040002000100008000C00060006000300030001800180018001C000C000C000C000E000E000E000E000E000E000E000E0 00E000E000E000E000C000C000C001C001800180018003000300060006000C0008001000200040008000> 16 46 -3 12 17.676] 41 @dc [<003FF800038000038000038000038000038000038000038000038003E3800E13801C0B80380780380380780380700380F003 80F00380F00380F00380F00380F003807003807803803803803C07801C058006198003E080> 24 29 -2 9 23.989] 113 @dc [ 32 31 -2 0 34.090] 78 @dc [<7FE3FE3FF0070070070007007007000700700700070070070007007007000700700700070070070007007007000700700700 070070070007007007000700700700070070070007007007000700700700070070070007007007000700700700FFFFFFFF00 0700700000070070000007007000000700700000070070000007007000000700F00F000300F00F000380F80F0001C07C0600 00F04F0400001F81F800> 40 32 0 0 37.878] 14 @dc [ 16 30 -4 0 22.727] 49 @dc 1 @bop1 (cmbx10.432) @sf 410 307 p 65 c 23 r (Con) s -1 r (tribution) s 22 r (on) s 23 r 97 c 22 r (Naming) s 23 r (Sc) s -1 r (heme) s (cmbx10.329) @sf 778 439 p 70 c -3 r (ebruary) s 16 r (6,) s 17 r (1991) s 892 555 p (source:) s 773 642 p (Marshall) s 18 r (T.) s 17 r (Rose) s 509 698 p 80 c -1 r (erformance) s 17 r (Systems) s 17 r (In) s (ternational,) s 16 r (Inc.) s 930 784 p (and) s 761 871 p (Einar) s 17 r (A.) s 18 r (Ste\013erud) s 531 927 p (Net) s 119 c -2 r (ork) s 17 r (Managemen) s -1 r 116 c 17 r (Asso) s 1 r (ciates,) s 18 r (Inc.) s 724 984 p (\(on) s 18 r 98 c 1 r (ehalf) s 18 r (of) s 17 r (Infonet\)) s (cmbx10.432) @sf 224 1123 p 49 c 69 r (The) s 23 r (Authorit) s -1 r 121 c 22 r (Problem) s (cmr10.329) @sf 224 1225 p (Computer) s 12 r (net) s 119 c -2 r (orks) s 11 r (form) s 12 r (the) s (cmti10.329) @sf 12 r (infr) s -2 r (astructur) s -2 r 101 c (cmr10.329) @sf 14 r 98 c 1 r (et) s 119 c -1 r (een) s 11 r (the) s 11 r (users) s 12 r (they) s 12 r (in) s (tercon-) s 224 1281 p (nect.) s 20 r 70 c -3 r (or) s 13 r (example,) s 13 r (the) s 14 r (electronic) s 13 r (mail) s 14 r (service) s 13 r (o\013ered) s 14 r 98 c 121 c 12 r (computer) s 14 r (net) s -1 r 119 c -1 r (orks) s 224 1337 p (pro) s (vides) s 17 r 97 c 19 r (means) s 19 r (for) s 18 r (users) s 19 r (to) s 18 r (collab) s 1 r (orate) s 19 r (to) s 119 c -2 r (ards) s 18 r (some) s 18 r (common) s 19 r (goal.) s 30 r (In) s 224 1394 p (the) s 15 r (simplest) s 14 r (cases,) s 15 r (this) s 14 r (collab) s 2 r (oration) s 14 r (ma) s 121 c 14 r 98 c 1 r 101 c 14 r (solely) s 15 r (for) s 14 r (the) s 15 r (dissemination) s 14 r (of) s 224 1450 p (information.) s 20 r (In) s 13 r (other) s 14 r (cases,) s 14 r 116 c 119 c -2 r 111 c 13 r (users) s 13 r (ma) s 121 c 13 r 119 c -1 r (ork) s 13 r (on) s 13 r 97 c 14 r (join) s 116 c 12 r (researc) s 104 c 13 r (pro) s 2 r (ject,) s 224 1507 p (using) s 15 r (electronic) s 15 r (mail) s 16 r (as) s 15 r (their) s 15 r (primary) s 15 r (means) s 15 r (of) s 15 r (comm) s (unication.) s 295 1563 p (Ho) s -1 r 119 c -1 r (ev) s -1 r (er,) s 19 r (net) s 119 c -1 r (orks) s 18 r (themselv) s (es) s 18 r (are) s 19 r (built) s 19 r (on) s 19 r (an) s 20 r (underlying) s 19 r (naming) s 19 r (and) s 224 1620 p 110 c (um) s -1 r 98 c (ering) s 16 r (infrastructure,) s 16 r (usually) s 16 r (in) s 16 r (the) s 16 r (form) s 16 r (of) s 16 r (names) s 16 r (and) s 16 r (addresses.) s 23 r 70 c -3 r (or) s 224 1676 p (example,) s 17 r (some) s 16 r (authorit) s 121 c 15 r 109 c (ust) s 15 r (exist) s 16 r (to) s 17 r (assign) s 16 r (net) s 119 c -2 r (ork) s 16 r (addresses,) s 16 r (to) s 16 r (ensure) s 224 1733 p (that) s 18 r 110 c (um) s -1 r 98 c (ering) s 18 r (collisions) s 19 r (do) s 18 r (not) s 18 r 111 c 1 r (ccur.) s 30 r (This) s 18 r (is) s 18 r (of) s 19 r (paramoun) s -1 r 116 c 18 r (imp) s 1 r (ortance) s 224 1789 p (for) s 15 r (an) s 15 r (en) s (vironmen) s -1 r 116 c 14 r (whic) s 104 c 14 r (consists) s 15 r (of) s 15 r 109 c (ultiple) s 14 r (service) s 15 r (pro) s (viders.) s 295 1846 p (Due) s 15 r (to) s 16 r (an) s 16 r (unfortunate) s 15 r (set) s 16 r (of) s 16 r (circumstances,) s 16 r (the) s 15 r (organization) s 16 r (and) s 15 r (op) s 2 r (er-) s 224 1902 p (ation) s 19 r (of) s 19 r (naming) s 20 r (and) s 19 r 110 c -1 r (um) s -1 r 98 c (ering) s 20 r (authorities) s 19 r (for) s 19 r (OSI) s 19 r (in) s 19 r (the) s 19 r (US) s 19 r (has) s 20 r (lagged) s 224 1958 p 98 c 1 r (ehind) s 18 r (the) s 17 r (demand) s 17 r (for) s 17 r (OSI) s 17 r (services.) s 27 r 84 c -3 r 111 c 16 r (date,) s 18 r 110 c (um) s -2 r 98 c 1 r (ering) s 17 r (has) s 17 r 111 c 1 r (ccurred) s 17 r (on) s 224 2015 p (an) s 15 r (ad) s 14 r (ho) s 1 r 99 c 15 r (and) s 14 r (informal) s 15 r (basis.) s 20 r 70 c -3 r (or) s 14 r (example,) s 14 r (although) s 15 r (sev) s (eral) s 13 r (ADMDs) s 15 r (op) s 1 r (er-) s 224 2071 p (ate) s 17 r (within) s 16 r (the) s 17 r (US,) s 17 r (there) s 16 r (is) s 17 r (no) s (cmti10.329) @sf 17 r 98 c -2 r (ona) s 17 r (\014de) s (cmr10.329) @sf 20 r (national) s 17 r (registration) s 16 r (authorit) s 121 c 16 r (for) s 224 2128 p (ADMD) s 12 r (or) s 11 r (PRMD) s 12 r (names.) s 19 r (Similarly) s -3 r 44 c 11 r (there) s 12 r (is) s 11 r (no) s (cmti10.329) @sf 12 r 98 c -1 r (ona) s 11 r (\014de) s (cmr10.329) @sf 15 r (ADDMD) s 12 r (authorit) s 121 c 224 2184 p (op) s 1 r (erating) s 19 r (within) s 19 r (the) s 18 r (US,) s 19 r (but) s 18 r (nonetheless) s 19 r (Directory) s 18 r (Services) s 19 r (are) s 18 r 98 c 2 r (eing) s 18 r (of-) s 224 2241 p (fered.) s 20 r (\(Readers) s 13 r (should) s 14 r (consult) s 13 r (App) s 1 r (endix) s 14 r 66 c 13 r (for) s 14 r 97 c 13 r (brief) s 14 r (exp) s 1 r (osition) s 13 r (of) s 14 r (existing) s 224 2297 p 110 c (um) s -1 r 98 c (ering) s 15 r (authorities) s 15 r (in) s 15 r (the) s 15 r (US.\)) s 295 2354 p (This) s 16 r (informal) s 16 r (pro) s 1 r (cess) s 16 r (is) s 16 r (adequate) s 16 r (for) s 16 r (pilot) s 16 r (usage) s 16 r (of) s 16 r (OSI) s 16 r (services.) s 23 r (Ho) s (w-) s 224 2410 p (ev) s (er,) s 14 r (in) s 15 r (order) s 15 r (for) s 15 r (OSI) s 15 r (to) s 15 r 98 c 2 r 101 c 15 r (deplo) s 121 c -2 r (ed) s 14 r (for) s 15 r (widespread) s 16 r (use) s 15 r (in) s 15 r (North) s 15 r (America,) s 224 2467 p (an) s 13 r (o\016cial) s 14 r 112 c 1 r (olicy) s 13 r (and) s 13 r (mec) s (hanism) s 12 r (for) s 14 r (OSI) s 13 r (naming) s 13 r (and) s 13 r 110 c (um) s -1 r 98 c (ering) s 13 r (authorities) s 960 2592 p 49 c @eop 2 @bop0 (cmr10.329) @sf [ 32 31 -1 0 34.090] 88 @dc [<381C7C3EFC7EFC7EB85C804080408040402040202010201010080804> 16 14 -5 -18 22.727] 92 @dc [<402020101008100808040804040204020402743AFC7EFC7EF87C7038> 16 14 -2 -18 22.727] 34 @dc [<000FE0000078182000E00460038002E0070001E00F0001E01E0001E01E0001E03C0001E03C0001E07C0001E0780001E0F800 03E0F8007FFCF8000000F8000000F8000000F8000000F8000000F8000000F8000000780000207C0000203C0000203C000060 1E0000601E0000600F0000E0070001E0038002E000E004E000781860000FE020> 32 33 -3 1 35.668] 71 @dc [<7FFFFFE0FFFFFFF00000000000000000000000000000000000000000000000000000000000000000FFFFFFF07FFFFFE0> 32 12 -3 -5 35.353] 61 @dc (cmbx10.432) @sf [ 32 39 -3 0 34.370] 50 @dc [ 40 39 -2 12 38.189] 112 @dc [ 24 27 -2 0 27.114] 115 @dc [<7FFF80007FFF80007FFF800007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0 000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F00000FFFFC000 FFFFC000FFFFC00007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F03E0007F07F0003F07F0003F8 7F0001F87F0000FE3E00003FFC000007F000> 32 42 -2 0 21.004] 102 @dc [<7FFFFFFFFFE0FFFFFFFFFFF0FFFFFFFFFFF07FFFFFFFFFE00000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000007FFFFFFFFFE0FFFFFFFFFFF0FFFFFFFF FFF07FFFFFFFFFE0> 48 18 -4 -6 53.465] 61 @dc [<00001FF800000001FFFF00000007FFFFC000000FF007E000003FC000F000007F00003800007E00001C0000FE00001C0001FE 00000E0001FC00000E0003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000 070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC00000700 03FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC0000070003FC 0000070003FC0000070003FC0000070003FC0000070003FC00000700FFFFF001FFFCFFFFF001FFFCFFFFF001FFFC> 48 41 -3 0 52.883] 85 @dc (cmr10.329) @sf [<40201010080804040474FCFCF870> 8 14 -4 -18 12.626] 39 @dc (cmti10.329) @sf [<03C0000E30001C08001C04001C04001C02001C02001C01001C01001C01000E00800E00800E00808700804700C04301C04383 C02307C03307800E0380> 24 20 -4 0 20.908] 118 @dc [<38006400E200E200E200E200710070007000700038003800380038001C001C001C001C000E000E000E000E00070007000700 070003800380038003801FC003C0> 16 32 -4 0 11.616] 108 @dc [<600700E00CC0700C40701C20700C20700E20380E103807003807003807001C03801C03801C03801C03800E01C00E01C00F01 C00E8180076300071E0007000007000003800003800003800003800001C00001C00001C00001C0000FE00001E000> 24 32 -3 0 23.232] 104 @dc [<3E0000438000C0C000E06000F07000F03800003800001C00001C0007DC000C3C001C1E00180E00180E001C0E001C07001C07 001C07001C07000E03800E03800E03808703804701C04301C04381C02301C03300E00E00C0> 24 29 -4 9 22.070] 121 @dc [ 32 31 -3 0 28.509] 76 @dc [<3F800060E000F07000783800301C00001C00001C00000E00000E0003CE000C2E001C17001C0F003C07003C07003C03803C03 803C03803C03801E01C01E01C01E01C00E01C00F00E00700E00380E001C1E000E270003C60> 24 29 -2 9 20.908] 103 @dc [<81F80000C6060000E80380007000C0006000E000600060006000700020003000200038002000380000003800000038000000 7800000078000001F800001FF000007FF00001FFE00001FF800003F8000003C0000003C00000038000000380010003800100 038001000180010001C0018000C003800060038000300580001C18C00007E040> 32 33 -3 1 25.555] 83 @dc [ 32 31 -3 0 34.317] 68 @dc [<00FC0000038304000E00CC001C002E0018003E0038001E0070001E0070000F0070000F0070000F00F0000F00F0000780F000 0780F000FFF0F0000000780000007800000078000000780000003C0000003C0000001E0000201E0000200E00003007000030 038000300380003001C0003800E0007800300078001C00980007030C0000FC04> 32 33 -6 1 35.163] 71 @dc [<000007C0FFF00C200F801C1007803C1007803C0807803C0807803C0003C01E0003C01E0003C01E0003C01E0001E00F0001E0 0E0001E01E0001E01C0000F0380000FFF00000F01E0000F00700007801C0007801E0007800F0007800F0003C0078003C0078 003C0078003C0078001E0078001E0070001E00E0001E03C001FFFF00> 32 32 -3 1 33.156] 82 @dc [<0FFE0000E00000E0000070000070000070000070000038000038000F380030B800705C00703C00F01C00F01C00F00E00F00E 00F00E00F00E007807007807007807003807003C03801C03800E03800705800388C000F040> 24 29 -4 9 20.908] 113 @dc [<300300380070070066003803806200380380E100380380610038038071001C01C070801C01C038001C01C038001C01C03800 0E00E01C000E00E01C000E00E01C008E00E01C004700700E004700700E004780680E004740640C002630C318001C0F80F000> 40 20 -4 0 37.171] 109 @dc [ 360 ] /cmbx10.360 @newfont (cmbx10.360) @sf [ 24 32 -3 0 28.642] 50 @dc [<3C007E00FF00FF00FF00FF007E003C00> 16 8 -4 0 15.912] 46 @dc [<7FFFF07FFFF001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F8 0001F80001F80001F80001F80001F80001F80001F80001F80001F80001F800FDF800FFF80003F800007800003800> 24 32 -4 0 28.642] 49 @dc [<0001FF0000001FFFE000007F80780001FC001C0003F000060007E00003000FC00001801FC00001803F800001C03F800000C0 7F800000C07F000000C07F00000000FF00000000FF00000000FF00000000FF00000000FF00000000FF00000000FF00000000 FF000000007F000000C07F000000C07F800000C03F800001C03F800001C01FC00003C00FC00003C007E00007C003F0000FC0 01FC001FC0007F80F3C0001FFFC1C00001FF0040> 40 34 -3 0 41.371] 67 @dc [ 32 35 -3 0 31.824] 104 @dc [<00FF000007FFE0000F81F0001F00F8003E007C007E007E007C003E00FC003F00FC003F00FC003F00FC003F00FC003F00FC00 3F00FC003F007C003E007C003E007C003E003E007C001F00F8000F81F00007FFE00000FF0000> 32 22 -2 0 28.642] 111 @dc [ 16 36 -2 0 15.912] 105 @dc [<00FE0007FF800FC0E01F00603F00307E00007E00007C0000FC0000FC0000FC0000FC0000FC0000FC00007C00007C01E07E03 F03E03F01F03F00F83F007FFE000FF80> 24 22 -2 0 25.459] 99 @dc [<00FF0003FFC00F80E01F00303E00183E00187C00007C0000FC0000FC0000FC0000FFFFF8FFFFF8FC00787C00787C00F87E00 F03E00F01F01E00F83C007FF8000FE00> 24 22 -2 0 26.255] 101 @dc [<7FFC007FFC000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0 000FC0000FC0000FC000FFFE00FFFE000FC0000FC0000FC0000FC0000FC0000FC0000FC1E00FC3F007E3F003E3F001F1F000 FFE0001F80> 24 35 -2 0 17.503] 102 @dc [ 48 34 -2 0 42.963] 82 @dc [ 40 34 -2 0 43.931] 68 @dc [ 48 34 -2 0 44.831] 78 @dc [<07E03F801FF87F807E0CF8007C02F800F801F800F801F800F801F800F801F8007C01F8003E01F8001F81F80003FDF800003F F8000001F8000001F8001E01F8003F01F8003F01F0003F03F0003F07E0001FFF800007FE0000> 32 22 -2 0 27.846] 97 @dc [ 48 22 -3 0 47.736] 109 @dc [ 24 22 -2 0 22.595] 115 @dc (cmr10.329) @sf [<70F8F8F8700000000000000000000070F8F8F870> 8 20 -4 0 12.626] 58 @dc (cmti10.329) @sf [ 24 29 0 9 23.232] 112 @dc (cmr10.329) @sf [ 24 30 -2 0 22.727] 50 @dc 2 @bop1 (cmr10.329) @sf 224 307 p (is) s 17 r (necessary) s -3 r 46 c 24 r (This) s 17 r (prop) s 1 r (osal) s 17 r (deals) s 17 r (only) s 17 r (with) s 16 r (the) s 17 r (US) s 17 r (national) s 17 r (decision) s 17 r (prob-) s 224 364 p (lem.) s 26 r (CA) s 18 r (\(Canada\)) s 17 r (and) s 17 r (MX) s 17 r (\(Mexico\)) s 17 r (are) s 18 r (on) s 17 r (their) s 17 r 111 c (wn) s 16 r (to) s 17 r (mak) s 101 c 16 r (their) s 17 r 111 c (wn) s 224 420 p (national) s 15 r (decisions.) s 295 477 p (According) s 12 r (to) s 12 r (the) s 12 r (CCITT) s 12 r (recommendations,) s 12 r (the) s 12 r (pro) s 2 r (cess) s 12 r (whereb) s 121 c 11 r (ADMD) s 224 533 p (names,) s 14 r (PRMD) s 14 r (names,) s 14 r (and) s 14 r (national) s 14 r (RDNs) s 14 r (ma) s 121 c 13 r 98 c 1 r 101 c 14 r (assigned,) s 14 r (is) s 14 r (decided) s 14 r 98 c 121 c 13 r 97 c 224 589 p (\\national) s 14 r (decision".) s 19 r (Study) s 14 r (Group) s 14 r 68 c 13 r (of) s 14 r (the) s 13 r (US) s 14 r (CCITT) s 14 r (National) s 13 r (Committee) s 224 646 p (is) s 18 r (curren) s -1 r (tly) s 17 r 119 c (orking) s 16 r (on) s 18 r 112 c 1 r (olicy) s 18 r (for) s 17 r (ADMD) s 18 r (and) s 17 r (PRMD) s 18 r (naming) s 18 r (authorities.) s 224 702 p (This) s 20 r (is) s 20 r (certainly) s 20 r 97 c 20 r 112 c 1 r (ositiv) s 101 c 19 r (dev) s (elopmen) s -1 r 116 c 19 r (for) s 20 r (Message) s 20 r (Handling.) s 34 r (Unfortu-) s 224 759 p (nately) s 18 r (no) s 17 r (corresp) s 1 r (onden) s 116 c 16 r (e\013ort) s 18 r (is) s 17 r (underw) s 97 c -1 r 121 c 16 r (for) s 18 r (Directory) s 17 r (Services.) s 27 r (In) s 17 r (par-) s 224 815 p (ticular,) s 15 r (there) s 15 r (is) s 15 r (no) s 15 r (authorit) s 121 c 14 r (to) s 15 r (assign) s 15 r (Relativ) s 101 c 14 r (Distinguished) s 15 r (Names) s 15 r (under) s 224 872 p (the) s 15 r (arc) s 15 r (\\coun) s (tryName) s 14 r (is) s 15 r (US") s 16 r (\(henceforth) s 15 r (referred) s 15 r (to) s 15 r (as) s 15 r (c=US\).) s (cmbx10.432) @sf 224 1015 p 50 c 69 r 65 c 23 r (Prop) s 2 r (osal) s 23 r (for) s 23 r (c=US) s (cmr10.329) @sf 224 1116 p (It) s 15 r (should) s 14 r 98 c 1 r 101 c 15 r (observ) s (ed) s 13 r (that) s 14 r (there) s 15 r (are) s 14 r (sev) s (eral) s 14 r (di\013eren) s -1 r 116 c 14 r (naming) s 14 r (univ) s (erses) s 13 r (that) s 224 1173 p (can) s 17 r 98 c 1 r 101 c 17 r (realized) s 17 r (in) s 17 r (the) s 16 r (Directory) s 17 r (Information) s 17 r 84 c -3 r (ree) s 16 r (\(DIT\).) s 17 r 70 c -3 r (or) s 16 r (example,) s 17 r (ge-) s 224 1229 p (ographical) s 24 r (naming,) s 26 r (comm) s (unit) s -1 r 121 c 23 r (naming,) s 26 r 112 c 1 r (olitical) s 24 r (naming,) s 27 r (organizational) s 224 1286 p (naming,) s 19 r (and) s 17 r (so) s 18 r (on.) s 28 r (The) s 18 r 99 c (hoice) s 17 r (of) s 17 r (naming) s 18 r (univ) s (erse) s 17 r (largely) s 17 r (determines) s 18 r (the) s 224 1342 p (di\016cult) s 121 c 18 r (in) s 20 r (mapping) s 20 r 97 c 19 r (user's) s 20 r (query) s 19 r (in) s (to) s 19 r 97 c 19 r (series) s 20 r (of) s 19 r (Directory) s 20 r (op) s 1 r (erations.) s 224 1399 p (Although) s 13 r (it) s 13 r (is) s 13 r 112 c 1 r (ossible) s 13 r (to) s 13 r (sim) s (ultaneously) s 11 r (supp) s 2 r (ort) s 13 r 109 c -1 r (ultiple) s 12 r (naming) s 13 r (univ) s (erses) s 224 1455 p (with) s 16 r (the) s 15 r (DIT,) s 16 r (this) s 16 r (is) s 16 r (lik) s -1 r (ely) s 15 r (to) s 16 r 98 c 1 r 101 c 16 r (unnatural.) s 21 r (As) s 16 r (suc) s (h,) s 14 r (this) s 16 r (prop) s 1 r (osal) s 16 r (fo) s 1 r (cuses) s 224 1512 p (on) s 15 r 97 c 15 r (single) s 16 r (naming) s 15 r (univ) s -1 r (erse.) s 295 1568 p (The) s 17 r (naming) s 17 r (univ) s -1 r (erse) s 16 r (in) s 17 r (this) s 17 r (prop) s 1 r (osal) s 17 r (is) s 17 r (based) s 17 r (on) s (cmti10.329) @sf 17 r (civil) s 18 r (authority) s (cmr10.329) @sf 46 c 25 r (That) s 224 1624 p (is,) s 20 r (it) s 18 r (uses) s 19 r (the) s 19 r (existing) s 19 r (civil) s 18 r (naming) s 19 r (infrastructure) s 19 r (and) s 18 r (suggests) s 19 r 97 c 19 r (\(nearly\)) s 224 1681 p (straigh) s (t-forw) s -1 r (ard) s 14 r (mapping) s 15 r (on) s 15 r (the) s 15 r (DIT.) s 295 1737 p (Although) s 13 r (this) s 14 r (prop) s 1 r (osal) s 13 r (fo) s 1 r (cuses) s 14 r (on) s 13 r 97 c 14 r (single) s 13 r (naming) s 13 r (univ) s (erse,) s 13 r (it) s 13 r (should) s 14 r 98 c 1 r 101 c 224 1794 p (observ) s (ed) s 10 r (that) s 10 r (some) s 11 r (other) s 11 r (naming) s 10 r (univ) s (erses,) s 11 r (and) s 10 r (in) s 11 r (particular) s 11 r (the) s 10 r (comm) s (unit) s -1 r 121 c 224 1850 p (naming) s 17 r (univ) s (erse) s 16 r (for) s 16 r (listing) s 17 r (services) s 17 r (\(as) s 17 r (describ) s 1 r (ed) s 17 r (in) s 17 r (the) s 17 r (Bellcore) s 17 r 84 c -3 r (ec) s -2 r (hnical) s 224 1907 p (Advisory) s 17 r (on) s (cmti10.329) @sf 17 r (Listing) s 18 r (Servic) s -2 r (es) s 17 r (Datab) s -1 r (ase) s 17 r (Generic) s 17 r 82 c -1 r 101 c -2 r (quir) s -2 r (ements) s (cmr10.329) @sf 2 r 41 c 17 r (can) s 17 r 98 c 1 r 101 c 17 r (sup-) s 224 1963 p 112 c 1 r (orted) s 16 r (with) s 15 r (some) s 15 r (co) s 1 r (op) s 1 r (eration.) s (cmbx10.360) @sf 224 2085 p (2.1) s 57 r (Choice) s 20 r (of) s 19 r (RDN) s 19 r (Names) s (cmr10.329) @sf 224 2171 p (The) s 13 r 107 c (ey) s 12 r (asp) s 1 r (ect) s 14 r (to) s 13 r (appreciate) s 13 r (for) s 13 r 99 c (hoice) s 12 r (of) s 13 r (RDNs) s 13 r (is) s 13 r (that) s 14 r (they) s 13 r (should) s 13 r (pro) s (vide) s 224 2227 p 97 c 19 r (large) s 18 r (name) s 19 r (space) s 19 r (to) s 18 r 97 c 118 c -1 r (oid) s 18 r (collisions:) s 27 r (the) s 18 r (naming) s 19 r (strategy) s 19 r 109 c -1 r (ust) s 18 r (pro) s (vide) s 224 2284 p (enough) s 19 r (\\real) s 18 r (estate") s 18 r (to) s 19 r (accommo) s 1 r (date) s 18 r 97 c 19 r (large) s 18 r (demand) s 19 r (for) s 18 r (en) s (tries.) s 29 r (This) s 18 r (is) s 224 2340 p (the) s (cmti10.329) @sf 14 r (primary) s (cmr10.329) @sf 17 r (requiremen) s 116 c 13 r (for) s 13 r (RDNs.) s 20 r 65 c (cmti10.329) @sf 14 r (se) s -2 r 99 c -2 r (ondary) s (cmr10.329) @sf 17 r (requiremen) s -1 r 116 c 13 r (is) s 14 r (that) s 13 r (RDNs) s 224 2397 p (should) s 14 r 98 c 1 r 101 c 14 r (meaningful) s 14 r (\(friendly) s 14 r (to) s 14 r 112 c 1 r (eople\)) s 14 r (and) s 14 r (should) s 14 r (not) s 13 r (imp) s 2 r (ede) s 14 r (searc) s -1 r (hing.) s 960 2592 p 50 c @eop 3 @bop0 [ 300 ] /cmtt10.300 @newfont (cmtt10.300) @sf [<03E0000FF8001FFC003C1E00780F00700700F00780E00380E00380E00380E00380E00380700700780F003C1E001FFC000FF8 0003E000> 24 18 -2 0 21.793] 111 @dc [ 24 18 -1 0 21.793] 114 @dc [<03F8000FFE003FFF807C07C07001C0E000E0E000E0E000E0E000E07803C03FFF801FFF001FFC001800003800001BE0001FF0 000FF8001C1C00380E00380E00380E00380E00380E001C1CC00FFFE007F7E003E3C0> 24 28 -1 10 21.793] 103 @dc [<0F83E03FE7E07FFFE0783E00E00E00E00E00E00E00700E003E0E001FFE0003FE00000E00000E00300E00783C007FF8003FF0 001FE000> 24 18 -2 0 21.793] 97 @dc [<7FC7F0FFE7F87FC7F00E03800E03800E03800E03800E03800E03800E03800E03800E03800E03800F03800F87807FFF00FEFE 007E3C00> 24 18 0 0 21.793] 110 @dc [<7FFF00FFFF007FFF0001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C0007FC0007FC0 007FC00000000000000000000000000001800003C00003C000018000> 24 26 -3 0 21.793] 105 @dc [ 24 18 -1 0 21.793] 122 @dc [<00F80001FC0003FE00078700070380070380070380070100070000070000070000070000070000070000070000FFFF00FFFF 007FFF00070000070000070000070000030000> 24 23 -1 0 21.793] 116 @dc [<7F0F00FF9F007F1F001C17001C37001C37001C37001C77001C77001C67001C67001CE7001CE7001CE7001CC7001CC7001DC7 001DC7001D87001D87001D87001D07007F1FC0FF3FE07E1FC0> 24 25 -1 0 21.793] 78 @dc [ 24 18 0 0 21.793] 109 @dc [<03F0000FFC001FFE003C0F00780700700700E00000E00000FFFF00FFFF00FFFF00E00700700700780E003C1E001FFC000FF8 0003E000> 24 18 -3 0 21.793] 101 @dc [ 16 18 -3 0 21.793] 115 @dc [<7F0000FF80007F00001C00001C00001C00001C00001C00001C00001C00001FF8001FFE001FFF001C0F801C03801C03C01C01 C01C01C01C01C01C03C01C03801C0F807FFF00FFFE007FF800> 24 25 -1 0 21.793] 80 @dc [<3FFE007FFF003FFE0001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C000FFFF00FFFF 007FFF0001C00001C00001C30001E78000FF80007F80001F00> 24 25 -1 0 21.793] 102 @dc [<03F0000FF8001FFC003E0E00780700700700F00000E00000E00000E00000E00000E00000700000780C003C1E001FFE000FFC 0003F800> 24 18 -3 0 21.793] 99 @dc [ 24 25 -2 0 21.793] 83 @dc [<3C00003F00007F80007BC00079C00001C00000E00000E00000E00000F00000F00000F00001B80001B800039800039C00039C 00071C00071C00070E000E0E000E0E000E07001C07007F1FC0FF9FE07F1FC0> 24 27 -1 9 21.793] 121 @dc [ 16 25 -3 0 21.793] 73 @dc [ 24 25 -2 0 21.793] 108 @dc [<60F0781C1E0E3E7E7E7C38> 8 11 -7 6 21.793] 44 @dc [<70F8F8F870> 8 5 -8 0 21.793] 46 @dc [ 329 ] /cmtt10.329 @newfont (cmtt10.329) @sf [<01F0000FFE001FFF003E0F803C07807803C07001C0F001E0E000E0E000E0E000E0E000E0E000E07001C07001C03803803E0F 801FFF000FFE0001F000> 24 20 -2 0 23.863] 111 @dc [<7FFE00FFFF007FFE0003800003800003800003800003800003800003800003800003800003C00003C00003E00003F03003F8 787FBFF8FF9FF07F87E0> 24 20 -1 0 23.863] 114 @dc [<01FC000FFF801FFFC07E03F07800F0E00038E00038E00038E000387000707801F03FFFE01FFFC01FFE001C000038000039E0 001FF8001FFC001E1E001C0E003807003807003807003807003807001C0E001E1E300FFFF807FFF801E1F0> 24 31 -1 11 23.863] 103 @dc [<07E1F01FFBF03FFFF0781F00F00F00E00700E00700E007007807007F07001FFF0007FF0000FF00000700000700300E00781E 007FFC003FF8001FE000> 24 20 -3 0 23.863] 97 @dc [<7FC3FCFFE7FE7FC3FC0E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00F00E00F80E00FC1 C07FFFC0FEFF807E3E00> 24 20 0 0 23.863] 110 @dc [ 24 29 -4 0 23.863] 105 @dc [ 24 20 -1 0 23.863] 122 @dc [<003E0000FF8001FFC001C1C00380E00380E00380E00380400380000380000380000380000380000380000380000380000380 00FFFFC0FFFFC07FFFC0038000038000038000038000018000> 24 25 -1 0 23.863] 116 @dc [<7F03C0FF87C07F07C01C0DC01C0DC01C0DC01C1DC01C19C01C19C01C39C01C39C01C39C01C31C01C71C01C71C01C61C01CE1 C01CE1C01CE1C01CC1C01CC1C01DC1C01D81C01D81C01D81C07F07F0FF0FF87E07F0> 24 28 -1 0 23.863] 78 @dc [<7F1F1F00FFBFBF807F1F1F001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C 1C001C1C1C001E1E1C001E1E1C001F1F1C007FFFF800FFFBF8007CE0E000> 32 20 1 0 23.863] 109 @dc [<01FC0007FF001FFF803E03C03801C07001C0700000E00000FFFFC0FFFFC0FFFFC0E001C0E001C07003807003803807803E0F 001FFE0007FC0001F000> 24 20 -3 0 23.863] 101 @dc (cmr10.329) @sf [<7FE7FE0700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700 E00700E00700E0FFFFE00700E00700E00700E00700E00700E00700E00700E00700E00381E001C1E000E0E0003FE0> 24 32 0 0 25.252] 13 @dc [<03F0001C3C00200E00400F00400780F00780F807C0F807C0F807C02007C00007C0000780000780000F00000E00003C0003F0 00003800001C00000E00000F00000F00000F80380F80780780780780780F80200F00100E000C1C0003F000> 24 31 -2 1 22.727] 51 @dc [<7FC3FE0700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700 E00700E00700E0FFFFE00700000700000700000700000700000700000701E00701E00381E001C0C000E0C0003F00> 24 32 0 0 25.252] 12 @dc (cmbx10.360) @sf [ 32 22 -3 0 31.824] 110 @dc [<01FFE0000FFFFC001F807E003E001F007C000F80F80007C0F80007C0F80007C078000FC07C001FC01FFFFF8007FFFF000FFF FF001FFFFC001FFFE0001C000000180000001800000008FE00000BFF80000F83E0001F01F0001E00F0003E00F8003E00F800 3E00F8003E00F8003E00F8001E00F0001F01F3C00F83E3C003FF9FC000FE0F80> 32 33 -1 11 28.642] 103 @dc [<00FC0003FE0007E30007C1800FC1800FC1800FC1800FC1800FC1800FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0 000FC0000FC0000FC000FFFF00FFFF001FC0000FC00007C00003C00001C00001C00000C00000C00000C00000C000> 24 32 -1 0 22.277] 116 @dc [ 16 35 -2 0 15.912] 108 @dc [ 32 34 -2 0 34.453] 76 @dc [<000E0000000E0000001F0000001F0000003F8000003F8000007FC000007EC000007EC00000FC600000FC600001F8300001F8 300003F8180003F0180007F01C0007E00C000FE00E000FC006000FC00700FFF01FE0FFF01FE0> 32 22 -1 0 30.233] 118 @dc [ 329 ] /cmsy10.329 @newfont (cmsy10.329) @sf [<03C0000FF0001FF8003FFC007FFE007FFE00FFFF00FFFF00FFFF00FFFF00FFFF00FFFF007FFE007FFE003FFC001FF8000FF0 0003C000> 24 18 -3 -2 22.727] 15 @dc (cmr10.329) @sf [ 32 31 -2 0 30.934] 69 @dc (cmbx10.329) @sf [ 24 29 -3 0 26.136] 50 @dc [ 16 4 -1 -8 17.424] 45 @dc [<0007FF000007FF000000F8000000F8000000F8000000F8000000F8000000F8000000F80003F8F8000FFEF8001F87F8003F01 F8007E00F8007E00F8007C00F800FC00F800FC00F800FC00F800FC00F800FC00F800FC00F8007C00F8007E00F8003E01F800 3F01F8001F87780007FE380001F81800> 32 29 -2 9 27.588] 113 @dc [<001C0000001C0000003E0000003E0000007F0000007F000000FF800000F9800001F9C00001F0C00001F0C00003E0600003E0 600007C0300007C030000F8018000F8018001F001C00FFE07F80FFE07F80> 32 20 -1 0 27.588] 118 @dc [ 300 ] /cmr8.300 @newfont (cmr8.300) @sf [<7FF007000700070007000700070007000700070007000700070007000700070007000700FF0007000300> 16 21 -2 0 17.642] 49 @dc (cmtt10.329) @sf [<01FCFC03FFFE07FFFC0F03E00E01E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00 E07E07E0FE0FE07E07E0> 24 20 0 0 23.863] 117 @dc [ 24 20 -3 0 23.863] 115 @dc [ 24 28 -2 0 23.863] 83 @dc [<0FF8003FFE007FFF00780F00700700F00780E00380E00380E00380E00380E00380E00380E00380E00380E00380E00380E003 80E00380E00380E00380E00380E00380F00780700700780F007FFF003FFE000FF800> 24 28 -3 0 23.863] 79 @dc [ 24 28 -1 0 23.863] 69 @dc [<003FF8003FF8003FF800038000038000038000038000038000038000038003E3800FFB801FFF803C1F80380F807007807007 80E00380E00380E00380E00380E00380E00380700780700780380F803E1F801FFF8007FB8001E380> 24 30 -2 10 23.863] 113 @dc [<00700000F80000F80001DC0001DC0001DC00038E00038E00038E00038E000707000707000707000E03800E03800E03801E03 C07F8FF0FF8FF87F8FF0> 24 20 -1 0 23.863] 118 @dc [<7FFFC0FFFFE07FFFC000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0 0000E00000E00000E00000E00000E00000E00000E00000E0007FE000FFE0007FE000> 24 28 -2 0 23.863] 108 @dc (cmtt10.300) @sf [<7FC000FFE0007FC0000E00000E00000E00000E00000E00000E00000E3C000EFF000FFF800F83C00F01E00E00E00E00700E00 700E00700E00700E00700E00700E00E00F00E00F83C07FFF80FEFF007E3E00> 24 27 0 9 21.793] 112 @dc [<03E3F007FBF80FFFF00E0F800E03800E03800E03800E03800E03800E03800E03800E03800E03800E03800E03807E1F80FE3F 807E1F80> 24 18 0 0 21.793] 117 @dc [<01F00007FC000FFE001F0F003C0700380380700380700380F00000E00000E00000E00000E00000E00000E00000E00000F000 007003807003803803803C07801F0F800FFF8007FB8001F180> 24 25 -2 0 21.793] 67 @dc [<07C7E00FE7F01FFFE03C1F00700F00700F00E00700E00700E00700E00700E00700E00700700700780F003C1F001FFF000FF7 0003C700000700000700000700000700003F00007F00003F00> 24 25 -1 0 21.793] 100 @dc [<000180000780001F80003E0000F80001F00007C0000F80003E0000FC0000F00000FC00003E00000F800007C00001F00000F8 00003E00001F80000780000180> 24 21 -2 -2 21.793] 60 @dc [ 24 25 -1 0 21.793] 70 @dc [<07E0001FF8003FFC00781E00E00700F00380F003806003800003800003803007003C0F003FFE003FFC003BF0003800003800 003800003800003800003800003800003FFE003FFE003FFE00> 24 25 -2 0 21.793] 53 @dc [ 24 3 -2 -11 21.793] 45 @dc [<7FFF80FFFF807FFF803803801E03800F000003800001C00000E000007000003800001C00000E000007000007000003800003 80600380F00380F00780E00700783E003FFC001FF80007E000> 24 25 -2 0 21.793] 50 @dc [ 24 21 -2 -2 21.793] 62 @dc [<03E0000FF8001FFC001E3C003C1E00780F00700700700700F00780E00380E00380E00380E00380E00380E00380E00380E003 80700700700700780F00380E001E3C001FFC000FF80003E000> 24 25 -2 0 21.793] 48 @dc [<03E0000FF8001FFC003C1E00380700700780700380700380E00380E00380F00380F00700F80F00FFFE00EFFC00E3F8007000 00700000780600380F001C0F000F070007FE0003FC0000F800> 24 25 -2 0 21.793] 54 @dc [ 300 ] /cmr6.300 @newfont (cmr6.300) @sf [ 16 16 -2 0 15.220] 49 @dc [ 300 ] /cmr9.300 @newfont (cmr9.300) @sf [ 16 26 0 0 10.666] 105 @dc [<60F0F060> 8 4 -3 0 10.666] 46 @dc [<07E00C18380830046000E000E000E000E000FFFCE00C600C701830181C3007C0> 16 16 -1 0 17.079] 101 @dc [<8040202010101070F0F060> 8 11 -3 7 10.666] 44 @dc [ 32 26 -1 0 28.792] 65 @dc [ 32 16 -1 0 31.997] 109 @dc [ 16 16 -1 0 15.018] 114 @dc [<07E00C18380830047000E000E000E000E000E000E00070003008381C0C1C07F8> 16 16 -1 0 17.065] 99 @dc [<1E3C0071FB00E0F100E07100E07100E070007070003070001C700007F00000700000700020700070E00070C0003F8000> 24 16 -2 0 19.198] 97 @dc [ 24 16 -1 0 21.331] 110 @dc [<87E000D81800E00400C00600C00200800300800300800300000300000700000E00003E0007FC001FF8003FE0007E00007000 00E00000C00200C00200C00200C00600600600200E001836000FC200> 24 26 -2 0 21.331] 83 @dc [<07E0001C3800381C00700E00600600E00700E00700E00700E00700E00700E00700600600700E00300C001C380007E000> 24 16 -1 0 19.198] 111 @dc [ 24 26 -2 0 25.061] 70 @dc [<07CFC01C2E00381E00700E00600E00E00E00E00E00E00E00E00E00E00E00E00E00700E00300E00380E000C3E0003CE00000E 00000E00000E00000E00000E00000E00000E00000E00000E00007E00> 24 26 -1 0 21.331] 100 @dc [<03800E401C201C201C201C201C201C001C001C001C001C001C001C001C00FFC03C001C000C000C00040004000400> 16 23 -1 0 14.932] 116 @dc [<8F80F040C020C0308030807000F01FE03FC07F00F000C020C020402060E01F20> 16 16 -1 0 15.145] 115 @dc [<7FE00E000E000E000E000E000E000E000E000E000E000E000E000E000E00FFC00E000E000E000E000E000E000E1007380318 01F0> 16 26 0 0 11.732] 102 @dc [ 32 26 -2 0 35.191] 77 @dc [<003F820001C06600030016000E000E001C000E001C000E0038000E0078000E0070000E0070000E00F001FFC0F0000000F000 0000F0000000F0000000F0000000700002007000020078000200380006001C0006001C000E000E001E0003002E0001C0C600 003F0200> 32 26 -2 0 30.129] 71 @dc [<07CFC00C2E001C1E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E00FC7E00> 24 16 -1 0 21.331] 117 @dc [ 24 26 -1 0 21.331] 104 @dc [ 16 26 0 0 10.666] 108 @dc [ 16 26 -1 0 13.860] 73 @dc [ 32 26 -2 0 28.792] 78 @dc [ 16 2 0 -7 12.799] 45 @dc [ 24 26 -2 0 26.128] 80 @dc [ 32 26 -2 0 28.261] 82 @dc [<000C0000000C0000001E0000001E0000001E0000003900000039000000390000007080000070800000E0400000E0400000E0 400001C0200001C0200003C0300003801000038010000700080007000800070008000E0004000E0004001C0006001E000F00 FF801FC0> 32 26 -1 0 28.792] 86 @dc [<07E000381C00600600C00300C00300C00300C00300600F001FFE003FFC003FF0007000006000002000002FC0001860003030 007038007038007038007038003030001873000FCE00> 24 24 -1 8 19.198] 103 @dc [<003E000000C18000018040000300400007002000060020000E0010000E0010000E0010000E0010000E0010000E0010000E00 10000E0010000E0010000E0010000E0010000E0010000E0010000E0010000E0010000E0010000E0010000E0010000E003800 FFE1FF00> 32 26 -2 0 28.792] 85 @dc 3 @bop1 (cmr10.329) @sf 295 307 p (Ho) s -1 r 119 c -1 r (ev) s -1 r (er,) s 22 r (it) s 21 r (is) s 22 r (imp) s 1 r (ortan) s 116 c 20 r (to) s 21 r (understand) s 22 r (that) s 21 r (this) s 21 r (second) s 22 r (requiremen) s -1 r 116 c 224 364 p (can) s 21 r 98 c 1 r 101 c 21 r (ac) s (hiev) s -2 r (ed) s 20 r 98 c 121 c 20 r (using) s 21 r (additional) s 20 r (\(non-distinguished\)) s 21 r (attribute) s 21 r 118 c -2 r (alues.) s 224 420 p 70 c -3 r (or) s 15 r (example,) s 15 r (if) s 15 r (the) s 15 r (RDN) s 15 r (of) s 15 r (an) s 15 r (en) s (try) s 14 r (is) s (cmtt10.300) @sf 338 500 p (organizationName) s 22 r (is) s 21 r (Performance) s 22 r (Systems) s 22 r (International,) s 22 r (Inc.) s (cmr10.329) @sf 224 586 p (then) s 18 r (it) s 18 r (is) s 18 r 112 c 2 r (erfectly) s 18 r (acceptable) s 18 r (\(and) s 18 r (indeed) s 18 r (desirable\)) s 18 r (to) s 18 r (ha) s 118 c -1 r 101 c 17 r (other) s 18 r 118 c -2 r (alues) s 224 643 p (for) s 15 r (the) s (cmtt10.329) @sf 15 r (organizationName) s (cmr10.329) @sf 16 r (attribute,) s 15 r (e.g.,) s (cmtt10.300) @sf 338 723 p (organizationName) s 22 r (is) s 21 r (PSI) s (cmr10.329) @sf 224 809 p (The) s 17 r (use) s 18 r (of) s 17 r (these) s 17 r (abbreviated) s 18 r (names) s 17 r (greatly) s 17 r (aids) s 18 r (searc) s -1 r (hing) s 17 r (whilst) s 17 r 97 c 118 c -2 r (oiding) s 224 866 p (unnecessary) s 15 r (distinguished) s 15 r (name) s 16 r (con\015icts.) s 295 922 p (In) s 14 r (order) s 15 r (to) s 15 r (appreciate) s 14 r (the) s 15 r (naming) s 15 r (sc) s -1 r (heme) s 14 r (whic) s 104 c 13 r (follo) s (ws,) s 14 r (it) s 14 r (is) s 15 r (imp) s 1 r (ortan) s 116 c 224 978 p (to) s 18 r (understand) s 17 r (that) s 17 r (it) s 18 r (lev) s -1 r (erages,) s 17 r (wherev) s (er) s 17 r 112 c 1 r (ossible,) s 18 r (existing) s 17 r (naming) s 18 r (infras-) s 224 1035 p (tructure.) s 36 r (That) s 20 r (is,) s 21 r (it) s 21 r (relies) s 20 r (hea) s (vily) s 19 r (on) s 20 r (non-OSI) s 21 r (naming) s 20 r (authorities) s 20 r (whic) s 104 c 224 1091 p (already) s 15 r (exist.) s 20 r (As) s 15 r (discussed) s 15 r (in) s 15 r (Section) s 15 r 51 c 15 r (this) s 15 r (strategy) s 15 r (should) s 15 r (maximize) s 15 r (con-) s 224 1148 p 118 c (ergence) s 14 r (with) s 15 r (the) s 15 r (\\\014nal") s 15 r (national) s 16 r (decision) s 15 r (in) s 15 r (this) s 15 r (matter.) s (cmbx10.360) @sf 224 1268 p (2.2) s 57 r (Naming) s 20 r (at) s 19 r (the) s 19 r (National) s 19 r (Lev) s -1 r (el) s (cmr10.329) @sf 224 1354 p 65 c 116 c 14 r (the) s 15 r (national-lev) s (el) s 14 r (\(at) s 15 r (least\)) s 15 r (three) s 16 r (kinds) s 15 r (of) s 15 r (names) s 15 r (ma) s 121 c 14 r 98 c 1 r 101 c 15 r (registered:) s (cmsy10.329) @sf 292 1440 p 15 c (cmr10.329) @sf 23 r (The) s 15 r (States) s 15 r (and) s 16 r (State-Equiv) s -2 r (alen) s -1 r (ts) s (cmsy10.329) @sf 292 1531 p 15 c (cmr10.329) @sf 23 r (Organizations) s 15 r (\(and) s 15 r (other) s 16 r (en) s -1 r (tities\)) s 14 r (with) s 16 r (National) s 15 r (Standing) s (cmsy10.329) @sf 292 1622 p 15 c (cmr10.329) @sf 23 r (ADDMD) s 15 r (Op) s 1 r (erators) s (cmbx10.329) @sf 224 1741 p (2.2.1) s 52 r (The) s 18 r (States) s 17 r (and) s 18 r (State-Equiv) s -2 r (alen) s -2 r (ts) s (cmr10.329) @sf 224 1827 p 70 c -3 r (or) s 17 r (eac) s 104 c 17 r (state) s 18 r (or) s 18 r (state-equiv) s -1 r (alen) s -1 r 116 c 17 r (\(the) s 18 r (District) s 18 r (of) s 18 r (Colum) s (bia) s 17 r (and) s 18 r (the) s 18 r (eigh) s 116 c 224 1883 p (outlying) s 20 r (areas) s (cmr8.300) @sf 508 1867 p 49 c (cmr10.329) @sf 528 1883 p (\),) s 21 r (an) s 19 r (instance) s 20 r (of) s 19 r (an) s (cmtt10.329) @sf 20 r (usStateOrEquivalent) s (cmr10.329) @sf 20 r (ob) s 2 r (ject) s 20 r (is) s 20 r (used.) s 224 1940 p (The) s 15 r (RDN) s 15 r (is) s 16 r (formed) s 15 r (as) s (cmtt10.300) @sf 338 2019 p (fipsStateNumericCode) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 2106 p (e.g.,) s (cmtt10.300) @sf 338 2186 p (fipsStateNumericCode) s 22 r (is) s 21 r (06) s (cmr10.329) @sf 224 2272 p (pro) s (vides) s 16 r (the) s 18 r (RDN) s 17 r (for) s 17 r (the) s 17 r (State) s 18 r (of) s 17 r (California.) s 27 r (Of) s 17 r (course,) s 18 r (this) s 17 r (en) s (try) s 16 r 119 c (ould) s 224 2329 p (con) s (tain) s 14 r (man) s 121 c 14 r (other) s 15 r (attributes) s 15 r (suc) s 104 c 14 r (as) s 224 2365 p 598 2 ru (cmr6.300) @sf 276 2392 p 49 c (cmr9.300) @sf 293 2408 p (i.e.,) s 10 r (American) s 9 r (Samoa,) s 10 r 70 c -2 r (ederated) s 8 r (States) s 9 r (of) s 9 r (Micronesia,) s 9 r (Guam,) s 10 r (Marshall) s 9 r (Islands,) s 10 r (North-) s 224 2454 p (ern) s 13 r (Mariana) s 13 r (Islands,) s 13 r 80 c -1 r (alau,) s 12 r (Puerto) s 13 r (Rico,) s 13 r (and) s 13 r (Virgin) s 12 r (Islands) s 13 r (of) s 13 r (the) s 13 r (US.) s (cmr10.329) @sf 960 2592 p 51 c @eop 4 @bop0 (cmtt10.300) @sf [<1FFC003FFE007FFF00780F00F00780F00780E00380E00380E00380E00380E00380E00380E00380E00380E00380E00380E003 80E00380E00380E00380F00780780F007FFF003FFE001FFC00> 24 25 -2 0 21.793] 79 @dc [<00E00001F00001F00003B80003B80003B800071C00071C00071C00071C000E0E000E0E000E0E001E0F001C07007F1FC0FF1F E07F1FC0> 24 18 -1 0 21.793] 118 @dc [<7F1FC0FF1FE07F1FC01C07001C07001C07001FFF000FFE000FFE000E0E000E0E00071C00071C00071C00071C00071C000318 0003B80003B80003B80001B00001B00001F00001F00000E000> 24 25 -1 0 21.793] 65 @dc [<7FC7F0FFE7F87FC7F00E03800E03800E03800E03800E03800E03800E03800E03800E03800E03800F03800F87800FFF000EFE 000E3C000E00000E00000E00000E00007E0000FE00007E0000> 24 25 0 0 21.793] 104 @dc (cmbx10.329) @sf [<001FF8000000FFFF000001F81F800007E007E0000FC003F0001F8001F8003F8001FC003F0000FC007F0000FE007F0000FE00 7E00007E00FE00007F00FE00007F00FE00007F00FE00007F00FE00007F00FE00007F00FE00007F00FE00007F00FE00007F00 7E00007E007E00007E007F0000FE003F0000FC001F0000F8001F8001F8000FC003F00007E007E00001F81F800000FFFF0000 001FF80000> 40 31 -3 0 39.266] 79 @dc [ 24 20 -1 0 23.232] 122 @dc (cmtt10.300) @sf [<7FF87FFC7FF8038003800380038003800380038003800380038003800380038003807380FF807F800F800780038003800180> 16 25 -4 0 21.793] 49 @dc [<03E70007F7000FFF001E1F003C0F00380F00700700700700F00700E03F80E07FC0E03F80E00000E00000E00000E00000F000 007007007007003807003C0F001E1F000FFF0007FF0003E300> 24 25 -2 0 21.793] 71 @dc [<00F80003FE0007FF000707000E03800E03801C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01 C01C01C01C01C01C01C01C01C01C01C07F07F0FF8FF87F07F0> 24 25 0 0 21.793] 85 @dc (cmbx10.329) @sf [<03FC001FFF803C0FC07807E0FC03F0FE03F0FE03F8FE03F87C03F83803F80003F80003F00003E00007C0000F8001FC0001FC 00001F00000F80000FC01E0FC03F07E03F07E03F07E03F07E01E0FC00E0F8007FF0001FC00> 24 29 -2 0 26.136] 51 @dc [ 40 31 -2 0 40.087] 68 @dc [ 32 29 -2 9 29.040] 112 @dc (cmtt10.329) @sf [<03E3F00FFBF81FFFF03C1F80380F80700780700780E00380E00380E00380E00380E00380E00380700380700780380F803C1F 801FFF800FFB8003E380000380000380000380000380000380001F80003F80001F80> 24 28 -2 0 23.863] 100 @dc [<7FFF007FFF007FFF0001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C0 00FFFFC0FFFFC07FFFC001C00001C00001C00001C0C000E1E000FFE0007FC0001F80> 24 28 -1 0 23.863] 102 @dc [<7F07F0FF8FF87F07F01C01C01C01C00E03800E03800FFF800FFF800FFF80070700070700070700070700030600038E00038E 00038E00038E00018C0001DC0001DC0001DC0000D80000D80000F80000F800007000> 24 28 -1 0 23.863] 65 @dc [<7FF800FFFE007FFF001C0F801C03C01C01C01C01E01C00E01C00E01C00F01C00701C00701C00701C00701C00701C00701C00 701C00701C00F01C00E01C00E01C01E01C03C01C03C01C0F807FFF00FFFE007FF800> 24 28 -1 0 23.863] 68 @dc [ 24 28 -1 0 23.863] 77 @dc (cmtt10.300) @sf [<7FF800FFFE007FFF001C0F801C07801C03C01C01C01C01C01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C01 E01C01C01C01C01C03C01C07801C0F007FFF00FFFE007FF800> 24 25 0 0 21.793] 68 @dc [ 24 25 -1 0 21.793] 77 @dc (cmr10.329) @sf [<00FFE0000E00000E00000E00000E00000E00000E00000E00FFFFF0C00E00400E00200E00200E00100E00080E00080E00040E 00020E00020E00010E00008E00008E00004E00002E00002E00001E00000E00000E00000600000600> 24 30 -1 0 22.727] 52 @dc 4 @bop1 (cmtt10.300) @sf 338 307 p (stateOrProvinceName) s 22 r (is) s 21 r (California) s (cmr10.329) @sf 224 400 p (and) s (cmtt10.300) @sf 338 485 p (fipsStateAlphaCode) s 22 r (is) s 21 r (CA) s (cmbx10.329) @sf 224 605 p (2.2.2) s 52 r (Organizations) s 18 r (with) s 17 r (National) s 18 r (Standing) s (cmr10.329) @sf 224 691 p (There) s 11 r (is) s 10 r (no) s 11 r (authorit) s 121 c 9 r (in) s 11 r (the) s 10 r (United) s 11 r (States) s 11 r (whic) s -1 r 104 c 10 r (unam) s (biguously) s 9 r (registers) s 11 r (the) s 224 747 p (alphan) s (umeric) s 13 r (names) s 13 r (of) s 14 r (organizations) s 14 r (with) s 13 r (national) s 14 r (standing.) s 20 r (It) s 13 r (is) s 14 r (prop) s 1 r (osed) s 224 804 p (that) s 15 r (ANSI) s 15 r (pro) s (vide) s 14 r (this) s 15 r (registry) s 14 r (and) s 15 r (that) s 15 r (the) s 15 r (ANSI) s 15 r (Numeric) s 15 r (Name) s 15 r (form) s 15 r 98 c 1 r 101 c 224 860 p (used) s 15 r (as) s 15 r (the) s 16 r (basis) s 15 r (for) s 15 r (RDNs.) s 295 917 p 70 c -3 r (or) s 12 r (eac) s 104 c 12 r (organization) s 13 r (with) s 13 r (national) s 13 r (standing,) s 14 r (an) s 13 r (instance) s 13 r (of) s 13 r (an) s (cmtt10.329) @sf 13 r (usOrgan) s 224 973 p (ization) s (cmr10.329) @sf 15 r (ob) s 3 r (ject) s 15 r (is) s 15 r (used.) s 20 r (The) s 15 r (RDN) s 16 r (is) s 15 r (formed) s 15 r (as) s (cmtt10.300) @sf 338 1059 p (ansiOrgNumericCode) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 1151 p (e.g.,) s (cmtt10.300) @sf 338 1237 p (ansiOrgNumericCode) s 22 r (is) s 21 r (101) s (cmr10.329) @sf 224 1330 p (pro) s (vides) s 13 r (the) s 15 r (RDN) s 15 r (for) s 14 r (the) s 15 r 70 c -3 r (ederal) s 14 r (Go) s -1 r 118 c -1 r (ernmen) s -1 r (t.) s 19 r (Of) s 15 r (course,) s 14 r (this) s 15 r (en) s (try) s 13 r 119 c (ould) s 224 1386 p (con) s (tain) s 14 r (man) s 121 c 14 r (other) s 15 r (attributes) s 15 r (suc) s 104 c 14 r (as) s (cmtt10.300) @sf 338 1472 p (organizationName) s 22 r (is) s 21 r (Government) s 22 r (of) s 22 r (the) s 22 r (United) s 22 r (States) s 21 r (of) s 22 r (America) s (cmr10.329) @sf 224 1564 p (and) s (cmtt10.300) @sf 338 1650 p (organizationName) s 22 r (is) s 21 r (Federal) s 22 r (Government) s (cmbx10.329) @sf 224 1770 p (2.2.3) s 52 r (ADDMD) s 18 r (Op) s 1 r (erators) s (cmr10.329) @sf 224 1855 p (There) s 18 r (is) s 18 r (no) s 18 r (authorit) s 121 c 17 r (in) s 18 r (the) s 18 r (United) s 18 r (States) s 17 r (whic) s 104 c 17 r (unam) s (biguously) s 17 r (registers) s 224 1912 p (the) s 17 r (names) s 18 r (of) s 17 r (ADDMD) s 17 r (op) s 1 r (erators.) s 27 r (It) s 17 r (is) s 17 r (exp) s 1 r (ected) s 17 r (that) s 18 r (the) s 17 r (North) s 17 r (American) s 224 1968 p (Directory) s 17 r 70 c -3 r (orum) s 16 r (will) s 16 r (co) s 1 r (ordinate) s 17 r (with) s 17 r (the) s 16 r (US) s 17 r (CCITT) s 16 r (National) s 17 r (Committee) s 224 2025 p (Study) s 17 r (Group) s 17 r 68 c 17 r (to) s 17 r (pro) s (vide) s 16 r (this) s 17 r (registry) s -2 r 46 c 25 r (\(A) s -1 r 116 c 16 r 119 c (orst,) s 17 r (the) s 17 r (ADDMDs) s 17 r (can) s 17 r (use) s 224 2081 p (ANSI) s 15 r 110 c (umeric) s 14 r (name) s 15 r (forms) s 15 r (for) s 16 r (their) s 15 r (RDN) s 15 r (attribute) s 15 r 118 c -1 r (alues.\)) s 295 2138 p 70 c -3 r (or) s 14 r (eac) s 104 c 15 r (ADDMD) s 15 r (op) s 2 r (erator,) s 15 r (an) s 16 r (instance) s 15 r (of) s 16 r 97 c (cmtt10.329) @sf 16 r (nadfADDMD) s (cmr10.329) @sf 15 r (ob) s 3 r (ject) s 15 r (is) s 16 r (used.) s 224 2194 p (The) s 15 r (RDN) s 15 r (is) s 16 r (formed) s 15 r (as) s (cmtt10.300) @sf 338 2280 p (addmdName) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 2372 p (e.g.,) s (cmtt10.300) @sf 338 2458 p (addmdName) s 22 r (is) s 21 r (PSI) s 22 r (Directory) s 22 r (Services) s (cmr10.329) @sf 960 2592 p 52 c @eop 5 @bop0 (cmbx10.360) @sf [<01FF00000FFFE0003C03F0007801FC007C01FC00FE00FE00FE00FF00FE00FF007C00FF007C00FF000000FF000000FE000000 FE000001FC000001F8000003E00000FF000000FF0000000FC0000003E0000003F0000001F8000C01F8001F01FC003F01FC00 3F81FC003F01FC003F01F8001E01F8000F03F00007FFC00000FF0000> 32 32 -2 0 28.642] 51 @dc [<0018006000001C00E000003C00F000003E01F000007E01F800007F03F800007F03F80000FF03EC0000FD87CC0001FD87C600 01F8CFC60001F8CF860003F0CF830003F07F030007E07F018007E03F01800FE03E01C00FC07E00C00FC07C00C01F807C00E0 FFF3FF87FCFFF3FF87FC> 40 22 -1 0 41.371] 119 @dc [<807FC000E7FFF000FF807800FC001C00F0001E00E0000F00E0000F00C0000F80C0000F80C0000F8000001F8000001F800000 3F800001FF00003FFF0003FFFF0007FFFE001FFFFC003FFFF8003FFFE0007FFF8000FFF00000FF000000FC000000FC000600 F8000600F800060078000E0078000E003C001E003C007E001F01FE0007FFCE0001FE0200> 32 34 -3 0 31.824] 83 @dc [ 24 22 -2 0 23.591] 114 @dc [ 16 5 -1 -9 19.095] 45 @dc [ 40 34 -2 0 37.635] 69 @dc [<0001FFE00001FFE000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0001FC3F0007FF3F000FC1 FF001F00FF003E007F007E003F007E003F00FC003F00FC003F00FC003F00FC003F00FC003F00FC003F00FC003F007C003F00 7E003F007E003F003F007F001F00DF000FC1CF0007FF070000FE0300> 32 32 -2 10 30.233] 113 @dc [<01FC3FE007FF3FE00FC1BF001F80FF001F807F001F803F001F803F001F803F001F803F001F803F001F803F001F803F001F80 3F001F803F001F803F001F803F001F803F001F803F001F803F001F803F00FF81FF00FF81FF00> 32 22 -3 0 31.824] 117 @dc (cmbx10.329) @sf [<0007FC0600003FFF8E0000FE01FE0003F000FE0007E0007E000FC0007E001F80007E003F00007E003F00007E007F00007E00 7E00007E007E00007E00FE003FFFE0FE003FFFE0FE00000000FE00000000FE00000000FE00000000FE000000007E00000600 7E000006007F000006003F00000E003F00000E001F80001E000FC0001E0007E0003E0003F000FE0000FE03DE00003FFF0E00 0007FC0200> 40 31 -3 0 41.097] 71 @dc (cmtt10.329) @sf [ 24 28 -1 0 23.863] 80 @dc [<01FC0007FF001FFF803E03C03801C07001C0700000E00000E00000E00000E00000E00000E000007000007000003803003E07 801FFF8007FF0001FE00> 24 20 -3 0 23.863] 99 @dc (cmtt10.300) @sf [<07E0001FF8003FFC00781E00E00700F00380600380000380000380000300000700001E0007FC0007F00007FC00003E00000E 00000700000700300700780700781E003FFC001FF80007E000> 24 25 -2 0 21.793] 51 @dc [<07000007000007000007000007000007000007000003800003800003800003800001C00001C00001C00000E00000E0000070 00007800003800001C00E01E00E00F00FFFF80FFFF80FFFF80E00000> 24 26 -2 0 21.793] 55 @dc [<7F1FC0FFBFE07F1FC01C07001C07001C07001C07001C07001C07001C07001C07001C07001FFF001FFF001FFF001C07001C07 001C07001C07001C07001C07001C07007F1FC0FFBFE07F1FC0> 24 25 -1 0 21.793] 72 @dc (cmr10.329) @sf [<03E0000C3800100E00200600400700400380E00380F003C0F003C07003C00003C00003C00003C00003800003801007801007 00180E00161C0011F0001000001000001000001000001000001000001FE0001FF8001FFC001FFE00180300> 24 31 -2 1 22.727] 53 @dc 5 @bop1 (cmbx10.360) @sf 224 307 p (2.3) s 57 r (Naming) s 20 r (within) s 19 r 97 c 19 r (State) s 19 r (or) s 19 r (State-Equiv) s -2 r (alen) s -2 r 116 c (cmr10.329) @sf 224 393 p 65 c 116 c 14 r (the) s 15 r (regional) s 15 r (lev) s (el) s 14 r (\(at) s 15 r (least\)) s 16 r (three) s 15 r (kinds) s 15 r (of) s 15 r (names) s 15 r (ma) s 121 c 14 r 98 c 1 r 101 c 15 r (registered:) s (cmsy10.329) @sf 292 487 p 15 c (cmr10.329) @sf 23 r (The) s 15 r (Regional) s 15 r (Go) s 118 c -1 r (ernmen) s -1 r 116 c (cmsy10.329) @sf 292 580 p 15 c (cmr10.329) @sf 23 r 80 c (opulated) s 14 r (Places) s (cmsy10.329) @sf 292 674 p 15 c (cmr10.329) @sf 23 r (Organizations) s 15 r (\(and) s 15 r (other) s 16 r (en) s -1 r (tities\)) s 14 r (with) s 16 r (Regional) s 15 r (Standing) s (cmbx10.329) @sf 224 794 p (2.3.1) s 52 r (The) s 18 r (Regional) s 17 r (Go) s 118 c -2 r (ernmen) s -1 r 116 c (cmr10.329) @sf 224 880 p 70 c -3 r (or) s 20 r (the) s 20 r (Regional) s 20 r (Go) s 118 c -2 r (ernmen) s -1 r (t,) s 21 r (an) s 20 r (instance) s 20 r (of) s 20 r (an) s (cmtt10.329) @sf 20 r (organization) s (cmr10.329) @sf 21 r (ob) s 2 r (ject) s 20 r (is) s 224 936 p (used.) s 20 r (The) s 16 r (RDN) s 15 r (is) s 15 r (formed) s 15 r (as:) s (cmtt10.300) @sf 338 1023 p (organizationName) s 22 r (is) s 21 r (Government) s 22 r (of) s 22 r () s (cmr10.329) @sf 224 1117 p (e.g.,) s (cmtt10.300) @sf 338 1204 p (organizationName) s 22 r (is) s 21 r (Government) s 22 r (of) s 22 r (the) s 22 r (State) s 22 r (of) s 21 r (California) s (cmbx10.329) @sf 224 1324 p (2.3.2) s 52 r 80 c (opulated) s 16 r (Places) s (cmr10.329) @sf 224 1410 p 70 c -3 r (or) s 16 r (eac) s 104 c 16 r 112 c 1 r (opulated) s 17 r (place) s 16 r (within) s 17 r 97 c 17 r (state) s 17 r (or) s 16 r (state-equiv) s -1 r (alen) s -1 r (t,) s 16 r (an) s 16 r (instance) s 17 r (of) s 224 1466 p (an) s (cmtt10.329) @sf 15 r (usPlace) s (cmr10.329) @sf 15 r (ob) s 3 r (ject) s 15 r (is) s 15 r (used.) s 20 r (The) s 16 r (RDN) s 15 r (is) s 15 r (formed) s 15 r (as) s (cmtt10.300) @sf 338 1553 p (usPlaceCode) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 1647 p (e.g.,) s (cmtt10.300) @sf 338 1733 p (usPlaceCode) s 22 r (is) s 21 r (37000) s (cmr10.329) @sf 224 1827 p (pro) s (vides) s 18 r (the) s 19 r (RDN) s 19 r (for) s 19 r (the) s 19 r (Hartford) s 19 r (en) s (try) s 18 r (immediately) s 19 r (sub) s 1 r (ordinate) s 19 r (to) s 19 r (the) s (cmtt10.329) @sf 224 1883 p (usStateOrEquivalent) s (cmr10.329) @sf 18 r (en) s -1 r (try) s 17 r (for) s 17 r (the) s 18 r (State) s 17 r (of) s 18 r (Connecticut.) s 27 r (Of) s 17 r (course,) s 19 r (this) s 224 1940 p (en) s (try) s 14 r 119 c (ould) s 14 r (con) s (tain) s 14 r (man) s 121 c 14 r (other) s 15 r (attributes) s 15 r (suc) s 104 c 14 r (as) s (cmtt10.300) @sf 338 2027 p (localityName) s 22 r (is) s 21 r (Hartford) s (cmbx10.329) @sf 224 2147 p (2.3.3) s 52 r (Organizations) s 18 r (with) s 17 r (Regional) s 18 r (Standing) s (cmr10.329) @sf 224 2233 p (An) s 15 r (organization) s 15 r (is) s 15 r (said) s 15 r (to) s 15 r (ha) s -1 r 118 c -1 r 101 c 14 r (regional) s 15 r (standing) s 15 r (if) s 15 r (it) s 14 r (is) s 15 r (registered) s 15 r (with) s 15 r (the) s 224 2289 p (\\Secretary) s 15 r (of) s 15 r (State") s 15 r (or) s 14 r (similar) s 15 r (en) s (tit) s -1 r 121 c 13 r (within) s 15 r (that) s 15 r (region,) s 15 r (as) s 15 r (an) s 14 r (en) s (tit) s -1 r 121 c 14 r (doing) s 224 2346 p (business) s 15 r (in) s 15 r (the) s 16 r (region.) s 295 2402 p 70 c -3 r (or) s 17 r (eac) s 104 c 17 r (organization) s 19 r (with) s 18 r (regional) s 18 r (standing,) s 20 r (an) s 18 r (instance) s 18 r (of) s 19 r (an) s (cmtt10.329) @sf 18 r (organ) s 224 2459 p (ization) s (cmr10.329) @sf 15 r (ob) s 3 r (ject) s 15 r (is) s 15 r (used.) s 20 r (The) s 15 r (RDN) s 16 r (is) s 15 r (formed) s 15 r (as) s 960 2592 p 53 c @eop 6 @bop0 (cmr10.329) @sf [<000100000003800000038000000380000007C0000007C0000007C000000F2000000F2000001F3000001E1000001E1000003C 0800003C0800003C0800007804000078040000F8060000F0020000F0020001F0010001E0010001E0010003C0008003C00080 03C0008007800040078000400F8000600F0000601F8000F8FFF003FE> 32 32 -1 1 34.090] 86 @dc (cmbx10.360) @sf [<01FFFF0001FFFF000007E0000007E0000007E0000007E0000007E0000007E0000007E000FFFFFF00FFFFFF00E003E0007003 E0003803E0001803E0000C03E0000E03E0000703E0000303E0000183E00001C3E00000E3E0000073E0000033E000001BE000 001FE000000FE0000007E0000003E0000003E0000001E0000000E000> 32 32 -2 0 28.642] 52 @dc [<0007FE0000003FFFC00000FE07F00003F801FC0007F000FE000FE0007F001FC0003F801FC0003F803F80001FC07F80001FE0 7F80001FE07F00000FE0FF00000FF0FF00000FF0FF00000FF0FF00000FF0FF00000FF0FF00000FF0FF00000FF0FF00000FF0 FF00000FF07F00000FE07F00000FE07F00000FE03F80001FC03F80001FC01F80001F801FC0003F800FE0007F0007F000FE00 03F801FC0000FE07F000003FFFC0000007FE0000> 40 34 -3 0 43.032] 79 @dc [ 24 22 -2 0 25.459] 122 @dc [<000C0038007000E001C003C0038007800F000F001E001E003E003C003C007C007C007C007800F800F800F800F800F800F800 F800F800F800F800F80078007C007C007C003C003C003E001E001E000F000F000780038003C001C000E000700038000C> 16 49 -4 12 22.277] 40 @dc [<1F0000007F80000069E00000FC600000FC300000FC3800007818000000180000000C0000000C0000000E0000000E0000001F 0000001F0000003F8000003F8000007FC000007EC000007EC00000FC600000FC600001F8300001F8300003F8180003F01800 07F01C0007E00C000FE00E000FC006000FC00700FFF01FE0FFF01FE0> 32 32 -1 10 30.233] 121 @dc [<01FC3FE007FF3FE00F81FF001F007F003E003F007E003F007C003F00FC003F00FC003F00FC003F00FC003F00FC003F00FC00 3F00FC003F007C003F007C003F007E003F003E003F001F007F000FC1FF0007FFBF0000FE3F0000003F0000003F0000003F00 00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F000001FF000001FF00> 32 35 -2 0 31.824] 100 @dc [ 16 49 -3 12 22.277] 41 @dc (cmtt10.329) @sf [<007C0001FF0003FF800783C00F01E00E00E01C00701C00701C00701C00701C00701C00701C00701C00701C00701C00701C00 701C00701C00701C00701C00701C00701C00701C00701C0070FF83FEFF83FEFF83FE> 24 28 0 0 23.863] 85 @dc (cmbx10.360) @sf [<03FC000FFF001C0FC03003E06003F0F801F8FC01F8FC01FCFC01FCFC01FC7801FC0001FC0001FC0001F80001F81001F01803 F01E07E01FFF8019FE001800001800001800001800001FF8001FFE001FFF001FFFC01FFFE01FFFE01E00F0100030> 24 32 -3 0 28.642] 53 @dc [ 40 34 -2 0 43.309] 65 @dc [ 48 34 -3 0 54.378] 77 @dc [<00FF000003FFE00007C1F0000F00F8001F007C003E007E003E007E007E007F007E007F007E007F00FE007F00FE007F00FE00 7F00FE007F00FF007E00FF007E00FF807C00FE80F800FE7FF000FE3FC000FE0000007E0000007E0000007E0078003F00FC00 1F00FC001F00FC000F80FC0007C0780001F0380000FFF000001FC000> 32 32 -2 0 28.642] 54 @dc [ 40 34 -2 0 39.158] 80 @dc [ 32 32 -2 10 31.824] 112 @dc (cmr10.329) @sf [ 24 31 -2 0 28.408] 76 @dc (cmbx10.329) @sf [ 32 31 -2 0 31.438] 76 @dc (cmtt10.300) @sf [<00E00001F00001F00001B00003B80003B80003B800031800071C00071C00071C00071C00060C000E0E000E0E000E0E000E0E 001C07001C07001C07001C0700380380FE0FE0FF1FE0FE0FE0> 24 25 -1 0 21.793] 86 @dc [<0F1E000F1E000F1E001DB7001DB7001DB7001DB70019B30019F30019F30038E380380380380380380380380380FF1FE0FFBF E0FF1FE0> 24 18 -1 0 21.793] 119 @dc (cmr10.329) @sf [<01F000061C000C0E001807003807003803807003807003C07003C0F003C0F003C0F003C0F003C0F003C0F80380F80380F807 00F40600F21C00F1F0007000007000007800003800003803001C07800C07800E0380070100018200007C00> 24 31 -2 1 22.727] 54 @dc 6 @bop1 (cmtt10.300) @sf 338 307 p (organizationName) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 387 p (e.g.,) s (cmtt10.300) @sf 338 459 p (organizationName) s 22 r (is) s 21 r (Performance) s 22 r (Systems) s 22 r (International,) s 22 r (Inc.) s (cmr10.329) @sf 224 539 p (migh) s 116 c 10 r (pro) s (vide) s 11 r (the) s 11 r (RDN) s 12 r (for) s 11 r 97 c 12 r (business) s 11 r (en) s (tit) s -1 r 121 c 10 r (registered) s 11 r (with) s 12 r (the) s 11 r (State) s 12 r (of) s 11 r (Vir-) s 224 595 p (ginia.) s 20 r (In) s 13 r (this) s 13 r (case,) s 14 r (the) s 13 r (en) s (try) s 12 r (th) s (us) s 12 r (named) s 13 r 119 c (ould) s 12 r 98 c 1 r 101 c 14 r (immediately) s 13 r (sub) s 1 r (ordinate) s 224 652 p (to) s 15 r (the) s (cmtt10.329) @sf 15 r (usStateOrEquivalent) s (cmr10.329) @sf 16 r (en) s -1 r (try) s 14 r (for) s 16 r (the) s 15 r (State) s 15 r (of) s 15 r (Virginia.) s 295 708 p (Note) s 15 r (that) s 16 r (other) s 16 r (non-distinguished) s 16 r (attributes,) s 16 r (suc) s -1 r 104 c 15 r (as) s 16 r (an) s 16 r (ANSI) s 15 r 110 c (umeric) s 224 765 p (name) s 15 r (form) s 15 r 118 c -1 r (alue,) s 14 r (ma) s 121 c 14 r 98 c 1 r 101 c 15 r (included) s 16 r (in) s 15 r (an) s 15 r (en) s (try) s -4 r 46 c (cmbx10.360) @sf 224 884 p (2.4) s 57 r (Naming) s 20 r (within) s 19 r (Organizations) s 19 r (\(of) s 19 r (an) s -1 r 121 c 18 r (standing\)) s (cmr10.329) @sf 224 970 p (The) s 16 r (in) s (ternal) s 15 r (structure) s 16 r (of) s 17 r (eac) s -1 r 104 c (cmtt10.329) @sf 16 r (usOrganization) s (cmr10.329) @sf 16 r (or) s (cmtt10.329) @sf 16 r (organization) s (cmr10.329) @sf 16 r (ob) s 3 r (ject) s 16 r (is) s 224 1026 p 97 c 15 r (matter) s 15 r (for) s 16 r (that) s 15 r (organization) s 15 r (to) s 15 r (establish.) s 295 1082 p (It) s 17 r (is) s 17 r (strongly) s 17 r (recommended) s 17 r (that) s (cmtt10.329) @sf 17 r (organizationalUnit) s (cmr10.329) @sf 17 r (ob) s 3 r (jects) s 17 r 98 c 1 r 101 c 17 r (used) s 224 1139 p (for) s 17 r (structuring.) s 24 r (\(If) s 17 r (an) s 16 r (organization) s 17 r (uses) s 16 r 97 c 17 r (lo) s 1 r (calit) s (y-based) s 15 r (organizational) s 17 r (hi-) s 224 1195 p (erarc) s 104 c -1 r 121 c -4 r 44 c 12 r (this) s 14 r (information) s 13 r (can) s 13 r (still) s 13 r 98 c 2 r 101 c 13 r (represen) s (ted) s 12 r (using) s 13 r (the) s (cmtt10.329) @sf 13 r (organizational) s 224 1252 p (Unit) s (cmr10.329) @sf 15 r (ob) s 3 r (ject.\)) s (cmbx10.360) @sf 224 1371 p (2.5) s 57 r (Naming) s 20 r (within) s 19 r (ADDMDs) s (cmr10.329) @sf 224 1457 p (The) s 13 r (in) s -1 r (ternal) s 12 r (structure) s 12 r (of) s 13 r (eac) s -1 r 104 c (cmtt10.329) @sf 12 r (nadfADDMD) s (cmr10.329) @sf 12 r (ob) s 3 r (ject) s 12 r (is) s 13 r 97 c 12 r (matter) s 13 r (for) s 12 r (that) s 12 r (service-) s 224 1513 p (pro) s (vider) s 14 r (to) s 15 r (establish.) s (cmbx10.360) @sf 224 1632 p (2.6) s 57 r (Naming) s 20 r (within) s 19 r 97 c 19 r 80 c -1 r (opulated) s 18 r (Place) s (cmr10.329) @sf 224 1718 p 65 c 116 c 14 r (the) s 15 r (lo) s 1 r (cal) s 16 r (lev) s -1 r (el) s 14 r (\(at) s 16 r (least\)) s 15 r (three) s 15 r (kinds) s 15 r (of) s 15 r (names) s 15 r (ma) s 121 c 14 r 98 c 2 r 101 c 15 r (registered:) s (cmsy10.329) @sf 292 1797 p 15 c (cmr10.329) @sf 23 r (The) s 15 r (Lo) s 1 r (cal) s 16 r (Go) s -1 r 118 c -1 r (ernmen) s -1 r 116 c (cmsy10.329) @sf 292 1885 p 15 c (cmr10.329) @sf 23 r (Organizations) s 15 r (\(and) s 15 r (other) s 16 r (en) s -1 r (tities\)) s 14 r (with) s 16 r (Lo) s 1 r (cal) s 15 r (Standing) s (cmsy10.329) @sf 292 1973 p 15 c (cmr10.329) @sf 23 r 80 c (ersons) s (cmbx10.329) @sf 224 2091 p (2.6.1) s 52 r (The) s 18 r (Lo) s 1 r (cal) s 18 r (Go) s -1 r 118 c -1 r (ernmen) s -2 r 116 c (cmr10.329) @sf 224 2177 p 70 c -3 r (or) s 17 r (the) s 17 r (Lo) s 1 r (cal) s 18 r (Go) s -1 r 118 c -1 r (ernmen) s -1 r (t,) s 17 r (if) s 17 r (an) s 121 c -4 r 44 c 17 r (an) s 17 r (instance) s 18 r (of) s 17 r (an) s (cmtt10.329) @sf 17 r (organization) s (cmr10.329) @sf 18 r (ob) s 2 r (ject) s 224 2233 p (is) s 15 r (used.) s 21 r (The) s 15 r (RDN) s 15 r (is) s 15 r (formed) s 15 r (as:) s (cmtt10.300) @sf 338 2306 p (organizationName) s 22 r (is) s 21 r (Government) s 22 r (of) s 22 r () s (cmr10.329) @sf 224 2385 p (e.g.,) s (cmtt10.300) @sf 338 2458 p (organizationName) s 22 r (is) s 21 r (Government) s 22 r (of) s 22 r (the) s 22 r (City) s 22 r (of) s 21 r (Mountain) s 22 r (View) s (cmr10.329) @sf 960 2592 p 54 c @eop 7 @bop0 (cmtt10.300) @sf [<07FC000FFE0007FC0000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0 0000E000E0E0E0E0E0E0E0E0E0E0E0E0FFFFE0FFFFE07FFFE0> 24 25 -1 0 21.793] 84 @dc (cmbx10.360) @sf [<0060000000F0000001F8000001F8000001F8000001F8000001F8000001F8000000F8000000F8000000F8000000F800000078 000000780000003C0000003C0000001C0000001C0000000C0000000E000000060000C0030000C0018000E000C00060006000 600060007FFFF0007FFFF8007FFFFC003FFFFE003FFFFF003FFFFF003C00000030000000> 32 34 -3 0 28.642] 55 @dc (cmr10.329) @sf [<000400020000000C00030000000E00070000000E00070000001E00078000001F000F8000001F000F8000001F000F8000003C 801E4000003C801E4000003C801E40000078C03E20000078403C20000078403C200000F0403C100000F02078100000F02078 100001F02078080001E010F0080001E010F0080003E010F00C0003C009E0040003C009E0040003C009E00400078007C00200 078007C00200078007C002000F0007C001000F00078001000F00078003801F800FC007C0FFF07FF81FF0> 48 32 -1 1 46.716] 87 @dc (cmtt10.329) @sf [<7FC000FFE0007FC0000E00000E00000E00000E00000E00000E00000E00000E3E000EFF800FFFC00FC1E00F80E00F00700F00 700E00380E00380E00380E00380E00380E00380E00700F00700F80E00FC1E07FFFC0FEFF807E3E00> 24 30 0 10 23.863] 112 @dc (cmtt10.300) @sf [<2070783C1C0E0E0E0E1E3E3C18> 8 13 -7 -12 21.793] 39 @dc (cmr10.329) @sf [<03000007800007800007800007800007800007800007800003800003800003800003800001800001C00000C00000C0000040 000040000020000020000010000008000008008004008002008002004001007FFF807FFF807FFFC0400000> 24 31 -3 1 22.727] 55 @dc 7 @bop1 (cmbx10.329) @sf 224 307 p (2.6.2) s 52 r (Organizations) s 18 r (with) s 17 r (Lo) s 2 r (cal) s 17 r (Standing) s (cmr10.329) @sf 224 393 p (An) s 20 r (organization) s 20 r (is) s 20 r (said) s 20 r (to) s 19 r (ha) s 118 c -1 r 101 c 19 r (lo) s 1 r (cal) s 20 r (standing) s 20 r (if) s 19 r (it) s 20 r (is) s 20 r (registered) s 20 r (with) s 20 r (the) s 224 449 p (Coun) s 116 c -1 r 121 c 21 r (or) s 22 r (Cit) s 121 c 21 r (Clerk) s 22 r (or) s 23 r (similar) s 22 r (en) s (tit) s -1 r 121 c 21 r (within) s 22 r (that) s 22 r (lo) s 2 r (calit) s -1 r 121 c 22 r (as) s 22 r (an) s 22 r (en) s (tit) s -1 r 121 c 224 506 p (\\doing) s 15 r (business") s 15 r (in) s 16 r (that) s 15 r (place.) s 295 562 p 70 c -3 r (or) s 24 r (eac) s -1 r 104 c 24 r (organization) s 25 r (with) s 24 r (lo) s 2 r (cal) s 24 r (standing,) s 27 r (an) s 25 r (instance) s 24 r (of) s 25 r (an) s (cmtt10.329) @sf 25 r (organ) s 224 619 p (ization) s (cmr10.329) @sf 15 r (ob) s 3 r (ject) s 15 r (is) s 15 r (used.) s 20 r (The) s 15 r (RDN) s 16 r (is) s 15 r (formed) s 15 r (as) s (cmtt10.300) @sf 338 706 p (organizationName) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 800 p (e.g.,) s (cmtt10.300) @sf 338 887 p (organizationName) s 22 r (is) s 21 r (The) s 22 r (Tied) s 22 r (House) s (cmr10.329) @sf 224 981 p (migh) s 116 c 19 r (pro) s (vide) s 20 r (the) s 20 r (RDN) s 21 r (for) s 20 r 97 c 21 r (business) s 21 r (en) s -1 r (tit) s -1 r 121 c 20 r (registered) s 20 r (with) s 21 r (the) s 20 r (Cit) s 121 c 20 r (of) s 224 1037 p (Moun) s (tain) s 15 r (View.) s 25 r (In) s 16 r (this) s 17 r (case,) s 17 r (the) s 17 r (en) s -1 r (try) s 16 r (th) s (us) s 15 r (named) s 17 r 119 c -1 r (ould) s 16 r 98 c 1 r 101 c 17 r (immediately) s 224 1094 p (sub) s 1 r (ordinate) s 16 r (to) s 15 r (the) s (cmtt10.329) @sf 15 r (usPlace) s (cmr10.329) @sf 15 r (en) s (try) s 14 r (for) s 15 r (the) s 15 r (Cit) s 121 c 14 r (of) s 15 r (Moun) s (tain) s 14 r (View.) s 295 1150 p (Note) s 15 r (that) s 16 r (other) s 16 r (non-distinguished) s 16 r (attributes,) s 16 r (suc) s -1 r 104 c 15 r (as) s 16 r (an) s 16 r (ANSI) s 15 r 110 c (umeric) s 224 1207 p (name) s 15 r (form) s 15 r 118 c -1 r (alue,) s 14 r (ma) s 121 c 14 r 98 c 1 r 101 c 15 r (included) s 16 r (in) s 15 r (an) s 15 r (en) s (try) s -4 r 46 c (cmbx10.360) @sf 224 1328 p (2.7) s 57 r (Naming) s 20 r (of) s 19 r 80 c -1 r (ersons) s (cmr10.329) @sf 224 1414 p (Within) s 11 r 97 c 11 r (place,) s 12 r (there) s 11 r (is) s 11 r (no) s 11 r (cen) s (tralized) s 10 r (naming) s 11 r (en) s (tit) s -1 r 121 c 10 r (whic) s 104 c 10 r (registers) s 11 r 112 c 1 r (ersons.) s 224 1471 p (It) s 19 r (is) s 19 r (prop) s 1 r (osed) s 19 r (that) s 19 r (en) s -1 r (tries) s 18 r (for) s 19 r 112 c 1 r (ersons) s 19 r 98 c 1 r 101 c 19 r (immediately) s 19 r (sub) s 1 r (ordinate) s 19 r (to) s 19 r (the) s (cmtt10.329) @sf 224 1527 p (usPlace) s (cmr10.329) @sf 15 r (ob) s 3 r (ject) s 15 r (whic) s 104 c 14 r (most) s 15 r (accurately) s 15 r (re\015ects) s 15 r (their) s 15 r (place) s 16 r (of) s 15 r (residence.) s 295 1583 p 70 c -3 r (or) s 12 r (eac) s 104 c 13 r 112 c 1 r (erson) s 13 r (\(wishing) s 14 r (to) s 13 r (ha) s 118 c -1 r 101 c 12 r (an) s 14 r (en) s (try) s 12 r (in) s 14 r (the) s 13 r (Directory\),) s 14 r (an) s 13 r (instance) s 224 1640 p (of) s 14 r 97 c (cmtt10.329) @sf 15 r (residentialperson) s (cmr10.329) @sf 14 r (is) s 14 r (used.) s 20 r (The) s 14 r (RDN) s 14 r (is) s 15 r (usually) s 14 r 109 c (ulti-v) s -3 r (alued,) s 14 r (formed) s 224 1696 p (as) s (cmtt10.300) @sf 338 1784 p (commonName) s 22 r (is) s 21 r () s 338 1833 p (streetAddress) s 22 r (is) s 21 r () s (cmr10.329) @sf 224 1927 p (Ho) s 119 c -1 r (ev) s -2 r (er,) s 19 r 98 c 1 r (ecause) s (cmtt10.329) @sf 19 r (streetAddress) s (cmr10.329) @sf 18 r (is) s 19 r (often) s 19 r (considered) s 18 r (priv) s -1 r (ate) s 17 r (information,) s 224 1984 p (based) s 20 r (on) s 20 r (agreemen) s 116 c 19 r (with) s 20 r (the) s 20 r (en) s -1 r (tit) s -1 r 121 c 19 r (managing) s 20 r (the) s 20 r (DMD) s 20 r (and) s 20 r (the) s 20 r 112 c 1 r (erson,) s 224 2040 p (some) s 16 r (other,) s 17 r (distinguishing) s 16 r (attribute) s 16 r (ma) s 121 c 15 r 98 c 1 r 101 c 16 r (used,) s 17 r (including) s 16 r 97 c 16 r (\\serial) s 16 r 110 c (um-) s 224 2097 p 98 c 1 r (er") s 20 r (\(ha) s (ving) s 19 r (no) s 20 r (other) s 20 r (purp) s 1 r (ose\).) s 34 r (It) s 20 r (should) s 20 r 98 c 1 r 101 c 20 r (noted) s 20 r (ho) s 119 c -1 r (ev) s -2 r (er) s 19 r (that) s 20 r (this) s 20 r (is) s 224 2153 p (non-helpful) s 14 r (in) s 14 r (regards) s 14 r (to) s 14 r (searc) s (hing,) s 13 r (unless) s 14 r (other) s 14 r (attribute) s 14 r 118 c -1 r (alues) s 13 r (con) s -1 r (taining) s 224 2209 p (meaningful) s 12 r (information) s 12 r (are) s 12 r (added) s 12 r (to) s 12 r (the) s 12 r (en) s (try) s 11 r (and) s 12 r (made) s 11 r 97 c 118 c -2 r (ailable) s 11 r (for) s 12 r (public) s 224 2266 p (access.) s 960 2592 p 55 c @eop 8 @bop0 (cmbx10.360) @sf [<01FF00000FFFE0001F00F0003C001C0078001C00F8000E00F0000E00F0000F00F0000F00F0001F00F0007F007801FF007803 FE003C0FFE001F3FFC0007FFF80003FFF00007FFE0000FFF80001FFFE0001FF8F0003FE078003FC03C003F003C003E003C00 3C003C001C003C001C0078000E0078000701F00003FFE00000FF0000> 32 32 -2 0 28.642] 56 @dc [ 24 34 -1 0 21.723] 73 @dc (cmr10.329) @sf [<40202010101008080878F8F8F0700000000000000000000070F8F8F870> 8 29 -4 9 12.626] 59 @dc (cmtt10.329) @sf [<1E00003F00007F80007BC00079E00000E00000F00000700000700000700000780000780000780000DC0000CC0000CC0001CE 0001CE00038E000386000387000707000707000703800E03800E03800E01C07F8FF0FF8FF87F8FF0> 24 30 -1 10 23.863] 121 @dc [<00F80003FE0007FF800F07C01E01C03C00E03800E07000E07000E0700000E00000E00000E00000E00000E00000E00000E000 00E000007000007000E07000E03800E03C01E01E03E00F07E007FFE003FEE000F8E0> 24 28 -2 0 23.863] 67 @dc [<7F8FF0FF8FF87F8FF00F0780070700038E00039E0001DC0000F80000F00000700000F80001F80001DC00039E00078E000707 007F8FF07F9FF07F8FF0> 24 20 -1 0 23.863] 120 @dc (cmbx10.360) @sf [<03F800000FFF00001C0FC0001E03E0003F01F0003F00F8003F00FC003F00FC001E007E0000007E0000007E0000007F0003FC 7F000FFE7F001F017F003E01FF007E00FF007E00FF00FE007F00FE007F00FE007F00FE007F00FE007E00FE007E00FE007E00 7E007C007E007C003E00F8001F00F0000F83E00007FFC00000FF0000> 32 32 -2 0 28.642] 57 @dc [<0000FF8000000FFFF000003F807800007E000C0000FC00060001F800030003F800018003F000018007F00000C007F00000C0 07F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C0 07F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C007F00000C0 07F00000C007F00000C0FFFF801FFEFFFF801FFE> 40 34 -2 0 44.070] 85 @dc (cmr10.329) @sf [ 32 31 -2 0 35.353] 75 @dc (cmbx10.432) @sf [<00FF800007FFF0001FFFFC003F01FE007C007F007E007F80FF007FC0FF003FC0FF003FE0FF003FE07E003FE03C003FE00000 3FE000003FE000003FC000003FC000007F8000007F0000007E000001FC0000FFF00000FFC0000007F0000001F8000001FC00 0000FE000000FF000000FF000F007F801F807F803F807F803F807F803F807F803F80FF001F00FF000F81FE0007FFFC0003FF F000007F8000> 32 39 -3 0 34.370] 51 @dc [ 40 27 -1 0 36.280] 120 @dc (cmr10.329) @sf [<03F0000C0C00100200200100600180C00080C000C0C000C0C000C0C001C04001C0600380300F80103F000C7E0007FC0003F8 000FF0001FC8003F06003E03007803007001806001806001806001802001803003001006000C0C0003F000> 24 31 -2 1 22.727] 56 @dc 8 @bop1 (cmbx10.360) @sf 224 307 p (2.8) s 57 r (Naming) s 20 r (of) s 19 r (OSI) s 19 r (En) s -1 r (tities) s (cmr10.329) @sf 224 393 p (Naming) s 20 r (of) s 20 r (OSI) s 20 r (application) s 21 r (pro) s 1 r (cesses) s 20 r (and) s 20 r (en) s (tities) s 19 r (remains) s 20 r (with) s 20 r (the) s 20 r (scop-) s 224 449 p (ing) s 22 r (DMD.) s 21 r (Ho) s 119 c -1 r (ev) s -2 r (er,) s 22 r (in) s 22 r (order) s 21 r (to) s 22 r (foster) s 21 r (in) s (terop) s (erabilit) s 121 c -4 r 44 c 22 r 116 c 119 c -1 r 111 c 20 r (requiremen) s (ts) s 224 506 p (are) s 14 r (made:) s 19 r (\014rst,) s 14 r (application) s 13 r (en) s (tit) s -2 r 121 c 13 r (ob) s 2 r (jects) s 14 r 109 c (ust) s 12 r 98 c 1 r 101 c 14 r (immediately) s 13 r (sub) s 1 r (ordinate) s 224 562 p (to) s 22 r (application) s 22 r (pro) s 2 r (cess) s 22 r (ob) s 2 r (jects;) s 26 r (and,) s 24 r (second,) s 24 r (application) s 22 r (en) s (tities) s 21 r (are) s 22 r (rep-) s 224 619 p (resen) s (ted) s 17 r 98 c 121 c 18 r (the) s (cmtt10.329) @sf 18 r (nadfApplicationEntity) s (cmr10.329) @sf 18 r (ob) s 3 r (ject,) s 19 r (whic) s 104 c 17 r (is) s 19 r (iden) s (tical) s 17 r (to) s 18 r (the) s (cmtt10.329) @sf 224 675 p (applicationEntity) s (cmr10.329) @sf 18 r (ob) s 3 r (ject) s 18 r (except) s 17 r (that) s 18 r (the) s 18 r (presence) s 18 r (of) s 18 r (an) s 18 r (attribute) s 18 r 118 c -1 r (alue) s 224 732 p (of) s (cmtt10.329) @sf 15 r (supportedApplicationContext) s (cmr10.329) @sf 15 r (is) s 16 r (mandatory) s -3 r 46 c (cmbx10.360) @sf 224 853 p (2.9) s 57 r (DUA) s 20 r (Algorithms) s (cmr10.329) @sf 224 939 p (In) s 11 r (order) s 10 r (to) s 11 r 98 c 1 r 101 c 11 r (e\013ectiv) s -1 r (e,) s 11 r (an) s 11 r (in) s -1 r (terrogation) s 10 r (algorithm) s 10 r 109 c (ust) s 10 r (ha) s -1 r 118 c -1 r 101 c 10 r (detailed) s 10 r (kno) s (wl-) s 224 996 p (edge) s 16 r (of) s 16 r (the) s 15 r (naming) s 16 r (structure.) s 22 r (The) s 16 r (basic) s 16 r (execution) s 15 r (of) s 16 r (suc) s 104 c 14 r (an) s 16 r (algorithm) s 16 r (is:) s 224 1052 p (tak) s 101 c 20 r (input) s 21 r (from) s 22 r (the) s 21 r (user) s 21 r (along) s 21 r (with) s 22 r (an) s 21 r (en) s (vironmen) s -2 r 116 c 21 r (of) s 21 r (user-options;) s 24 r (in-) s 224 1109 p 118 c (ok) s -1 r 101 c 13 r (Directory) s 15 r (op) s 1 r (erations) s 15 r (\(mostly) s 15 r (searc) s -1 r 104 c 14 r (and) s 15 r (read\);) s 14 r (in) s 15 r 98 c 1 r (et) s 119 c -1 r (een) s 14 r (op) s 1 r (erations,) s 224 1165 p (in) s (teract) s 19 r (with) s 20 r (user,) s 21 r (as) s 20 r (appropriate,) s 21 r (in) s 20 r (order) s 20 r (to) s 20 r (fo) s 1 r (cus) s 20 r (use) s 20 r (of) s 20 r (the) s 20 r (Directory) s 224 1221 p (op) s 1 r (erations.) s 295 1278 p (There) s 16 r (are) s 16 r (man) s -1 r 121 c 15 r 112 c 2 r (ossible) s 16 r (algorithms) s 16 r (whic) s -1 r 104 c 15 r (ma) s 121 c 15 r 98 c 1 r 101 c 16 r (used) s 16 r (with) s 16 r (this) s 16 r (nam-) s 224 1334 p (ing) s 20 r (sc) s (heme.) s 33 r (One) s 20 r (suc) s 104 c 19 r (algorithm) s 20 r (is) s 20 r (Kille's) s 20 r (User-F) s -3 r (riendly) s 19 r (Naming) s 20 r (Sc) s (heme) s 224 1391 p (\(NADF-35\).) s 24 r (Kille's) s 16 r (algorithm) s 16 r (is) s 16 r (based) s 17 r (on) s 16 r (ordered) s 16 r (but) s 17 r (un) s -1 r 116 c -1 r (yp) s (ed) s 17 r (input) s 16 r (from) s 224 1447 p (the) s 12 r (user,) s 12 r (coupled) s 12 r (with) s 11 r 97 c 12 r (searc) s (h-list) s 10 r (giving) s 12 r (lik) s (ely) s 11 r (places) s 11 r (to) s 12 r (start) s 11 r (in) s (terrogation.) s 224 1504 p (If) s 16 r (in) s -1 r 118 c -1 r (ok) s -1 r (ed) s 14 r (in) s (teractiv) s -1 r (ely) s -4 r 44 c 14 r (the) s 15 r (algorithm) s 16 r (will) s 15 r (query) s 16 r (the) s 15 r (user) s 15 r (to) s 16 r (select) s 15 r 98 c 1 r (et) s 119 c -1 r (een) s 224 1560 p (exact,) s 15 r (go) s 2 r 111 c 1 r (d,) s 15 r (and) s 15 r 112 c 1 r 111 c 2 r (or) s 15 r (matc) s (hes.) s (cmbx10.432) @sf 224 1703 p 51 c 69 r (The) s 23 r (Next) s 23 r (Step) s (cmr10.329) @sf 224 1805 p (The) s 13 r (prop) s 1 r (osal) s 12 r (outlined) s 13 r (ab) s 1 r 111 c 118 c -2 r 101 c 12 r (should) s 12 r 98 c 2 r 101 c 12 r (adequate) s 13 r (as) s 12 r (the) s 12 r (basis) s 13 r (for) s 12 r 97 c 13 r (long-term) s 224 1861 p (solution.) s 36 r (Note) s 20 r (that) s 20 r (inasm) s (uc) s -2 r 104 c 20 r (as) s 20 r (it) s 20 r (relies) s 20 r (on) s 21 r (existing) s 20 r (naming) s 20 r (authorities,) s 224 1918 p (there) s 13 r (is) s 13 r (little) s 13 r 99 c (hance) s 12 r (that) s 13 r (the) s 13 r (\\\014nal") s 13 r (national) s 13 r (decision) s 13 r (could) s 13 r (obsolete) s 13 r (it.) s 20 r (\(T) s -3 r 111 c 224 1974 p (do) s 21 r (so) s 21 r 119 c (ould) s 20 r (require) s 21 r 97 c 21 r (national) s 22 r (decision) s 21 r (that) s 21 r (disregards) s 21 r (existing) s 21 r (national) s 224 2031 p (and) s 15 r (regional) s 15 r (infrastructure,) s 14 r (and) s 15 r (establishes) s 15 r (some) s 15 r (en) s -1 r (tirely) s 14 r (new) s 15 r (and) s 14 r (di\013eren) s 116 c 224 2087 p (national) s 15 r (naming) s 15 r (infrastructure.\)) s 295 2144 p (As) s 13 r (suc) s (h,) s 13 r (it) s 14 r (is) s 14 r (our) s 13 r 98 c 1 r (elief) s 14 r (that) s 14 r (once) s 14 r (the) s 13 r (NADF) s 14 r (has) s 14 r (reac) s -1 r (hed) s 13 r (consensus) s 14 r (on) s 13 r 97 c 224 2200 p (prop) s 1 r (osal) s 17 r (suc) s -1 r 104 c 16 r (as) s 16 r (the) s 16 r (one) s 16 r (ab) s 1 r 111 c 118 c -1 r (e,) s 15 r (that) s 17 r (the) s 16 r (NADF) s 16 r (should) s 16 r (submit) s 16 r (its) s 16 r 119 c (ork) s 15 r (as) s 224 2257 p (con) s (tribution) s 17 r (to) s 17 r (Study) s 18 r (Group) s 17 r 68 c 18 r (of) s 18 r (the) s 17 r (US) s 18 r (CCITT) s 17 r (National) s 18 r (Committee) s 18 r (as) s 224 2313 p (the) s 15 r (basis) s 15 r (for) s 16 r (national) s 15 r 112 c 1 r (olicy) s -3 r 46 c 960 2592 p 56 c @eop 9 @bop0 (cmbx10.432) @sf [<007FFFF8007FFFF8007FFFF80000FE000000FE000000FE000000FE000000FE000000FE000000FE000000FE00FFFFFFF8FFFF FFF8FFFFFFF8E0007E0070007E0038007E001C007E000E007E000E007E0007007E0003807E0001C07E0000E07E0000E07E00 00707E0000387E00001C7E00000E7E00000E7E0000077E000003FE000001FE000000FE000000FE0000007E0000003E000000 1E0000000E00> 32 39 -2 0 34.370] 52 @dc [ 32 42 -2 0 36.280] 107 @dc [<00078003C00000078003C000000FC007E000000FC007E000000FC007E000001FE00FF000001FE00FF000003FF01FF800003F F01FB800003FF01FB800007F783F3C00007F383F1C0000FF383F1E0000FE1C7E0E0000FE1C7E0E0001FE1EFC0F0001FC0EFC 070001FC0EFC070003F807F8038003F807F8038007F807F803C007F003F001C007F003F001C00FE007E000E0FFFE7FFC0FFE FFFE7FFC0FFEFFFE7FFC0FFE> 48 27 -1 0 49.646] 119 @dc [<003FC3FF8000FFF3FF8003F03BFF8007C00FF8000F8007F8001F8003F8003F8003F8007F0003F8007F0003F8007F0003F800 FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F8007F0003F8007F0003F8007F0003F800 3F8003F8001F8003F8000FC007F80007E00FF80003F03FF80000FFFBF800001FE3F800000003F800000003F800000003F800 000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F80000003FF800 00003FF80000003FF800> 40 42 -2 0 38.189] 100 @dc (cmr10.329) @sf [<007FFE00000007C000000003C000000003C000000003C000000003C000000003C000000003C000000003C000000003C00000 0003C000000003C000000003C000000007C000000007A00000000FB00000001F100000001E080000003E080000003C040000 007C04000000F802000000F003000001F001000001E000800003E000800007C000400007800040000F800060001F8000F800 FFF003FF00> 40 31 -1 0 34.090] 89 @dc [<03F0000E1C001C0E00180600380700780780700380700380700380F003C0F003C0F003C0F003C0F003C0F003C0F003C0F003 C0F003C0F003C0F003C0F003C0F003C07003807003807003807003803807001806001C0E000E1C0003F000> 24 31 -2 1 22.727] 48 @dc [<0FC000107000201800700C00780E0078060030070000070000038000038000038003E3C00E13C0180BC03807C07007C07007 C0F003C0F003C0F003C0F003C0F003C0F00380F003807003807007003807003806001C0C000E180003F000> 24 31 -2 1 22.727] 57 @dc (cmti10.329) @sf [<00FE00000381C000060020000C001800180004003800020038000100700001007000008070000080F0000080F0000000F000 0000F0000000F0000000780000007800000078000000780000003C0000003C0000001E0000101E0000100F00001807000018 0380001801C0001800C0001C0060003C0038003C001C004C000781860000FE02> 32 33 -6 1 32.524] 67 @dc [<07E000000C18000038040000300200007001000070008000F0004000F0004000F0002000F0002000F0002000780010007800 100078001000780010003C0008003C0008003C0008003C0008001E0004001E0004001E0004001E0004000F0002000F000200 0F0002000F00020007800100078001000780010007C003C07FFC1FF8> 32 32 -9 1 33.787] 85 @dc (cmr10.329) @sf [<0000078000000FC000001FE000001FE000003FF0000038700000383000003010001FB01000F0F01001E0380007A03E000F20 4F000E2047001E1087803C0F03C03C0003C07C0003E0780001E0780001E0F80001F0F80001F0F80001F0F80001F0F80001F0 F80001F0F80001F0F80001F0F80001F0780001E07C0003E07C0003E03C0003C03C0003C01E0007800E0007000F000F000780 1E0001C0380000F0F000001F8000> 32 41 -3 9 35.353] 81 @dc [ 24 45 -3 11 22.727] 47 @dc (cmti10.329) @sf [ 32 31 -8 0 32.524] 84 @dc [ 40 31 -3 0 33.787] 72 @dc [<01FC0000078380000E00E0001C00700038003C0038001E0078000F007000070070000380F00003C0F00001C0F00001E0F000 00E0F00000F0F00000F0780000787800007878000078780000783C0000383C0000381C0000381E0000380E00003807000038 078000380380007001C0007000E00060003000E0001C01C0000707000001FC00> 32 33 -6 1 34.847] 79 @dc [ 40 31 -3 0 33.787] 78 @dc [ 40 31 -2 0 33.787] 88 @dc [ 8 5 -5 0 13.939] 46 @dc [<1F000061C000406000803000803800801C00E01E00F00E00F00F00700F00000F000007800007800007800007800807000C07 00060600058C0004780004000002000002000002000002000001000001000001FE0001FF8000FFC000C060> 24 31 -5 1 23.232] 53 @dc [<0FC000187000303800701C00700E00700700F00700F00780F00380F003C07003C07801C07801E07801E07801E03C00F03C00 F03C00F03C00F01E00701E00780E00780F00780F007807003803803803803001C07000E0700030E0000F80> 24 31 -4 1 23.232] 48 @dc [ 32 32 -2 0 33.787] 65 @dc [ 32 31 -3 0 29.671] 70 @dc 9 @bop1 (cmbx10.432) @sf 224 307 p 52 c 69 r (Ac) s -1 r (kno) s -2 r (wledgemen) s -2 r (ts) s (cmr10.329) @sf 224 409 p (This) s 15 r (do) s 2 r (cumen) s -1 r 116 c 14 r (is) s 16 r (based) s 15 r (on) s 15 r (man) s 121 c 14 r (sources,) s 15 r (including,) s 15 r (but) s 15 r (not) s 15 r (limited) s 16 r (to:) s (cmsy10.329) @sf 292 502 p 15 c (cmti10.329) @sf 23 r (Listing) s 22 r (Servic) s -1 r (es) s 20 r (Datab) s -1 r (ase) s 21 r (Generic) s 22 r 82 c -2 r 101 c -2 r (quir) s -2 r (ements) s (cmr10.329) @sf 44 c 22 r (Bellcore) s 21 r 84 c -3 r (A-TSY-) s 338 559 p (000985;) s (cmsy10.329) @sf 292 653 p 15 c (cmti10.329) @sf 23 r (Common) s 22 r (Dir) s -2 r 101 c -2 r (ctory) s 21 r (Use) s (cmr10.329) @sf 24 r (ED) s 21 r (013) s 21 r (\(Q/511\)) s 21 r (\(EW) s (OS/EGDIR/90/156\);) s 338 709 p (and,) s (cmsy10.329) @sf 292 803 p 15 c (cmti10.329) @sf 23 r (The) s 16 r (THORN) s 17 r (X.500) s 16 r (Naming) s 16 r 65 c 114 c -2 r (chite) s -3 r (ctur) s -2 r 101 c (cmr10.329) @sf 18 r (\(UCL-45) s 15 r (revision) s 15 r (6.1\).) s 224 897 p (In) s 16 r (addition,) s 16 r (discussion) s 15 r (within) s 16 r (the) s (cmti10.329) @sf 15 r (North) s 17 r 65 c (meric) s -2 r (an) s 15 r (Dir) s -1 r 101 c -2 r (ctory) s 15 r 70 c -2 r (orum) s (cmr10.329) @sf 18 r (\(when) s 224 953 p (this) s 23 r (do) s 1 r (cumen) s 116 c 21 r 119 c (as) s 22 r (originally) s 22 r (con) s (tributed) s 21 r (as) s 23 r (NADF-71\),) s 24 r (also) s 23 r (resulted) s 22 r (in) s 224 1010 p (substan) s (tiv) s -1 r 101 c 14 r (impact.) s 960 2592 p 57 c @eop 10 @bop0 (cmbx10.432) @sf [<1C003E007F00FF80FF80FF807F003E001C000000000000000000000000000000000000001C003E007F00FF80FF80FF807F00 3E001C00> 16 27 -5 0 19.094] 58 @dc (cmbx10.360) @sf [<03FFFFF80003FFFFF8000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F80000 0003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F80000 0003F80000C003F80060C003F80060C003F80060C003F80060E003F800E0E003F800E06003F800C07003F801C07803F803C0 7E03F80FC07FFFFFFFC07FFFFFFFC0> 40 33 -2 0 39.849] 84 @dc (cmbx10.329) @sf [<1FC03FF07878FC7CFC3C783E303E003E003E003E003E003E003E003E003E003E003E003E003E003E003E003E003E003E003E 003E003E01FE01FE0000000000000000000000000038007C00FE00FE00FE007C0038> 16 42 3 9 15.972] 106 @dc [<0007FC00003FFF8000FE01C003F0007007E000380FC000181F80000C3F00000C3F0000067F0000067E0000067E000000FE00 0000FE000000FE000000FE000000FE000000FE000000FE0000007E0000067E0000067F0000063F00000E3F00000E1F80001E 0FC0001E07E0003E03F000FE00FE03DE003FFF0E0007FC02> 32 31 -3 0 37.751] 67 @dc 10 @bop1 (cmbx10.432) @sf 224 307 p (App) s 2 r (endix) s 23 r (A:) s 23 r (Naming) s 23 r (Arc) s -1 r (hitecture) s (cmr10.329) @sf 224 409 p (There) s 18 r (are) s 18 r 116 c 119 c -2 r 111 c 17 r (asp) s 1 r (ects) s 18 r (to) s 18 r (the) s 18 r (naming) s 18 r (arc) s (hitecture:) s 24 r 97 c 18 r (DIT) s 18 r (structure) s 18 r (and) s 18 r 97 c 224 465 p (set) s 15 r (of) s 15 r (related) s 16 r (Sc) s -1 r (hema) s 14 r (de\014nitions.) s (cmbx10.360) @sf 224 587 p (DIT) s 19 r (Structure) s 224 668 p 1843 2 ru 223 724 p 2 56 ru (cmbx10.329) @sf 329 707 p (Lev) s (el) s 554 724 p 2 56 ru 579 707 p (Elemen) s 116 c 792 724 p 2 56 ru 909 707 p (ob) s 3 r (jectClass) s 1285 724 p 2 56 ru 1311 707 p (Sup) s 1 r (erior) s 1531 724 p 2 56 ru 1739 707 p (RDN) s 2066 724 p 2 56 ru 224 726 p 1843 2 ru 223 782 p 2 56 ru (cmr10.329) @sf 447 765 p (ro) s 2 r (ot) s 554 782 p 2 56 ru 670 765 p 48 c 792 782 p 2 56 ru 493 r 2 56 ru 246 r 2 56 ru 535 r 2 56 ru 224 784 p 1843 2 ru 223 840 p 2 56 ru 276 823 p (in) s -1 r (ternational) s 554 840 p 2 56 ru 670 823 p 49 c 792 840 p 2 56 ru 817 823 p (coun) s (try) s 1285 840 p 2 56 ru 1398 823 p 48 c 1531 840 p 2 56 ru 1557 823 p (coun) s (tryName) s 2066 840 p 2 56 ru 224 842 p 1843 2 ru 223 898 p 2 56 ru 368 881 p (national) s 554 898 p 2 56 ru 670 881 p 50 c 792 898 p 2 56 ru 817 881 p (usStateOrEquiv) s -1 r (alen) s -1 r 116 c 1285 898 p 2 56 ru 1398 881 p 49 c 1531 898 p 2 56 ru 1557 881 p (\014psStateNumericCo) s 1 r (de) s 2066 898 p 2 56 ru 223 955 p 2 56 ru 331 r 2 56 ru 670 938 p 51 c 792 955 p 2 56 ru 817 938 p (usOrganization) s 1285 955 p 2 56 ru 1398 938 p 49 c 1531 955 p 2 56 ru 1557 938 p (ansiOrgNumericCo) s 1 r (de) s 2066 955 p 2 56 ru 223 1011 p 2 56 ru 331 r 2 56 ru 670 994 p 52 c 792 1011 p 2 56 ru 817 994 p (nadfADDMD) s 1285 1011 p 2 56 ru 1398 994 p 49 c 1531 1011 p 2 56 ru 1557 994 p (addmdName) s 2066 1011 p 2 56 ru 224 1013 p 1843 2 ru 223 1069 p 2 56 ru 373 1053 p (regional) s 554 1069 p 2 56 ru 670 1053 p 53 c 792 1069 p 2 56 ru 817 1053 p (organization) s 1285 1069 p 2 56 ru 1398 1053 p 50 c 1531 1069 p 2 56 ru 1557 1053 p (organizationName) s 2066 1069 p 2 56 ru 223 1126 p 2 56 ru 331 r 2 56 ru 670 1109 p 54 c 792 1126 p 2 56 ru 817 1109 p (usPlace) s 1285 1126 p 2 56 ru 1398 1109 p 50 c 1531 1126 p 2 56 ru 1557 1109 p (\014psPlaceNumericCo) s 1 r (de) s 2066 1126 p 2 56 ru 224 1128 p 1843 2 ru 223 1184 p 2 56 ru 437 1167 p (lo) s 2 r (cal) s 554 1184 p 2 56 ru 670 1167 p 55 c 792 1184 p 2 56 ru 817 1167 p (organization) s 1285 1184 p 2 56 ru 1398 1167 p 54 c 1531 1184 p 2 56 ru 1557 1167 p (organizationName) s 2066 1184 p 2 56 ru 223 1240 p 2 56 ru 331 r 2 56 ru 662 1224 p 56 c 792 1240 p 2 56 ru 817 1224 p (residen) s (tialP) s -1 r (erson) s 1285 1240 p 2 56 ru 1398 1224 p 54 c 1531 1240 p 2 56 ru 1557 1224 p (commonName,) s 15 r (other) s 2066 1240 p 2 56 ru 224 1242 p 1843 2 ru 223 1299 p 2 56 ru 249 1282 p (organizational) s 554 1299 p 2 56 ru 670 1282 p 57 c 792 1299 p 2 56 ru 817 1282 p (organizationalUnit) s 1285 1299 p 2 56 ru 1345 1282 p (3,5,7,9) s 1531 1299 p 2 56 ru 1557 1282 p (organizationalUnitName) s 2066 1299 p 2 56 ru 223 1355 p 2 56 ru 331 r 2 56 ru 651 1338 p (10) s 792 1355 p 2 56 ru 817 1338 p (organizationalRole) s 1285 1355 p 2 56 ru 1345 1338 p (3,5,7,9) s 1531 1355 p 2 56 ru 1557 1338 p (commonName) s 2066 1355 p 2 56 ru 223 1411 p 2 56 ru 331 r 2 56 ru 651 1395 p (11) s 792 1411 p 2 56 ru 817 1395 p (organizationalP) s (erson) s 1285 1411 p 2 56 ru 1345 1395 p (3,5,7,9) s 1531 1411 p 2 56 ru 1557 1395 p (commonName) s 2066 1411 p 2 56 ru 224 1413 p 1843 2 ru 223 1470 p 2 56 ru 310 1453 p (application) s 554 1470 p 2 56 ru 651 1453 p (12) s 792 1470 p 2 56 ru 817 1453 p (applicationPro) s 2 r (cess) s 1285 1470 p 2 56 ru 1345 1453 p (3,5,7,9) s 1531 1470 p 2 56 ru 1557 1453 p (commonName) s 2066 1470 p 2 56 ru 223 1526 p 2 56 ru 331 r 2 56 ru 651 1509 p (13) s 792 1526 p 2 56 ru 817 1509 p (nadfApplicationEn) s (tit) s -1 r 121 c 1285 1526 p 2 56 ru 1386 1509 p (12) s 1531 1526 p 2 56 ru 1557 1509 p (commonName) s 2066 1526 p 2 56 ru 224 1528 p 1843 2 ru 949 2592 p (10) s @eop 11 @bop0 (cmbx10.360) @sf [<7FF8FFF07FF8FFF00FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC0 1F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F80FFFFFF80FFFFFF800FC0FF800FC000000FC00000 0FC00C000FC01E000FC03F000FC03F000FC03F0007E03F0003F01F0001FC0E00007FFC000007F800> 32 35 -1 0 31.824] 12 @dc [ 300 ] /cmtt9.300 @newfont (cmtt9.300) @sf [ 24 23 -1 0 19.613] 78 @dc [ 24 23 -1 0 19.613] 65 @dc [ 24 23 -1 0 19.613] 68 @dc [<7F80007F80001C00001C00001C00001C00001C00001C00001C00001C38001C38001FF8001FF8001C38001C38001C00001C00 001C03801C03801C03801C03807FFF807FFF80> 24 23 -1 0 19.613] 70 @dc [ 16 3 -2 -10 19.613] 45 @dc [ 16 23 -2 0 19.613] 83 @dc [<03C00FF01C38181C380C700E700E600EE000E000E000E000E000E000E000600E700E700E381E181E1C3E0FFE03C6> 16 23 -2 0 19.613] 67 @dc [ 24 23 -1 0 19.613] 72 @dc [<7FFFC07FFFC01C01C01C01C01C01C01C01C01C00001C00001C00001C38001C38001FF8001FF8001C38001C38001C00001C00 001C03801C03801C03801C03807FFF807FFF80> 24 23 0 0 19.613] 69 @dc [ 24 23 0 0 19.613] 77 @dc [<003E00FE01E003800380038003800380038003800380038003807F00FE007F00038003800380038003800380038003800380 038001E000FE003E> 16 29 -2 3 19.613] 123 @dc [ 24 16 0 0 19.613] 110 @dc [<0F8F803FFF80707C00E01C00E01C00E01C00701C003C1C001FFC0007FC00001C00001C002018007078007FF0001FC000> 24 16 -2 0 19.613] 97 @dc [<07CFC01FEFC0383E00301E00700E00E00E00E00E00E00E00E00E00E00E00E00E00700E00301E001C3E000FFE0007CE00000E 00000E00000E00000E00000E00007E00007E00> 24 23 -1 0 19.613] 100 @dc [<7FFC7FFC038003800380038003800380038003800380038003800380FFFE7FFE038003800380038401CE00FE007C> 16 23 -1 0 19.613] 102 @dc [<07C01FF03C78783C701CE00EE00EE00EE00EE00EE00E701C701C3C781FF007C0> 16 16 -2 0 19.613] 111 @dc [<03E7E00FFFE01C1F001C07001C07001C07001C07001C07001C07001C07001C07001C07001C07001C0700FC3F00FC3F00> 24 16 0 0 19.613] 117 @dc [ 16 23 -2 0 19.613] 108 @dc [<03F00FFC1C1E380E70006000E000FFFEFFFEE00EE00E700C301C1C380FF007E0> 16 16 -2 0 19.613] 101 @dc [ 16 16 -2 0 19.613] 115 @dc [<03F00FFC1C1E380E70006000E000E000E000E0006000700038081C1C0FFC03F8> 16 16 -2 0 19.613] 99 @dc [ 24 23 0 0 19.613] 104 @dc [ 24 16 0 0 19.613] 109 @dc [<00C001C0030006000C001C0038003000700070006000E000E000E000E000E000E000E000600070007000300038001C000C00 0600030001C000C0> 16 29 -6 3 19.613] 40 @dc [<7FF07FF0070007000700070007000700070007000700070007000700070007004700F7003F000F00070003000300> 16 23 -4 0 19.613] 49 @dc [<40006000300018000C000E000700030003800380018001C001C001C001C001C001C001C0018003800380030007000E000C00 1800300060004000> 16 29 -3 3 19.613] 41 @dc [<7800FE000F00038003800380038003800380038003800380038001FC00FE01FC038003800380038003800380038003800380 03800F00FE007800> 16 29 -2 3 19.613] 125 @dc [<7FFC7FFC03800380038003800380038003800380038003800380038003800380038003800380038003807FFC7FFC> 16 23 -2 0 19.613] 73 @dc [<0FF8000FF80001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C0 00E1C380E1C380E1C380E1C380FFFF807FFF80> 24 23 -1 0 19.613] 84 @dc [<1FF07FFC783C701CE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00E701C783C7FFC1FF0> 16 23 -2 0 19.613] 79 @dc [<70F8F8F87000000000000070F8F8F870> 8 16 -7 0 19.613] 58 @dc [ 24 9 -1 -7 19.613] 61 @dc [<7FFC007FFE001C0F001C07001C03801C03801C03801C03801C03801C07001C0F001FFE001FFE001C0F001C07001C03801C03 801C03801C03801C07001C0F007FFE007FF800> 24 23 0 0 19.613] 66 @dc [<03CE000FFE001C3E00181E00381E00700E00700E00600E00E00E00E07F00E07F00E00000E00000E00000E00000600E00700E 00700E00381E00181E001C3E000FFE0003C600> 24 23 -1 0 19.613] 71 @dc [<7F00007F00001C00001C00001C00001C00001C00001C00001C00001C00001FF8001FFE001C0F001C07001C03801C03801C03 801C03801C03801C07001C0F007FFE007FF800> 24 23 0 0 19.613] 80 @dc [ 24 23 -1 0 19.613] 82 @dc [<03E00003E00003E0000770000770000770000630000E38000E38000E38001C1C001C1C001C1C001C1C00FE3F80FE3F80> 24 16 -1 0 19.613] 118 @dc [<7FF8007FF80007000007000007000007000007000007000007000007000007800007800007C0800771C07F3FC07F0F80> 24 16 0 0 19.613] 114 @dc [<3C00007E000077000073800003800001C00001C00001C00001E00001E00001E0000370000370000730000730000738000E38 000E38000E1C001C1C001C1C001C1C00FE3F80FE3F80> 24 24 -1 8 19.613] 121 @dc [<00F003FC070C070E070E070E07000700070007000700070007000700FFFC7FFC07000700070007000300> 16 21 -1 0 19.613] 116 @dc [ 16 24 -3 0 19.613] 105 @dc [<07F0001FFC003C1E00700700E00380E00380E00380E00380700F003FFE001FFC003FF80070000070000037C0003FF0003838 00301800701C00701C00701C00301800383B801FFF8007CF00> 24 25 -1 9 19.613] 103 @dc [<0E78000E78001E7C001A6C001A6C001B6C001B6C0019CC0039CE0039CE00380E00380E00380E00380E00FF7F80FF7F80> 24 16 -1 0 19.613] 119 @dc [ 24 23 -1 0 19.613] 107 @dc [<3F007F80E0C040E00070007000700070007000700070007000700070007000700070007000700070007000701FF01FF00000 000000000000006000F000F00060> 16 32 -2 8 19.613] 106 @dc [<0FC03FF07878601CE01CE00E400E000E000E000C201C78387FF077C070007000700070007000700070007FFC3FFC> 16 23 -2 0 19.613] 53 @dc [<0CF8001DFC001F0E001E03001C03801C01C01C01C01C01C01C01C01C01C01C01C01C03801E03001F07001DFE001CF8001C00 001C00001C00001C00001C0000FC0000FC0000> 24 23 0 0 19.613] 98 @dc [ 24 16 -1 0 19.613] 120 @dc [ 24 24 0 8 19.613] 112 @dc [<07C00FF01C38381C700C700E600EE00EE00EF00CF01CF838EFF0E7C0E000700070003000381C1C1C0E1C07F801F0> 16 23 -2 0 19.613] 54 @dc [<80E070301878F8F8F06000000000000070F8F8F870> 8 21 -7 5 19.613] 59 @dc [<1F007FC0F0E0E070E070007000700070007000700070007000700070007000700070007000700070007007FC07FC> 16 23 -3 0 19.613] 74 @dc [<01FF0001FF00003800003800003800003800003800FFFF80FFFF80E038007038003038003838001C38000C38000E38000638 0003380003380001B80001B80000F800007800> 24 23 -1 0 19.613] 52 @dc [<007FC0007FC0000E00000E00000E00000E00000E00000E0007CE000FEE001C3E00301E00700E00E00E00E00E00E00E00E00E 00E00E00E00E00700E00301E001C3E000FFE0003CE00> 24 24 -1 8 19.613] 113 @dc [<7FFF807FFF801C03801C03801C03801C03801C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00 001C00001C00001C00001C00007F80007F8000> 24 23 -1 0 19.613] 76 @dc [<00F80003FE000707000E03800E03801C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01C01 C01C01C01C01C01C01C01C01C07F07F07F07F0> 24 23 1 0 19.613] 85 @dc [ 8 10 -7 5 19.613] 44 @dc [<7FFE7FFE300E180E0C000600030001C000E0007000300038001C001C000E400EE00EE00EE00E701C38381FF00FC0> 16 23 -2 0 19.613] 50 @dc 11 @bop1 (cmbx10.360) @sf 224 307 p (Sc) s (hema) s 18 r (De\014nitions) s (cmtt9.300) @sf 338 382 p (NADF-SCHEMA) s 19 r 123 c 20 r (--) s 20 r (nadfModule) s 19 r (schema\(1\)) s 20 r (--) s 19 r 125 c 338 474 p (DEFINITIONS) s 19 r (::=) s 20 r (BEGIN) s 338 565 p (IMPORTS) s 416 610 p (--) s 20 r (everything) s 495 656 p (FROM) s 19 r (InformationFramework) s 573 702 p 123 c 20 r (joint-iso-ccitt) s 19 r (ds\(5\)) s 20 r (module\(1\)) s 691 747 p (informationFramework\(1\)) s 19 r 125 c 416 793 p (--) s 20 r (attributes) s 19 r (and) s 20 r (syntaxes) s 495 839 p (FROM) s 19 r (SelectedAttributeTypes) s 573 884 p 123 c 20 r (joint-iso-ccitt) s 19 r (ds\(5\)) s 20 r (module\(1\)) s 691 930 p (selectedAttributeTypes\(5\)) s 19 r 125 c 416 976 p (--) s 20 r (object) s 19 r (classes) s 495 1021 p (FROM) s 19 r (SelectedObjectClasses) s 573 1067 p 123 c 20 r (joint-iso-ccitt) s 19 r (ds\(5\)) s 20 r (module\(1\)) s 691 1113 p (selectedObjectClasses\(6\)) s 19 r 125 c 495 1158 p 59 c 338 1295 p (nadf) s 19 r (OBJECT) s 20 r (IDENTIFIER) s 20 r (::=) s 19 r 123 c 20 r (--) s 19 r (TBD) s 20 r (--) s 20 r 125 c 338 1387 p (nadfModule) s 196 r (OBJECT) s 20 r (IDENTIFIER) s 19 r (::=) s 20 r 123 c 19 r (nadf) s 20 r 49 c 20 r 125 c 338 1432 p (nadfAttributeType) s 59 r (OBJECT) s 19 r (IDENTIFIER) s 20 r (::=) s 19 r 123 c 20 r (nadf) s 20 r 52 c 19 r 125 c 338 1478 p (nadfAttributeSyntax) s 19 r (OBJECT) s 20 r (IDENTIFIER) s 20 r (::=) s 19 r 123 c 20 r (nadf) s 19 r 53 c 20 r 125 c 338 1524 p (nadfObjectClass) s 98 r (OBJECT) s 19 r (IDENTIFIER) s 20 r (::=) s 20 r 123 c 19 r (nadf) s 20 r 54 c 20 r 125 c 338 1661 p (--) s 19 r (object) s 20 r (classes) s 338 1752 p (usStateOrEquivalent) s 19 r (OBJECT-CLASS) s 416 1798 p (SUBCLASS) s 20 r (OF) s 19 r (locality) s 416 1843 p (MUST) s 20 r (CONTAIN) s 19 r 123 c 20 r (fipsStateNumericCode,) s 710 1889 p (fipsStateAlphaCode,) s 710 1935 p (stateOrProviceName) s 20 r 125 c 416 1980 p (::=) s 20 r 123 c 19 r (nadfObjectClass) s 20 r 49 c 20 r 125 c 338 2072 p (usPlace) s 19 r (OBJECT-CLASS) s 416 2117 p (SUBCLASS) s 20 r (OF) s 19 r (locality) s 416 2163 p (MUST) s 20 r (CONTAIN) s 19 r 123 c 20 r (fipsPlaceNumericCode,) s 710 2209 p (localityName) s 20 r 125 c 416 2254 p (::=) s 20 r 123 c 19 r (nadfObjectClass) s 20 r 50 c 20 r 125 c 338 2346 p (usCounty) s 19 r (OBJECT-CLASS) s 416 2391 p (SUBCLASS) s 20 r (OF) s 19 r (usPlace) s 416 2437 p (MUST) s 20 r (CONTAIN) s 19 r 123 c 20 r (fipsCountyNumericCode) s 20 r 125 c (cmr10.329) @sf 949 2592 p (11) s @eop 12 @bop0 (cmtt9.300) @sf [<0FC03FF07838701CE00EE00E400E000E000E001C003807F007E000700038001C001C201C701C701C38381FF00FC0> 16 23 -2 0 19.613] 51 @dc [ 24 16 -1 0 19.613] 122 @dc [<07F00007F00001C00001C00001C00001C00001C00001C00001C00001C00003E00003E0000360000770000770000E38000E38 001E3C001C1C003C1E00380E00FE3F80FE3F80> 24 23 -1 0 19.613] 89 @dc [ 24 23 -1 0 19.613] 88 @dc [ 16 23 -2 0 19.613] 90 @dc [<001E001C003C003800781FF07FFC78FC71DCE1CEE38EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00EE00E701C 783C7FFC1FF0> 16 28 -2 5 19.613] 81 @dc 12 @bop1 (cmtt9.300) @sf 416 307 p (::=) s 20 r 123 c 19 r (nadfObjectClass) s 20 r 51 c 20 r 125 c 338 398 p (usOrganization) s 19 r (OBJECT-CLASS) s 416 444 p (SUBCLASS) s 20 r (OF) s 19 r (organization) s 416 490 p (MUST) s 20 r (CONTAIN) s 19 r 123 c 20 r (ansiOrgNumericCode) s 20 r 125 c 416 535 p (::=) s 20 r 123 c 19 r (nadfObjectClass) s 20 r 52 c 20 r 125 c 338 627 p (nadfApplicationEntity) s 19 r (OBJECT-CLASS) s 416 672 p (SUBCLASS) s 20 r (OF) s 19 r (applicationEntity) s 416 718 p (MUST) s 20 r (CONTAIN) s 19 r 123 c 20 r (supportedApplicationContext) s 20 r 125 c 416 764 p (::=) s 20 r 123 c 19 r (nadfObjectClass) s 20 r 53 c 20 r 125 c 338 855 p (nadfADDMD) s 19 r (OBJECT-CLASS) s 416 901 p (SUBCLASS) s 20 r (OF) s 19 r (top) s 416 946 p (MUST) s 20 r (CONTAIN) s 19 r 123 c 20 r (addmdName) s 20 r 125 c 416 992 p (::=) s 20 r 123 c 19 r (nadfObjectClass) s 20 r 54 c 20 r 125 c 338 1129 p (--) s 19 r (attribute) s 20 r (syntaxes) s 338 1220 p (fipsStateNumericSyntax) s 19 r (ATTRIBUTE-SYNTAX) s 416 1266 p (NumericString) s 20 r (\(SIZE) s 19 r (\(2\)\)) s 79 r (--) s 20 r (leading) s 19 r (zero) s 20 r (is) s 19 r (significant) s 416 1312 p (MATCHES) s 20 r (FOR) s 19 r (EQUALITY) s 20 r (ORDERING) s 416 1357 p (::=) s 20 r 123 c 19 r (nadfAttributeSyntax) s 20 r 49 c 20 r 125 c 338 1449 p (fipsAlphaSyntax) s 19 r (ATTRIBUTE-SYNTAX) s 416 1494 p (PrintableString) s 20 r (\(SIZE) s 19 r (\(2\)\)) s 416 1540 p (MATCHES) s 20 r (FOR) s 19 r (EQUALITY) s 157 r (--) s 20 r (case-insensitive) s 416 1586 p (::=) s 20 r 123 c 19 r (nadfAttributeSyntax) s 20 r 50 c 20 r 125 c 338 1677 p (fipsCountyNumericSyntax) s 19 r (ATTRIBUTE-SYNTAX) s 416 1723 p (NumericString) s 20 r (\(SIZE) s 19 r (\(3\)\)) s 79 r (--) s 20 r (leading) s 19 r (zeros) s 20 r (are) s 19 r (significant) s 416 1768 p (MATCHES) s 20 r (FOR) s 19 r (EQUALITY) s 20 r (ORDERING) s 416 1814 p (::=) s 20 r 123 c 19 r (nadfAttributeSyntax) s 20 r 51 c 20 r 125 c 338 1905 p (fipsPlaceNumericSyntax) s 19 r (ATTRIBUTE-SYNTAX) s 416 1951 p (NumericString) s 20 r (\(SIZE) s 19 r (\(5\)\)) s 79 r (--) s 20 r (leading) s 19 r (zeros) s 20 r (are) s 19 r (significant) s 416 1997 p (MATCHES) s 20 r (FOR) s 19 r (EQUALITY) s 20 r (ORDERING) s 416 2042 p (::=) s 20 r 123 c 19 r (nadfAttributeSyntax) s 20 r 52 c 20 r 125 c 338 2134 p (ansiOrgNumericSyntax) s 19 r (ATTRIBUTE-SYNTAX) s 416 2179 p (INTEGER) s 416 2225 p (MATCHES) s 20 r (FOR) s 19 r (EQUALITY) s 20 r (ORDERING) s 416 2271 p (::=) s 20 r 123 c 19 r (nadfAttributeSyntax) s 20 r 53 c 20 r 125 c 338 2408 p (--) s 19 r (attribute) s 20 r (types) s (cmr10.329) @sf 949 2592 p (12) s @eop 13 @bop0 (cmtt9.300) @sf [<0F1E000F1E000F1E000D16000DB6000DB6001DB7001DB7001DB7001DB7001DB7001DF7001DF70018E3001803003803803803 803803803803803803803803807E0FC07E0FC0> 24 23 0 0 19.613] 87 @dc 13 @bop1 (cmtt9.300) @sf 338 307 p (fipsStateNumericCode) s 19 r (ATTRIBUTE) s 495 353 p (--) s 19 r (values) s 20 r (defined) s 20 r (in) s 19 r (US) s 20 r (FIPS) s 19 r (PUB) s 20 r (5-2) s 416 398 p (WITH) s 20 r (ATTRIBUTE) s 19 r (SYNTAX) s 20 r (fipsStateNumericSyntax) s 416 444 p (::=) s 20 r 123 c 19 r (nadfAttributeType) s 20 r 49 c 20 r 125 c 338 535 p (fipsStateAlphaCode) s 19 r (ATTRIBUTE) s 495 581 p (--) s 19 r (values) s 20 r (defined) s 20 r (in) s 19 r (US) s 20 r (FIPS) s 19 r (PUB) s 20 r (5-2) s 416 627 p (WITH) s 20 r (ATTRIBUTE) s 19 r (SYNTAX) s 20 r (fipsStateAlphaSyntax) s 416 672 p (::=) s 20 r 123 c 19 r (nadfAttributeType) s 20 r 50 c 20 r 125 c 338 764 p (fipsCountyNumericCode) s 19 r (ATTRIBUTE) s 495 809 p (--) s 19 r (values) s 20 r (defined) s 20 r (in) s 19 r (US) s 20 r (FIPS) s 19 r (PUB) s 20 r (6-4) s 416 855 p (WITH) s 20 r (ATTRIBUTE) s 19 r (SYNTAX) s 20 r (fipsCountyNumericSyntax) s 416 901 p (::=) s 20 r 123 c 19 r (nadfAttributeType) s 20 r 51 c 20 r 125 c 338 992 p (fipsPlaceNumericCode) s 19 r (ATTRIBUTE) s 495 1038 p (--) s 19 r (values) s 20 r (defined) s 20 r (in) s 19 r (US) s 20 r (FIPS) s 19 r (PUB) s 20 r (55-2) s 416 1083 p (WITH) s 20 r (ATTRIBUTE) s 19 r (SYNTAX) s 20 r (fipsPlaceNumericSyntax) s 416 1129 p (::=) s 20 r 123 c 19 r (nadfAttributeType) s 20 r 52 c 20 r 125 c 338 1220 p (ansiOrgNumericCode) s 19 r (ATTRIBUTE) s 495 1266 p (--) s 19 r (values) s 20 r (defined) s 20 r (in) s 19 r (ANSI) s 20 r (registry) s 416 1312 p (WITH) s 20 r (ATTRIBUTE) s 19 r (SYNTAX) s 20 r (ansiOrgNumericSyntax) s 416 1357 p (::=) s 20 r 123 c 19 r (nadfAttributeType) s 20 r 53 c 20 r 125 c 338 1449 p (addmdName) s 19 r (ATTRIBUTE) s 495 1494 p (--) s 19 r (values) s 20 r (defined) s 20 r (in) s 19 r (NADF) s 20 r (registry) s 416 1540 p (WITH) s 20 r (ATTRIBUTE) s 19 r (SYNTAX) s 20 r (caseIgnoreStringSyntax) s 416 1586 p (::=) s 20 r 123 c 19 r (nadfAttributeType) s 20 r 54 c 20 r 125 c 338 1677 p (END) s (cmr10.329) @sf 949 2592 p (13) s @eop 14 @bop0 (cmbx10.432) @sf [ 48 41 -3 0 48.898] 66 @dc [ 40 41 -3 0 45.163] 69 @dc (cmtt10.300) @sf [<001F80007F8000FF8001E00001C00001C00001C00001C00001C00001C00001C00001C00001C00003C0007F8000FF0000FF00 007F800003C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001E00000FF80007F80001F80> 24 32 -2 3 21.793] 123 @dc [<063C000EFF000FFF800F83C00F01E00E00E00E00700E00700E00700E00700E00700E00700E00E00F00E00F83C00FFF800EFF 000E3E000E00000E00000E00000E00007E0000FE00007E0000> 24 25 0 0 21.793] 98 @dc [<00E001E0038007000E001C001C0038003800700070007000E000E000E000E000E000E000E000E000E0007000700070003800 38001C001C000E000700038001E000E0> 16 33 -6 4 21.793] 40 @dc [<6000700038001C000E00070007000380038001C001C001C000E000E000E000E000E000E000E000E000E001C001C001C00380 0380070007000E001C00380070006000> 16 33 -4 4 21.793] 41 @dc [<07F0001FFC003FFE007C1F00700700F00780E00380E00380E00380F007807007003C1E001FFC0007F0001FFC007C1F007007 00E00380E00380E00380F007807C1F003FFE001FFC0007F000> 24 25 -2 0 21.793] 56 @dc [<01FFC001FFC001FFC0001C00001C00001C00001C00001C00FFFFE0FFFFE0FFFFE0F01C00781C00381C003C1C001E1C000E1C 000F1C00071C00039C00039C0001DC0000DC0000FC00007C00> 24 25 -1 0 21.793] 52 @dc [<7C0000FF0000FF800003C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001E00000FF00007F80007F 8000FF0001E00001C00001C00001C00001C00001C00001C00001C00001C00001C00003C000FF8000FF00007C0000> 24 32 -2 3 21.793] 125 @dc 14 @bop1 (cmbx10.432) @sf 224 307 p (App) s 2 r (endix) s 23 r (B:) s 23 r (Existing) s 23 r (Authorities) s 23 r (in) s 23 r (the) s 23 r (US) s (cmr10.329) @sf 224 409 p (In) s 16 r (the) s 16 r (US,) s 16 r (the) s 16 r (authors) s 16 r (kno) s 119 c 15 r (of) s 16 r (three) s (cmti10.329) @sf 16 r 98 c -1 r (ona) s 16 r (\014de) s (cmr10.329) @sf 19 r (ISO-OSI) s 16 r (naming) s 16 r (and) s 16 r 110 c (um-) s 224 465 p 98 c 1 r (ering) s 16 r (authorities:) s (cmbx10.329) @sf 315 559 p (ANSI:) s (cmr10.329) @sf 23 r (The) s 21 r (American) s 21 r (National) s 20 r (Standards) s 21 r (Institute) s 21 r (is) s 21 r (authorized) s 21 r (to) s 429 615 p (assign) s 15 r (names) s 15 r (and) s 15 r 110 c (um) s -1 r 98 c (ers) s 15 r (under:) s (cmtt10.300) @sf 529 703 p 123 c 21 r (iso) s 22 r (member-body\(2\)) s 22 r (us\(840\)) s 22 r 125 c (cmr10.329) @sf 429 796 p (With) s 19 r (eac) s 104 c 18 r 110 c (um) s -1 r 98 c (er) s 19 r (assigned,) s 21 r (at) s 19 r (the) s 20 r (user's) s 19 r (request,) s 20 r 97 c 20 r (unique) s 19 r (al-) s 429 853 p (phan) s -1 r (umeric) s 16 r (tag) s 18 r (\(dra) s -1 r (wn) s 16 r (from) s 17 r (the) s 18 r (rep) s 1 r (ertoire) s 17 r (of) s 17 r (T.61) s 17 r (visible) s 17 r 99 c (har-) s 429 909 p (acters\)) s 14 r (ma) s 121 c 14 r (also) s 14 r 98 c 2 r 101 c 14 r (assigned.) s 20 r (\(Although) s 15 r (there) s 14 r (is) s 15 r (no) s 15 r (o\016cial) s 14 r (basis,) s 429 966 p (man) s -1 r 121 c 18 r (organizations) s 18 r (exp) s 2 r (ect) s 18 r (to) s 18 r (use) s 19 r (the) s 18 r (ANSI) s 19 r (registered) s 18 r (alphan) s (u-) s 429 1022 p (meric) s 18 r (tag) s 18 r (for) s 19 r (MHS) s 18 r (ADMD) s 18 r (and) s 18 r (PRMD) s 19 r (naming) s 18 r (purp) s 1 r (oses.) s 30 r (Suc) s 104 c 429 1079 p (use) s 13 r (implies) s 14 r 97 c 14 r (limitation) s 13 r (to) s 14 r (16) s 13 r 99 c (haracters) s 13 r (from) s 13 r (the) s 14 r (Prin) s (tableString) s 429 1135 p (rep) s 1 r (ertoire.\)) s 429 1210 p (Although) s 16 r (ANSI) s 17 r (is) s 16 r (authorized) s 16 r (to) s 17 r (register) s 16 r (names) s 17 r (and) s 16 r (assign) s 17 r 110 c -1 r (um-) s 429 1267 p 98 c 1 r (ers,) s 18 r (and) s 18 r (has) s 18 r (receiv) s (ed) s 17 r (\(according) s 17 r (to) s 18 r (some) s 18 r (hearsa) s (y\)) s 16 r (man) s 121 c 17 r (appli-) s 429 1323 p (cations,) s 23 r (they) s 21 r (ha) s 118 c -2 r 101 c 21 r 121 c (et) s 20 r (to) s 21 r (register) s 22 r 97 c 21 r (single) s 22 r (alphan) s -1 r (umeric) s 21 r (name.) s 429 1380 p (ANSI) s 22 r (has) s 22 r (recen) s (tly) s 21 r (announced) s 22 r (that) s 22 r (they) s 22 r (are) s 22 r (assigning) s 22 r 110 c (umeric) s 429 1436 p (name) s 13 r (forms) s 14 r (in) s 14 r (1Q91,) s 14 r (and) s 13 r (that) s 14 r (they) s 14 r (will) s 14 r (start) s 13 r (to) s 14 r (register) s 14 r (alphan) s -1 r (u-) s 429 1492 p (mericnames) s 16 r 98 c 121 c 15 r (the) s 16 r (end) s 17 r (of) s 16 r (1Q91.) s 24 r (New) s 16 r (applications) s 16 r 109 c (ust) s 15 r 98 c 1 r 101 c 17 r (\014led) s 429 1549 p 98 c -1 r 121 c 17 r (an) s -1 r 121 c 16 r (organizations) s 18 r (that) s 17 r (ha) s -1 r 118 c -1 r 101 c 16 r (already) s 17 r (requested) s 17 r (registration) s 18 r (of) s 429 1605 p (an) s 16 r (alphan) s (umeric) s 15 r (name.) s 24 r (Alphan) s (umeric) s 15 r (name) s 16 r (form) s 17 r (registration) s 16 r (is) s 429 1662 p (on) s 13 r (hold) s 13 r (un) s (til) s 12 r (then,) s 14 r (while) s 13 r (some) s 13 r (di\016culties) s 13 r (with) s 13 r (the) s 13 r (pro) s 2 r (cedures) s 13 r (are) s 429 1718 p (resolv) s -1 r (ed.) s 429 1793 p (It) s 12 r (should) s 12 r 98 c 2 r 101 c 12 r (noted) s 12 r (that) s 13 r (ANSI) s 12 r (in) s (tends,) s 11 r (at) s 13 r (some) s 12 r (unsp) s 1 r (eci\014ed) s 13 r (time) s 12 r (in) s 429 1850 p (the) s 14 r (future,) s 14 r (to) s 14 r (allo) s 119 c 13 r (the) s 14 r (us\(840\)) s 14 r 110 c (umeric) s 13 r (name) s 14 r (form) s 14 r (to) s 14 r 98 c 1 r 101 c 14 r (used) s 14 r (as) s 429 1906 p (comp) s 1 r (onen) s (ts) s 17 r (for) s 18 r (net) s -1 r 119 c -1 r (ork) s 17 r (addresses,) s 19 r (under) s 18 r (the) s 18 r (NSAP) s 18 r (pre\014x) s 18 r (ha) s (v-) s 429 1963 p (ing) s 20 r (AFI) s 21 r (39) s 20 r (and) s 21 r (IDI) s 20 r (840.) s 37 r (The) s 20 r (DSP) s 21 r (for) s 20 r (this) s 21 r (pre\014x) s 20 r (is) s 21 r (curren) s (tly) s 429 2019 p (unde\014ned,) s 20 r (but) s 19 r (there) s 20 r (are) s 19 r (rep) s 1 r (orts) s 19 r (of) s 20 r (progress) s 19 r (on) s 19 r (adoption) s 19 r (of) s 20 r (the) s 429 2076 p (U.S.) s 15 r (GOSIP-lik) s 101 c 14 r (NSAP) s 15 r (format) s 15 r (for) s 15 r (IDI) s 15 r (840.) s (cmbx10.329) @sf 315 2169 p (GSA:) s (cmr10.329) @sf 23 r (The) s 22 r (General) s 21 r (Services) s 22 r (Administration) s 22 r (\(GSA\)) s 22 r (is) s 21 r (authorized) s 22 r (to) s 429 2226 p (assign) s 17 r (net) s 119 c -1 r (ork) s 16 r (addresses) s 17 r (under) s 18 r (the) s 17 r (NSAP) s 18 r (pre\014x) s 17 r (ha) s (ving) s 16 r (AFI) s 18 r (47) s 429 2282 p (IDI) s 15 r (0005) s 15 r (with) s 15 r 110 c (um) s -1 r 98 c (ers) s 15 r (under:) s (cmtt10.300) @sf 529 2370 p 123 c 21 r (iso) s 22 r (identified-organization\(3\)) s 22 r (us-government\(5\)) s 22 r 125 c (cmr10.329) @sf 949 2592 p (14) s @eop 15 @bop0 15 @bop1 (cmr10.329) @sf 429 307 p (for) s 14 r (en) s -1 r (tities) s 13 r (within) s 14 r (the) s 14 r (US) s 14 r (Go) s -1 r 118 c -1 r (ernmen) s -1 r (t.) s 19 r (The) s 14 r (GSA) s 13 r (has) s 14 r (de\014ned) s 14 r (the) s 429 364 p (DSP) s 12 r (for) s 12 r (use) s 12 r (with) s 11 r (these) s 12 r (NSAPs) s 12 r (\(the) s 12 r (US) s 12 r (GOSIP) s 12 r (v2) s 12 r (NSAP) s 12 r (format\).) s 429 439 p (Although) s 12 r (priv) s -1 r (ate) s 11 r (organizations) s 13 r (ma) s 121 c 11 r (apply) s 13 r (to) s 13 r (the) s 12 r (GSA) s 13 r (for) s 13 r (GOSIP) s 429 495 p (net) s -1 r 119 c -1 r (ork) s 13 r (\(NSAP\)) s 15 r 110 c -1 r (um) s -1 r 98 c (ers,) s 15 r (GSA) s 14 r (is) s 14 r 119 c (aiting) s 13 r (for) s 15 r 97 c 14 r 112 c 1 r (olicy) s 15 r (statemen) s -1 r 116 c 429 552 p (from) s 11 r (the) s 12 r (US) s 11 r (GOSIP) s 12 r (User) s 11 r (Group,) s 12 r 98 c 2 r (efore) s 11 r (it) s 12 r (will) s 11 r (honor) s 12 r (applications.) s 429 608 p (It) s 14 r (is) s 15 r (lik) s (ely) s 13 r (that) s 15 r (this) s 15 r (matter) s 14 r (will) s 15 r 98 c 1 r 101 c 15 r (resolv) s (ed) s 14 r (in) s 14 r (the) s 15 r (near-term,) s 15 r (but) s 429 665 p (there) s 15 r (will) s 15 r 98 c 1 r 101 c 15 r (limitations) s 16 r (on) s 15 r (who) s 15 r (ma) s 121 c 14 r (qualify) s -3 r 46 c (cmbx10.329) @sf 315 758 p (IANA:) s (cmr10.329) @sf 23 r (The) s 14 r (In) s (ternet) s 13 r (Assigned) s 14 r (Num) s 98 c (ers) s 14 r (authorit) s 121 c 13 r (is) s 14 r (authorized) s 15 r (to) s 14 r (as-) s 429 815 p (sign) s 15 r (OID) s 15 r 110 c (um) s -2 r 98 c 1 r (ers) s 15 r (under:) s (cmtt10.300) @sf 529 902 p 123 c 21 r (iso) s 22 r (identified-organization\(3\)) s 22 r (us-dod\(6\)) s 703 952 p (internet\(1\)) s 22 r 125 c (cmr10.329) @sf 429 1046 p (In) s 15 r (particular,) s 15 r (organizations) s 15 r (ma) s 121 c 14 r (acquire) s 15 r (their) s 15 r 111 c (wn) s 14 r (OID) s 15 r (under:) s (cmtt10.300) @sf 529 1133 p 123 c 21 r (iso) s 22 r (identified-organization\(3\)) s 22 r (us-dod\(6\)) s 703 1183 p (internet\(1\)) s 22 r (private\(4\)) s 22 r (enterprises\(1\)) s 21 r 125 c (cmr10.329) @sf 429 1276 p (This) s 13 r (arc) s 14 r 119 c (as) s 13 r (created) s 13 r (for) s 14 r (net) s 119 c -2 r (ork) s 13 r (managemen) s 116 c 13 r (use) s 13 r (in) s 14 r (the) s 14 r (In) s -1 r (ternet) s 429 1333 p (to) s 17 r (pro) s (vide) s 16 r (OIDs) s 17 r (for) s 17 r (en) s (terprise) s 16 r (ob) s 3 r (jects.) s 26 r (As) s 18 r (of) s 17 r (this) s 17 r (writing,) s 18 r (some) s 429 1389 p (150) s 15 r (en) s (terprise) s 14 r 110 c -1 r (um) s -1 r 98 c (ers) s 16 r (ha) s -1 r 118 c -1 r 101 c 14 r 98 c 2 r (een) s 15 r (assigned.) s 224 1483 p (It) s 17 r (should) s 18 r 98 c 1 r 101 c 17 r (clear) s 18 r (that) s 17 r (the) s 17 r (scop) s 1 r 101 c 18 r (of) s 17 r (existing) s 17 r 110 c (um) s -1 r 98 c (ering) s 17 r (authorities) s 18 r (fall) s 17 r (far) s 224 1540 p (short) s 15 r (of) s 15 r (the) s 16 r (need,) s 15 r (esp) s 1 r (ecially) s 15 r (for) s 15 r (use) s 15 r 98 c 121 c 14 r (Directory) s 16 r (Services.) s 949 2592 p (15) s @eop @end   Return-Path: Received: from ws10.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <24758-0@bells.cs.ucl.ac.uk>; Fri, 8 Feb 1991 05:29:51 +0000 Received: by ws10.nisc.sri.com (5.64/SRI-NISC1.1) id AA02344; Thu, 7 Feb 91 16:48:00 -0800 Message-Id: <9102080048.AA02344@ws10.nisc.sri.com> To: osi-ds@uk.ac.ucl.cs Cc: meo@com.SRI.NISC, rlang@com.SRI.NISC Subject: Updates for next week's meeting Date: Thu, 07 Feb 91 16:47:50 PST From: Ruth Lang We will be meeting in Conference Room A (not B) in Building A at SRI. All other directions are the same. While attending the meeting, your work associates may leave messages for you by calling Judy Meo at (415) 859-3640. Faxes can be sent to (415) 859-6028. See you next week. Ruth Lang   Return-Path: Received: from trident.arc.nasa.gov by bells.cs.ucl.ac.uk with SMTP inbound id <15364-0@bells.cs.ucl.ac.uk>; Sat, 9 Feb 1991 22:52:25 +0000 Received: by trident.arc.nasa.gov (5.64/1.2); Sat, 9 Feb 91 14:52:32 -0800 Date: Sat, 9 Feb 91 14:52:32 -0800 From: Peter "E." Yee Message-Id: <9102092252.AA08537@trident.arc.nasa.gov> To: osi-ds@uk.ac.ucl.cs Subject: X.500 security paper X-Lines: 334 X-Mailer: Berkeley Mail (5.2 6/85) Last minute comments are welcome. I'll bring paper copies to the meeting on Tuesday. Following this message, there will be a separate message containing a Postscript copy of the paper. -Peter A Scheme for Secure X.500 in the Internet Peter Yee NASA Ames Research Center William Manning Texas Instruments _A_B_S_T_R_A_C_T This paper discusses a rationale for X.500 security requirements in the Internet, proposes a set of such requirements, and offers a scheme that may be used to implement them. _R_a_t_i_o_n_a_l_e With the growth of X.500 pilot projects in the Internet and in other research oriented networks, experience has shown that security is a crucial concept in gaining wider acceptance of X.500 as a viable information service. Until organizations have full control over access to their data, they are neither likely to make that data openly available, nor trust data they extract from the service. Problems with uncontrolled and unauthenticated access to the data stored by a directory service range from the obvious to the subtle. In the case where X.500 is used to provide a white pages service, a fully populated database is a ripe target for abuse on several levels. Most organiza- tions do not desire to give indiscriminate access to contact data for their personnel. Commercial organizations may not wish to release a full list of their corporate personnel for fear that such a list will give a competitor an advantage. On the technical level, control of who has permission to modify and maintain the information contained with the DIT (Directory Information Tree) is also important. Uncon- strained write access to the DIT makes malicious tampering with the stored data simple. It also makes reliance on the service's data a mistake. A compromised DIT could easily facilitate several classes of attacks, including trojan horses, denial of service, and masquerades. For more details on the handling of common security problems, refer Yee & Manning February 9, 1991 Page 1 INTERNET-DRAFTA Scheme for Secure X.500 in the InternetJanuary 1991 to X.509. _S_e_c_u_r_i_t_y _R_e_q_u_i_r_e_m_e_n_t_s In general, security concerns may be classified by the type of threat and its impact upon operations and use of the directory. Threats such as denial of service compromise the usability of the directory, but do not necessarily harms its integrity. Manipulation of the data (either internal to directory storage or during transit between DSAs and other DSAs and DUAs) can potentially destroy its trustworthiness, and ultimately undermines the service. Annex A of CCITT recommendation X.509 contains a more detailed overview of generalized security requirements in the directory. The basic platform upon which many of the security ser- vices needed by the directory are built is user authentica- tion. Authentication is the process in which a user is associated with a unique user identifier. In the case of the directory this would involve associating a user with a Distinguished Name. X.509 specifies two forms of user authentication -- simple and strong. Simple authentication is based upon passwords (either plaintext or protected by a one-way hash function). Strong authentication depends on the cryptographic properties of public key cryptosystems to provide authentication with a higher level of trust. Through the use of user certificates, strong authentication can provide chains of trust between the user and remote DSAs. Although X.509 favors the use of strong authentication, there are problems with its use in the United States which would affect most participants in the Internet pilot. While X.509 does not specify the public key encryption (PKE) algo- rithm to be used, most implementations use the RSA algo- rithm. Use of RSA currently requires licensing by US users -- obtainable from RSA, Inc. Other public key algorithms are also likely to require licensing in the United States, since the base patents for public key cryptography have been obtained by a commercial venture for further licensing.[1] Because of difficulties in handling of the licensing pro- cedures, not to mention the cost, it is suggested that experimental projects, such as the Internet pilot, confine themselves to using simple authentication, at least until such time as the licensing issues can be resolved. At the same time, it is expected that as favorable policy on public _________________________ 9 [1] This problem has manifested itself in other forums. For additional information, consult the minutes of the January, 1990 meeting of ANSI X9E9 or the January and November 1990 meetings of IEEE 802.10. Also see RFC 1170 for a response from Public Key Partners. 9 Yee & Manning February 9, 1991 Page 2 INTERNET-DRAFTA Scheme for Secure X.500 in the InternetJanuary 1991 key cryptography is established, the pilot will move towards strongs authentication as its benefits are desirable. The next step in building a secure directory service requires the definition of a security policy, which is sim- ply "the set of rules laid down by the security authority governing the use and provision of security services and facilities.[2]" These rules are not necessarily between dif- ferent organizations, and in fact, probably vary radically. In addition, different applications of the directory may require different security policies. Thus, a pilot imple- mentation must support a wide range of security policies, with a granularity that meets the real-world needs of the participants. Finally, to complete the basic securing of a directory service, an access control scheme must be defined and used, in conjunction with the authentication ability of the direc- tory, to implement the security policy. Access control allows the owner of a portion of the Directory Information Base (DIB) to manage operations that affect his data. By selecting a set of access controls consistent with the secu- rity policy, the operator may provide protection at various conceptual levels of the data. Granularity may be at quite a fine level, i.e. a specific user is allowed to modify a specific attribute in a specific entry. Or it may be at coarse level, i.e. all users are allowed to list the chil- dren of a particular node that is the root the organization's subtree. _A_n _A_c_c_e_s_s _C_o_n_t_r_o_l _S_c_h_e_m_e The concept of access control lists (ACLs, pronounced "ackle") is introduced. An ACL defines the actions that a user may take in interacting with the directory. ACLs may be defined to manage varying levels of granularity. In our scheme a node in the DIT has four possible types of ACLs.[3] These ACLs are defined for the protection of the node itself (entry), for its children (child), for the sub- tree rooted at the node (subtree), and for its attributes (attribute). The possible actions that may be specified by the ACLs are "none", "detect", "compare", "read", "add", "delete", and "modify".[4] For each of these actions, a _________________________ 9 [2] X.509 (88), unofficial copy, Section 3.3. 9 [3] This section is based upon X.509, as well as, Proposed Draft Addendum Documents (PDADs) to ISO 9594/Part 2, 3, and 4. 9 [4] Proposed extensions to Part 2, Annex F (Access Control) define the additional access permissions "manage," and "administer". These permissions are used to control access to the access control information it- 9Yee & Manning February 9, 1991 Page 3 INTERNET-DRAFTA Scheme for Secure X.500 in the InternetJanuary 1991 distinguished name is given, which specifies to whom the ACL applies. The pseudo-DNs "self" and "other" have the mean- ings of "the name of the DN for which we are doing ACL pro- cessing", and "all other DNs". The DNs are sorted, within ACL type, from most to least distinguished DN. DNs are then checked for matches, with the first match being the one applied. In addition, any ACLs that protect entry attri- butes specify which attributes are protected. Several modifications to this basic scheme come to mind. For a non-leaf node, the DN may be treated as a pre- fix and any DN being checked against the prefix DN is com- pared only up to the length of the prefix. Groups of DNs may be used to manage the maintenance of multiple individual DNs that share a common ACL. Groups may be defined recursively, i.e. there may be groups of groups, groups of DNs, or a combination of groups and DNs. Use of groups brings up the problems of performance and correct- ness. In terms of performance, any expansion of a group is bound to be slow. It may involve requesting information from other DSAs. It may also introduce the possibility of an ACL lookup loop. Correctness of the result may also be important, but must be weighed against performance. Groups may be handled in two ways: 1. The list of DNs are first checked, and if no match is found, the group is expanded and then checked for a match; 2. The group is first expanded, and the result is merged in with the other DNs. This has the potential to be substantially slower, although this pro- cedure could be done en masse at startup and the results cached.[5] However, the first alternative has the potential to produce an incorrect application of access control. For example, an DN may be found in the list of DNs that denies access to the entry. Because a match was found, no search- ing of the group need by done. It is possible, though, that the group contains a more distinguished name which when matched with the DN being checked would produce a different access control response. A novel idea, although one that is probably not suit- able in a pure OSI pilot, would be to use NSAPs as an addi- tional basis for access control. Based on an NSAP com- parison (or possibly a substring of a text encoded NSAP) it is also possible to control access with a large, non-user based, granularity. 9_________________________ self. However, by treating the ACLs as attributes themselves, they may be handled by the attribute ACL like any other attribute. This is discussed later. 9 [5] Handling cache consistency and policy is a whole other bag of worms. It is also not discussed in this document. Yee & Manning February 9, 1991 Page 4 INTERNET-DRAFTA Scheme for Secure X.500 in the InternetJanuary 1991 Finally it should be noted that where possible and where applicable, the pilot project will attempt to track emerging CCITT/ISO standards on directory security, incor- porating them as appropriate. Yee & Manning February 9, 1991 Page 5   Return-Path: Received: from trident.arc.nasa.gov by bells.cs.ucl.ac.uk with SMTP inbound id <15381-0@bells.cs.ucl.ac.uk>; Sat, 9 Feb 1991 22:53:10 +0000 Received: by trident.arc.nasa.gov (5.64/1.2); Sat, 9 Feb 91 14:53:13 -0800 Date: Sat, 9 Feb 91 14:53:13 -0800 From: Peter "E." Yee Message-Id: <9102092253.AA08546@trident.arc.nasa.gov> To: osi-ds@uk.ac.ucl.cs Subject: Postscript version of the X.500 security paper X-Lines: 2079 X-Mailer: Berkeley Mail (5.2 6/85) %!PS-Adobe-1.0 %%Creator: trident.arc.nasa.gov:yee (Peter E. &,233/240,3812,9673487,233-18) %%Title: stdin %%CreationDate: Sat Feb 9 14:49:55 1991 %%DocumentFonts: Times-Roman Times-Italic Times-Bold Symbol Times-Roman %%Pages: (atend) %%EndComments % lib/pscat.pro -- prolog for pscat (troff) files % Copyright (C) 1985 Adobe Systems, Inc. save /pscatsave exch def /$pscat 50 dict def $pscat begin /fm [1 0 0 1 0 0] def /xo 0 def /yo 0 def /M /moveto load def /R /show load def /S {exch currentpoint exch pop moveto show}def /T {exch currentpoint pop exch moveto show}def /U {3 1 roll moveto show}def /siz 0 def /font 0 def /Z {/siz exch def SF}def /F {/font exch def SF}def /SF{font 0 ne {catfonts font 1 sub get fm 0 siz put fm 3 siz neg put fm makefont setfont}if}def /BP{save/catsv exch def 0 792 translate 72 432 div dup neg scale xo yo translate 0 0 moveto}def /EP{catsv restore showpage}def % definitions for PPROC callback functions % each PPROC is called with the following number on the stack: % pointsize charcode railmag pswidth pschar x y wid /$pprocs 50 dict def /fractm [.65 0 0 .6 0 0] def % fractions /PS1{gsave $pprocs begin /wid exch def pop pop pop pop pop /ch exch def /size exch def /pair $pprocs ch get def /cf currentfont def cf fractm makefont setfont 0 .3 size mul 6 mul 2 copy neg rmoveto pair 0 get show rmoveto currentfont cf setfont (\244) show setfont pair 1 get show grestore wid .06 div 0 rmoveto end}def $pprocs begin 8#34 [(1)(4)] def 8#36 [(1)(2)] def 8#46 [(3)(4)] def end % boxes /PS2{gsave /wid exch def pop pop /char exch def pop pop pop /size exch def /len size 3.5 mul def % length of a side len 0 rlineto 0 len neg rlineto len neg 0 rlineto closepath char 3 eq {fill}{size 5 mul .07 mul setlinewidth stroke}ifelse grestore wid .06 div 0 rmoveto}def /PS3/PS2 load def % boxes are the same... % circle /PS4{gsave /wid exch def pop pop pop pop pop pop /size exch def wid .8333 mul size 2.5 mul neg rmoveto currentpoint % center newpath size 1.8 mul 0 360 arc size .2 mul setlinewidth stroke grestore wid .06 div 0 rmoveto}def /bb{$pprocs begin /wid exch def pop pop pop pop pop pop /size exch 6 mul def /s2 size 2 div def /s4 size 4 div def gsave currentpoint newpath transform round exch round exch itransform translate size 16 div setlinewidth 2 setlinejoin 0 setgray}def $pprocs begin /mrr{moveto rlineto rlineto}def /be{stroke grestore wid .06 div 0 rmoveto end}def end % leftfloor /PS6 {bb s4 0 0 size s4 size -.8 mul mrr be}def % rightfloor /PS7 {bb s4 neg 0 0 size s4 size -.8 mul mrr be}def % leftceil /PS8 {bb s4 0 0 size neg s4 size .2 mul mrr be}def % rightceil /PS9 {bb s4 neg 0 0 size neg s4 size .2 mul mrr be}def % boldvert /PS5 {bb 0 0 0 size neg s4 size .2 mul mrr be}def % box rule /PS32 {bb /sw size 24 div def sw 2 div size 4.5 div moveto 0 size neg rlineto sw setlinewidth be}def % rule (roman, bold and italic) /PS16 {gsave $pprocs begin /wid exch def pop pop pop pop pop pop /size exch 6 mul def /sw size 14 div def currentpoint exch sw 2 div sub exch newpath transform round exch round exch itransform translate 0 0 moveto size 2 div 0 rlineto sw setlinewidth be}def % lefttopcurl /PS20 {bb s4 size .2 mul moveto 0 size -.55 mul rlineto currentpoint pop size -.8 mul 2 copy exch s4 add exch s4 arcto pop pop pop pop be}def % leftbotcurl /PS21 {bb s4 size -.8 mul moveto 0 size .55 mul rlineto currentpoint pop size .2 mul 2 copy exch s4 add exch s4 arcto pop pop pop pop be}def % righttopcurl /PS22 {bb s4 size .2 mul moveto 0 size -.55 mul rlineto currentpoint pop size -.8 mul 2 copy exch s4 sub exch s4 arcto pop pop pop pop be}def % rightbotcurl /PS23 {bb s4 size -.8 mul moveto 0 size .55 mul rlineto currentpoint pop size .2 mul 2 copy exch s4 sub exch s4 arcto pop pop pop pop be}def % rightmidcurl /PS25 {bb /s3 size -.3 mul def s4 size -.8 mul moveto s4 s3 s2 s3 s4 arcto pop pop size add s4 s3 4 2 roll s4 arcto pop pop pop pop s4 size .2 mul lineto be}def % leftmidcurl /PS24 {bb /s3 size -.3 mul def s4 size -.8 mul moveto s4 s3 0 s3 s4 arcto pop pop size add s4 s3 4 2 roll s4 arcto pop pop pop pop s4 size .2 mul lineto be}def /catfonts [ /Times-Roman findfont /Times-Italic findfont /Times-Bold findfont /Symbol findfont /Times-Roman findfont ] def %%EndProlog %%Page: ? 1 BP 3 F 72 Z 1057 831(A)U 1133(Scheme)S 1393(for)S 1509(Secure)S 1741(X.500)S 1943(in)S 2027(the)S 2147(Internet)S 1 F 60 Z 1356 1083(N)U 2 F 1609 975(Peter)U 1760(Yee)S 1 F 1399 1083(ASA)U 1538(Ames)S 1698(Research)S 1939(Center)S 1504 1335(T)U 2 F 1514 1227(William)U 1725(Manning)S 1 F 1541 1335(exas)U 1668(Instruments)S 798 1695(T)U 2 F 1586 1551(ABSTRACT)U 1 F 835 1695(his)U 929(paper)S 1087(discusses)S 1334(a)S 1385(rationale)S 1621(for)S 1715(X.500)S 1886(security)S 2100(requirement)S 2392(s)S 2438(in)S 2508(the)S 2605(Internet,)S 648 1839(m)U 648 1767(proposes)U 886(a)S 937(set)S 1028(of)S 1102(such)S 1236(requirement)S 1528(s,)S 1590(and)S 1701(offers)S 1865(a)S 1916(scheme)S 2121(that)S 2236(may)S 2364(be)S 2445(used)S 2579(to)S 2650(imple-)S 695 1839(ent)U 789(them.)S 3 F 432 2055(Rationale)U 1 F 582 2148(With)U 729(the)S 828(growth)S 1023(of)S 1098(X.500)S 1271(pilot)S 1407(projects)S 1623(in)S 1695(the)S 1794(Internet)S 2007(and)S 2119(in)S 2191(other)S 2340(research)S 2566(oriented)S 2789(networks,)S 432 2292(v)U 432 2220(experienc)U 667(e)S 725(has)S 836(shown)S 1023(that)S 1145(security)S 1367(is)S 1438(a)S 1495(crucial)S 1690(concept)S 1908(in)S 1985(gaining)S 2196(wider)S 2363(accept)S 2518(ance)S 2659(of)S 2739(X.500)S 2917(as)S 2997(a)S 462 2292(iable)U 602(information)S 909(service.)S 1137(Until)S 1283(organizati)S 1525(ons)S 1630(have)S 1766(full)S 1872(control)S 2065(over)S 2194(access)S 2370(to)S 2439(their)S 2572(data,)S 2710(they)S 2835(are)S 2930(nei-)S 432 2364(ther)U 546(likely)S 704(to)S 771(make)S 922(that)S 1033(data)S 1154(openly)S 1338(availabl)S 1530(e,)S 1592(nor)S 1692(trust)S 1819(data)S 1940(they)S 2064(extract)S 2249(from)S 2386(the)S 2480(service.)S 582 2457(Problems)U 835(with)S 968(uncontrolled)S 1299(and)S 1412(unauthentic)S 1694(ated)S 1821(access)S 2001(to)S 2074(the)S 2174(data)S 2301(stored)S 2473(by)S 2558(a)S 2610(directory)S 2853(service)S 3009 2529(,)U 432 2601(a)U 432 2529(range)U 587(from)S 725(the)S 820(obvious)S 1031(to)S 1099(the)S 1194(subtle.)S 1394(In)S 1465(the)S 1560(case)S 1684(where)S 1851(X.500)S 2019(is)S 2079(used)S 2209(to)S 2276(provide)S 2480(a)S 2527(white)S 2681(pages)S 2838(service)S 481 2601(fully)U 617(populated)S 877(database)S 1107(is)S 1169(a)S 1218(ripe)S 1333(target)S 1492(for)S 1583(abuse)S 1741(on)S 1822(several)S 2014(levels.)S 2211(Most)S 2355(organizati)S 2597(ons)S 2701(do)S 2782(not)S 2880(desire)S 3007 2673(t)U 432 2745(w)U 432 2673(to)U 507(give)S 639(indiscrimina)S 941(te)S 1013(access)S 1195(to)S 1270(contact)S 1473(data)S 1602(for)S 1700(their)S 1839(personnel.)S 2136(Commercia)S 2418(l)S 2463(organizati)S 2705(ons)S 2816(may)S 2947(no)S 475 2745(ish)U 568(to)S 638(release)S 829(a)S 879(full)S 986(list)S 1083(of)S 1155(their)S 1288(corporate)S 1538(personnel)S 1794(for)S 1886(fear)S 2002(that)S 2115(such)S 2247(a)S 2296(list)S 2392(will)S 2508(give)S 2634(a)S 2683(competit)S 2895(or)S 2967(an)S 432 2817(advantage)U 677(.)S 582 2910(On)U 684(the)S 787(technica)S 989(l)S 1035(level,)S 1197(control)S 1396(of)S 1474(who)S 1605(has)S 1713(permission)S 2005(to)S 2080(modify)S 2282(and)S 2397(maintai)S 2579(n)S 2637(the)S 2739(information)S 2994 2982(o)U 432 3054(t)U 432 2982(contained)U 692(with)S 824(the)S 923(DIT)S 1048(\(Directory)S 1324(Information)S 1637(Tree\))S 1793(is)S 1858(also)S 1980(important.)S 2275(Unconstrained)S 2651(write)S 2799(access)S 2977(t)S 449 3054(he)U 527(DIT)S 648(makes)S 823(malici)S 975(ous)S 1079(tampering)S 1345(with)S 1473(the)S 1568(stored)S 1736(data)S 1858(simple.)S 2075(It)S 2133(also)S 2250(makes)S 2424(reliance)S 2636(on)S 2716(the)S 2810(service's)S 432 3198(h)U 432 3126(data)U 558(a)S 610(mistake.)S 858(A)S 926(compromised)S 1279(DIT)S 1404(could)S 1562(easily)S 1727(facilit)S 1869(ate)S 1964(several)S 2159(classes)S 2350(of)S 2424(attacks,)S 2631(including)S 2883(trojan)S 462 3198(orses,)U 621(denial)S 790(of)S 861(service,)S 1068(and)S 1176(masquerades.)S 1543(For)S 1647(more)S 1792(details)S 1971(on)S 2052(the)S 2147(handling)S 2379(of)S 2450(common)S 2682(security)S 2894(prob-)S 3 F 432 3414(S)U 1 F 432 3270(lems,)U 581(refer)S 715(to)S 782(X.509.)S 3 F 465 3414(ecurity)U 666(Requirements)S 1 F 582 3507(I)U (n)R 657(general,)S 875(security)S 1091(concerns)S 1330(may)S 1459(be)S 1541(classi\256ed)S 1790(by)S 1875(the)S 1974(type)S 2103(of)S 2178(threat)S 2341(and)S 2453(its)S 2535(impact)S 2725(upon)S 2870(opera-)S 3004 3579(-)U 432 3651(t)U 432 3579(tions)U 572(and)S 682(use)S 784(of)S 856(the)S 952(directory.)S 1227(Threats)S 1430(such)S 1562(as)S 1634(denial)S 1804(of)S 1876(service)S 2069(compromise)S 2389(the)S 2485(usability)S 2715(of)S 2787(the)S 2883(direc)S 449 3651(ory,)U 571(but)S 675(do)S 762(not)S 866(necessarily)S 1161(harms)S 1335(its)S 1418(integrity.)S 1684(Manipulation)S 2035(of)S 2111(the)S 2211(data)S 2338(\(either)S 2522(internal)S 2733(to)S 2806(directory)S 3001 3723(s)U 432 3795(t)U 432 3723(storage)U 644(or)S 732(during)S 927(transit)S 1116(between)S 1355(DSAs)S 1535(and)S 1660(other)S 1822(DSAs)S 2002(and)S 2127(DUAs\))S 2336(can)S 2457(potential)S 2669(ly)S 2753(destroy)S 2967(it)S 449 3795(rustworthiness,)U 845(and)S 963(ultimat)S 1135(ely)S 1240(undermines)S 1552(the)S 1657(service.)S 1893(Annex)S 2083(A)S 2156(of)S 2236(CCITT)S 2440(recommenda)S 2752(tion)S 2876(X.509)S 432 3867(contains)U 653(a)S 700(more)S 844(detaile)S 1006(d)S 1056(overview)S 1300(of)S 1370(generaliz)S 1592(ed)S 1669(security)S 1880(requirement)S 2172(s)S 2215(in)S 2282(the)S 2376(directory.)S 582 3960(The)U 699(basic)S 846(platform)S 1077(upon)S 1220(which)S 1390(many)S 1547(of)S 1619(the)S 1715(security)S 1928(services)S 2144(needed)S 2337(by)S 2419(the)S 2515(directory)S 2755(are)S 2851(built)S 2984(is)S 3004 4032(r)U 432 4104(i)U 432 4032(user)U 563(authentic)S 785(ation.)S 972(Authenticat)S 1254(ion)S 1362(is)S 1433(the)S 1537(process)S 1747(in)S 1824(which)S 2001(a)S 2058(user)S 2188(is)S 2258(associated)S 2536(with)S 2673(a)S 2730(unique)S 2924(use)S 449 4104(denti\256er.)U 706(In)S 777(the)S 872(case)S 997(of)S 1068(the)S 1163(directory)S 1402(this)S 1510(would)S 1681(involve)S 1882(associating)S 2170(a)S 2217(user)S 2337(with)S 2464(a)S 2511(Distinguished)S 2865(Name.)S 432 4248(u)U 432 4176(X.509)U 604(speci\256es)S 835(two)S 949(forms)S 1113(of)S 1187(user)S 1311(authentic)S 1533(ation)S 1678(\320)S 1762(simple)S 1946(and)S 2056(strong.)S 2264(Simple)S 2458(authentic)S 2680(ation)S 2824(is)S 2887(based)S 462 4248(pon)U 587(passwords)S 871(\(either)S 1064(plaintext)S 1311(or)S 1396(protected)S 1656(by)S 1751(a)S 1812(one-way)S 2053(hash)S 2197(function\).)S 2487(Strong)S 2681(authentic)S 2903(ation)S 2997 4320(a)U 432 4392(h)U 432 4320(depends)U 656(on)S 743(the)S 844(cryptographic)S 1206(properties)S 1474(of)S 1551(public)S 1729(key)S 1842(cryptosystems)S 2212(to)S 2285(provide)S 2495(authentic)S 2717(ation)S 2864(with)S 462 4392(igher)U 611(level)S 754(of)S 829(trust.)S 996(Through)S 1228(the)S 1327(use)S 1432(of)S 1507(user)S 1632(certi\256cat)S 1844(es,)S 1934(strong)S 2109(authentic)S 2331(ation)S 2477(can)S 2586(provide)S 2795(chains)S 2974(of)S 432 4629(Y)U 432 4464(trust)U 559(between)S 780(the)S 874(user)S 994(and)S 1101(remote)S 1289(DSAs.)S 475 4629(ee)U 549(&)S 616(Manning)S 2857(Page)S 2994(1)S EP %%Page: ? 2 BP 1 F 60 Z 2994 381(1)U 432(INTERNET-DRAFT)S 1195(A)S 1258(Scheme)S 1469(for)S 1559(Secure)S 1743(X.500)S 1911(in)S 1978(the)S 2072(Internet)S 2697(January)S 2904(199)S 582 597(Although)U 838(X.509)S 1014(favors)S 1192(the)S 1294(use)S 1402(of)S 1480(strong)S 1658(authentic)S 1880(ation,)S 2044(there)S 2193(are)S 2295(problems)S 2547(with)S 2682(its)S 2767(use)S 2875(in)S 2950(the)S 432 741(t)U 432 669(United)U 619(States)S 786(which)S 956(would)S 1129(affect)S 1290(most)S 1430(participa)S 1642(nts)S 1735(in)S 1805(the)S 1901(Internet)S 2111(pilot.)S 2279(While)S 2449(X.509)S 2619(does)S 2751(not)S 2850(specify)S 449 741(he)U 533(public)S 710(key)S 823(encryption)S 1107(\(PKE\))S 1286(algorithm)S 1547(to)S 1620(be)S 1703(used,)S 1854(most)S 1997(impleme)S 2209(ntations)S 2426(use)S 2532(the)S 2632(RSA)S 2774(algorithm.)S 432 885(a)U 432 813(Use)U 550(of)S 625(RSA)S 766(currently)S 1009(requires)S 1228(licensing)S 1471(by)S 1556(US)S 1657(users)S 1805(\320)S 1890(obtainable)S 2167(from)S 2309(RSA,)S 2465(Inc.)S 2601(Other)S 2762(public)S 2937(key)S 459 885(lgorithms)U 712(are)S 808(also)S 927(likely)S 1087(to)S 1155(require)S 1347(licensing)S 1586(in)S 1654(the)S 1749(United)S 1934(States,)S 2114(since)S 2259(the)S 2354(base)S 2482(patents)S 2674(for)S 2765(public)S 2937(key)S 3001 957(s)U 432(cryptography)S 775(have)S 911(been)S 1047(obtained)S 1277(by)S 1359(a)S 1408(commerci)S 1650(al)S 1716(venture)S 1919(for)S 2010(further)S 2195(licensing.)S 2473(Because)S 2695(of)S 2766(dif\256cultie)S 48 Z 2428 939(1)U 60 Z 3004 1029(-)U 432 1101(j)U 432 1029(in)U 504(handling)S 740(of)S 815(the)S 913(licensing)S 1155(procedures,)S 1458(not)S 1559(to)S 1630(mention)S 1852(the)S 1950(cost,)S 2086(it)S 2144(is)S 2208(suggested)S 2469(that)S 2584(experiment)S 2856(al)S 2924(pro)S 449 1101(ects,)U 585(such)S 722(as)S 799(the)S 900(Internet)S 1115(pilot,)S 1268(con\256ne)S 1472(themselves)S 1767(to)S 1841(using)S 1998(simple)S 2186(authentic)S 2408(ation,)S 2570(at)S 2640(least)S 2777(until)S 2914(such)S 2994 1173(y)U 432 1245(o)U 432 1173(time)U 564(as)S 638(the)S 736(licensing)S 978(issues)S 1145(can)S 1253(be)S 1334(resolved.)S 1597(At)S 1681(the)S 1779(same)S 1927(time,)S 2074(it)S 2132(is)S 2196(expecte)S 2381(d)S 2435(that)S 2549(as)S 2622(favorable)S 2873(polic)S 462 1245(n)U 523(public)S 705(key)S 823(cryptography)S 1175(is)S 1245(established,)S 1558(the)S 1662(pilot)S 1803(will)S 1927(move)S 2091(towards)S 2311(strongs)S 2514(authentic)S 2736(ation)S 2887(as)S 2967(its)S 432 1317(bene\256ts)U 639(are)S 733(desirable.)S 582 1410(The)U 703(next)S 834(step)S 958(in)S 1032(building)S 1260(a)S 1314(secure)S 1494(directory)S 1738(service)S 1935(requires)S 2155(the)S 2255(de\256nition)S 2512(of)S 2588(a)S 2641(security)S 2858(policy,)S 432 1554(s)U 432 1482(which)U 600(is)S 661(simply)S 846(``the)S 981(set)S 1068(of)S 1138(rules)S 1275(laid)S 1386(down)S 1539(by)S 1619(the)S 1713(security)S 1924(authority)S 2162(governing)S 2426(the)S 2520(use)S 2620(and)S 2727(provision)S 2974(of)S 455 1554(ecurity)U 644(services)S 859(and)S 967(facilit)S 1109(ies.)S 1215('')S 1276(These)S 1441(rules)S 1579(are)S 1674(not)S 1772(necessarily)S 2061(between)S 2282(different)S 2510(organizati)S 2752(ons,)S 2870(and)S 2977(in)S 432 1626(f)U 48 Z 1191 1536(2)U 60 Z 452 1626(act,)U 564(probably)S 804(vary)S 937(radicall)S 1119(y.)S 1210(In)S 1286(addition,)S 1524(different)S 1757(applicat)S 1949(ions)S 2074(of)S 2149(the)S 2248(directory)S 2491(may)S 2620(require)S 2816(different)S 432 1770(g)U 432 1698(security)U 648(policies.)S 896(Thus,)S 1056(a)S 1108(pilot)S 1244(impleme)S 1456(ntation)S 1649(must)S 1791(support)S 1996(a)S 2048(wide)S 2190(range)S 2349(of)S 2424(security)S 2639(policies,)S 2866(with)S 2997(a)S 462 1770(ranularity)U 717(that)S 828(meets)S 989(the)S 1083(real-world)S 1354(needs)S 1511(of)S 1581(the)S 1675(participa)S 1887(nts.)S 2997 1863(e)U 432 1935(d)U 582 1863(Finally,)U 793(to)S 865(complete)S 1112(the)S 1211(basic)S 1360(securing)S 1589(of)S 1664(a)S 1715(directory)S 1957(service,)S 2167(an)S 2248(access)S 2426(control)S 2621(scheme)S 2826(must)S 2967(b)S 462 1935(e\256ned)U 631(and)S 740(used,)S 887(in)S 956(conjunction)S 1263(with)S 1392(the)S 1488(authentic)S 1710(ation)S 1853(ability)S 2030(of)S 2102(the)S 2198(directory,)S 2453(to)S 2522(impleme)S 2734(nt)S 2802(the)S 2897(secu-)S 432 2079(m)U 432 2007(rity)U 541(policy.)S 752(Access)S 947(control)S 1143(allows)S 1325(the)S 1424(owner)S 1599(of)S 1674(a)S 1726(portion)S 1925(of)S 2000(the)S 2099(Directory)S 2355(Information)S 2668(Base)S 2810(\(DIB\))S 2977(to)S 479 2079(anage)U 641(operations)S 913(that)S 1025(affect)S 1184(his)S 1275(data.)S 1432(By)S 1523(selecting)S 1759(a)S 1806(set)S 1893(of)S 1963(access)S 2137(controls)S 2351(consistent)S 2612(with)S 2739(the)S 2833(security)S 2994 2151(y)U 432 2223(b)U 432 2151(policy,)U 624(the)S 724(operator)S 950(may)S 1079(provide)S 1288(protection)S 1558(at)S 1627(various)S 1829(conceptua)S 2074(l)S 2116(levels)S 2282(of)S 2357(the)S 2456(data.)S 2617(Granularity)S 2920(ma)S 462 2223(e)U 513(at)S 581(quite)S 726(a)S 777(\256ne)S 891(level,)S 1048(i.e.)S 1146(a)S 1197(speci\256c)S 1405(user)S 1529(is)S 1593(allowed)S 1808(to)S 1879(modify)S 2076(a)S 2126(speci\256c)S 2333(attribute)S 2558(in)S 2628(a)S 2678(speci\256c)S 2885(entry.)S 432 2367(r)U 432 2295(Or)U 516(it)S 571(may)S 696(be)S 774(at)S 839(coarse)S 1014(level,)S 1168(i.e.)S 1263(all)S 1345(users)S 1489(are)S 1584(allowed)S 1796(to)S 1864(list)S 1959(the)S 2054(children)S 2273(of)S 2343(a)S 2390(particula)S 2602(r)S 2642(node)S 2779(that)S 2890(is)S 2950(the)S 452 2367(oot)U 549(the)S 643(organizati)S 885(on's)S 1008(subtree.)S 3 F 432 2511(An)U 528(Access)S 718(Control)S 938(Scheme)S 1 F 582 2604(The)U 700(concept)S 912(of)S 986(access)S 1163(control)S 1357(lists)S 1477(\(ACLs,)S 1678(pronounced)S 1985(``ackle''\))S 2236(is)S 2299(introduced.)S 2615(An)S 2711(ACL)S 2854(de\256nes)S 432 2748(v)U 432 2676(the)U 534(actions)S 733(that)S 852(a)S 907(user)S 1035(may)S 1167(take)S 1296(in)S 1371(interact)S 1553(ing)S 1658(with)S 1792(the)S 1893(directory.)S 2173(ACLs)S 2343(may)S 2474(be)S 2558(de\256ned)S 2762(to)S 2836(manage)S 462 2748(arying)U 636(levels)S 797(of)S 867(granularity.)S 582 2841(I)U (n)R 656(our)S 760(scheme)S 965(a)S 1016(node)S 1157(in)S 1228(the)S 1326(DIT)S 1450(has)S 1553(four)S 1676(possible)S 1896(types)S 2046(of)S 2119(ACLs.)S 2324(These)S 2491(ACLs)S 2657(are)S 2754(de\256ned)S 2954(for)S 48 Z 2277 2823(3)U 60 Z 3004 2913(-)U 432 2985(t)U 432 2913(the)U 529(protection)S 797(of)S 870(the)S 967(node)S 1107(itself)S 1250(\(entry\),)S 1451(for)S 1543(its)S 1622(children)S 1842(\(child\),)S 2040(for)S 2132(the)S 2228(subtree)S 2424(rooted)S 2600(at)S 2666(the)S 2762(node)S 2901(\(sub)S 449 2985(ree\),)U 588(and)S 705(for)S 805(its)S 892(attribute)S 1094(s)S 1147(\(attribute)S 1369(\).)S 1454(The)S 1578(possible)S 1804(actions)S 2004(that)S 2124(may)S 2257(be)S 2343(speci\256ed)S 2586(by)S 2675(the)S 2778(ACLs)S 2950(are)S 3004 3057(-)U 5 F 432(")S 1 F (none)R 5 F (")R 1 F (,)R 5 F 641(")S 1 F (detec)R 794(t)S 5 F (")R 1 F (,)R 5 F 878(")S 1 F (compare)R 5 F 1111(")S 1 F (,)R 5 F 1178(")S 1 F (read)R 5 F (")R 1 F (,)R 5 F 1374(")S 1 F (add)R 5 F (")R 1 F (,)R 5 F 1553(")S 1 F (delet)R 1696(e)S 5 F (")R 1 F (,)R 1790(and)S 5 F 1904(")S 1 F (modify)R 5 F (")R 1 F (.)R 2194(For)S 2304(each)S 2442(of)S 2519(these)S 2669(actions,)S 2881(a)S 2934(dis)S 48 Z 2143 3039(4)U 60 Z 2994 3129(d)U 5 F 432 3201(")U 1 F 432 3129(tinguished)U 716(name)S 880(is)S 953(given,)S 1135(which)S 1315(speci\256es)S 1554(to)S 1633(whom)S 1815(the)S 1921(ACL)S 2073(applies.)S 2311(The)S 2437(pseudo-DNs)S 5 F 2768(")S 1 F (self)R 5 F (")R 1 F 2937(an)S 457 3201(other)U 5 F (")R 1 F 629(have)S 766(the)S 863(meanings)S 1117(of)S 5 F 1190(")S 1 F (the)R 1311(name)S 1464(of)S 1536(the)S 1632(DN)S 1740(for)S 1832(which)S 2001(we)S 2093(are)S 2189(doing)S 2348(ACL)S 2490(processing)S 5 F (")R 1 F (,)R 2829(and)S 5 F 2938(")S 1 F (all)R 432 3345(c)U 432 3273(other)U 577(DNs)S 5 F (")R 1 F (.)R 767(The)S 882(DNs)S 1012(are)S 1107(sorted,)S 1290(within)S 1464(ACL)S 1604(type,)S 1743(from)S 1880(most)S 2017(to)S 2084(least)S 2215(distinguished)S 2556(DN.)S 2697(DNs)S 2826(are)S 2920(then)S 459 3345(hecked)U 657(for)S 754(matches,)S 994(with)S 1128(the)S 1229(\256rst)S 1349(match)S 1524(being)S 1685(the)S 1786(one)S 1900(applied.)S 2140(In)S 2217(addition,)S 2457(any)S 2570(ACLs)S 2739(that)S 2856(protect)S 432 3417(entry)U 576(attribute)S 778(s)S 821(specify)S 1015(which)S 1182(attribute)S 1384(s)S 1427(are)S 1521(protected.)S 582 3510(Several)U 788(modi\256cations)S 1141(to)S 1213(this)S 1325(basic)S 1474(scheme)S 1680(come)S 1836(to)S 1908(mind.)S 2092(For)S 2199(a)S 2250(non-leaf)S 2475(node,)S 2631(the)S 2729(DN)S 2839(may)S 2967(be)S 432 3654(o)U 432 3582(treated)U 620(as)S 693(a)S 743(pre\256x)S 906(and)S 1016(any)S 1126(DN)S 1235(being)S 1392(checked)S 1613(against)S 1807(the)S 1904(pre\256x)S 2067(DN)S 2175(is)S 2237(compared)S 2497(only)S 2626(up)S 2708(to)S 2777(the)S 2873(length)S 462 3654(f)U 502(the)S 596(pre\256x.)S 0 F 48 Z 840 3714 M 8 22 0 0 16 0 0 18 PS16 432 3714 M 8 22 0 0 16 0 0 18 PS16 456 3714 M 8 22 0 0 16 0 0 18 PS16 480 3714 M 8 22 0 0 16 0 0 18 PS16 504 3714 M 8 22 0 0 16 0 0 18 PS16 528 3714 M 8 22 0 0 16 0 0 18 PS16 552 3714 M 8 22 0 0 16 0 0 18 PS16 576 3714 M 8 22 0 0 16 0 0 18 PS16 600 3714 M 8 22 0 0 16 0 0 18 PS16 624 3714 M 8 22 0 0 16 0 0 18 PS16 648 3714 M 8 22 0 0 16 0 0 18 PS16 672 3714 M 8 22 0 0 16 0 0 18 PS16 696 3714 M 8 22 0 0 16 0 0 18 PS16 720 3714 M 8 22 0 0 16 0 0 18 PS16 744 3714 M 8 22 0 0 16 0 0 18 PS16 768 3714 M 8 22 0 0 16 0 0 18 PS16 792 3714 M 8 22 0 0 16 0 0 18 PS16 816 3714 M 8 22 0 0 16 0 0 18 PS16 1 F 534 3783(This)U 636(problem)S 812(has)S 893(manifested)S 1119(itself)S 1231(in)S 1285(other)S 1400(forums.)S 1580(For)S 1663(additional)S 1869(information,)S 2122(consult)S 2276(the)S 2350(minutes)S 2517(of)S 2573(the)S 2647(January,)S 432 3843(1)U 36 Z 492 3768(1)U 48 Z 456 3843(990)U 546(meeting)S 717(of)S 775(ANSI)S 906(X9E9)S 1036(or)S 1094(the)S 1170(January)S 1337(and)S 1424(November)S 1644(1990)S 1758(meetings)S 1948(of)S 2006(IEEE)S 2127(802.10.)S 2305(Also)S 2414(see)S 2493(RFC)S 2601(1170)S 2714(for)S 2787(a)S 432 3903(response)U 616(from)S 725(Public)S 863(Key)S 959(Partners.)S 534 3972(X.509)U 669(\(88\),)S 777(unof\256cial)S 976(copy,)S 1097(Section)S 1256(3.3.)S 36 Z 492 4026(3)U 492 3957(2)U 48 Z 534 4041(This)U 636(section)S 788(is)S 837(based)S 963(upon)S 1076(X.509,)S 1224(as)S 1281(well)S 1380(as,)S 1449(Proposed)S 1644(Draft)S 1761(Addendum)S 1990(Documents)S 2224(\(PDADs\))S 2423(to)S 2476(ISO)S 2570(9594/Part)S 2772(2,)S 432 4101(3,)U 484(and)S 569(4.)S 534 4170(Proposed)U 731(extensions)S 951(to)S 1006(Part)S 1101(2,)S 1155(Annex)S 1301(F)S 1346(\(Access)S 1516(Control\))S 1696(de\256ne)S 1831(the)S 1906(additional)S 2113(access)S 2252(permissions)S 2498(``manage,'')S 2739(and)S 432 4230(`)U 36 Z 492 4155(4)U 48 Z 448 4230(`administer''.)U 742(These)S 873(permissions)S 1119(are)S 1194(used)S 1299(to)S 1353(control)S 1505(access)S 1644(to)S 1697(the)S 1771(access)S 1909(control)S 2060(information)S 2301(itself.)S 2440(However,)S 2644(by)S 2708(treat-)S 2792 4290(-)U 432 4350(c)U 432 4290(ing)U 512(the)S 589(ACLs)S 723(as)S 782(attributes)S 978(themselves,)S 1221(they)S 1322(may)S 1423(be)S 1486(handled)S 1655(by)S 1721(the)S 1797(attribute)S 1973(ACL)S 2087(like)S 2176(any)S 2263(other)S 2379(attribute.)S 2583(This)S 2686(is)S 2736(dis)S 453 4350(ussed)U 576(later.)S 60 Z 432 4629(Y)U (ee)R 549(&)S 616(Manning)S 2857(Page)S 2994(2)S EP %%Page: ? 3 BP 1 F 60 Z 2994 381(1)U 432(INTERNET-DRAFT)S 1195(A)S 1258(Scheme)S 1469(for)S 1559(Secure)S 1743(X.500)S 1911(in)S 1978(the)S 2072(Internet)S 2697(January)S 2904(199)S 582 597(Groups)U 782(of)S 856(DNs)S 988(may)S 1115(be)S 1195(used)S 1328(to)S 1398(manage)S 1609(the)S 1706(maintena)S 1928(nce)S 2035(of)S 2108(multiple)S 2333(individual)S 2601(DNs)S 2733(that)S 2847(share)S 2997(a)S 3009 669(,)U 432 741(o)U 432 669(common)U 665(ACL.)S 842(Groups)S 1040(may)S 1166(be)S 1245(de\256ned)S 1444(recursively,)S 1749(i.e.)S 1845(there)S 1988(may)S 2113(be)S 2191(groups)S 2375(of)S 2446(groups,)S 2645(groups)S 2829(of)S 2900(DNs)S 462 741(r)U 515(a)S 574(combinati)S 816(on)S 908(of)S 990(groups)S 1185(and)S 1304(DNs.)S 1480(Use)S 1605(of)S 1687(groups)S 1882(brings)S 2064(up)S 2156(the)S 2262(problems)S 2518(of)S 2600(performance)S 2937(and)S 2997 813(e)U 432 885(r)U 432 813(correctne)U 657(ss.)S 763(In)S 838(terms)S 997(of)S 1072(performance)S 1377(,)S 1417(any)S 1529(expansion)S 1798(of)S 1873(a)S 1925(group)S 2090(is)S 2155(bound)S 2330(to)S 2401(be)S 2482(slow.)S 2654(It)S 2715(may)S 2843(involv)S 452 885(equesting)U 706(information)S 1013(from)S 1152(other)S 1298(DSAs.)S 1497(It)S 1556(may)S 1682(also)S 1801(introduce)S 2051(the)S 2147(possibility)S 2420(of)S 2492(an)S 2571(ACL)S 2713(lookup)S 2902(loop.)S 432 1029(m)U 432 957(Correctness)U 745(of)S 824(the)S 927(result)S 1090(may)S 1223(also)S 1349(be)S 1435(important,)S 1714(but)S 1819(must)S 1964(be)S 2049(weighed)S 2281(against)S 2480(performance)S 2785(.)S 2848(Groups)S 479 1029(ay)U 557(be)S 635(handled)S 847(in)S 915(two)S 1026(ways:)S 1207(1.)S 1293(The)S 1408(list)S 1503(of)S 1574(DNs)S 1703(are)S 1797(\256rst)S 1910(checked,)S 2143(and)S 2250(if)S 2307(no)S 2387(match)S 2555(is)S 2615(found,)S 2790(the)S 2884(group)S 2994 1101(n)U 432 1173(w)U 432 1101(is)U 494(expanded)S 747(and)S 856(then)S 982(checked)S 1202(for)S 1294(a)S 1343(match;)S 1550(2.)S 1637(The)S 1753(group)S 1914(is)S 1975(\256rst)S 2089(expanded,)S 2356(and)S 2464(the)S 2559(result)S 2714(is)S 2775(merged)S 2977(i)S 475 1173(ith)U 562(the)S 659(other)S 806(DNs.)S 973(This)S 1102(has)S 1204(the)S 1300(potential)S 1534(to)S 1603(be)S 1682(substantially)S 2009(slower,)S 2206(although)S 2439(this)S 2548(procedure)S 2811(could)S 2967(be)S 3004 1245(-)U 432(done)S 571(en)S 650(masse)S 819(at)S 885(startup)S 1071(and)S 1180(the)S 1276(results)S 1455(cached.)S 1684(However,)S 1941(the)S 2036(\256rst)S 2150(alternat)S 2332(ive)S 2427(has)S 2528(the)S 2623(potential)S 2856(to)S 2924(pro)S 48 Z 1638 1227(5)U 60 Z 432 1317(d)U (uce)R 570(an)S 651(incorrect)S 890(applicat)S 1082(ion)S 1183(of)S 1257(access)S 1435(control.)S 1665(For)S 1772(example,)S 2016(an)S 2097(DN)S 2207(may)S 2335(be)S 2415(found)S 2578(in)S 2648(the)S 2745(list)S 2842(of)S 2915(DNs)S 3009 1389(.)U 432 1461(I)U 432 1389(that)U 547(denies)S 725(access)S 903(to)S 974(the)S 1072(entry.)S 1255(Because)S 1480(a)S 1531(match)S 1703(was)S 1820(found,)S 1999(no)S 2083(searching)S 2338(of)S 2412(the)S 2509(group)S 2672(need)S 2809(by)S 2892(done)S 452 1461(t)U 491(is)S 553(possible,)S 787(though,)S 991(that)S 1104(the)S 1200(group)S 1362(contains)S 1585(a)S 1634(more)S 1780(distinguished)S 2123(name)S 2276(which)S 2445(when)S 2596(matched)S 2822(with)S 2950(the)S 432 1533(DN)U 538(being)S 692(checked)S 910(would)S 1080(produce)S 1294(a)S 1341(different)S 1569(access)S 1743(control)S 1934(response.)S 582 1626(A)U 653(novel)S 815(idea,)S 959(although)S 1198(one)S 1313(that)S 1432(is)S 1500(probably)S 1742(not)S 1847(suitable)S 2063(in)S 2138(a)S 2193(pure)S 2328(OSI)S 2452(pilot,)S 2606(would)S 2784(be)S 2869(to)S 2944(use)S 3004 1698(-)U 432 1770(s)U 432 1698(NSAPs)U 634(as)S 711(an)S 795(additional)S 1064(basis)S 1211(for)S 1307(access)S 1487(control.)S 1719(Based)S 1892(on)S 1978(an)S 2061(NSAP)S 2239(comparison)S 2546(\(or)S 2642(possibly)S 2868(a)S 2921(sub)S 455 1770(tring)U 591(of)S 663(a)S 712(text)S 825(encoded)S 1048(NSAP\))S 1242(it)S 1298(is)S 1359(also)S 1477(possible)S 1695(to)S 1763(control)S 1955(access)S 2130(with)S 2258(a)S 2306(large,)S 2463(non-user)S 2694(based,)S 2867(granu-)S 432 1842(larity.)U 582 1935(Finally)U 775(it)S 831(should)S 1013(be)S 1092(noted)S 1248(that)S 1361(where)S 1530(possible)S 1749(and)S 1858(where)S 2026(applicabl)S 2248(e,)S 2311(the)S 2406(pilot)S 2538(project)S 2727(will)S 2842(attempt)S 0 F 48 Z 432 4272 M 8 22 0 0 16 0 0 18 PS16 1 F 60 Z 432 2007(to)U 499(track)S 640(emerging)S 888(CCITT/ISO)S 1195(standards)S 1442(on)S 1522(directory)S 1760(security,)S 1986(incorporating)S 2331(them)S 2472(as)S 2542(appropriate.)S 0 F 48 Z 456 4272 M 8 22 0 0 16 0 0 18 PS16 480 4272 M 8 22 0 0 16 0 0 18 PS16 504 4272 M 8 22 0 0 16 0 0 18 PS16 528 4272 M 8 22 0 0 16 0 0 18 PS16 552 4272 M 8 22 0 0 16 0 0 18 PS16 576 4272 M 8 22 0 0 16 0 0 18 PS16 600 4272 M 8 22 0 0 16 0 0 18 PS16 624 4272 M 8 22 0 0 16 0 0 18 PS16 648 4272 M 8 22 0 0 16 0 0 18 PS16 672 4272 M 8 22 0 0 16 0 0 18 PS16 696 4272 M 8 22 0 0 16 0 0 18 PS16 720 4272 M 8 22 0 0 16 0 0 18 PS16 744 4272 M 8 22 0 0 16 0 0 18 PS16 768 4272 M 8 22 0 0 16 0 0 18 PS16 792 4272 M 8 22 0 0 16 0 0 18 PS16 816 4272 M 8 22 0 0 16 0 0 18 PS16 840 4272 M 8 22 0 0 16 0 0 18 PS16 1 F 534 4341(H)U (andling)R 728(cache)S 852(consistency)S 1091(and)S 1176(policy)S 1311(is)S 1359(a)S 1396(whole)S 1529(other)S 1643(bag)S 1728(of)S 1784(worms.)S 1959(It)S 2004(is)S 2052(also)S 2145(not)S 2222(discussed)S 2422(in)S 2475(this)S 2560(document.)S 60 Z 432 4629(Y)U 36 Z 492 4326(5)U 60 Z 475 4629(ee)U 549(&)S 616(Manning)S 2857(Page)S 2994(3)S EP %%Trailer pscatsave end restore %%Pages: 3   Return-Path: Received: from BBN.com by bells.cs.ucl.ac.uk with SMTP inbound id <18703-0@bells.cs.ucl.ac.uk>; Mon, 11 Feb 1991 21:00:22 +0000 From: Lyman Chapin Subject: Re: Books on X.400 and X.500 To: A.Macpherson@uk.co.stc.stl Cc: Andrew.Findlay@uk.ac.brunel, directory-group@uk.ac.rutherford, osi-ds@uk.ac.ucl.cs In-Reply-To: <"7779 Tue Jan 1 15:08:26 1991"@stl.stc.co.uk> Date: Mon, 11 Feb 91 13:53:41 EST Mail-System-Version: >Date: Tue, 1 Jan 1991 15:07:54 +0000 >From: A.Macpherson@stl.stc.co.uk >To: Andrew.Findlay@brunel.ac.uk >Cc: osi-ds@cs.ucl.ac.uk, directory-group@rutherford.ac.uk >Subject: Re: Books on X.400 and X.500 > > >Andrew.Findlay@brunel.ac.uk writes: >| I am occasionally asked to recommend a book on X.400 and X.500 that >| goes a bit beyond the single chapters normally found in general >| networking texts. I do not know of any such books. Can anyone suggest >| some? > >@book{nccX400:84, > Author = Paul Chilton, > title = "X.400: the messaging and interconnection medium > for the future", > publisher = "{NCC} Blackwell", > year = 1990, > series = "An {NCC} Management Report", > address = {"NCC Blackwell Ltd, 108 Cowley Road, > Oxford OX14 13F, England"} } > >I found this book well written and very clear on 84, It steers well >clear of alphabet soup. The treatment of the 88 standards seems to >reflect a publisher's deadline which is a great pity, as I think we are >all hoping to skip straight past to 88. > >Paul Chilton has also written a volume "Introducing X.400" > >When I asked that question I was recommended "OSI explained". I found >it extremely heavy going. One should avoid this volume until one has a >considerable background familiarity with OSI acronyms. > >-- >A.Macpherson@stl.stc.co.uk - or - Post@stl.stc.co.uk >"Quot homines, tot sententiae" The best X.400 book I've found has been available for a couple of years now, but only in German; it's "Elektronische Post und Daten-Kommunikation", subtitled "X.400: Die Normen und ihre Anwendung", by Bernhard Plattner (et. al.). Fortunately, Addison-Wesley (UK) has decided to publish an English-language version, which has a publication date of July 1991. I strongly recommend that you look for a copy of this book as soon as it is available. - Lyman Chapin   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <16009-0@bells.cs.ucl.ac.uk>; Sun, 17 Feb 1991 22:40:06 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <4393-0@sun2.nsfnet-relay.ac.uk>; Sun, 17 Feb 1991 22:40:11 +0000 Received: from [129.240.2.50] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa02428; 17 Feb 91 22:35 GMT X400-Received: by mta pat.uio.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Sun, 17 Feb 1991 23:34:50 +0100 X400-Received: by /PRMD=uninett/ADMD=/C=/; Relayed; Sun, 17 Feb 1991 23:34:41 +0100 Date: Sun, 17 Feb 1991 23:34:41 +0100 X400-Originator: Geir.Pedersen@no.uio.use X400-MTS-Identifier: [/PRMD=uninett/ADMD=/C=/;910217233441] X400-Content-Type: P2-1984 (2) Content-Identifier: 1539 From: "Geir K. Pedersen" Message-ID: <"1539*/G=Geir/S=Pedersen/OU=use/O=uio/PRMD=uninett/ADMD= /C=no/"@MHS> To: osi-ds (IPM Return Requested) Subject: Concise summary of Object Classes and Attribute Types In a previous version of the draft for the COSINE and Internet X.500 Naming Architecture, there was an appendix giving a concise summary of all the defined object classes and attribute types. This is removed from the current version, apparently because of lack of interest from the community. We are currently working on a tool for managing data to be made available in the directory under the University of Oslo. As output this tool will produce EDB-files. It is necessary that the tool at least is capable of verifying the internal consistency of the objects generated. The mentioned appendix is suitable as a basis for doing this type of checks for us. I would think it also to be suitable as (partial) input to a generator of schema description files for x.500 implementations in general. A strong vote from us to get Appendix D back in again! Regards, Geir Pedersen University of Oslo Computing Service   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <16737-0@bells.cs.ucl.ac.uk>; Thu, 21 Feb 1991 20:27:14 +0000 Received: Thu, 21 Feb 91 15:24:48 EST by mazatzal.merit.edu (5.51/1.6) Date: Thu, 21 Feb 91 15:24:48 EST From: Chris Weider Message-Id: <9102212024.AA05254@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: New DISI working group and charter Gang: I have spoken to Joyce Reynolds and we will be having the first meeting of the DISI working group at St. Louis. Everything is cool for aims and purposes... I will be sending out a second revision of the charter for this group tomorrow to this mailing list. Everyone in authority has singed off on it, so, Let's Do It!!! Chris Weider MERIT   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4103-0@bells.cs.ucl.ac.uk>; Fri, 22 Feb 1991 11:09:07 +0000 To: "Geir K. Pedersen" cc: osi-ds (IPM Return Requested) Subject: Re: Concise summary of Object Classes and Attribute Types Phone: +44-71-380-7294 In-reply-to: Your message of Sun, 17 Feb 91 23:34:41 +0100. <"1539*/G=Geir/S=Pedersen/OU=use/O=uio/PRMD=uninett/ADMD= /C=no/"@MHS> Date: Fri, 22 Feb 91 11:09:02 +0000 Message-ID: <1712.667220942@UK.AC.UCL.CS> From: Steve Kille Does anyone else support this? The feedback received from most others has been that this appendix is not needed. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9642-0@bells.cs.ucl.ac.uk>; Fri, 22 Feb 1991 11:40:02 +0000 To: quipu@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Subject: Monitoring the top level of the DIT Phone: +44-71-380-7294 Date: Fri, 22 Feb 91 11:39:59 +0000 Message-ID: <1862.667222799@UK.AC.UCL.CS> From: Steve Kille We have been undertaking probing of the DSAs managing the top parts of the DIT. This work is now being done as a part of the PARADISE project. We see it as essential to improve the availability of the global pilot. We had been sending results of the probes to the QUIPU list. It seems inappropriate to do this on a list concerned with a single implementation. Therefore, we are going to send the results of this probing to the osi-ds list every two weeks. We feel that it is better to use this existing list, rather than to set up yet another list. Does anyone object to this approach? Steve   Return-Path: Received: from 192.33.33.110 by bells.cs.ucl.ac.uk with SMTP inbound id <15209-0@bells.cs.ucl.ac.uk>; Fri, 22 Feb 1991 17:29:48 +0000 Received: by ws10.nisc.sri.com (5.64/SRI-NISC1.1) id AA03378; Fri, 22 Feb 91 07:40:54 -0800 Message-Id: <9102221540.AA03378@ws10.nisc.sri.com> To: Chris Weider Cc: osi-ds@uk.ac.ucl.cs, rlang@com.SRI.NISC Subject: Re: New DISI working group and charter In-Reply-To: Your message of "Thu, 21 Feb 91 15:24:48 EST." <9102212024.AA05254@mazatzal.merit.edu> Date: Fri, 22 Feb 91 07:40:51 PST From: Ruth Lang Chris, When during the week of IETF will DISI be meeting? Ruth   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <15513-0@bells.cs.ucl.ac.uk>; Fri, 22 Feb 1991 17:39:48 +0000 Received: Fri, 22 Feb 91 12:37:20 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Feb 91 12:37:20 EST From: Chris Weider Message-Id: <9102221737.AA06339@mazatzal.merit.edu> To: clw@edu.merit, rlang@com.SRI.NISC Subject: Re: New DISI working group and charter Cc: osi-ds@uk.ac.ucl.cs O.K., the first meeting of the DISI group will be during the USWG meeting on Monday afternoon March 11, and will last for between one and one and a half hours. More info as I get it.... Chris Weider   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <18892-0@bells.cs.ucl.ac.uk>; Fri, 22 Feb 1991 20:30:31 +0000 Received: Fri, 22 Feb 91 15:28:06 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Feb 91 15:28:06 EST From: Chris Weider Message-Id: <9102222028.AA06549@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Draft Charter for the DISI Working Group (Take 2) Draft Charter for Directory Information Services (pilot) Infrastructure ___________________ Directory Information Services (pilot) Infrastructure Working Group (DISI) Chairperson: Chris Weider, MERIT clw@merit.edu Mailing Lists: General Discussion: disi@merit.edu To Subscribe: disi-request@merit.edu Mail Archive: pub/disi-archive@merit.edu Description of Working Group: The Directory Information Services (pilot) Infrastructure Working Group is chartered to facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards. It will facilitate this deployment by producing informational RFCs intended to serve as a Directory Services "Administrator's Guide". These RFCs will relate the current usage and scope of the X.500 standard and Directory Services in North America and the world, and will contain information on the procurement, installation, and operation of various implementations of the X.500 standard. As the various implementations of the X.500 standard work equally well over TCP/IP and CLNP, the DISI working group shall not mandate specific implementations or transport protocols. The Directory Information Services (pilot) Infrastructure Working Group is an offshoot of the OSI Directory Services group. The OSIDS working group was chartered to smooth out technical differences in information storage schema and difficulties in the interoperability and coherence of various X.500 implementations. The DISI group is concerned solely with expanding the Directory Services infrastructure. As DISI will be building infrastructure with an eye towards truely operational status, DISI will need to form liasons with COSINE, Paradyse, and perhaps the RARE WG3. As a final document, the DISI working group shall write a charter for a new working group concerned with user services, integration, and operations of Directory Services, the Internet Directory User Services Group. Goals and Milestones: March 1991: First IETF Meeting: review and approve the charter making any changes necessary. Examine needs and resources for the documentation to be produced, using as a first draft a document produced by Chris Weider, MERIT, which will be brought to the IETF. Assign writing assignments. Further work will be done electronically. Discuss liasons to various European Directory Services groups. July 1991: Second IETF Meeting: review and approve documentation; review and approve charter for the IDUS group. August 1991: Electronically review final draft of documentation, and, if acceptable, submit to IESG for publication. December 1991: Third IETF Meeting: Declare success and reform DISI group as IDUS group.   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <16039-0@bells.cs.ucl.ac.uk>; Mon, 25 Feb 1991 15:57:48 +0000 Received: Mon, 25 Feb 91 10:55:17 EST by mazatzal.merit.edu (5.51/1.6) Date: Mon, 25 Feb 91 10:55:17 EST From: Chris Weider Message-Id: <9102251555.AA08664@mazatzal.merit.edu> To: jkrey@edu.isi, osi-ds@uk.ac.ucl.cs Subject: second revision of DISI charter... Gang: The DISI draft charter has been amended to reflect the fact that DISI is in both the User Services and the OSI Integration areas. Again, could someone please forward this to Rob and Ross as I can't seem to reach them? Thanks! Chris Weider MERIT Draft Charter for Directory Information Services (pilot) Infrastructure ___________________ Directory Information Services (pilot) Infrastructure Working Group (DISI) Chairperson: Chris Weider, MERIT clw@merit.edu Mailing Lists: General Discussion: disi@merit.edu To Subscribe: disi-request@merit.edu Mail Archive: pub/disi-archive@merit.edu Description of Working Group: The Directory Information Services (pilot) Infrastructure Working Group is chartered to facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards. It will facilitate this deployment by producing informational RFCs intended to serve as a Directory Services "Administrator's Guide". These RFCs will relate the current usage and scope of the X.500 standard and Directory Services in North America and the world, and will contain information on the procurement, installation, and operation of various implementations of the X.500 standard. As the various implementations of the X.500 standard work equally well over TCP/IP and CLNP, the DISI working group shall not mandate specific implementations or transport protocols. The Directory Information Services (pilot) Infrastructure Working Group is an offshoot of the OSI Directory Services group, and, accordingly, is a combined effort of the OSI Integration Area and User Services Area of the IETF. The current OSIDS working group was chartered to smooth out technical differences in information storage schema and difficulties in the interoperability and coherence of various X.500 implementations. The DISI group is concerned solely with expanding the Directory Services infrastructure. As DISI will be building infrastructure with an eye towards truly operational status, DISI will need to form liasons with COSINE, Paradyse, and perhaps the RARE WG3. As a final document, the DISI working group shall write a charter for a new working group concerned with user services, integration, and operations of Directory Services, the Internet Directory User Services Group. Goals and Milestones: March 1991: First IETF Meeting: review and approve the charter making any changes necessary. Examine needs and resources for the documentation to be produced, using as a first draft a document produced by Chris Weider, MERIT, which will be brought to the IETF. Assign writing assignments. Further work will be done electronically. Discuss liasons to various European Directory Services groups. July 1991: Second IETF Meeting: review and approve documentation; review and approve charter for the IDUS group. August 1991: Electronically review final draft of documentation, and, if acceptable, submit to IESG for publication. December 1991: Third IETF Meeting: Declare success and reform DISI group as IDUS group.   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <20704-0@bells.cs.ucl.ac.uk>; Tue, 26 Feb 1991 01:38:29 +0000 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 25 Feb 91 17:39:05 -0800 Date: Mon, 25 Feb 91 17:38:27 PST From: hotz@edu.ISI Posted-Date: Mon, 25 Feb 91 17:38:27 PST Message-Id: <9102260138.AA09812@chienne.isi.edu> Received: by chienne.isi.edu (4.1/4.0.3-4) id ; Mon, 25 Feb 91 17:38:27 PST To: osi-ds@uk.ac.ucl.cs Subject: Subscribe &/or add to list Please add me to the the osids WG mailing list. Thanks, steve   Return-Path: Received: from att.att.com by bells.cs.ucl.ac.uk with SMTP inbound id <21461-0@bells.cs.ucl.ac.uk>; Tue, 26 Feb 1991 02:34:48 +0000 From: youbong@com.att.arch2 Date: Mon, 25 Feb 91 16:56 EST To: osi-ds@uk.ac.ucl.cs Cc: pww@ca.bnr Subject: Re:X/OPEN API Peter, I was not there when the IETF group discussed the adoption of X/OPEN API. Here are my comments: --------------------------------------------------- > The disadvantages are: 1) APIs might develop dependencies on > internal hooks into OM code, 2) each implementation of X.xxx > requires its own OM, and 3) X.400 and X.500 (to name two > possible X.xxx - there may be more! - users of the X/OPEN OM) > cannot necessarily share the same OM. > > 1) should not be a problem - .... --------------------------------------------------- No comment --------------------------------------------------- > 2) if users of QUIPU develop an X/OPEN compliant API, they might > not be able to share it with non-QUIPU users participating in > the pilot - why should each site have to reinvent the wheel? ---------------------------------------------------- I am confused with your "user". Do you mean a DUA implementor or a DUA user? X/OPEN API was developed for application programmers, i.e. DUA users, so that users can have application portability. For a DUA implementor's point of view, your concern does not seem to go away even if the IETF DS group does not adopt XDS (X/OPEN API) because any DUA implemention whether it use QUIPU or non-QUIPU, needs to implement some API anyway. ------------------------------------------------------ > Furthermore, if any particular implementation of X.x00 changes > "too much" from release to release, the OM may have to change, > and that might entail a significant amount of work - perhaps > enough to justify not using X/OPEN at all. ------------------------------------------------------- I hope that a X.x00 implementation includes the OM. Although a X.x00 implementation changes "too much" including OM implementation, it probably keeps the same XOM interface. Thus, users using the X.x00 implementation may not need any work. ---------------------------------------------------------- > 3) this seems to defeat the idea of a common OM altogether - why > have a common OM if X.400 and X.500 require different OMs? ----------------------------------------------------------- It is not a common OM for X.400 and X.500 implementations, but it is a common OM for users of the X.400 and X.500 implementations. Although X.400 and X.500 may require different OM internals, they require the same XOM interface so that users can access it in the same way. Thus, users can transfer from one "workspace" of X.400 to the other "workspace" of X.500 for the same object through the XOM interface. Or am I missing anything here? Youbong Weon-Yoon AT&T youbong@arch2.att.com   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <23268-0@bells.cs.ucl.ac.uk>; Tue, 26 Feb 1991 06:03:43 +0000 Received: Tue, 26 Feb 91 01:04:18 EST by merit.edu (5.59/1.6) Date: Tue, 26 Feb 91 01:04:18 EST From: Mark Knopper Message-Id: <9102260604.AA22745@merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Proposed Minutes of February 1991 OSI-DS Meeting Minutes of the Third IETF-Directory Services (OSI-DS) Working Group February 12-13, 1991 Menlo Park (SRI) 1. Attendees Mark Knopper Merit 313-763-6061 mak@merit.edu Tim Howes U-Michigan 313-764-2278 tim@d.cc.umich.edu Alex Pepple BNR 613-763-7684 alexp@bnr.ca Peter Mierswa DEC 508-486-5581 mierswa@smaug.enet.dec.com Bill Nowicki Legato 415-329-7856 nowicki@legato.com Russ Wright LBL 415-486-6965 wright@lbl.gov Arlene Getchell ESnet/NERSC 415-423-6349 getchell@nersc.gov Ruth Lang SRI 415-859-5608 rlang@nisc.sri.com Jose Garcia-Luna SRI 415-859-5647 garcia@sri.com Steve Kille UCL +44-71-380-7294 s.kille@cs.ucl.ac.uk M. T. Rose PSI 408-562-6222 mrose@psi.com Barry Holroyd Sun 415-336-2949 berries@eng.sun.com Paul Koski HP 408-447-3461 koski@hpindeg.cup.hp.com Peter Yee NASA 415-604-3812 yee@ames.arc.nasa.gov Chris Weider Merit 313-936-2090 clw@merit.edu Stuart Cain HP 408-447-2417 scain@hpindeg.cup.hp.com Cyrus Chow Nasa 415-604-6843 cchow@ames.arc.nasa. gov 2. Agenda, Revised a. Agenda, Revised b. Minutes of previous meeting c. Liaisons: RARE WG3, NIST, NADF, AARN, ANSI d. Replication i. Replication Requirements ii. Replication Solutions iii.Network Addresses iv. Presentation Addresses e. APIs for the Pilot f. User Friendly Naming g. Domains and X.500 h. Representation of Network Info in X.500 i. DSA Naming j. Building Internet Directory/Strategy k. Operational Pilot Status l. Monthly Reports on Pilots m. New working groups: Operations, User Support n. Internet Schema o. Naming Guidelines p. Naming for Internet Pilot q. Security r. Directory Assistance Protocol s. Quality of Service t. Date and Venue of next meeting 3. Introduction The meeting was opened by Steve Kille at 9:10am on February 12, 1991. The agenda was slightly revised and massively reordered. 4. Minutes of Previous Meeting Steve thanked Richard Colella and Peter Whittaker for producing the minutes. He reported on the status of some of the action items at the last meeting. The formatting of the documents has been improved. The "Infrastructure" document met with some difficulty in forwarding as an RFC. Steve was asked to produce a separate "Strategy" document and to revise the RFC. Steve contacted Al Grimstad to check on a user friendly naming related proposal, and found that this is no longer relevant. There were no corrections to the minutes. 5. Liaisons a. RARE WG3 Steve reported on this meeting which took place in Brussels in January. They discussed the activities of our IETF-DS group. Their next meeting is April 16-17 in Utrecht, Holland. They meet three times per year. They are very interested in getting more US participation. Future meetings are in July, and also October 31- November 1. Can the IAB find funding for international travel for IETF members? Steve will look into the funding question with appropriate people. European meetings usually have 1-2 representatives from each country. They would also like representation from the FOX project. b. NIST Stuart Cain reported on the Directory SIG meeting in December. They discussed implementation agreements for replication and access control. They would like to see the requirements from our group. NIST is working from the current CDAM. There is already a stable implementors agreement based on the 1988 CCITT recommendation. The new spec is expected by the end of the year. The next meeting will be in March. Steve has replied informally to the NIST liaison to encourage coordination between the two groups and also to share our documents on replication requirements and solution. The sense of this was agreed to by the group, and it will be used to generate a formal liaison response. The NIST group is concerned with "freezing" their agreements based on a DIS version of the standard, and will be working to avoid that kind of discrepancy. c. North American Directory Forum Marshall Rose reported that the last meeting was in October, before the last IETF-DS meeting. The next meeting is in March, after this meeting. Oh well. d. Australian Academic Research Network Steve received a liaison statement from George Michaelson. Standards Australia is working on X.500 naming and addressing standards. They will send people to the IETF some time this year. They have not been able to participate in this group due to lack of funds. e. ANSI US Directory Ad Hoc Group Roy Van Dorn (HP) reported that this group met last week. They are bringing ballot comments to ISO. Subordinate references will be replicated, according to the latest draft standard. Replicating cross-references will not occur. Hoyt Kesterson is the ISO Rapporteur. Skip Sloan will be the head of the US delegation. Steve will send them the replication documents from our group. There will be one more US meeting in March for ballot comments. The liaison of the group's documents to ISO will be done through ANSI by Paul Koski. Access control and replication are US priorities. Some of the schema document will get into the 1992 standard. The definitions of attributes will be more like 1988. The four types of object classes will continue. Subtrees and partial entries within subtrees can be replicated. A completeness flag is included in replication. Searches on attributes that don't exist will be referred for further lookup. The unit of replication is an entry, not an attribute within an entry. 6. Replication a. Replication Requirements It was agreed that this Internet Draft (Replication Requirements to Provide an Internet Directory Using X.500) be progressed to an RFC. b. Replication Solutions There was substantial discussion of this paper. Marshall and Steve revised the text during the meeting and redistributed the document. Marshall suggested that the title be changed to include the changes to Distributed Operations as well as replication. This suggestion was agreed to by all. A number of changes were suggested to make the document more clear. There was a suggestion to include a figure describing knowledge replication. None of the proposed changes require discussion at a further meeting, and Steve agreed to send a revised document out to the list on Monday (February 18). The group will respond within one week with any comments. After that the Internet Draft (Replication to Provide an Internet Directory Using X.500: A Proposed Solution. However the title may be changed.) will be progressed to an RFC. c. Network Addresses There were a few comments from the IAB regarding the Telex kludge. It was agreed that this Internet Draft (An Interim Approach to Use of Network Addresses) be progressed to an RFC. d. Presentation Addresses It was agreed that this Internet Draft (A String Encoding of Presentation Addresses) be progressed to an RFC. 7. APIs for the Pilot Ruth Lang said that this was an important area and would like to see suggestions for APIs (application programming interface). The only comment received so far on the list was from Peter Whittaker (BNR) about object management support in XOPEN. There was a discussion of the XDS agreements. Peter Mierswa said that DEC participated in XDS. The user-friendly and object-oriented aspects of XDS will cause applications to be large. It is difficult to extend the XDS object set. There are other technical drawbacks, but it was agreed to by a number of parties. DEC will support the XDS API but also a more functional layer. Quipu does not support XDS. XDS and object management documentation is available from Omnicom. It was felt that APIs did not fit into our group's charter. We may want to make recommendations but then move on to the technical infrastructure. This group is also not to manage projects or pilots. 8. User Friendly Naming Peter Mierswa tried to find a common syntax set with the OSF DCE naming (based on unix filesystem syntax) and the proposed X.400 annex for business card OR address format (uses semicolons and slashes, which evolved out of the RFC 987 work). However there was no such syntax in common and Peter gave up. The algorithm in this document is useful based on experience, though there may be scope for experimentation. It was noted that name space organization affects efficiency of searches. For example Cambridge University uses many levels of OU. It is recommended in the Naming Guidelines document (see section 18) that pilots be laid out so that this user friendly naming scheme works reasonably. It was agreed that this Internet Draft (Using the OSI Directory to Achieve User Friendly Naming) be progressed to an RFC. 9. Domains and X.500 UCL has done some work in implementing this scheme. There is a tool to do a white pages lookup based on a domain address. This is an experimental service. The general appropriateness of representing domain name system information in the Directory was discussed. This is viewed as controversial. The X.500 version of DNS may have be usable for other functions than those currently offered by the DNS, such as browsing. Mailbox records are included in the DNS, but are not widely used. Peter Mierswa said that it would not matter if this was not submitted as an RFC. Steve disagreed with that and would like to progress the work. Tim Howes suggested that we submit this with a disclaimer that it is experimental. Steve would like the IAB to discuss these issues. Jose Garcia-Luna felt that security should be discussed in this paper. It was eventually agreed that this Internet Draft (Domains and X.500) should be progressed as an RFC. 10. Representation of Network Information in X.500 Mark Knopper and Chris Weider gave a presentation on some work in progress at Merit, which will become part of the DARPA/NSF sponsored Field Operational X.500 (FOX) project. They have entered the network contacts part of the whois data into the @o=Internet part of the White Pages DIT. New object classes have been defined. Bill Nowicki noted that putting all of the IP network numbers into a single location in the DIT will not scale well. It was suggested that the network number entries be located within the owning organizations. This would obviously require much more participation in the X.500 projects. For now the net numbers can be entered in a separate tree under o=Internet and eventually these entries will just be pointers to the master network entries. Steve proposes another solution to this in the Domains and X.500 paper. It is scalable, but also requires more work to bootstrap. There will be further cooperation with SRI, ISI and PSI to allow the rest of the NIC's data to be entered into X.500. There were a number of useful suggestions on how the network information could be stored in the DIT. It was recommended that Merit produce an internet draft to document this effort, both work in progress as well as long term design. Chris agreed to do this by March 7. He will take the scalability issues into account. 11. DSA Naming The current South American wildlife names don't seem to be descriptive enough! The solutions outlined in this paper solve some operational problems with quipu-based pilots. Peter pointed out that the section on multinational organizations does not solve the problem. There were several suggestions for modifications, and discussion of this will be necessary at the next working group meeting. It was felt that after that, this Internet Draft (DSA Naming) can be progressed to an RFC. 12. Building Internet Directory/Strategy The infrastructure Internet Draft was held up in protracted discussion regarding how to submit RFCs. Steve wrote a new strategy document. It was agreed that APIs should be mentioned in this document. The "strategy" was removed from the I.D. and so that was renamed to a very long name beginning with "Overall Plan". The strategy document was agreed to in principle but will not be forwarded at this time. The Overall Plan Internet Draft was agreed to be progressed to an RFC again. 13. Operational Pilot Status a. PSI Pilot Marshall reported that there are about 70 organizations on the US pilot. Growth has been linear since the pilot began. ISODE 6.8 interim release is due out by the end of the month. It is a very stable and higher performance version. It will have Tim Howes' mods to quipu, and also the Directory Assistance Protocol (which allows splitting the DUA between two different hosts). FRED is faster now. There is a Macintosh DUA offered by PSI as shareware. A source license is available similar to the Nysernet SNMP license. The PSI pilot only allows DSAs to be connected via IP (and now CLNP). The quality of X.25 in the US "sucks dead pigs through a straw". [Ed. Note: It has been suggested offline to formalize this language to "provides pneumatic inward pork- pressure via narrow flexible tubing".] b. COSINE Pilots Steve reported that 19 out of 20 countries in COSINE are running X.500 pilots. The COSINE P2.1 pilot has been renamed as PARADISE, and has officially started. Its manager is David Goodman. ULCC has an operational facility to replace Giant Tortoise. Their plan is to support international pilots until the end of 1992. France has a research pilot based on quipu and also a commercial pilot based on Pizarro. Xtel and the Dutch PTT are involved in PARADISE. 14. Monthly Reports on Pilots It is felt that the operational pilots should distribute status reports on a monthly basis. The FOX project is interested in coordinating the US report. Ruth Lang contacted Jon Postel at ISI about this and Jon volunteered ISI to produce the reports. Some FOX mailing lists will be set up to help coordinate the US report. David Goodman, the PARADISE manager, will integrate this into the international report. FOX and PARADISE will agree on timescales for ensuring that this comes out each month. Reports will be timely, with noncontributors marked as "no report for XXX". This international report will be sent out as a part of the Internet Monthly Report and to a separate list for those not interested in other aspects of the IMR. The reports should be on "The State of the DIT". Organizations should be queried for their activities. Marshall gets regular statistics reports from the US DSAs. The Canadian pilot is operated by the University of Toronto. 15. New Working Groups a. X.500 User Support Working Group Chris Weider volunteered to chair a new working group. Steve will talk to the IETF area coordinators and suggest that the new group be jointly in the OSI and User Services areas. Several of the group participants were interested in joining the new group. The first meeting will be at the next IETF. Chris distributed a draft charter and several comments were made. Chris will talk to Joyce Reynolds and Dana Sitzler, to see whether it would be reasonable to model the group after the NISI working group. Perhaps the new group should be called DISI (pronounced "dizzy"). The group would provide a documentation package for sites, as well as a center of expertise for X.500 issues. b. X.500 Operations Working Group There was some interest in forming such a group but it was felt that this should wait until the activities of the main IETF-DS group come to an end, or at least go into "maintenance mode". It was viewed that the group will only last for one more meeting with the same high level of activity. After that the operations group will be formed. Marshall Rose and Chris Weider were involved in discussing the charter of the new group. 16. Internet Schema Marshall suggested that the name of the Internet Draft (COSINE and Internet Naming Architecture) be changed from "naming architecture" to "schema". This was accepted. There were comments on this document at the RARE WG3 meeting. The textEncodedORAddress attribute was deprecated by OSI purists, but some members felt it was useful in the pilots. This Internet Draft was agreed to be progressed to an RFC. 17. Naming Guidelines Steve introduced this Internet Draft and explained that it sets out some guidelines for how to lay out a pilot DIT. It is a followon to annex B of X.521. Marshall mentioned that the T.61 character sets for international symbols once were a problem but work now in quipu. Peter mentioned that this is not a solution for multinational organizations. It is viewed that this is a difficult problem, and that the acceptable solutions should be documented. There needs to be a definition of "multinational organization". HP would like to see a single "mount point". There was a discussion of organization naming strategy. Marshall suggested that the names be fully descriptive to avoid later, possibly legal, conflicts. The naming authorities must enforce unique names within the DMD. Long names were recommended. Marshall mentioned that a small DIT depth makes browsing less effective. It is not useful to define conformance rules for a guidelines document. Conformance is useful for a given national pilot. Steve and Paul Barker will edit the document and distribute to the group. At the next meeting it will be proposed that the Internet Draft (Naming Guidelines for Directory Pilots) be progressed to an RFC. 18. Naming for Internet Pilot Marshall gave a presentation of a paper he and Einar Stefferud had written to be presented at the NADF, US-CCITT-Study Group D, and ANSI as well as to this group. The problem is that there are no OSI numbering authorities in the US, but they are needed for pilots to advance to a production stage. ANSI has accepted over 500 applications for OIDs under 1.2.840, but due to legal problems have not assigned any. Numbers are not a problem for ANSI but names are. The only legal method would be to assign the name and then publish the fact in the Federal Register with the reserve to revoke on a 6-month challenge procedure basis. GSA has been assigning NSAPs under AFI/IDI=47/0005, only for federal agencies. IANA has assigned several hundred OIDs under 1.3.6.1.4.1 for internet network management use. US-CCITT-SG-D is trying to make a national decision on naming, but only for an X.400 ADMD/PRMD registry and not for X.500. Possible naming universes are geographical, political or community. Civil authorities are the best choice as it gives a familiar and undisputed structure. However collisions in RDNs must be avoided. The proposal suggests using the numeric code assigned by ANSI for the RDN itself. This was heavily disputed, but as Marshall noted it would be legally defensible. The consensus was that we should fix ANSI rather than using numeric RDNs. Marshall and Stef believe that their presenting this proposal to the four groups will force a national decision. The proposal went on to recommend use of numeric codes for states and populated places. Naming of OSI entities was included, and there was a suggestion that non- OSI entities should get names too (eg. SNA, TCP/IP applications). Steve suggested that this be made into an Internet Draft but not a standard. Marshall will make the changes suggested by the group before the NADF presentation in March. He will "lean heavily" on ANSI to begin assigning names. Beth Summerville is ANSI's registrar for the naming authority function. 19. Security Peter Yee's paper was revised since the last meeting. There were not many changes due to lack of comments at Boulder. Marshall said that it will be necessary to consult with the IETF Security working group before progressing this document. Peter will contact Steve Crocker to get help on proper security terms and concepts. Marshall suggested splitting the discussion in the paper between authentication (simple now, strong later), and authorization (access control lists). Paul suggested including an ACL to control access for searching. Steve suggested that this should become an Internet Draft with title Security Requirements for X.500 in the Internet. There should be a companion document for Security Solutions, and this should reference the 1992 CCITT document. A problem at MIT is that they want to limit searching their organizations to return data only if less than n entries. HP wants to disallow searching their organization entirely. Peter will revise the document and send it out to the list by March 1. 20. Directory Assistance Protocol Marshall wrote an RFC describing a protocol used by PSI's Macintosh DUA client. It documents existing practice and is not a standard. The server is part of ISODE. He characterized the protocol as "horrid". Tim Howes has also been working on a Macintosh DUA with a different protocol. Tim will write an RFC for his DAP pretty soon. 21. Quality of Service Steve submitted an informal writeup to suggest that QOS attributes be added to the schema to represent the advertised quality of DSA services in the pilots. This was thought to be a good idea and there were no objections to including this in the Schema document. 22. Notable Actions, Dispositions and Promises a. RFC Progression The following documents were recommended to be progressed to RFC status: Replication Requirements to Provide an Internet Directory Using X.500 (section 6a) Replication Solution and Distributed Operations (section 6b) An Interim Approach to Use of Network Addresses (section 6c) A String Encoding of Presentation Addresses (section 6d) Using the OSI Directory to Achieve User-Friendly Naming (section 8) Domains and X.500 (section 9) Overall Plan (section 12) Internet Schema (section 16, and including QOS item in section 21) Naming Guidelines for Directory Pilots (section 17) b. Action Items Strategy document will be revised by Steve (sections 4, 12). The issue of travel funding will be investigated by Steve (section 5a). A formal response to NIST will be drafted by Steve (section 5b). The replication documents will be sent to ISO via ANSI and Paul Koski by Steve (section 5c). Jon Postel, for the FOX project, will set up a mailing list, and produce monthly reports coordinated with PARADISE and the Internet Monthly Reports (sections 10 and 14). Chris Weider will start up the new Directory Information Services Infrastructure working group (section 15a). Chris and Mark will write an RFC on representing network infrastructure information by March 7 (section 10). Marshall Rose will lean heavily on ANSI to assign organization ids and names (section 18). The security document will be revised by March 1 by Peter Yee (section 19). 23. Date and Venue of Next Meeting There will be no OSI-DS meeting at the March IETF. The next meeting will be after that, to be decided on the list. A possibility is a video conference, or alternatively a face to face meeting either in Ann Arbor or on the east coast in May or June. The choice depends on online discussion of the working drafts. Given some comments, it might be appropriate to wait until July. Steve will poll the group after the next round of editing. 23. Thanking the Host Ruth Lang and SRI International were thanked for their excellent services including a lunch.   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <13711-0@bells.cs.ucl.ac.uk>; Tue, 26 Feb 1991 19:55:50 +0000 Received: Tue, 26 Feb 91 14:56:16 EST by merit.edu (5.59/1.6) From: Mark Knopper Message-Id: <9102261956.AA07835@merit.edu> To: Paul-Andre Pays Cc: osi-ds@uk.ac.ucl.cs Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting In-Reply-To: Your message of 26 Feb 91 09:30:32 +0100. <9102260830.AA18110@mars.emse.fr> Date: Tue, 26 Feb 91 14:56:15 -0500 Paul-Andre, Thanks for the clarification. As I recall the status report here was quite brief and my notes were sketchy. I will produce a revised version of the minutes when the comments settle down and re-post to the list. Mark ------- > Steve reported that 19 out of 20 countries in COSINE are running > X.500 pilots. The COSINE P2.1 pilot has been renamed as PARADISE, > and has officially started. Its manager is David Goodman. ULCC > has an operational facility to replace Giant Tortoise. Their plan > is to support international pilots until the end of 1992. France > has a research pilot based on quipu and also a commercial pilot > based on Pizarro. Xtel and the Dutch PTT are involved in > PARADISE. > > As the coordinator of the french directory pilot, I am a little bit surpris ed by the above statement about France. FYI one can say: There is french pilot project named OPAX (Operation Pilote Aristote X.500) under the ARistote association umbrella. It consists of 2 parts: . paradis: is the name of the "research" branch and for phase 1 consists of 4 "academic" sites, with Pizarro sources. this is really the french branch of PARADISE. . eden: is the more "industrial" branch (though it consists of research organisations) as it uses commercial products and software house support. During phase 1 the software used is UCOM-DIR from E3X (it is a commercial version of Pizarro). Though Pizarro based at the begining, the pilot will open to different vendor X.500 impolementations; Quipu, HP and Bull products are planned within a few monthes. Regards -- PAP   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6373-0@bells.cs.ucl.ac.uk>; Wed, 27 Feb 1991 10:46:50 +0000 To: Mark Knopper cc: osi-ds@uk.ac.ucl.cs Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 26 Feb 91 14:56:15 -0500. <9102261956.AA07835@merit.edu> Date: Wed, 27 Feb 91 10:46:49 +0000 Message-ID: <930.667651609@UK.AC.UCL.CS> From: Steve Kille Can I clarify (accuracy) what I said: 19 out of 20 Cosine (European) countries are represented in the Paradise project. Not all of these are running pilots. I undrestood, but presumably explained poorly, the French situation. Paul-Andre's message explains things nicely from the viewpoint of the French pilot. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17127-0@bells.cs.ucl.ac.uk>; Wed, 27 Feb 1991 15:04:30 +0000 To: mierswa@com.dec.enet.smaug, koski@com.hp.cup.hpindeg cc: osi-ds@uk.ac.ucl.cs Subject: NSSRs Phone: +44-71-380-7294 Date: Wed, 27 Feb 91 15:04:28 +0000 Message-ID: <1844.667667068@UK.AC.UCL.CS> From: Steve Kille Peter/Paul, You queried my definition of NSSRs. I suggested that where there is an NSSR, the DSA will hold the master of the entry. You suggested that one of the DSAs pointed to by the NSSRs holds the entry itself, which I accepted at the meeting and agreed to make changes. I've been checking X.518 and I think that you are wrong/misunderstood what I was saying. 10.3.5, defines an NSSR as "the Acces Point of a DSA which holds one or more IMMEDIATELY SUBORDINATE naming contexts" (my capitalisation). Thus where there is a (set of) NSSRs, they point to the level below. I note that there is one change to what I had tho, which might have been what you were trying to tell me. There is no requirement that the the master is held in the EDB. It may be pointed to by a subordinate/cross reference. I should also make another clarification. My note had been written assuming that NSSRs are not mixed with other types of reference. Where they are, the NSSR will be stored at a level in the DIT higher than the subordinate/internal refs. The note is descibing a situation where there are ONLY subordiante refs below a given point. Generalising this would make things clearer. Do you agree with this, or am I confused? Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <27623-0@bells.cs.ucl.ac.uk>; Wed, 27 Feb 1991 17:03:38 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Revised document on Replication + Dist Operation Phone: +44-71-380-7294 Date: Wed, 27 Feb 91 17:03:30 +0000 Message-ID: <2189.667674210@UK.AC.UCL.CS> From: Steve Kille As promised, I have revised the "replication solution" document. It is available for FTP - description on how to get it is appended to this message. Let me recap what was agreed at the meeting. A number of documents were agreed to go forward as RFCs with no (or trvial) editing. It was agreed that this document was technically stable, agreed, and ready to go forward. It was also agreed that it needed to be released as soon as possible. However, some aspects of the description were not sufficently clear. I undertook to edit a revised document immediately after the meeting (I have slipped my deadline on this by 8 days - apologies). The revised document will be commented on immediately. A 1 week comment period was agreed. This gives until 7th March. After this, assuming everyone happy, the document should be submitted as RFC. Please send comment ASAP. The following sorts of messages are suitable replies. Please be careful to distinguish what sort of message you are sending. 1. Document should go forward as RFC with no changes 2. Request for an extension of the deadline (please justify) 3. Editorial comment, but otherwise as 1. 4. Changes which need to be made, but otherwise as 1. (This type of message should go to the whole list) 5. Changes which need to be made, and justify another version of the document being circulated for comment (and a new deadline) No reply will be interpreted as 1. I would like to get replies from everyone who attended the SRI meeting. If you suggest changes, please send alternate text! Steve The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ repl-sol.ps Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Kille February 1991 Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29737-0@bells.cs.ucl.ac.uk>; Wed, 27 Feb 1991 17:22:53 +0000 To: osi-ds@uk.ac.ucl.cs cc: J.Crowcroft@uk.ac.ucl.cs, j.cowan@uk.ac.ucl.cs Subject: Videoconference meeting of OSI-DS group Phone: +44-71-380-7294 Date: Wed, 27 Feb 91 17:22:38 +0000 Message-ID: <2196.667675358@UK.AC.UCL.CS> From: Steve Kille I've been looking into this. I am very tempted to hold a videoconference late in March. This will let us touch base on various aspects. I'd suggest a half day (morning on West Coast, Early Evening in Europe). This would definitely also be an experiment on the Videoconference facilities, so we should not rely on this for too much. There are still quite a number of technical problems. The possible locations are: London (UCL) - good facility (20-30) Washington (DARPA) - good facility (20-30) Bay Area (NASA/Moffet Field) - smaller facility (8 people) Boston (BBN) - poor facility (5-6 people) Most use of the system so far has been for very small groups of people (4-6) to resolve specific areas (not counting observers). Our meeting would be larger, and so rather experimental in this sense. Most (all?) meetings so far have been at two sites. I'm told that it is now possible to work with four sites. This aspect would also be experimental. Such a usage would need to be booked quite a way ahead. I'd suggest that we go for three sites (UCL, NASA and either DARPA or BBN). Assuming that we do this, that I can create an interesting but not critical agenda, and that the date is convenient, how many of you would like to participate in this? Please let me know which site, and if east coast (BBN/DARPA) whether you would be prepared to use the other one. If enough Europeans can get to UCL, we could use some of this to discuss international co-ordination. I think that this sounds fun, and am prepared to give it a try if I get some other enthusiastic responses. Steve   Return-Path: Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <18663-0@bells.cs.ucl.ac.uk>; Wed, 27 Feb 1991 19:38:53 +0000 Received: from mcsun.eu.net by kestrel.Ukc.AC.UK via EUnet with authorised SMTP id aa01106; 27 Feb 91 18:40 GMT Received: from inria.inria.fr by mcsun.EU.net with SMTP; id AA01810 (5.65a/CWI-2.75); Wed, 27 Feb 91 19:39:38 +0100 Received: by inria.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA00653; Wed, 27 Feb 91 19:38:54 +0100 (MET) Received: from cli53an.edf.fr by edfder1.edf.fr, Wed, 27 Feb 91 17:25:01 +0100 Received: from loghost by cli53an.edf.fr (4.0/SMI-4.0) id AA00815; Wed, 27 Feb 91 17:25:25 +0100 To: Mark Knopper Cc: Paul-Andre Pays , osi-ds@uk.ac.ucl.cs Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting In-Reply-To: Mark Knopper's message of 26 Feb 91 14:56:15 -0500. <9102261956.AA07835@merit.edu> Date: Wed, 27 Feb 91 17:25:25 +0100 Message-Id: <814.667671925@cli53an> From: Sylvain Langlois Sender: sylvain > > Steve reported that 19 out of 20 countries in COSINE are running > > X.500 pilots. The COSINE P2.1 pilot has been renamed as PARADISE, > > and has officially started. Its manager is David Goodman. ULCC > > has an operational facility to replace Giant Tortoise. Their plan > > is to support international pilots until the end of 1992. France > > has a research pilot based on quipu and also a commercial pilot > > based on Pizarro. Xtel and the Dutch PTT are involved in > > PARADISE. > > > > > As the coordinator of the french directory pilot, I am a little > bit surprised > by the above statement about France. > FYI one can say: > There is french pilot project named OPAX (Operation Pilote Aristote > X.500) under the ARistote association um> brella. > It consists of 2 parts: > . paradis: is the name of the "research" branch and for phase 1 > consists of 4 "academic" sites, with Pizarro sources. > this is really the french branch of PARADISE. > . eden: is the more "industrial" branch (though it consists of > research organisations) as it uses commercial products and > software house support. During phase 1 the software used > is UCOM-DIR from E3X (it is a commercial version of Pizarro). > Though Pizarro based at the begining, the pilot will open > to different vendor X.500 impolementations; Quipu, HP and Bull > products are planned within a few monthes. May I object that the French Unix User Group (AFUU) and the french Unix network (Fnet) are also running a pilot project (not only related to X500 facilities though) called Fnet-2G. One of the activities of this pilot is to investigate towards operationnal X500 services in the short term. I'm having serious connectivity (i.e security) problems running the Fnet-2G main DSA (QUIPU-based, cn=Brown Pelican) from where I actually am (i.e Electricite de France Research Center). I already contacted Steve and David about this. I also said that, if these conectivity problems could not come to an end by the end of March, the Brown Pelican DSA would be installed on another site. This activity is not connected to COSINE activities directly: goals maybe somewhat different. Could you please keep in mind that ARISTOTE is not covering all network activities in France. Thanks Sylvain ---------------- Sylvain Langlois "Dogmatic attachement to the supposed merits (sylvain@cli53an.edf.fr) of a particular structure hinders the search of an appropriate structure" (Robert Fripp)   Return-Path: Received: from Sun.com by bells.cs.ucl.ac.uk with SMTP inbound id <19168-0@bells.cs.ucl.ac.uk>; Thu, 28 Feb 1991 00:05:39 +0000 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA14260; Wed, 27 Feb 91 12:58:35 PST Received: from bush.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06472; Wed, 27 Feb 91 13:04:47 PST Received: by bush.Eng.Sun.COM (4.1/SMI-4.1) id AA19128; Wed, 27 Feb 91 12:58:32 PST Date: Wed, 27 Feb 91 12:58:32 PST From: berries@com.Sun.Eng (Barry Holroyd) Message-Id: <9102272058.AA19128@bush.Eng.Sun.COM> To: S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Subject: Re: Videoconference meeting of OSI-DS group Cc: J.Crowcroft@uk.ac.ucl.cs, j.cowan@uk.ac.ucl.cs Steve, I will attend, if I can. I may have scheduling conflicts (about half of March is already booked for me). Barry   Return-Path: Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17158-0@bells.cs.ucl.ac.uk>; Thu, 28 Feb 1991 10:55:12 +0000 To: Mark Knopper cc: osi-ds@uk.ac.ucl.cs Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting In-reply-to: Your message of Wed, 27 Feb 91 10:46:49 +0000. <930.667651609@UK.AC.UCL.CS> Date: Thu, 28 Feb 91 10:55:10 +0000 From: D.Goodman@uk.ac.ucl.cs > Can I clarify (accuracy) what I said: 19 out of 20 Cosine (European) > countries are represented in the Paradise project. Not all of these are > running pilots. I undrestood, but presumably explained poorly, the French > situation. Paul-Andre's message explains things nicely from the viewpoint > of the French pilot. > Steve Just for a little further clarification .... there are 20 countries contributing to the Eureka programme within which COSINE is project number 8. These countries are: EC 12 EFTA 6 Turkey, Yugoslavia 2 These projects work on a subscription basis and two of these countries have "dropped" from participation in COSINE (Turkey, Iceland) - leaving 18. However the CEC also considers itself in some respects to have nation status so you could say it is 19. David   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <14094-0@bells.cs.ucl.ac.uk>; Thu, 28 Feb 1991 20:42:54 +0000 Received: Thu, 28 Feb 91 15:43:33 EST from home.merit.edu by merit.edu (5.59/1.6) Received: by home.merit.edu (4.1/dumb-0.9) id AA06616; Thu, 28 Feb 91 15:43:31 EST Date: Thu, 28 Feb 91 15:43:31 EST From: mak@edu.merit Message-Id: <9102282043.AA06616@home.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting ------- Forwarded Message Received: Thu, 28 Feb 91 14:20:11 EST from crl.dec.com by merit.edu (5.59/1.6) Received: by crl.dec.com; id AA06089; Thu, 28 Feb 91 14:20:06 -0500 Received: by easynet.crl.dec.com; id AA20059; Thu, 28 Feb 91 14:15:39 -0500 Message-Id: <9102281915.AA20059@easynet.crl.dec.com> Received: from guiduk.enet; by crl.enet; Thu, 28 Feb 91 14:19:51 EST Date: Thu, 28 Feb 91 14:19:51 EST From: Steve Farowich To: mak@merit.edu Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting Mark, I was a little surprised... >>From: CRL::"mak@merit.edu" "Mark Knopper" 26-FEB-1991 13:07:52.98 >>To: Paul-Andre Pays >> Though Pizarro based at the begining, the pilot will open >> to different vendor X.500 impolementations; Quipu, HP and Bull >> products are planned within a few monthes. ... that no Digital products were planned. steve   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Fri, 1 Mar 1991 10:28:19 +0000 Date: Fri, 1 Mar 1991 10:28:19 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.985:01.02.91.10.28.19] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Fri, 1 Mar 1991 10:28:19 +0000) From: Paul-Andre Pays Message-ID: <9103010925.AA29586@mars.emse.fr> To: osi-ds@uk.ac.ucl.cs Subject: Re: Proposed Minutes... I am really sorry to be the indirect cause of the list "pollution": > From: mak@merit.edu > To: osi-ds@cs.ucl.ac.uk > ------- Forwarded Message > > From: Steve Farowich > To: mak@merit.edu > Subject: Re: Proposed Minutes of February 1991 OSI-DS Meeting > > Mark, > I was a little surprised... > > >>From: CRL::"mak@merit.edu" "Mark Knopper" 26-FEB-1991 13:07:52.98 > >>To: Paul-Andre Pays > >> Though Pizarro based at the begining, the pilot will open > >> to different vendor X.500 implementations; Quipu, HP and Bull > >> products are planned within a few monthes. > > .... that no Digital products were planned. > > steve > Why DEC people if they have to complain about the french pilot choices don't directly contact me? Is not that advertising? In any case it has nothing to do with the "Minutes". Regards, -- PAP   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <24979-0@bells.cs.ucl.ac.uk>; Fri, 1 Mar 1991 11:56:20 +0000 To: osi-ds@uk.ac.ucl.cs Subject: Messge from Alan Young Phone: +44-71-380-7294 Date: Fri, 01 Mar 91 11:56:18 +0000 Message-ID: <850.667828578@UK.AC.UCL.CS> From: Steve Kille First point: fixed by deleting the would. This is aligning to editing instructions from the meeting which I got wrong! Second point: Your option 3 was discounted at the meeting as unaccptable. I have noted it but disallowed it, so that this is clear. I agree with you that option 1 has some problems, and would not choose it. However, it has been agreed as valid. I have added a sentence noting the problem. The revised text for this section follows: \begin{enumerate} \item Refuse/block updates until the EDB is transferred. This may cause problems where the rate of update and transfer is high, as this may make update very difficult (for the manager). \item Create a new version of the EDB, whilst retaining the old EDB to complete the bulk transfer. \item Allow the update and fail subsequent transfer requests for the EDB. This option is noted, but is not a valid implementation of this specification, as it may cause both transfer failure and excessive waste of bandwidth. \end{enumerate} thanks for the comments Steve ------- Forwarded Message From: Alan Young To: s.kille@uk.ac.ucl.cs Subject: Replication & Distributed Operations Date: Fri, 01 Mar 91 09:05:51 +0000 [I suspect I should have copied this to the osi-ds list but I do not know the submission address.] Reading the Internet Draft "Replication and Distributed Operations extensions to provide an Internet Directory using X.500" of February 1991, I have a couple of points. Section 4, page 5, second bullet: there is a typo; ... "these operations would might require to access" .... Replication protocol (page 10, points 1/2). A third possibility is to allow the update and fail the replication continuation operation with EDBVersionError. I do not think that 1 is a good option given that under high levels of fanout and a large number of DSAs slaving off a single master (I understand that this is not necessarily the only model or even a good one but could easily become common practice) it could become very difficult to get updates through at all. Option 3 (introduced above) would suffer from a large number of failures during periods of high update rate, which could be common during setting up phases of the pilot and when regular updates would be most desirable. Thus option 2 seems much the most desirable. ------- End of Forwarded Message   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <7601-0@bells.cs.ucl.ac.uk>; Fri, 1 Mar 1991 17:37:20 +0000 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 01 Mar 91 17:37:19 +0000 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 15th February - Friday 1st March. Probes preformed from ULCC, UCL, STC, Brunel and by Mark Prior of Adelaide University. (Multiple addresses due to both old and new versions of the probe running) Bind Fail %age Best Worst Ave Address GB: False Cobra (Future Giant Tortoise) 14 0 100.00 1.0 3.6 1.60 Janet 25 7 72.00 0.8 30.3 8.04 Internet 14 4 71.43 3.1 8.4 4.99 IXI Giant Tortoise (Old Root, GB Master) 23 0 100.00 0.3 86.4 5.20 TCP 23 0 100.00 1.1 3.4 1.33 JANET 30 0 100.00 1.3 2.5 1.72 Janet 36 0 100.00 2.0 12.7 3.23 IXI 41 2 95.12 2.3 29.0 4.23 X121 23 2 91.30 2.1 4.6 2.35 UCL-X121 14 3 78.57 2.0 3.3 2.45 Janet 14 5 64.29 2.1 6.0 3.66 IXI 28 11 60.71 0.6 9.7 3.18 Internet 18 13 27.78 8.4 11.2 9.12 Internet 62 51 17.74 1.9 4.9 2.96 X121 106 106 0.00 0.0 0.0 0.00 Janet 53 53 0.00 0.0 0.0 0.00 IXI Vampire Bat (GB backup) 14 0 100.00 3.3 15.7 6.81 Janet 148 9 93.92 1.2 5.6 2.00 Janet 77 5 93.51 2.0 12.4 2.93 IXI 14 4 71.43 3.3 14.6 6.29 IXI 14 14 0.00 0.0 0.0 0.00 NS 23 23 0.00 0.0 0.0 0.00 realNS Maned Sloth (Edinburgh, DSA holding NRS info) 148 11 92.57 1.7 22.5 2.75 Janet 14 3 78.57 50.1 104.1 87.21 Janet Passionflower Leaf Beetle (GB Domain name information) 13 1 92.31 0.6 4.5 1.11 Internet 29 18 37.93 0.6 15.7 5.24 Internet 12 12 0.00 0.0 0.0 0.00 IXI 12 12 0.00 0.0 0.0 0.00 UCL-JANET 12 12 0.00 0.0 0.0 0.00 UCL-X121 14 14 0.00 - - - Janet 14 14 0.00 0.0 0.0 0.00 IXI 14 14 0.00 0.0 0.0 0.00 X121 Coypu (Thorn acces pt to quipu) 23 4 82.61 0.3 1.2 0.81 Local 23 4 82.61 0.3 6.5 1.32 TCP 23 4 82.61 1.0 1.9 1.19 JANET 23 5 78.26 2.1 2.5 2.15 X121 125 28 77.60 1.2 2505.3 29.70 Janet 77 21 72.73 2.5 16.6 3.93 X121 6 3 50.00 11.4 13.6 12.30 Internet 14 8 42.86 1.1 7.6 3.23 Local Ether 14 8 42.86 1.3 5.1 2.83 Janet 29 18 37.93 4.5 85.3 19.15 Internet DE: Puma (GMD/FOKUS) 14 0 100.00 7.9 22.7 10.14 Int-X.25 78 13 83.33 2.1 49.6 4.21 IXI 87 16 81.61 3.3 6.8 4.21 Int-X25 14 4 71.43 4.4 8.4 5.81 IXI 29 11 62.07 12.4 108.9 42.08 Internet 30 15 50.00 12.8 42.0 22.25 Internet 14 14 0.00 0.0 0.0 0.00 NS 24 24 0.00 0.0 0.0 0.00 realNS Margay (GMD/F3, DE backup) 87 6 93.10 3.1 37.6 4.61 Int-X25 78 7 91.03 2.1 52.1 4.12 IXI 14 2 85.71 7.5 19.5 12.38 Int-X.25 14 4 71.43 4.6 12.2 7.31 IXI 29 10 65.52 13.1 112.9 32.37 Internet 30 16 46.67 10.1 37.2 20.53 Internet NO: Boa Constrictor (Norway Backup) 87 3 96.55 2.5 19.0 5.87 Int-X25 76 3 96.05 3.3 56.6 7.29 IXI 15 1 93.33 4.7 153.3 27.46 Int-X.25 29 4 86.21 6.5 105.8 41.72 Internet 29 17 41.38 6.2 36.6 18.01 Internet 15 15 0.00 0.0 0.0 0.00 IXI Electric Eel (Norway Master) 85 4 95.29 3.1 13.8 4.65 Int-X25 14 1 92.86 4.4 18.5 8.38 Int-X.25 69 6 91.30 1.9 19.7 4.24 IXI 28 8 71.43 2.8 87.1 21.45 Internet 14 5 64.29 5.4 16.4 9.58 IXI 29 17 41.38 3.8 25.0 10.96 Internet 8 8 0.00 0.0 0.0 0.00 IXI CH: Condor (ETH Zurich) 14 1 92.86 5.3 20.0 8.32 Int-X.25 29 4 86.21 3.6 93.0 18.72 Internet 29 15 48.28 1.5 9.0 4.67 Internet 86 77 10.47 3.7 6.0 4.24 Int-X25 Chinchilla (Swiss Master) 29 3 89.66 9.4 112.5 26.27 Internet 29 15 48.28 2.2 15.4 5.12 Internet 14 14 0.00 - - - Int-X.25 86 86 0.00 0.0 0.0 0.00 Int-X25 AU: Anaconda (AU Master) 87 7 91.95 5.6 315.8 14.86 Int-X25 15 4 73.33 14.6 113.4 58.23 Int-X.25 30 14 53.33 1.2 17.9 5.74 Internet 29 14 51.72 4.0 42.9 8.36 Internet Bush Dog (master for AU (phony)) 30 16 46.67 1.5 111.9 16.07 Internet 29 17 41.38 6.0 17.6 10.43 Internet NL: Hornero (NL Master) 98 8 91.84 2.7 11.9 4.80 X121 29 15 48.28 2.0 31.2 11.04 Internet 28 19 32.14 7.8 118.5 27.94 Internet Agouti (NL Slave) 29 29 0.00 0.0 0.0 0.00 Internet 30 30 0.00 - - - Internet IT swdsa (IT Master) 94 13 86.17 6.1 16.0 7.74 \"SWDSA\"/\"1\"/X121 ES: Cayman (Madrid Uni.) 87 15 82.76 4.4 22.2 7.68 Int-X25 77 14 81.82 2.1 12.2 4.38 IXI 15 3 80.00 9.4 31.2 19.30 Int-X.25 30 7 76.67 12.8 118.0 41.59 Internet 15 6 60.00 6.9 26.5 14.23 IXI 29 14 51.72 2.8 68.4 18.33 Internet Iguana (ES Master. Programa IRIS) 14 6 57.14 12.7 38.6 26.90 IXI 14 6 57.14 7.1 33.7 21.15 Int-X.25 86 41 52.33 4.8 18.6 9.08 Int-X25 28 15 46.43 4.6 40.9 19.99 Internet 77 49 36.36 2.4 46.4 8.40 IXI 30 23 23.33 1.9 10.8 5.14 Internet CA: Pangolin (Northern Telecom Master) 28 7 75.00 4.5 24.1 11.01 Internet 30 14 53.33 2.5 15.5 7.56 Internet 14 14 0.00 0.0 0.0 0.00 NS 24 24 0.00 0.0 0.0 0.00 realNS Wayne Gretzky (Canada Master) 30 17 43.33 1.3 15.6 7.58 Internet 29 17 41.38 3.8 96.3 28.88 Internet US: Fruit Bat (US@l=NY master) 29 8 72.41 3.3 19.7 9.04 Internet 29 20 31.03 1.2 14.2 6.43 Internet Alpaca (US master) 30 9 70.00 2.4 83.2 10.87 Internet 29 15 48.28 1.0 9.7 4.25 Internet 83 69 16.87 5.2 6.5 5.76 Int-X25 4 4 0.00 - - - Int-X.25 Giant Anteater 27 15 44.44 3.1 10.3 6.79 Internet 29 18 37.93 1.4 9.8 5.89 Internet FI: Jaguar (Finland Master) 29 12 58.62 9.3 107.1 32.98 Internet 30 14 53.33 2.3 96.7 24.01 Internet 101 48 52.48 4.0 231.7 12.78 X121 5 5 0.00 0.0 0.0 0.00 NS SE: Hummingbird (Sweden Master) 28 14 50.00 10.5 108.8 37.86 Internet 100 58 42.00 3.7 32.7 7.28 X121 29 21 27.59 2.3 38.5 15.86 Internet DK Axolotl (DK master) 29 19 34.48 21.5 103.8 47.39 Internet 29 19 34.48 5.3 27.5 12.90 Internet IS: Elephant Seal (IS Master) 29 25 13.79 22.2 55.4 40.92 Internet 29 29 0.00 0.0 0.0 0.00 Internet   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <3096-0@bells.cs.ucl.ac.uk>; Sun, 3 Mar 1991 02:38:19 +0000 Received: Sat, 2 Mar 91 21:38:55 EST from home.merit.edu by merit.edu (5.59/1.6) Received: by home.merit.edu (4.1/dumb-0.9) id AA08070; Sat, 2 Mar 91 21:38:52 EST Date: Sat, 2 Mar 91 21:38:52 EST From: mak@edu.merit Message-Id: <9103030238.AA08070@home.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: video technology Hi. Could someone tell me what kind of video transmission would be used on a video conference as several people have proposed for this group? It's possible that U-Michigan has some facilities but there are questions about what type of video. Mark   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13093-0@bells.cs.ucl.ac.uk>; Mon, 4 Mar 1991 15:54:39 +0000 Replied: Mon, 04 Mar 91 15:17:15 +0000 Replied: Jon Crowcroft Return-Path: Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11455-0@bells.cs.ucl.ac.uk>; Mon, 4 Mar 1991 15:13:03 +0000 To: mak@edu.merit cc: j.cowan@uk.ac.ucl.cs, Steve Kille Subject: video technology In-reply-to: Your message of Mon, 04 Mar 91 14:36:59 +0000. <1833.668097419@UK.AC.UCL.CS> Date: Mon, 04 Mar 91 15:12:58 +0000 From: Jon Crowcroft Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Mon, 04 Mar 91 15:54:32 +0000 Resent-Message-ID: <2465.668102072@UK.AC.UCL.CS> Resent-From: Steve Kille Mark, as per steve k's request: we use ST (not ST-II) and our connection is via BBN to the Terrestrial Wideband Net - i dont believe anyonenot on this net is currently reachable via this video system, since this is old ST (not above IP, but dual routed with IP) ... jon crowcroft >------- Forwarded Message >To: osi-ds@uk.ac.ucl.cs >Subject: video technology >Date: Sat, 2 Mar 91 21:38:52 EST >Hi. Could someone tell me what kind of video transmission would >be used on a video conference as several people have proposed >for this group? It's possible that U-Michigan has some facilities >but there are questions about what type of video. > Mark >------- End of Forwarded Message jon   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <29186-0@bells.cs.ucl.ac.uk>; Wed, 6 Mar 1991 19:55:30 +0000 Received: Wed, 6 Mar 91 14:41:25 EST by mazatzal.merit.edu (5.51/1.6) Date: Wed, 6 Mar 91 14:41:25 EST From: Chris Weider Message-Id: <9103061941.AA18129@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: DISI Working Group meeting... Cc: disi@edu.merit Since this appearantly hasn't made it onto the official IETF agenda yet: The first meeting of the DISI working group (Directory Information Services (pilot) Infrastructure) will be during the User Services Area meeting on Monday Afternoon in St. Louis. Joyce Reynolds has graciously given me 1 1/2 hours during that meeting. This Working group lies in both the User Services and the OSI Integration area, and has the blessing of both. Meet me in St. Loooie!! Chris Weider MERIT   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <6606-0@bells.cs.ucl.ac.uk>; Thu, 7 Mar 1991 21:52:51 +0000 Received: Thu, 7 Mar 91 16:49:46 EST by mazatzal.merit.edu (5.51/1.6) Date: Thu, 7 Mar 91 16:49:46 EST From: Chris Weider Message-Id: <9103072149.AA19261@mazatzal.merit.edu> To: rlang@com.SRI.NISC Subject: Re: object and attribute descriptions Cc: osi-ds@uk.ac.ucl.cs Here it is, Ruth.... Sorry it's so late. I've been out the past week with an emergency.... :( 1.2 New attributes for this information New attributes used for this information are ipNetworkNumber; a string containing the network number. whoisIdent; a string containing the NIC handle of the contact for the network or AS. ipNetworkName; a string containing the name of the network as registered with the NIC. asNumber; a string containing the AS number. The ASN.1 descriptions of these attributes are on the next page. ^L __ __ __ __ __ ipNetworkNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipnetnum)) ::= { meritAttributeType.7 } ub-ipnetnum INTEGER ::= 20 whoisIdent ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-whois)) ::= { meritAttributeType.8 } ub-whois INTEGER ::= 15 ipNetworkName ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipNetName)) ::= { meritAttributeType.9 } ub-ipNetName INTEGER ::= 256 asNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-asnum)) ::= { meritAttributeType.10 } ub-asnum INTEGER ::= 20 _______________________________________________________________________________ 1.3 New object classes There are two new object classes to hold this information; siteContact, and asSiteContact, which are detailed in ASN.1 below. The siteContact object class is used to hold information about network site contacts, while the asSiteContact object class is used to hold information about site contacts for Autonomous Systems. _______________________________________________________________________________ siteContact OBJECT-CLASS SUBCLASS OF pilotPerson MUST CONTAIN { ipNetworkNumber } MAY CONTAIN { whoisIdent, ipNetworkName } ::= { meritObjectClass.3 } asSiteContact OBJECT-CLASS SUBCLASS OF pilotPerson MUST CONTAIN { asNumber } MAY CONTAINS { whoisIdent } ::= { meritObjectClass.4 } _______________________________________________________________________________ ASN.1 definitions for new object classes.   Return-Path: Received: from cheetah.ca.psi.com by bells.cs.ucl.ac.uk with SMTP inbound id <3072-0@bells.cs.ucl.ac.uk>; Fri, 8 Mar 1991 01:29:33 +0000 Received: from localhost by cheetah.ca.psi.com at Thu, 7 Mar 91 17:24:11 -0800. (5.61.14/XIDA-1.2.8.34) id AA08469 for osi-ds@cs.ucl.ac.uk via SMTP To: clw@edu.merit (Chris Weider) Cc: rlang@com.sri.nisc, osi-ds@uk.ac.ucl.cs Reply-To: osi-ds@uk.ac.ucl.cs Subject: Re: object and attribute descriptions In-Reply-To: Your message of Thu, 07 Mar 91 16:49:46 -0500. <9103072149.AA19261@mazatzal.merit.edu> Date: Thu, 07 Mar 91 17:24:08 -0800 Message-Id: <8467.668395448@cheetah.ca.psi.com> From: Marshall Rose 1. How do you envision naming for objects of class siteContact and asSiteContact? (What do RDNs look like?) 2. Shouldn't ub-ipnetnum be 15: "255.255.255.255" looks like 15 octets to me. 3. Are ipNetworkNumbers always of the form a.b.c.d, or can the hostnum pargs be left off (e.g., just "a" for a class A net). /mtr   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <2087-0@bells.cs.ucl.ac.uk>; Fri, 8 Mar 1991 20:15:10 +0000 Received: Fri, 8 Mar 91 15:12:00 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 8 Mar 91 15:12:00 EST From: Chris Weider Message-Id: <9103082012.AA20434@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Re: object and attribute descriptions >1. How do you envision naming for objects of class siteContact and > asSiteContact? (What do RDNs look like?) >2. Shouldn't ub-ipnetnum be 15: "255.255.255.255" looks like 15 octets > to me. >3. Are ipNetworkNumbers always of the form a.b.c.d, or can the hostnum >pargs be left off (e.g., just "a" for a class A net). 1. The RDNs for siteContact and asSiteContact look like o=Internet@ou=Site Contacts@ipNetworkNumber=blah.blah.blah or o=Internet@ou=Site Contacts@asNumber=blah.blah.blah 2. Yes, ub-ipnetnum should be 15. This will be changed in the document. Thanks for pointing this out.... 3. The program that generates the EDB is smart enough to build RDNs that ar in "network" form, i.e., you can do an "xwhois -net 35" or an "xwhois -net 128.140" and the search will find an exact match. Chris   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <22038-0@bells.cs.ucl.ac.uk>; Fri, 8 Mar 1991 22:20:07 +0000 Received: Fri, 8 Mar 91 17:16:44 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 8 Mar 91 17:16:44 EST From: Chris Weider Message-Id: <9103082216.AA20676@mazatzal.merit.edu> To: Tim.Howes@edu.umich.cc.terminator, clw@edu.merit Subject: Re: object and attribute descriptions Cc: osi-ds@uk.ac.ucl.cs Tim: I think that if we change something, it would be to ou=Networks... The way the NOC uses these, they need to look up networks, which then have primary, secondary, and tertiary technical contacts. I think we will be angling to expanding the Site Contacts to something truly like Networks with lots of cross references..... Chris   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <21223-0@bells.cs.ucl.ac.uk>; Fri, 8 Mar 1991 22:12:37 +0000 Received: from terminator.cc.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA28188; Fri, 8 Mar 91 17:11:32 -0500 Message-Id: <9103082211.AA28188@terminator.cc.umich.edu> To: Chris Weider Cc: osi-ds@uk.ac.ucl.cs Subject: Re: object and attribute descriptions In-Reply-To: Your message of "Fri, 08 Mar 91 15:12:00 EST." <9103082012.AA20434@mazatzal.merit.edu> Date: Fri, 08 Mar 91 17:11:27 -0500 From: Tim Howes > >1. How do you envision naming for objects of class siteContact and > > asSiteContact? (What do RDNs look like?) > > 1. The RDNs for siteContact and asSiteContact look like > o=Internet@ou=Site Contacts@ipNetworkNumber=blah.blah.blah > > or > o=Internet@ou=Site Contacts@asNumber=blah.blah.blah An internet site contact is a person, not a network, right? It makes more sense to me to have the person's name as the rdn, and then list networks for which they are responsible as a multi-valued ipNetworkNumber attribute. Either that, or change the ou=Site Contacts to something like ou=Networks or whatever. -- Tim   Return-Path: Received: from ws10.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <8940-0@bells.cs.ucl.ac.uk>; Sat, 9 Mar 1991 06:15:15 +0000 Received: by ws10.nisc.sri.com (5.64/SRI-NISC1.1) id AA05134; Fri, 8 Mar 91 21:55:19 -0800 Message-Id: <9103090555.AA05134@ws10.nisc.sri.com> To: clw@edu.merit Cc: osi-ds@uk.ac.ucl.cs, klh@com.SRI.NISC, rlang@com.SRI.NISC Subject: Re: object and attribute descriptions Date: Fri, 08 Mar 91 21:55:16 PST From: Ruth Lang Chris, I haven't had a chance to thoroughly read the object and attribute descriptions you mailed, but I wanted to address the recent exchange between you and Tim Howes. Indeed, a site contact is a person and there is a relationship between the person, their role, and the network they're responsible for. These issues have in the past been addressed by WHOIS. As part of the FOX project, Ken Harrenstien and I have begun work to convert WHOIS to X.500 (maintain a partial replicate in X.500). We will send some initial ideas to this group for comment by or soon after the 15th; after the FOX participants, including Merit, have had a chance to respond. In general, our plan is to represent WHOIS information in X.500 as directly as possible. We envisage something like @o=Internet@ou=WHOIS under which will be @cn=Individual, Computer, Network, Domain, Autonomous System, Organization, and Group. More details in our note. This registration information will be centralized in one part of the DIT. The real challenge in front of us is determining how to effectively distribute and manage both responsibility and information via the Directory. Regards, Ruth   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18877-0@bells.cs.ucl.ac.uk>; Mon, 11 Mar 1991 09:27:54 +0000 To: osi-ds@uk.ac.ucl.cs Subject: late documents Phone: +44-71-380-7294 Date: Mon, 11 Mar 91 09:27:53 +0000 Message-ID: <512.668683673@UK.AC.UCL.CS> From: Steve Kille We agreed at the last meeting to have all the documen drafts by March 7th. This has not happened. Messrs Kille, Barker, Yee, and Weider are all late in delivering their documents. Could the other three of you give me some realistic estimates of when we will see the output? Steve   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <3882-0@bells.cs.ucl.ac.uk>; Mon, 11 Mar 1991 14:17:13 +0000 Received: Mon, 11 Mar 91 09:14:03 EST by mazatzal.merit.edu (5.51/1.6) Date: Mon, 11 Mar 91 09:14:03 EST From: Chris Weider Message-Id: <9103111414.AA22765@mazatzal.merit.edu> To: S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Subject: Re: late documents Steve: Please find enclosed my draft document. Because of editorial haggling, it wasn't ready until Sat March 9. It will be sent off to the RFC editor today also.... Chris Weider Directory Information Services (pilot) Chris Weider Infrastructure Working Group Mark Knopper INTERNET--DRAFT MERIT March 1991 Internet Network Infrastructure Information In X.500 Status of this Memo As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory information, it was percieved that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. The first section of this paper describes the schema used to contain this information; the second section describes the DIT structure built for this information. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group disi@merit.edu. INTERNET--DRAFT Network Infrastructure Information March 1991 SECTION 1: PRELIMINARIES 1.1 Introduction Information related to the Interent Network Infrastructure is stored and created by a number of different organizations, such as the Network Information Center (NIC), the Internet Assigned Numbers Authority (IANA), and the NSFNet Network Operations Center (NOC). The information is in general "mastered" (stored and maintained) by these organizations on a centralized basis, i.e. there is a single place to look for a definitive list of entries for these categories. This has worked will in the past but given the tremendous growth of the Internet and its number of users and networks, it is essential that a distributed scheme be used. An example of where this kind of scheme has worked is the domain name system for host naming and addressing information. The X.500 Directory standard seems to be an ideal technology for implementing this distributed method of managing network infrastructure information. X.500 allows distributed ownership of different parts of the global Directory Information Tree, and with replication can provide this information on a query basis to users rapidly. The access control and security capabilities exist in the current standards and implementation and also are being developed by IETF working groups and implementors. A worldwide pilot project involving over 20 countries is in progress, primarily for the purpose of making "white pages" or people-oriented information available. The Field Operational X.500 (FOX) project is a funded project involving several US organizations who are committed to advancing the X.500 projects to an operational status. This RFC proposes a way to get started on the implementation of an X.500 directory of network infrastructure information. Eventually all of the data maintained by these various organizations should be entered into the X.500 systems but there is some information that has already been entered on a trial basis and this can be expanded to include a more complete and useful information set. Topics covered in this RFC include the schema used for representing new network-related opject types, the preliminary design of the Directory Information Tree structure used at present, and a discussion of possible future directions and possible schema. 1.2 Information to be incorporated The Site Contacts information that is being loaded into the MERIT DSA is being generated weekly by the SRI NIC, and is output into two text files NETINFO:NETWORK-CONTACTS.TXT and NETINFO:ASN.TXT, both of which are available via anonymous FTP. Representative entries from both files are on the next page: INTERNET--DRAFT Network Infrastructure Information March 1991 __ __ __ __ __ 3.0.0.0 GE-INTERNET Bradt, James E. (JEB50) bradt@CRD.GE.COM (518) 387-7170 Representative entry from the Network-Contacts file __ __ __ __ __ ASN Numbers 1 The BBN Core Gateways [MB] Representative entry from the ASN.TXT file _______________________________________________________________________________ SECTION 2: NEW SCHEMA 2.1 Evolution of schema design In the initial phases of incorporating this information into the Directory, we constrained ourselves to working with object classes that had already been defined. This forced some highly nonintuitive choices for mapping the data into the object classes, but it did make the information widely available. In choosing the object class schema we did for the current implementation of the data, we wanted to contain the new NIC information and still leave room for the contact information. Marshall Rose suggested that we make object classes that were subclasses of the pilotPerson object class, which fits the bill admirably for the limited amount of data which we are incorporating, but will limit us as we try to load all the NIC data into the Directory. 2.2 New attributes for this information New attributes used for this information are ipNetworkNumber; a string containing the network number. whoisIdent; a string containing the NIC handle of the contact for the network or AS. ipNetworkName; a string containing the name of the network as registered with the NIC. asNumber; a string containing the AS number. The ASN.1 descriptions of these attributes are on the next page. INTERNET--DRAFT Network Infrastructure Information March 1991 __ __ __ __ __ ipNetworkNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipnetnum)) ::= { meritAttributeType.7 } ub-ipnetnum INTEGER ::= 15 whoisIdent ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-whois)) ::= { meritAttributeType.8 } ub-whois INTEGER ::= 15 ipNetworkName ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipNetName)) ::= { meritAttributeType.9 } ub-ipNetName INTEGER ::= 256 asNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-asnum)) ::= { meritAttributeType.10 } ub-asnum INTEGER ::= 20 _______________________________________________________________________________ ASN.1 definitions for new attributes. INTERNET--DRAFT Network Infrastructure Information March 1991 2.3 New object classes There are two new object classes to hold this information; siteContact, and asSiteContact, which are detailed in ASN.1 below. The siteContact object class is used to hold information about network site contacts, while the asSiteContact object class is used to hold information about site contacts for Autonomous Systems. _______________________________________________________________________________ siteContact OBJECT-CLASS SUBCLASS OF pilotPerson MUST CONTAIN { ipNetworkNumber } MAY CONTAIN { whoisIdent, ipNetworkName } ::= { meritObjectClass.3 } asSiteContact OBJECT-CLASS SUBCLASS OF pilotPerson MUST CONTAIN { asNumber } MAY CONTAINS { whoisIdent } ::= { meritObjectClass.4 } _______________________________________________________________________________ ASN.1 definitions for new object classes. SECTION 3: Design of the Directory Information Tree and Future Work 3.1 Current DIT organization The Site Contacts information is currently residing under the @o=Internet@ou=Site Contacts portion of the DIT. An RDN for a siteContact for a given network would be "@o=Internet@ou=Site Contacts@ipNetworkNumber=35" while an RDN for a asSiteContact would be "@o=Internet@ou=Site Contacts @asNumber=267". There are two additional nodes under o=Interent, one for a directory of RFC documents and another for FYI documents. Merit is working on adding several other nodes in this position to hold data on network topology utilized by the NSFNet NOC and the mid-level networks. These include NSFNet-NSS (an entry for each NSFNet router with machine and contact information), HOSTS (a directory containing a list of major IP hosts known to the NOC for purposes of running traceroute, ping and similar tools to determine reachability), and AD (administrative domain information, including constituent autonomous systems for each AD and contact information). Finally Merit is also working on a schema for an NSAP directory for OSI CLNS addresses. The Site Contacts portion is updated regularly and is used by the NSFNet NOC. Currently it holds the set of approximately 20,000 network numbers which have been assigned by the NIC, although the number of EDB entries is on the order of 2,500 because the networks with unconnected status have been allocated in large contiguous blocks, and each block is stored in a single EDB entry with a multi-valued RDN for searching purposes. It also holds the >1000 assigned Autonomous System numbers. The structure of the Site Contacts is essentially flat, i.e., each network and AS number resides directly under the INTERNET--DRAFT Network Infrastructure Information March 1991 ou=Site Contacts entry, with no heirarchy. This flat organization does not scale well for a large number of networks. Another problem is that variable access control is not used which means that the contact people may not update the information themselves. The information remains under control of a central organization (still the NIC since Merit downloads their file into the X.500 directory regularly). Yet another problem is that the personal information on the contacts is stored separately in Site Contacts even in the case where the person's organization has an entry for her in their White Pages project DSA. Finally, the sheer number of networks in the contacts DIT may get quite large as new numbers are assigned, and previously assigned numbers become connected. This will undoubtedly cause problems with the quipu implementation and create replication difficulties. 3.2 Future DIT Organization and Plans Several useful suggestions have been proposed by IETF OSI-DS members. Ignoring the number of networks problem for a moment, it would seem useful to allow pointers to additional information in other parts of the global DIT when that is available. If an organization is a functioning participant in a White Pages Project, it would make sense to allow that organization to register and maintain their own entry in their DIT for contact and technical data on that network. It will probably make sense to allocate blocks of network numbers to regional authorities such as the US mid-level networks or European networking agencies. These activities can be done soon to allow the distributed aspects of X.500 to be enjoyed tight away. All that is necessary is for the reliability of the various DSAs to be improved. Another suggestion for the network number organization was given in the "Domains and X.500" Internet Draft [Kil89]. He compares the problem of representing network number information to the in-addr domain in the DNS. In that paper it is proposed to represent mailbox and domain-related-object information in X.500, and network information could be added in to this activity. This work has begun on an experimental basis, allowing browsing through the DNS information for example. It will require experimentation and a much more complete population of the directory entries before this can be used successfully for site contact information. The UCL staff are looking into this. As for future work, the SRI group, as participants in the FOX project, will be working on entering all of the WHOIS information into X.500. The other participants are ISI, PSI, and Merit. This will no doubt involve quite a bit of effort and many revisions to the schema design and DIT. The FOX project will be producing monthly reports, to be included in the Internet Monthly Reports as well as to be distributed separately for those who are interested. In addition it is expected that further internet drafts and RFCs will be produced to inform others on this progress. INTERNET--DRAFT Network Infrastructure Information March 1991 SECTION 4: WHO WE ARE 4.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109 (313) 936-2090 (Chris) (313) 763-6061 (Mark) SECTION 5: REFERENCES [Kil89] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College Lon- don, May 1989. Also Internet Draft: DRAFT-UCL-KILLE- X500DOMAINS-00.PS   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <10504-0@bells.cs.ucl.ac.uk>; Mon, 11 Mar 1991 18:29:07 +0000 Received: Mon, 11 Mar 91 13:28:50 EST from home.merit.edu by merit.edu (5.59/1.6) Received: by home.merit.edu (4.1/dumb-0.9) id AA05486; Mon, 11 Mar 91 13:28:48 EST From: mak@edu.merit Message-Id: <9103111828.AA05486@home.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Second draft of OID RFC.... Date: Mon, 11 Mar 91 13:28:48 -0500 This is the latest draft of our internet draft. Chris is discussing this at the DISI working group today. Any comments from this group would certainly be welcome. I think this is what Chris agreed to write by March 7 but one can't always be certain. Mark ------- Forwarded Message Received: Fri, 8 Mar 91 18:12:02 EST from mazatzal.merit.edu by merit.edu (5.59/1.6) Received: Fri, 8 Mar 91 18:08:53 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 8 Mar 91 18:08:53 EST From: Chris Weider Message-Id: <9103082308.AA20768@mazatzal.merit.edu> To: mak@merit.edu Subject: Second draft of OID RFC.... Directory Information Services (pilot) Chris Weider Infrastructure Working Group Mark Knopper INTERNET--DRAFT MERIT March 1991 Internet Network Infrastructure Information In X.500 Status of this Memo As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory information, it was percieved that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. The first section of this paper describes the schema used to contain this information; the second section describes the DIT structure built for this information. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group disi@merit.edu. INTERNET--DRAFT Network Infrastructure Information March 1991 SECTION 1: PRELIMINARIES 1.1 Introduction Information related to the Interent Network Infrastructure is stored and created by a number of different organizations, such as the Network Information Center (NIC), the Internet Assigned Numbers Authority (IANA), and the NSFNet Network Operations Center (NOC). The information is in general "mastered" (stored and maintained) by these organizations on a centralized basis, i.e. there is a single place to look for a definitive list of entries for these categories. This has worked will in the past but given the tremendous growth of the Internet and its number of users and networks, it is essential that a distributed scheme be used. An example of where this kind of scheme has worked is the domain name system for host naming and addressing information. The X.500 Directory standard seems to be an ideal technology for implementing this distributed method of managing network infrastructure information. X.500 allows distributed ownership of different parts of the global Directory Information Tree, and with replication can provide this information on a query basis to users rapidly. The access control and security capabilities exist in the current standards and implementation and also are being developed by IETF working groups and implementors. A worldwide pilot project involving over 20 countries is in progress, primarily for the purpose of making "white pages" or people-oriented information available. The Field Operational X.500 (FOX) project is a funded project involving several US organizations who are committed to advancing the X.500 projects to an operational status. This RFC proposes a way to get started on the implementation of an X.500 directory of network infrastructure information. Eventually all of the data maintained by these various organizations should be entered into the X.500 systems but there is some information that has already been entered on a trial basis and this can be expanded to include a more complete and useful information set. Topics covered in this RFC include the schema used for representing new network-related opject types, the preliminary design of the Directory Information Tree structure used at present, and a discussion of possible future directions and possible schema. 1.2 Information to be incorporated The Site Contacts information that is being loaded into the MERIT DSA is being generated weekly by the SRI NIC, and is output into two text files NETINFO:NETWORK-CONTACTS.TXT and NETINFO:ASN.TXT, both of which are available via anonymous FTP. Representative entries from both files are on the next page: INTERNET--DRAFT Network Infrastructure Information March 1991 __ __ __ __ __ 3.0.0.0 GE-INTERNET Bradt, James E. (JEB50) bradt@CRD.GE.COM (518) 387-7170 Representative entry from the Network-Contacts file __ __ __ __ __ ASN Numbers 1 The BBN Core Gateways [MB] Representative entry from the ASN.TXT file _______________________________________________________________________________ SECTION 2: NEW SCHEMA 2.1 Evolution of schema design In the initial phases of incorporating this information into the Directory, we constrained ourselves to working with object classes that had already been defined. This forced some highly nonintuitive choices for mapping the data into the object classes, but it did make the information widely available. In choosing the object class schema we did for the current implementation of the data, we wanted to contain the new NIC information and still leave room for the contact information. Marshall Rose suggested that we make object classes that were subclasses of the pilotPerson object class, which fits the bill admirably for the limited amount of data which we are incorporating, but will limit us as we try to load all the NIC data into the Directory. 2.2 New attributes for this information New attributes used for this information are ipNetworkNumber; a string containing the network number. whoisIdent; a string containing the NIC handle of the contact for the network or AS. ipNetworkName; a string containing the name of the network as registered with the NIC. asNumber; a string containing the AS number. The ASN.1 descriptions of these attributes are on the next page. INTERNET--DRAFT Network Infrastructure Information March 1991 __ __ __ __ __ ipNetworkNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipnetnum)) ::= { meritAttributeType.7 } ub-ipnetnum INTEGER ::= 15 whoisIdent ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-whois)) ::= { meritAttributeType.8 } ub-whois INTEGER ::= 15 ipNetworkName ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipNetName)) ::= { meritAttributeType.9 } ub-ipNetName INTEGER ::= 256 asNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-asnum)) ::= { meritAttributeType.10 } ub-asnum INTEGER ::= 20 _______________________________________________________________________________ ASN.1 definitions for new attributes. INTERNET--DRAFT Network Infrastructure Information March 1991 2.3 New object classes There are two new object classes to hold this information; siteContact, and asSiteContact, which are detailed in ASN.1 below. The siteContact object class is used to hold information about network site contacts, while the asSiteContact object class is used to hold information about site contacts for Autonomous Systems. _______________________________________________________________________________ siteContact OBJECT-CLASS SUBCLASS OF pilotPerson MUST CONTAIN { ipNetworkNumber } MAY CONTAIN { whoisIdent, ipNetworkName } ::= { meritObjectClass.3 } asSiteContact OBJECT-CLASS SUBCLASS OF pilotPerson MUST CONTAIN { asNumber } MAY CONTAINS { whoisIdent } ::= { meritObjectClass.4 } _______________________________________________________________________________ ASN.1 definitions for new object classes. SECTION 3: Design of the Directory Information Tree and Future Work 3.1 Current DIT organization The Site Contacts information is currently residing under the @o=Internet@ou=Site Contacts portion of the DIT. An RDN for a siteContact for a given network would be "@o=Internet@ou=Site Contacts@ipNetworkNumber=35" while an RDN for a asSiteContact would be "@o=Internet@ou=Site Contacts @asNumber=267". There are two additional nodes under o=Interent, one for a directory of RFC documents and another for FYI documents. Merit is working on adding several other nodes in this position to hold data on network topology utilized by the NSFNet NOC and the mid-level networks. These include NSFNet-NSS (an entry for each NSFNet router with machine and contact information), HOSTS (a directory containing a list of major IP hosts known to the NOC for purposes of running traceroute, ping and similar tools to determine reachability), and AD (administrative domain information, including constituent autonomous systems for each AD and contact information). Finally Merit is also working on a schema for an NSAP directory for OSI CLNS addresses. The Site Contacts portion is updated regularly and is used by the NSFNet NOC. Currently it holds the set of approximately 20,000 network numbers which have been assigned by the NIC, although the number of EDB entries is on the order of 2,500 because the networks with unconnected status have been allocated in large contiguous blocks, and each block is stored in a single EDB entry with a multi-valued RDN for searching purposes. It also holds the >1000 assigned Autonomous System numbers. The structure of the Site Contacts is essentially flat, i.e., each network and AS number resides directly under the INTERNET--DRAFT Network Infrastructure Information March 1991 ou=Site Contacts entry, with no heirarchy. This flat organization does not scale well for a large number of networks. Another problem is that variable access control is not used which means that the contact people may not update the information themselves. The information remains under control of a central organization (still the NIC since Merit downloads their file into the X.500 directory regularly). Yet another problem is that the personal information on the contacts is stored separately in Site Contacts even in the case where the person's organization has an entry for her in their White Pages project DSA. Finally, the sheer number of networks in the contacts DIT may get quite large as new numbers are assigned, and previously assigned numbers become connected. This will undoubtedly cause problems with the quipu implementation and create replication difficulties. 3.2 Future DIT Organization and Plans Several useful suggestions have been proposed by IETF OSI-DS members. Ignoring the number of networks problem for a moment, it would seem useful to allow pointers to additional information in other parts of the global DIT when that is available. If an organization is a functioning participant in a White Pages Project, it would make sense to allow that organization to register and maintain their own entry in their DIT for contact and technical data on that network. It will probably make sense to allocate blocks of network numbers to regional authorities such as the US mid-level networks or European networking agencies. These activities can be done soon to allow the distributed aspects of X.500 to be enjoyed tight away. All that is necessary is for the reliability of the various DSAs to be improved. Another suggestion for the network number organization was given in the "Domains and X.500" Internet Draft [Kil89]. He compares the problem of representing network number information to the in-addr domain in the DNS. In that paper it is proposed to represent mailbox and domain-related-object information in X.500, and network information could be added in to this activity. This work has begun on an experimental basis, allowing browsing through the DNS information for example. It will require experimentation and a much more complete population of the directory entries before this can be used successfully for site contact information. The UCL staff are looking into this. As for future work, the SRI group, as participants in the FOX project, will be working on entering all of the WHOIS information into X.500. The other participants are ISI, PSI, and Merit. This will no doubt involve quite a bit of effort and many revisions to the schema design and DIT. The FOX project will be producing monthly reports, to be included in the Internet Monthly Reports as well as to be distributed separately for those who are interested. In addition it is expected that further internet drafts and RFCs will be produced to inform others on this progress. INTERNET--DRAFT Network Infrastructure Information March 1991 SECTION 4: WHO WE ARE 4.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109 (313) 936-2090 (Chris) (313) 763-6061 (Mark) SECTION 5: REFERENCES [Kil89] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College Lon- don, May 1989. Also Internet Draft: DRAFT-UCL-KILLE- X500DOMAINS-00.PS ------- End of Forwarded Message   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <8919-0@bells.cs.ucl.ac.uk>; Mon, 11 Mar 1991 23:31:55 +0000 Received: from cheetah.ca.psi.com by sun2.nsfnet-relay.ac.uk with SMTP inbound id <22076-0@sun2.nsfnet-relay.ac.uk>; Mon, 11 Mar 1991 18:32:29 +0000 Received: from localhost by cheetah.ca.psi.com at Mon, 11 Mar 91 10:00:17 -0800. (5.61.14/XIDA-1.2.8.34) id AA06910 for osi-ds@cs.ucl.ac.uk via SMTP To: clw@edu.merit (Chris Weider) Cc: S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Reply-To: osi-ds@uk.ac.ucl.cs Subject: Re: late documents In-Reply-To: Your message of Mon, 11 Mar 91 09:14:03 -0500. <9103111414.AA22765@mazatzal.merit.edu> Date: Mon, 11 Mar 91 10:00:15 -0800 Message-Id: <6908.668714415@cheetah.ca.psi.com> From: Marshall Rose Section 2.1: you probably don't have to cite me by name. (-: Section 2.2: in your ASN.1 figure, OIDs should be given as { meritAttributeType 7 } not { meritAttributeType.7 } Section 2.3: ditto comment for Section 2.2 Section 3.1: I think the short-term model should be that FOX is simply exporting the site-contact/as-number info into X.500 from some other source. This mean that updates, etc., still have to go to the primary source (i.e., the NIC). However, in the primary source, someone should add a new field which means "X.500 see also", so that someone both in the Directory and in the site-contact/as-number DB can have a pointer. In the corresondent X.500 entry for the site-contact/as-number, you sould have seeAlso= <> Until such time as the primary source is distributed (or mastered by X.500), you probably don't want to split up the X.500 ownership or deal with access-control. Steve may have some thoughts on how you might want to structure things. /mtr   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13865-0@bells.cs.ucl.ac.uk>; Tue, 12 Mar 1991 15:49:16 +0000 To: Chris Weider cc: osi-ds@uk.ac.ucl.cs Subject: Re: late documents Phone: +44-71-380-7294 In-reply-to: Your message of Mon, 11 Mar 91 09:14:03 -0500. <9103111414.AA22765@mazatzal.merit.edu> Date: Tue, 12 Mar 91 15:49:11 +0000 Message-ID: <1436.668792951@UK.AC.UCL.CS> From: Steve Kille Chris, Thanks for this. I have installed it into the UCL OSI-DS WG archive, where it can be pulled from. Some comments. The document has two roles: 1) defining an interim mechansim (you note the limitations) for representing Network contact and ASNs in the directory 2) noting an overall strategy for network infrastructure information in the directory I suggest that you split your document into two, giving the first document a title indicating its more restricted role. You should define your attributes and object classes as types not values (this jut means changing the first letter to upper case and dropping the OID assignment). The OIDs should be assigned in a later version of the schema document. This will ensure that the OIDs get propogated by a single mechanism. Your object class definitions end up with the strange effect of assigning people IP numbers. I suggest you do the following 1) Get the attribute "Whoisident" added to the pilotperson object class. Many people in the pilot may have this as a valid attribute. 2) Define new object classes: IPNetwork OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN {commonName, ipNetworkNumber} -- note that common name will be the network name. This allows this new -- object to be named by a standard attribute ASN OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN {commonName, asNumber} In each case the manager attribute, which comes with pilotObject, will give a pointer to the manager. If the manager has an entry already in the DIT, this can be used. If not, and entry can be assigned user a OU=Managers brancy of the 0=Internet tree. 3) Define an object class NetworkManager OBJECT-CLASS SUBCLASS OF pilotPerson MAY CONTAIN {IPNetworkName, ASNName} Both of these new attributes have DistinguisehdNameSyntax. This allows a pilotperson to be a manager of networks and ASNs identified by name. This is much cleaner, especially when one person managers lots of networks. It is probably better to use NetworkName, rather than IPNetworkName, as this then makes the approach technology independent. I hope that this helps Steve   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <25885-0@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 10:25:21 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Wed, 13 Mar 1991 10:20:09 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 13 Mar 1991 10:10:22 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 13 Mar 1991 11:09:00 +0000 Date: Wed, 13 Mar 1991 10:10:22 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.642:13.02.91.10.10.22] X400-Content-Type: P2-1984 (2) Content-Identifier: Character set... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"13645 Wed Mar 13 11:10:28 1991"@surver.surfnet.nl> To: Rare WG3 , RARE & IETF OSI-DS wg Subject: Character set issues Working Group X-VMS-To: WG3 Sender: HUIZER@nl.surfnet Again I send this out to both lists, as I feel people on both lists should be interested. The character set issue is important to both User Servbices and Directory Services. If you are interested please read the part below. Erik Huizer SURFnet --------------------------------------------------------------------------- Dear networkers, at the last meeting of the RARE COA in Braga it was decided that RARE WG1 should take the activities on the character set item under its umbrella. It was fully understood that this item is not only an X.400 matter but all other applications and even also lower layers must be concidered. After this initial announcement I propose the following next steps: 1. I create a local distribution list with the addresses of the rare-char@dkuug.dk distribution list. 2. You look out for experts in the character set area, it would be nice if we find people with additional knowledge in the fields of e-mail, file transfer or networking in general in order to work in the standardization and in the implementation/operation areas 3. On the list the working area for this soub group should be discussed 4. I will organise a meeting after an agenda has been drafted. Earliest date: June 4-5 5. I contact piet Bovenga on how to organise subgroup meetings payed by CEC. 6. The subgroup defines its terms of reference 7. The subgroup becomes an independent working group after the startup phase under WG1. Comments are welcome. Please contact me if you need more information. Kind regards, Urs Eppenberger Switch eppenberger@verw.switch.ch ___________________________________________________________________________   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <15224-0@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 09:19:27 +0000 Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <3065-0@bells.cs.ucl.ac.uk>; Thu, 7 Mar 1991 12:20:12 +0000 From: jkrey@edu.ISI (Joyce Reynolds) Received: by venera.isi.edu (5.61/5.61+local) id ; Wed, 6 Mar 91 17:00:26 -0800 Received-Date: Wed, 6 Mar 91 17:00:17 -0800 Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 6 Mar 91 17:00:17 -0800 Date: Wed, 6 Mar 91 17:00:13 PST Posted-Date: Wed, 6 Mar 91 17:00:13 PST Message-Id: <9103070100.AA01193@akamai.isi.edu> Received: by akamai.isi.edu (4.1/4.0.3-4) id ; Wed, 6 Mar 91 17:00:13 PST To: ietf@edu.ISI Subject: Agenda for DISI meeting at upcoming IETF Cc: clw@edu.merit, jkrey@edu.ISI, mdavies@us.va.reston.nri Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Wed, 13 Mar 91 09:19:24 +0000 Resent-Message-ID: <495.668855964@UK.AC.UCL.CS> Resent-From: Steve Kille Directory Information Services (pilot) Infrastructure Working Group (DISI), chaired by Chris Weider. The first meeting of this group will be on Monday, March 11, 1:30pm-3:30pm, during the User Services WG session. AGENDA: Review and approve DISI charter. Examine needs and resources for the documentation to be produced, using as a first pass draft a document produced by Chris Weider. Assign writing assignments. Discuss liaisons to various European Directory Services groups.   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <25756-0@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 10:18:52 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Wed, 13 Mar 1991 10:13:33 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 13 Mar 1991 10:03:48 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 13 Mar 1991 11:02:00 +0000 Date: Wed, 13 Mar 1991 10:03:48 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.636:13.02.91.10.03.48] X400-Content-Type: P2-1984 (2) Content-Identifier: Call for 2nd ... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"13637 Wed Mar 13 11:03:57 1991"@surver.surfnet.nl> To: Rare WG3 , jkrey@edu.isi.venera, RARE & IETF OSI-DS wg Subject: Call for 2nd 19191 WG3 meeting and announcement 3rd WG3 meeting X-VMS-To: WG3,IN%"jkrey@venera.isi.EDU",OSI-DS Sender: HUIZER@nl.surfnet Hello there, Sorry to send this out to both the WG3 list and the OSI-ds list, some of you get it twice now, but I want to extend the invitation to the people in the IETF-DS group to join our meeting when they get the chance (and funding). Erik ___________________________________________________________________________ Announcement 3rd meeting RARE WG3 in 1991 ___________________________________________________________________________ The third WG3 meeting of 1991 will be held from 30 september till 3 october in a place to be determined in the 2nd meeting (see below). The third meeting will roughly be structured like this (subject to changes): 30 sept. 1300-1800 DS 1 oct 900-1300 DS 1400-1600 Plenary 1600-1800 US&IS 2 oct 0900-1600 US&IS And the 3rd should be reserved in case this structure changes due to input from P2.1, P2.2 and/or P3 ___________________________________________________________________________ ___________________________________________________________________________ **** CALL FOR 2nd MEETING of RARE WG3 in 1991 **** ___________________________________________________________________________ The 2nd meeting of RARE WG3 in 1991 will take place in Brussels, where we are the guests of the CEC. The meeting will take place from april 15 till april 18 according to the following structure: Place: Brussels, Berlaymont building (same as last time) room S8 15 april 1400-1800 US&IS 16 april 0900-1430 US&IS including a P2.2 presentation 1430-1700 Plenary (US&IS people are kindly invited to stay on for the rest of the meeting, but if you have to catch a plane you can plan to leave around 1600, when the most important matters will probably be covered) 17 april 0900-1500 DS 1500-1700 P2.1 18 april 0900-1300 P2.1 If judged necessary by Paradise, else we will stop earlier or later. The following interesting subjects will be covered during this meeting: - Will you ever get paid for travelling to WG3? - Where will the september meeting be held? (Umdac, Utrecht, Oslo, London?) - The Internet Directory Services pilot - The Internet User Support activities (IETF group) - Fox (yet another acronym?) - Terms of Reference (see next message) - Directory User Interfaces - DSA access for the P2.2 server - Le mousse au chocolat blanc - Le mousse au chocolat noir - How to punish people who did NOT fill in Maria's template - How to punish people who did NOT respond to my "PLEASE REPLY" mail - counting the people left over after the punishments - How to create a Paradise (P2.1 pilot Directory Services) - How to create a Concise Inferno (P2.2, European Information Service) - How to dress at the Blois JENC In summary you do not want to miss this meeting. ___________________________________________________________________________ If you plan to come to the april meeting please let me know NOW! I need to send a list of attendees in before 1st april. So please register with me before then. Erik   Return-Path: Received: from newcastle.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <28802-0@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 11:29:32 +0000 Received: from uk.ac.ncl.mts by uk.ac.newcastle; Wed, 13 Mar 91 11:27:54 GMT Date: Wed, 13 Mar 91 11:27:12 GMT From: Jill.Foster@uk.ac.newcastle Subject: Re: Call for 2nd 19191 WG3 meeting and announcement 3rd WG3 meeting To: Erik.Huizer@nl.surfnet Cc: Rare WG3 , jkrey@edu.isi.venera, RARE & IETF OSI-DS wg Message-Id: In-Reply-To: <"13637 Wed Mar 13 11:03:57 1991"@surver.surfnet.nl> Please could everyone let Erik know NOW: a) whether they intend to attend the meetings: 1) DIS subgroup 2) UIS Subgroup b) whether they will have their own funding Please note that numbers were very near the limit last time. We can only have one rep. from each country funded to come to each subgroup meeting. Note some countries send two reps. but use their own funding. You should not book anything if you require funding until you get the OK from Erik. Jill   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 13 Mar 1991 16:18:20 +0000 Date: Wed, 13 Mar 1991 16:18:20 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.989:13.02.91.16.18.20] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Wed, 13 Mar 1991 16:18:19 +0000) From: Christian Huitema Message-ID: <9103131616.AA01029@jerry.inria.fr> To: Tim Howes Cc: Chris Weider , osi-ds@uk.ac.ucl.cs In-Reply-To: <9103082211.AA28188@terminator.cc.umich.edu> Subject: Re: object and attribute descriptions You should have distribution in mind. So, the real name for the site contact at "aaa.bbb.ccc.ddd" should be something like: o=Internet@ou=aaa@ou=bbb@ou=ccc@ou=ddd so that aliasing and distributions could be used! Christian Huitema   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <13792-0@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 16:44:07 +0000 Received: from terminator.cc.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA27604; Wed, 13 Mar 91 11:43:00 -0500 Message-Id: <9103131643.AA27604@terminator.cc.umich.edu> To: Christian Huitema Cc: Chris Weider , osi-ds@uk.ac.ucl.cs Subject: Re: object and attribute descriptions In-Reply-To: Your message of "Wed, 13 Mar 91 16:18:20 GMT." <9103131616.AA01029@jerry.inria.fr> Date: Wed, 13 Mar 91 11:42:57 -0500 From: Tim Howes > You should have distribution in mind. So, the real name for the site > contact at "aaa.bbb.ccc.ddd" should be something like: > > o=Internet@ou=aaa@ou=bbb@ou=ccc@ou=ddd > > so that aliasing and distributions could be used! But that doesn't take into account the class of the network. For example, there is no "ou=141", but there is an "ou=141.211.164", though something other than ou is probably appropriate. -- Tim   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <16716-6@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 18:29:08 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <24134-81@sun2.nsfnet-relay.ac.uk>; Wed, 13 Mar 1991 17:15:07 +0000 Received: from [192.70.139.21] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa10927; 13 Mar 91 16:24 GMT Received: from localhost by cheetah.ca.psi.com at Wed, 13 Mar 91 08:31:32 -0800. (5.61.14/XIDA-1.2.8.34) id AA28458 for osi-ds@cs.ucl.ac.uk via SMTP To: Christian.Huitema@fr.inria.mirsa (Christian Huitema) Cc: Tim Howes , Chris Weider , osi-ds@uk.ac.ucl.cs Reply-To: osi-ds@uk.ac.ucl.cs Subject: Re: object and attribute descriptions In-Reply-To: Your message of Wed, 13 Mar 91 16:18:20 +0000. <9103131616.AA01029@jerry.inria.fr> Date: Wed, 13 Mar 91 08:31:30 -0800 Message-Id: <28456.668881890@cheetah.ca.psi.com> From: Marshall Rose Uh, there is something called subnetting which I think breaks that assumption... /mtr   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1121-0@bells.cs.ucl.ac.uk>; Wed, 13 Mar 1991 21:57:27 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Wed, 13 Mar 1991 21:52:22 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 13 Mar 1991 21:49:21 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 13 Mar 1991 22:48:00 +0000 Date: Wed, 13 Mar 1991 21:49:21 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.616:13.02.91.21.49.21] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Call for ... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"14617 Wed Mar 13 22:49:28 1991"@surver.surfnet.nl> To: Jill.Foster@uk.ac.newcastle, Rare WG3 , RARE & IETF OSI-DS wg , jkrey@edu.isi.venera Subject: Re: Call for 2nd 19191 WG3 meeting and announcement 3rd WG3 meeting X-VMS-To: IN%"Jill.Foster@newcastle.ac.uk" Sender: HUIZER@nl.surfnet > Subj: Re: Call for 2nd 19191 WG3 meeting and announcement 3rd WG3 meeting Anyone who thinks he/she cannot wait till 19191 is welcome in 1991 too. dates and time are the same :-) > Please could everyone let Erik know NOW: > > a) whether they intend to attend the meetings: > 1) DIS subgroup > 2) UIS Subgroup I should have said this in my first mail, thanks Jill. By the way we should start using the same abbreviations you and me to avoid confusion. Please read my ToR on this. > b) whether they will have their own funding > > Please note that numbers were very near the limit last time. We can > only have one rep. from each country funded to come to each subgroup > meeting. Note some countries send two reps. but use their own > funding. > You should not book anything if you require funding until you get the > OK from Erik. I have applied for funding for 24 peoplefor the Directory Service meeting and 24 for the User Support and Information Services meeting. Funding has been confirmed according to my application. This means that different people from each country can join the different subgroup meetings. One per country per subgroup. And unfortunately only RARE member countries are funded. Erik Ps, PaP brushed up my French, it's La mousse instead of Le mousse It will taste even mieux now   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Thu, 14 Mar 1991 08:57:13 +0000 Date: Thu, 14 Mar 1991 08:57:13 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.824:14.02.91.08.57.13] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Thu, 14 Mar 1991 08:57:13 +0000) From: Christian Huitema Message-ID: <9103140855.AA01968@jerry.inria.fr> To: osi-ds@uk.ac.ucl.cs Cc: Tim Howes , Chris Weider References: <"Your message of Wed*"@MHS>, <28456.668881890@cheetah.ca.psi.com> Subject: Re: object and attribute descriptions Marshall, You are correct as far as subnetting is concerned, and a simple form like "...@ou=aaa@ou=bbb@ou=ccc@ou=ddd" will not catch correctly some forms of subnet masks. However, the need for distribution does exist, and the simple solution which I proposed has at least the advantage of being consistant with the current DNS names for IP hosts. Christian Huitema   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3841-0@bells.cs.ucl.ac.uk>; Thu, 14 Mar 1991 09:38:14 +0000 To: Christian Huitema cc: osi-ds@uk.ac.ucl.cs, Tim Howes , Chris Weider Subject: Re: object and attribute descriptions Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 14 Mar 91 08:57:13 +0000. <9103140855.AA01968@jerry.inria.fr> Date: Thu, 14 Mar 91 09:38:13 +0000 Message-ID: <704.668943493@UK.AC.UCL.CS> From: Steve Kille Christian, Tim, Marhsall, You are reinventing stuff which is already covered in the Internet Draft "Domains and X.500". Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5246-0@bells.cs.ucl.ac.uk>; Fri, 15 Mar 1991 12:43:47 +0000 To: youbong@com.att.arch2 cc: dssig@com.sri.nisc, osi-ds@uk.ac.ucl.cs, scain@com.hp.cup.hpindeg Phone: +44-71-380-7294 Subject: Liaison from IETF OSI-DS WG to NIST OIW group on Directories Date: Fri, 15 Mar 91 12:43:45 +0000 Message-ID: <1736.669041025@UK.AC.UCL.CS> From: Steve Kille You-Bong, Thank you for your positive liaison. The attached message is a formal liaison, agreed by the WG at its Frebruary meeting. Steve Liaison from IETF OSI-DS WG to NIST OIW group on Directories March 1991 We am glad to hear that you are undertaking work on replication, and that you are taking the Internet requirements in to account. We would be happy to discuss these with you if clarification is needed. We have a working document on requirements for replication, and we expect that our working document on security will lead to a number of requirements on access control. We will be happy to make your documents available to the WG. We do not have a paper distribution, so to enable effective comment you should supply text or postscript versions of any documents. We can place these in the WG's document archive. We will be happy to review documents in these areas produced by your group. The OSI-DS group is an open group. We have a mailing list, which covers both the Internet IETF WG and the Directory Subgroup of RARE WG3 (European). All members of DSSIG are invited to join this list. Send to to be added.   Return-Path: Received: from ames.arc.nasa.gov by bells.cs.ucl.ac.uk with SMTP inbound id <28998-0@bells.cs.ucl.ac.uk>; Sat, 16 Mar 1991 04:23:41 +0000 Received: from localhost.arc.nasa.gov by ames.arc.nasa.gov (5.64/1.2); Fri, 15 Mar 91 20:23:48 -0800 Message-Id: <9103160423.AA26463@ames.arc.nasa.gov> To: Steve Kille Cc: osi-ds@uk.ac.ucl.cs Subject: Re: late documents In-Reply-To: Your message of Mon, 11 Mar 91 09:27:53 +0000. <512.668683673@UK.AC.UCL.CS> Date: Fri, 15 Mar 91 20:23:46 PST From: yee@gov.nasa.arc.ames My document are currently being reviewed by IESG (right acronym?). Upon receiving their input (which I imagine will be extremely useful), I will revise my document further and then submit it to the osi-ds list. -Peter   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28690-0@bells.cs.ucl.ac.uk>; Tue, 19 Mar 1991 14:51:37 +0000 To: osi-ds@uk.ac.ucl.cs cc: J.Crowcroft@uk.ac.ucl.cs, j.cowan@uk.ac.ucl.cs, S.Kille@uk.ac.ucl.cs Subject: Status report Phone: +44-71-380-7294 Date: Tue, 19 Mar 91 14:51:30 +0000 Message-ID: <698.669394290@UK.AC.UCL.CS> From: Steve Kille It is time to give a status report on progress and documents! First, I propose that we schedule a videoconference on 11th April, with 9th April as backup. The facilities are being requested (UCL, BBN, DARPA, NASA). I propose a meeting of about four hours (morning in California, evening in UK). The focus of this meeting should be: - work on the pending documents. I'd particularly like to focus on the Network mapping stuff. - US/European liaison, and establishing pilots. There will be quite a few UK people present, and I hope a few from the continent, and in particular the chair of WG3 (Erik). We can disucss the detailed Agenda in due course. Monthly reporting was discussed at a recent PARADISE meeting, and the details are being co-ordianted between PARADISE and FOX. Liaison statement sent to NIST OIW Preliminary investigations of getting some funding for US participants in RARE WG3 meetings have been made. The draft strategy document "A proposed strategy for deploying an OSI Internet Directory" has been sent to the IAB for comment. The WG will no longer be working on the document, but will be kept informed of progress. The document "Overall plan of the IETF Working Group on OSI Directories (OSI-DS) to build an Internet Directory using X.500" has been modified to satisfy the final IESG comments, and should appear as an RFC soon. This, and all other new or modified documents are available from the UCL archive -- index attached. Two documents have been submitted as RFCs with no editing: "An Interim Approach to use of Network Addresses" "A String encoding of Presentation Address" Four documents have been submitted as RFCs with minor editing "Domains and X.500" "Using the OSI Directory to achieve User Friendly Naming" "Replication Requirement to provide an Internet Directory using X.500" "The COSINE and Internet X.500 Schema" (Barker/Kille) The document "Replication and Distributed Operations extensions to provide an Internet Directory using X.500" has had moderate revision to improve clarity, and is being submitted as an RFC following online agreement of the group. Particular thanks to Peter Mierswa and Paul Koski for useful comments. Two Internet Drafts have been updated and resubmitted: "Naming Guidelines for Directory Pilots" (Barker/Kille) "DSA Naming" Chris Weider has submitted two versions of an I-D "Internet Network Infrastructure Information In X.500". The QOS work was to be added to the Schema document. Paul Barker and I decided that it needed a standalone specification to be created, and so there is a new I-D: "Handling QOS (Quality of service) in the Directory" Peter Yee has submitted his Security draft to IESG, and it will be updated in light of their comments. Work on US Naming is pending on the activities of the NADF. I think that is about it! Steve ------- INDEX OF IETF OSI DS Documents The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP scope.ps scope.txt IETF Directory Working Group Scope (Version 4) S.E. Kille December 22, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS minutes-1-oct90.txt 1st Meeting, San Jose, Oct 90 minutes-2-dec90.txt, ps 2nd Meeting, Boulder, Dec 90 minutes-3-feb91.txt 3rd Meeting, SRI, Feb 91 ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS strategy.txt strategy.ps A proposed strategy for deploying an OSI Internet Directory S.E. Kille March 1991 Abstract: This document is a first cut at describing an overall strategy for deploying an OSI Directory on the Internet. This is a draft document, and does not carry any implications of agreement on policy. goals.txt goals.ps Overall plan of the IETF Working Group on OSI Directories (OSI-DS) to build an Internet Directory using X.500 S.E. Kille February 1991 Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b]. This document summarises the plan established by the working group to achieve this, and describes a number of RFCs which the working group will write in order to establish the technical framework. This document has now been submitted as an RFC nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille draft-ucl-kille-networkaddresses-02.txt, .ps January 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-02.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. domain.ps domain.txt Domains and X.500 S.E. Kille March 1991 Abstract: This INTERNET--DRAFT considers X.500 in relation to Internet and UK Domains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille March 1991 Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. repl-req.ps repl-req.txt Replication Requirement to provide an Internet Directory using X.500 S.E. Kille March 1991 draft-ietf-osids-replication-01.txt, .ps Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90 ]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This INTERNET--DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. na.txt P. Barker S.E. Kille March 1991 The COSINE and Internet X.500 Schema Abstract: This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema This document also proposes a mechanism for allowing the schema to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, and comments on the updating mechanisms are particularly welcome. Corrections and additions to the schema should now be sent the list, as described within. repl-sol.ps Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Kille March 1991 Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point. structure.ps structure.txt P. Barker S.E. Kille February 1991 Naming Guidelines for Directory Pilots Abstract: Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. dsanaming.ps dsanaming.txt DSA Naming S.E. Kille March 1991 Abstract: This INTERNET--DRAFT describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot. I believe this note to be an important step forward, as it begins to evolve a clear model of a Directory Management Domain. contacts.txt Internet Network Infrastructure Information In X.500 C. Weider M. Knopper March 1991 Abstract: As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory information, it was percieved that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. The first section of this paper describes the schema used to contain this information; the second section describes the DIT structure built for this information. qos.ps qos.txt Handling QOS (Quality of service) in the Directory S.E. Kille March 1991 Abstract: This document describes a mechanism for specifying the Quality of Service for DSA Operations and Data in the Internet Pilot Directory Service [Kil90]. ------------------------------------------------------------------------   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1525-0@bells.cs.ucl.ac.uk>; Wed, 20 Mar 1991 13:55:41 +0000 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Wed, 20 Mar 1991 13:50:37 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 20 Mar 1991 13:54:37 +0000 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Wed, 20 Mar 1991 14:54:00 +0000 Date: Wed, 20 Mar 1991 13:50:37 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.445:20.02.91.13.54.37] X400-Content-Type: P2-1984 (2) Content-Identifier: FYI From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"16448 Wed Mar 20 14:54:45 1991"@surver.surfnet.nl> To: RARE & IETF OSI-DS wg Subject: FYI X-VMS-To: OSI-DS Sender: HUIZER@nl.surfnet ___________________________________________________________________________ forwarded mail: ___________________________________________________________________________ Send-date: Saturday, March 16, 1991 at 7:12 GMT+0100 From: "Kevin E. Jordan" To: [confirm, return] Sensitivity:personal Message-ID: xnren:23 Auto-forward: true Subject: CDC's usage of X.500 I have attached a description of how CDC's X.400 products use X.500 directory services for finding routes, MTA's, and address mappings. In a future message, I will propose a strategy for mechanically mapping X.400 O/R addresses to X.500 distinguished names. This will allow X.400 configuration and mapping information, such as is provided below, to be recorded and maintained in a distributed fashion, yet be "indexed" by X.400 O/R address. ------------------------------------------------------ INTRODUCTION This document describes the X.500 objects used by Control Data's X.400 products. The schemas described here are actively used by CDC's X.400 products today. We are already considering some improvements, and you are invited to propose more. This document is intended to initiate discussion. One goal of the IETF X.400 Operations Working Group should be to agree upon schemas and a strategy for using X.500 in support of X.400 on the Internet. Let the CDC schemas and strategy be a starting point. Schemas are presented in QUIPU's oidtable format. OVERVIEW Control Data has defined three types of X.500 objects in support of X.400. These objects define information about routes, message queues, MTA's, and address mappings. The objects are used today in the X.400 (1984 version) products delivered by Control Data to customers of its EP/IX operating system. EP/IX is a variant of UNIX(tm) which is binary compatible with the RISCos operating produced by MIPS Computer Inc. SEARCH STRATEGY The simple configuration file defined for a CDC MTA includes a directive which defines the X.500 directory base to be used by the MTA. The directory base is the location within the DIT where the MTA should make its directory queries. The configuration file also defines the name of the MTA. The MTA uses these two pieces of information to anchor its queries. When an MTA needs to look up information such as the routing information associated with an O/R address, the MTA first queries the subtree whose base is defined by: configured-base@MTAname=name For example, if the configured base is defined as the RDN "c=us@o=cdc@ou=cpg" and the MTA name is defined as "CDC.US", then this MTA first queries the subtree whose base is defined by the RDN: c=us@o=cdc@ou=cpg@MTAname=CDC.US If the MTA fails to find what it is looking for within that subtree, then it steps up one level in the tree and tries again. In this case, it would step up to the subtree defined by: c=us@o=cdc@ou=cpg If it fails to find what it is lookup for at that level of the DIT, it stops looking. This design allows MTA-private information to be defined and stored in the directory under a subtree defined by the MTA's own name. Information common to a set of related MTA's can be defined and stored at a common level of the directory, the level which is the common parent of the MTA subtrees. MTA OBJECT DEFINITION The MTA object schema describes the characteristics of an X.400 message transfer agent. It includes all of the information necessary for one MTA (1984) to establish a connection with another MTA. It also includes RFC987 gateway information. cdcMTA: cdcObjectClass.1: top: MTAname: \ x400domain, \ gatewayRfc987address, \ gatewayDomainName, \ gatemaster, \ serviceName, \ localMTApassword, \ remoteMTApassword, \ mailAdministrator All of the attributes are defined as "caseIgnoreString". Their definitions are: MTAname - This is the RDN of the object. It identifies the name of the respective message transfer agent. x400domain - This attribute is the text encoded (using RFC987 syntax) X.400 domain address of the MTA. This address should contain only country, ADMD, and optionally PRMD. Example: /c=us/admd=attmail/prmd=cdc/ gatewayRfc987address - This attribute defines the text encoded X.400 O/Raddress (using RFC987 syntax) of the RFC987 gateway associated with the MTA, if any. Example: /c=us/admd=attmail/prmd=cdc/o=cpg/ou=cpg-gw/ gatewayDomainName - This attribute defines the Internet domain name associated with the MTA, if any. Example: cpg-gw.cpg.cdc.com gatemaster - This attribute defines the electronic mail address of the master of the RFC987 gateway (if a gateway is associated with this MTA). In the CDC implementation, this address is placed in the "From:" field of non/delivery reports mapped from X.400 to RFC822. Example: postmaster@cpg-gw.cpg.cdc.com serviceName - This attribute is a distinguished name expressed using the QUIPU syntax for X.500 distinguished names. The distinguished name identifies an object of type applicationProcess. In turn, the applicationProcess object should form the root of a subtree which contains objects of type applicationEntity. The RDN of one of these applicationEntity objects must be "MHS-84", and it must contain an attribute which defines the OSI address of the MTA (aka RTS responder address). localMTApassword - This attribute defines the password, if any, which must be supplied by a local MTA when attempting an association with the MTA defined by this object. remoteMTApassword - This attribute defines the password, if any, which must be supplied by the MTA defined by this object when it attempts to make an association with a local MTA. mailAdministrator - This attribute identifies the administrator of the MTA defined by this object. Attributes which ought to be added to this schema include: uniqueIdentifier - The X.400 implementors agreements indicate that message identifiers should be constructed from an MTA dependent unique identifier and an MTA name which is unique within the X.400 domain of the MTA. Furthermore, the agreements indicate that the unique MTA name shall not exceed 12 characters in length. Consequently, there is a need to map a real-world MTA name to a unique 12 character identifier. description - Most objects have an attribute which is used to provide a general description. The MTA object schema should include this attribute too. supportedProfiles - This could be defined as a multivalued attribute which describes the OSI communication profiles supported by the MTA (e.g. RFC1006, TP0/X.25, TP4/CLNS) supportedVersions - This multivalued attribute could define the X.400 versions supported by the MTA (e.g. 1984, 1988, 1992, etc.). O/R NAME OBJECT DEFINITION The O/Rname object schema describes routing and mapping information about an X.400 address. The schema for this object is currently defined as follows: cdcORname: cdcObjectClass.2: top: rfc987address: \ queue, \ domainName, \ MTAname, \ mailAdministrator All of the attributes are defined as "caseIgnoreString". Their definitions are: rfc987address - This is the RDN of the object. It represents a text encoded (using RFC987 syntax) X.400 address. Examples: /c=us/admd=attmail/prmd=cdc/o=cpg/s=Jordan/ /c=us/admd=attmail/prmd=cdc/ /c=fr/ queue - This attribute defines the name of the message queue into which messages destined for the specified O/Rname are to be placed. In other words, this is a routing attribute. domainName - This attribute defines the Internet domain name associated with the X.400 O/Rname. In other words, this attribute defines the RFC822 mapping of the X.400 address. MTAname - This attribute defines the name of the MTA to which messages destined for the specified O/Rname should be sent. mailAdministrator - This attribute identifies the administrator of this object. Attributes which ought to be added are: description - Most objects have an attribute which is used to provide a general description. The O/Rname object schema should include this attribute too. Also, the MTAname attribute ought to be redefined as a distinguished name. This will allow it to reference an MTA object definition located anywhere in the DIT. DOMAIN NAME OBJECT DEFINITION The domain name object schema describes the mapping of an Internet domain name to an X.400 O/R address. The schema for this object is currently defined as follows: cdcDomainName: cdcObjectClass.3: top: domainName: \ rfc987address, \ mailAdministrator All of the attributes are defined as "caseIgnoreString". Their definitions are: domainName - This is the RDN of the object. It is an Internet domain name (e.g. cpg.cdc.com). rfc987address - This attribute represents a text encoded (using RFC987 syntax) X.400 address. It defines the X.400 O/R address to which the domain name may be mapped. mailAdministrator - This attribute identifies the administrator of this object. Attributes which ought to be added are: description - Most objects have an attribute which is used to provide a general description. The O/Rname object schema should include this attribute too. USE OF THORNPERSON OBJECT QUIPU defines an object class called "thornPerson". This object class contains a number of very useful attributes for describing information about people. In particular, the thornPerson class defines attributes for the text encoded O/R address and the Internet mail address of a person. CDC's RFC987 gateway product makes use of the these attributes to map a user's UNIX mailbox name to a full X.400 personal name, and vice versa. When an RFC822 user sends a mail message through the CDC RFC987 gateway, the gateway extracts the sender's Internet address from the "From:" field. It uses the local part (part to the left of the "@") as a key for making an X.500 query. For example, my RFC822 address is "kej@mercury.udev.cdc.com". Our gateway extracts "kej" from my RFC822 address and queries the directory for an object with the distinguished name: c=us@o=cdc@ou=cpg@commonName=kej If an object with this name is found, and if the object has an "rfc822mailbox" attribute whose value matches "kej@mercury.udev.cdc.com", then the value of the "textEncodedORaddress" attribute, if any, of this object will be used as my X.400 originator address. Similarly, when an X.400 originator sends a message to an RFC822 recipient, the X.500 directory is used to map X.400 recipient addresses to RFC822 mailbox addresses. In this case, the personal name elements of the recipient O/R address are used to construct an X.500 RDN and a query is made. For example, if a recipient address is: /c=us/admd=attmail/prmd=cdc/o=cpg/s=Jordan/g=Kevin/ then a distinguished name like the following is constructed: c=us@o=cdc@ou=cpg@commonName=Kevin Jordan and the directory is queried for an object by this name. In this case, an exact match need not be made. For example, if the directory contains an object with RDN "Kevin E Jordan", a match will be made as long as this is the only object at the specified location in the DIT which has "Kevin" as a given name and "Jordan" as a surname, and the value of the "textEncodedORaddress" attribute of this object matches the X.400 recipient address. If a match is made and the matched object has a value in its "rfc822mailbox" attribute, then the X.400 recipient address will be mapped to that value. To avoid cluttering the directory with redundant information, we create one "thornPerson" object for each user. The RDN of this object is the user's full personal name (e.g. "Kevin E Jordan"). Then we create an X.500 alias object for the user. The RDN of the alias is the user's UNIX username (e.g. "kej"). The alias references the "thornPerson" object.   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <9007-0@bells.cs.ucl.ac.uk>; Wed, 20 Mar 1991 19:38:53 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA09431; Wed, 20 Mar 91 14:37:16 -0500 From: Mark Knopper Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA09427; Wed, 20 Mar 91 14:37:14 -0500 Received: by home.merit.edu (4.1/dumb-0.9) id AA01229; Wed, 20 Mar 91 14:37:12 EST Message-Id: <9103201937.AA01229@home.merit.edu> To: clw@edu.merit Cc: disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Additions to disi-list In-Reply-To: Your message of "Wed, 20 Mar 91 12:11:28 EST." <9103201711.AA01203@mazatzal.merit.edu> Date: Wed, 20 Mar 91 14:37:11 -0500 FYI, the osi-ds list is now a subset of the disi@merit.edu list. Let me know at disi-request@merit.edu if this causes problems. Mark ps. To expand the list, telnet merit.edu smtp and say expn disi-rcpt. ---- Mark: I couldn't get the disi list to expand when I telnetted to 35.1.1.42 2 5. I think Sue Hares has also been having this problem. So, if it is not alre ady added, could you add osi-ds@cs.ucl.ac.uk and Sue Hares to the DISI list? Thanks! Chris   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <8634-0@bells.cs.ucl.ac.uk>; Wed, 20 Mar 1991 19:37:00 +0000 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA09427; Wed, 20 Mar 91 14:37:14 -0500 Received: by home.merit.edu (4.1/dumb-0.9) id AA01229; Wed, 20 Mar 91 14:37:12 EST From: mak@edu.merit Message-Id: <9103201937.AA01229@home.merit.edu> To: clw@edu.merit Cc: disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Additions to disi-list In-Reply-To: Your message of "Wed, 20 Mar 91 12:11:28 EST." <9103201711.AA01203@mazatzal.merit.edu> Date: Wed, 20 Mar 91 14:37:11 -0500 FYI, the osi-ds list is now a subset of the disi@merit.edu list. Let me know at disi-request@merit.edu if this causes problems. Mark ps. To expand the list, telnet merit.edu smtp and say expn disi-rcpt. ---- Mark: I couldn't get the disi list to expand when I telnetted to 35.1.1.42 2 5. I think Sue Hares has also been having this problem. So, if it is not alre ady added, could you add osi-ds@cs.ucl.ac.uk and Sue Hares to the DISI list? Thanks! Chris   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <5105-0@bells.cs.ucl.ac.uk>; Wed, 20 Mar 1991 21:45:14 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA11956; Wed, 20 Mar 91 16:43:49 -0500 Received: from rivendell.merit.edu by merit.edu (5.65/1123-1.0) id AA11952; Wed, 20 Mar 91 16:43:47 -0500 Received: Wed, 20 Mar 91 16:45:46 EST by rivendell.merit.edu (5.51/1.6) Date: Wed, 20 Mar 91 16:45:46 EST From: Susan Hares Message-Id: <9103202145.AA17411@rivendell.merit.edu> To: rlang@com.SRI.NISC, sturtevant@gov.NERSC.CCC Subject: Re: Writing Assignments from the March 11 meeting Cc: disi@edu.merit Hi all: I'm new to the DISI group. Has anyone thought about making two documents out of the X.500 survery document - one with product descriptions by authors/implementors and a second with user comments. Sometimes it is very valuable to read a comment from another user before trying a pieces of software. The editors of these documents could deny any support of the comments. Comments the DISI working group felt strongly about could be entered from the working group. I'm chair of the NOOP (Network Layer OSI Operational) working group, and have privately wondered about the issues in terms of osi routers and the Network Management tools for OSI Network Layer. Sue Hares   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <7595-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 00:39:35 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA14289; Wed, 20 Mar 91 19:38:34 -0500 Received: from sparkle.lbl.gov by merit.edu (5.65/1123-1.0) id AA14285; Wed, 20 Mar 91 19:38:29 -0500 Message-Id: <9103210038.AA14285@merit.edu> Received: from b50b-cnr9.lbl.gov by sparkle.lbl.gov with SMTP (PP) id <2354-0@sparkle.lbl.gov>; Wed, 20 Mar 1991 16:38:17 -0800 Date: Wed, 20 Mar 91 16:38:25 From: wright@gov.lbl.sparkle (Russ Wright) To: skh@edu.merit Subject: Re: Writing Assignments from the March 11 meeting Cc: disi@edu.merit > I'm new to the DISI group. Has anyone thought about making two > documents out of the X.500 survery document - one with product descriptions > by authors/implementors and a second with user comments. Sometimes > it is very valuable to read a comment from another user before trying > a pieces of software. The editors of these documents could deny any > support of the comments. Comments the DISI working group felt strongly > about could be entered from the working group. I agree that user comments can be useful. Putting user comments into the RFC, however, would be asking for trouble (even if we put a disclaimer at the top of the RFC). One of the things we can put into the RFC is pointer to useful mail archives and e-mail lists. I know this is not an ideal solution, but it will allow us to produce an OBJECTIVE RFC. Russ Wright Lawrence Berkeley Laboratory wright@lbl.gov   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <24701-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 01:50:33 +0000 Received: Wed, 20 Mar 91 20:47:40 EST by mazatzal.merit.edu (5.51/1.6) Date: Wed, 20 Mar 91 20:47:40 EST From: Chris Weider Message-Id: <9103210147.AA01780@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Interim Network Infrastructure Schema I-D Here it is, everyone, the first of the two new papers. The second should be out tomorrow or Friday. Enjoy! Chris & Mark Directory Information Services (pilot) Chris Weider Infrastructure Working Group Mark Knopper INTERNET--DRAFT Merit Network March 1991 Interim Schema for Network Infrastructure Information in X.500 Status of this Memo As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory Information, it was perceived that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. This paper describes the interim schema used to contain this information. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group disi@merit.edu. INTERNET--DRAFT Interim Network Information Schema March 1991 SECTION 1: PRELIMINARIES 1.1 Introduction Information related to the Interent Network Infrastructure is stored and created by a number of different organizations, such as the Network Information Center (NIC), the Internet Assigned Numbers Authority (IANA), and the NSFNet Network Operations Center (NOC). The information is in general "mastered" (stored and maintained) by these organizations on a centralized basis, i.e. there is a single place to look for a definitive list of entries for these categories. This has worked well in the past but given the tremendous growth of the Internet and its number of users and networks, it is essential that a distributed scheme be used. An example of where this kind of scheme has worked is the domain name system for host naming and addressing information. The X.500 Directory standard seems to be an ideal technology for implementing this distributed method of managing network infrastructure information. X.500 allows distributed ownership of different parts of the global Directory Information Tree, and with replication can provide this information on a query basis to users rapidly. The access control and security capabilities exist in the current standards and implementation and also are being developed by IETF working groups and implementors. A worldwide pilot project involving over 20 countries is in progress, primarily for the purpose of making "white pages" or people-oriented information available. The Field Operational X.500 (FOX) project is a funded project involving several US organizations who are committed to advancing the X.500 projects to an operational status. This RFC proposes a set of interim schema to be used to hold this information in the Directory. It also discusses some limitations of the schema proposed and some possible resolutions of these limitations. 1.2 Information to be incorporated The Site Contacts information that is being loaded into the MERIT DSA is being generated weekly by the SRI NIC, and is output into two text files NETINFO:NETWORK-CONTACTS.TXT and NETINFO:ASN.TXT, both of which are available via anonymous FTP. Representative entries from both files are on the next page: INTERNET--DRAFT Interim Network Information Schema March 1991 __ __ __ __ __ 3.0.0.0 GE-INTERNET Bradt, James E. (JEB50) bradt@CRD.GE.COM (518) 387-7170 Representative entry from the Network-Contacts file __ __ __ __ __ ASN Numbers 1 The BBN Core Gateways [MB] Representative entry from the ASN.TXT file _______________________________________________________________________________ SECTION 2: NEW SCHEMA 2.1 Evolution of schema design In the initial phases of incorporating this information into the Directory, we constrained ourselves to working with object classes that had already been defined. This forced some highly nonintuitive choices for mapping the data into the object classes, but it did make the information widely available. In choosing the object class schema we did for the current implementation of the data, we wanted to contain the new NIC information, and build a schema structure which was logically appealing. 2.2 New attributes for this information New attributes used for this information are IpNetworkNumber; a string containing the network number. WhoisIdent; which has been semi-officially added to the pilotPerson object class; which is a string containing the NIC handle of the contact for the network or AS. AsNumber; a string containing the AS number. TechnicalContact; a seeAlso type reference to the technical contact for this net or AS. AdministrativeContact; a seeAlso type reference to the administrative contact for this net or AS. The ASN.1 descriptions of these attributes are on the next page. INTERNET--DRAFT Interim Network Information Schema March 1991 __ __ __ __ __ IpNetworkNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipnetnum)) ub-ipnetnum INTEGER ::= 15 whoisIdent ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-whois)) ::= { psiAttributeType.13 } ub-whois INTEGER ::= 15 AsNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-asnum)) ub-asnum INTEGER ::= 20 TechnicalContact ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax AdministrativeContact ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax NetworkName ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax ASNName ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax _____________________________________________________________________________ ASN.1 definitions for new attributes. INTERNET--DRAFT Interim Network Information Schema March 1991 2.3 New object classes There are three new object classes to hold this information; IPNetwork, which holds ip network contact information; ASN, which holds AS contact info; and NetworkManager, which holds personal information for Network and AS managers and contacts. These are detailed in ASN.1 below. _____________________________________________________________________________ IPNetwork OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName, ipNetworkNumber } MAY CONTAIN { TechnicalContact, AdministrativeContact } ASN OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName, asNumber } MAY CONTAIN { TechnicalContact, AdministrativeContact } NetworkManager OBJECT-CLASS SUBCLASS OF pilotPerson MAY CONTAIN { NetworkName, ASNName } _____________________________________________________________________________ ASN.1 definitions for new object classes The NetworkName and ASNName attributes are needed for the NetworkManager object class because the parallel information is contained in the commonName attribute in the IPNetwork and ASN object classes. This allows us to extend a standard RDN to each of these new object classes. 2.4 RDNs for new object classes The RDNs for each object class is as follows: IPNetwork: @o=Internet@ou=ipnetworks@cn=35.0.0.0 for network 35.0.0.0 ASN: @o=Internet@ou=autonomous systems@cn=267 for AS 267 NetworkManager: @o=Internet@ou=Managers@cn=Hans-Werner Braun for Hans-Werner Braun INTERNET--DRAFT Interim Network Information Schema March 1991 SECTION 3: WHO WE ARE 3.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109 SECTION 4: REFERENCES [Kil89] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College Lon- don, May 1989. Also Internet Draft: DRAFT-UCL-KILLE- X500DOMAINS-00.PS [Kil90] S.E. Kille. The COSINE and Internet X.500 Naming Architecture. Internet Draft: DRAFT-IETF-OSIDS-COSINEX500-02.TXT   Return-Path: Received: from vtvm1.cc.vt.edu by bells.cs.ucl.ac.uk with SMTP inbound id <1576-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 02:19:48 +0000 Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 0775; Wed, 20 Mar 91 21:19:36 EST Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.07) with BSMTP id 9005; Wed, 20 Mar 91 21:19:35 EST Date: Wed, 20 Mar 91 21:18:23 EST From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Naming Schemas and deployment To: osi-ds@uk.ac.ucl.cs Message-Id: <910320.204806.EST.VALDIS@vtvm1.cc.vt.edu> I just printed off the "latest and greatest" copy of Barker & Kille "The COSINE and Internet X.500 Schema". A number of these attributes (In particular the "uniqueIdentifier" (pilotAttributeType.44)) look quite immediately applicable to our installation. (1) I notice that 'pilot' is defined as 'ucl.100', which overloads 'thorn' which had the same definition. What resolution is proposed? (2) Is there a "target date" that organizations participating in the various X.500 pilots should wait for, before actually using the proposed naming schema? In particular, what is likely to break, and how should we avoid it? Our organization is currently within a few weeks of deploying on-line updating of the directory from multiple sources, so my window to do a "mass reload" of the entire DSA is rapidly closing - after we go live with the online updates, I'll have to find alternate methods to apply mass changes. As our production DSA has (currently) 12,911 entries in 573 EDBs, being able to make changes in the "mass load" program rather than on a per-EDB basis is a big win.... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <7771-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 08:29:48 +0000 Replied: Wed, 20 Mar 91 16:51:34 +0000 Replied: Graham REES Return-Path: Received: from bunyip.cc.uq.oz.au by bells.cs.ucl.ac.uk with SMTP inbound id <4087-0@bells.cs.ucl.ac.uk>; Tue, 12 Mar 1991 01:39:23 +0000 Received: from uqvax by bunyip.cc.uq.oz.au id aa14535; 12 Mar 91 11:39 EST Date: Tue, 12 Mar 91 11:39 EST From: Graham REES Subject: AARNet Directory Services Project To: s.kille@uk.ac.ucl.cs Message-id: X-Envelope-to: s.kille@cs.ucl.ac.uk X-VMS-To: IN%"s.kille@cs.ucl.ac.uk" X-VMS-Cc: CCREES Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Thu, 21 Mar 91 08:29:46 +0000 Resent-Message-ID: <388.669544186@UK.AC.UCL.CS> Resent-From: Steve Kille Steve, Further to my mail the other day here is the news press release which briefly describes the AARNet DS project. AARNet Directory Services Project The Australian Academic and Research Network Directory Services (AARNet DS) Project proposes to implement a pilot, national, electronic directory service over AARNet. In its simplest sense it can be seen as analogous to an internal telephone directory (and indeed can be used as such), but it is also capable of providing access to an on-line distributed database of the individuals, resources and organisations which form Australia's academic and research community. It is envisaged that the directory will store such data as a person's full name, commonly used names, telephone number, postal address, electronic mail address, job description and research interests. Individuals will be able to keep the directory up to date by changing their own entry details as required. With links to similar projects in many other countries this service will become a significant component of the global academic and research infrastructure. History Directory services work within AARNet (Australian Academic and Research Network) has been informal with a number on institutions running the QUIPU DSA (Directory Servcie Agent). The Prentice Centre at The University of Queensland, as well as operating local directory services, acts as the Australian hub of the QUIPU directory systems and provides a registration centre for other interested parties. Levels of representation within the Directory Information Tree (DIT) vary between cooperating sites, as does the commitment to machine power and human resources. To date some 10,000 people have been registered across the AVCC (Australian Vice-Chancellors Committee) institutions and CSIRO (Commonwealth Scientific and Industrial Research Organisation) in 10 directory systems (DSAs). Few of these are in stand alone systems, or in secured and reliable environments. This coupled with the complexity of bootstrapping a directory services from available information has impeded growth of Directory Services AARNet wide. The Project The AARNet DS Project is being funded by the AVCC as a pilot to encourage the development of AARNet wide X.500 Directory Services. While the pilot only involves 4 Universities and CSIRO Division of Information Technology, there a number of other institutions and individuals interested in and committed to such a concept. The project will report to the AVCC and the AARNet community at the Net-Workshop in Hobart early in December 1991. The main aims of the project, and expectations of the AVCC, are to produce: - A national electronic directory structure, populated initially with information from the participating institutions. - Documentation of the costs and benefits experienced by the participating institutions in providing directory services. This will serve as a guide to other institution's entry into this national program. - The acquisition of valuable experience within AARNet in the use of emerging open networking technologies in a service and production role. - The fostering of participation of Australian network engineers and researchers in the ongoing development of global communications technologies, with the consequent strategic benefit that results from such active participation. - Documentation of the experiences in the management of a national project within the AARNet program, as a guide to future activities of similar national significance to the Australian academic and research community. The project participants are The University of Queensland, the University of Adelaide, the University of Sydney, Monash University and the CSIRO Division of Information Technology. The project will be managed by The University of Queensland. Enquiries should be directed to: Project Management: Graham Rees, g.rees@uqvax.cc.uq.edu.au Technical Contact: George Michaelson, ggm@cc.uq.edu.au The other participating sites and contacts are: The University of Sydney, John Resauer, johnr@extro.ucc.su.oz.au Monash University, John Mann, johnm@vaxc.cc.monash.edu.au The University of Adelaide, Mark Prior, mrp@itd.adelaide.edu.au CSIRO Division of Information Technology, Andrew Waugh, A.Waugh@mel.dit.csiro.au Implementation Four directory service systems will be purchased, one to be located in the capital city of each of the participating institutions, that is, Brisbane, Sydney, Melbourne and Adelaide. The systems will be used for development during 1991 and then revert to AARNet ownership to be used specifically to support directory services in those regions. The initial work will be concerned with fully populating the directories with information about the staff in the participating institutions. Following this, a number of "focussed" projects will be undertaken, which will reflect the interests and skills of the participants. These will mainly centre on improved application software and management of the directories. Interest The AVCC funded those institutions who requested funds under their Development Grant scheme in 1990. It is realised that there are other institutions and individuals interested in directory services. We wish to involve to everyone who has an interest in this developing technology, but at this stage, we're not sure of the best way this can be achieved. If you have an interest please mail g.rees @uqvax.cc.uq.edu.au and we will endeavour to create a suitable mechanism. It would helpful if you could let us know your level of interest and commitment to DS, for example, are you running a DSA and how much resource is committed or are you just an interested bystander? Other organisations would be welcome to setup their own directory systems and interoperate with the pilot sites. The software being used is the QUIPU DSA, which is part of the ISODE distribution. Contact Andrew Waugh, CSIRO DIT for further information on ISODE.   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <18157-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 09:15:47 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA20342; Thu, 21 Mar 91 04:15:15 -0500 Received: from bells.cs.ucl.ac.uk by merit.edu (5.65/1123-1.0) id AA20338; Thu, 21 Mar 91 04:15:12 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17860-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 09:14:23 +0000 To: disi@edu.merit Subject: osi-ds as a sublist of disi@merit.edu Phone: +44-71-380-7294 Date: Thu, 21 Mar 91 09:14:20 +0000 Message-Id: <634.669546860@UK.AC.UCL.CS> From: Steve Kille I have no problems with this, but some people might. I suggest tht we try it for now, and see if there are any problems. If lots of people on osi-ds object, we should reconsider this choice. Steve   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <20397-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 09:25:50 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA20342; Thu, 21 Mar 91 04:15:15 -0500 Received: from bells.cs.ucl.ac.uk by merit.edu (5.65/1123-1.0) id AA20338; Thu, 21 Mar 91 04:15:12 -0500 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17860-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 09:14:23 +0000 To: disi@edu.merit Subject: osi-ds as a sublist of disi@merit.edu Phone: +44-71-380-7294 Date: Thu, 21 Mar 91 09:14:20 +0000 Message-Id: <634.669546860@UK.AC.UCL.CS> From: Steve Kille I have no problems with this, but some people might. I suggest tht we try it for now, and see if there are any problems. If lots of people on osi-ds object, we should reconsider this choice. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22868-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 09:38:44 +0000 To: Valdis Kletnieks cc: osi-ds@uk.ac.ucl.cs Subject: Re: Naming Schemas and deployment Phone: +44-71-380-7294 In-reply-to: Your message of Wed, 20 Mar 91 21:18:23 -0500. <910320.204806.EST.VALDIS@vtvm1.cc.vt.edu> Date: Thu, 21 Mar 91 09:38:39 +0000 Message-ID: <850.669548319@UK.AC.UCL.CS> From: Steve Kille In most cases, we have left the numbers the same (all that goes over the net), and changed the names to be appropriate for what is being done. This will ease transition. I would suggest that the pilot transition should be at a date (fairly soon) after the RFC is published. When there is an operations group, it should be indicating when documents come into play. I'm not sure that this is a big deal, because of the way in which changes will be made. We will not be changing OIDs in the short term. (However, we may need to later if NIST or ISO standardise attributes we are using in the pilot). The rest of the message is specific to QUIPU. We have added in a feature to allow aliasing of Object Identifiers. In the tables distributed with 6.8, all of the new (changed) identifiers are aliased onto the old ones. In the next release, the new OIDs will be the defaults, with the old OIDs aliased onto them. This should give a transparent transition. Steve   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <18696-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 13:28:11 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA22222; Thu, 21 Mar 91 08:24:38 -0500 Received: from DIAMOND.BUCKNELL.EDU by merit.edu (5.65/1123-1.0) id AA22216; Thu, 21 Mar 91 08:24:35 -0500 Received: from regulus.bucknell.edu.sol_nis by sol.bucknell.edu (4.1/Bucknell-1.1) id ; Thu, 21 Mar 91 08:25:50 EST Date: Thu, 21 Mar 91 08:25:50 EST From: droms@edu.bucknell.sol (Ralph E. Droms) Message-Id: <9103211325.AA02646@sol.bucknell.edu> Received: by regulus.bucknell.edu.sol_nis (4.1/SMI-4.1) id AA01084; Thu, 21 Mar 91 08:22:24 EST To: S.Kille@uk.ac.ucl.cs Cc: disi@edu.merit In-Reply-To: Steve Kille's message of Thu, 21 Mar 91 09:14:20 +0000 <634.669546860@UK.AC.UCL.CS> Subject: Re: osi-ds as a sublist of disi@merit.edu Reply-To: droms@edu.bucknell I have no problems with this, but some people might. I seem to have a problem with the current arrangement. I recevied *4* copies of Steve's note. One from my original subscription to disi, one from my subscription to osi-ds, one from my subscription to another WPP-associated list (osi-ds is cross-subscribed with another WPP list) and I dunno where the fourth copy came from. Unfortunately, I can't trace any of the mailing-list details from the mail headers as I've received them. I'm sorry not to have kept track of which lists I'm subscribed to, and I've been meaning to figure out why I get multiple copies of mail to the osi-ds list, and I'm sorry to bother all of you with this question, but can *someone* suggest which one list I can subscribe to so that I can keep track of all of this. Whew. Thanks... - Ralph Droms Computer Science Department droms@bucknell.edu 323 Dana Engineering Bucknell University (717) 524-1145 Lewisburg, PA 17837   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <4954-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 17:32:53 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA26238; Thu, 21 Mar 91 12:31:47 -0500 Received: from sparkle.lbl.gov by merit.edu (5.65/1123-1.0) id AA26233; Thu, 21 Mar 91 12:31:44 -0500 Message-Id: <9103211731.AA26233@merit.edu> Received: from b50b-cnr9.lbl.gov by sparkle.lbl.gov with SMTP (PP) id <2685-0@sparkle.lbl.gov>; Thu, 21 Mar 1991 09:31:30 -0800 Date: Thu, 21 Mar 91 09:31:28 From: wright@gov.lbl.sparkle (Russ Wright) To: disi@edu.merit Subject: Re: osi-ds as a sublist of disi@merit.edu I hate getting all this mail, for what it's worth. Russ   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <9000-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 19:38:46 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA28422; Thu, 21 Mar 91 14:37:25 -0500 Received: from stsci.edu by merit.edu (5.65/1123-1.0) id AA28418; Thu, 21 Mar 91 14:37:22 -0500 Received: Thu, 21 Mar 91 14:37:49 EST from GHOST.STSCI.EDU by stsci.edu (4.1) Received: Thu, 21 Mar 91 14:37:46 EST by ghost.stsci.edu (4.1) Date: Thu, 21 Mar 91 14:37:46 EST From: (Richard Bowles) bowles Message-Id: <9103211937.AA12207@GHOST.STSCI.EDU> To: disi@edu.merit Subject: Re: osi-ds as a sublist of disi@merit.edu > From disi-owner@merit.edu Thu Mar 21 12:33:35 1991 > To: disi@merit.edu > Subject: Re: osi-ds as a sublist of disi@merit.edu > > I hate getting all this mail, for what it's worth. > Russ > I agree. If the groups are different enough to exist separately, they should have separate lists. (i.e. let the user decide). Richard Bowles   Return-Path: Received: from mbunix.mitre.org by bells.cs.ucl.ac.uk with SMTP inbound id <11221-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 20:02:14 +0000 Received: by mbunix.mitre.org (5.57/4.7) id AA29266; Thu, 21 Mar 91 15:03:17 EST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Received: from localhost.mitre.org by ulana.mitre.org (4.1/SMI-4.0) id AA13804; Thu, 21 Mar 91 15:01:48 EST Message-Id: <9103212001.AA13804@ulana.mitre.org> To: osi-ds@uk.ac.ucl.cs Subject: Please add me to the list Date: Thu, 21 Mar 91 15:01:47 EST From: David "T." Miller Please add me to the osi-ds mailing list. Thanx. ============================================================================ David T. Miller E-mail: dtm@mitre.org MITRE Corporation Phone: 617/ 271-3993 ----------------------------------------------------------------------------   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <12213-0@bells.cs.ucl.ac.uk>; Thu, 21 Mar 1991 20:26:53 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA29463; Thu, 21 Mar 91 15:25:21 -0500 Received: from ws28.nisc.sri.com by merit.edu (5.65/1123-1.0) id AA29270; Thu, 21 Mar 91 15:17:22 -0500 Received: by ws28.nisc.sri.com (5.64/SRI-NISC1.1) id AA01302; Thu, 21 Mar 91 12:17:05 -0800 Message-Id: <9103212017.AA01302@ws28.nisc.sri.com> To: disi@edu.merit Subject: Re: osi-ds as a sublist of disi@merit.edu Date: Thu, 21 Mar 91 12:17:04 PST From: Ruth Lang Date: Thu, 21 Mar 91 14:37:46 -0500 From: (Richard Bowles) > I agree. If the groups are different enough to exist > separately, they should have separate lists. (i.e. > let the user decide). > > Richard Bowles I too vote for separate lists. Ruth Lang   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <21851-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 09:26:56 +0000 To: clw@edu.merit, mak@edu.merit cc: osi-ds@uk.ac.ucl.cs Subject: OSI-DS inclusion in DISI mailing list Phone: +44-71-380-7294 Date: Fri, 22 Mar 91 09:26:55 +0000 Message-ID: <787.669634015@UK.AC.UCL.CS> From: Steve Kille Following public and private comment, can I request that the osi-ds list is removed from the DISI mailing list. I think that this inclusion is inappropriate. It would be useful if you sent a message to the osi-ds list, noting the scope of the list (perhaps a resend of the charter) and giving information on how to subscribe. Steve   Return-Path: Received: from funet.fi by bells.cs.ucl.ac.uk with SMTP inbound id <28621-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 12:50:59 +0000 To: clw@edu.merit CC: osi-ds@uk.ac.ucl.cs, katz@edu.merit, mak@edu.merit, skh@edu.merit In-reply-to: Chris Weider's message of Wed, 20 Mar 91 20:47:40 EST <9103210147.AA01780@mazatzal.merit.edu> Subject: Interim Network Infrastructure Schema I-D Date: Fri, 22 Mar 1991 14:49:53 +0200 From: Juha Heinanen Sender: Juha.Heinanen@fi.funet IPNetwork: @o=Internet@ou=ipnetworks@cn=35.0.0.0 for network 35.0.0.0 how about also NSAP: @o=Internet@ou=nsapPrefixes@ou=47 @o=Internet@ou=nsapPrefixes@ou=47@ou=0005 @o=Internet@ou=nsapPrefixes@ou=47@ou=0005@cn=80FF.FF00.0000.0602 for MITRE ie. can't we solve the OSI thing at the same time? -- juha   Return-Path: Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1845-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 14:08:19 +0000 Received: from mcsun.eu.net by kestrel.Ukc.AC.UK via EUnet with authorised SMTP id aa01726; 22 Mar 91 13:55 GMT Received: from inria.inria.fr by mcsun.EU.net with SMTP; id AA01758 (5.65a/CWI-2.77); Fri, 22 Mar 91 14:53:46 +0100 Received: by inria.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA12820; Fri, 22 Mar 91 14:52:00 +0100 (MET) Received: from cli53an.edf.fr by edfder1.edf.fr, Fri, 22 Mar 91 09:22:43 +0100 Received: from loghost by cli53an.edf.fr (4.0/SMI-4.0) id AA21072; Fri, 22 Mar 91 09:23:37 +0100 To: osi-ds@uk.ac.ucl.cs Cc: disi@edu.merit Subject: Re: osi-ds as a sublist of disi@merit.edu In-Reply-To: Ruth Lang's message of 21 Mar 91 12:17:04 -0800. <9103212017.AA01302@ws28.nisc.sri.com> Date: Fri, 22 Mar 91 09:23:36 +0100 Message-Id: <21071.669630216@cli53an> From: Sylvain Langlois Sender: sylvain > I too vote for separate lists. So do I! Sylvain ---------------- Sylvain Langlois "Dogmatic attachement to the supposed merits (sylvain@cli53an.edf.fr) of a particular structure hinders the search of an appropriate structure" (Robert Fripp)   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <7101-6@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 16:41:26 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <2618-44@sun2.nsfnet-relay.ac.uk>; Fri, 22 Mar 1991 15:24:54 +0000 Received: from [129.6.55.32] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa06997; 22 Mar 91 14:01 GMT Received: by emu.ncsl.nist.gov (4.0/NIST(rbj/dougm)) id AA00425; Fri, 22 Mar 91 09:21:17 EST Date: Fri, 22 Mar 91 09:21:17 EST Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9103221421.AA00425@emu.ncsl.nist.gov> To: Juha.Heinanen@fi.funet, clw@edu.merit Subject: Re: Interim Network Infrastructure Schema I-D Cc: ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit From: colella@gov.nist.ncsl.osi3 Sender: colella@gov.nist.ncsl.emu > IPNetwork: @o=Internet@ou=ipnetworks@cn=35.0.0.0 for network 35.0.0.0 > >how about also > > NSAP: @o=Internet@ou=nsapPrefixes@ou=47 > @o=Internet@ou=nsapPrefixes@ou=47@ou=0005 > @o=Internet@ou=nsapPrefixes@ou=47@ou=0005@cn=80FF.FF00.0000.0602 > for MITRE > >ie. can't we solve the OSI thing at the same time? > >-- juha > We can and should. Chris, Ruth Lang, and I had discussed a similar idea at the last IETF meeting. This seems to fill the bill. I would think that we want more granularity in what you call cn, though. E.g., ....xx=@xx=@xx= or ....xx=@xx=@xx=@xx= Also, consider: ....xx=<47.0005> (U.S. GOSIP) and ....xx=<39.0840> (ANSI) as alternative initial pieces. What is the rationale for using o, ou, and cn for the attribute types? This seems awfully unnatural. Why not a new type like nsapElement? --Richard   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <11445-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 18:19:54 +0000 Received: Fri, 22 Mar 91 13:17:04 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Mar 91 13:17:04 EST From: Chris Weider Message-Id: <9103221817.AA03852@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs, sylvain@fr.edf.cli53an Subject: Re: osi-ds as a sublist of disi@merit.edu Cc: disi@edu.merit Mark has split these lists once again...... Chris Weider   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <11911-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 18:43:08 +0000 Received: Fri, 22 Mar 91 13:39:42 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Mar 91 13:39:42 EST From: Chris Weider Message-Id: <9103221839.AA03913@mazatzal.merit.edu> To: Christian.Huitema@fr.inria.mirsa, colella@gov.nist.ncsl.osi3 Subject: Re: Interim Network Infrastructure Schema I-D Cc: Juha.Heinanen@fi.funet, clw@edu.merit, ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit Christian: I think that, in places where the structure has been defined (U.S. GOSIP) for example, that we can and should build a portion of the DIT to reflect the structure. As I understand it, each subtree of the DIT can have a different structure, so that should make things O.K. It might be better to have a structured part of the DIT which is aliased to the NSAP which has been stored as in 1) or 2), but I think that we also want to make things as 'user-friendly' as possible. Chris   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <11616-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 18:25:31 +0000 Received: Fri, 22 Mar 91 13:20:58 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Mar 91 13:20:58 EST From: Chris Weider Message-Id: <9103221820.AA03865@mazatzal.merit.edu> To: Juha.Heinanen@fi.funet, clw@edu.merit, colella@gov.nist.ncsl.osi3 Subject: Re: Interim Network Infrastructure Schema I-D Cc: ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit Richard and Juha: I will have a paper out by next Wednesday that will attempt to solve these problems. I would appreciate all your comments on it. I will not be kludging the semantics of the NSAP addressing into stuff like o=47, etc, because it A) make's the user agent's life more difficult, and B) It's a kludge. I hope to have something that will stand up to scrutiny, but we shall see.... Chris Weider   Return-Path: Received: from EMU.NCSL.NIST.gov by bells.cs.ucl.ac.uk with SMTP inbound id <12590-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 19:18:10 +0000 Received: by emu.ncsl.nist.gov (4.0/NIST(rbj/dougm)) id AA01924; Fri, 22 Mar 91 14:15:41 EST Date: Fri, 22 Mar 91 14:15:41 EST Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9103221915.AA01924@emu.ncsl.nist.gov> To: Christian.Huitema@fr.inria.mirsa, clw@edu.merit Subject: Re: Interim Network Infrastructure Schema I-D Cc: Juha.Heinanen@fi.funet, ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit From: colella@gov.nist.ncsl.osi3 Chris, One point that Christian made is that, to construct an appropriate query, you would like to minimize the amount of a priori knowledge that you have to have. In the DNS, a reverse map query (i.e., using inaddr.arpa) is always just a single read because you know the target name. With OSI NSAPs, there can be a variety of structures and not all of these are necessarily known to the asker ("Gee, somebody's connected to my system from this NSAP address and I've never seen one from that addressing domain before."). So, to restate what Christian wrote as requirements, a solution seems to require: * that the representation be generalizable to a variety of (all?) NSAP formats, * that a lookup be reasonably efficient in terms of number of operations and the scope of each operation, and, * that it require little or (preferably) no a priori knowledge (no a priori knowledge is an interesting case, since if you don't recognize the AFI you don't know where the IDI is). The next question is, when you have finally discover the right entry, where does it point? (assuming it is an alias) One suggestion is to the entry for the network management on the target machine. --Richard   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <23976-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 20:44:31 +0000 Received: Fri, 22 Mar 91 15:41:37 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Mar 91 15:41:37 EST From: Chris Weider Message-Id: <9103222041.AA04094@mazatzal.merit.edu> To: disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Minor changes to Interim Network Information I-D Gang: Here's the last revision of the Interim Network Information Schema Internet Draft. The changes are extremely minor, and involve expanding the name of one attribute and one object class. This will be placed in the appropriate repositories..... Chris Weider Directory Information Services (pilot) Chris Weider Infrastructure Working Group Mark Knopper INTERNET--DRAFT Merit Network March 1991 Interim Schema for Network Infrastructure Information in X.500 Status of this Memo As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory Information, it was perceived that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. This paper describes the interim schema used to contain this information. This draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group disi@merit.edu. INTERNET--DRAFT Interim Network Information Schema March 1991 SECTION 1: PRELIMINARIES 1.1 Introduction Information related to the Interent Network Infrastructure is stored and created by a number of different organizations, such as the Network Information Center (NIC), the Internet Assigned Numbers Authority (IANA), and the NSFNet Network Operations Center (NOC). The information is in general "mastered" (stored and maintained) by these organizations on a centralized basis, i.e. there is a single place to look for a definitive list of entries for these categories. This has worked well in the past but given the tremendous growth of the Internet and its number of users and networks, it is essential that a distributed scheme be used. An example of where this kind of scheme has worked is the domain name system for host naming and addressing information. The X.500 Directory standard seems to be an ideal technology for implementing this distributed method of managing network infrastructure information. X.500 allows distributed ownership of different parts of the global Directory Information Tree, and with replication can provide this information on a query basis to users rapidly. The access control and security capabilities exist in the current standards and implementation and also are being developed by IETF working groups and implementors. A worldwide pilot project involving over 20 countries is in progress, primarily for the purpose of making "white pages" or people-oriented information available. The Field Operational X.500 (FOX) project is a funded project involving several US organizations who are committed to advancing the X.500 projects to an operational status. This RFC proposes a set of interim schema to be used to hold this information in the Directory. It also discusses some limitations of the schema proposed and some possible resolutions of these limitations. 1.2 Information to be incorporated The Site Contacts information that is being loaded into the MERIT DSA is being generated weekly by the SRI NIC, and is output into two text files NETINFO:NETWORK-CONTACTS.TXT and NETINFO:ASN.TXT, both of which are available via anonymous FTP. Representative entries from both files are on the next page: INTERNET--DRAFT Interim Network Information Schema March 1991 __ __ __ __ __ 3.0.0.0 GE-INTERNET Bradt, James E. (JEB50) bradt@CRD.GE.COM (518) 387-7170 Representative entry from the Network-Contacts file __ __ __ __ __ ASN Numbers 1 The BBN Core Gateways [MB] Representative entry from the ASN.TXT file _______________________________________________________________________________ SECTION 2: NEW SCHEMA 2.1 Evolution of schema design In the initial phases of incorporating this information into the Directory, we constrained ourselves to working with object classes that had already been defined. This forced some highly nonintuitive choices for mapping the data into the object classes, but it did make the information widely available. In choosing the object class schema we did for the current implementation of the data, we wanted to contain the new NIC information, and build a schema structure which was logically appealing. 2.2 New attributes for this information New attributes used for this information are IpNetworkNumber; a string containing the network number. WhoisIdent; which has been semi-officially added to the pilotPerson object class; which is a string containing the NIC handle of the contact for the network or AS. AsNumber; a string containing the AS number. TechnicalContact; a seeAlso type reference to the technical contact for this net or AS. AdministrativeContact; a seeAlso type reference to the administrative contact for this net or AS. The ASN.1 descriptions of these attributes are on the next page. INTERNET--DRAFT Interim Network Information Schema March 1991 __ __ __ __ __ IpNetworkNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-ipnetnum)) ub-ipnetnum INTEGER ::= 15 whoisIdent ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-whois)) ::= { psiAttributeType.13 } ub-whois INTEGER ::= 15 AsNumber ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-asnum)) ub-asnum INTEGER ::= 20 TechnicalContact ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax AdministrativeContact ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax NetworkName ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax AutonomousSystemName ATTRIBUTE WITH ATTRIBUTE SYNTAX distinguishedNameSyntax _____________________________________________________________________________ ASN.1 definitions for new attributes. INTERNET--DRAFT Interim Network Information Schema March 1991 2.3 New object classes There are three new object classes to hold this information; IPNetwork, which holds ip network contact information; AutonomousSystem, which holds AS contact info; and NetworkManager, which holds personal information for Network and AS managers and contacts. These are detailed in ASN.1 below. _____________________________________________________________________________ IPNetwork OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName, ipNetworkNumber } MAY CONTAIN { TechnicalContact, AdministrativeContact } AutonomousSystem OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName, asNumber } MAY CONTAIN { TechnicalContact, AdministrativeContact } NetworkManager OBJECT-CLASS SUBCLASS OF pilotPerson MAY CONTAIN { NetworkName, AutonomousSystemName } _____________________________________________________________________________ ASN.1 definitions for new object classes The NetworkName and AutonomousSystemName attributes are needed for the NetworkManager object class because the parallel information is contained in the commonName attribute in the IPNetwork and AutonomousSystem object classes. This allows us to extend a standard RDN to each of these new object classes. 2.4 RDNs for new object classes The RDNs for each object class is as follows: IPNetwork: @o=Internet@ou=ipnetworks@cn=35.0.0.0 for network 35.0.0.0 AutonomousSystem: @o=Internet@ou=autonomous systems@cn=267 for AS 267 NetworkManager: @o=Internet@ou=Managers@cn=Hans-Werner Braun for Hans-Werner Braun INTERNET--DRAFT Interim Network Information Schema March 1991 SECTION 3: WHO WE ARE 3.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109 SECTION 4: REFERENCES [Kil89] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College Lon- don, May 1989. Also Internet Draft: DRAFT-UCL-KILLE- X500DOMAINS-00.PS [Kil90] S.E. Kille. The COSINE and Internet X.500 Naming Architecture. Internet Draft: DRAFT-IETF-OSIDS-COSINEX500-02.TXT   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <21623-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 20:34:47 +0000 Received: Fri, 22 Mar 91 15:31:54 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Mar 91 15:31:54 EST From: Chris Weider Message-Id: <9103222031.AA04071@mazatzal.merit.edu> To: disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: DISI Charter as approved at St. Louis... Gang: This is the DISI Charter as approved at St. Louis. If anyone has any changes, please let me know by Wednesday, March 27, as this will be submitted to Joyce and Ross and Rob for final acceptance then. Chris Weider, Chair DISI Draft Charter for Directory Information Services (pilot) Infrastructure ___________________ Directory Information Services (pilot) Infrastructure Working Group (DISI) Chairperson: Chris Weider, MERIT clw@merit.edu Mailing Lists: General Discussion: disi@merit.edu To Subscribe: disi-request@merit.edu Mail Archive: pub/disi-archive@merit.edu Description of Working Group: The Directory Information Services (pilot) Infrastructure Working Group is chartered to facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards. It will facilitate this deployment by producing informational RFCs intended to serve as a Directory Services "Administrator's Guide". These RFCs will relate the current usage and scope of the X.500 standard and Directory Services in North America and the world, and will contain information on the procurement, installation, and operation of various implementations of the X.500 standard. As the various implementations of the X.500 standard work equally well over TCP/IP and CLNP, the DISI working group shall not mandate specific implementations or transport protocols. The Directory Information Services (pilot) Infrastructure Working Group is an offshoot of the OSI Directory Services group, and, accordingly, is a combined effort of the OSI Integration Area and User Services Area of the IETF. The current OSIDS working group was chartered to smooth out technical differences in information storage schema and difficulties in the interoperability and coherence of various X.500 implementations. The DISI group is concerned solely with expanding the Directory Services infrastructure. As DISI will be providing information to facilitate the building of infrastructure with an eye towards truly operational status, DISI will need to form liasons with COSINE, PARADISE, and perhaps the RARE WG3. As a final document, the DISI working group shall write a charter for a new working group concerned with user services, integration, maintenance and operations of Directory Services, the Operations and Infrastructure of Directory Services (OIDS) Group. Goals and Milestones: March 1991: First IETF Meeting: review and approve the charter making any changes necessary. Examine needs and resources for the documentation to be produced, using as a first draft a document produced by Chris Weider, MERIT, which will be brought to the IETF. Assign writing assignments. Further work will be done electronically. Discuss liasons to various European Directory Services groups. July 1991: Second IETF Meeting: review and approve documentation; review and approve charter for the OIDS group. August 1991: Electronically review final draft of documentation, and, if acceptable, submit to IESG for publication. December 1991: Third IETF Meeting: Declare success and reform DISI group as OIDS group.   Return-Path: Received: from vtvm1.cc.vt.edu by bells.cs.ucl.ac.uk with SMTP inbound id <1392-0@bells.cs.ucl.ac.uk>; Fri, 22 Mar 1991 21:50:22 +0000 Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 0770; Fri, 22 Mar 91 16:50:40 EST Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 Beta) with BSMTP id 5679; Fri, 22 Mar 91 16:50:39 EST Date: Fri, 22 Mar 91 16:40:05 EST From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Minor changes to Interim Network Information I-D To: Chris Weider , disi@edu.merit, osi-ds@uk.ac.ucl.cs Message-Id: <910322.164005.EST.VALDIS@vtvm1.cc.vt.edu> In-Reply-To: <9103222041.AA04094@mazatzal.merit.edu> On Fri, 22 Mar 91 15:41:37 EST you said: >Gang: > Here's the last revision of the Interim Network Information Schema >Internet Draft. The changes are extremely minor, and involve expanding the >name of one attribute and one object class. This will be placed in the >appropriate repositories..... > >Chris Weider >2.2 New attributes for this information > >New attributes used for this information are > > IpNetworkNumber; a string containing the network number. Chris: I would recommend that before this goes to 'informational RFC' status, that somebody fill in the OID numbers you are using for these attribute and object classes. As it stands now, I can't add it and poke at your DSA with any of my tools (quipu 'dish' or whatever) because your stuff isn't in my OIDtables yet. And with something like this, not being able to poke at it restricts the ability to check if it REALLY addresses the problem well. Of course, a reply of "We haven't actually LOADED it into a DSA, we'll add the OID numbers when we pick some" is also acceptable.... My only other comment has already been voiced by others - namely, that any scheme should also allow the representation of OSI-based networks as well as TCP/IP nets. Given that the routing group is currently experimenting with multi-protocol routing in the core, I think we'll need to represent this a lot sooner than we might like (after all, it's usually NOT a long-existing, stable net that you need the contact for - you grab for that info when some new bogon net has gone beserk and is doing Something Bad...) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute   Return-Path: Received: from shum.huji.ac.il by bells.cs.ucl.ac.uk with SMTP inbound id <1209-0@bells.cs.ucl.ac.uk>; Sun, 24 Mar 1991 07:08:59 +0000 Received: by shum.huji.ac.il (HU-2.5) id AA21436; Sun, 24 Mar 91 10:08:36 +0300 From: Juliana Solomon Date: Sun, 24 Mar 91 10:08:36 +0300 Message-Id: <9103240708.AA21436@shum.huji.ac.il> To: osi-ds@uk.ac.ucl.cs Subject: request Please sign me up in your list. Thanks a lot.   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11932-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 08:23:24 +0000 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Mon, 25 Mar 91 08:23:20 +0000 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 8th March - Friday 23rd March.; Probes preformed from ULCC, UCL, STC, Brunel and by Mark Prior of Adelaide University. Bind Fail %age Best Worst Ave Address GB: False Cobra (Future Giant Tortoise) 55 0 100.00 1.2 2.0 1.40 Janet 55 0 100.00 2.4 4.5 2.59 X121 114 13 88.60 0.4 39.8 8.22 Internet 55 55 0.00 0.0 0.0 0.00 IXI Vampire Bat (GB backup) 130 2 98.46 1.2 12.6 2.21 Janet 55 1 98.18 2.0 8.1 2.99 IXI 55 1 98.18 3.4 15.5 4.94 Janet 55 55 0.00 0.0 0.0 0.00 NS 55 55 0.00 0.0 0.0 0.00 IXI Coypu (Thorn acces pt to quipu) 55 2 96.36 1.0 3.2 1.52 Local Ether 55 2 96.36 1.3 12.9 2.08 Janet 131 5 96.18 1.3 11.2 2.83 Janet 90 4 95.56 2.5 7.6 3.74 X121 118 28 76.27 0.5 95.4 18.35 Internet Giant Tortoise (Old Root, GB Master) 55 7 87.27 1.9 4.2 2.32 Janet 124 44 64.52 0.6 107.4 7.80 Internet 90 42 53.33 1.8 3.2 2.08 X121 131 131 0.00 0.0 0.0 0.00 Janet 55 55 0.00 0.0 0.0 0.00 IXI 56 56 0.00 0.0 0.0 0.00 IXI Passionflower Leaf Beetle (GB Domain name information) 124 40 67.74 0.5 93.8 11.62 Internet 47 47 0.00 - - - Janet 47 47 0.00 0.0 0.0 0.00 IXI 47 47 0.00 0.0 0.0 0.00 X121 Maned Sloth (Edinburgh, DSA holding NRS info) 131 70 46.56 1.7 7.3 3.13 Janet 55 34 38.18 5.2 101.6 82.16 Janet ES: Cayman (Madrid Uni.) 34 1 97.06 5.2 119.4 11.85 '0101'H/Int-X25 56 10 82.14 2.1 28.7 5.20 '0101'H/IXI 55 16 70.91 7.3 50.1 17.37 Int-X.25 125 45 64.00 6.7 91.1 30.01 Internet 55 55 0.00 0.0 0.0 0.00 IXI Iguana (ES Master. Programa IRIS) 56 14 75.00 2.4 23.3 7.89 '0101'H/IXI 55 28 49.09 10.0 49.3 24.98 Int-X.25 123 78 36.59 3.9 112.2 35.66 Internet 35 23 34.29 5.1 15.7 7.38 '0101'H/Int-X25 12 12 0.00 0.0 0.0 0.00 '0101'H/NS 37 37 0.00 0.0 0.0 0.00 '0101'H/NS 55 55 0.00 0.0 0.0 0.00 IXI DE: Margay (GMD/F3, DE backup) 34 1 97.06 3.9 8.4 5.01 '0101'H/Int-X25 55 21 61.82 2.2 5.7 3.27 '0101'H/IXI 55 21 61.82 7.3 58.5 13.30 Int-X.25 124 51 58.87 3.9 115.1 30.36 Internet 55 55 0.00 0.0 0.0 0.00 IXI Puma (GMD/FOKUS) 34 2 94.12 4.0 30.7 6.78 '0101'H/Int-X25 55 13 76.36 2.1 64.6 5.05 '0101'H/IXI 75 21 72.00 3.3 82.1 16.38 Internet 55 22 60.00 6.4 106.5 13.98 Int-X.25 43 26 39.53 12.8 116.4 39.11 Internet 12 12 0.00 0.0 0.0 0.00 '0101'H/NS 55 55 0.00 0.0 0.0 0.00 IXI CH: Condor (ETH Zurich) 35 2 94.29 3.7 8.7 4.18 Int-X25 55 21 61.82 4.5 86.0 13.09 Int-X.25 120 50 58.33 2.9 107.6 12.98 Internet Chinchilla (Swiss Master) 17 3 82.35 8.5 22.7 13.74 Internet 103 34 66.99 8.7 116.7 24.83 Internet 34 34 0.00 0.0 0.0 0.00 Int-X25 55 55 0.00 - - - Int-X.25 NO: Boa Constrictor (Norway Backup) 34 3 91.18 3.5 14.6 5.96 '0101'H/Int-X25 56 14 75.00 3.3 21.1 7.14 '0101'H/IXI 121 48 60.33 6.4 113.7 34.24 Internet 56 26 53.57 4.4 42.7 12.18 Int-X.25 56 56 0.00 0.0 0.0 0.00 IXI Electric Eel (Norway Master) 56 6 89.29 2.0 11.5 3.94 '0101'H/IXI 35 5 85.71 3.6 7.7 4.74 '0101'H/Int-X25 55 14 74.55 4.0 55.5 10.21 Int-X.25 122 39 68.03 2.9 104.5 21.61 Internet 55 55 0.00 0.0 0.0 0.00 IXI AU: Anaconda (AU Master) 119 19 84.03 1.2 81.8 9.21 Internet 34 8 76.47 5.8 8.0 6.30 '0101'H/Int-X25 56 14 75.00 7.2 107.1 23.90 Int-X.25 Bush Dog (master for AU (phony)) 122 39 68.03 0.7 106.6 18.09 Internet US: Alpaca (US master) 125 30 76.00 2.2 77.4 10.17 Internet Fruit Bat (US@l=NY master) 122 33 72.95 3.3 109.3 18.55 Internet Giant Anteater (Various slave) 120 43 64.17 3.1 103.7 13.81 Internet CA: Pangolin (Northern Telecom Master) 116 33 71.55 3.7 99.7 19.27 Internet 55 55 0.00 0.0 0.0 0.00 '0101'H/NS Wayne Gretzky 124 84 32.26 5.1 101.8 21.33 Internet IS Elephant Seal (IS Master) 122 45 63.11 11.8 111.7 38.64 Internet FI; Jaguar (Finland Master) 122 48 60.66 2.6 120.5 32.05 Internet 89 56 37.08 3.9 11.8 5.89 '0101'H/X121 55 55 0.00 0.0 0.0 0.00 '0101'H/NS SE: Hummingbird (Sweden Master) 123 56 54.47 4.7 101.4 26.82 Internet 90 51 43.33 4.0 98.3 14.80 '0101'H/X121 NL: Agouti (NL Slave) 125 63 49.60 4.2 44.8 15.20 Internet Hornero (NL Slave) 90 49 45.56 3.1 109.7 11.17 '0101'H/X121 121 82 32.23 6.0 101.9 23.19 Internet DK Axolotl (DK master) 125 78 37.60 4.6 111.9 38.71 Internet   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5835-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 12:28:05 +0000 To: Valdis Kletnieks cc: Chris Weider , disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Minor changes to Interim Network Information I-D Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 22 Mar 91 16:40:05 -0500. <910322.164005.EST.VALDIS@vtvm1.cc.vt.edu> Date: Mon, 25 Mar 91 12:28:04 +0000 Message-ID: <2016.669904084@UK.AC.UCL.CS> From: Steve Kille Vladis, The approach to allocating pilot OIDs is that they all go into the Schema RFC. This means that sites do not need to go around collecting lots of OIDs. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5752-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 12:26:41 +0000 To: colella@gov.nist.ncsl.osi3 cc: Christian.Huitema@fr.inria.mirsa, clw@edu.merit, Juha.Heinanen@fi.funet, ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit Subject: Re: Interim Network Infrastructure Schema I-D Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 22 Mar 91 14:15:41 -0500. <9103221915.AA01924@emu.ncsl.nist.gov> Date: Mon, 25 Mar 91 12:26:40 +0000 Message-ID: <2004.669904000@UK.AC.UCL.CS> From: Steve Kille Another requirement that needs to be added is that the fanout is manageable. A sinlge level for all NSAPs (or a very very shallow tree) might meet all the other requierments, but it would not be useful. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6077-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 12:37:40 +0000 To: Chris Weider cc: disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Minor changes to Interim Network Information I-D Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 22 Mar 91 15:41:37 -0500. <9103222041.AA04094@mazatzal.merit.edu> Date: Mon, 25 Mar 91 12:37:37 +0000 Message-ID: <2088.669904657@UK.AC.UCL.CS> From: Steve Kille Chris, Two small things: Discussion list: you should discuss this draft on a single list. I would suggest that osi-ds is the right one. Up to you tho. I think that this should be on the standards track. It is not a protocol per se, but it does affect "what goes over the wire", and is defining procedures to be followed in order to achieve services. Steve   Return-Path: Received: from kwai.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <13426-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 16:03:52 +0000 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 25 Mar 91 17:01:13+0100 Date: 25 Mar 91 17:01:13+0100 From: Christian Huitema Message-ID: <9103251601.AA04325@jerry.inria.fr> To: Juha Heinanen cc: colella@gov.nist.ncsl.osi3, clw@edu.merit, ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit Subject: Interim Network Infrastructure Schema I-D References: , <9103231117.AA09099@mirsa.inria.fr> Juha, You should think twice. If you do a reverse search by NSAP, you want to be able to use it for one of two purposes: authentication and routing. Authentication means that the entry should point to something describing the "open system" through which the call is routed. Routing is still a dream, but it could mean something like describing the snpa addresses on various networks, or the transit networks that could be used. In any case, the NSAP is not the name of a person; the "owner" or "administrator" attribute attached to the NSAP should be used for that purpose! Christian Huitema PS. Regarding the structure of NSAPs: you can always tell from the AFI if the DSP is made of decimal digits or binary octets. Hexadecimal digits are never used!   Return-Path: Received: from kwai.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <14902-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 16:44:59 +0000 X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 25 Mar 91 17:42:55+0100 Date: 25 Mar 91 17:42:55+0100 From: Christian Huitema Message-ID: <9103251642.AA04487@jerry.inria.fr> To: Juha Heinanen cc: colella@gov.nist.ncsl.osi3, clw@edu.merit, ietf-osi-nsap@gov.nist.ncsl.osi3, katz@edu.merit, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit References: , <9103251613.AA07822@mirsa.inria.fr> Juha, We will sooner or later have to solve routing issues in large scale networks. IS/IS, as defined (distance vector for interdomain routing) does not scale well; neither does ES/IS for a large public net. Directory access will sooner or later have to be used to implement e.g. policy routing, mapping to large scale subnets, initialization of gateways. I know that nothing is defined yet; but having a vehicle handy would not hurt... Christian Huitema   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <18077-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 18:37:21 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA25170; Mon, 25 Mar 91 13:36:41 -0500 Date: Mon, 25 Mar 91 13:36:41 -0500 From: Dave Katz Message-Id: <9103251836.AA25170@merit.edu> To: Christian.Huitema@fr.inria.mirsa, clw@edu.merit, colella@gov.nist.ncsl.osi3 Subject: Re: Interim Network Infrastructure Schema I-D Cc: Juha.Heinanen@fi.funet, clw@edu.merit, ietf-osi-nsap@gov.nist.ncsl.osi3, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit One should be careful about the scope of NSAP structures--it may well be the case that some people will want to deviate from the GOSIP structure, for example, while using GOSIP addressing. This is not necessarily a good idea, but is within the realm of possibility. The most likely deviation will be in the system ID field; DIS 10589 allows any length to be used (within reason) so long as it is consistent within the routing domain. For what it's worth. From clw@merit.edu Fri Mar 22 13:43:32 1991 Received: from mazatzal.merit.edu by merit.edu (5.65/1123-1.0) id AA18605; Fri, 22 Mar 91 13:43:25 -0500 Received: Fri, 22 Mar 91 13:39:42 EST by mazatzal.merit.edu (5.51/1.6) Date: Fri, 22 Mar 91 13:39:42 EST From: Chris Weider Message-Id: <9103221839.AA03913@mazatzal.merit.edu> To: Christian.Huitema@mirsa.inria.fr, colella@osi3.ncsl.nist.gov Subject: Re: Interim Network Infrastructure Schema I-D Cc: Juha.Heinanen@funet.fi, clw@merit.edu, ietf-osi-nsap@osi3.ncsl.nist.gov, katz@merit.edu, mak@merit.edu, osi-ds@cs.ucl.ac.uk, skh@merit.edu Status: RO Christian: I think that, in places where the structure has been defined (U.S. GOSIP) for example, that we can and should build a portion of the DIT to reflect the structure. As I understand it, each subtree of the DIT can have a different structure, so that should make things O.K. It might be better to have a structured part of the DIT which is aliased to the NSAP which has been stored as in 1) or 2), but I think that we also want to make things as 'user-friendly' as possible. Chris   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <20475-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 21:01:55 +0000 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA28129; Mon, 25 Mar 91 16:01:06 -0500 Date: Mon, 25 Mar 91 16:01:06 -0500 From: Dave Katz Message-Id: <9103252101.AA28129@merit.edu> To: Christian.Huitema@fr.inria.mirsa, Juha.Heinanen@fi.funet Subject: Interdomain Routing Cc: clw@edu.merit, colella@gov.nist.ncsl.osi3, ietf-osi-nsap@gov.nist.ncsl.osi3, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit >IS/IS, as defined (distance vector for interdomain routing) does not scale >well; neither does ES/IS for a large public net. I assume you're talking about IDRP (which isn't true distance vector, but rather a hybrid approach). I'd be interested in hearing your views on how IDRP scales; perhaps we should take the discussion off of this list so as to not bore the audience...   Return-Path: Received: from thumper.bellcore.com by bells.cs.ucl.ac.uk with SMTP inbound id <27375-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 21:49:21 +0000 Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for osi-ds@cs.ucl.ac.uk; Mon, 25 Mar 91 16:49:43 EST Received: by chiya.bellcore.com (5.57/4.7) id AA29580; Mon, 25 Mar 91 16:50:06 -0500 Date: Mon, 25 Mar 91 16:50:06 -0500 From: tsuchiya@com.bellcore.thumper (Paul Tsuchiya) Message-Id: <9103252150.AA29580@chiya.bellcore.com> To: Christian.Huitema@fr.inria.mirsa, Juha.Heinanen@fi.funet, katz@edu.merit Subject: Re: Interdomain Routing Cc: clw@edu.merit, colella@gov.nist.ncsl.osi3, ietf-osi-nsap@gov.nist.ncsl.osi3, mak@edu.merit, osi-ds@uk.ac.ucl.cs, skh@edu.merit > > >IS/IS, as defined (distance vector for interdomain routing) does not scale > >well; neither does ES/IS for a large public net. > I assume you're talking about IDRP (which isn't true distance vector, but > rather a hybrid approach). I'd be interested in hearing your views on > how IDRP scales; perhaps we should take the discussion off of this list so > as to not bore the audience... > I'd like to hear it too. May as well keep it on the list. PT   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Mon, 25 Mar 1991 22:58:39 +0000 Date: Mon, 25 Mar 1991 22:58:39 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.541:25.02.91.22.58.39] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Mon, 25 Mar 1991 22:58:39 +0000) From: "Andrew Macpherson (Postmaster)" Message-ID: <"15542 Mon Mar 25 22:58:29 1991"@stl.stc.co.uk> To: Paul Tsuchiya Cc: ietf-osi-nsap@gov.nist.ncsl.osi3, osi-ds@uk.ac.ucl.cs Subject: Re: Interdomain Routing Second that motion Paul Tsuchiya wrote: | I'd like to hear it too. May as well keep it on the list. | | PT   Return-Path: Received: from earn-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <11636-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 23:08:10 +0000 Received: from UKACRL by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 7767; Mon, 25 Mar 91 23:02:58 GMT Received: from IRUCCIBM.BITNET by UKACRL.BITNET (Mailer R2.07) with BSMTP id 9681; Mon, 25 Mar 91 23:02:58 GM Received: from IRUCCVAX.UCC.IE (CBTS8001) by IRUCCIBM.BITNET (Mailer R2.07) with BSMTP id 6404; Mon, 25 Mar 91 22:48:30 I Date: Mon, 25 Mar 91 22:48 GMT From: Peter Flynn UCC Subject: Sub To: disi@edu.MERIT, osi-ds@uk.ac.ucl.cs X-VMS-To: IN%"disi@merit.edu",IN%"osi-ds@cs.ucl.ac.uk" As Donal will be handling the Irish X.500 participation, I would be grateful if you would remove me from the DISI and OSI-DS lists. ///Peter   Return-Path: Received: from enet-gw.pa.dec.com by bells.cs.ucl.ac.uk with SMTP inbound id <14495-0@bells.cs.ucl.ac.uk>; Mon, 25 Mar 1991 23:24:34 +0000 Received: by enet-gw.pa.dec.com; id AA12865; Mon, 25 Mar 91 15:23:47 -0800 Message-Id: <9103252323.AA12865@enet-gw.pa.dec.com> Received: from bigfut.enet; by decwrl.enet; Mon, 25 Mar 91 15:24:11 PST Date: Mon, 25 Mar 91 15:24:11 PST From: 25-Mar-1991 1801 To: christian.huitema@fr.inria.mirsa, "ietf-osi-nsap@osi3.ncsl.nist.gov"@com.dec.Pa, "osi-ds@cs.ucl.ac.uk"@com.dec.Pa Subject: re: scaling of IS-IS Christian; > > We will sooner or later have to solve routing issues in large scale networks. > IS/IS, as defined (distance vector for interdomain routing) does not scale > well; neither does ES/IS for a large public net. Directory access will sooner > or later have to be used to implement e.g. policy routing, mapping to large > scale subnets, initialization of gateways. I know that nothing is defined yet; > but having a vehicle handy would not hurt... > > Christian Huitema > Well, I guess it depends upon what you mean by "scale well". IS-IS is designed to scale well to routing domains with thousands of routers. However, it is not designed to work in the case of a single non-broadcast subnet (such as a public data network) which has thousands of routers on it. I would expect that such "very branchy" networks will tend to NOT be internal to a single routing domain, but rather used to interconnect large numbers of routing domains. Thus, dealing with thousands of routers on a single network is VERY important, but is probably something that an inter-domain routing protocol has to deal with (rather than the current IS-IS intra-domain protocol). My gut feeling is that our current notion of treating large public networks as basically a branchy data link, over which we interconnect large numbers of routers, is probably not going to work in this case. Thus, rather than basically offering a link layer service, I think that the very branchy ("public") networks will need to basically provide a network layer service. The "border" router that interconnects a corporate network to the public network will not think that it is directly connected to thousands of other corporate networks over the link service, but rather will think that it is connected to a single "public service" router. I also think that we need to assign NSAP addresses in a way which allows a single prefix to be used to represent an enormous number of corporate networks. Thus, for example, if there are 500,000 corporate networks in the US, connected to 100 regionals, then we need to have the "public" routers telling the corporate routers that they can offer service to about four or five NSAPS (one for the Gosip ICD, one for the USA DCC, one for any X.121 address starting with the USA DCC, and one for any ISDN address which starts with "USA" -- possibly one to a global default route), or possibly to 100 prefixes (one for each regional), not to 500,000 prefixes. Finally, "public" networks (by "public" I mean a network which offers an interconnection service to a very large number of subscribers, such as PTTs and NSFNET regionals) will probably have to either insist that subscribers use the address that the "public" network assigns them, or they will have to charge enough for the privelege of using your own address (assigned from another source) that few folks will actually do this. I personally prefer the latter solution, since it will allow such "foreign" addresses to be used in those cases where there is a strong economic reason to do so. Ross   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <24373-0@bells.cs.ucl.ac.uk>; Tue, 26 Mar 1991 12:56:41 +0000 To: clw@edu.merit cc: osi-ds@uk.ac.ucl.cs Subject: Interime Schema for Network Information Phone: +44-71-380-7294 Date: Tue, 26 Mar 91 12:56:40 +0000 Message-ID: <1285.669992200@UK.AC.UCL.CS> From: Steve Kille A few comments on this spec. An example at the back, showing use of the linkage attributes from network to manager and vice versa would be useful. I think that networks should be named by thier common name (i.e., CN=Merit and not ipNetworkNumber=35.0.0.0 Searching can be used if the network number is given as a key. I'm sending this note to osi-ds, as (just re-reading the DISI charter) I think that this is the most appropriate forum. Steve   Return-Path: Received: from enet-gw.pa.dec.com by bells.cs.ucl.ac.uk with SMTP inbound id <10089-0@bells.cs.ucl.ac.uk>; Tue, 26 Mar 1991 15:13:54 +0000 Received: by enet-gw.pa.dec.com; id AA14680; Tue, 26 Mar 91 07:13:23 -0800 Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-osi-nsap@osi3.ncsl.nist.gov@Pa.dec.com; Tue, 26 Mar 91 10:13:00 EST Received: by chiya.bellcore.com (5.57/4.7) id AA00236; Tue, 26 Mar 91 10:13:25 -0500 Date: Tue, 26 Mar 91 10:13:25 -0500 From: tsuchiya@com.bellcore.thumper (Paul Tsuchiya) Message-Id: <9103261513.AA00236@chiya.bellcore.com> To: "ietf-osi-nsap@osi3.ncsl.nist.gov"@com.dec.Pa, "osi-ds@cs.ucl.ac.uk"@com.dec.Pa, callon@com.dec.enet.bigfut, christian.huitema@fr.inria.mirsa Subject: re: scaling of IS-IS > > My gut feeling is that our current notion of treating large > public networks as basically a branchy data link, over which we > interconnect large numbers of routers, is probably not going to > work in this case. Thus, rather than basically offering a link > layer service, I think that the very branchy ("public") networks > will need to basically provide a network layer service. The > "border" router that interconnects a corporate network to the > public network will not think that it is directly connected to > thousands of other corporate networks over the link service, but > rather will think that it is connected to a single "public > service" router. I also think that we need to assign NSAP With respect to this, in IPLPDN (IP over Large Public Data Networks), we are defining this "route server" function, in the context of BGP. Basicly, there are two modes. In one, each border router talks to a route server, and learns about all reachable networks. In the other mode, a router learns "on demand" how to reach networks, possibly via a redirect, or via a query response of some sort. PT   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <8576-0@bells.cs.ucl.ac.uk>; Wed, 27 Mar 1991 16:03:25 +0000 Received: Wed, 27 Mar 91 11:00:39 EST by mazatzal.merit.edu (5.51/1.6) Date: Wed, 27 Mar 91 11:00:39 EST From: Chris Weider Message-Id: <9103271600.AA08386@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: DISI minutes - St. Louis From disi-owner@merit.edu Wed Mar 27 10:44:53 1991 Received: Wed, 27 Mar 91 10:44:52 EST by mazatzal.merit.edu (5.51/1.6) Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA03071; Wed, 27 Mar 91 10:42:40 -0500 Received: from venera.isi.edu by merit.edu (5.65/1123-1.0) id AA03067; Wed, 27 Mar 91 10:42:36 -0500 Received: from akamai.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 27 Mar 91 07:41:44 -0800 Date: Wed, 27 Mar 91 07:41:43 PST From: jkrey@ISI.EDU Posted-Date: Wed, 27 Mar 91 07:41:43 PST Message-Id: <9103271541.AA04230@akamai.isi.edu> Received: by akamai.isi.edu (4.0/4.0.3-4) id ; Wed, 27 Mar 91 07:41:43 PST To: disi@merit.edu, mdavies@nri.reston.va.us, us-wg@nnsc.nsf.net Subject: USWG/DISI minutes - St. Louis Cc: jkrey@ISI.EDU User Services Working Group Report IETF - St Louis Monday, March 10th - 1:30pm - 3:30pm Chair: Joyce K. Reynolds/ISI (jkrey@isi.edu) Announcements: -New Working Group - Internet User Glossary (USER-GLOSS) -New Working Group - "Son of NOCTOOLS" (NOCTOOL2) -New Working Group - Directory Information Services Infrastructure (DISI) -Q/A for New Internet Users - published (RFC 1206, FYI 4) -Q/A for Experienced Internet Users - published (RFC 1207, FYI 7) -SSPHWG - met Tuesday afternoon, 3/12, 1:30pm-3:30pm -NISI - met Wednesday afternoon, 3/13, 1:30pm-3:30pm Discussions/Reports: QUAIL - presented by: Gary Malkin Gary led a brief discussion of the two currently issued Quail documents, and requested additional volunteers to continue to help monitor the mailing lists, and to contribute to future updates of Quail. DISI - presented by: Chris Weider The rest of the USWG session was devoted to the new working group, DISI. Chris Weider led the session, which included discussion on the current charter, current deployment and players, available implementations, documents to be produced, and how this group segues into User Services activities. 1) In reviewing the current charter, suggestions were made to change the last paragraph to include "maintenance", and in the 2nd paragraph, change "building" to "providing" information. 2) Chris will amend the charter, and send out a new one for approval. The "combined efforts" of the OSI Integration Area and the User Services Area was discussed, as was what the current deployment of DSAs are. There are curretnly more than 200 DSAs in 20 countries! 3) What organizations are currently building infrastructure? The FOX project at ISI, Merit, PSI, and SRI. In Europe, PARADISE. Quipu - Part of the ISODE, IAN at UBC, NIST (not fully functional yet). 4) Documents to be produced by DISI. Vol. 1 - Advantage Document; What should I do it,, even if I know what it is?? Vol. 2 - Implementation Document; rapidly changing. Would provide current implementation & interoperability profiles. Vol. 3 - Advanced usages document/administrators guide (~1 year life span). 5) Writing Assignments Vol. 1 - Chirs Weider, Sergio Heker and Joyce Reynolds Vol. 2 - Ruth Lang and Russ Wright Vol. 3 - Assignments will be made at the next IETF in Atlanta.   Return-Path: Received: from GOVERNMENT-CENTER.BBN.com by bells.cs.ucl.ac.uk with SMTP inbound id <3200-0@bells.cs.ucl.ac.uk>; Fri, 29 Mar 1991 15:33:13 +0000 Date: Fri, 29 Mar 91 10:31:19 EST From: John Lowry To: osi-ds@uk.ac.ucl.cs Subject: 2 Questions Would some kind souls have pity on a poor implementor and answer a couple of questions ? I recognize that there are plethora of opinions ... Gentle answers are prefered... 1) Is there agreement on or enlightenment about the meaning of the statement in X.509 p.8.7 where it states that the members of a SET OF shall be encoded in the ascending order of their octet value ? In the case of RDNs where one might have two AttributeValueAssertions, what specific component is evaluated ? Is it the AVA, the encoded AVA, the value ? What is the sort mechanism ? 2) In RDNs where one might specify two or more AttributeValueAssertions, are there constraints on which ones may appear ? The text is ambiguous to me. The text could be read to imply that the only restriction is that AVAs have exactly one value. However, some have read it to imply that one cannot have two AVAs with the same type (ObjectIdentifiers) even if the AVAs have different values. Can one have two AVAs with identical types (ObjectIdentifiers) but with different values ? Can one have two identical values with different types ? Is the restriction looser, ie. are you restricted only from having two identical AVAs (same type and value) ? Could someone please give me a canonicalized statement ? Examples: 1) (Same type, different value) RDN AVA type=CN value=Ms. Margaret Smith AVA type=CN value=Mrs. Margaret Jones 2) (Different type, same value) RDN AVA type=stateOrProvinceName value=New York AVA type=localityName value=New York Thanks, John Lowry   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <320-0@bells.cs.ucl.ac.uk>; Sat, 30 Mar 1991 07:05:42 +0000 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <255-3@sun2.nsfnet-relay.ac.uk>; Sat, 30 Mar 1991 06:39:43 +0000 Received: from merit.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa18748; 30 Mar 91 6:08 GMT Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA22464; Sat, 30 Mar 91 01:37:09 -0500 Received: by home.merit.edu (4.1/dumb-0.9) id AA05508; Sat, 30 Mar 91 01:37:08 EST From: mak@edu.merit Message-Id: <9103300637.AA05508@home.merit.edu> To: Steve Kille Cc: clw@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Interime Schema for Network Information In-Reply-To: Your message of "Tue, 26 Mar 91 12:56:40 GMT." <1285.669992200@UK.AC.UCL.CS> Date: Sat, 30 Mar 91 01:37:07 -0500 Steve, I don't think the "common names" of IP networks are real names, ie. they aren't domain names and no one refers to these names currently except the NIC. So it doesn't seem to make sense to key on this artificial name. Tim Howes has a version of quipu that can optimize searches based on the net number. Mark --- A few comments on this spec. An example at the back, showing use of the linkage attributes from network to manager and vice versa would be useful. I think that networks should be named by thier common name (i.e., CN=Merit and not ipNetworkNumber=35.0.0.0 Searching can be used if the network numbe r is given as a key. I'm sending this note to osi-ds, as (just re-reading the DISI charter) I think that this is the most appropriate forum. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5387-0@bells.cs.ucl.ac.uk>; Tue, 2 Apr 1991 13:01:06 +0100 To: John Lowry cc: osi-ds@uk.ac.ucl.cs Subject: Re: 2 Questions Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 29 Mar 91 10:31:19 -0500. Date: Tue, 02 Apr 91 13:01:03 +0100 Message-ID: <1051.670593663@UK.AC.UCL.CS> From: Steve Kille >From: John Lowry >To: osi-ds@uk.ac.ucl.cs >Subject: 2 Questions >Date: Fri, 29 Mar 91 10:31:19 EST >Would some kind souls have pity on a poor implementor and >answer a couple of questions ? I recognize that there are >plethora of opinions ... Gentle answers are prefered... >1) Is there agreement on or enlightenment about the meaning > of the statement in X.509 p.8.7 where it states that > the members of a SET OF shall be encoded in the > ascending order of their octet value ? In the case of > RDNs where one might have two AttributeValueAssertions, > what specific component is evaluated ? Is it the AVA, > the encoded AVA, the value ? What is the sort > mechanism ? > This refers to the encoding. A clearer spec can be found in the laters DER (Distinguished Encoiding Rules) draft of the ASN.1 group. >2) In RDNs where one might specify two or more > AttributeValueAssertions, are there constraints on > which ones may appear ? I believe so > The text is ambiguous to me. > The text could be read to imply that the only > restriction is that AVAs have exactly one value. yes > However, some have read it to imply that one cannot > have two AVAs with the same type (Obj >ectIdentifiers) > even if the AVAs have different values. This is the case > Can one have > two AVAs with identical types (ObjectIdentifiers) but > with different values ? No > Can one have two identical > values with different types ? yes > Is the restriction > looser, ie. are you restricted only from having two > identical AVAs (same type and value) ? Could someone > please give me a canonicalized statement ? > Examples: > 1) (Same type, different value) > RDN > AVA > type=CN > value=Ms. Margaret Smith > AVA > type=CN > value=Mrs. Margaret Jones Illegal > 2) (Different type, same value) > RDN > AVA > type=stateOrProvinceName > value=New York > AVA > type=localityName > value=New York Legal >Thanks, >John Lowry Steve   Return-Path: Received: from CCV1.BBN.com by bells.cs.ucl.ac.uk with SMTP inbound id <6909-0@bells.cs.ucl.ac.uk>; Tue, 2 Apr 1991 15:31:47 +0100 To: Steve Kille cc: John Lowry , osi-ds@uk.ac.ucl.cs, solo@com.BBN Subject: Re: 2 Questions In-reply-to: Your message of Tue, 02 Apr 91 13:01:03 +0100. <1051.670593663@UK.AC.UCL.CS> Date: Tue, 02 Apr 91 09:27:38 -0500 From: solo@com.BBN Steve, I am still not clear on the interpretation of the DER for SET OF types. The draft revised DER spec I have does not provide any additional enlightenment. Is the intent to sort on the value of the first octet of the value, the entire value viewing the entire item as an integer, etc? For example, if I have a SET OF INTEGER where the values are 0x234 and 0x40, which is first. Similarly, if I have a SET OF OCTET STRING where values are "ACDJK", "X", and "ABYZ", what is the proper order? Thanks, Dave   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <10192-0@bells.cs.ucl.ac.uk>; Tue, 2 Apr 1991 18:34:56 +0100 Received: Tue, 2 Apr 91 12:32:15 EST by mazatzal.merit.edu (5.51/1.6) Date: Tue, 2 Apr 91 12:32:15 EST From: Chris Weider Message-Id: <9104021732.AA13743@mazatzal.merit.edu> To: S.Kille@uk.ac.ucl.cs, clw@edu.merit Subject: Re: Interime Schema for Network Information Cc: osi-ds@uk.ac.ucl.cs Steve and all other interested parties... I will be making the changes as discussed below to the Interim Schema document and then sending it out a final time, to reduce my incremental load. I will do just as you're doing, taking comments and then I will discuss this (or have Mark discuss this) at the Video Conference of OSI-DS. >From S.Kille@cs.ucl.ac.uk Tue Mar 26 07:54:45 1991 >A few comments on this spec. > >An example at the back, showing use of the linkage attributes from network >to manager and vice versa would be useful. > It shall be done... :^) >I think that networks should be named by thier common name (i.e., CN=Merit >and not ipNetworkNumber=35.0.0.0 Searching can be used if the network number >is given as a key. I think that this could be quite misleading. The first point is that not every network has a common Name, which my software generates automatically if it doesn't have one. The second is that I'm not sure if the name is required to be unique, since no one uses it. The third point is that eventually one would like to be able to look up say "GM's nets" or something general like that in which case searching would be facilitated by not having unique common names. > >I'm sending this note to osi-ds, as (just re-reading the DISI charter) I >think that this is the most appropriate forum. > I think that osi-ds is the most appropriate forum for this material. I wanted to know if it would be o.k. with you if this paper appeared under the imprimus if the OSI-DS group instead of the DISI group as is currently listed. Also, I am willing to put this paper on the standards track, but I think it will be rapidly superseded by whatever Ruth Lang and FOX come up with for the whois information. If you think that it should be on the track, though, I will follow your lead. Also, due to the DISI charter limitation, I think that all of the schema and DIT papers should appear and be discussed on the OSI-DS list only. Although I think that the DSA probes your folks are doing should be discussed on the DISI list also, as I would like to steer DISI into working on reliability and operations issues also. > >Steve Chris   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <21275-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 04:33:40 +0100 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA15687; Tue, 2 Apr 91 22:34:28 -0500 Received: by home.merit.edu (4.1/dumb-0.9) id AA11884; Tue, 2 Apr 91 22:34:27 EST From: mak@edu.merit Message-Id: <9104030334.AA11884@home.merit.edu> To: Chris Weider Cc: S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Subject: Re: Interime Schema for Network Information In-Reply-To: Your message of "Tue, 02 Apr 91 12:32:15 EST." <9104021732.AA13743@mazatzal.merit.edu> Date: Tue, 02 Apr 91 22:34:26 -0500 I'd like to discourage you from "standardizing" this, or anything with the word Interim at the front of the title. What possible good can come of that? Actually I'm not sure if I will be able to attend the video conference. Mark ---- Steve and all other interested parties... I will be making the changes as discussed below to the Interim Schema docum ent and then sending it out a final time, to reduce my incremental load. I will do just as you're doing, taking comments and then I will discuss thi s (or have Mark discuss this) at the Video Conference of OSI-DS. >From S.Kille@cs.ucl.ac.uk Tue Mar 26 07:54:45 1991 >A few comments on this spec. > >An example at the back, showing use of the linkage attributes from network >to manager and vice versa would be useful. > It shall be done... :^) >I think that networks should be named by thier common name (i.e., CN=Merit >and not ipNetworkNumber=35.0.0.0 Searching can be used if the network numb er >is given as a key. I think that this could be quite misleading. The first point is that not every network has a common Name, which my software generates automatically if it doesn't have one. The second is that I'm not sure if the name is required to be unique, since no one uses it. The third point is that eventu ally one would like to be able to look up say "GM's nets" or something general like that in which case searching would be facilitated by not having unique common names. > >I'm sending this note to osi-ds, as (just re-reading the DISI charter) I >think that this is the most appropriate forum. > I think that osi-ds is the most appropriate forum for this material. I wa nted to know if it would be o.k. with you if this paper appeared under the impri mus if the OSI-DS group instead of the DISI group as is currently listed. Also, I am willing to put this paper on the standards track, but I think it will be rapidly superseded by whatever Ruth Lang and FOX come up with for t he whois information. If you think that it should be on the track, though, I will follow your lead. Also, due to the DISI charter limitation, I think that all of the schema an d DIT papers should appear and be discussed on the OSI-DS list only. Although I think that the DSA probes your folks are doing should be discussed on the DISI list also, as I would like to steer DISI into working on reliability and operations issues also. > >Steve Chris   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3875-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 09:04:12 +0100 To: osi-ds@uk.ac.ucl.cs cc: J.Crowcroft@uk.ac.ucl.cs, j.cowan@uk.ac.ucl.cs Subject: Videoconference on 11th April Phone: +44-71-380-7294 Date: Wed, 03 Apr 91 09:04:10 +0100 Message-ID: <376.670665850@UK.AC.UCL.CS> From: Steve Kille We are still shooting for this date. We are waiting on confirmation from BBN to deal with both line and room bookings (anyone on this list able to chase locally - BBN especially, but also on the other end points?). I am expecting this to sort out! Locations. We will definitely use UCL, BBN, RIACS (Bay Area on NASA Moffet Field site). I had expected to use DARPA (Washington). We could use ISI (Marina del Rey) instead - I had not realised this earlier. This should be decided quickly. Can I have a vote. (A vote is "I will use the X facility if it is chosen"). Times. April 11th UK: 17:00 - 21:00 BST East Cost: 12:00 - 16:00 EDT West Coast: 09:00 - 13:00 PDT Please let me know if you are planning to attend (and where) Steve   Return-Path: Received: from xtel.co.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <4026-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 09:08:18 +0100 Received: from spitfire by lancaster.xtel.co.uk with SMTP (PP) id <08578-0@lancaster.xtel.co.uk>; Wed, 3 Apr 1991 09:04:31 +0100 To: Steve Titcombe cc: osi-ds@uk.ac.ucl.cs Subject: Re: DSA Probe Statistics For Root DSAs. In-reply-to: Your message of Mon, 25 Mar 91 08:23:20 +0000. Date: Wed, 03 Apr 91 09:05:56 +0100 From: Colin Robbins Thanks for these stats Steve. It looks to me like IXI had a pretty bad week! 821 connection attempts out of which 548 (67%) failed. Colin >DSA Probe Statistics For Root DSAs, for the period Friday 8th March - Friday >23rd March.; > >Probes preformed from ULCC, UCL, STC, Brunel and by Mark Prior of Adelaide >University. >GB: >False Cobra (Future Giant Tortoise) > 55 55 0.00 0.0 0.0 0.00 IXI >Vampire Bat (GB backup) > 55 1 98.18 2.0 8.1 2.99 IXI > 55 55 0.00 0.0 0.0 0.00 IXI >Giant Tortoise (Old Root, GB Master) > 55 55 0.00 0.0 0.0 0.00 IXI > 56 56 0.00 0.0 0.0 0.00 IXI >Passionflower Leaf Beetle (GB Domain name information) > 47 47 0.00 0.0 0.0 0.00 IXI >Cayman (Madrid Uni.) > 55 55 0.00 0.0 0.0 0.00 IXI >Iguana (ES Master. Programa IRIS) > 55 55 0.00 0.0 0.0 0.00 IXI >Margay (GMD/F3, DE backup) > 55 55 0.00 0.0 0.0 0.00 IXI >Puma (GMD/FOKUS) > 55 13 76.36 2.1 64.6 5.05 '0101'H/IXI > 55 55 0.00 0.0 0.0 0.00 IXI >Boa Constrictor (Norway Backup) > 56 14 75.00 3.3 21.1 7.14 '0101'H/IXI > 56 56 0.00 0.0 0.0 0.00 IXI >Electric Eel (Norway Master) > 56 6 89.29 2.0 11.5 3.94 '0101'H/IXI > 55 55 0.00 0.0 0.0 0.00 IXI   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <10644-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 12:22:54 +0100 To: mak@edu.merit cc: clw@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Interime Schema for Network Information Phone: +44-71-380-7294 In-reply-to: Your message of Sat, 30 Mar 91 01:37:07 -0500. <9103300637.AA05508@home.merit.edu> Date: Wed, 03 Apr 91 12:22:52 +0100 Message-ID: <1269.670677772@UK.AC.UCL.CS> From: Steve Kille I think that it is better to have the nets named by stings, which make SOME sense to a typical end user. I don't care that much tho. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <15558-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 15:22:31 +0100 To: solo@com.BBN cc: John Lowry , osi-ds@uk.ac.ucl.cs Subject: Re: 2 Questions Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 02 Apr 91 09:27:38 -0500. Date: Wed, 03 Apr 91 15:22:30 +0100 Message-ID: <1755.670688550@UK.AC.UCL.CS> From: Steve Kille The DER Draft (CD 8825-3, Nov 90) describes the ordering convention in 5.2.4. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17857-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 16:49:52 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Videoconference booking confirmed Phone: +44-71-380-7294 Date: Wed, 03 Apr 91 16:49:50 +0100 Message-ID: <2105.670693790@UK.AC.UCL.CS> From: Steve Kille The facilities are now reserved. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19414-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 17:28:55 +0100 Return-Path: Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18749-0@bells.cs.ucl.ac.uk>; Wed, 3 Apr 1991 17:06:51 +0100 To: s.kille@uk.ac.ucl.cs Subject: video site details Date: Wed, 03 Apr 91 17:06:50 +0100 From: Jon Crowcroft Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Wed, 03 Apr 91 17:28:54 +0100 Resent-Message-ID: <2287.670696134@UK.AC.UCL.CS> Resent-From: Steve Kille Subject: MULTI-MEDIA CONFERENCING SITE INFORMATION AND REQUEST FORM Site Information The conference requester is responsible for distributing this information to the other conference participants as needed. For local hotel information or directions contact the Site Administrative Liaison for the site in question. One suggestion for lunch is to have participants "brown-bag" their own. BBN Location: 10 Moulton Street Cambridge, MA Upon arrival at BBN, check in with the receptionist at the front desk. The receptionist will issue you a vistor badge and notify either Carla Jenkins or Sharon Wolpert at extension 4070. Your badge must be worn at all times while at BBN. Carla or Sharon will meet you in the front lobby and escort you to the conference room. Local phone for messages: 617-873-4070 Conference Room Phone: 617-873-2914 FAX Information: FAX #: 617-873-3776 Please include the following on your cover sheet: TO: Teleconference Room 6/565 NOTE: Materials for teleconference in progress. Contact Carla or Sharon ext. 4070 immediately! After sending a FAX, please notify one of the following people, as the FAX machine is UNATTENDED! Carla or Sharon @ 617-873-4070 Site Admin Liaison: Carla Jenkins Sharon Wolpert 617-873-4070 Site Tech Liaison: Andy Veitch aveitch@bbn.com 617-873-2588 Network Operations Center Hotline (NOC) for technical emergencies Dial: 3427 Amenities: Cafeterias: Within the building, on 7th floor, 70 Fawcett, on 1st floor, 125 Cambridge Park, 1st floor Nearby local restaurants: 99' Restuarant Ground Round Joyce Chen Jose's (pretty good Mexican food) Take out lunches: All the above available for take out Domino Pizza Delivery: 643-2300 Local Cab: 484-3070 or contact front desk at X 3010 who will call a cab for you. DARPA Location: DARPA 1400 Wilson Blvd., 12th Floor Arlington, VA 22209 (check into the Visitor Control Center, Suite 111, to contact DARPA personnel.) There are two multi-media conference rooms located at DARPA. Most multi-media conferences are held in the conference room on the 12th floor. Conference Room Phone: (703) 522-2805 FAX Information: FAX #:202-694-4750 Please include the following on your cover sheet: TO: Teleconference Participants All faxing (sending & receiving) at DARPA will be the responsibility of the sendee or recipient. This will generally mean that the faxee/faxer will use the DARPA contact as a means of accomplishing their faxing business. Be sure to note on the fax that the material is for a teleconference in progress and contact the attendees at the conference room number that the fax has been sent. Site Tech and Admin. Liaison: John Reed jdr@vax.darpa.mil 703-614-8096 Amenities: Restaurants within walking distance: New York New York Japanese Steak House Orleans Restaurant Take out lunches: Tivoli's (downstairs) the Eatery Safeway Emporium next door Domino Pizza delivery: Local Cab: Cab stand is directly across the street ISI Location: 4676 Admiralty Way Marina del Rey, CA Go to 11th floor, head east past middle corridor to east corr., then turn right. Teleconference Room is 1145 on the right. Local phone for messages: 213-822-1511 ext. 171 Conference Room Phone: 213-822-1511 ext. 136 FAX Information: FAX #: 213-823-6714 Please include the following on your cover sheet: TO: Teleconference Room 1145ME NOTE: Materials for teleconference in progress. Please contact a Div7 project assistant to deliver immediately! After sending a FAX, please notify the following person: Kathleen McLaughlin at 213-822-1511, ext. 171 Site Admin Liaison: Kathleen McLaughlin kathleen@isi.edu 213-822-1511 ext. 171 Site Tech Liaison: Stephen Casner Casner@ISI.EDU 213-822-1511 ext. 153 Amenities: Nearby Restaurants: The Good Earth, The Coffee Emporium Take out lunches: Marina Market Deli across the street Catering: can be made available by special arrangement; contact site admin liaison Domino Pizza Delivery: 213-821-6656 Local cab: 213-838-2121 RIACS Location: 625 Ellis Street Mountain View, CA 94043 From the south, exit US 101 on Ellis Street, one exit past the Mathilde Ave. From the north, exit US 101 at Ellis Street, one exit past Moffett Field. Turn west on Ellis Street (opposite Moffett Field) and move immediately into the left lane. Turn left into the 1st INterstate Bank building parking lot. RIACS is located on the second floor. Take the lobby elevator to the second floor, turn left down the corridor to Suite 207 located on the right. Walk through to a second corridor. The multi-media conference room is the first door on the left down this corridor. Local phone for messages: 415-604-4991 Conference Room Phone: FAX Information: FAX #: 415-962-7772 Please include the following on your cover sheet: To: Teleconference Room NOTE: Materials for teleconference in progress. Contact Karen (x7751) or Fran (x7770) immediately. Point of Contact: Karen Rickman Fran Abel Suite 202A Suite 201A 415-962-7751 415-962-7770 UCL Location: University College of London Gower Street Dept. of Computer Sciences London England United Kingdom WCIE 6BTUK Primary Contact: Dennis Timm / timm@cs.ucl.ac.uk Phone: 011-44-71-380-7214 Secondary Phone Number: 011-44-71-387-7677 Notes: -->: After Hours # 011-44-71-387-2424 VIDEO TELECONFERENCE REQUEST FORM Video teleconferencing facilities have been made available to the DARPA and Internet community on a by-appointment basis. Formal meetings should be scheduled at least 2 weeks in advance. Informal meetings should be scheduled with at LEAST 2 DAYS' notice. We will try to accomodate all requests, but we can NOT guarantee a request will be processed with less than 2 days' notice. PLEASE NOTE: Conference requests are processed twice a day; first thing in the morning and early afternoon. Please be aware that should you send a request late in the afternoon, it may not be read until the next morning. A teleconference may include any two, three or four sites from this list: BBN -- Cambridge, MA (Boston) DARPA -- Arlington, VA (Washington) ISI -- Marina del Rey, CA (Los Angeles) RIACS -- Mountain View, CA (San Francisco) An additional site at UCL, London, England can participate in a two-site teleconference with any one of the sites in the list above. Each site can accommodate a maximum of 8 participants, although 6 is a more comfortable limit and 3 is a good working size. The larger the meeting, the harder it is to manage, especially for a teleconference. If sites on both coasts are to be included, then a practical limit on the hours is: 9:00am - 3:00pm West Coast 12:00pm - 6:00pm East Coast Practical times to hold point-to-point conferences with UCL are: 8:30am - 12:30pm West Coast OR 8:30am - 3:30pm East Coast 4:30pm - 8:30pm UK Time 1:30pm - 8:30pm UK Time If you plan an all-day meeting, you may wish to have working lunches at local lunchtimes. Please note that the conference sites are not responsible for providing lunch. You should designate a participant at each site to be responsible for lunch arrangements if needed. To set up a teleconference, please fill out the template enclosed and send it to VIDEO-CONF-REQUEST@BBN.COM. You will receive in return an acknowlegement with additional information about the sites, including lunch suggestions, and preparing materials for a teleconference. After the dates have been checked, you will receive a message either confirming your request or soliciting an alternate date, should your first choice(s) not be available. SUGGESTION: If you are a frequent user of the system, and generally hold conferences with the same individuals, you might want to keep a "filled-out" copy of the form below in a file; issuing subsequent conference requests might require changing only the date. NOTE: The teleconferencing system consists of a number of hardware and software components including workstations, gateways, packet switches and telco equipment. Occasionally, some parts of the system may be unavailable due to component failure. Every effort will be made to fix any problems as quickly as possible. If you have technical difficulties you should call the technical administrator at your site location for further information. Once your conference request has been confirmed, you will receive notification from the Conference Coordinator. It is the responsibility of the requestor to notify all participants of dates and times of the conference. If you have any questions regarding requesting a video conference, send electronic mail to the Conference Coordinator (video-conf-request@bbn.com).   Return-Path: Received: from ibm.com by bells.cs.ucl.ac.uk with SMTP inbound id <1541-0@bells.cs.ucl.ac.uk>; Thu, 4 Apr 1991 10:06:32 +0100 Received: from ZURLVM1 by IBM.COM (IBM VM SMTP R1.2.1MX) with BSMTP id 9878; Wed, 03 Apr 91 23:37:13 PST Date: Thu, 04 Apr 91 09:37:24 SET From: Stefano Zatti To: osi-ds@uk.ac.ucl.cs Message-Id: <040491.093508.zat@ibm.com> Subject: Looking for a document Can somebody send me a copy or tell me where I can find a copy of the document: Distinguished Encoding Rules, Draft, CD 8825-3, November 1990? (An electronic copy would be wonderful, of course!) Contact me directly to get my whereabouts. Thanks a lot, Stefano zat@ibm.com   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9350-0@bells.cs.ucl.ac.uk>; Thu, 4 Apr 1991 12:35:37 +0100 To: Chris Weider cc: osi-ds@uk.ac.ucl.cs Subject: Re: Interime Schema for Network Information Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 02 Apr 91 12:32:15 -0500. <9104021732.AA13743@mazatzal.merit.edu> Date: Thu, 04 Apr 91 12:35:34 +0100 Message-ID: <1957.670764934@UK.AC.UCL.CS> From: Steve Kille Sound good. We'll discuss your document on the 11th. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <10840-0@bells.cs.ucl.ac.uk>; Thu, 4 Apr 1991 13:12:52 +0100 To: osi-ds@uk.ac.ucl.cs Subject: First draft Videoconference Agenda Phone: +44-71-380-7294 Date: Thu, 04 Apr 91 13:12:51 +0100 Message-ID: <2143.670767171@UK.AC.UCL.CS> From: Steve Kille Here is the first draft of the Agenda. Please send comments The fourth site is still to be chosen. DARPA is more likely than ISI, as it has more votes so far. I will decide in the next 24 hours. Please let me know if you are planning to attend, and where. Steve PS I believe that the US will have switched to daylight saving by the 11th. UK has already changed. Agenda for fourth meeting of IETF Directory Services Group (Revision 0) S.E. Kille April 4, 1991 This is a joint meeting with members of RARE WG3. Date Videoconference on Thursday 11th April UCL 17:00 - 21:00 BST BBN 12:00 - 16:00 EDT RIACS (Bay Area) 09:00 - 13:00 PDT Draft agenda follows. Times are ``UCL time'' (BST) 1 Tuesday 17:00 Introduction o Discussion of Videoconference modus operandi o Agenda o Minutes of previous meeting o Matters arising o No liaisons! 1 17:15 Document Status. Review status of all working documents, Internet Drafts, and submitted RFCs. 17:25 Presentation of Pilot Activitiy DISI (Chris Weider) Paradise (David Goodman) FOX (Ruth Lang?) RARE WG3 (Erik Huizer) Pizarro Deployment (Paul Andre Pays) Top level DSA configuration (Colin Robbins) 18:15 US/Europe liaison issues 18:30 Management of ``experimental'' object identifiers 18:40 Naming Guidelines (Paul Barker) 19:10 Representing Network Information (Chris Weider) 19:55 Security (Peter Yee) 20:20 Naming in the US in light of NADF 123 (Marshall T. Rose?) 20:50 Date and Venue of next meeting 20:50 -- 21:00 AOB 2   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5014-0@bells.cs.ucl.ac.uk>; Fri, 5 Apr 1991 09:55:32 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 05 Apr 91 09:55:32 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 23rd March - Friday 5th April. Probes performed from STC, ULCC, UCL, Brunel, Adelaide Uni, and Queensland University. Bind Fail %age Best Worst Ave Address AU: Anaconda (AU Master) 2 0 100.00 0.4 0.5 0.45 Internet 2 0 100.00 1.5 1.5 1.50 Int-X25 105 5 95.24 1.7 93.3 8.79 Internet 50 6 88.00 7.6 28.7 12.75 Int-X.25 Bush Dog 87 5 94.25 0.6 95.8 3.63 Internet 104 14 86.54 0.6 105.0 10.65 Internet GB: Coypu (Thorn acces pt to quipu) 50 0 100.00 0.9 1.9 1.10 Local Ether 50 0 100.00 1.3 2.3 1.50 Janet 105 5 95.24 0.7 36.7 9.27 Internet 87 9 89.66 3.2 25.7 5.70 Internet 137 43 68.61 2.5 59.3 5.05 X121 204 90 55.88 1.3 10.1 2.71 Janet False Cobra (Giant Tortoise backup) 50 0 100.00 1.2 2.1 1.33 Janet 104 6 94.23 0.4 64.5 8.03 Internet 137 43 68.61 2.4 11.3 4.30 X121 50 50 0.00 0.0 0.0 0.00 IXI Passionflower Leaf Beetle (GB Domain name information) 103 10 90.29 0.5 92.6 9.34 Internet 48 48 0.00 - - - Janet 48 48 0.00 0.0 0.0 0.00 IXI 48 48 0.00 0.0 0.0 0.00 X121 Giant Tortoise (Root, GB Master) 50 5 90.00 1.8 2.6 1.92 X121 87 9 89.66 2.7 24.2 5.81 Internet 105 20 80.95 0.6 77.0 8.15 Internet 50 12 76.00 1.9 3.3 2.22 Janet 86 86 0.00 0.0 0.0 0.00 IXI 86 86 0.00 0.0 0.0 0.00 Janet Vampire Bat (GB backup) 48 5 89.58 3.4 15.6 4.10 Janet 54 6 88.89 2.0 7.0 2.97 IXI 140 32 77.14 1.2 3.9 1.86 Janet 48 48 0.00 0.0 0.0 0.00 NS 48 48 0.00 0.0 0.0 0.00 IXI 64 64 0.00 0.0 0.0 0.00 Janet Maned Sloth (Edinburgh, DSA holding NRS info) 204 204 0.00 0.0 0.0 0.00 Janet 48 48 0.00 - - - Janet IT: swdsa (Italy Master) 12 0 100.00 8.5 10.0 9.11 \"SWDSA\"/\"1\"/X121 CH: Chinchilla (Swiss Master) 87 4 95.40 3.6 22.5 5.43 Internet 99 25 74.75 5.6 109.0 23.02 Internet 50 50 0.00 - - - Int-X.25 87 87 0.00 0.0 0.0 0.00 Int-X25 Condor (ETH Zurich) 87 4 95.40 2.9 16.4 4.68 Internet 105 49 53.33 2.6 67.1 15.16 Internet 50 24 52.00 4.8 66.1 11.12 Int-X.25 87 48 44.83 6.8 46.7 9.53 Int-X25 DE: Margay (GMD/F3, DE backup) 54 3 94.44 1.9 8.5 3.23 IXI 48 3 93.75 5.8 15.8 8.98 Int-X.25 12 1 91.67 5.1 5.7 5.35 Int-X25 12 1 91.67 5.7 50.5 14.10 Internet 103 14 86.41 4.0 60.9 19.99 Internet 48 48 0.00 0.0 0.0 0.00 IXI Puma (GMD/FOKUS) 12 2 83.33 5.2 6.1 5.47 Int-X25 54 10 81.48 2.1 8.6 3.06 IXI 101 40 60.40 4.4 99.3 21.94 Internet 48 20 58.33 7.4 113.9 23.16 Int-X.25 12 9 25.00 7.6 18.8 11.57 Internet 48 48 0.00 0.0 0.0 0.00 IXI NO: Boa Constrictor (Norway Backup) 87 5 94.25 3.4 46.5 8.16 Internet 50 8 84.00 4.0 54.2 8.72 Int-X.25 104 18 82.69 5.5 84.9 24.58 Internet 87 42 51.72 6.0 15.5 7.62 Int-X25 142 100 29.58 3.4 155.4 10.70 IXI 50 50 0.00 0.0 0.0 0.00 IXI Electric Eel (Norway Master) 55 4 92.73 1.8 147.6 6.45 IXI 87 7 91.95 3.1 53.6 7.34 Internet 50 7 86.00 4.5 41.2 9.05 Int-X.25 104 21 79.81 2.4 95.8 18.86 Internet 87 43 50.57 6.3 16.8 7.95 Int-X25 50 50 0.00 0.0 0.0 0.00 IXI 86 86 0.00 0.0 0.0 0.00 IXI US: Giant Anteater (Various slave) 87 5 94.25 2.8 31.2 4.64 Internet 105 35 66.67 4.0 79.3 10.23 Internet Alpaca 105 12 88.57 3.1 62.9 8.85 Internet 87 31 64.37 2.5 37.7 5.20 Internet 87 67 22.99 7.6 12.5 9.00 Int-X25 Fruit Bat 105 17 83.81 3.1 56.8 15.20 Internet 87 38 56.32 2.5 14.0 5.40 Internet NL: Agouti (NL Slave) 105 8 92.38 4.0 104.1 18.92 Internet 87 87 0.00 0.0 0.0 0.00 Internet Hornero (NL Master) 87 7 91.95 3.5 27.0 5.80 Internet 105 35 66.67 3.0 99.1 19.23 Internet 136 57 58.09 3.9 19.0 7.52 X121 SE: Hummingbird (Sweden Master) 104 8 92.31 4.0 85.9 20.14 Internet 87 28 67.82 3.7 55.2 8.10 Internet 135 56 58.52 4.5 95.3 8.84 X121 CA: Pangolin (Northern Telecom Master) 87 10 88.51 3.3 22.2 7.29 Internet 102 12 88.24 4.5 58.1 17.00 Internet 48 48 0.00 0.0 0.0 0.00 NS 87 87 0.00 0.0 0.0 0.00 localTCP Wayne Gretzky (Canada Master) 103 56 45.63 4.2 77.4 16.10 Internet 12 12 0.00 0.0 0.0 0.00 Internet DK: Axolotl (DK Master) 104 12 88.46 4.2 85.4 25.21 Internet 87 87 0.00 0.0 0.0 0.00 Internet FI: Jaguar (Finland Master) 103 13 87.38 3.8 112.0 21.99 Internet 87 19 78.16 3.3 30.1 9.43 Internet 135 92 31.85 6.9 15.0 9.23 X121 48 48 0.00 0.0 0.0 0.00 NS IS: Elephant Seal (IS Master) 103 34 66.99 10.9 85.2 30.14 Internet 87 63 27.59 6.6 28.6 12.37 Internet ES: Iguana (ES Master. Programa IRIS) 48 16 66.67 5.9 102.0 25.27 Int-X.25 103 69 33.01 4.1 102.1 31.46 Internet 87 63 27.59 7.4 30.3 14.79 Int-X25 140 102 27.14 2.5 24.2 9.12 IXI 87 76 12.64 6.3 13.3 7.60 Internet 48 48 0.00 0.0 0.0 0.00 NS 48 48 0.00 0.0 0.0 0.00 IXI Cayman (Madrid Uni.) 105 84 20.00 9.6 108.6 43.40 Internet 50 40 20.00 8.3 65.4 24.98 Int-X.25 142 126 11.27 2.3 115.6 11.03 IXI 87 86 1.15 8.6 8.6 8.60 Int-X25 50 50 0.00 0.0 0.0 0.00 IXI   Return-Path: Received: from xtel.co.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <6151-0@bells.cs.ucl.ac.uk>; Fri, 5 Apr 1991 10:38:45 +0100 Received: from spitfire by lancaster.xtel.co.uk with SMTP (PP) id <02196-0@lancaster.xtel.co.uk>; Fri, 5 Apr 1991 10:34:50 +0100 To: Steve Titcombe cc: osi-ds@uk.ac.ucl.cs Subject: Re: DSA Probe Statistics For Root DSAs. In-reply-to: Your message of Fri, 05 Apr 91 09:55:32 +0000. Date: Fri, 05 Apr 91 10:36:24 +0100 From: Colin Robbins A quick bit of analysis of these figures is not too impressive. I just counted up all the attempted connections and failures for each network group. Results below. IXI: 1253 attempts, 963 failed (76.8555%) Int-x25: 635 attempts, 439 failed (69.1339%) Janet: 992 attempts, 589 failed (59.375%) Internet: 4198 attempts, 1138 failed (27.1081%) The X.25 failure rate is VERY high. Some of this can be attributed to the probe, but not all ( a new version is being worked on). Colin PS Steve - do you think you could append a summary like this to each set of stats you mail out.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17985-0@bells.cs.ucl.ac.uk>; Fri, 5 Apr 1991 18:57:05 +0100 To: osi-ds@uk.ac.ucl.cs cc: Andy Veitch , video-conf-request@com.BBN Subject: ISI will be the fourth site Phone: +44-71-380-7294 Date: Fri, 05 Apr 91 18:57:04 +0100 Message-ID: <1961.670874224@UK.AC.UCL.CS> From: Steve Kille I have decided to choose ISI over DARPA. Basically, it was about even, and the the balance tipped by the FOX people at ISI. My apologies to the people who can only make the Washington site. Another twist has been added tho! I gather that we can have a phone link into the conference (to BBN). There is a single line to an echo canceller. This can be used by either one individual, or by an AT&T phone conference. Would any of you not able to participate directly like to use a phone link? If more than one, is someone prepared to sort out a phone conference? Steve   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1624-84@bells.cs.ucl.ac.uk>; Sun, 7 Apr 1991 17:38:28 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <29244-2@sun2.nsfnet-relay.ac.uk>; Sat, 6 Apr 1991 00:07:49 +0100 Received: from [137.39.1.2] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa19997; 6 Apr 91 0:07 BST Received: from microsoft.UUCP by uunet.UU.NET with UUCP (5.61/UUNET-primary-gateway) id AA03137; Fri, 5 Apr 91 17:56:29 -0500 From: microsoft!randyd@net.uu.uunet Message-Id: <9104052256.AA03137@uunet.UU.NET> To: osi-ds@uk.ac.ucl.cs Subject: Alias Entries in X.500 Date: Fri Apr 5 14:33:49 1991 I have a question about alias entries in X.500. In particular, I'm wondering about the meaning of X.501, section 9.4.8.2, which defines the alias object class. Assume that we define the term "abstract class" to mean a class that has no instances. An abstract class is used as a base class that is further refined by subclass definitions. In a system with abstract classes, no object can be an instance of abstract class. However, a object could be an instance of a non-abstract subclass of an abstract class. (To drive home the point, imagine a system with three classes: person, male, and female. This system defines person to be an abstract class; male and female are subclasses of person. Every object in this system is either an instance of male or female. There are no objects in the system that are instances of person.) Does the X.500 specification envision/require that the "Alias" object class be an "abstact class"? That is, are there any entries in the DIB that are instances of the alias class? Or are all alias entries in the DIB instances of a subclass of the alias class? Presumably the subclass will specify the RDN types for this object. Is this correct? Thank you, Randy Day Microsoft microsoft!randyd@uunet.uu.net   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <2272-19@bells.cs.ucl.ac.uk>; Sun, 7 Apr 1991 21:00:43 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Fri, 5 Apr 1991 20:51:20 +0100 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Fri, 5 Apr 1991 20:55:05 +0100 Date: Fri, 5 Apr 1991 19:51:20 +0000 X400-Originator: huitema@fr.inria.jerry X400-MTS-Identifier: [/PRMD=inria/ADMD=atlas/C=FR/;670881318@kwai.inria.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Interime ... From: Christian Huitema Message-ID: <9104051955.AA13742@jerry.inria.fr> To: Steve Kille Cc: mak@edu.merit, clw@edu.merit, osi-ds@uk.ac.ucl.cs In-Reply-To: <1269.670677772@UK.AC.UCL.CS> Subject: Re: Interime Schema for Network Information Sender: huitema@fr.inria.jerry Quite the contrary. The principle of "user friendly naming" is that you choose "natural" name components, i.e. components which have not to be guessed, which remain stable, which can be easily derivable from "natural" properties, etc. This leads indeed to using "common names" for human users; but it also very naturally leads to using network numbers for numbers. Besides, usage of "network numbers" based names allow to solve the query by a single read operation + also allow (to an extent) to distribute the data base. I vote a 100 times for using network numbers as the basis of the name of networks; I dont even know what is the network name of "INRIA/Sophia" today! Christian Huitema   Return-Path: Received: from taunivm.tau.ac.il by bells.cs.ucl.ac.uk with SMTP inbound id <429-0@bells.cs.ucl.ac.uk>; Mon, 8 Apr 1991 13:46:23 +0100 Received: from VM.TAU.AC.IL by TAUNIVM.TAU.AC.IL (IBM VM SMTP R1.2.2MX) with BSMTP id 0625; Mon, 08 Apr 91 13:40:25 IST X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from VM.TAU.AC.IL (HANK) by VM.TAU.AC.IL (Mailer R2.07) with BSMTP id 6967; Mon, 08 Apr 91 13:40:25 IST Date: Mon, 08 Apr 91 13:37:59 IST From: Hank Nussbacher Subject: NADF To: osi-ds@uk.ac.ucl.cs Reply-To: Hank Nussbacher , Hank Nussbacher My Ministry of Communication called me and asked whether the osi-ds pilot project (QUIPU) is being coordinated with the North American Directory Forum. I had never heard of such an organization and figured that someone here might know. Thanks and please reply directly to me, Hank   Return-Path: Received: from xtel.co.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <4932-1@bells.cs.ucl.ac.uk>; Mon, 8 Apr 1991 15:42:01 +0100 Received: from spitfire by lancaster.xtel.co.uk with SMTP (PP) id <15957-0@lancaster.xtel.co.uk>; Mon, 8 Apr 1991 09:27:12 +0100 To: microsoft!randyd@net.uu.uunet cc: osi-ds@uk.ac.ucl.cs Subject: Re: Alias Entries in X.500 In-reply-to: Your message of Fri, 05 Apr 91 14:33:49. <9104052256.AA03137@uunet.UU.NET> Date: Mon, 08 Apr 91 09:29:00 +0100 From: Colin Robbins >Does the X.500 specification envision/require that the "Alias" >object class be an "abstact class"? That is, are there any entries in >the DIB that are instances of the alias class? Or are all alias entries >in the DIB instances of a subclass of the alias class? Presumably >the subclass will specify the RDN types for this object. Is this >correct? I have used "Alias" in the following manner in the pilot DIT: RDN: commonName = Colin Robbins Attributes: objectClass = alias & top aliasedObjectName= Colin Robbins, X-Tel, GB The use of "commonName" is acceptable in the schema sence, as I am assuming the existence of the "object class without an assigned object identifier" (X.501, Section 9.4.1.) which in this case declares commonName to be an optional attribute. I am not sure if this is an "abstract" use or not. You could argue that this is an abstract use of alias, as there is the subclass "object class without an assigned object identifier" is used. But as the use of "object class without an assigned object identifier" is not defined in the object class attribute, the "highest" visible class is alias - so it's non-abstract. Anyway, I don't think this is the real issue. I *think* you were really asking is an entry of the above form legal X.500 ? I claim it is. Colin   Return-Path: Received: from NRI.RESTON.VA.us by bells.cs.ucl.ac.uk with SMTP inbound id <5221-0@bells.cs.ucl.ac.uk>; Mon, 8 Apr 1991 15:48:56 +0100 Received: from mcimail.com by NRI.NRI.Reston.VA.US id aj19894; 8 Apr 91 10:40 EDT Date: Mon, 8 Apr 91 14:31 GMT From: Ted Myer <0004454742@com.mcimail> To: Hank Nussbacher Cc: Ben Heckscher <0003094996@com.mcimail> Cc: osi ds Subject: RE: NADF Message-Id: <81910408143118/0004454742NB1EM@mcimail.com> Hank, the NADF is a group of North American communication service companies, primarily E-Mail service suppliers, that is developing a public X.500-based directory service. --Ted Myer   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <13060-0@bells.cs.ucl.ac.uk>; Mon, 8 Apr 1991 18:52:36 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Mon, 8 Apr 1991 18:45:20 +0100 X400-Received: by /PRMD=ca/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 8 Apr 1991 17:54:22 +0100 Date: Mon, 8 Apr 1991 09:54:22 -0700 X400-Originator: eskovgaa@ca.bc.cue X400-MTS-Identifier: [/PRMD=ca/ADMD=TELECOM.CANADA/C=CA/;910408095422] X400-Content-Type: P2-1984 (2) Content-Identifier: 332 Conversion: Prohibited From: Erik Skovgaard Message-ID: <332*/S=eskovgaa/OU=cue/O=bc/PRMD=cdn/ADMD=telecom.canada/C=ca/@MHS> To: Hank Nussbacher <"/DD.=EAN-RELAY.AC/RFC-822=HANK(a)il.ac.tau.taunivm/PRMD=UK/ADMD=/C=/"@uk.ac.mhs-relay> (IPM Return Requested), Hank Nussbacher <"/DD.=EAN-RELAY.AC/RFC-822=hank(a)il.ac.tau.vm/PRMD=UK/ADMD=/C=/"@uk.ac.mhs-relay> (IPM Return Requested) Cc: osi-ds@uk.ac.ucl.cs (IPM Return Requested) In-Reply-To: Subject: NADF The NADF is a group of - mostly telephone companies and electronic mail service providers that meet to set up the North American DIT, schema and to discuss accounting issues. As far as I know, it is a closed forum. ....Erik.   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <14192-0@bells.cs.ucl.ac.uk>; Mon, 8 Apr 1991 19:42:40 +0100 Posted-Date: Mon, 08 Apr 91 11:42:09 PDT Message-Id: <9104081842.AA08840@venera.isi.edu> Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 8 Apr 91 11:42:35 -0700 To: osi-ds@uk.ac.ucl.cs Subject: re: ISI will be the fourth site Cc: kathleen@edu.ISI Reply-To: hotz@edu.ISI Date: Mon, 08 Apr 91 11:42:09 PDT From: Steve Hotz Hi. How many bodies should ISI expect? For those who want directions and other misc. information contact: Kathleen McLaughlin (kathleen@isi.edu) 213.822-1511 Regards, steve ------- Forwarded Message Date: Fri, 05 Apr 91 18:57:04 +0100 From: Steve Kille To: osi-ds@cs.ucl.ac.uk cc: Andy Veitch , video-conf-request@BBN.com Subject: ISI will be the fourth site I have decided to choose ISI over DARPA. Basically, it was about even, and the the balance tipped by the FOX people at ISI. My apologies to the people who can only make the Washington site. Another twist has been added tho! I gather that we can have a phone link into the conference (to BBN). There is a single line to an echo canceller. This can be used by either one individual, or by an AT&T phone conference. Would any of you not able to participate directly like to use a phone link? If more than one, is someone prepared to sort out a phone conference? Steve ------- End of Forwarded Message   Return-Path: Received: from nrtc.northrop.com by bells.cs.ucl.ac.uk with SMTP inbound id <25795-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 00:56:22 +0100 Received: from nma.com by nrtc.nrtc.northrop.com id aa03614; 8 Apr 91 15:55 PST Received: from odin.nma.com by nma.com id aa02666; 8 Apr 91 14:12 PDT To: osi-ds@uk.ac.ucl.cs Subject: OOPS! Re: NADF In-reply-to: Your message of Mon, 08 Apr 91 09:54:22 -0800. <332*/S=eskovgaa/OU=cue/O=bc/PRMD=cdn/ADMD=telecom.canada/C=ca/@MHS> Reply-to: Stef@edu.uci.ics From: Einar Stefferud Date: Mon, 08 Apr 91 15:10:18 MDT Message-ID: <9387.671148618@nma.com> Sender: stef@com.nma OOPS! I see that I should have jumped in to explain before someone jumped in with less than full information. Sorry Erik! DISCLAIMER: What I am reporting here is not formal or official, since I only attend as a member's delegate. I have now attended 3 meetings in a row. I have not cleared any of this with any NADF person. The NADF (North American Directory Forum) is an "open" organization in that it is open to any entity that offers or plans to offer public directory services in North America (which commonly includes Canada, the US, and Mexico), and which will agree to defray its share of the operational cost of the NADF. The NADF members agree to defray the costs of operation, which are unofficially estimated at about $5500/year/member. Canadian and US organizations are attending. The meeting attendees have included participants from Ameritech, ATT, Bell Atlantic, Bellcore, BellSouth, BT Tymnet, GE Information Services, IBM, INFONET, MCI International, NYNEX, Pacific Bell, Performance Systems International, Rapport Communications, Southwestern bell, Sprint International, Teleglobe Canada, US Postal Service, and US West. Some of these companies are international in scope. At the two prior meetings, Directory System Vendors were invited to one, and Directory Users were invited the other. Mexican organizations have not been heard from and have not been aggressively pursued, but will (should) be pursued in the near future to be sure they are aware that they are welcome (and encouraged) to participate. The output documents were recently declared to be openly available (not restricted as proprietary) though there is no plan to provide free copies of anything to just anyone in the world who happens to ask. I do not know quite how one gets copies without attending. In general, the meetings are closed to existing member company delegates, though membership is open as mentioned above. The press is not invited to attend and report on the content of the working meeting discussions. A general Press Release has been issued following every meeting. Meetings are held 4 times per year. The last was in late March and the next is July 8-11. The recently distributed NADF123 document is a notable output result of NADF work, which forms an agreed upon (for now) basis for a naming scheme for c=US. I believe this document is now being discussed in this (osi-ds) forum. The NADF is making NADF123 widely available and is soliciting comment on it from anyone who is concerned or interested. It has been recently released as RFC1218 (see below). The NADF Secretariat is provided by RAPPORT Communications, and Ted Myer is the RAPPORT person who attends each meeting and serves as the permanent NADF ViceChair. Ted Myer's phone number in Washington DC is: (202) 342-2727 RAPPORT main phone numbers in California are: (415) 494-1044 FAX: (415) 494-7240 TLX: 704066 TMIUS UD If you are interested in joining the NADF, please contact RAPPORT for more information. Otherwise, I suggest that you ask your questions in this forum (osi-df) so we can answer them for all to see. Best...\Stef -------- Begin Enclosure From: "Joyce K. Reynolds" Reply-to: jkrey@isi.edu Subject: RFC1218 on A Naming Scheme for c=US Date: Wed, 03 Apr 91 14:53:42 PST A new Request for Comments is now available from the Network Information Center in the online library at NIC.DDN.MIL. RFC 1218: Title: A Naming Scheme for c=US Author: The North American Directory Forum Mailbox: mrose@psi.com Pages: 23 Characters: 42,698 Updates/Obsoletes: none pathname: RFC:RFC1218.TXT This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). The NADF is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. ------- End   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <131-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 04:31:01 +0100 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA28910; Mon, 8 Apr 91 23:30:59 -0400 Received: by home.merit.edu (4.1/dumb-0.9) id AA16805; Mon, 8 Apr 91 23:30:58 EDT From: mak@edu.merit Message-Id: <9104090330.AA16805@home.merit.edu> To: Steve Kille Cc: osi-ds@uk.ac.ucl.cs, Andy Veitch , video-conf-request@com.BBN Subject: Re: ISI will be the fourth site In-Reply-To: Your message of "Fri, 05 Apr 91 18:57:04 +0100." <1961.670874224@UK.AC.UCL.CS> Date: Mon, 08 Apr 91 23:30:58 -0400 Steve, Chris will be on vacation that day but I would like to be able to participate by phone at least for the discussion about FOX-related issues. Could you give me an updated time for that part of the discussion? Perhaps it might be possible to have someone call me during the meeting so that I can join by voice at the appropriate time? My phone number is +1 313 763-6061. Mark --- I have decided to choose ISI over DARPA. Basically, it was about even, and the the balance tipped by the FOX people at ISI. My apologies to the peop le who can only make the Washington site. Another twist has been added tho! I gather that we can have a phone link into the conference (to BBN). There is a single line to an echo canceller . This can be used by either one individual, or by an AT&T phone conference. Would any of you not able to participate directly like to use a phone link? If more than one, is someone prepared to sort out a phone conference? Steve   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <375-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 04:49:08 +0100 Received: from casner.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 8 Apr 91 20:48:48 -0700 Posted-Date: Mon 8 Apr 91 20:47:58-PDT Received: by casner.isi.edu (4.0/4.0.3-4) id ; Mon, 8 Apr 91 20:48:00 PDT Date: Mon 8 Apr 91 20:47:58-PDT From: Stephen Casner Subject: Re: ISI will be the fourth site To: S.Kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Cc: aveitch@com.bbn, VIDEO-CONF-REQUEST@com.bbn Message-Id: <671172478.0.CASNER@ISI.EDU> In-Reply-To: <1961.670874224@UK.AC.UCL.CS> Mail-System-Version: Given that ISI and BBN sites are both included in the teleconference, there are two echo cancellers with phone lines that can be called. At BBN the number is 617-873-2914. At ISI the number is 213-822-9266. -- Steve -------   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <29997-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 04:29:19 +0100 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA28882; Mon, 8 Apr 91 23:29:17 -0400 Received: by home.merit.edu (4.1/dumb-0.9) id AA16794; Mon, 8 Apr 91 23:29:16 EDT From: mak@edu.merit Message-Id: <9104090329.AA16794@home.merit.edu> To: Christian Huitema Cc: Steve Kille , clw@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: Interime Schema for Network Information In-Reply-To: Your message of "Fri, 05 Apr 91 19:51:20 GMT." <9104051955.AA13742@jerry.inria.fr> Date: Mon, 08 Apr 91 23:29:16 -0400 Christian, Well said. --Mark --- Quite the contrary. The principle of "user friendly naming" is that you choose "natural" name components, i.e. components which have not to be guessed, which remain stable, which can be easily derivable from "natural" properties, etc. This leads indeed to using "common names" for human users; but it also very naturally leads to using network numbers for numbers. Besides, usage of "network numbers" based names allow to solve the query by a single read operation + also allow (to an extent) to distribute the data base. I vote a 100 times for using network numbers as the basis of the name of networks; I dont even know what is the network name of "INRIA/Sophia" today! Christian Huitema   Return-Path: Received: from xtel.co.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <3803-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 08:32:17 +0100 Received: from spitfire by lancaster.xtel.co.uk with SMTP (PP) id <27287-0@lancaster.xtel.co.uk>; Tue, 9 Apr 1991 08:27:06 +0100 To: randyd@uucp.microsoft cc: osi-ds@uk.ac.ucl.cs Subject: Re: Alias Entries in X.500 In-reply-to: Your message of Mon, 08 Apr 91 17:46:02. <9104090106.AA21731@relay1.UU.NET> Date: Tue, 09 Apr 91 08:28:59 +0100 From: Colin Robbins >Thanks for the reply, Colin. Your interpretation of X.501, Section 9.4.1, >sparked some interesting discussion here. I gather that your >interpretation of unassigned object identifier object classes is >that they don't represent the definition of a new class. Rather they are >a mechanism for changing existing object class definitions. For example >they allow additions to mandatory or optional attribute sets. Technically it defines a new class. But as you can't see the object class OID ('cos there isn't one) the observed effect is to add a few attributes to the existing class. Colin   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5648-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 09:31:56 +0100 To: Erik.Huizer@nl.surfnet Cc: osi-ds@uk.ac.ucl.cs, j.cowan@uk.ac.ucl.cs, d.timm@uk.ac.ucl.cs Subject: Re: After the video conference Phone: +44-71-380-7294 In-reply-to: Your message of Mon, 08 Apr 91 21:28:03 -0000. <"6513 Mon Apr 8 23:32:33 1991"@surver.surfnet.nl> Date: Tue, 09 Apr 91 09:31:56 +0100 Message-ID: <599.671185916@UK.AC.UCL.CS> From: Steve Kille Silly me! There will be an official videoconference beer and curry after the meeting at UCL. (Sorry to disturb those of you not coming to UCL, but want to make sure I reach everyone). Steve >From: Erik.Huizer@nl.surfnet >To: Steve Kille >Subject: After the video conference >Date: Mon, 8 Apr 1991 21:28:03 +0000 >Can we go out for dinner with the London branch? Iwouldn't mind eating >Indian food again :-) as we're finishing too late for me to fly back. >Erik   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <25776-0@bells.cs.ucl.ac.uk>; Tue, 9 Apr 1991 17:27:26 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Tue, 9 Apr 1991 17:20:07 +0100 X400-Received: by /PRMD=ca/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 Apr 1991 17:24:35 +0100 Date: Tue, 9 Apr 1991 16:20:07 +0000 X400-Originator: eskovgaa@ca.bc.cue X400-MTS-Identifier: [/PRMD=ca/ADMD=TELECOM.CANADA/C=CA/;910409092435] X400-Content-Type: P2-1984 (2) Content-Identifier: 337 Conversion: Prohibited From: Erik Skovgaard Message-ID: <337*/S=eskovgaa/OU=cue/O=bc/PRMD=cdn/ADMD=telecom.canada/C=ca/@MHS> To: osi-ds@uk.ac.ucl.cs (IPM Return Requested) Subject: Help! Sorry to use the list for this purpose, but I am getting swamped by some mailers from DEC. They appear to be named "Nieman" and "Farowich" and seem to choke on a message I sent a couple of days ago. Please fix it - my system is running out of memory! Thanks, ....Erik.   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <26946-0@bells.cs.ucl.ac.uk>; Wed, 10 Apr 1991 01:28:14 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <26907-1@sun2.nsfnet-relay.ac.uk>; Wed, 10 Apr 1991 01:13:43 +0100 Received: from venera.isi.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa22152; 10 Apr 91 1:08 BST Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-2) id ; Tue, 9 Apr 91 17:08:02 -0700 Date: Tue, 9 Apr 91 17:07:35 PDT From: hotz@edu.ISI Posted-Date: Tue, 9 Apr 91 17:07:35 PDT Message-Id: <9104100007.AA02740@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Tue, 9 Apr 91 17:07:35 PDT To: osi-ds@uk.ac.ucl.cs Cc: fox500@edu.ISI Subject: directory services report (Inet monthly excerpt) Sender: hotz Hi. This is the directory services report for the Internet and various US/NA activities as it is going out in the Internet Monthly report this week. I am also talking with Einar Stefferud (ANSI USA RAC and SG-D MHS-MD) and Youbing Weon-Yoon (OIW DSSIG) about including reports from these groups in the future. Since it's genesis was this group's (osids) suggestion, i thought i'd distribute a copy before the videoconference so that comments on the direction the report has taken, and how it might be altered, can be made (although i'm uncertain if Steve has allocated time for this). FOX/ISI will set up a mailing list for those who want to receive this report without the rest of the IMR (naturally we'll instantiate the pointers to IETF WG reports in the standalone version). Cheers, steve =================================================== Directory Services Activities ----------------------------- Beginning this month, the Internet Monthly Report will contain a section on the development of directory services that are for, or effect, the Internet. We would like to encourage any organization with related news on directory services development to use this forum for publishing brief monthly news items. Current reports include: o IETF OSIDS & DISI Working Groups o Field Operational X.500 Project - ISI - Merit - PSI - SRI o North American Directory Forum o PARADISE Project o PSI WHITE PAGES PILOT IETF OSIDS & DISI Working Groups -------------------------------- Refer to IETF section for the OSIDS and DISI working group reports. FOX -- Field Operational X.500 Project -------------------------------------- The FOX project is a DARPA funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. There are two primary thrusts of the FOX project: 1. X.500 Infrastructure It is important that multiple interoperable platforms be available for deployment. FOX plans to examine and test the interoperability of the Quipu and NIST-X.500 (Custos) implementations, and DNANS-X.500 if possible. In addition, FOX will explore X.500 interfaces to conventional database systems (one target is Sybase), an alternate OS platform (VM) for X.500 servers, and X-window based user interfaces. 2. X.500 Applications A long-range goal is to facilitate the use of X.500 for real Internet applications. FOX will first focus on making network infrastructure information available through X.500. This includes network and AS site contacts, topology information, and the NIC WHOIS service. A centrally managed X.500 version will be the first phase of a WHOIS service. Providing an X.500 version of a well-known widely-used service should promote the use of X.500 by Internet users. In addition, this effort will provide experience in designing X.500 applications. However, the managability of this scheme will be short-lived, so the next step will be a design for a distributed version of WHOIS. Finally, it is critical for Internet X.500 efforts to be aligned with directory service efforts that are ongoing in other communities. FOX participants are involved in, or are otherwise tracking these efforts, and information about FOX activities will be publicly available. Steve Hotz (hotz@isi.edu) ISI --- ISI has been pushing to get the subcontracts completed and in place, and has applied for a no-cost extension to the end of the year for the FOX project. A similar extension will be made to the subcontracts. A telephone conference is scheduled during the week of April 15th. Steve Hotz (hotz@isi.edu) Merit ----- Several things have been happening at MERIT in conjunction with the FOX project: 1: Merit has added another person to the X.500 crew: Richard Conto, who will be working on FOX approximately 1/2 time. 2: ISODE 6.8i has been installed behind both of Merit's X.500 DSAs (directory servers). Merit operates a DSA on merit.edu for the Merit staff and for network information, and also a DSA on sprint.com for the Sprintmail X.400 gateway. 3: One Internet Draft has gone out from Merit's FOX project team: the title is "Interim Schema for Network Infrastructure Information in X.500". It contains a schema definition for the Site Contacts portion of the directory information tree (DIT - X.500's hierarchical name space). Two more IDs are in progress: one on a long term DIT structure for network information, and one on representing NSAPs in X.500. 4: Chris Weider of Merit is chairing a new X.500 related IETF working group. The working group's name is "Directory Information Services (pilot) Infra-structure Working Group" or DISI for short. This working group is concerned with developing an "Administrator's Guide" to Directory Services through X.500, and with promoting the growth of the X.500 infrastructure. 5: Merit staff are using a Macintosh X.500 client written by Mark Smith, Bryan Beecher, and Tim Howes of the University of Michigan. This client is very nice, and uses Tim Howes' lightweight "Dixie" protocol to talk to the DSA. 6: The X.500 directory is now used to maintain and generate the production "aliases" file for the Sprintmail X.400 gateway. Previously the aliases file was edited as a text file by Sprint staff and updated manually. Now the Sprint staff and some of their customers use an e-mail based command protocol to modify the alias entries. Chris Weider (clw@merit.edu) PSI --- Awaiting official approval/funding as of April 1, 1991. Marshall Rose (mrose@cheetah.ca.psi.com) SRI --- In order to provide an interim capability offering network information via the Directory, SRI has begun the task of replicating a subset of the WHOIS information in the Directory. SRI has analyzed the WHOIS database and selected this subset. Review by and discussion among the FOX project, participants provided valuable feedback for finalizing the selected subset. The development of a schema to support the WHOIS information is underway and will be completed in early April. SRI developed a program to produce a QUIPU EDB load file for WHOIS individual information. It uses the pilotPerson object as a prototype, as a means to anticipate potential data conversion problems (e.g. size mismatches). Other more straightforward conversions will be required, but the following two have been identified as mismatches: - WHOIS address field maximum greater than postalAddress - reversed name ordering. Names in WHOIS are last name first, whereas commonName suggests first name first. The other WHOIS entities (e.g., computer, domain) will be analyzed in a similar manner as part of the conversion process. Ruth Lang attended the twentieth IETF held March 11-15 in St. Louis. At the kick-off meeting of the Directory Information Services (pilot) Infrastructure Working Group (DISI), two RFC/FYI documents were identified as output from this working group. Ruth, along with Russ Wright of LBL, will co-author one of these, a catalogue of X.500 implementations. Work has begun to develop the survey form that will be used to gather information on the implementations. The survey itself will be initiated in early April. NORTH AMERICAN DIRECTORY FORUM ------------------------------ The North American Directory Forum (NADF) is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. The NADF met in Reston, VA the week of March 18-22, 1991. Outputs from this meeting include NADF-123, "A Naming Scheme for c=US", which the NADF is widely circulating for comment prior to their next meeting in mid-July. An ASCII version of NADF-123 has been published as RFC-1218. The NADF-123 document proposes the use of existing civil infrastructure for naming objects under c=US. This has the advantage of using existing registration authorities and not establishing any new ones (the document simply maps names assigned by existing authorities into different portions of the c=US DIT). The NADF-123 document is intended as the basis for X.500 names in the US for the long-term; it is important that interested parties get a copy, review it, and return comments. A second output, which is still undergoing development, is NADF-128, a preliminary draft on "Mapping the DIT onto Multiple ADDMDs". This describes how the c=US portion of the DIT is mapped onto DSAs and what service-providers must minimally share in order to achieve a working public directory. The next revision of this document will likely be ASCII-ized and published as an informational RFC. Marshall Rose (mrose@cheetah.ca.psi.com) PARADISE PROJECT ---------------- This is the first report from the PARADISE project based at the Department of Computer Science, University College London (UCL). PARADISE is a sub-project of the broader COSINE project sponsored under the umbrella of EUREKA by eighteen participating countries and aimed at promoting OSI to the academic, industrial and governmental research and development organisations in Europe. The countries involved are those of the EC, EFTA plus Yugoslavia; that is: Austria, Belgium, Denamark, Finland, France, Germany, Greece, Holland, Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom, and Yugoslavia. The partners funded by PARADISE besides UCL are: - the Networks Group at the University of London Computer Centre (ULCC), which is a service-oriented organisation providing a range of facilities to the academic community in London and the entry point into the UK for IXI, the COSINE international X.25 backbone; - X-Tel Services Ltd, a software company based in Nottingham which currently provides service support to the UK Academic X.500 pilot; and - PTT Telematic Systems from the Netherlands, which in turn has subcontracted the Swiss and Finnish PTTs, and whose involvement is to create a forum for discussion on X.500 among the European carrier administrations. The project also aims to have representation from all the participating countries, which in the majority of cases are the existing X.500 national pilots. Of the 18 countries involved, 12 are registered in the tree, including Ireland and Italy whose nodes were taken up this month. Most countries are using the QUIPU implementation developed at UCL. However, a French group have developed PIZARRO, which will form the basis of the emerging French pilot and, in Italy, a Torino-based company Systems Wizards are using DirWiz, which is curently the sole representative from Italy in the tree. PARADISE recently announced an operational service providing a central configuration DSA with connectivity via IPSS, IXI, JANET (UK Joint Academic Network) and the Internet. This DSA contains the "root of the world" node and provides the glue at the top of the international DIT. By this summer a central DUA will be installed with public access via ULCC. Multilingual versions of this interface will be made available later in the project. Both these central services will be provided by ULCC, which will be offering a help desk with telephone and e-mail support. David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager PSI WHITE PAGES PILOT PROJECT ----------------------------- As of 91-03-27: There are 74 sites under c=US, 66 operating as PRDMDs. New additions this month: Sun Microsystems Incorporated Steve Kille's quality-of-service object classes and attributes (defined in draft-ietf-osids-qos-00.txt) were implemented. The attributes and object classes defined in NADF-123 (RFC-1218) were implemented. Based on NADF-123 and Kille's draft-ietf-osids-dsanaming-00.txt, an initial draft of a transition scheme for the c=US DIT is being drafted. Pilot participants were informed about the upcoming transition, and will receive the next version of the transition scheme, which is nearly complete. Marshall Rose (mrose@cheetah.ca.psi.com)   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13206-0@bells.cs.ucl.ac.uk>; Thu, 11 Apr 1991 14:24:35 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Modfied Agenda for Videoconference Phone: +44-71-380-7294 Date: Thu, 11 Apr 91 14:24:33 +0100 Message-ID: <3765.671376273@UK.AC.UCL.CS> From: Steve Kille Here is an updated Agenda. The changes reflect attendance. I've reduced the amount of time on the Networks paper, as Chris won't be attending and Mark is on a telephone. I've also added a section to talk about the monthly reporting. Steve Agenda for fourth meeting of IETF Directory Services Group (Revision 1) S.E. Kille April 11, 1991 This is a joint meeting with members of RARE WG3. Date Videoconference on Thursday 11th April UCL 17:00 - 21:00 BST BBN 12:00 - 16:00 EDT RIACS (Bay Area) 09:00 - 13:00 PDT Draft agenda follows. Times are ``UCL time'' (BST) 1 Tuesday 17:00 Introduction o Discussion of Videoconference modus operandi o Agenda o Minutes of previous meeting o Matters arising o No liaisons! 1 17:15 Document Status. Review status of all working documents, Internet Drafts, and submitted RFCs. 17:25 Presentation of Pilot Activitiy DISI (Chris Weider) Paradise (David Goodman) FOX (Steve Hotz, Bob Braden, Ruth Lang) RARE WG3 (Erik Huizer) Top level DSA configuration (Colin Robbins) 18:15 Monthly Reporting (Steve Hotz/David Goodman) 18:30 US/Europe liaison issues 18:45 Management of ``experimental'' object identifiers 19:00 Naming Guidelines (Paul Barker) 19:15 Representing Network Information (Mark Knopper??) 19:45 Security (Peter Yee) 20:20 Naming in the US in light of NADF 123 (Einar Sefferud) 20:50 Date and Venue of next meeting 20:50 -- 21:00 AOB 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13251-0@bells.cs.ucl.ac.uk>; Thu, 11 Apr 1991 14:26:43 +0100 To: mak@edu.merit cc: osi-ds@uk.ac.ucl.cs, Andy Veitch , video-conf-request@com.BBN Subject: Re: ISI will be the fourth site Phone: +44-71-380-7294 In-reply-to: Your message of Mon, 08 Apr 91 23:30:58 -0400. <9104090330.AA16805@home.merit.edu> Date: Thu, 11 Apr 91 14:26:42 +0100 Message-ID: <3781.671376402@UK.AC.UCL.CS> From: Steve Kille >From: mak@edu.merit >To: Steve Kille >Subject: Re: ISI will be the fourth site >Date: Mon, 08 Apr 91 23:30:58 -0400 >Steve, > Chris will be on vacation that day but I would like to be >able to participate by phone at least for the discussion >about FOX-related issues. Could you give me an updated >time for that part of the discussion? Perhaps it might >be possible to have someone call me during the meeting >so that I can join by voice at the appropriate time? >My phone number is +1 313 763-6061. > Mark Mark, We'll try to sort something out. I've just posted the Agenda, which gives a new time. Someone will call you at the appropriate time. Steve   Return-Path: Received: from nrtc.northrop.com by bells.cs.ucl.ac.uk with SMTP inbound id <27250-0@bells.cs.ucl.ac.uk>; Mon, 15 Apr 1991 19:35:52 +0100 Received: from nma.com by nrtc.nrtc.northrop.com id aa01417; 15 Apr 91 10:35 PST Received: from odin.nma.com by nma.com id aa08074; 15 Apr 91 10:23 PDT Received: from nrtc.northrop.com by nma.com id aa26776; 3 Apr 91 18:15 PST Received: from ics.uci.edu by nrtc.nrtc.northrop.com id aa13348; 3 Apr 91 18:00 PST Received: from nrtc.northrop.com by ICS.UCI.EDU id aa15359; 3 Apr 91 17:48 PST Received: from adm.brl.mil by nrtc.nrtc.northrop.com id aa13318; 3 Apr 91 17:47 PST Received: from vgr.brl.mil by ADM.BRL.MIL id aa05845; 3 Apr 91 20:43 EST Received: from NIC.DDN.MIL by VGR.BRL.MIL id aa08110; 3 Apr 91 20:27 EST Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 3 Apr 91 14:53:07 PST Posted-Date: Wed, 03 Apr 91 14:53:42 PST Message-Id: <9104032253.AA04978@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.61/5.61+local) id ; Wed, 3 Apr 91 14:53:46 -0800 To: Request-for-Comments-List:; Subject: RFC1218 on A Naming Scheme for c=US Cc: jkrey@edu.isi Reply-To: jkrey@edu.isi Date: Wed, 03 Apr 91 14:53:42 PST From: "Joyce K. Reynolds" Prev-Resent-Date: Wed, 3 Apr 91 17:48:25 PST Prev-Resent-From: stef@ics.uci.edu Prev-Resent-To: stef%nma.com@nrtc.northrop.com Resent-To: osi-ds@uk.ac.ucl.cs Resent-Date: Mon, 15 Apr 91 11:22:10 MDT Resent-Message-ID: <13413.671739730@nma.com> Resent-From: Einar Stefferud A new Request for Comments is now available from the Network Information Center in the online library at NIC.DDN.MIL. RFC 1218: Title: A Naming Scheme for c=US Author: The North American Directory Forum Mailbox: mrose@psi.com Pages: 23 Characters: 42,698 Updates/Obsoletes: none pathname: RFC:RFC1218.TXT This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). The NADF is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. RFCs can be obtained via FTP from NIC.DDN.MIL, NIS.NSF.NET, or NISC.JVNC.NET. RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login with FTP, username "anonymous" and password "guest". The NIC also provides an automatic mail service for those sites which cannot use FTP. Address the request to SERVICE@NIC.DDN.MIL and in the subject field of the message indicate the RFC number, as in "Subject: RFC nnnn". To obtain RFCs from NIS.NSF.NET via FTP, login with username "anonymous" and password "guest"; then connect to the RFC directory ("cd RFC"). The file name is of the form RFCnnnn.TXT-1 (where "nnnn" refers to the number of the RFC). The NIS also provides an automatic mail service for those sites which cannot use FTP. Address the request to NIS-INFO@NIS.NSF.NET and leave the subject field of the message blank. The first line of the text of the message must be "SEND RFCnnnn.TXT-1", where nnnn is replaced by the RFC number. RFCs can also be obtained via FTP from NISC.JVNC.NET, with the pathname rfc/RFCnnnn.TXT.v.Z (where "nnnn" refers to the number of the RFC and "v" refers to the version number of the RFC). There are a number of RFCs available in postscript format. Those RFCs have modifiers of .PS instead of .TXT. Login with FTP, username "anonymous" and your e-mail address as your password. JvNCnet also provides a mail service for those sites which cannot use FTP. Address the request to NISC@JVNC.NET and in the subject field of the message indicate the RFC number, as in "Subject: RFC nnnn". Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Requests to be added to or deleted from this distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Joyce K. Reynolds USC/Information Sciences Institute   Return-Path: Received: from ws28.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <24504-0@bells.cs.ucl.ac.uk>; Wed, 17 Apr 1991 18:09:12 +0100 Received: by ws28.nisc.sri.com (5.64/SRI-NISC1.1) id AA01277; Wed, 17 Apr 91 10:08:55 -0700 Message-Id: <9104171708.AA01277@ws28.nisc.sri.com> To: iso@mil.ddn.nic, isode@mil.ddn.nic, osi-ds@uk.ac.ucl.cs, D.Goodman@uk.ac.ucl.cs, disi@edu.merit Cc: wright@gov.lbl, rlang@com.SRI.NISC Subject: X.500 Survey -- please respond Date: Wed, 17 Apr 91 10:08:53 PDT From: Ruth Lang X.500 Implementation Survey Goal Of This Survey: To gather information regarding currently available implementations of X.500 including products, public domain and openly available offerings. The Directory Information Services (pilot) Infrastructure (DISI) working group of IETF will produce an RFC/FYI that identifies existing implementations of the X.500 standard. This RFC/FYI will provide information to the Internet community regarding the availability and capability of X.500 implementations. It will not specify a standard, list IAB policy, or list IAB recommendations. It will be similar in intent, nature, and scope to the Network Management Tools Catalog (RFC 1147/FYI 2). Instructions For Completing This Survey: If you are an X.500 implementor or product representative, please fill-out this survey using one form per application suite or named application. Return completed forms by May 3, 1991 to: Ruth Lang (rlang@nisc.sri.com) Russ Wright (wright@lbl.gov) Questions regarding how to complete the survey may also be sent to either Ruth Lang or Russ Wright. We apologize for the duplicates received by those of you who are on some or all of the mailing list recipients of this message. Please feel free to pass this survey form on to others who may have something to contribute but are not on any of the lists above. The editors and the DISI working group thank you for your participation! X.500 Product and Public Domain Implementation Survey Return completed forms by May 3, 1991 to: Ruth Lang (rlang@nisc.sri.com) Russ Wright (wright@lbl.gov) NAME: ABSTRACT: COMPLETENESS: INTEROPERABILITY: BUGS: CAVEATS and GENERAL LIMITATIONS: INTERNETWORKING ENVIRONMENT: HARDWARE PLATFORMS: SOFTWARE PLATFORMS: AVAILABILITY: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4109-0@bells.cs.ucl.ac.uk>; Fri, 19 Apr 1991 10:10:51 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 19 Apr 91 10:10:52 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 23rd March - Friday 5th April. Probes performed from STC, ULCC, UCL, Brunel, Adelaide University. Bind Fail %age Best Worst Ave Address GB: Coypu (Thorn acces pt to quipu) 43 0 100.00 0.9 3.1 1.21 Local Ether 43 0 100.00 1.3 3.4 1.57 Janet 71 7 90.14 2.5 138.2 10.06 X121 99 14 85.86 0.8 75.4 12.60 Internet 56 10 82.14 1.3 5.3 2.68 Janet False Cobra (Giant Tortoise backup) 43 1 97.67 1.2 2.0 1.38 Janet 71 8 88.73 2.4 43.2 5.88 X121 99 17 82.83 0.4 38.1 7.48 Internet 43 37 13.95 3.3 5.5 4.07 IXI Vampire Bat (GB backup) 55 5 90.91 1.2 5.7 1.75 Janet 55 7 87.27 2.0 11.2 3.70 IXI 43 10 76.74 2.6 15.2 4.80 Janet 43 38 11.63 3.3 14.8 6.58 IXI 43 43 0.00 - - - NS Giant Tortoise (Root, GB Master) 43 10 76.74 1.6 79.2 6.06 Janet 99 42 57.58 0.6 29.6 6.60 Internet 71 31 56.34 1.8 82.8 7.61 X121 43 43 0.00 - - - IXI 55 55 0.00 - - - IXI 55 55 0.00 - - - Janet Passionflower Leaf Beetle (GB Domain name information) 99 26 73.74 0.5 94.6 12.09 Internet 43 43 0.00 - - - Janet 43 43 0.00 - - - IXI 71 71 0.00 - - - X121 Maned Sloth (Edinburgh, DSA holding NRS info) 43 43 0.00 - - - Janet 55 55 0.00 - - - Janet NL: Agouti (NL Slave) 97 5 94.85 3.8 89.0 17.05 Internet Hornero (NL Master) 99 46 53.54 3.9 97.0 27.58 Internet 71 35 50.70 4.3 72.5 16.08 X121 DE: Puma (GMD/FOKUS) 55 3 94.55 2.1 119.2 6.75 IXI 71 9 87.32 4.7 61.3 9.91 Int-X.25 99 35 64.65 4.6 117.5 30.17 Internet 43 37 13.95 5.3 7.7 6.48 IXI Margay (GMD/F3, DE backup) 55 4 92.73 1.9 10.9 3.60 IXI 70 9 87.14 6.3 104.8 24.75 Int-X.25 99 28 71.72 5.1 107.9 26.39 Internet 43 37 13.95 6.1 17.3 10.00 IXI AU: Anaconda (AU Master) 99 9 90.91 1.3 48.1 7.73 Internet 71 11 84.51 10.8 152.7 30.06 Int-X.25 Bush Dog (master for AU (phony)) 98 13 86.73 0.7 75.1 7.86 Internet NO: Boa Constrictor (Norway Backup) 56 6 89.29 3.3 16.8 7.76 IXI 98 16 83.67 8.9 100.1 29.16 Internet 70 34 51.43 4.0 58.3 10.47 Int-X.25 43 43 0.00 - - - IXI Electric Eel (Norway Master) 56 11 80.36 1.7 1356.5 74.48 IXI 99 37 62.63 3.8 78.8 24.21 Internet 71 42 40.85 4.5 60.2 10.65 Int-X.25 43 40 6.98 4.4 15.1 8.23 IXI US: Fruit Bat (US@l=NY master) 99 11 88.89 2.7 52.7 16.06 Internet Alpaca (US master) 99 22 77.78 2.9 30.8 7.94 Internet Giant Anteater (Various slave) 99 23 76.77 3.9 87.5 10.57 Internet CA: Pangolin (Northern Telecom Master) 99 13 86.87 4.2 101.6 17.41 Internet 43 43 0.00 - - - NS Wayne Gretzky (Canada Master) 99 76 23.23 3.5 87.5 17.09 Internet SE: Hummingbird (Sweden Master) 98 17 82.65 4.2 104.1 27.87 Internet 70 26 62.86 4.8 174.1 14.90 X121 ES: Iguana (ES Master. Programa IRIS) 55 10 81.82 2.4 16.9 6.87 IXI 71 23 67.61 7.1 152.5 28.27 Int-X.25 99 38 61.62 4.0 107.4 50.14 Internet 43 42 2.33 47.8 47.8 47.80 IXI 10 10 0.00 - - - NS 10 10 0.00 - - - NS 23 23 0.00 - - - NS Cayman (Madrid Uni.) 71 19 73.24 7.2 111.5 28.87 Int-X.25 99 28 71.72 6.5 88.0 28.61 Internet 56 17 69.64 2.1 14.7 4.20 IXI 43 38 11.63 12.6 19.5 15.26 IXI CH; Chinchilla (Swiss Master) 99 19 80.81 4.5 113.0 17.59 Internet 71 71 0.00 - - - Int-X.25 Condor (ETH Zurich) 71 29 59.15 4.5 92.6 17.31 Int-X.25 99 41 58.59 3.1 103.9 13.00 Internet FI Jaguar (Finland Master) 99 27 72.73 6.7 119.8 33.29 Internet 70 63 10.00 13.6 103.8 44.96 X121 43 43 0.00 - - - NS DK: Axolotl (DK Master) 99 28 71.72 4.9 106.2 29.93 Internet IS: Elephant Seal (IS Master) 99 33 66.67 10.7 84.7 35.68 Internet   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <21631-0@bells.cs.ucl.ac.uk>; Fri, 19 Apr 1991 14:46:51 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Fri, 19 Apr 1991 14:39:05 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Fri, 19 Apr 1991 14:42:52 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Fri, 19 Apr 1991 16:44:00 +0100 Date: Fri, 19 Apr 1991 13:39:05 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.392:19.03.91.13.42.52] X400-Content-Type: P2-1984 (2) Content-Identifier: Free tutorial... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"3398 Fri Apr 19 15:42:57 1991"@surver.surfnet.nl> To: RARE & IETF OSI-DS wg , us-wg@net.nsf.nnsc, nisi@edu.merit Subject: Free tutorials and Demo's at next RARE WG3 meeting X-VMS-To: OSI-DS Sender: HUIZER@nl.surfnet The subject line was constructed to make you read this :-) It is true though: This is to inform the non-Europeans and non-Uk people among you, that we are planning a special RARE WG3 meeting. This meeting will take place from 30 september till 3 october probably in Zurich, otherwise Geneva (both in Switzerland). This meeting will contain: One day tutorials and demo's on/of - installing a DSA - managing a DSA - X-windows DUA's - Mac dua's - PC-dua's - other dua's - Hypertext Information Server - Free text retrieval - NISP information Server - Concise Information Server - and anything else related to Directory Services and User Information Services I can get hold of and is interesting. Furthermore we will have the regular RARE WG3 Directory Services meeting and the RARE WG3 User Support and Information Services meeting We would like the tutorial and Demo's day (probably the 1st of october) to be really internationally oriented, combined with the fact that the meetings are open for international liaisons, this provides an excellent excuse to now go out and get your boss to fund you to come to this meeting. The cost of travel will surely be compensated by the FREE tutorials and demo's from which you learn in one day what would cost you about half a year when you stay home :-) We are hoping for a large North American attendance. Further information follows for those of you who mail me that they are interested. Erik huizer SURFnet BV chairman RARE WG3   Return-Path: Received: from lance.tis.llnl.gov by bells.cs.ucl.ac.uk with SMTP inbound id <26553-0@bells.cs.ucl.ac.uk>; Sat, 20 Apr 1991 00:00:17 +0100 Received: by lance.tis.llnl.gov (4.1/LLNL-1.18) id AA13415; Fri, 19 Apr 91 15:56:42 PDT Message-Id: <9104192256.AA13415@lance.tis.llnl.gov> Date: Fri, 19 Apr 91 15:56:40 -0800 From: genovese@net.es Subject: Re: Some "ideas" on DIT transition To: osi-ds@uk.ac.ucl.cs, wpp-camayocs@net.psi.nisc Cc: Stef@edu.uci.ics X-Orig-Date: Fri, 19 Apr 91 11:56:49 MDT X-Orig-From: Einar Stefferud X-Orig-Message-Id: <16829.672087409@nma.com> In your message you write: > > (I hate to bring this up again, but.... :-) > > NO PROBLEM;-) > Since I will be gone all next week I had hoped we could put this obvious unsolved problem off until the NADF releases the paper on "sharing" DIT information. > But, you should not forget that your authorization to use your name > does not define where you can or should be listed in the directory. > > This is the major breakthrough in thinking that resulted in NADF123. I don't see the NADF as a humanatarian organization that is looking out for my customers best interests. They are big commercial orgs that met in private to decide how they were going to establish and protect their interest. At least this is the preception of some :) > > YOU SHOULD WANT TO BE LISTED WHERE PEOPLE WILL FIND YOUR LISTING! > (Else, why bother to be listed at all!) I thought Bob Aiken pointed out that this was not obvious to us so how could someone on high determine the best solution. Again I guess I missed the devine insight. The rest was an eloquent argument for a moot court. But, people want to have control over the name space so ... I want to know how will Private Directory Management Domains (PRDMD) peer with each other without having to use Administration Directory Management Domains (ADDMD). I don't see any reason why NSFnet, ESnet, NASA, LLNL, HP and others could not peer wihout using an ADDMD. You would probably agree. Yet I have not seen any discussion on this infrastructure, I may of missed it but in any case it is not clear to me. Maybe the NADF in the goodness of their golden hearts worked out a way we could do bussiness without them. And maybe they will share it with us as they did the first 122 documents. If this peering was worked out then LLNL could pick c=us; o=LLNL and anyone that wanted to peer (ADDMD or PRDMD) with them would know how to work it out. There would not be any name collision because we are all good people and we have registered with ansi. This discussion looks alot like the one on ADMD vs PRMD in X.400. There it was overt because the address fields include the ADMD and PRMD. If we don't work out PRDMD peering in X.500 we may end up like some countries in the X.400 world having to use ADMDs. I would still like to give the NADF the benefit of the doubt and wait for their document. tony.   Return-Path: Received: from ics.uci.edu by bells.cs.ucl.ac.uk with SMTP inbound id <16060-0@bells.cs.ucl.ac.uk>; Sat, 20 Apr 1991 01:38:26 +0100 Received: from ics.uci.edu by ics.uci.edu id aa18382; 19 Apr 91 17:37 PDT To: genovese@net.es cc: osi-ds@uk.ac.ucl.cs, wpp-camayocs@net.psi.nisc Subject: Re: Some "ideas" on DIT transition In-reply-to: Fri, 19 Apr 91 15:56:40 I. <9104192256.AA13415@lance.tis.llnl.gov> Cc: Einar Stefferud Date: Fri, 19 Apr 91 17:36:56 -0700 Message-ID: <18380.672107816@ics.uci.edu> From: Einar Stefferud Hi Tony -- It appears that our NADF123 document is a bit too much of an internal document and as such is hard for "outsiders" to comprehend, without a tutorial. In a phone call with Marshall the other day we agreed that we need to do something to make it easier to find the real basic messages in the document. What to do is not entirely obvious (or we might have done it). So, your remarks are pretty much on the mark, in terms of what a properly suspicious person might expect from NADF THE BIG BOYS. They (we) do seem to have an image problem. But, let me try to push that aside by saying that I (and other NADFers will agree I am sure) do not share any thoughts of trying to be closed in the ways you suggest. I also do not feel that the rest of the NADF participants have any of these thoughts, though I am sure that competitive interests are not lacking. One aspect of this is that there does not appear to be a lot of revenue to generated with a Public Directory. Instead, the whole thing can be viewed as a necessary cost of doing business, with a high interest in keeping the costs to a minimum. It is viewed as a cost sharing problem, not a revenue sharing problem. This tends to reduce "monopoly fever!" NADF documents are not restricted to members, though we are not shipping them free to everyone. Many of them would not be good reading in any case, cause they are half baked working documents, and harder to read than NADF123. But, all that aside, let me try to answer your basic questions and "charges". I believe that the mechanisms that are in development for "peer level sharing" among ADDMDs will work just as well among PRDMDs, with the requirement that some kind of agreements have to be made and sharing facilities have to be implemented and installed (what ever that means), among the sharing partners whoever they may be). I wish I could explain exactly what that means, but that is what is in the paper that is not yet completely written, so we can only ask that you be patient with us. It will however be made openly public and widely circulated with a request for comment, as was NADF123 (RFC1218). To give you a hint (non-authoritative) which I hope will not be found to be in error ... :-( There will have to be a shared public DIT that holds the DN for all entities that are arranged to be listed in the Public Directory. For each DN in that tree there will will be an entry that serves as a "link" which is very nearly a multi-valued "alias". At least for this message, consider this "link" to be exactly a "multi-valued X.500 alias". This link then contains a set of DNs for ADDMD (and maybe PRDMD) entries that hold information of interest. (e.g., PacBel holds your phone number entry, MCImail holds your MCImail address information, SPRINTmail holds your TELEMAIL address information, LLNL holds your office address and office phone number, etc). (I Don't know if LLNL wants to do this, but this is just an example.) Each listed entity will be expected to negotiate (arrange) with their service providers who hold their information entries (PacBel, MCImail, SPRINTmail, etc) to add their entry (listing) to the Public DIT under your own DN, so that public directory lookup can be accomplished. Now, just how PRDMDs will arrange to link into this has not yet been resolved, if it has even been seriously discussed, but you can be sure that it is not far from the front burner. However, there is no intention that I can detect that this is to become a closed monopoly situation of some miserable kind. [I must however congratulate you on observing that this is the X.500 [analog of the X.400 ADMD and PRMD attribute problem, and your [observation that X.500 at least figured out to keep the ADDMD and PRDMD [attributes out of our Directory Names. This in critically important, [and is a major factor in development of the "link" technology for [sharing of the DN name space in a public DIT. Shifting to wear my State Dept SG-D MHS-MD Subcommittee member hat, I can suggest that SG-D is going to have the same interests in this Public Directory that it has in the Public X.400 "backbone" arrangements. I expect that the same ITU treaty obligations will apply to the situation, such that if any single country unilaterally decides to declare X.500 directory service to be a "basic service", then all US providers of public X.500 services will have to facilitate open access from any foreign access point to any entry in the Public DIT, subject to access controls on the entry contents (of course). So, I don't think you should need to worry about the NADF hunkering down in a dark cave to somehow do things that you will not like. However, wearing my "Consultant to PRMD Users Hat", let me suggest that the NADF is indeed looking out from their service providers ADDMD cave, and not looking out from inside your PRDMD cave. So, how about someone forming a PRDMD-NADF to look out for PRDMD interests? This has recently happened with the EMA setting up a PRMD Operators Group (EMA-POG) as a subunit of the EMA. This is partly in response to the IAOG (International ADMD Operators Group) which looks out for international interests of ADMDs. (Unfortunately, the EMA-POG is closed to only EMA paying members, so it is less open than the NADF which admits anyone who represents an entity that declares its intention to offer a public directory service in North America, and who agrees to cover their share of NADF costs of operation.) I suggest that if someone forms a PRDMD-NADF, that it not be restricted in membership to members of some other high cost organization. It should also plan to collaborate with the NADF. Who knows, maybe it can organize itself the same way as the NADF, as an independent and open shared cost operation? I hope this helps to ease your concerns. It is worth worrying about fur sure! On the other hand, I think the technical solutions we have hammered out in the NADF will be as open as you could hope for, and will serve to help you solve your PRDMD problems too. I also trust that I have not crossed up the NADF be saying all this without benefit of clearing it with anyone first. You have to accept this from me as an individual with no authority to speak for the NADF. (I normally avoid these disclaimers, but in this case I must disclaim.) Cheers...\Stef   Return-Path: Received: from cheetah.ca.psi.com by bells.cs.ucl.ac.uk with SMTP inbound id <16611-0@bells.cs.ucl.ac.uk>; Sat, 20 Apr 1991 10:01:41 +0100 Received: from localhost by cheetah.ca.psi.com at Sat, 20 Apr 91 02:01:18 -0700. (5.61.14/XIDA-1.2.8.34) id AA26419 for osi-ds@cs.ucl.ac.uk via SMTP To: genovese@net.es Cc: osi-ds@uk.ac.ucl.cs, wpp-camayocs@net.psi.nisc, Stef@edu.uci.ics Reply-To: wpp-camayocs@net.psi.nisc Subject: Re: Some "ideas" on DIT transition In-Reply-To: Your message of Fri, 19 Apr 91 15:56:40 -0800. <9104192256.AA13415@lance.tis.llnl.gov> Date: Sat, 20 Apr 91 02:01:16 -0700 Message-Id: <26416.672138076@cheetah.ca.psi.com> From: Marshall Rose No one ever claimed the NADF was chartered under the International Red Cross. On the other hand, any talk of conspiracy is plain fantasy. Having a c=US naming scheme is in the best interests of anyone who wants X.500 to work in the US. Unfortunately, until the NADF came along, no one had the chutzpah to propose one. Upon a careful examination of the NADF proposal, one will find that there are two major namespaces: public and service-provider. The public namespace is based on existing civil authority. There is nothing that prevents *any* organization from acting as its own PRDMD, and simply using its public listing as the "mount point" from the public space into its own space. What that organization does with that subtree is its problem. The key thing here is that two organizations can communicate X.500 information directly without any involvement of an ADDMD. The service-provider namespace is for ADDMDs. Organizations may, or may not, wish to have an ADDMD operate their organization subtree, and if so, naming links are inserted in the public namespace (whether the organization is listed) to a service-provider namespace (where the data resides). As a result, ADDMDs are irrelevant. It is up to the organizations or people being listed in the public namespace as to who manages the data. Given this perspective, I think the NADF proposal falls a lot closer to the Red Cross end of the spectrum than the Illuminati end of the spectrum. /mtr   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <8299-0@bells.cs.ucl.ac.uk>; Thu, 25 Apr 1991 17:08:22 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Videoconference minutes Phone: +44-71-380-7294 Date: Thu, 25 Apr 91 17:07:50 +0100 Message-ID: <1457.672595670@UK.AC.UCL.CS> From: Steve Kille I have all the pieces. Have not been able to find time to edit. Will do this when I get back on May 20th. Steve   Return-Path: Received: from ws28.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <8167-0@bells.cs.ucl.ac.uk>; Wed, 1 May 1991 16:10:47 +0100 Received: by ws28.nisc.sri.com (5.64/SRI-NISC1.1) id AA07481; Wed, 1 May 91 08:10:02 -0700 Message-Id: <9105011510.AA07481@ws28.nisc.sri.com> To: iso@mil.ddn.nic, isode@mil.ddn.nic, osi-ds@uk.ac.ucl.cs, D.Goodman@uk.ac.ucl.cs, disi@edu.merit Cc: wright@gov.lbl, rlang@com.SRI.NISC Subject: X.500 Survey Reminder Date: Wed, 01 May 91 08:10:01 PDT From: Ruth Lang Folks, The May 3 deadline is approaching quickly. Please send your survey responses to Russ and me by that date. One of the DISI members suggested that statements be made in the COMPLETENESS session in reference to Section 9 of X.519. Please do so. We will contact those of you who have already returned your survey input if more information is needed. As Russ Wright is on vacation until May 6, please refer any questions to me. Ruth Lang -------------------------------------- X.500 Implementation Survey Goal Of This Survey: To gather information regarding currently available implementations of X.500 including products, public domain and openly available offerings. The Directory Information Services (pilot) Infrastructure (DISI) working group of IETF will produce an RFC/FYI that identifies existing implementations of the X.500 standard. This RFC/FYI will provide information to the Internet community regarding the availability and capability of X.500 implementations. It will not specify a standard, list IAB policy, or list IAB recommendations. It will be similar in intent, nature, and scope to the Network Management Tools Catalog (RFC 1147/FYI 2). Instructions For Completing This Survey: If you are an X.500 implementor or product representative, please fill-out this survey using one form per application suite or named application. Return completed forms by May 3, 1991 to: Ruth Lang (rlang@nisc.sri.com) Russ Wright (wright@lbl.gov) Questions regarding how to complete the survey may also be sent to either Ruth Lang or Russ Wright. We apologize for the duplicates received by those of you who are on some or all of the mailing list recipients of this message. Please feel free to pass this survey form on to others who may have something to contribute but are not on any of the lists above. The editors and the DISI working group thank you for your participation! X.500 Implementation Survey Return completed forms by May 3, 1991 to: Ruth Lang (rlang@nisc.sri.com) Russ Wright (wright@lbl.gov) NAME: ABSTRACT: COMPLETENESS: INTEROPERABILITY: BUGS: CAVEATS and GENERAL LIMITATIONS: INTERNETWORKING ENVIRONMENT: HARDWARE PLATFORMS: SOFTWARE PLATFORMS: AVAILABILITY: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18790-0@bells.cs.ucl.ac.uk>; Fri, 3 May 1991 11:17:09 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 03 May 91 11:17:00 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 19th April - Friday 3rd May. Probes performed from STC, ULCC, UCL, Brunel, Adelaide University. Bind Fail %age Best Worst Ave Address NO: Boa Constrictor (Norway Backup) 47 0 100.00 2.5 21.4 7.14 IXI 108 27 75.00 6.4 108.8 28.52 Internet 168 124 26.19 4.2 98.8 11.33 Int-X.25 52 52 0.00 - - - IXI Electric Eel (Norway Master 47 0 100.00 1.8 7.4 3.22 IXI 108 16 85.19 3.3 104.8 22.25 Internet 52 11 78.85 3.5 14.1 6.33 IXI 167 121 27.54 4.5 41.1 9.21 Int-X.25 GB: Coypu (Thorn acces pt to quipu) 52 0 100.00 0.9 7.7 1.73 Local Ether 52 0 100.00 1.3 13.1 2.19 Janet 169 1 99.41 2.5 49.9 10.86 X121 47 2 95.74 1.3 8.5 3.48 Janet 108 13 87.96 0.7 65.0 11.60 Internet False Cobra (Giant Tortoise backup) 52 0 100.00 1.2 2.6 1.40 Janet 168 6 96.43 2.4 42.7 7.90 X121 52 3 94.23 2.7 23.3 5.22 IXI 108 18 83.33 0.4 43.5 7.51 Internet Vampire Bat (GB backup) 46 5 89.13 1.2 6.6 1.86 Janet 46 5 89.13 2.1 10.8 3.36 IXI 51 8 84.31 2.8 28.4 5.60 Janet 51 14 72.55 3.2 15.8 5.99 IXI 51 51 0.00 - - - NS Passionflower Leaf Beetle (GB Domain name information) 106 14 86.79 0.5 111.6 14.34 Internet 165 165 0.00 - - - X121 51 51 0.00 - - - Janet 51 51 0.00 - - - IXI Giant Tortoise (Root, GB Master) 52 13 75.00 1.9 16.9 3.44 Janet 52 14 73.08 1.8 79.4 17.43 IXI 167 69 58.68 2.1 81.1 8.87 X121 108 64 40.74 0.6 27.1 6.36 Internet 46 46 0.00 - - - IXI 46 46 0.00 - - - Janet Maned Sloth (Edinburgh, DSA holding NRS info) 46 46 0.00 - - - Janet 52 52 0.00 - - - Janet DE: Margay (GMD/F3, DE backup) 166 5 96.99 4.9 155.3 25.64 Int-X.25 52 3 94.23 3.6 50.6 8.73 IXI 46 3 93.48 2.0 8.8 3.27 IXI 107 24 77.57 3.6 92.0 25.63 Internet Puma (GMD/FOKUS) 165 26 84.24 4.6 60.7 8.16 Int-X.25 46 10 78.26 2.1 7.3 3.09 IXI 51 13 74.51 4.1 10.2 5.74 IXI 106 31 70.75 3.9 113.2 22.50 Internet AU: Anaconda (AU Master) 108 10 90.74 1.7 86.8 9.15 Internet 169 21 87.57 8.5 241.4 44.85 Int-X.25 Bush Dog (master for AU (phony)) 108 20 81.48 0.8 31.5 8.13 Internet CA: Pangolin (Northern Telecom Master) 106 10 90.57 4.2 102.6 17.76 Internet 51 51 0.00 - - - NS Wayne Gretzky (Canada Master) 106 82 22.64 4.4 65.5 14.44 Internet NL: Agouti (NL Slave) 108 14 87.04 4.2 51.1 15.96 Internet Hornero (NL Master) 167 47 71.86 5.6 126.8 19.33 X121 108 35 67.59 6.0 116.1 24.05 Internet SE: Hummingbird (Sweden Master) 107 21 80.37 3.7 109.1 23.56 Internet 167 79 52.69 4.7 219.5 22.93 X121 CH: Chinchilla (Swiss Master) 108 30 72.22 4.7 96.5 15.82 Internet 161 161 0.00 - - - Int-X.25 Condor (ETH Zurich) 108 34 68.52 3.0 112.9 16.36 Internet 169 61 63.91 4.9 157.2 19.55 Int-X.25 FI: Jaguar (Finland Master) 107 30 71.96 6.4 101.3 33.91 Internet 166 105 36.75 7.4 182.2 51.14 X121 52 52 0.00 - - - NS DK: Axolotl (DK Master) 108 34 68.52 5.2 121.9 27.92 Internet US: Alpaca (US master) 108 36 66.67 3.0 28.5 8.40 Internet Fruit Bat (US@l=NY master 108 37 65.74 4.1 87.8 21.68 Internet Giant Anteater (Various slave) 108 59 45.37 4.0 26.1 9.07 Internet IS: Elephant Seal (IS Master) 108 47 56.48 8.2 90.3 34.57 Internet ES: Cayman (Madrid Uni.) 169 103 39.05 8.7 247.8 42.12 Int-X.25 52 37 28.85 7.4 20.8 12.78 IXI 108 80 25.93 9.3 94.1 37.76 Internet 47 35 25.53 2.3 12.0 5.04 IXI Iguana (ES Master. Programa IRIS) 167 123 26.35 8.4 214.3 29.37 Int-X.25 46 35 23.91 2.6 14.5 7.40 IXI 107 88 17.76 5.0 112.7 36.06 Internet 52 43 17.31 7.8 35.9 19.43 IXI 52 52 0.00 - - - NS   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <24381-0@bells.cs.ucl.ac.uk>; Tue, 7 May 1991 21:21:36 +0100 Received: Tue, 7 May 91 16:21:42 EDT by mazatzal.merit.edu (5.51/1.6) Date: Tue, 7 May 91 16:21:42 EDT From: Chris Weider Message-Id: <9105072021.AA19428@mazatzal.merit.edu> To: disi@edu.merit, fox500@edu.merit, mrose@com.psi.ca.cheetah, osi-ds@uk.ac.ucl.cs Subject: Lack of communications.... Gang: I'm sorry I haven't been very responsive for the last few weeks. The reason this happened is that I got MARRIED Saturday, May 4th! The wedding preparations were a nightmare..... Be that as it may: I accidentally hosed my entire mail file this morning (I left a "1" off the front of one of my "delete" modifiers.) Could anyone who has something that I should see send me another copy of it? I'm particularly interested in anything from Marshall, Steve Kille, and Ruth Lang. Thanks a million! Chris Weider   Return-Path: Received: from lbl.gov by bells.cs.ucl.ac.uk with SMTP inbound id <4005-0@bells.cs.ucl.ac.uk>; Wed, 8 May 1991 03:43:31 +0100 Received: from Mac-mailer ([128.3.148.18]) by lbl.gov (4.1/1.39) id AA00299; Tue, 7 May 91 19:44:02 PDT Message-Id: <9105080244.AA00299@lbl.gov> Date: Tue, 07 May 91 19:43:28 From: wright@gov.lbl (Russ Wright) To: iso@mil.ddn.nic, isode@mil.ddn.nic, osi-ds@uk.ac.ucl.cs, D.Goodman@uk.ac.ucl.cs, disi@edu.merit Subject: X.500 Survey status Cc: wright@gov.lbl.csa1, rlang@com.sri.nisc Hi Everyone, Ruth and I would like to thank everyone for their help in providing X.500 survey information and suggestions. We have received 16 responses to the survey so far. There are more X.500 implementations out there and we would love to include them in our survey, but time is running out. In particular, Retix, Wollongong, Siemens and Unisys are reported to have implementations. Please complete those forms!!! I must admit that I bent the truth a bit when I said that we had received 16 responses. In reality, we have received 17 but lost one. Oops! So, if you completed a survey and are not on our list, please send it out again to Ruth and I. Ruth Lang (rlang@nisc.sri.com) Russ Wright (wright@lbl.gov) Below is a list of the responses we have received. Thank You, Russ Name Type Submitter E-mail address ------------------------------------------------------------------------------ Alliance OSI X.500 DSA/DUA Vince Hunt vince@touch.com Custos DSA/DUA Len Gebase gebase@osi3.ncsl.nist.gov Directory 500 DSA/DUA Duncan Stickings dunc@vancouver.osiware.bc.ca DIXIE DUA Tim Howes tim.howes@terminator.cc.umich.edu QUIPU DSA Colin Robbins c.robbins@xtel.co.uk maX.500 DUA Tim Howes tim.howes@terminator.cc.umich.edu MDUA DUA Colin Robbins c.robbins@xtel.co.uk POD DUA Damanjit S Mahl damanjit.mahl@brunel.ac.uk SD DUA Damanjit S Mahl damanjit.mahl@brunel.ac.uk UCOM.X 500 DSA/DUA Philippe Brun phb@phil.sync.fr VTT X.500 DSA/DUA Asko Vilavaara asko.vilavaara@tel.vtt.fi XDI DUA Sze-Ying Wuu sywuu@thumper.bellcore.com XDS DUA Andrew Waugh ajw@mel.dit.csiro.au XDUA DUA Brian May brian.may@mel.dit.csiro.au XWP Browser Rob Hagens hagens@cs.wisc.edu X.500 DUA process DUA Ly Loi lll@snow.esd.3com.com   Return-Path: Received: from lbl.gov by bells.cs.ucl.ac.uk with SMTP inbound id <14056-0@bells.cs.ucl.ac.uk>; Fri, 10 May 1991 23:09:03 +0100 Received: from Mac-mailer ([128.3.148.18]) by lbl.gov (4.1/1.39) id AA14187; Fri, 10 May 91 15:09:51 PDT Message-Id: <9105102209.AA14187@lbl.gov> Date: Fri, 10 May 91 15:09:12 From: wright@gov.lbl (Russ Wright) To: osi-ds@uk.ac.ucl.cs Subject: New photo format Cc: wpp-camayocs@net.psi.nisc Hi Everyone, I hope I'm not alone when I say that the g3fax format we are using is pathetic. Is anyone looking into another format? I just bumped into an article on the JPEG still picture compression standard (Communications of the ACM, April 1991) which is being developed by CCITT and ISO. JPEG looks quite impressive and I think it deserves a hard look. Russ   Return-Path: Received: from ean-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <3423-0@bells.cs.ucl.ac.uk>; Mon, 13 May 1991 09:08:25 +0100 Received: from nsfnet-relay.ac.uk by Ean-Relay.AC.UK via Ethernet with SMTP id aa02372; 13 May 91 9:46 BST Received: from brolga.cc.uq.oz.au by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa02113; 13 May 91 8:56 BST Date: Mon, 13 May 91 18:03:39 EST From: G.Michaelson@au.oz.uq.cc Subject: how to discuss new objects/attributes before proposing? To: osi-ds@uk.ac.ucl.cs Sender: "G.Michaelson" the AARN DS project is on the cusp of creating some new objects and information types. the OSI-DS gives a framework for submitting requests for the registry of new types, but doesn't seem to propose a framework for their discusssion in the wider community. Before attempting to register our ideas, we'd like to see them discussed since they have global implications and might have less impact if structured after discussion. Is this feasible, and is osi-ds the right place to do this? -George   Return-Path: Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <8999-0@bells.cs.ucl.ac.uk>; Mon, 13 May 1991 10:11:28 +0100 To: G.Michaelson@au.oz.uq.cc cc: osi-ds@uk.ac.ucl.cs Subject: Re: how to discuss new objects/attributes before proposing? In-reply-to: Your message of Mon, 13 May 91 18:03:39 -0500. Date: Mon, 13 May 91 10:11:26 +0100 From: Paul Barker > Before attempting to register our ideas, we'd like to see them discussed > since they have global implications and might have less impact if structured > after discussion. > Is this feasible, and is osi-ds the right place to do this? There is a section in the "The COSINE and Internet X.500 Schema" which reads: It is anticipated that most requests for modifications to the schema will be met without any need for editorial intervention. Sometimes, however, some discussion between the submitter of a request and the schema's editor may be required. For example, the editor may have to judge the relative merits of two very similar requests and, as a result, one of the parties may not get quite what they want. In cases such as this where the submitter of a request feels aggrieved about an editorial decision, the requestor may appeal to a broader community by explaining their views to the mailing list osi-ds@cs.ucl.ac.uk. Heed will be paid to any consensus that emerges from discussions on the schema on this list. If it proves that this list is used almost solely for discussions on schema issues, a separate discussion list will be created. The procedures haven't been tested "in anger" yet, and will presumably settle over time. Until then, I might observe that since there hasn't been a welter of complaints against this piece of text, I would guess that osi-ds is the right place, initially at least, for information and discussion of the sort you propose. > -George Paul   Return-Path: Received: from ean-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <21660-0@bells.cs.ucl.ac.uk>; Tue, 14 May 1991 02:17:13 +0100 Received: from [130.102.128.5] by Ean-Relay.AC.UK via Ethernet with SMTP id aa11681; 14 May 91 2:57 BST Date: Tue, 14 May 91 11:16:52 EST From: G.Michaelson@au.oz.uq.cc Subject: attribute proposal: To: aarn-ds@au.oz.uq.cc Cc: osi-ds@uk.ac.ucl.cs Sorry Paul, I read that as meaning discussion followed a submission, not proceeded it. I shall carry on anyway. Attribute Type: Sourcetag Description: The Sourcetag attribute type specifies the source of another attribute. It is used to tag attributes with information about where their contents are derived from. This permits multiple data sources to be coordinated within the DIT, such as when the directory must co-exist with established MIS and PABX databases. OCMust: - this is probably a non-mandatory attribute OCMay: - this attribute is intended to be used with any attribute ASN1ATMacro:sourcetag ATTRIBUTE WITH ATTRIBUTE SYNTAX SEQUENCE { taggedAttribute, -identifies the attribute being tagged sourceInfo -details the data source } taggedAttribute ::= OBJECT IDENTIFIER - the OID of the attribute - being tagged sourceInfo ::= CHOICE { unknown [0] UTCTime, localMIS [1] UTCTime, localPABX [2] UTCTime, thisEntity [3] SEQUENCE { entityName DistinguishedName timeStamp UTCTime } Rationale behind the attribute type: at UQ, and at other places within the AARN ds project, we have had to accept the existance of multiple sources for common information. In the longterm we obviously seek to reduce these to as few as possible, ideally 1 data source for each attribute|entry|entity with all others 'shadowing' that data in some sense. In practice this is not possible. Instead the DIT has to tag data to identify source, and use external procedures to coordinate which source is used, and when changes are applied. The sourceTag uses OID to identify the attribute being tagged for obvious reasons. This does present a problem since multiple valued attributes cannot be separated into their instances. I suggest that this is a general problem with the OID and the multiple valued attribute, and should not be addressed by this extension but by some other mechanism such as instance-numbers. The Value identifies where the data has been sourced from, in an open-ended method. The default is "not known" but still provides a timestamp so that individual attributes can be timestamped, complementing the "lastmodified" record which applies to the whole entity. the second and third Values allow data to be tagged as coming from a locally meaningful offline information source. MIS and PABX typify the two sources of data we expect to be using to build the DIT. the fourth instance shows a proposed method for identifying explicitly the data source as an entity named in the DIT. This can of course be used to represent cases above, but they are suffiently common to justify optimisation. This attribute is a good candidate for attribute inheritance, where a single information source is used to construct most of the DIT. the exceptions can be identified by overrides. Comments requested. Is this totally off-beam? Can people suggest improvements to the (cruddy) ASN.1? -George   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 14 May 1991 11:01:12 +0100 Date: Tue, 14 May 1991 10:01:12 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.941:14.04.91.10.01.12] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Tue, 14 May 1991 11:01:12 +0100) From: Colin Robbins Message-ID: <"10540 Tue May 14 11:01:21 1991"@xtel.co.uk> To: G.Michaelson@au.oz.uq.cc Cc: aarn-ds@au.oz.uq.cc, osi-ds@uk.ac.ucl.cs Subject: Re: attribute proposal: Isn't the sourcing problem more complex than this. Your proposal suggests tagging each attribute with a source, I would argue that each value potentially need a source label. I have two telephone numbers registered in the DIT. One comes through a local exchange, so should be managed by the phone operators. The second is a direct line so is managed by me. Any management/upgrade scripts will need to know which phone numbers they are responsible for and so which they can change. I am sure someone has done some work on this, but I can't remember exactly who. The two people it might be are on this list, so I'm sure they'll say something soon... Colin   Return-Path: Received: from brunel.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <17393-0@bells.cs.ucl.ac.uk>; Tue, 14 May 1991 12:42:04 +0100 Received: from brunel.ac.uk by Echo.brunel.ac.uk with SMTP (PP) id <6487-0@Echo.brunel.ac.uk>; Tue, 14 May 1991 12:42:32 +0100 Received: from babbage.brunel.ac.uk by Sirius.brunel.ac.uk with SMTP (PP) id <29371-0@Sirius.brunel.ac.uk>; Tue, 14 May 1991 12:42:26 +0100 From: Andrew Findlay Message-Id: <26680.9105141142@babbage.brunel.ac.uk.brunel.ac.uk> Subject: Re: attribute proposal: To: c.robbins@uk.co.xtel (Colin Robbins) Date: Tue, 14 May 91 12:42:31 BST Cc: G.Michaelson@au.oz.uq.cc, aarn-ds@au.oz.uq.cc, osi-ds@uk.ac.ucl.cs In-Reply-To: <"10540 Tue May 14 11:01:21 1991"@xtel.co.uk>; from "Colin Robbins" at May 14, 91 10:01 am X-Mailer: ELM [version 2.2-hd PL 10] >Your proposal suggests tagging each attribute with a source, I would >argue that each value potentially need a source label. I suspect I am one of the `two people it might be' :-) I agree with Colin - every value (or attribute-value pair if you prefer to think that way) needs a source tag. Unfortunately this does not fit very well into the objectclass mechanism unless you ban *all* simple attributes. I am talking here about converting commonName from CaseIgnoreString to a type that includes *both* CaseIgnoreString *and* an origin tag (which may in itself be a structured type containing a DN, date, version, etc) There is no easy solution.... Andrew -- --------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk phone: +44 895 74000 x2512 | ---------------------------------------------------------------------   Return-Path: Received: from nrtc.northrop.com by bells.cs.ucl.ac.uk with SMTP inbound id <14785-0@bells.cs.ucl.ac.uk>; Tue, 14 May 1991 23:55:52 +0100 Received: from nma.com by nrtc.nrtc.northrop.com id aa01996; 14 May 91 15:56 PDT Received: from odin.nma.com by nma.com id aa18049; 14 May 91 14:22 PDT To: Steve Hotz cc: osi-ds@uk.ac.ucl.cs Subject: News from ANSI re ALPHA Registration Reply-to: Stef@edu.uci.ics From: Einar Stefferud Date: Tue, 14 May 91 14:18:26 MDT Message-ID: <19508.674255906@nma.com> Sender: stef@com.nma Alpha Registration is in motion! Best...\Stef ------- Forwarded Message From: epg@gateway.mitre.org To: mhsig@nrtc.northrop.com Cc: epg@gateway.mitre.org Subject: Alphanumeric Identifiers Date: Tue, 14 May 91 14:05:52 EDT Just talked with Beth Somerville at ANSI who said they just mailed out the applications for alphanumeric identifiers today. The fee is $2500 for both a numeric and an alphanumeric identifier. The procedures do not provide for registering an alphanumeric identifer without a numeric identifier. If a numeric identifier has already been obtained the additional charge for an alphanumeric identifier would be $1500. The U.S. Government has been preregistered as GOV. The U.S. CCITT Study Group D has not yet decided how to proceed with management domain registration as I understand it. Ella Gardner MITRE ------- End of Forwarded Message   Return-Path: Received: from ean-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <17509-0@bells.cs.ucl.ac.uk>; Wed, 15 May 1991 01:20:22 +0100 Received: from nsfnet-relay.ac.uk by Ean-Relay.AC.UK via Janet with NIFTP id aa00156; 15 May 91 1:57 BST Received: from brolga.cc.uq.oz.au by sun2.nsfnet-relay.ac.uk with SMTP inbound id <3460-0@sun2.nsfnet-relay.ac.uk>; Wed, 15 May 1991 00:32:16 +0100 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au id aa23919; 15 May 91 9:30 EST To: Andrew Findlay cc: Colin Robbins , G.Michaelson@au.oz.uq.cc, aarn-ds@au.oz.uq.cc, osi-ds@uk.ac.ucl.cs, ggm@au.oz.uq.cc Subject: Re: attribute proposal: In-reply-to: Your message of "Tue, 14 May 91 12:42:31 BST." <26680.9105141142@babbage.brunel.ac.uk.brunel.ac.uk> Date: Wed, 15 May 91 09:30:44 +1000 Message-ID: <23917.674263844@brolga.cc.uq.oz.au> From: George Michaelson Sender: ggm >Your proposal suggests tagging each attribute with a source, I would >argue that each value potentially need a source label. I suspect I am one of the `two people it might be' :-) Ahem... having been 1/2 accused of "not reading the docs" can I rebut with: [from my own posting] >In practice this is not possible. Instead the DIT has to tag data to identify >source, and use external procedures to coordinate which source is used, and >when changes are applied. > >The sourceTag uses OID to identify the attribute being tagged for obvious >reasons. This does present a problem since multiple valued attributes cannot >be separated into their instances. I suggest that this is a general problem >with the OID and the multiple valued attribute, and should not be addressed >by this extension but by some other mechanism such as instance-numbers. I do not think it appropriate to try and fix a more general problem with the sourceTag mechanism. I think this needs a fix buried into the model to identify uniquely instances of multi-valued attributes which I take to include multiple instances of attributes as well! thats why I say some other mechanism like instance-numbers is needed. harumph! George   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <17653-0@bells.cs.ucl.ac.uk>; Wed, 15 May 1991 01:31:49 +0100 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-2) id ; Tue, 14 May 91 17:31:51 -0700 Date: Tue, 14 May 91 17:31:45 PDT From: hotz@edu.ISI Posted-Date: Tue, 14 May 91 17:31:45 PDT Message-Id: <9105150031.AA00490@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Tue, 14 May 91 17:31:45 PDT To: osi-ds@uk.ac.ucl.cs Cc: dsar-reporters@edu.ISI Subject: Directory Services Activities 4/91 Hi. This is the directory services report for the Internet and various other US/NA activities for April 1991. Since the genesis of this report was this group's suggestion, i will also distribute it here. I will take up the issue of whether these reports should continue to be distributed via this list with Steve when he returns from his honeymoon. Please inform anyone you know who may be interested in receiving this report that they may subscribe to the distribution list by sending a message to: dsar-request@isi.edu [Note: this report appears virtually unchanged as part of the Internet Monthly Report.] Cheers, steve =================================================================== April 1991 Issue #2 Directory Services Activities ----------------------------- This report serves as a forum to distribute information about the various efforts working to develop directory services that are for, or effect, the Internet. It is published as part of the FOX Project's efforts to facilitate the coordination and cooperation of different directory services working groups. This report is distributed virtually unchanged as part of the Internet Monthly Report, and a modified version is submitted to the PARADISE International Report. We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. Current reports include: o IETF OSIDS & DISI Working Groups o Field Operational X.500 Project - ISI - Merit - PSI - SRI o National Institute of Standards and Technology o North American Directory Forum o OSI Implementor's Workshop o PARADISE Project o PSI WHITE PAGES PILOT o Registration Authority Committee (ANSI USA RAC) o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) Steve Hotz (hotz@isi.edu) DS Report Coordinator IETF OSIDS & DISI WORKING GROUPS -------------------------------- No report this month. FOX -- FIELD OPERATIONAL X.500 PROJECT -------------------------------------- The FOX project is a DARPA and NSF funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. Steve Hotz (hotz@ISI.EDU) ISI --- ISI organized the April 17 FOX phone conference, which included participants from all of the FOX contractors and several government agency representatives. The primary topics of this meeting were: (1) a discussion of the FOX project and how it relates to various other X.500 efforts, (2) status of and questions about the ongoing activities at each site, and (3) potential research issues that FOX may need to resolve to facilitate Internet X.500 deployment. Hotz produced minutes for this meeting, which were distributed to the participants. The March 1991 Directory Services Activities Report was edited and submitted to be included in the PARADISE International X.500 report. Bob Braden and Steve Hotz attended the April 11 IETF OSI-DS videoconference. Hotz supplied ISI site notes for inclusion in the meeting's minutes. Steve Hotz (hotz@ISI.EDU) MERIT ----- Merit FOX members participated in a meeting at NSF on Network Information Services, to help determine requirements for the new "NIC". Emphasis was placed on Directory Services as an important requirement to be provided, and on the incorporation of X.500 in particular. Work and discussions on the interim network infrastructure information schema and DIT drafts continued. Merit began the initial design and discussion of a scheme for representing Internet resources in X.500. Chris Weider (clw@merit.edu) Mark Knopper (mak@merit.edu) PSI --- A tool to translate from RFC-INDEX.TXT to QUIPU's EDB format was developed; the Directory has been updated accordingly. These entries are contained in the Directory under: @o=Internet@cn=RFC Documents A document relating NADF-123 and X.500 in the Internet was circulated to the FOX partners. Marshall Rose (mrose@cheetah.ca.psi.com) SRI ---- The White Pages Pilot (WPP) Project DSA offering access to SRI staff information, San Joaquin Kit Fox, was upgraded to ISODE 6.8. SRI continued work on providing access to WHOIS information via the Directory. A prototype DSA offering access to Individual, Computer, Network, Domain, Autonomous System, Organization, and Group information is running locally at SRI. Schema additions, both new objects and attributes, were made to support the WHOIS information. The prototype employs the new schema but does not yet contain distinguished name references (e.g., between individual and computer that they coordinate); these will be added in early May. Also in May, SRI will contact the WPP Manager to have this DSA added to the Pilot DMD, and apply to have the WHOIS-supporting objects and attributes added to the Cosine and Internet X.500 Schema. An early analysis of WHOIS data mapping to the Directory revealed that a significant number of entries fail postalAddress length restrictions (6 address lines, each no greater than 30 characters). 47% of the addresses listed for Individuals failed the length restrictions; a majority of the failures were due to the 30 character per address line limit. SRI will pursue a means to provide feedback to the standards community on this issue. As part of the Directory Information Services (pilot) Infrastructure Working Group (DISI), an RFC/FYI document cataloging X.500 implementations will be created. Ruth Lang, along with Russ Wright of LBL, wrote and distributed an X.500 implementation survey form to relevant Internet mailing lists. Although the date for receipt of survey forms was 5/3/91, late survey input will be accepted. Contact rlang@nisc.sri.com or wright@lbl.gov to receive a survey form. The DISI working group will review and edit input during the month of May. It is anticipated that this document will be distributed as a draft RFC/FYI in June. Ruth Lang attended the OSI-DS videoconference meeting held on April 11, and was the designated scribe for the RIACS site. Jose Garcia-Luna, Ken Harrenstien, and Ruth Lang participated in a FOX project phone conference meeting held on April 17. Ruth Lang (rlang@NISC.SRI.COM) NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY ---------------------------------------------- NIST is involved in several X.500 activities: standards, pilot deployment, and development of an X.500 implementation, Custos. The objective is to see X.500 widely deployed and used in the US government. X.500 is expected to be in the next release of the US Government OSI Profile (GOSIP). In the standards efforts, emphasis is on access control and replication; the other activities are described in some detail below. (A) NIST/GSA X.500 Pilot Deployment NIST and GSA are collaborating in the creation of a U.S. government X.500 pilot deployment. To date, two meetings have been held. At the second, held on April 25th at NIST, significant progress was made towards refining an initial draft schema developed by NIST. A number of government agency requirements will be included in the next schema revision. Once the schema is defined, agencies will begin collecting data for loading into the directory. Initially, NIST will offer to host agency data on Custos DSAs running at NIST. Eventually, agencies are expected to obtain and operate DSAs. The next meeting of the NIST/GSA pilot project is scheduled for June 18, 1991. Operational deployment is expected to begin in October 1991. (B) Custos Update The NIST X.500 public-domain implementation, Custos, is implemented on ISODE, although it otherwise bears no relation to QUIPU. One of its more interesting features is that the DBMS interface is SQL, and we provide a simple DBMS as part of Custos to support the DSA. Information can be optionally loaded into memory, and the memory usage is reasonably efficient on a per-entry basis. NIST has implemented, tested, and made a limited release of Custos, referred to as Release 0.1. It implements the read, add, compare, and list operations, along with a significant amount of "infrastructure" code that applies to all operations. The organizations that have received Release 0.1 are: SRI and Merit, which plan to incorporate Custos into the FOX effort; York University in Toronto, which plans to instrument it with OSI network management; and COS, which intends to use Custos to evaluate X.500 test systems. The conditions for getting 0.1 are that the organization make some contribution to improving the implementation, and only minimal support from NIST is provided until Release 0.2 is available. An interim release of 0.1 will be made available by May 15 which incorporates additional efficiencies in the DBMS, and modifications for DAP interoperability with OSIWARE and QUIPU. Search, access control, and schema management are currently under development. This is the additional functionality for Release 0.2, which is due out in October. The extent of the distribution for this release has not yet been determined. Richard Colella (colella@osi.ncsl.nist.gov) NORTH AMERICAN DIRECTORY FORUM ------------------------------- NADF-123 was published as an informational RFC (RFC-1218). Marshall Rose (mrose@CHEETAH.CA.PSI.COM) OSI IMPLEMENTOR'S WORKSHOP (OIW) -------------------------------- The OSI Implementor's Workshop (OIW) is an open public forum for technical issues, concerned with the timely development of implementation agreements based on emerging international OSI standards. The Workshop accepts as input the specifications of emerging standards for protocols, and produces as output agreements on the implementation and testing particulars of these protocols. This process is expected to expedite the development of OSI protocols and to promote interoperability of independently manufactured data communications equipment. The Workshop organizes its work through Special Interest Groups (SIGs) that prepare technical documentation. The SIGs are encouraged to coordinate with standards organizations and user groups, and to seek widespread technical consensus on implementation agreements through international discussions and liaison activities. The Directory SIG of the Workshop produces agreements on the implementation of Directory protocols based on ISO 9594 | CCITT X.500 Recommendations. There are three major areas that the SIG is working on for 1991: access control, replication, and distributed operations. Three subgroups have been formed, each focusing on one of these areas. The SIG plans to achieve agreements in these areas based on the Draft International Standards and the Draft Amendments by the end of 1991. At their last meeting (March, 1991), the subgroups detailed workplans and produced outlines of the agreements. At their next meeting (scheduled for June 10-14, 1991), the groups expect to start to produce actual agreements based on the output of the April 1991 ISO/CCITT Directory Editor's meeting. Youbong Weon-Yoon (youbong@arch2.att.com) PARADISE -------- The first PARADISE report (found in the March 1991 Internet Monthly) was a summary of what the project was about and who was involved. This report is a summary of what's been happening over the last three months. Subsequent reports will contain only monthly status updates. (A) Central DSA The SUN 4/330 was configured with ISODE-6.7m and was running a test DSA from 30 January. Extensive connectivity tests of IPSS, IXI, Janet and Internet were made with no significant problems. On February 18, the DSA became "Giant Tortoise" and thus held the master copy of the root of the pilot DIT (Directory Information Tree). The DSA has been running since then without major problems. It is now accepting an average of 3000 associations per week, with approximately 10,000 operations per week. Most of these are caused by either the replication protocol or by the relay service giving IXI access to the US via the Internet. The SUN is connected to the Internet via the "Fat-Pipe" and is now running SUNOS 4.0.3 and has been upgraded to ISODE 6.8. System back-up procedures are now in place, and automatic back-ups to tape are done nightly. There have been some complaints about the fat-pipe connection to the US; since a recent software upgrade there have been very few outages. There is now a backup via Germany which will kick in if necessary. (B) Central DUA Work on the interface for the central DUA service is progressing steadily and should be ready on schedule in June. This service will run on the SUN 4/470 purchased by the project. The interface is currently able to resolve most queries given to it, although more work is still needed. Additional work is also needed on formatting the output of results to the user. A test version of the interface will be made available via the central server to the PUNTERS for comments and appraisal in the near future. It is hoped that this interface will come on-line in June, with the possibility of other simple interfaces available on the central server. (C) Central Support A staff appointment has been made for the PARADISE HelpDesk based at ULCC. Phone and email contact have been available since April 29th. Telephone: +44 71 405 8400 x432 Telefax: +44 71 242 1845 Email: helpdesk@paradise.ulcc.ac.uk There will also be an info-server which it is hoped will contain a variety of PARADISE documents, including a number of "living" documents: o a list of reference implementation sites o a product file of DSAs o a product file of DUAs o the PARADISE International Report o a calendar of meetings and events relevant to PARADISE and the Internet (D) PUNTERS The national pilots involved in the project are known as the PUNTERS (Paradise UNfunded parTnERS). Representation is mostly drawn from members of RARE WG3, and is clear for all countries where national pilots exist, or at least country level nodes have been taken. In those other cases, it is unclear who the representative is, or which group will represent a future national pilot. The next PUNTERS meeting will be held back-to-back with the RARE WG3 meeting in Zurich, September 30th through October 2nd. It is hoped that demonstrations and tutorials will be offered. Internet visitors will be welcomed. During the last quarter, AUSTRIA has connected its single DSA to the pilot, and hopes to add another shortly. ITALY provided the first non-QUIPU implementation in the pilot. Systems Wizards participated in interoperability testing with UCL to demonstrate their product DirWiz. IRELAND has put up a DSA, but are having operational problems. A national pilot for FRANCE (OPAX) has been put together, and it is hoped that once testing with their product, PIZARRO, is complete, they will join the pilot. YUGOSLAVIA took delivery of QUIPU 6.7, and hopes to have something working soon. SPAIN hopes to have an operational service very shortly. The UK has moved to extend its academic pilot to the commercial world, though support will not be provided by the JNT. (E) PTT Developments PTT Telecom (Netherlands), which is subcontracted to UCL is itself subcontracting to the Swiss and Finnish PTTs to provide project liaison with the other European PTTs. The team has developed a long term action plan which includes an investigation (by means of a survey and interview) of the possible acceptance of X.500 within the European PTTs. Their study will look at whether X.500 can be used as a basis of an operational commercial public service; all conclusions will be looked at with a view towards taking positive future action. The exact relationship between X.500 and the TPH028 protocol for interconnecting public telephony directories will also be investigated, with discussion of possible future migration. Also of some importance to future strategy is the development of valid accounting mechanisms; for X.500 these are an order of magnitude bigger than those for X.400. The PTTs will be monitoring developments through ETSI. David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager PSI WHITE PAGES PILOT PROJECT ----------------------------- As of May 5th, 1991 there were 76 sites under c=US, 68 of them operating as PRDMDs. New additions this month: University of Alaska Fairbanks, Auburn University. In order to test the next DIT naming scheme, the Directory was loaded with the US organizations from the UUMAP database (over 6000 entries). These are leaf organization objects under the appropriate state. This uncovered a new optimization for the UFN algorithm, which was subsequently coded. Marshall Rose (mrose@cheetah.ca.psi.com) REGISTRATION AUTHORITY COMMITTEE (ANSI USA RAC) ----------------------------------------------- This committee (ANSI USA RAC) was formed by the ANSI ISSB (Information Systems Standards Board) "To serve as an advisory group to the Registration Coordinator with regards to technical or procedural questions and to serve as an appeals body." Members are appointed by the ISSB. It held its first meeting at ANSI offices in New York on 30 January 1991, and its second meeting at Boulder, CO on 4 April 1991. At this point, after the second meeting, the USA RAC has approved its own operating rules, and has modified and approved the previously drafted procedures for registration of Alphanumeric Form Names and Numeric Form names under the ISO DCC arc { iso member- body US(840) }, which is also known by the numeric object identifier form "1 2 840". The following unofficial text describes the ANSI organization name registration service. The American National Standards Institute (ANSI) has established an organization name registration service in line with the authority vested in ANSI as the U.S. member body of the International Standards Organization (ISO). The service has been established in response to industry concerns for creating a U.S. national registry of organizational names whose value may be an integer or alpha-numeric characters. ANSI's service provides that once registered, the owner of the registered value must determine its usage and must take the appropriate action to encourage its use. Potential usages are foreseen in the context of Open Systems Interconnection products and services. Once registered, the value is asserted to be nationally unique within the context defined in ISO standards. For example, the values may be used in various computer network systems and services to identify entities of interest to users. A fee is collected for registration of both the numeric integer and alpha-numeric value. The fees are designed to cover the costs incurred by ANSI in administering the registration authority. For further information and an application form, contact the Registration Coordinator (Beth Somerville), ANSI, 11 West 42nd Street, New York, NY 10036. Phone 212 354 3300. FAX 212-398- 0023. (NOTE: This is a new address, but the same FAX and Phone numbers.) ANSI began registration of numeric name forms in January of 1991, and intends to begin registration of alpha-numeric name forms in May of 1991. In the meantime, ISO and CCITT actions have led to voting on a proposal to move the Object Identifier Tree that is allowed to have Alpha-numeric Name Forms as well as Numeric Name Forms from the ISO arc to the Joint-ISO-CCITT arc, since both ISO and CCITT standards and recommendations require alpha-numeric names for certain identifiers, such as for X.500 and X.400. Only one among all the trees in the ISO and CCITT "forest" allows alpha-numeric values to be registered. It is expected that the vote will be affirmative, and that the current arc used by ANSI will then be moved to place it under the joint-iso-ccitt arc. This of course means a change in all object identifiers currently formed by concatenation with the ANSI registered values. Another consequence of this action is that both the ISO member-body (ANSI) and the CCITT member-body (SG-D) for the U.S. will both have some jurisdiction over registration policies and procedures. The processes of alignment and negotiation of joint control have begun with the exchange mutual recognition indications between ANSI and SG-D. Fortunately there is a large overlap in the membership of both committees. So, stay tuned! The good news is that something is happening. Unfortunately, the bad news is that something is happening. Einar Stefferud (stef@ics.uci.edu) SG-D MHS-MD ----------- On the X.400 front, the CCITT member-body for the U.S. is the Department of State, which fulfills its CCITT member-body role by chairing the U.S. CCITT National Committee, which has subordinate Study Groups (A, B, C, and D). Study Group D (SG-D) is responsible for certain telecommunications areas, including X.400 and X.500 services. In response to industry concerns about registration of ADMD and PRMD names in the U.S., SG-D formed a new subcommittee (MHS-MD) to develop rules and procedures for MHS MD name registration and use. The MHS-MD committee has met twice since it was commissioned under a charter that was developed by an ad hoc MHS-MD group for consideration and adoption by SG-D. The first official meeting was held at the U.S. Department of State on 17-18 December 1990, and the second meeting in Scottsdale, AZ, on 7-8 March 1991. The next meeting will be held on 6-7 June 1991, at the U.S. Department of State in Washington, DC. Additional meetings are set for 16-17 September 1991, and 6-7 December 1991. All meetings of the MHS-MD subcommittee are open to anyone doing business in the U.S. who has an interest in the issues before the subcommittee. All outputs from the MHS-MD subcommittee are forwarded to SG-D for consideration and adoption, and are then passed on to the U.S. CCITT National Committee for ratification. Now, why, you ask, is the U.S. Department of State involved in such arcane technical matters in the telecommunication services area? Good question! The answer is that in the U.S., where there are many telecommunication service providers, many of which provide international services with connections to service providers in other countries, someone has to be responsible for fulfillment of U.S. treaty obligations under the ITU (International Telecommunications Union) treaties. Although, we in the U.S. do not consider packet switching or X.500 or X.400 to be "basic telecommunication services" under the ITU treaties, the fact is that if any other country does make these services "basic" according to law, then the ITU treaties take effect and the U.S. Department of State must act to fulfill its treaty responsibilities under U.S. law for compliance with all applicable aspects of the ITU treaties. Under these treaties, all U.S. service providers are obligated to make arrangements such that any user in any foreign country can make a packet service connection or address X.400 mail to any user connected to a U.S. public service provider of those services, and expect the connection to be made, or the mail to be delivered, regardless of which U.S. service provider serves the addressed user. Thus, the U.S. Department of State has a vested interest in assuring that there is a sufficient U.S. service provider "backbone" to support international connections to any user on any network in the U.S. For X.400, this starts with ADMD and PRMD Name Registration and ends with rules for how the ADMDs (public service providers) will voluntarily arrange to provide a suitable backbone operation for X.400 mail services. It is expected that SG-D may have a similar interest in X.500 directory services. Thus, it is encouraged to send copies of any contribution to ANSI or SG-D to the other. Each has agreed to keep the other fully informed. The MHS-MD subcommittee is not as far along with its MD name registration procedures as the ANSI USA RAC, in part because it started work much later (ANSI procedures have been under development since 1988). Another reason is that the problem is somewhat harder for X.400 because of the "real estate" problem: The restriction of ADMD/PRMD names to 16 characters of PrintableString and the requirement that these names form a single flat space of unique names for the entire c=US. Fortunately, X.500 does not force either of these restrictions on the choice of names for organizations registered under c=US. MHS-MD is now assembling its first draft for review and progression at its meeting in June, and we expect that a final draft will be available by the December meeting of this year. Einar Stefferud (stef@ics.uci.edu)   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <24979-0@bells.cs.ucl.ac.uk>; Fri, 17 May 1991 12:23:41 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 17 May 91 12:23:40 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 3rd May. Friday 17th May. Probes performed from STC, ULCC, UCL, Brunel, Adelaide University. Bind Fail %age Best Worst Ave Address GB: Coypu (Thorn acces pt to quipu) 135 0 100.00 2.5 94.9 11.97 X121 51 0 100.00 0.9 2.4 1.24 Local Ether 51 0 100.00 1.3 5.2 1.69 Janet 53 4 92.45 1.3 10.1 2.87 Janet 102 13 87.25 0.8 107.3 12.93 Internet False Cobra (Giant Tortoise backup) 135 2 98.52 2.4 23.9 6.59 X121 51 1 98.04 1.2 2.6 1.38 Janet 102 10 90.20 0.4 49.2 7.44 Internet 51 5 90.20 2.8 33.5 7.05 IXI Passionflower Leaf Beetle (GB Domain name information) 50 3 94.00 3.7 10.1 4.65 Janet 101 9 91.09 0.5 65.5 9.12 Internet 50 6 88.00 4.7 19.6 7.97 IXI 133 21 84.21 3.8 35.6 10.46 X121 Vampire Bat (GB backup) 53 5 90.57 1.2 7.2 1.98 Janet 53 7 86.79 2.0 15.6 4.83 IXI 50 13 74.00 3.6 14.4 5.35 Janet 50 14 72.00 3.2 15.8 5.74 IXI Giant Tortoise (Root, GB Master) 51 15 70.59 1.8 15.1 5.26 IXI 51 18 64.71 2.0 17.3 3.38 Janet 135 53 60.74 2.1 14.0 5.87 X121 102 45 55.88 0.6 18.8 4.69 Internet 53 53 0.00 - - - IXI 53 53 0.00 - - - Janet Maned Sloth (Edinburgh, DSA holding NRS info) 50 50 0.00 - - - Janet 53 53 0.00 - - - Janet DE: Margay (GMD/F3, DE backup) 53 2 96.23 2.0 12.4 4.24 IXI 134 6 95.52 6.5 134.3 20.75 Int-X.25 50 4 92.00 4.3 25.6 7.69 IXI 101 19 81.19 4.7 117.7 24.07 Internet Puma (GMD/FOKUS) 53 2 96.23 2.0 11.6 3.94 IXI 133 10 92.48 4.5 20.2 7.86 Int-X.25 101 13 87.13 3.8 111.3 19.89 Internet 50 7 86.00 4.0 11.3 6.30 IXI NL: Hornero (NL Master) 134 10 92.54 5.0 152.4 14.78 X121 102 19 81.37 5.9 96.6 17.90 Internet Agouti (NL Slave) 102 8 92.16 4.6 67.8 16.13 Internet CA: Pangolin (Northern Telecom Master) 101 9 91.09 4.4 97.4 17.21 Internet Wayne Gretzky (Canada Master) 101 101 0.00 - - - Internet NO: Boa Constrictor (Norway Backup) 53 6 88.68 3.1 13.6 7.17 IXI 102 16 84.31 5.6 86.8 17.90 Internet 135 91 32.59 3.9 35.2 6.75 Int-X.25 51 51 0.00 - - - IXI Electric Eel (Norway Master) 53 8 84.91 1.8 10.3 3.98 IXI 102 16 84.31 2.7 85.2 14.13 Internet 51 11 78.43 3.4 24.9 6.99 IXI 135 91 32.59 4.4 51.5 7.69 Int-X.25 CH: Condor (ETH Zurich) 102 12 88.24 3.5 89.1 13.02 Internet 135 17 87.41 4.7 126.2 22.80 Int-X.25 Chinchilla (Swiss Master) 102 39 61.76 4.0 47.3 11.84 Internet 39 39 0.00 - - - Int-X.25 ES: Iguana (ES Master. Programa IRIS) 53 7 86.79 2.3 18.6 5.93 IXI 134 44 67.16 6.9 123.0 29.00 Int-X.25 101 40 60.40 3.8 116.7 53.37 Internet 50 35 30.00 3.7 21.2 10.85 IXI Cayman (Madrid Uni.) 51 15 70.59 4.5 81.8 15.39 IXI 53 16 69.81 2.1 24.7 6.26 IXI 135 52 61.48 7.5 178.1 36.26 Int-X.25 102 41 59.80 7.5 117.2 38.49 Internet US: Giant Anteater (Various slave) 102 15 85.29 3.8 70.1 10.46 Internet Alpaca (US master) 102 18 82.35 2.8 41.1 8.83 Internet Fruit Bat (US@l=NY master) 102 41 59.80 7.1 94.8 25.29 Internet AU: Anaconda (AU Master) 135 21 84.44 7.6 259.8 34.18 Int-X.25 102 18 82.35 1.6 64.5 9.97 Internet Bush Dog (master for AU (phony)) 102 18 82.35 0.7 54.8 9.06 Internet DK: Axolotl (DK Master) 102 27 73.53 5.9 119.5 18.94 Internet IS: Elephant Seal (IS Master) 102 30 70.59 7.3 104.6 26.63 Internet SE: Hummingbird (Sweden Master) 101 40 60.40 3.9 84.8 14.90 Internet 134 88 34.33 5.0 62.7 10.08 X121 FI Jaguar (Finland Master) 101 45 55.45 3.7 103.7 23.98 Internet 131 97 25.95 8.8 196.5 36.21 X121   Return-Path: Received: from vtvm1.cc.vt.edu by bells.cs.ucl.ac.uk with SMTP inbound id <13003-0@bells.cs.ucl.ac.uk>; Sun, 19 May 1991 02:39:30 +0100 Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 2572; Sat, 18 May 91 21:39:00 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 Beta) with BSMTP id 7272; Sat, 18 May 91 21:38:59 EDT Date: Sat, 18 May 91 21:31:35 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: attribute proposal: To: G.Michaelson@au.oz.uq.cc, aarn-ds@au.oz.uq.cc cc: osi-ds@uk.ac.ucl.cs Message-Id: <910518.213135.EDT.VALDIS@vtvm1.cc.vt.edu> In-Reply-To: Message of Tue, 14 May 91 11:16:52 EST from On Tue, 14 May 91 11:16:52 EST you said: > sourceInfo ::= CHOICE { > unknown [0] UTCTime, > localMIS [1] UTCTime, > localPABX [2] UTCTime, > thisEntity [3] SEQUENCE > { > entityName DistinguishedName > timeStamp UTCTime > } > Two questions: (a) Am I misreading this, or are 'localMIS' and 'localPABX' given a UTCTime value *only*, and 'thisEntity' has a DN attached as well? I'd *really* rather see the localMIS (at least) provide a PrintableString or DN value as well, so we can identify *which* database fed it - I think our IMS system has 50 or 100 of the beasts, and tracking the source would be nice ("Hmm.. did this bum value come out of the PAYROLL database, or out of the PERSONELL database, or...."). (I'll avoid for the moment discussing what the DN of an MVS-based IMS database is.. ;) (b) How do you handle the case of a multi-valued attribute, where different instances are put in from different sources ("Lessee... *this* phone number was downloaded from the PBX, and *this* one out of the department secretary's database, and *this* one....."). Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <28655-12@bells.cs.ucl.ac.uk>; Mon, 20 May 1991 15:36:58 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Mon, 20 May 1991 14:34:25 +0100 X400-Received: by /PRMD=iris/ADMD= /C=es/; Relayed; Mon, 20 May 1991 14:34:02 +0100 Date: Mon, 20 May 1991 15:34:02 +0200 X400-Originator: celestino.tomas@es.iris-dcp X400-MTS-Identifier: [/PRMD=iris/ADMD= /C=es/;910520153402] X400-Content-Type: P2-1984 (2) Content-Identifier: 286 From: Celestino Tomas Message-ID: <"286*/G=celestino/S=tomas/O=iris-dcp/PRMD=iris/ADMD= /C=es/"@MHS> To: osi-ds (Receipt Notification Requested) (Non Receipt Notification Requested) Cc: dspilotop2 (Receipt Notification Requested) (Non Receipt Notification Requested) Subject: DISH over VMS Here,I send some information about the implementation of a DUA over VMS, which is being developed in IRIS. Best regards, Celestino Tomas Guirao RedIRIS/FUNDESCO Alcala,61 E-28014 Madrid Spain Tel: +34 1 4351214 Fax: +34 1 5781773 ================== IRIS (RedIRIS) DISH over VMS (version 2.0) This distribution is the result of the convertion of part of the ISODE 6.0 packet to the VMS 5.3 operating system. It is a result of a colaboration project between the IRIS (RedIRIS) and Facultad de Informatica de Barcelona(Universidad Politecnica de Cataluna). It works overs VMS 5.3, using VMS/ULTIX Connection V1.2 (RFC 1006 TCP/IP) and VAX P.S.I. V 4.2 (TP0 / X.25) Authors: Rosa Maria Martin y Victor Huerta (Laboratorio de Calculo Facultad de Informatica de Barcelona) Postal address: Rosa Maria Martin LCFIB Facultad de Informatica C/ Pau Gargallo, 5 08028 Barcelona SPAIN Tel: +34 3 4016943 Fax: +34 3 4017040 e-mail: isode@fib.upc.es ORGANIZATION OF THIS DISTRIBUTION Top Directory / | \ ETC BIN LOG The main directory contains the following files: - README. - DISH.COM : Command file to use before using the interface (to define logic names, ....) - ISODE.HLB : Help library The ETC directory contains: - DSAPTAILOR - ISOALIASES - ISOBJECTS - ISODOCUMENTS - ISOENTITIES - ISOMACROS - ISOSERVICES - ISOTAILOR - OIDTABLE.AT - OIDTABLE.GEN - OIDTABLE.OC - QUIPUTAILOR The BIN directory contains: - EDITENTRY.COM: DCL file called by the interface when you have to edit an entry of the DIT. - DISH.EXE: The executable file for DISH. This release needs the installation of VMS/Ultrix Connection software in order to work properly, althought you may not use TCP/IP or X.25 connections. - DISH_X25. EXE: The executable file for DISH. This release only works over X.25 The LOG directory does not contain anything at this moment. It is used to Keep the log files of ISODE and DISH. PUBLIC AVAILABLE Version : 2.0 Transfer mode binary. FTP anonymous sun.iris-dcp.es (130.206.1.2) FTAM, user anon DN X500 c=es@o=RedIRIS@cn=filestore tsel= <0103>H Int-X25= 21452160234012 IXI= 2043145100102 ISO-CLNS= 39724F1001000000010001000113020600100200 (COSINE P4.1) Directory /isodevms File : dishVMS2.BCK.Z compress SAVE_SET file (1.6 Mbytes) File : lzdcm.exe to uncompress the file   Return-Path: Received: from gateway.mitre.org by bells.cs.ucl.ac.uk with SMTP inbound id <5505-0@bells.cs.ucl.ac.uk>; Tue, 21 May 1991 16:19:44 +0100 Received: from luna.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA18031; Tue, 21 May 91 11:18:44 -0400 Full-Name: Ella P. Gardner Return-Path: Received: by luna.mitre.org (5.54/SMI-2.2) id AA10217; Tue, 21 May 91 11:19:34 EDT Date: Tue, 21 May 91 11:19:34 EDT From: epg@org.mitre.gateway Message-Id: <9105211519.AA10217@luna.mitre.org> To: osi-ds@uk.ac.ucl.cs Subject: Directory Editing Meeting Here's a summary of the Directory editing meeting which was held in Phoenix 22 April-3 May 1991. Will someone pick this up for the Internet Monthly Report for May? Let me know if you want any additional information. Ella Gardner MITRE ---------------------------------------------------------------------- Synopsis An International Organization for Standardization (ISO)/International Telegraph and Telephone Consultative Committee (CCITT) collaborative editing meeting on the Open Systems Interconnection (OSI) Directory was held at Phoenix, Arizona from 22 April to 3 May 1991 with representatives from ten countries. National Body and Liaison Organization ballot comments on the Committee Draft (CD) and twelve Proposed Draft Amendments (PDAM) that were completed at Ottawa in October of 1990 were resolved. All thirteen revised documents will be circulated for balloting at the same level on 3 June 1991. This ballot will close on 3 September and an editing meeting to consider comments will take place in Berlin in October, 1991. Draft International Standard (DIS) output is expected from the Berlin meeting. The replication and access control models are considered stable; however, the Directory and Directory System Agent (DSA) models, abstract services, and distributed operations parts of the standard need to be aligned with the replication and access control models. The most controversial decision on replication was the choice of the Reliable Transfer Service Element (RTSE) for recovery for replication. Some members of ISO do not believe that RTSE fits the OSI model. However, the Directory Group believes that it is the only solution practical for the 1992 standard. Going into the meeting, the documents for distributed operations and schema (Directory models) needed the most work. At the previous meeting in Ottawa, U.S. participants had concentrated on the replication and access control documents. The U.S. position is that all documents must progress together, so a major effort was made this time to revise the distributed operations and schema PDAMs. The MITRE representative attended the Schema Working Group. Document Summary The CD and PDAMs being prepared for ISO balloting are listed below. The official titles are listed with the descriptive titles shown in brackets. JTC1/ REFERENCE TITLE SC21 NUMBER 5942 ISO/IEC 9594-1/2nd PDAM-1 Replication, Schema, and Access Control [Overview] 5943 ISO/IEC 9594-2/2nd PDAM-2 Schema Extensions [Directory Models] 5944 ISO/IEC 9594-2/2nd PDAM-3 Replication [DSA Models] 5945 ISO/IEC 9594-3/2nd PDAM-2 Replication, Schema, and Enhanced Search [Abstract Service] 5946 ISO/IEC 9594-4/2nd PDAM-2 Replication, Schema, and Enhanced Search [Distributed Operations] 5947 ISO/IEC 9594-5/2nd PDAM-1 Replication [Protocol Specifications] 5948 ISO/IEC 9594-6/2nd PDAM-1 Schema Extensions [Selected Attribute Types] 5949 ISO/IEC 9594-7/2nd PDAM-1 Schema Extensions [Selected Object Classes] 5951 ISO/IEC 2nd CD 9594-9 Replication 5952 ISO/IEC 9594-2 3rd PDAM-1 Access Control 5953 ISO/IEC 9594-3 3rd PDAM-1 Access Control 5954 ISO/IEC 9594-4 3rd PDAM-1 Access Control 5955 ISO/IEC 9594-8 2nd PDAM-1 Access Control   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17512-0@bells.cs.ucl.ac.uk>; Thu, 23 May 1991 11:17:49 +0100 To: Chris Weider cc: osi-ds@uk.ac.ucl.cs Subject: Re: Lack of communications.... Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 07 May 91 16:21:42 -0400. <9105072021.AA19428@mazatzal.merit.edu> Date: Thu, 23 May 91 11:17:34 +0100 Message-ID: <964.674993854@UK.AC.UCL.CS> From: Steve Hardcastle-Kille You will be pleased to be reminded that there is a full mail archive kept at UCL. Same place as all the WG documents. Steve   Return-Path: Received: from RUTGERS.edu by bells.cs.ucl.ac.uk with SMTP inbound id <7326-0@bells.cs.ucl.ac.uk>; Fri, 24 May 1991 00:16:41 +0100 Received: by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18284; Thu, 23 May 91 19:16:28 EDT To: systems-ietf-x500@edu.rutgers Path: rutgers!cs.ucl.ac.uk!S.Kille From: S.Kille@uk.ac.ucl.cs (Steve Hardcastle-Kille) Newsgroups: systems.ietf.x500 Subject: Re: Lack of communications.... Message-Id: <964.674993854@UK.AC.UCL.CS> Date: 23 May 91 10:17:34 GMT References: <9105072021.AA19428@mazatzal.merit.edu> Sender: pleasant@edu.rutgers Lines: 4 You will be pleased to be reminded that there is a full mail archive kept at UCL. Same place as all the WG documents. Steve   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17450-0@bells.cs.ucl.ac.uk>; Fri, 31 May 1991 13:28:36 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 31 May 91 13:28:34 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 17th May. Friday 31st Bind time Bind Fail %age Best Worst Ave Address GB: Coypu (Thorn acces pt to quipu) 135 0 100.00 2.5 94.9 11.97 X121 51 0 100.00 0.9 2.4 1.24 Local Ether 51 0 100.00 1.3 5.2 1.69 Janet 53 4 92.45 1.3 10.1 2.87 Janet 102 13 87.25 0.8 107.3 12.93 Internet False Cobra (Root, GB backup) 135 2 98.52 2.4 23.9 6.59 X121 51 1 98.04 1.2 2.6 1.38 Janet 102 10 90.20 0.4 49.2 7.44 Internet 51 5 90.20 2.8 33.5 7.05 IXI Passionflower Leaf Beetle (GB Domain name information) 50 3 94.00 3.7 10.1 4.65 Janet 101 9 91.09 0.5 65.5 9.12 Internet 50 6 88.00 4.7 19.6 7.97 IXI 133 21 84.21 3.8 35.6 10.46 X121 Vampire Bat (GB backup) 53 5 90.57 1.2 7.2 1.98 Janet 53 7 86.79 2.0 15.6 4.83 IXI 50 13 74.00 3.6 14.4 5.35 Janet 50 14 72.00 3.2 15.8 5.74 IXI 42 42 0.00 - - - NS Giant Tortoise (Root, GB Master) 51 15 70.59 1.8 15.1 5.26 IXI 51 18 64.71 2.0 17.3 3.38 Janet 135 53 60.74 2.1 14.0 5.87 X121 102 45 55.88 0.6 18.8 4.69 Internet 53 53 0.00 - - - IXI 53 53 0.00 - - - Janet Maned Sloth 50 50 0.00 - - - Janet 53 53 0.00 - - - Janet DE: Margay (GMD/F3, DE backup) 53 2 96.23 2.0 12.4 4.24 '0101'H/IXI 134 6 95.52 6.5 134.3 20.75 Int-X.25 50 4 92.00 4.3 25.6 7.69 IXI 101 19 81.19 4.7 117.7 24.07 Internet Puma (GMD/FOKUS) 53 2 96.23 2.0 11.6 3.94 '0101'H/IXI 133 10 92.48 4.5 20.2 7.86 Int-X.25 101 13 87.13 3.8 111.3 19.89 Internet 50 7 86.00 4.0 11.3 6.30 IXI NL: Hornero (NL Master) 134 10 92.54 5.0 152.4 14.78 '0101'H/X121 102 19 81.37 5.9 96.6 17.90 Internet Agouti (NL Slave) 102 8 92.16 4.6 67.8 16.13 Internet CA: Pangolin (Northern Telecom Master) 101 9 91.09 4.4 97.4 17.21 Internet 42 42 0.00 - - - '0101'H/NS Wayne Gretzky (Canada Master) 101 101 0.00 - - - Internet NB Beluga Whale is new Canada Master - Appears next time. NO: Boa Constrictor (Norway Backup) 53 6 88.68 3.1 13.6 7.17 '0101'H/IXI 102 16 84.31 5.6 86.8 17.90 Internet 135 91 32.59 3.9 35.2 6.75 Int-X.25 51 51 0.00 - - - IXI Electric Eel (Norway Master 53 8 84.91 1.8 10.3 3.98 '0101'H/IXI 102 16 84.31 2.7 85.2 14.13 Internet 51 11 78.43 3.4 24.9 6.99 IXI 135 91 32.59 4.4 51.5 7.69 Int-X.25 CH: Condor (ETH Zurich) 102 12 88.24 3.5 89.1 13.02 Internet 135 17 87.41 4.7 126.2 22.80 Int-X.25 Chinchilla (Swiss Master) 102 39 61.76 4.0 47.3 11.84 Internet 39 39 0.00 - - - Int-X.25 ES: Iguana 53 7 86.79 2.3 18.6 5.93 '0101'H/IXI 134 44 67.16 6.9 123.0 29.00 Int-X.25 101 40 60.40 3.8 116.7 53.37 Internet 50 35 30.00 3.7 21.2 10.85 IXI 42 42 0.00 - - - '0101'H/NS Cayman 51 15 70.59 4.5 81.8 15.39 IXI 53 16 69.81 2.1 24.7 6.26 '0101'H/IXI 135 52 61.48 7.5 178.1 36.26 Int-X.25 102 41 59.80 7.5 117.2 38.49 Internet US: Giant Anteater (Various slave) 102 15 85.29 3.8 70.1 10.46 Internet Alpaca (US master) 102 18 82.35 2.8 41.1 8.83 Internet Fruit Bat (US@l=NY master) 102 41 59.80 7.1 94.8 25.29 Internet AU: Anaconda (AU Master) 135 21 84.44 7.6 259.8 34.18 Int-X.25 102 18 82.35 1.6 64.5 9.97 Internet Bush Dog (master for AU (phony)) 102 18 82.35 0.7 54.8 9.06 Internet DK: Axolotl (DK Master) 102 27 73.53 5.9 119.5 18.94 Internet IS: Elephant Seal (Iceland Master) 102 30 70.59 7.3 104.6 26.63 Internet SE: Hummingbird (Sweden Master) 101 40 60.40 3.9 84.8 14.90 Internet 134 88 34.33 5.0 62.7 10.08 '0101'H/X121 FI: Jaguar (Finland Master) 101 45 55.45 3.7 103.7 23.98 Internet 131 97 25.95 8.8 196.5 36.21 '0101'H/X121 16 16 0.00 - - - '0101'H/NS 26 26 0.00 - - - '0101'H/NS   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <17410-0@bells.cs.ucl.ac.uk>; Mon, 10 Jun 1991 15:11:36 +0100 Received: Mon, 10 Jun 91 10:11:29 EDT by mazatzal.merit.edu (5.51/1.6) Date: Mon, 10 Jun 91 10:11:29 EDT From: Chris Weider Message-Id: <9106101411.AA22932@mazatzal.merit.edu> To: fox500@edu.merit, jkrey@edu.ISI, osi-ds@uk.ac.ucl.cs Subject: Internet-Draft for NIC Profiles Here's the first of many Internet Drafts.... IETF OSI-DS Working Group Chris Weider INTERNET--DRAFT Mark Knopper Merit Network June 1991 Schema for NIC Profile information in X.500 Status of this memo: The authors wish to put put up a readily accessible, distributed Directory of Network Information Centers, or NICs. This paper discusses the schema used to hold the NIC Profiles, as well as the DIT structure necessary for this information. This draft document will be submitted to the RFC as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors. INTERNET--DRAFT NIC Profile Schema June 1991 SECTION 1: PRELIMINARIES 1.1 Introduction The authors of this document, in conjuction with the chairs of the IETF Network Information Services Infrastructure (NISI) group, would like to implement a Directory of Network Information Centers, or NICs. This will enable NICs to find each other easily, will allow users with access to a DSA to find out where NICs are, and will in general facilitate the distribution of information about the Internet and some of its infrastructure. This RFC proposes a set of standard schema for this information. 1.2 Information to be incorporated The profile for each NIC contains the following information: the name of the NIC, the name of the parent organization, the e-mail address of the NIC, the postal address of the NIC, the hours of operation, a contact person, services offered, publications offered, and the networks which the NIC serves. SECTION 2: NEW ATTRIBUTES AND OBJECT CLASSES 2.1 New attributes As many of the attributes required here are already defined, let's just list the new attributes: parentOrganizationName: Name of the parent organization; servicesOffered: services offered by a particular NIC; publicationsOffered: publications offered by a particular NIC; associatedNetworks: a network associated with a perticular NIC. The ASN.1 definitions follow. _____________________________________________________________________________ parentOrganizationName ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-parentorg)) ub-parentorg INTEGER ::= 128 servicesOffered ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-servicesoff)) ub-servicesoff INTEGER ::= 128 publicationsOffered ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-puboffered)) ub-puboffered INTEGER ::= 128 INTERNET--DRAFT NIC Profile Schema June 1991 associatedNetworks ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-assocnets)) ub-assocnets INTEGER ::= 64 ASN.1 definitions for new attributes _____________________________________________________________________________ 2.2 New object class. The new object class associated with this information is detailed in ASN.1 below. ____________________________________________________________________________ nicProfile OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName } MAY CONTAIN { parentOrganizationName, rfc822Mailbox, postalAddress, roomNumber, streetAddress, postOfficeBox, stateOrProvinceName, telephoneNumber, facsimileTelephoneNumber, hoursOfService, contactName, servicesOffered, publicationsOffered, associatedNetworks } ASN.1 definition for new object class __________________________________________________________________________ SECTION 3: DIT STRUCTURE 3.1 DIT structure changes This information will reside in a subtree of the o=Internet branch, in the ou=NIC Profiles subtree. A sample RDN for an entry would be @o=Internet@ou=NIC Profiles@cn=NSF Network Service Center. SECTION 4: AUTHOR INFORMATION 4.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu 1075 Beal Avenue Ann Arbor, MI 48109   Return-Path: Received: from mazatzal.merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <19549-0@bells.cs.ucl.ac.uk>; Mon, 10 Jun 1991 15:32:00 +0100 Received: Mon, 10 Jun 91 10:31:55 EDT by mazatzal.merit.edu (5.51/1.6) Date: Mon, 10 Jun 91 10:31:55 EDT From: Chris Weider Message-Id: <9106101431.AA22956@mazatzal.merit.edu> To: fox500@edu.ISI, jkrey@edu.ISI, osi-ds@uk.ac.ucl.cs Subject: DIFFERENT!!! Int-Draft for Online Info Resources Schema Here's the next one.... IETF OSI-DS Working Group Chris Weider INTERNET-DRAFT Merit Network May 1991 Schema for Information Resource Description in X.500 Status of this memo: The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors. INTERNET--DRAFT Information Resource Schema May 1991 SECTION 1: PRELIMINARIES 1.1 Introduction As one of the beginning steps to the Internet Yellow Pages, the authors have taken advantage of a need to place Information Resource descriptions online in a distributed fashion. The schema proposed here holds the information desired by the US-MARC committee and the Coalition for Networked Information (CNI). A companion paper will discuss the DIT structure needed for this information. This RFC proposes a standard schema for this information. 1.2 Information to be incorporated The Information Resource data to be incorporated includes a subset of the US-MARC attributes that will be kept for Online Information Resources. The Data Elements are listed below with the appropriate US-MARC fields. The mapping between the Data Elements and the X.500 attributes of the schema will be done in section 2. _______________________________________________________________________________ Data Element US-MARC Field Name of the Resource 245$a Title Statement Acronym/Initialism 211$a Acronym or Shortened Title Producer 537$a Source of Data Note (Responsibility for Data) Distributor of the Resource 260$b Name of distributor Location 260$a Place of distribution Contact Name and Address Network Access Network Address 265$a Acquisition/Subscription Address Hours of Service Telephone Fax Network Access Instructions Terminal Emulation Supported 538$a Technical Details Note Logon/Subscription Instructions Logoff/unsubscribe Instructions Type of the Resource 516$a Type of File or Data Note Size of Resource 256$a File Characteristics Frequency of Update 310$a Current Frequency Language of Resource 546$a Language Note Profile of Resource 520$a Summary, Abstract, etc. Note Audience 521$a Target Audience Note Restrictions on Access 506$a Restrictions on Access Note Authorization 540$c$d Terms governing Use Note Source Machine 538$a Technical Details Note Cost for Use Coverage 513$a$b Type and Period Note Indexing Terms 653$a Index Term Databases Available 505$a Contents Note Other Providers of Database 582$a Related Computer File Note Documentation Available 556$a Information about Documentation Note INTERNET--DRAFT Information Resource Schema May 1991 US-MARC mapping table (cont) Data Element US-MARC field Responsibility for Record 040$a$d Cataloging Source Maintenance Date/Time of Last Update of 005 Date and Time of Latest Transaction Directory Information Local Access Information and 590 Local Notes Guidelines ______________________________________________________________________________ SECTION 2: SCHEMA DESIGN 2.2 New attributes for this information New attributes used for this information are producerOfResource; a string containing the name of the producer of the resource. distributorOfResource; a string containing the name of the distributor of the resource. hoursOfService; a string listing the hours of service for the resource. networkAccess; a string describing network accessibility. networkAddress; a string containing the address of the resource. (proposed instead of emailAddress because this is a different concept) terminalEmulationSupported; a string listing which terminal emulation is available on this resource. logonInstructions; a string explaining how to logon or subscribe to the resource. logoffInstructions; a string explaining how to logoff or unsubscribe the resource. typeOfResource; a string explaining what type of resource this is. sizeOfResource; a string containing the size of the resource. frequencyOfUpdate; a string containing the frequency of update. languageOfResource; a string containing the Language of the Resource profileOfResource; a string with a brief profile of the resource. targetAudience; a string with the target audience. restrictionsOnAccess; a string with the restrictions to access. authorizationPolicy; a string with the authoriztion policy. INTERNET--DRAFT Information Resource Schema May 1991 sourceMachine; a string with the make of the source machine. costOfUse; the cost of usage. extentOfCoverage; which times and periods this resource covers. indexingTerms; terms by which this resource is indexed. databasesAvailable; which databases are in this resource. alternateProviders; which other organizations provide this info. accessToDocumentation; how to get the documentation. maintananceAuthority; who has the responsibility for maintaining this resource. lastUpdateOfData; last time the data was updated. localAccessInformation; information about local access and guidelines. networkAccessInstructions; a string describing how to access the resource. Many of these new schema should be common to a wide range of types of resources and should be generic enough for reuse. The ASN.1 definitions of the new attributes follows. __ __ __ __ __ __ __ __ __ __ producerOfResource ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-producer)) ub-producer INTEGER ::= 160 distributorOfResource ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-distributor)) ub-distributor INTEGER ::= 160 networkAccess ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-netaccess)) ub-netaccess INTEGER ::= 80 networkAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-netaddress)) ub-netaddress INTEGER ::= 128 INTERNET--DRAFT Information Resource Schema May 1991 terminalEmulationSupported ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (size (1 .. ub-terminal)) ub-terminal INTEGER ::= 30 logonOrSubscriptionInstructions ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-logoninstructions)) ub-logoninstructions INTEGER ::= 1024 logoffOrUnsubscribeInstructions ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-logoffinstructions)) ub-logoffinstructions INTEGER ::= 1024 typeOfResource ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-resourcetype)) ub-resourcetype INTEGER ::= 1024 sizeOfResource ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-resourcesize)) ub-resourcesize INTEGER ::= 64 frequencyOfUpdate ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-frequency)) ub-frequency INTEGER ::= 64 languageOfResource ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-language)) ub-language INTEGER ::= 64 profileOfResource ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-resourceprofile)) ub-resourceprofile INTEGER ::= 1024 INTERNET--DRAFT Information Resource Schema May 1991 targetAudience ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-targetaudience)) ub-targetaudience INTEGER ::= 128 restrictionsOnAccess ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-accessrestrictions)) ub-accessrestrictions INTEGER ::= 512 authorizationPolicy ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-authorization)) ub-authorization INTEGER ::= 1024 sourceMachine ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-sourcemachine)) ub-sourcemachine INTEGER ::= 128 costOfUse ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-costofuse)) ub-costofuse INTEGER ::= 128 extentOfCoverage ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-coverage)) ub-coverage INTEGER ::= 256 indexingTerms ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-indexing)) ub-indexing INTEGER ::=64 databasesAvailable ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-databases)) INTERNET--DRAFT Information Resource Schema May 1991 ub-databases INTEGER ::= 256 alternateProviders ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-alternateproviders)) ub-alternateproviders INTEGER ::= 256 accessToDocumentation ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-documentaccess)) ub-documentaccess INTEGER ::= 1024 maintenanceAuthority ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-maintenanceauthority)) ub-maintenanceauthority INTEGER ::= 1024 lastUpdateOfData ATTRIBUTE WITH ATTRIBUTE SYNTAX UTCTime (SIZE (1 .. ub-lastupdate)) ub-lastupdate INTEGER ::= 128 localAccessInformation ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-localaccess)) ub-localaccess INTEGER ::= 1024 contactName ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-contactname)) ub-contactname INTEGER ::= 128 hoursOfService ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-hoursofservice)) ub-hoursofservice INTEGER ::= 128 networkAccessInstructions ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-netaccins)) ub-netaccins INTEGER ::= 1024 ASN.1 definitions for new attributes _______________________________________________________________________________ INTERNET--DRAFT Information Resource Schema May 1991 2.2 New object class There is just one new object class; onlineInformationResource. This holds all the information mentioned above. The ASN.1 definition: -- -- -- -- -- -- -- -- -- -- onlineInformationResource OBJECT-CLASS SUBCLASS of pilotObject MUST CONTAIN { commonName } MAY CONTAIN { producerOfResource, distributorOfResource, contactName, postalAddress, roomNumber, streetAddress, postOfficeBox, stateOrProvinceName, networkAccess, networkAddress, hoursOfService, telephoneNumber, facsimileTelephoneNumber, networkAccess, networkAddress, terminalEmulationSupported, logonOrSubscriptionInstructions, logoffOrUnsubscribeInstructions, typeOfResource, sizeOfResource, frequencyOfUpdate, languageOfResource, profileOfResource, targetAudience, restrictionsOnAccess, authorizationPolicy, sourceMachine, costOfUse, extentOfCoverage, indexingTerms, databasesAvailable, alternateProviders, accessToDocumentation, maintenanceAuthority, lastUpdateOfData, localAccessInformation, networkAccessInstructions } ASN.1 definition for the new object class _______________________________________________________________________________ SECTION 3: WHO WE ARE 3.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <8676-0@bells.cs.ucl.ac.uk>; Tue, 11 Jun 1991 09:31:12 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Tue, 11 Jun 1991 09:29:48 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 11 Jun 1991 09:22:52 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Tue, 11 Jun 1991 11:23:00 +0100 Date: Tue, 11 Jun 1991 08:22:52 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.558:11.05.91.08.22.52] X400-Content-Type: P2-1984 (2) Content-Identifier: Preliminary p... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"4559 Tue Jun 11 10:22:59 1991"@surver.surfnet.nl> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: Preliminary program RARE WG3 demo/tutorial meeting X-VMS-To: OSI-DS, WG3 Sender: HUIZER@nl.surfnet Good Morning, Sorry to send this out to the whole OSI-DS list as well, but so many people on this list expressed interest, that this is easiest for me to reach them. I hope some of you out there on the wrong (:-)) side of the ocean will be able to squeeze some funding from somewhere to join us in Zurich. You're welcome. Any contributions to the demo-session or suggestions for the second talk are welcome. (Chris? Mark? Steve? Ruth? anyone from PSI?) I might (no promises) be able to get travel funding for 1 person from the US for this second talk in the program. Applications to me. Detailed questions you can ask me in Atlanta, or before via E-mail. Hotel information will be send out by Thomas Lenggenhager in a short while. He has made block bookings in two hotels which remain valid until july or something. The travel funding for all regular WG3 members is OK, so those people can start booking. Erik ___________________________________________________________________________ Program RARE WG3 meeting 30 sept.-2 oct. 1991 Zurich, Switzerland Zurich, Switch/ETHZ 30 september 1300 DS session, including P2.1 operational meeting 1800 closing 1 october Big room Terminal room Lecture room with video no facilities ------------------------------------------------------ 0900 Paul Barker (UCL/Paradise) Paradise Central DUA 0945 Someone from the US(?) Mac DUA or FOX/WPP status 1030 break 1100 Andrew Findlay (Brunell) Brunell (X)DUA 1145 Graham Knight (Level-7 Ltd) P2.2 Prototype 1300 Lunch PARALLEL SESSIONS: 1400 Tim Berners-Lee (CERN) Colin Robbins (Xtel) Hypertext Tutorial DSA 1500 Steve Benford (Nottingham Univ.) continued Group Communications 1600 Plenary 1700 Drinks Various demo's The various demos would consist of: ETHZ ITAXA DUA for Mac Steve benford Group Communication PSI (?) Mac DUA Tim Howes (?) Mac DUA Brunel DUA's Paul Barker DUA Level-7 P2.2 Celestino Tomas VMS DUA X-tel DUAs Tim Berners-Lee Hypertext next Maria Dimou CERN Directory Joyce Reynolds (?) 2 october 0900 USIS part (maybe parallel some DS demo evaluations) 1600 P2.2 whatever 1800 end of meeting ___________________________________________________________________________   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <9697-0@bells.cs.ucl.ac.uk>; Tue, 11 Jun 1991 10:08:48 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Tue, 11 Jun 1991 10:08:38 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Tue, 11 Jun 1991 11:07:55 +0100 Date: Tue, 11 Jun 1991 09:08:38 +0000 X400-Originator: ansen@ch.switch.clients X400-MTS-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;910611110755] X400-Content-Type: P2-1984 (2) Content-Identifier: 117 From: "Erik.Huizer" Original-Sender: Debra Ansen Message-ID: <117*/S=ansen/OU=clients/O=switch/PRMD=switch/ADMD=arcom/C=CH/@MHS> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: Preliminary program RARE WG3 demo/tutorial meeting Autoforwarded: TRUE X-VMS-To: OSI-DS, WG3 Sender: ansen@ch.switch.clients   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <20338-0@bells.cs.ucl.ac.uk>; Wed, 12 Jun 1991 17:56:31 +0100 Return-Path: Received: from mazatzal.merit.edu by merit.edu (5.65/1123-1.0) id AA06458; Wed, 12 Jun 91 12:56:37 -0400 Received: by mazatzal.merit.edu (5.65/client-0.9) id AA00281; Wed, 12 Jun 91 12:56:07 -0400 Date: Wed, 12 Jun 91 12:56:07 -0400 From: clw@edu.merit Message-Id: <9106121656.AA00281@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: Database constraints in X.500 From clw@merit.edu Wed Jun 12 12:48:59 1991 Received: from venera.isi.edu by merit.edu (5.65/1123-1.0) id AA06338; Wed, 12 Jun 91 12:48:54 -0400 Received: from merit.edu by venera.isi.edu (5.61/5.61+local-2) id ; Wed, 12 Jun 91 09:48:47 -0700 Return-Path: Received: from mazatzal.merit.edu by merit.edu (5.65/1123-1.0) id AA06334; Wed, 12 Jun 91 12:48:39 -0400 Received: by mazatzal.merit.edu (5.65/client-0.9) id AA00275; Wed, 12 Jun 91 12:48:10 -0400 Date: Wed, 12 Jun 91 12:48:10 -0400 From: clw@merit.edu Message-Id: <9106121648.AA00275@mazatzal.merit.edu> To: fox500@ISI.EDU Subject: Database constraints in X.500 Cc: tim@terminator.cc.umich.edu Gang: Here's a explication of the remarks I made on the phone conference about the problem of 'repeated groups'. The example is as follows: Suppose I have a schema for a 'mainframe' object which contains the following information: 1) the name of the mainframe 2) the name, address, and phone number of the technical contact. Now, the attribute in which to put the name of the mainframe is obvious. The problem arises in attempting to encapsulate the contact person information: If we have just one contact name, the solution is obvious. If we have more than one contact name, the problem becomes quite trickier. It seems to me that we can 1) just list 'name, address, phone number, name, address, phonenumber' so that the EDB would look like: cn=Mighty Mainframe contactName=Fred Smith postalAddress=One Fred Street $ Fredville, MA 00000 telephoneNumber= 1-800-882-FRED contactName=Joe Jones postalAddress=10 Backward Lane $ Joeburg, MA 99999 telephoneNumber= 1-800-882-1JOE In this case, the Quipu software will print out something like cn=Mighty Mainframe contactName=Fred Smith contactName= Joe Jones postalAddress=One Fred Street $ Fredville, MA 00000 postalAddress=10 Backward Lane $ Joeburg, MA 99999 telephoneNumber= 1-800-882-FRED telephoneNumber=1-800-882-1JOE destroying the 'semantic linkage' between the items. This is obviously unacceptable. Even if quipu (or whatever) didn't do this and printed out the EDB in correct order, there's no way to tell the schema that each contactName must have an associated telephoneNumber. (for example) 2) We could define attributes 'contactName1' ... 'contactName10', 'telephoneNumber1' ... 'telephoneNumber10', etc. and thus be able to keep the semantic linkage even if the DUA garbles the order of the attributes. The problem with this solution is that it doesn't scale at all. Yuck. 3) We could build an attribute and a new syntax that allows us to put all the information concerning one contact person into one item, e.g. contactInfo ATTRIBUTE WITH ATTRIBUTE SYNTAX infoOnContact where infoOnContact is a set of lines separated by '$', a' la the postalAddress attribute, and a syntax handler which would split this up. The problem with this solution is that 1) searches become much more difficult because one is not able to specify search information in an 'intuitive' manner and because the infoOnContact string could be quite long, 2) For each group of attributes which one wanted to link together one would have to write a new syntax handler, and 3) converting information to be loaded into X.500 from some other source would become progressively more difficult. 4) We can put in a 'contact' attribute which contains an RDN, and would solve most of these problems. We would then have a separate part of the directory which would contain entries for all those contacts who do not have entries already in the DIT. This works very well for people at the present time. However, !This does not scale well when the group of attributes which need to be linked together does not have a natually associated schema!. As a second example, let's say that in the above example that we needed a contact name, address, telephone number, and a part of the mainframe that this contact was an expert on (Operating System, DASD devices, etc). Now, in this case, we can link the 'expertOn' attribute to the contact in any of the above three ways, or we can expand the pilotPerson schema to include an 'expertOn' attribute. I would argue that as more people need to put in more information associated with a given person in various contacts, expanding the pilotPerson schema will become more and more cumbersome. The other problem with this solution is that as we have more and more groups that need to be linked together, we will have to build more and more object classes that really have no other intrinsic value. All of the above solutions are bad. I would argue that we need to do two things here... We need to find some immediate solution to this which doesn't look good (i.e. a short term kludge), and we need to find a way to change the standard (sorry expand the standard) to include this. In addition, as we start expanding the structure of the Directory, we will need to look at strategies for updating information. A centralized database simplifies this process by attempting to keep the information in what is called 'normal form'. The reference I have for this is "Fundamentals of Data Normalization" by Dutka and Hanson from Addison Wesley. The following concepts are (IMO) inapplicable to X.500, but it provides some clues to how a centralized database works around potential update problems. A relation is in 'first normal form' if it contains no repeating groups. For instance, in the above example, the Directory would be in 'FNF' if we used solution 4 to get around the contact problem. As shown above, this causes some problems in our design. The benefit of a relation being in 'FNF' is that we only have to update the information in one spot. Each of the stricter normal forms (Second normal form, etc). depends on the data already being in first normal form. As noted above, this will be hard to do, so I think that a good research project for FOX is to see if we can get some sort of mathematical structure out of what we are doing, and see if we cna optimize the updating procedure. (The other obvious question is "Should we be doing anything here at all???) I think that it will be important as the Direcotry goes into operational status that we look at some of these issues, and see what we can come up with. For various reasons, we will not be able be able to build an 'optimized' data- base from the X.500 directory as it stands now. The power of X.500 comes from the fact that the information is not in normal form and is a heirarchical system. Well, enough blathering. I would be intensely interested in any responses, and would like to know if anyone has hear of anybody working on these issues. Chris   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <14573-0@bells.cs.ucl.ac.uk>; Thu, 13 Jun 1991 12:26:36 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Thu, 13 Jun 1991 12:26:11 +0100 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Thu, 13 Jun 1991 12:22:01 +0100 Date: Thu, 13 Jun 1991 13:22:01 +0200 X400-Originator: Lenggenhager@ch.switch.gate X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910613132201] X400-Content-Type: P2-1984 (2) Content-Identifier: 5599 From: Thomas Lenggenhager Message-ID: <5599*/S=Lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: RARE WG3 in Zurich (30.9.-2.10): Hotel Information Hello, here the already announced followup to the preliminary program for the RARE WG3 demo/tutorial meeting. We were able to place block reservations in two hotels nearby the meeting room. These reservations are open until end of July. Please say explicetly that you want one of these reservations made under the name 'SWITCH'. For some of you coming from further away, it couldbe probably of interest that in the week after that meeting the Telecom 91 takes place in Geneva. In case you want to spend the few days inbetween somewhere in Switzerland, you could contact one of the following tourist information offices: Tourist Information for Zurich Tel: 41 1 211 40 00 Bahnhofplatz 15 Fax: 41 1 212 01 41 CH-8001 Zurich Swiss Tourist Information Tel: 41 1 288 11 11 Postfach Fax: 41 1 288 12 05 CH-8027 Zurich Shortly before the meeting I will send around the information on how to get from the airport into the city and to the meeting room. (It takes only about 30 to 45 minutes to get from the airport to the meeting room.) Thomas Lenggenhager SWITCH =============================================================================== Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerland INET: lenggenhager@switch.ch | Tel: +41-1-261 8178 | Fax: +41-1-261 8133 X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH =========== (All prices are given in Swiss Francs) *** Hotel Rex (Garni) Tel: 41 1 361 96 46 Weinbergstrasse 92 Fax: 41 1 361 20 47 CH-8006 Zurich Price: 140.00 (5 rooms have twin beds, 5 rooms have "normal beds), bath or shower, taxes, breakfast, service included) 10 Rooms have been booked until July 29, 1991 at the latest. After that day, there will not be any contingent booked for the meeting participants. Please ask for a room booked on behalf of SWITCH. 5 minutes to the meeting room, new, rather large rooms, phone, colour TV *** Hotel Ruetli Tel: 41 1 251 54 26 Zaehringerstrasse 43 Fax: 41 1 261 21 53 CH-8001 Zurich Price: 130.00 (bath or shower, WC, breakfast, taxes, service included). 12 rooms have been booked until July 31, 1991 at the latest. After that day, there will not be any contingent booked for the meeting participants. Please ask for a room booked on behalf of SWITCH. 4 minutes to the meeting room, new rooms, phone, colour TV Other possible hotels: ** Hotel Sunnehus Tel: 41 1 251 65 80 Sonneggstrasse 17 CH-8006 Zurich Price appr. 120 - 140 3 minutes to the meeting room *** Hotel Astor Tel: 41 1 251 35 60 Weinbergstrasse 44 Fax: 41 1 251 49 15 CH-8006 Zurich Price: appr. 150 - 160 rather small rooms one minute to the meeting room *** Hotel Arc Royal Comfort Inn Tel: 41 1 261 67 10 Leonhardstrasse 6 Fax: 41 1 251 47 80 CH-8001 Zurich Price appr. 110 - 140 2 minutes to the meeting room **** Hotel Helmhaus Tel: 41 1 251 88 10 Schifflaendeplatz 30 Fax: 41 1 251 04 30 CH-8001 Zurich Price appr. 140 5 min. ride by tram the hotel is located in the "old" part of the city. ==========   Return-Path: Received: from gateway.bnr.ca by bells.cs.ucl.ac.uk with SMTP inbound id <18197-0@bells.cs.ucl.ac.uk>; Thu, 13 Jun 1991 14:25:45 +0100 Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA28337; Thu, 13 Jun 91 09:25:52 -0400 Message-Id: <9106131325.AA28337@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 0858; Thu, 13 Jun 91 09:25:14 EDT Date: 13 Jun 91 09:22:00 EDT To: osi-ds@uk.ac.ucl.cs From: Peter (P.W.) Whittaker Subject: fw:Database constraints in X.500 Sender: Peter (P.W.) Whittaker Chris writes: > All of the above solutions are bad. I would argue that we need to do two > things here... We need to find some immediate solution to this which doesn't > look good (i.e. a short term kludge), and we need to find a way to change the > standard (sorry expand the standard) to include this. > > In addition, as we start expanding the structure of the Directory, we will > need to look at strategies for updating information. A centralized database > simplifies this process by attempting to keep the information in what is > called 'normal form'. The reference I have for this is "Fundamentals of > Data Normalization" by Dutka and Hanson from Addison Wesley. As a short term solution that requires no extensions or hacking, why not use the groupOfNames attribute type to refer to the list of persons with relevant mainframe (or whatever) experience? The DNs in the groupOfNames would refer to pilotPerson entries containing phoneNumbers, userids, rfcmailboxes, and descriptions. Part of the description could be "expert on VTAM, SNA, PVM" or some other MF speciality. Either that or create a new object class (subsystemGuru?), a subclass of pilotPerson (so that it has all pilotPerson attributes), with mandatory attribute susbsystemExpertise. The groupOfNames attribute could be used to refer to these entries instead. Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ DSA's'R'Us! ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25735-0@bells.cs.ucl.ac.uk>; Fri, 14 Jun 1991 11:25:27 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 14 Jun 91 11:25:25 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 31st May - Friday 14th June Bind Fail %age Best Worst Ave Address GB: Coypu (Thorn acces pt to quipu) 54 0 100.00 1.0 1.0 1.74 Local Ether 109 6 94.50 21.2 2.4 5.44 X121 118 13 88.98 9.5 1.2 6.84 Internet 205 33 83.90 1.0 0.1 0.40 dsa_available 160 32 80.00 4.4 2.5 9.57 Janet Vampire Bat (GB backup) 40 0 100.00 0.5 0.5 0.61 Private TCP 130 34 73.85 5.9 1.3 6.12 Janet 131 35 73.28 1.0 0.1 0.37 dsa_available 123 70 43.09 8.0 0.0 7.19 IXI False Cobra (Root, GB backup) 92 6 93.48 4.2 0.0 3.55 X121 117 11 90.60 5.2 0.9 4.03 Internet 180 23 87.22 1.0 0.0 0.41 dsa_available 153 25 83.66 3.4 1.9 3.88 Janet 146 73 50.00 4.9 0.0 6.04 IXI Giant Tortoise (Root, GB Master) 92 9 90.22 5.0 2.1 3.48 X121 117 27 76.92 3.9 0.3 2.49 Internet 152 37 75.66 4.3 1.8 3.95 Janet 179 45 74.86 1.0 0.1 0.41 dsa_available 145 62 57.24 5.3 0.0 4.79 IXI Passionflower Leaf Beetle (GB Domain name information) 134 52 61.19 9.4 0.0 8.62 Janet 159 62 61.01 1.0 0.0 0.33 dsa_available 115 50 56.52 10.0 0.0 4.64 Internet 93 41 55.91 16.9 0.0 4.17 X121 127 98 22.83 6.8 0.0 5.87 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 133 133 0.00 - - - Janet 133 133 0.00 - - - dsa_available DE: Puma (GMD/FOKUS) 92 3 96.74 7.2 6.7 13.83 Int-X.25 145 10 93.10 1.0 0.1 0.30 dsa_available 92 12 86.96 4.9 0.0 7.42 Internet 20 7 65.00 12.1 105.1 53.92 Internet 123 46 62.60 8.0 0.0 8.36 IXI Margay (GMD/F3, DE backup) 93 14 84.95 11.0 6.1 11.90 Int-X.25 115 24 79.13 17.5 4.0 21.16 Internet 150 32 78.67 1.0 0.1 0.30 dsa_available 126 71 43.65 8.9 0.0 4.88 IXI AU: Bush Dog (master for AU (phony)) 118 5 95.76 0.1 0.1 0.10 dsa_available 118 5 95.76 5.9 0.7 15.36 Internet Anaconda (AU Master) 123 18 85.37 5.4 1.2 6.67 Internet 169 56 66.86 0.1 0.0 0.10 dsa_available 139 52 62.59 26.0 0.0 37.11 Int-X.25 SE: Hummingbird (Sweden Master) 115 8 93.04 0.1 0.0 0.10 dsa_available 114 8 92.98 8.9 3.8 12.47 Internet 92 76 17.39 6.8 0.0 2.02 '0101'H/X121 US: Giant Anteater (Various slave) 118 14 88.14 0.1 0.1 0.10 dsa_available 118 14 88.14 6.0 4.2 6.75 Internet Alpaca (US master) 124 34 72.58 0.1 0.1 0.10 dsa_available 124 34 72.58 6.4 3.7 7.68 Internet Fruit Bat (US@l=NY master) 118 29 75.42 0.1 0.1 0.10 dsa_available 118 29 75.42 8.1 5.0 18.05 Internet NO: Electric Eel (Norway Master) 116 14 87.93 5.1 4.6 8.60 Internet 185 46 75.14 1.0 0.0 0.34 dsa_available 109 28 74.31 6.1 0.0 6.64 Int-X.25 144 64 55.56 5.2 0.0 6.51 IXI Boa Constrictor (Norway Backup) 119 15 87.39 11.5 5.7 13.85 Internet 224 68 69.64 1.0 0.0 0.33 dsa_available 153 65 57.52 9.3 0.0 12.67 IXI 136 69 49.26 16.7 0.0 7.79 Int-X.25 CH: Chinchilla (Swiss Master) 118 16 86.44 6.9 3.2 14.16 Internet 119 17 85.71 0.1 0.0 0.10 dsa_available 1 1 0.00 - - - Int-X.25 Condor (ETH Zurich) 119 18 84.87 5.8 2.6 8.41 Internet 137 29 78.83 0.1 0.0 0.10 dsa_available 110 24 78.18 21.0 0.0 13.41 Int-X.25 DK: Axolotl (DK Master) 123 17 86.18 0.1 0.1 0.10 dsa_available 123 17 86.18 9.1 4.1 40.24 Internet CA: Beluga Whale (Canada Master) 55 9 83.64 0.1 0.1 0.10 dsa_available 55 9 83.64 3.7 3.6 22.04 Internet Pangolin (Northern Telecom Master) 115 78 32.17 0.1 0.1 0.10 dsa_available 115 78 32.17 9.2 5.1 13.62 Internet Wayne Gretzky (Old Canada Master) 110 107 2.73 0.1 0.0 0.02 dsa_available 110 107 2.73 3.9 0.0 3.71 Internet IL: Dorcan Gazelle (Israel Master) 52 12 76.92 0.1 0.1 0.10 dsa_available 52 12 76.92 10.9 8.5 27.75 Internet IS: Elephant Seal (Iceland Master) 118 29 75.42 0.1 0.1 0.10 dsa_available 118 29 75.42 11.7 7.9 22.42 Internet FI: Jaguar (Finland Master) 117 31 73.50 0.1 0.0 0.10 dsa_available 116 31 73.28 9.9 3.1 13.78 Internet 92 64 30.43 3.7 0.0 2.48 '0101'H/X121 ES: Iguana (ES Master. Programa IRIS) 92 33 64.13 94.0 8.1 22.36 Int-X.25 113 48 57.52 12.1 3.8 18.89 Internet 169 75 55.62 1.0 0.1 0.39 dsa_available 145 112 22.76 25.9 0.0 23.10 IXI 1 1 0.00 - - - IXI AT: Piranah (AT Master) 114 42 63.16 0.1 0.0 0.07 dsa_available 112 49 56.25 8.1 0.0 8.49 Internet 93 42 54.84 12.8 0.0 16.31 Int-X.25 NL: Hornero (NL Master) 113 45 60.18 0.1 0.1 0.10 dsa_available 112 51 54.46 9.4 2.3 11.94 Internet 92 42 54.35 19.4 4.5 10.55 '0101'H/X121 Agouti (NL Slave) 126 126 0.00 - - - Internet 126 126 0.00 - - - dsa_available IE: Irish Elk (Republic of Ireland Master) 144 113 21.53 1.0 0.0 0.41 dsa_available 144 113 21.53 30.3 0.0 19.60 IXI BE: Woolly Spider Monkey (Belgium Master 53 53 0.00 - - - Internet 53 53 0.00 - - - dsa_available   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <28177-0@bells.cs.ucl.ac.uk>; Mon, 17 Jun 1991 05:14:51 +0100 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-2) id ; Sun, 16 Jun 91 21:15:02 -0700 Date: Sun, 16 Jun 91 21:14:10 PDT From: hotz@edu.ISI Posted-Date: Sun, 16 Jun 91 21:14:10 PDT Message-Id: <9106170414.AA05166@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Sun, 16 Jun 91 21:14:10 PDT To: dsar@edu.ISI Cc: osi-ds@uk.ac.ucl.cs Subject: Directory Services Activities Report 5/91 May 1991 Issue #3 Directory Services Activities ----------------------------- This report serves as a forum to distribute information about the various efforts working to develop directory services that are for, or effect, the Internet. It is published as part of the FOX Project's efforts to facilitate the coordination and cooperation of different directory services working groups. This report is distributed virtually unchanged as part of the Internet Monthly Report, and a modified version is submitted to the PARADISE International Report. To be included on the mailing list which receives the stand-alone version of this report, send a note to "dsar-request@isi.edu". We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. The current reporters list includes: o IETF OSIDS & DISI Working Groups o Field Operational X.500 Project - ISI - Merit - PSI - SRI o ISO/CCITT Directory Editing Meeting - synopsis o National Institute of Standards and Technology o PARADISE Project o PSI DARPA/NNT X.500 Project o PSI WHITE PAGES PILOT o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) Steve Hotz (hotz@isi.edu) DS Report Coordinator IETF OSIDS & DISI WORKING GROUPS -------------------------------- Refer to IETF section (above) for additional information regarding the OSIDS and DISI working groups. Directory Information Services (pilot) Infra-structure WG --------------------------------------------------------- Ruth Lang (SRI) and Russ Wright (LBL) have finished the first round of surveys for their X.500 implementations guide for DISI. A second survey has gone out, and everything looks on track for a solid paper for the Atlanta IETF. Chris Weider (clw@merit.edu) FOX -- FIELD OPERATIONAL X.500 PROJECT -------------------------------------- The FOX project is a DARPA and NSF funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. ISI --- ISI organized the May 28 FOX phone conference, which included participants from all of the FOX contractors and NIST. The primary topic of this meeting was the status of projects ongoing at the various sites. Further discussion followed about establishing milestones for intra-FOX testing, demonstration, and eventual distribution of FOX sponsored projects. Other topics of discussion focused on potential Internet requirements for large distributed X.500 services, and the suitability of X.500 for bibliographic indexing applications. Steve Hotz (hotz@ISI.EDU) MERIT ----- This month Merit worked on representing "information resources" in an x.500 directory. This will include information about NICs, K-12 resources, and general online information. The UofM folks will start work to modify their MaX500 application to handle our object classes for these resources. We have been communicating with folks from Educom about the K-12 resources and with the NISI group about NIC information. An internet draft is in progress to document the resources schema definitions. Some specific activities related to the FOX project: we have been working to install some upgrades to quipu from Tim Howes, and have ordered a Sparc 2 to serve as another DSA for FOX activities. Chris Weider (clw@merit.edu) Mark Knopper (mak@merit.edu) PSI --- An alpha-release version of an X.500-based tool to provide simple document retrieval capabilities on RFCs and FYI documents was completed, and has been made available to the participants of the FOX project. Wengyik Yeong (yeongw@psi.com) SRI --- SRI completed efforts to provide access to WHOIS information through the White Pages Pilot Project (o=Internet@ou=WHOIS). The Northern Swift Fox DSA offers Individual, Computer, Network, Domain, Autonomous System, Organization, and Group information. A request to add WHOIS schema extensions to the Cosine and Internet X.500 Schema will be made in June. Custos 0.1.1 (NIST) was retrieved and compiled. Testing has uncovered some ISODE version related problems: Custos has been developed and tested with ISODE 6.0 while SRI is running version 6.8. These problems are being addressed by NIST and SRI. Survey responses for the DISI X.500 implementation catalogue were collected and collated. We have received approximately 20 responses thus far. The DISI group is reviewing submissions. Comments will be fed back to authors in June. The editors, Russ Wright (LBL) and Ruth Lang (SRI), are aiming to have a rough draft of the entire document completed for DISI review by the end of June. SRI provided input to Brad Harrison of DEC Professional regarding the DISI X.500 implementation survey. Harrison's article will appear in their July issue. Ruth Lang (rlang@nisc.sri.com) ISO/CCITT DIRECTORY EDITING MEETING - SYNOPSIS ---------------------------------------------- An International Organization for Standardization (ISO) and International Telegraph and Telephone Consultative Committee (CCITT) collaborative editing meeting on the Open Systems Interconnection (OSI) Directory was held in Phoenix, Arizona from 22 April to 3 May 1991 with representatives from ten countries attending. The National Body and Liaison Organization ballot comments on the Committee Draft (CD) and twelve Proposed Draft Amendments (PDAM) that were completed at the October 1990 meeting in Ottawa were resolved. All thirteen revised documents will be circulated for balloting at the same level on 3 June 1991. This ballot will close on 3 September and an editing meeting to consider comments will take place in Berlin in October, 1991. Draft International Standard (DIS) output is expected from the Berlin meeting. The replication and access control models are considered stable; however, the Directory and Directory System Agent (DSA) models, abstract services, and distributed operations parts of the standard need to be aligned with the replication and access control models. The most controversial decision concerning replication was the choice of the Reliable Transfer Service Element (RTSE) for recovery for replication. Some members of ISO do not believe that RTSE fits the OSI model. However, the Directory Group believes that it is the only solution practical for the 1992 standard. Going into the meeting, the documents for distributed operations and schema (directory models) needed the most work. At the previous meeting in Ottawa, U.S. participants had concentrated on the replication and access control documents. The U.S. position is that all documents must progress together, so a major effort was made this time to revise the distributed operations and schema PDAMs. Document Summary: The CDs and PDAMs being prepared for ISO balloting are listed below. The official titles are listed with the descriptive titles shown in brackets followed by reference number and JTC1/SC21 number. Replication, Schema, and Access Control [Overview] ISO/IEC 9594-1/2nd PDAM-1 #5942 Schema Extensions [Directory Models] ISO/IEC 9594-2/2nd PDAM-2 #5943 Replication [DSA Models] ISO/IEC 9594-2/2nd PDAM-3 #5944 Replication, Schema, and Enhanced Search [Abstract Service] ISO/IEC 9594-3/2nd PDAM-2 #5945 Replication, Schema, and Enhanced Search [Distributed Operation] ISO/IEC 9594-4/2nd PDAM-2 #5946 Replication [Protocol Specifications] ISO/IEC 9594-5/2nd PDAM-1 #5947 Schema Extensions [Selected Attribute Types] ISO/IEC 9594-6/2nd PDAM-1 #5948 Schema Extensions [Selected Object Classes] ISO/IEC 9594-7/2nd PDAM-1 #5949 Replication ISO/IEC 2nd CD 9594-9 #5951 Access Control ISO/IEC 9594-2 3rd PDAM-1 #5952 Access Control ISO/IEC 9594-3 3rd PDAM-1 #5953 Access Control ISO/IEC 9594-4 3rd PDAM-1 #5954 Access Control ISO/IEC 9594-8 2nd PDAM-1 #5955 Ella Gardner (epg@gateway.mitre.org) NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY ---------------------------------------------- On May 22nd NIST provided an interim release of the Custos X.500 software to the current Custos community. Release 0.1.1 incorporates: o changes for DAP interoperability with QUIPU and the OSIWARE X.500 product, o some restructuring of the database tables to support enhanced search performance, o improvements in a few areas such as correct handling of the root and more latitude in the configuration of context prefixes, and, o a number of bug fixes. The third meeting of the government-wide X.500 Pilot, sponsored by GSA and NIST, is scheduled for June 18th. Work is focused on further extensions to the draft schema document. Richard Colella (colella@osi.ncsl.nist.gov) PARADISE -------- The central DSA is being closely monitored. A cause of the "watchdog" problem reported last month has been found (X.25 RESETs). A patch has been applied to the DSA software, but this appears to only partly fix the problem. A new fix is being worked on. Belgium, Ireland and Israel have now joined the pilot (see below), although access to all three countries has not been good. There have been further interoperability tests with the French PIZARRO implementation, but there is currently a problem at the presentation level of the OSI stack which is being looked into. The first version of the "de" interface for the Central DUA service is now ready and being tested by the project. It will be made available to the PUNTERS group for beta testing and to elicit comments in the second week of June. A version of the software for a packaged DSA based upon ISODE is now ready, and will be made available for delivery once it has been decided whether to go with version 6.8, or to wait for the next full release, 7.0, which is expected very soon. The project produced the PARADISE International Report in both electronic and brochure form. The brochure was made available for the RARE Networking Conference held at Blois, France from 13-16 May. It is hoped to repeat the report every six months with electronic updates maintained regularly. A locality node, l=Europe, was set up with the intention of establishing a base for European multinational organizations to provide pointers to organizational entries below the country level of more than one European country. Site Reports: The Belgian DSA is based at the University of Brussels and is managed by Nils Meulemans running a QUIPU DSA (cn=Woolly Spider Monkey). The Israeli DSA (cn=Dorcan Gazelle) is based at the Hebrew University in Givat Ram, Jerusalem and managed by Juliana Solomon. The Irish Root DSA (Irish Elk) joined the global DIT this month. This DSA is running at Trinity College in Dublin and uses DEC X.25 Access for Ultrix to connect to IXI. Network performance is a problem, but the links are being upgraded soon. Currently there are only about 100 entries pertaining to the local site, but we hope that other universities and research institutions will be included later in the year. Any queries should be addressed to Donal O'Mahony (omahony@cs.tcd.ie). Portugal The Portuguese Pilot Directory Project is managed at the University of Minho, Data Communications Centre of the Department of Informatics, under a contract with FCCN (Fundacao de Calculo Cientifico Nacional), the national foundation in charge of the Portuguese Academic Network (RCCN). The Pilot Directory Project started in May 1991 and its plan consists of four phases: o installation of a master DSA for PT, local connectivity tests with DSP and DAP protocols, interfaces with e-mailers and connection to the European PARADISE pilot (May-July, 1991) o preparation phase: definition of the DIT structure, collection of information for the pilot service on a limited and selected scope and the gathering of experience in the management of the service (June-August, 1991) o distribution phase: set-up of DSAs in other sites (Universities and R&D Laboratories) and connectivity tests (September-November, 1991) o production phase: use in the RCCN (December 1991 - ...) Contacts for the Portuguese Pilot Directory Project are Joaquim Macedo (macedo@uminho.pt) and Fernando Pinto (fernando@uminho.pt). David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager PSI DARPA/NNT X.500 PROJECT --------------------------- In response to substantial comments received on NADF-123, revisions were made to the document, which will be submitted in revised form at the upcoming North American Directory Forum meeting. Development is under way on an MSDOS front-end to the information available in the PSI White Pages Project. It is intended that this software tool will eventually provide access to White Pages information from IBM PCs and compatibles that support FTP Software Inc.'s PCTCP stack. Wengyik Yeong (yeongw@psi.com) PSI WHITE PAGES PILOT PROJECT ----------------------------- As of June 4, 1991, there are 75 organizations participating in the White Pages in the United States of America. New organizations added in the past month are: University of Pennsylvania Oakland University In an effort to improve the general level of service afforded by the White Pages, organizations whose DSAs had longstanding reachability problems were 'pruned' from c=US. The following organizations have been deleted from the c=US arc of the DIT: Advanced Decision Systems Carnegie Mellon University NCI National Institute of Health University of Colorado at Boulder University of Rochester Beta testing was completed on a front-end to the PSI White Pages for the Macintosh. Version 1.0 of this shareware software is now available for anonymous ftp from uu.psi.com [136.161.128.3] in pilot/PSIWP.Hqx. This shareware has also been contributed to the USENET group comp.binaries.mac. Wengyik Yeong (yeongw@psi.com) SG-D MHS-MD ----------- SG-D MHS-MD just concluded a meeting held at the State Dept. in Washington, DC. Progress includes the revision of the draft procedures for MHS MD name registration. A tentative agreement was reached on the structure for resolving how ANSI registered national standing names can be used for MHS MD names, and also used as a "stem" for constructing names using a construction syntax to build additional nationally unique names for use as MHS MD names. This tentative resolution is to be fleshed out in the draft procedures for review and discussion at the next meeting on September 16-17 at the US Dept. of State in Washington. A discussion of the issues regarding how to organize a US National MTS (backbone) network of ADMD service providers was opened. This involves consideration of various alternative schemes; among them is an arrangement similar to that advocated in the UK scheme, which uses value for the ADMD name. We are soliciting contributions on this topic. SG-D MHS-MD is not yet focusing on issues of Directory Services. Einar Stefferud (stef@ics.uci.edu)   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6601-0@bells.cs.ucl.ac.uk>; Mon, 17 Jun 1991 13:49:52 +0100 To: wright@gov.lbl (Russ Wright) cc: osi-ds@uk.ac.ucl.cs Subject: Re: New photo format Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 10 May 91 15:09:12 +0000. <9105102209.AA14187@lbl.gov> Date: Mon, 17 Jun 91 13:49:50 +0100 Message-ID: <2147.677162990@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I'll put this on the Agenda for the Atlanta meeting. Could you prepare a 10 minute presentation on the issues? Steve >From: wright@gov.lbl (Russ Wright) >To: osi-ds@uk.ac.ucl.cs >Subject: New photo format >Date: Fri, 10 May 91 15:09:12 >Hi Everyone, >I hope I'm not alone when I say that the g3fax format we are using is >pathetic. Is anyone looking into another format? I just bumped into an >article on the JPEG still picture compression standard (Communications of the >ACM, April 1991) which is being developed by CCITT and ISO. JPEG looks quite >impressive and I think it deserves a hard look. > Russ   Return-Path: Received: from lbl.gov by bells.cs.ucl.ac.uk with SMTP inbound id <10372-0@bells.cs.ucl.ac.uk>; Mon, 17 Jun 1991 21:45:23 +0100 Received: from Mac-mailer (b50b-cnr20.lbl.gov) by lbl.gov (4.1/1.39) id AA23899; Mon, 17 Jun 91 13:46:37 PDT Message-Id: <9106172046.AA23899@lbl.gov> Date: Mon, 17 Jun 91 13:45:15 From: wright@gov.lbl (Russ Wright) To: S.Kille@uk.ac.ucl.cs Subject: Re: New photo format Cc: osi-ds@uk.ac.ucl.cs I'm no expert, but I will give it a try. Russ   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Mon, 17 Jun 1991 23:23:43 +0100 Date: Mon, 17 Jun 1991 22:23:43 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.678:17.05.91.22.23.43] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Mon, 17 Jun 1991 23:23:43 +0100) From: David Wright Message-ID: <0094a47df47336de@ash.stl.stc.co.uk> To: osi-ds@uk.ac.ucl.cs, wright@gov.lbl Subject: Re: New photo format X-Vms-Mail-To: INET%"wright@lbl.gov" Do bear in mind that the JPEG standard represents lossy compression of the image, and also tends to need a lot of CPU power to process. Neither is a bar to use - the losses are those which (hopefully) are not particularly noticable to the human eye, and CPU performance keeps going up. But it is not the completely reversible compression we're used to with G3, GIF etc. On the positive side, proponents of JPEG claim that on typical images it can achieve far greater compression ratios than lossless methods - which in turn allows greater spatial resolution in a given bandwidth. For those of you with access to the news net, there's an ongoing discussion of JPEG in news group comp.compression. Regards, "None shall be enslaved by poverty, ignorance or conformity" David Wright BNR Europe, London Road, Harlow, Essex CM17 9NA, UK dww@stl.stc.co.uk ...uunet!mcsun!ukc!stl!dww PSI%234237100122::DWW /g=David/s=Wright/org=STC Technology Ltd/prmd=STC plc/admd=Gold 400/co=GB   Return-Path: Received: from ean-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1730-0@bells.cs.ucl.ac.uk>; Tue, 18 Jun 1991 00:19:57 +0100 Received: from [130.102.128.5] by Ean-Relay.AC.UK via Ethernet with SMTP id aa11982; 18 Jun 91 1:05 BST Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au id aa08293; 18 Jun 91 9:17 EST To: David Wright cc: osi-ds@uk.ac.ucl.cs, wright@gov.lbl, ggm@au.oz.uq.cc Subject: Re: New photo format In-reply-to: Your message of "Mon, 17 Jun 91 22:23:43 GMT." <0094a47df47336de@ash.stl.stc.co.uk> Date: Tue, 18 Jun 91 09:17:18 +1000 Message-ID: <8291.677200638@brolga.cc.uq.oz.au> From: George Michaelson Do bear in mind that the JPEG standard represents lossy compression of the image, and also tends to need a lot of CPU power to process. Neither is a bar to use - the losses are those which (hopefully) are not particularly noticable to the human eye, and CPU performance keeps going up. But it is not the completely reversible compression we're used to with G3, GIF etc Imaging as it stands in ISODE/QUIPU is hardly loss-free. Most of the images have been scanned/processed/cuisinarted into a mushy mess long before they get fax encoded. If jumping up into JPEG meant I could embed colour images without preventing slow nets fetching the image as B&W for instance, I for one would like it. I suggest a generalized representation in the DB, and a range of filters to produce appropriate format prior to DSP/DAP injection, and also in the DUA. George   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <15212-0@bells.cs.ucl.ac.uk>; Tue, 18 Jun 1991 17:47:31 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <14894-3@sun2.nsfnet-relay.ac.uk>; Tue, 18 Jun 1991 17:36:21 +0100 Received: from lbl.gov by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa09202; 18 Jun 91 17:30 BST Received: from Mac-mailer (b50b-cnr20.lbl.gov) by lbl.gov (4.1/1.39) id AA27550; Tue, 18 Jun 91 09:34:33 PDT Message-Id: <9106181634.AA27550@lbl.gov> Date: Tue, 18 Jun 91 09:33:09 From: wright@gov.lbl (Russ Wright) To: D.W.Wright@uk.co.stc.stl Subject: Re: New photo format Cc: osi-ds@uk.ac.ucl.cs Sender: wright@gov.lbl > Do bear in mind that the JPEG standard represents lossy compression of the > image, and also tends to need a lot of CPU power to process. Neither is a > bar to use - the losses are those which (hopefully) are not particularly > noticable to the human eye, and CPU performance keeps going up. But it > is not the completely reversible compression we're used to with G3, GIF etc. The JPEG standard includes lossless compression which does not use the cosine transforms. The claim is 2:1 compression. If you want completely reversible compression, you have to pay the price. I would rather have a smaller image. One of the neat things about JPEG is that you can choose the compression level (up to 50:1), depending on the required image quality. Does anyone know where there is a description of the G3 fax format we are currently using? >For those of you with access to the news net,there's an ongoing discussion of > JPEG in news group comp.compression. Some very useful information here. Here is one example: -------- From: tgl@g.gp.cs.cmu.edu (Tom Lane) > To put this in perspective, here's some actual data for a small (205 x 250) > full color image that I have handy. This would be about a factor of 4 > smaller than a typical 640x480 image. > > Format # Bytes Compression > full color uncompressed (PPM format) 150 Kb > same passed thru Unix "compress" (enlarges file 9%) > alleged performance of JPEG lossless spec 75 Kb 2:1 > 256-color GIF (made with PPM tools) 49 Kb 3:1 > Lossy JPEG at "typical" quality setting 9.5 Kb 16:1 > Lossy JPEG at "high" quality setting 16.5 Kb 9:1 > > (The JPEG lossless number is a guess based on the 2:1 ratio claimed in the > spec; all the rest are actual numbers. Many GIFs are more like 4:1 or 5:1 > smaller than full color equivalents, so this test case might be atypical.) Russ   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <16565-0@bells.cs.ucl.ac.uk>; Tue, 18 Jun 1991 19:10:04 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <16800-1@sun2.nsfnet-relay.ac.uk>; Tue, 18 Jun 1991 19:05:34 +0100 Received: from lbl.gov by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa10362; 18 Jun 91 19:02 BST Received: from Mac-mailer (b50b-cnr20.lbl.gov) by lbl.gov (4.1/1.39) id AA28144; Tue, 18 Jun 91 11:07:04 PDT Message-Id: <9106181807.AA28144@lbl.gov> Date: Tue, 18 Jun 91 11:05:41 From: wright@gov.lbl (Russ Wright) To: osi-ds@uk.ac.ucl.cs Subject: next IETF Sender: wright@gov.lbl X.400 wants to use Tuesday and Wednesday. When is X.500 going to meet? I need to go to both. Russ   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22326-0@bells.cs.ucl.ac.uk>; Wed, 19 Jun 1991 09:23:02 +0100 To: wright@gov.lbl (Russ Wright) cc: osi-ds@uk.ac.ucl.cs Subject: Re: next IETF Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 18 Jun 91 11:05:41 +0000. <9106181807.AA28144@lbl.gov> Date: Wed, 19 Jun 91 09:22:59 +0100 Message-ID: <542.677319779@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I have aksed for 2 sessions (i.e., two thirds of a day) for OSI-DS, which should be convenient for someone attending OSI-DS only (i.e. adjacent!). I think that this should be sufficient to cover things on the table (if people think that we need a longer session, let me know soon). There are quite a few potential conflicts, and I've asked the organisers to find a slot which minimises these. I'll let you know as soon as I have a date. Things which it must not conflict with: DISI (very large overlap); ad hoc 1148 revision editing group (I chair both). I have requested to avoid conflicts with: X.400 (this may be hard, as it is a LONG meeting) Resource Location (this is very relevant to directory development) Steve   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <28031-0@bells.cs.ucl.ac.uk>; Wed, 19 Jun 1991 20:09:34 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <14838-16@sun2.nsfnet-relay.ac.uk>; Wed, 19 Jun 1991 20:04:42 +0100 Received: from [129.6.55.32] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa08241; 19 Jun 91 19:58 BST Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA16153; Wed, 19 Jun 91 13:12:39 EDT Date: Wed, 19 Jun 91 13:12:39 EDT From: Richard Colella Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9106191712.AA16153@emu.ncsl.nist.gov> To: disi@edu.merit, fox@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Happenings at the recent OIW Directory SIG meeting. Cc: Richard_ , dssig@com.sri.nisc, rlang@com.sri.nisc The Directory SIG met last week during the OSI Implementors' Workshop. The agenda included an item resulting from the attempts at SRI to load the WHOIS database into X.500. In particular, the postalAddress upper bound constraint of 30 characters per line was too small for about half of the 100K entries. I had offered to carry this issue in on behalf of the FOX effort; I am reporting the results more widely, since I believe this to be of general interest. The upshot of the SIG meeting is that the SIG voted unanimously to change the upper bound on a line to 60 characters (the number of lines will remain at 6). This change will be reflected in the Working Agreements out of this meeting, and will be voted on for inclusion into the Stable Implementation Agreements at the September meeting. A number of individuals were polled informally during the week to get a reading on whether this would be a problem: - A representative from the USPS (since the 6x30 constraint is based on a UPU standard); - A long-standing member of the ANSI/ISO X.500 standards effort, who knows the X.500 history; and, - Folks from the MHS SIG, who build X.400 products. The general consensus was that, not only should the Directory SIG make this change, but it should be used as a driving function get others to make the same change. --Richard   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <22058-0@bells.cs.ucl.ac.uk>; Thu, 20 Jun 1991 04:10:57 +0100 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA11655; Wed, 19 Jun 91 23:10:59 -0400 Message-Id: <9106200310.AA11655@terminator.cc.umich.edu> To: wright@gov.lbl (Russ Wright) Cc: D.W.Wright@uk.co.stc.stl, osi-ds@uk.ac.ucl.cs Subject: Re: New photo format In-Reply-To: Your message of "Tue, 18 Jun 91 09:33:09." <9106181634.AA27550@lbl.gov> Date: Wed, 19 Jun 91 23:11:00 -0400 From: Tim Howes > Does anyone know where there is a description of the G3 fax format we are > currently using? I don't know of anywhere it's available on line, but G3 fax is described by CCITT standard T.4. -- Tim   Return-Path: Received: from dg-rtp.rtp.dg.com by bells.cs.ucl.ac.uk with SMTP inbound id <3423-0@bells.cs.ucl.ac.uk>; Thu, 20 Jun 1991 19:26:00 +0100 Received: from bigben.dle.dg.com by dg-rtp.dg.com (5.64+/dg-rtp-proto) id AA04086; Thu, 20 Jun 91 14:25:58 EDT Received: by bigben.dle.dg.com (4.30/dg-g01) id AA07236; Thu, 20 Jun 91 19:25:55 bst via SMTP Date: Thu, 20 Jun 91 19:25:55 bst From: philip@com.dg.dle.bigben (Philip Gladstone) Message-Id: <9106201825.AA07236@bigben.dle.dg.com> To: D.W.Wright@uk.co.stc.stl, osi-ds@uk.ac.ucl.cs, wright@gov.lbl Subject: Re: New photo format On the subject of JPEG displays. I did a version of xphoto that would decode and display a JPEG photo rather than a g3fax one. My experiments showed that the CPU time was significantly LESS for jpeg rather than g3fax. I suspect that this was more due to the way that the X display was driven rather than the encoding format being easier! Philip   Return-Path: Received: from ean-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <26670-0@bells.cs.ucl.ac.uk>; Fri, 21 Jun 1991 00:43:25 +0100 Received: from [130.102.128.5] by Ean-Relay.AC.UK via Ethernet with SMTP id aa11760; 21 Jun 91 1:25 BST Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au id aa09412; 21 Jun 91 9:39 EST To: Philip Gladstone cc: D.W.Wright@uk.co.stc.stl, osi-ds@uk.ac.ucl.cs, wright@gov.lbl, ggm@au.oz.uq.cc Subject: Re: New photo format In-reply-to: Your message of "Thu, 20 Jun 91 19:25:55 BST." <9106201825.AA07236@bigben.dle.dg.com> Date: Fri, 21 Jun 91 09:39:25 +1000 Message-ID: <9410.677461165@brolga.cc.uq.oz.au> From: George Michaelson On the subject of JPEG displays. I did a version of xphoto that would decode and display a JPEG photo rather than a g3fax one. My experiments showed that the CPU time was significantly LESS for jpeg rather than g3fax. I suspect that this was more due to the way that the X display was driven rather than the encoding format being easier! Philip I'm demoing the directory later this month and BADLY need code to disply colour images. Can I possibly beg sight of this program? George   Return-Path: Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <16563-0@bells.cs.ucl.ac.uk>; Fri, 21 Jun 1991 09:09:02 +0100 To: George Michaelson cc: Philip Gladstone , osi-ds@uk.ac.ucl.cs Subject: Re: New photo format In-reply-to: Your message of Fri, 21 Jun 91 09:39:25 +1000. <9410.677461165@brolga.cc.uq.oz.au> Date: Fri, 21 Jun 91 09:08:57 +0100 From: Jon Crowcroft Philip, >I'm demoing the directory later this month and BADLY need code to disply >colour images. Can I possibly beg sight of this program? me too - i'm interested in efficient code for image compression/coding/decoding... is't possible to see src? jon   Return-Path: Received: from EMU.NCSL.NIST.gov by bells.cs.ucl.ac.uk with SMTP inbound id <404-0@bells.cs.ucl.ac.uk>; Fri, 21 Jun 1991 21:34:47 +0100 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA11217; Fri, 21 Jun 91 16:32:56 EDT Date: Fri, 21 Jun 91 16:32:56 EDT From: Richard Colella Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9106212032.AA11217@emu.ncsl.nist.gov> To: osi-ds@uk.ac.ucl.cs Subject: COSINE and Internet X.500 Schema The rfc822Mailbox, domainComponent, and janetMailbox attributes reference caseIgnoreIA5StringSyntax. However, this syntax is not defined here (or in the standard). My guess is that the syntax definition was inadvertantly left out. Alternatively, iA5StringSyntax could have been intended, but this is case-sensitive (probably not what is needed). (I'm looking at the March 91 version.) --Richard   Return-Path: Received: from ws28.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <14394-0@bells.cs.ucl.ac.uk>; Fri, 21 Jun 1991 23:18:34 +0100 Received: by ws28.nisc.sri.com (5.64/SRI-NISC1.1) id AA02729; Fri, 21 Jun 91 15:18:06 -0700 Message-Id: <9106212218.AA02729@ws28.nisc.sri.com> To: Richard Colella Cc: osi-ds@uk.ac.ucl.cs, rlang@com.SRI.NISC Subject: Re: COSINE and Internet X.500 Schema In-Reply-To: Your message of Fri, 21 Jun 91 16:32:56 -0400. <9106212032.AA11217@emu.ncsl.nist.gov> Date: Fri, 21 Jun 91 15:18:05 PDT From: Ruth Lang Date: Fri, 21 Jun 91 16:32:56 EDT From: Richard Colella > The rfc822Mailbox, domainComponent, and janetMailbox attributes > reference caseIgnoreIA5StringSyntax. However, this syntax is > not defined here (or in the standard). My guess is that the > syntax definition was inadvertantly left out. Alternatively, > iA5StringSyntax could have been intended, but this is case-sensitive > (probably not what is needed). (I'm looking at the March 91 version.) > > --Richard One reference for the definition of caseIgnoreIA5StringSyntax is the "X.500 and Domains" internet draft. Ruth   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9249-0@bells.cs.ucl.ac.uk>; Fri, 28 Jun 1991 11:55:59 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 28 Jun 91 11:55:58 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 14th June - Friday 28th June. Bind Fail %age Best Worst Ave Address GB: Vampire Bat (GB backup) 33 0 100.00 0.4 1.2 0.55 Private TCP 81 7 91.36 0.1 1.0 0.47 dsa_available 81 7 91.36 1.3 11.6 4.90 Janet 76 34 55.26 0.0 2.9 3.67 IXI Coypu (Thorn acces pt to quipu) 31 1 96.77 1.0 8.4 2.39 Local Ether 85 4 95.29 1.6 10.1 11.24 X121 84 5 94.05 1.4 13.0 9.91 Janet 140 9 93.57 0.1 1.0 0.32 dsa_available 92 11 88.04 0.5 53.3 12.05 Internet False Cobra (Root, GB backup) 86 4 95.35 1.5 8.9 5.42 X121 83 5 93.98 1.3 10.3 4.59 Janet 140 9 93.57 0.1 1.0 0.32 dsa_available 93 11 88.17 0.3 100.6 8.45 Internet 79 32 59.49 0.0 3.7 4.35 IXI Giant Tortoise (Root, GB Master) 83 26 68.67 1.0 9.6 3.77 Janet 84 30 64.29 0.4 69.9 4.90 X121 138 50 63.77 0.1 1.0 0.32 dsa_available 91 42 53.85 0.2 9.6 3.36 Internet 79 41 48.10 0.0 2.0 3.78 IXI Passionflower Leaf Beetle (GB Domain name information) 132 45 65.91 0.0 1.0 0.31 dsa_available 82 28 65.85 0.0 8.3 6.57 Janet 81 33 59.26 0.0 9.5 6.06 X121 93 39 58.06 0.0 74.8 8.85 Internet 78 53 32.05 0.0 6.6 4.38 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 84 84 0.00 - - - Janet 84 84 0.00 - - - dsa_available DE: Puma (GMD/FOKUS) 77 3 96.10 3.4 23.0 8.02 Int-X.25 124 14 88.71 0.1 1.0 0.32 dsa_available 30 4 86.67 4.8 93.5 20.24 Internet 58 16 72.41 3.1 26.1 7.54 Internet 77 37 51.95 0.0 3.4 7.41 IXI Margay (GMD/F3, DE backup) 78 6 92.31 3.4 23.4 9.40 Int-X.25 91 11 87.91 2.1 94.8 16.53 Internet 127 17 86.61 0.1 1.0 0.32 dsa_available 80 43 46.25 0.0 4.2 5.43 IXI CA: Pangolin (Northern Telecom Master) 30 2 93.33 1.2 52.4 8.14 Private TCP 97 21 78.35 0.1 0.1 0.10 dsa_available 90 22 75.56 3.8 68.6 15.89 Internet Beluga Whale (Canada Master) 32 6 81.25 0.1 0.1 0.10 dsa_available 32 6 81.25 4.1 100.7 13.45 Internet Wayne Gretzky (Old Canada Master) 86 84 2.33 0.0 0.1 0.06 dsa_available 86 84 2.33 0.0 28.0 12.59 Internet SE: Hummingbird (Sweden Master) 89 6 93.26 3.1 91.0 16.93 Internet 102 19 81.37 0.1 0.1 0.10 dsa_available 86 86 0.00 - - - X121 AU: Anaconda (AU Master) 118 8 93.22 0.1 0.1 0.10 dsa_available 90 8 91.11 9.2 197.3 28.70 Int-X.25 109 13 88.07 1.8 23.8 11.54 Internet Bush Dog (master for AU (phony)) 93 8 91.40 0.1 0.1 0.10 dsa_available 93 8 91.40 0.7 11.7 21.60 Internet NO: Electric Eel (Norway Master) 93 8 91.40 2.8 18.2 7.70 Internet 78 10 87.18 2.9 19.0 6.91 Int-X.25 130 17 86.92 0.1 1.0 0.31 dsa_available 79 38 51.90 0.0 4.3 6.09 IXI Boa Constrictor (Norway Backup) 98 15 84.69 5.6 78.6 21.55 Internet 79 14 82.28 2.4 33.9 9.15 Int-X.25 137 25 81.75 0.1 1.0 0.31 dsa_available 81 41 49.38 0.0 12.2 13.89 IXI IS: Elephant Seal (Iceland Master) 92 9 90.22 0.1 0.1 0.10 dsa_available 92 9 90.22 6.4 80.5 27.76 Internet ES: Iguana (ES Master. Programa IRIS) 91 11 87.91 3.2 80.9 18.17 Internet 127 47 62.99 0.0 0.1 0.08 dsa_available 78 78 0.00 - - - Int-X.25 80 80 0.00 - - - IXI CH: Condor (ETH Zurich) 103 18 82.52 0.1 0.1 0.10 dsa_available 79 14 82.28 3.3 56.5 14.74 Int-X.25 97 25 74.23 2.5 15.5 10.47 Internet Chinchilla (Swiss Master) 97 43 55.67 0.1 0.1 0.10 dsa_available 97 43 55.67 3.6 20.9 16.27 Internet US: Fruit Bat (US@l=NY master) 91 18 80.22 0.1 0.1 0.10 dsa_available 91 18 80.22 1.3 54.5 17.98 Internet Alpaca (US master) 110 22 80.00 0.1 0.1 0.10 dsa_available 110 22 80.00 1.1 28.9 8.26 Internet Giant Anteater (Various slave) 91 43 52.75 0.1 0.1 0.10 dsa_available 91 43 52.75 1.4 27.9 8.96 Internet IL: Dorcan Gazelle (Israel Master) 31 7 77.42 0.1 0.1 0.10 dsa_available 31 7 77.42 10.3 117.9 34.23 Internet AT: Piranah (AT Master) 95 28 70.53 0.0 0.1 0.08 dsa_available 77 24 68.83 0.0 247.4 29.55 Int-X.25 90 35 61.11 0.0 107.0 13.75 Internet NL: Hornero (NL Master) 104 60 42.31 0.0 0.1 0.08 dsa_available 91 55 39.56 0.0 34.0 10.53 Internet 85 52 38.82 0.0 18.4 7.82 X121 Agouti (NL Slave) 110 110 0.00 - - - Internet 110 110 0.00 - - - dsa_available FI: Jaguar (Finland Master) 91 56 38.46 3.9 87.7 14.81 Internet 104 68 34.62 0.1 0.1 0.10 dsa_available 87 72 17.24 0.0 5.4 4.38 X121 DK: Axolotl (DK Master) 109 68 37.61 0.1 0.1 0.10 dsa_available 109 68 37.61 5.0 56.5 14.24 Internet IE: Irish Elk (Republic of Ireland Master) 80 80 0.00 - - - IXI 80 80 0.00 - - - dsa_available BE: Woolly Spider Monkey (Belgium Master) 30 30 0.00 - - - Internet 30 30 0.00 - - - dsa_available   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <18411-0@bells.cs.ucl.ac.uk>; Fri, 28 Jun 1991 14:37:42 +0100 To: osi-ds@uk.ac.ucl.cs Cc: Megan Davies Subject: DRAFT * Minutes of the April Videoconference * DRAFT Phone: +44-71-380-7294 Date: Fri, 28 Jun 91 14:37:41 +0100 Message-ID: <1683.678116261@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Eventaully finished! I append a draft for comment. If anyone else wishes to add personal comments, please let me have them. The delay is entirely my fault. All of the other authors of the minutes were very prompt. I will release revised versions (text and postscript) on 4th July. Steve Minutes of the Third IETF Directory Services (OSI-DS) Working Group Videoconference 11th April 1991 Peter Mierswa Ruth Lang Colin Robbins Steve Hotz BBN SRI X-Tel ISI Steve Kille UCL June 28, 1991 1 Contents 1 Introduction 4 2 Agenda 4 3 Attendees 6 4 Introductions 6 5 Pilot activity 7 5.1 PARADISE (David Goodman) . . . . . . . 7 5.2 FOX (Bob Braden, Steve Hotz) . . . . . 8 5.3 RARE WG3 (Erik Huizer) . . . . . . . 9 5.4 NADF (Einar Stefferud) . . . . . . . 9 6 Monthly Reporting 10 7 Management of experimental object identifiers 10 8 Activities Documents 11 9 Management of Experimental Object IDs 11 10 Document Status 12 10.1 Strategy Document . . . . . . . . 12 10.2 IETF OSIDS documents . . . . . . . 12 11 Other documents 13 2 11.1 Naming Guidelines . . . . . . . . 13 11.2 Representing Network Information . . . . 13 11.3 NADF-123 . . . . . . . . . . 14 12 DISI and OSI-DS 15 13 Meeting Administrivia 15 14 AOB 16 15 Next Meeting 16 16 Peronsal Comments on the meeting 17 16.1Colin Robbins . . . . . . . . . 17 16.2Steve Titcombe . . . . . . . . . 17 16.3Einar Stefferud . . . . . . . . . 19 16.4Steve Kille . . . . . . . . . . 20 3 1 Introduction This meeting was held as a videoconference at four sites: BBN; SRI (RIACS facility); ISI; UCL. Minutes were taken at each site, and this note is a compilation of those minutes. In addition, there was a phone-in from Merit. The meeting was an interesting ``first'' in use of the videoconference technology in that: o It was not a videoconference about videoconferencing o Four sites were involved, one not in the US o There were more than one or two participants at each site 2 Agenda This is a joint meeting with members of RARE WG3. Date Videoconference on Thursday 11th April UCL 17:00 - 21:00 BST BBN 12:00 - 16:00 EDT SRI/RIACS (Bay Area) 09:00 - 13:00 PDT Times are ``UCL time'' (BST) Tuesday 17:00 Introduction o Discussion of Videoconference modus operandi o Agenda o Minutes of previous meeting o Matters arising o No liaisons! 4 17:15 Document Status. Review status of all working documents, Internet Drafts, and submitted RFCs. 17:25 Presentation of Pilot Activity DISI (Chris Weider) PARADISE (David Goodman) FOX (Steve Hotz, Bob Braden, Ruth Lang) RARE WG3 (Erik Huizer) Top level DSA configuration (Colin Robbins) 18:15 Monthly Reporting (Steve Hotz/David Goodman) 18:30 US/Europe liaison issues 18:45 Management of ``experimental'' object identifiers 19:00 Naming Guidelines (Paul Barker) 19:15 Representing Network Information (Mark Knopper??) 19:45 Security (Peter Yee) 20:20 Naming in the US in light of NADF 123 (Einar Sefferud) 20:50 Date and Venue of next meeting 20:50 -- 21:00 AOB 5 3 Attendees At BBN: Peter Mierswa (DEC) RIACS attendees: Russ Wright, LBL Ruth Lang, SRI ISI site attendance list: Bob Braden ISI 213.822.1511 braden@isi.edu Steve Hotz ISI 213.822.1511 hotz@isi.edu Einar Stefferud NMA stef@ics.uci.edu Dan Molinelli TRW 213.812.2161 moline@gumby.dsd.trw.com Charles Wolverton Aerospace wolverton@msandc.mve.aero.org At UCL there were: Jim Cragie JNT Paul Barker UCL Steve Kille UCL David Goodman UCL Colin Robbins X-Tel Erik Huizer Surfnet Julian Onions X-Tel Steve Titcombe UCL Peter Williams UCL Nick Emery DEC 4 Introductions Meeting started at 5:15 (UCL) after some work to set mike levels etc. Introductions were made from the remote sites: BBN; ISI and RIACS. Not knowing many of the people made it almost impossible to work out who was actually introducing themselves. 6 5 Pilot activity 5.1 PARADISE (David Goodman) PARADISE is a sub-project of the broader COSINE project sponsored under the umbrella of EUREKA by eighteen participating countries and aimed at promoting OSI to the academic, industrial and governmental research and development organizations in Europe. The countries involved are those of the EC, EFTA plus Yugoslavia. The partners funded by PARADISE besides UCL are: o the Networks Group at the University of London Computer Centre (ULCC), which is a service-oriented organization providing a range of facilities to the academic community in London and the entry point into the UK for IXI, the COSINE international X.25 backbone; o X-Tel Services Ltd, a software company based in Nottingham which currently provides service support to the UK Academic X.500 pilot; and o PTT Telematic Systems from the Netherlands, which in turn has subcontracted the Swiss and Finnish PTTs, and whose involvement is to create a forum for discussion on X.500 among the European carrier administrations. The project also aims to have representation from all the participating countries, which in the majority of cases are the existing X.500 national pilots. Of the 18 countries involved, 12 are registered in the tree, including Ireland and Italy whose nodes were taken up this month. Most countries are using the QUIPU implementation developed at UCL. However, a French group have developed PIZARRO, which will form the basis of the emerging French pilot and, in Italy, a Torino-based company Systems Wizards are using DirWiz, which is currently the sole representative from Italy in the tree. PARADISE recently announced an operational service providing a central configuration DSA with connectivity via IPSS, IXI, JANET (UK Joint Academic Network) and the Internet. This DSA contains the "root of the world" node and provides the glue at the top of the international DIT. By this summer a central DUA will be installed with public access via ULCC. Multilingual versions of 7 this interface will be made available later in the project. Both these central services will be provided by ULCC, which will be offering a help desk with telephone and e-mail support. 5.2 FOX (Bob Braden, Steve Hotz) Bob Braden remarked that the Internet funding agencies, as well as the IAB, were anxious to see an X.500 directory service infrastructure in the Internet, and that the FOX project was working toward this goal. He further noted that the FOX project wants to make every effort to make certain that it's effort are aligned with X.500 activities in other communities. Steve Hotz commented on the recently released directory activities report (for Internet and other North American efforts) that appeared in the March Internet Monthly Report. He asked for comments regarding contents of the report, additional efforts that should be contacted, and ideas on where else it should be distributed, in addition to the IMR. Steve announced that the FOX project has scheduled a phone conference for Wed. April 17th. The FOX project is a DARPA and NSF funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. There are two primary thrusts of the FOX project: 1. X.500 Infrastructure It is important that multiple interoperable platforms be available for deployment. FOX plans to examine and test the interoperability of the Quipu and NIST-X.500 (Custos) implementations, and DNANS-X.500 if possible. In addition, FOX will explore X.500 interfaces to conventional database systems (one target is Sybase), an alternate OS platform (VM) for X.500 servers, and X-window based user interfaces. 2. X.500 Applications A long-range goal is to facilitate the use of X.500 for real Internet applications. FOX will first focus on making network infrastructure information available through X.500. This includes network and AS site contacts, topology information, and the NIC 8 WHOIS service. A centrally managed X.500 version will be the first phase of a WHOIS service. Providing an X.500 version of a well-known widely-used service should promote the use of X.500 by Internet users. In addition, this effort will provide experience in designing X.500 applications. However, the manageability of this scheme will be short-lived, so the next step will be a design for a distributed version of WHOIS. 5.3 RARE WG3 (Erik Huizer) Erik pointed out that WG3 was not a pilot activity, but rather an engineering group whose activities parallel those of IETF OSI-DS. WG3 is the directory services subgroup of the COSINE project, whose purpose was to handle technical aspects of directory service deployment. In the future, issues such as privacy, data management, and data update will receive more focus. He mentioned the efforts of the P2.2 project in user information services to build a meta-information server, which would contain data about network services worldwide. A commercial company (Level-7) has been contracted to provide this service. 5.4 NADF (Einar Stefferud) Einar announced the release of NADF-123, a document on the organization of the North American DIT, and that they are currently soliciting comments. NADF-123 specifies that the current civilian infrastructure be used to organize the DIT, and pointed out some of the difficulties with other structures. In particular, U.S. organizations are registered at a state level, so difficulties arise if one were to normally place entities under the country level. NADF-123 proposes multiple-attribute RDNs to allow organizations that, in addition, want to be listed at the country level. This scheme deals with possible name conflicts that may result from multiple entities registered in different states. S.K. Asked about timetable to build conforming directory services? E.S. Replied that different service providers vary widely in the stage of development of their services. What matters is the time when someone mounts the first shared DS. 9 NADF has also gotten directory providers to agree that they will share information about the DIT. Einar commented that this was a significant milestone. 6 Monthly Reporting Hotz is working to coordinate the US submission; he offered that he had not had a chance to coordinate the International report with Goodman. Goodman suggested model that complete status be given every six months and that incremental reports be given bimonthly. Discussion followed regarding whether reports should be given by country. The Internet is international, whereas the DIT is structured by country. Goodman suggested that each country's efforts be summarized and an Internet summary be included as well. Hotz is working with OIW-DS to include their report as well. 7 Management of experimental object identifiers Problem identified -- experimental ids admitted to schema are changed; this forces a fast update cycle of document Points: 1) No fundamental need to change oid when put into schema, but is a management problem. 2) Changing oid gives it an identity with schema. 3) Mixing concept of registry vs library of oids. Suggestion that library id numbers be created and given out with each. Kille moved that Barker reflect the idea of 1 plus 3 in the schema document. Discussion continued regarding: 1) the transition of oids from informal to formal. No conclusions. 2) IANA model. IANA process is mechanical, Kille feels that a purely administrative approach to the schema is not advisable -- technical and aesthetic concerns must be incorporated as well. No conclusions. 10 8 Activities Documents Hotz discussed further status of the North American and Internet activities activities report. He indicated that he was talking with Einar about including entries for ANSI USA RAC and SG-D MHS-MD, and Youbong Weon-Yoon about OIW DSSIG reports. David Goodman discussed the tentative plans for an international report, which is to be produced either every two or three months. Goodman asked Hotz if he would provide a summary for the Internet and other US activities. Hotz agreed, and asked for guidance in what was needed. Hotz and Goodman will continue off-line. 9 Management of Experimental Object IDs There is some question whether (and how) provisions should be made for very fast allocation of OIDs for experimental efforts, in light of the consequent revocation problems. This is not facilitated by the current mechanisms for including new OIDs into the standard schema. Stefferud commented that a plan which included reassignment of OIDs is a bad idea, as has been seen before with other assigned numbers. Braden suggested that IANA be assigned an OID space and that mechanisms, already in place to assign Internet numbers, be used to allocate OIDs. A comment from UCL was that this approach would lead to many name spaces, and this could make to various problems in managing the globally standard OIDs. How would one know where to find all of those currently supported? Paul Barker noted that different OID requests and their intended applications had different characteristics, and that it might be possible to decide on a case-by-case basis which mechanism should be used. ACTION ITEM: Paul Barker will write this idea up. Kille pointed out that the OID aliasing mechanism in Quipu could be used to facilitate transition when OIDs are reassigned. He added that maybe this mechanism should be required in directory pilots. Einar has a document concerning number assignment. He will distribute it via email, where this topic can be further pursued. Braden commented that a directory services requirements document, 11 in a similar vein as the host and gateway requirements documents, would be useful. Among other things, this could document the OIDs required to interoperate, and solve the question of where to look for the officially required OIDs. Kille expressed concern that this would only document Internet requirements and not be sufficient for international needs. Braden pointed out that one needed to start somewhere and that this was an IETF working group meeting. He went on to note that the Internet is an international activity, and is growing more so. Einar Stefferud commented that the Internet will only remain an American effort so long as the European community insists that it is. Kille asked about who should be responsible for producing a requirements document. Braden replied that this decision should be taken up with the IESG coordinator. 10 Document Status Steve Kille organized this topic into three areas: strategy document, IETF OSI-DS documents, and others. 10.1 Strategy Document Steve Kille noted that this has been submitted as an RFC. Bob Braden, who is serving as interim RFC editor will help see this along. Braden and Kille will follow this up off-line. 10.2 IETF OSIDS documents Steve Kille enumerated these seven documents. Braden inquired about the plans for progressing these documents. scheme document - standards track interim network names - standards track representing presentation addresses - info only, maybe standards?? replication requirements - statement, info only replication solutions - standards user friendly naming - standards X.500 and domain names - experimental, maybe standards track later?? 12 Braden indicated that he believed some of these should be offered as experimental RFCs now. Kille ask for a clarification of experimental versus standards track RFCs. Braden pointed out that there was not a strong relationship between experimental and standards track RFCs. It is not the case that standards track RFCs always (or never) start out as experimental. 11 Other documents 11.1 Naming Guidelines Paul Barker discussed the addition of support for multilingual names, adding that it requires considerable effort. As an example, one can consider names of organizational units and departments. One would want people worldwide to be able to understand these attributes. This suggests multi-lingual tagging of commonly used names. The various structuring of human names is another issue to be resolved. Einar Stefferud remarked that it would be an unacceptable burden to have every directory understandable in every other language. It was suggested that a language attribute could be included to indicate what languages are supported. This raises the need for OIDs for each language; national OIDs would not be appropriate since there are many more languages and dialects than countries. The question was raised about how one would name multi-national organizations. Einar commented that NADF-123 document dealt with multi-state organizations in the U.S., and that an analogous scheme could be used for international organizations. Kille commented that any structure could work, but was concerned with how well they would work, and the technical impact that they might have. 11.2 Representing Network Information Mark Knopper asked if there were any questions or comments on the Network Infrastructure Schema document that was distributed some time ago. 13 Kille commented that the flat space was not scalable, and that it should match hierarchical network number structure. Braden pointed out that there was no hierarchical structure in Internet network numbers; it is a flat space. Ruth Lang commented that it is recognized as an interim scheme to serve current needs. The question of how to name networks was raised. Einar suggested that network names were user friendly, and the NICs names would be bad choices. Mark pointed out that most networks do not have official names, and using an ad hoc name for the RDN was not suitable. Kille questioned whether numbers were more friendly than network names. He pointed out that network numbers were not technologically independent, and expressed concern that this could lead to inconsistent naming of networks. Hotz commented that the lack of network names was perhaps a more general problem that the Internet needed to address. A mechanism for mapping network numbers to names exists within the DNS, but is not frequently used. Einar suggested that the network number be used as the RDN, and the name be included for searching. Kille suggested that the opposite would work just as well, and would make for more user-friendly names. This is to be discussed further off-line. 11.3 NADF-123 This was discussed somewhat during the NADF report. Kille remarked that using the old structure (civilian infrastructure) could put entities in very unnatural places, making it difficult for those outside the structure to find things. Einar emphasized that everything in the U.S. has a registered name already in the current infrastructure, and that renaming/registration expressly for purposes of directory services would be unlikely. 14 Einar pointed out that the underlying notion is that the right to register and obtain a name is different the the right to be listed in parts of the DIT. Organizations will naturally want to be listed in the places where others will look for them. Kille commented that he would like to see experience with this architecture before incorporating it into the naming guidelines. 12 DISI and OSI-DS Knopper raised question regarding the roles of both groups. Kille responded that he sees DISI tackling operational issues, technical administration and issuing related technical specifications. OSI-DS deals with technical issues related to DS. 13 Meeting Administrivia Steve Kille asked for comments about the usefulness of the videoconference meeting. Bob Braden said that this videoconference was unusually bad. Usually a videoconference rates a 7 or 8 on a scale from 1 (email) to 10 (in person), this one only rated a 4. Most other comments ranked the videoconference somewhere between email and in person. Opinions varied on its usefulness compared to a phone conference. One of the UCL folks commented that traveling to a teleconference site was unsatisfying, particularly with the quality of this one. If one had to make the effort to travel, one might as well meet in person. This raised the subject of U.S./European collaboration. Someone noted that IETF meetings are rather well attended by Europeans, but conferences and working group meetings in Europe do not receive a similar level of U.S. participation. Braden pointed out that many U.S. participants traveled on government funds, and that the cost of European trips is, unfortunately, not viewed in a particularly favourable light. Steve Kille will take comments about the videoconference into consideration when deciding if and when it would be appropriate again. 15 To wind up there was a discussion to see if people thought the meeting useful. BBN: Not as good as a face to face meeting, but better than email. RIACS: might be more effective to choose a few items and discuss to focus on the issues. ISI (Bob): Technical quality apalling - too much delay. Echo annoying. Sound poor. Scale: email -- 1, in person -- 10, then generally video -- 7, but this time -- 4 due to the delay and quality. on line terminal may help. UCL (SEK): ``interesting'', some useful discussion. Presentations did not work. If too technical interchange did not work. 14 AOB DUA on VMS -- one will be publically available soon. It was developed in Spain. 15 Next Meeting THis will be at the IETF Meeting in Atlanta, in the week of 29th July. 16 16 Peronsal Comments on the meeting 16.1 Colin Robbins The delay and quality made it very hard to hold a real meeting. Use of video circuits would clear much of the delay and improve quality (but higher cost). Unless you knew the people at the remote end it was not possible to determine who was speaking (on occasions from where as well). Adding Mark Knopper by phone probably work the best. People always ``gave way'' to him to allow him to speak. Questions were directed at him. This seems to imply there was a sort of auto-floor control taking place. Perhaps a more form floor control mechanism would help the video meeting. I wounder if using a phone conference for audio would help. This would clear the audio delay significantly, and may help quality. It may give a weird interaction though. From memory - the picture were in sort of colour. I wonder if having higher quality black and white would help. I don't think the overhead camera would have been any use unless the remote ends also have copies of the document. I would like to have seen an image of the whole conference on one of the three monitors in front of the desk. The ``audience'' monitor was of little use. 16.2 Steve Titcombe Quality of sound The sound quality was fairly reasonable, from all sites except one, which seemed to have electronic bubble noises popping and bursting very time someone from that site talked. This was not too annoying, but it did mean that you had to listen carefully to hear what was being said. There was about a one second delay echo of anything said from UCL that was audible at UCL and very audible at other sites. The echo did cause some major problems with ordering who was talking. It also got fairly chaotic at times when everyone started talking at once, or people were chattering in the background. Quality of Pictures Picture quality at the UCL site was very good, the screen monitoring what was being broadcast out was very good. 17 Other sites pictures were pretty good, but when split down into a 2x2 grid for four sites, it was possible to see if someone had a beard or not, but no more. (This was referring to their shots of an entire room.) This was not too important in itself, but it made life difficult when trying to work out who was talking at a site, and sometimes which site was talking. The picture quality of our site on the 2x2 screen was noticeably worse than the other sites. Placing a black biro drawing on a blank sheet of paper was recognisable at other sites, but we would not have known this as our picture was not. Improvements? Some method of communication would have to be established, as at times, there was so much talking going on, everything merged into a raucous cacophony. A microphone switch at each site would be a great improvement to cutting out background chatter and private comments, letting the speaker "engage" the microphone at his site. This would cut out the feedback of your jokes being good or not, but... This should not prevent four people, one from each site, all bickering over a contentious point. On starting to speak, an announcement of who is speaking, from which site, and a hand wave to show which person on the screen. (Wild gesticulations while talking would also help...) Upon finishing speaking, a very obvious statement indicating the termination of desire to speak should be issued. (Over and out. Finished.) Having an elected chairman for the conference meeting who tries to impartially include the viewpoint of everyone in a discussion. There should also be a "sub-chairman" at each site to whom you can put in a request to take control of the mike, and put a query flag up. If a global question is thrown open, the enquirer should offer the question to the next site, and the remaining sites should progress round in an order decided at the start of the session. (For example, UCL, BBN, RIACS, ISI) The next site should be ready to pick up and reply to the question, without having to wait for the delays of being invited to speak by the chairman. If a point is not understood, disagreed upon, or incorrect, a VISUAL flag should be signalled, rather than have everyone shout furiously simultaneously. Some formal "pushing the current status onto the stack" should be performed, ie "Mr Barker answering the question X set by ISI, with BBN yet to speak." Then the chairman can proceed round asking each site for their reason of interruption. If someone else mentions your query, remove the visual flag. Once the point has been discussed, restate the question, and the "stack", and let the person continue. (This part really did slow our video conference down in places, sometimes minutes were spent trying to re-establish where we were and who was talking.) 18 Good or bad/Feelings The conference is something that I would have never been able to go to normally, and it was far easier to follow the discussions there, than 10 e-mail threads simultaneously. I found the quality of sound a little low occasionally, and that I was having to listen carefully, but more annoying was trying to work out who was talking. No doubt this would have been easier if I knew everyone at the conference and what their particular views were. I found the meeting far more relaxed than any full size all-person attendance meeting, because you could go grab a cup of coffee, or "dispose of one", pop back and ask your neighbour if you had missed anything. I had the feeling that it was like watching your Grans favourite film at Christmas, respect and courtesy had to be shown, but if you had to do something, you could. I was surprised that with all the TV screens around, that we only had 2 screens in use, one for our outgoing picture, and one incoming for the conference. It would have been good to have a screen for the outgoing, a screen for the incoming whole conference, a screen of the current speakers channel, and a screen for some notes or doodles. The last one could possibly be on a workstation, running wscrawl, an n-person doodle screen running across the network. 16.3 Einar Stefferud First, it well was worth it to help build understanding across the Atlantic. We need to reach out to make the our European colleagues feel fully welcome in the INTERNET community, and we have ample evidence that Eropeans in the IETF-SMTP/822 discussions seem to feel otherwise. It is not easy to use any kind of graphical exchange, unless it is done with the WorkStations that I understrand are installed at each site. (Does this include UCL?) It does not work to show view graphs on the regular Video Screen. The resolution is not good enough to see anything from a normal viewgraph. (Just a feature of this particular facility.) The video is very slow, and acts more like slow scan, when linked among UCL, BBN, RIACS and ISI. (e.g., I could not watch lips moving.) Motion seems to stop competely at times. I understand that this is a result of some differences between the UCL installed equipment and the equipment at BBN, ISI, RIACS, or ARPA, which required us to run the VidConf through BBN as a HUB which meant that the signals had to go twice over the Atlantic (or something like this) for some reason. Bob Braden might be able to explain this point (better than I). 19 I would suggest that we have a clear agenda, with clearly identified documents whose numbers relate to the agenda items, so we can always get a solid cite for what each speaker is referring to when making comments. Looking at the text of one of documents on the workstation screens, with the speaker doing the pointing would be a good idea. We should avoid verbal status reports of sub group activities. Such reports should be circulated by netmail in advance of the VidConf. We should make an effort to let everyone speak so we can get to know each other better. With some efforts to "do it right" it should be very worthwhile. 16.4 Steve Kille I believe that the meeting was useful, although it did not fulfill all expectations. The long delays were a serious problem. I found the meeting very stressful to chair, despite a very high level of cooperation from each site. The approach of identifying a co-ordinator at each site was useful. Asking for comments in order around the sites proved to be a necessary approch. Getting minutes taken at each site was a disaster. The major reason for the delay in producing these minutes was the problem of merging four similar but different pieces of text. There should only be one minute-taker, perhaps supplemented by notes from each site. Comments on the videoconference were provided by a number of people, and this was useful. 20   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19156-0@bells.cs.ucl.ac.uk>; Fri, 28 Jun 1991 14:57:32 +0100 To: osi-ds@uk.ac.ucl.cs cc: Rob Hagens , Ross Callon , Megan Davies Subject: Draft Agenda for OSI-DS Phone: +44-71-380-7294 Date: Fri, 28 Jun 91 14:57:28 +0100 Message-ID: <1740.678117448@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Here is the first draft of the Agenda. Please let me have comments. I hope that the exact date of the meeting will be finalised soon. I will let you know when this has happended. Steve Agenda for fifth meeting of IETF Directory Services Group S.E. Kille June 28, 1991 Date Week of 29th July Tentatively on Monday 29th July (2 sessions) Venue IETF Bell South Atlanta, GA Draft agenda follows. 1 Session 1 0:00 Introduction o Agenda o Minutes of previous meeting o Matters arising 0:30 Liaisons o RARE WG3 o ISO/CCITT o NIST o NADF 1:00 Document progress (report from OSI Area Directors/ IESG representative) 1 1:30 Requirements Specification (review of new document) 1:45 Operational status of pilots 2 Session 2 0:00 Resource description (new I-D) 0:30 NIC Profile information (new I-D) 0:45 Representing Pictures in the directory (Russ Wright) 1:05 Naming Guidelines (review I-D) 1:35 DSA Naming (review of I-D) 1:50 AOB 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <590-0@bells.cs.ucl.ac.uk>; Tue, 2 Jul 1991 11:26:27 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Document numbers Phone: +44-71-380-7294 Date: Tue, 02 Jul 91 11:26:25 +0100 Message-ID: <979.678450385@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I have updated the index to give all of the OSI-DS documents numbers, as agreed at the videoconference. The text of the documents will acquire numbers as they get revised. I have give Chris + Mark's two documents numbers. Would anyone else submitting OSI-DS documents get a number from me first? Steve INDEX OF IETF OSI DS Documents (OSI-DS 0) July 1991 The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All docuents are numbered, in the form OSI-DS nnn The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX OSI-DS 0 index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP OSI-DS 1 scope.ps scope.txt IETF Directory Working Group Scope (Version 4) S.E. Kille December 22, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER OSI-DS 2 charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS minutes-1-oct90.txt 1st Meeting, San Jose, Oct 90 minutes-2-dec90.txt, ps 2nd Meeting, Boulder, Dec 90 minutes-3-feb91.txt 3rd Meeting, SRI, Feb 91 ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS OSI-DS 3 strategy.txt strategy.ps A proposed strategy for deploying an OSI Internet Directory S.E. Kille March 1991 Abstract: This document is a first cut at describing an overall strategy for deploying an OSI Directory on the Internet. This is a draft document, and does not carry any implications of agreement on policy. OSI-DS 4 goals.txt goals.ps Overall plan of the IETF Working Group on OSI Directories (OSI-DS) to build an Internet Directory using X.500 S.E. Kille February 1991 Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b]. This document summarises the plan established by the working group to achieve this, and describes a number of RFCs which the working group will write in order to establish the technical framework. This document has now been submitted as an RFC OSI-DS 5 nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille draft-ucl-kille-networkaddresses-02.txt, .ps January 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88 ] [ISO87a ]. The OSI Directory, and any OSI application utilising the OSI Directory must be able to deal with these Network Addresses. Currently, most environments cannot cope with them. It is not reasonable or desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to have to wait for the lower layers to sort out. This note is a proposal for mechanisms to utilise Network Addresses. OSI-DS 6 string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-02.txt, ps S.E. Kille November 1990 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. OSI-DS 7 domain.ps domain.txt Domains and X.500 S.E. Kille March 1991 Filename : draft-ucl-kille-x500domains-03.txt, or .ps Abstract: This INTERNET--DRAFT considers X.500 in relation to Internet and UK Domains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. OSI-DS 8 ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille March 1991 draft-ietf-osids-friendlynaming-02.txt, or .ps Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. OSI-DS 9 repl-req.ps repl-req.txt Replication Requirement to provide an Internet Directory using X.500 S.E. Kille March 1991 draft-ietf-osids-replication-02.txt, .ps Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90 ]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This INTERNET--DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. OSI-DS 10 na.txt P. Barker S.E. Kille March 1991 The COSINE and Internet X.500 Schema draft-ietf-osids-cosinex500-03.txt Abstract: This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema This document also proposes a mechanism for allowing the schema to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, and comments on the updating mechanisms are particularly welcome. Corrections and additions to the schema should now be sent the list, as described within. OSI-DS 11 repl-sol.ps Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Kille March 1991 draft-ietf-osids-replsoln-02.txt, or .ps Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point. OSI-DS 12 structure.ps structure.txt P. Barker S.E. Kille February 1991 Naming Guidelines for Directory Pilots draft-ietf-osids-dirpilots-00.txt, .ps Abstract: Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. OSI-DS 13 dsanaming.ps dsanaming.txt DSA Naming S.E. Kille March 1991 draft-ietf-osids-dsanaming-00.txt, or .ps Abstract: This INTERNET--DRAFT describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot. I believe this note to be an important step forward, as it begins to evolve a clear model of a Directory Management Domain. OSI-DS 14 contacts.txt Internet Network Infrastructure Information In X.500 C. Weider M. Knopper March 1991 Abstract: As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory Information, it was perceived that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. This paper describes the interim schema used to contain this information. OSI-DS 15 qos.ps qos.txt Handling QOS (Quality of service) in the Directory S.E. Kille March 1991 draft-ietf-osids-qos-00.txt,.ps Abstract: This document describes a mechanism for specifying the Quality of Service for DSA Operations and Data in the Internet Pilot Directory Service [Kil90]. OSI-DS 16 nic-profile.txt Schema for NIC Profile information in X.500 Chris Weider Mark Knopper June 1991 Abstract: The authors wish to put put up a readily accessible, distributed Directory of Network Information Centers, or NICs. This paper discusses the schema used to hold the NIC Profiles, as well as the DIT structure necessary for this information. OSI-DS 17 resource-schema.txt Schema for Information Resource Description in X.500 Chris Weider May 1991 Abstract: The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. ------------------------------------------------------------------------   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4283-0@bells.cs.ucl.ac.uk>; Tue, 2 Jul 1991 13:31:56 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Directory Requirements Phone: +44-71-380-7294 Date: Tue, 02 Jul 91 13:31:56 +0100 Message-ID: <1175.678457916@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I append a first draft in this message. Assuming that not TOO many rocks are thrown at me, I will revise this and submit as in Internet Draft. I will do this in a week's time. Steve Network Working Group S.E. Hardcastle-Kille INTERNET--DRAFT University College London March 1991 Directory Requirements for COSINE and Internet Pilots Status of this Memo This document specifies operational requirements for DUAs and DSAs in the Internet and COSINE communities. This document summarises conformance requirements. In most cases, technical detail is handled by reference to other documents. This document refers to core directory infrastructure. Each application using the directory may impose additional requirements. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT Directory Requirements March 1991 1 General The following documents are relevant to this requirements specification. It is assumed that Internet Drafts will be RFCs by the time that this document is an RFC. Each document is given a keyword, which is used to refer to it in the text. These will be replaced by RFC references in the final document. X.500 The OSI Directory is defined in [CCI88]. Overview The technical framework for the remainder of the documents is given ins [Kil90a]. Schema The COSINE and Internet X.500 Schema is defined in [BK91a]. Naming Guidelines Naming guidelines are given in [BK91b]. Extensions A number of extensions to the OSI Directory, relating to distributed operations and replication are defined in [Kil91c]. DSA Naming An approach to DSA Naming is defined in [Kil91a]. NSAP Approach An approach to handling network addresses is defined in [Kil89a]. RFC 1006 The mapping of COTS onto TCP/IP is defined in RFC 1006 [RC87]. PSAP String A string representation of presentation addresses is defined in [Kil89b]. UFN A string representation of directory names is defined in [Kil90b]. QOS A definition of Quality of Service is defined in [Kil91b]. Security Need something on security guidelines. A number of lower layer options are possible to provide COTS. These are: CONS TP0--TP4 over CONS CLNS TP4 over CLNS RFC 1006 RFC 1006 used to provide COTS over TCP/IP Hardcastle-Kille Page 1 INTERNET--DRAFT Directory Requirements March 1991 X.25 TP0 over X.25(80) or X.25(84) without use of extended addressing to provide CONS. The first three are global services. Where X.25 is used without qualification, use of the international X.25 services is implied. If IXI is used, this is referred to as X.25/IXI. In the case of RFC 1006 and X.25, network addresses shall be represented according to (NSAP Approach). 2 DIT Conformance This section refers to that portion of the DIT which is managed by systems which claim conformance to this specification. All non-leaf entries shall be labelled with data quality as defined in (QOS). All entries shall conform to X.500 schema requirements. All entries shall conform to (Schema), with the exception of parts of the tree where the data is marked as ``experimental''. 3 DUA Conformance 3.1 DSA Access A DUA may operate over any lower layer stack. Each conforming DUA shall have a service agreement with at least one DSA. At least two DSAs is recommended. It is recommended that DUAs access DSAs using X.500 DAP over COTS, based on CLNS, CONS, RFC 1006, or X.25. Support of DAP and multiple means to support COTS will maximise potential use of DSA referral. DUAs may access DSAs by private (local) protocols. 3.2 Distributed Operation DUAs may optimise their performance based on (Extensions). DUAs may optimise their performance based on (QOS). Hardcastle-Kille Page 2 INTERNET--DRAFT Directory Requirements March 1991 3.3 Presentation of Information The DUA shall provide an option to present Distinguish Names as defined in (UFN). It is recommended that support be given for the search algorithms described in (UFN). If presentation addresses are displayed, the syntax defined in (PSAP String) shall be used. DSA Names and addresses should not usually be displayed to users. 4 DSA Conformance 4.1 Protocol DSAs shall support DAP and DSP as defined in X.500. DSAs shall support Internet DSP as defined in (Extensions). 4.2 Lower Layers There will be use of different lower layers in different pilots. In order to provide a single global directory, it is important that there is sufficient commonality, and "relay DSAs" to provide a single global directory. All participants need to work towards this. A pilot is synonymous with a DMD. A DMD (pilot) is self declared. An example pilot is the UK Academic community pilot. The lower layer policy within a pilot is the concern of that pilot. There is an Internet Pilot, represented by FOX. DSAs within this DMD shall support RFC 1006, and are recommended to support CLNS. Every pilot, including the Internet Pilot, must provide connectivity to the following lower layers. Where a lower layer is not required on all DSAs in the pilot, relay DSAs shall be provided to give the required connectivity. X.25 Required for all pilots (this is expected to become optional when CONS is widely available) RFC 1006 Required for all pilots Hardcastle-Kille Page 3 INTERNET--DRAFT Directory Requirements March 1991 X.25/IXI Recommended for all pilots (this is expected to become optional when CONS is widely available) CONS Recommended for all pilots (this is expected to be mandatory later) CLNS Recommended for all pilots (this is expected to be mandatory later) 4.3 DSA Naming To facilitate management, DSAs shall be named as defined in (DSA Naming). 4.4 Schema DSAs shall allow any data which conforms to (Schema) to be stored. References [BK91a] P. Barker and S.E. Kille. The COSINE and Internet X.500 schema, March 1991. [BK91b] P. Barker and S.E. Kille. Handling qos (quality of service) in the directory, March 1991. Internet Draft: draft-ietf-osids-dirpilots-00.txt,.ps. [CCI88] The Directory --- overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations. [Kil89a] S.E. Kille. An interim approach to use of network addresses. Research Note RN/89/13, Department of Computer Science, University College London, February 1989. Internet Draft: draft-ucl-kille-networkaddresses-02.txt, ps. [Kil89b] S.E. Kille. A string encoding of presentation address. Research Note RN/89/14, Department of Computer Science, University College London, February 1989. Internet Draft: draft-ucl-kille-presentationaddress-01.txt, ps. [Kil90a] S.E. Kille. Building and internet directory using X.500, November 1990. Internet Draft: draft-ietf-osix500-directories-01.txt. Hardcastle-Kille Page 4 INTERNET--DRAFT Directory Requirements March 1991 [Kil90b] S.E. Kille. Using the OSI directory to achieve user friendly naming. Research Note RN/90/29, Department of Computer Science, University College London, February 1990. [Kil91a] S.E. Kille. Dsa naming, March 1991. Internet Draft: draft-ietf-osids-dsanaming-00.txt,.ps. [Kil91b] S.E. Kille. Handling qos (quality of service) in the directory, March 1991. Internet Draft: draft-ietf-osids-qos-00.txt,.ps. [Kil91c] S.E. Kille. Replication and distributed operations extensions to provide an internet directory using X.500, January 1991. Internet Draft: draft-ietf-osids-replsoln-02.txt, ps. [RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services on top of the TCP. Request for Comments 1006, DDN Network Information Center, SRI International, May 1987. 5 Security Considerations Security considerations are not discussed in this INTERNET--DRAFT . 6 Author's Address Steve Hardcastle-Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Hardcastle-Kille Page 5   Return-Path: Received: from kwai.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <7143-0@bells.cs.ucl.ac.uk>; Tue, 2 Jul 1991 14:36:22 +0100 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 02 Jul 91 15:33:43+0200 Date: 02 Jul 91 15:33:43+0200 From: Christian Huitema Message-ID: <9107021333.AA01098@mitsou.inria.fr> To: osi-ds@fr.reunir.sunir ,C: osi-ds@cs.ucl.ac.uk ,Ubject: Re: Directory Requirements ,N-Reply-To: Your message of 02 Jul 91 13:31:56 +0100. <1175.678457916@UK.AC.UCL.CS> ,Ate: Tue, 02 Jul 91 15:33:33 BST ,Rom: Christian Huitema , Steve, I hope you will see this as comments, not rocks... Christian Huitema ------------------------------------------------------------------------------ >The DUA shall provide an option to present Distinguish Names as >defined in (UFN). I have a technical problem here. The UFN format is not designed to support "Distinguished names", but rather untagged, weakly structured, not necessarily uniques "user friendly names". I have some sympathy for the search algorithm that you describe and for the general idea of supporting a single line form, but we should not confuse the problems. My distinguished name should be something like: < C=FR; O=INRIA; CN=Christian Huitema;> i.e. the attribute types should be apparent -- and some compatibility with the notation of X.400 addresses could not hurt. Also, the unique notation should be capable of delimiting RDNs made of several assertions -- or we should explicitely disallow them in the architecture. >It is recommended that support be given for the search algorithms >described in (UFN). The algorithm described in UFN is useful. However it has implications, like the necessity to conduct highlevel searches, which are not easily met by all directory configurations. Alternative algorithms can be studied, which can yeld better performances -- I would rather call it a research topic than a requirement! >4.2 Lower Layers > >There will be use of different lower layers in different pilots. This is an Internet draft. It should describe the requirements on the now TCP-IP, later multi-protocol Internet. In clear, it should mandate RFC-1006 and later TP4/CLNS. References to other protocols like X.25, IXI and CONS should be placed in a annex, not in the document body.   Return-Path: Received: from chx400.switch.ch by bells.cs.ucl.ac.uk with SMTP inbound id <28276-0@bells.cs.ucl.ac.uk>; Wed, 3 Jul 1991 14:03:29 +0100 X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Wed, 3 Jul 1991 15:03:00 +0200 X400-Received: by /PRMD=UBS/ADMD=ARCOM/C=CH/; Relayed; Wed, 3 Jul 1991 15:54:56 +0200 Date: Wed, 3 Jul 1991 13:03:00 +0000 X400-Originator: Armin.Hersperger@ch.arcom.UBS.UBS.ZH007 X400-MTS-Identifier: [/PRMD=UBS/ADMD=ARCOM/C=CH/;910703145456] X400-Content-Type: P2-1984 (2) Content-Identifier: 175 Conversion: Prohibited From: Armin Hersperger Message-ID: <175*/G=Armin/S=Hersperger/OU=ZH007/O=UBS/PRMD=UBS/ADMD=ARCOM/C=CH/@MHS> To: osi-ds Subject: DF Documents July 3, 1991 The Directory Forum - Documents This is a question to the postmaster because I simply do not know where else to send it: Are the documents produced by "The Directory Forum" available on a node through X.400 or interactivly thru Internet. I have access to the osi-ds directory on cs.ucl.ac.uk. Thank you very much for your cooperation. A.Hersperger   Return-Path: Received: from thumper.bellcore.com by bells.cs.ucl.ac.uk with SMTP inbound id <29459-0@bells.cs.ucl.ac.uk>; Wed, 3 Jul 1991 20:21:16 +0100 Received: from latour.bellcore.com by thumper.bellcore.com (4.1/4.7) id for osi-ds@cs.ucl.ac.uk; Wed, 3 Jul 91 15:21:27 EDT Received: by latour.bellcore.com (4.12/4.7) id for quipu@cs.ucl.ac.uk; Wed, 3 Jul 91 15:21:25 edt Date: Wed, 3 Jul 91 15:21:25 edt From: sywuu@com.bellcore.thumper (Sze-Ying Wuu) Message-Id: <9107031921.AA13654@latour.bellcore.com> To: disi@edu.merit, osi-ds@uk.ac.ucl.cs Subject: xdi - a DUA implementation Cc: quipu@uk.ac.ucl.cs A beta release of a X.500 DUA implementation, xdi, is available via anonymous FTP on thumper.bellcore.com in pub/xdi.tar.Z. Source code and executables can be freely distributed for non-commercial and non-profit use. The xdi implementation was inspired from the Quipu and Pod implementations of ISODE release 6.8. It was originally done for an internal experimental protype which is slightly different from this public release. It has been compiled and tested in SunOS environment. In addition to providing a user-friendly interface, xdi supports Directory interactions of different levels of complexity. It is simple to use for novice users but is also useful to formulate complex queries. Xdi accepts "user-friendly names" in most cases. There are two different search screens to do name based search and attribute based search. Attribute based search screen is useful to do search filtering on attribute information, or to use attribute information to disambiguate a common name. It also allows DISH-like filters where complex queries can be done by logical expressions. The ISODE 6.8 libraries, X11R4, the associated X toolkit and Athena widget libraries are required to install and run xdi. No support and warranty will be provided for xdi. However, bugs report are still welcome. Sze-Ying -------------------------------------------------------------------- Sze-Ying Wuu Voice:(201)829-5201 Internet:sywuu@thumper.bellcore.com UUCP:bellcore!thumper!sywuu"   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <16976-0@bells.cs.ucl.ac.uk>; Thu, 4 Jul 1991 09:29:15 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Meeting dates in Atlanta Phone: +44-71-380-7294 Date: Thu, 04 Jul 91 09:29:10 +0100 Message-ID: <730.678616150@UK.AC.UCL.CS> From: Steve Hardcastle-Kille The OSI-DS meeting will be on Monday 29th July, in morning and early afternoon. DISI will be late afternoon. I will send a revised agenda next week. Steve   Return-Path: Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <11322-0@bells.cs.ucl.ac.uk>; Fri, 5 Jul 1991 12:49:00 +0100 Received: from mcsun by kestrel.Ukc.AC.UK with UUCP id aa23076; 5 Jul 91 12:44 BST Received: from corton.inria.fr by mcsun.EU.net with SMTP; id AA08875 (5.65a/CWI-2.96); Fri, 5 Jul 91 13:34:57 +0200 Received: from edfder1.UUCP by corton.inria.fr (5.65c+/90.0.9) via Fnet-EUnet id AA03921; Fri, 5 Jul 91 12:31:02 +0200 (MET) Received: from cli53an.edf.fr by edfder1.edf.fr, Fri, 5 Jul 91 12:23:31 +0200 Received: from loghost by cli53an.edf.fr (4.0/SMI-4.0) id AA09294; Fri, 5 Jul 91 12:26:53 +0200 To: sywuu@com.bellcore.thumper Cc: isode@mil.ddn.nic, osi-ds@uk.ac.ucl.cs, art-dir@fr.cnet.lannion Subject: Xdi beta Reply-To: sylvain@fr.edf.cli53an Date: Fri, 05 Jul 91 12:26:52 +0200 Message-Id: <9293.678709612@cli53an> From: Sylvain Langlois the XDI tar image available on thumper is buggy. 1) Some bitmaps are missing: Keep and KeepPress can be found in the Pod subdirectory of the ISODE release. Print and PrintPress do not exist at all. 2) routine "strlower" is not defined. 3) "make" file is incorrect. the XDI subtree should be placed in the isode**/others/quipu/uips directory. You will find below something you can give to patch in order to fix "make" and "filt.c". By the way (not surprising) XDI seems to work fine on the latest ISODE beta release as far as I have been able to test. *** make Fri Jul 5 11:18:48 1991 --- make~ Mon Jun 24 19:04:42 1991 *************** *** 4,7 **** M=/usr/bin/make fi ! exec $M TOPDIR=../../../../ -f ../../../../config/CONFIG.make -f Makefile ${1+"$@"} --- 4,7 ---- M=/usr/bin/make fi ! exec $M TOPDIR=../../../../ -f ./CONFIG.make -f Makefile ${1+"$@"} *** filt.c Fri Jul 5 12:18:55 1991 --- filt.c~ Mon Jul 1 20:30:15 1991 *************** *** 682,706 **** } - /* strlower() was missing in the beta-version: here it is... - * sylvain@cli53an.edf.fr - */ - char * - strlower(string) - char *string; - { - - char *c; - - for (c = string; (*c != '\0'); c++) { - if (isupper(*c)) - *c = tolower (*c); - } - - return(string); - - } - /************************************************************************/ /* Attr_Sequence make_as_item(stroid) */ /* creates attribute sequence for stroid */ --- 682,687 ---- Sylvain ---------------- Sylvain Langlois "Dogmatic attachement to the supposed merits (sylvain@cli53an.edf.fr) of a particular structure hinders the search of an appropriate structure" (Robert Fripp)   Return-Path: Received: from skinfaxe.diku.dk by bells.cs.ucl.ac.uk with SMTP inbound id <14489-0@bells.cs.ucl.ac.uk>; Fri, 5 Jul 1991 14:31:41 +0100 Received: by skinfaxe.diku.dk id AA08424 (5.65+/IDA-1.3.5 for osi-ds@cs.ucl.ac.uk); Fri, 5 Jul 91 15:31:11 +0200 Message-Id: <9107051331.AA08424@skinfaxe.diku.dk> To: sylvain@fr.edf.cli53an Cc: sywuu@com.bellcore.thumper, isode@mil.ddn.nic, osi-ds@uk.ac.ucl.cs, art-dir@fr.cnet.lannion Subject: Re: Xdi beta In-Reply-To: The message from sylvain@cli53an.edf.fr of Fri, 05 Jul 91 12:26:52 +0200. <9293.678709612@cli53an> Date: Fri, 05 Jul 91 15:31:11 +0200 From: Steen Linden >the XDI tar image available on thumper is buggy. >1) Some bitmaps are missing: Keep and KeepPress can be found in the Pod > subdirectory of the ISODE release. Print and PrintPress do not exist at all. The bitmaps are not missing. They are not used. It is the depend specifications in the Makefile that are wrong. Make some new with e.g. cc -M. Regards, Steen Linden The Computer Department Dept. of Computer Science (DIKU) University of Copenhagen Denmark   Return-Path: Received: from thumper.bellcore.com by bells.cs.ucl.ac.uk with SMTP inbound id <17301-0@bells.cs.ucl.ac.uk>; Fri, 5 Jul 1991 15:44:57 +0100 Received: from kirby.bellcore.com by thumper.bellcore.com (4.1/4.7) id for osi-ds@cs.ucl.ac.uk; Fri, 5 Jul 91 10:45:02 EDT Received: by kirby.bellcore.com (5.57/4.7) id AA08893; Fri, 5 Jul 91 10:44:58 -0400 Date: Fri, 5 Jul 91 10:44:58 -0400 From: sywuu@com.bellcore.thumper (Sze-Ying Wuu) Message-Id: <9107051444.AA08893@kirby.bellcore.com> To: anubis@dk.diku.skinfaxe, sylvain@fr.edf.cli53an Subject: Re: Xdi beta Cc: Damanjit.Mahl@uk.ac.brunel, art-dir@fr.cnet.lannion, brian@au.csiro.dit.mel, getchell@gov.nersc.jasmine, isode@mil.ddn.nic, karen@uk.ac.rutherford.informatics, klunder@nl.TUDELFT.RC, osi-ds@uk.ac.ucl.cs, sywuu@com.bellcore.thumper Sorry for the bugs in the distribution. I wasn't aware of the bugs because this is a different version than what is used internally. I tried to clean out the bitmaps after I tested compilation of the public release. The bitmaps that are missing in the Makefile are not used and should be deleted from the Makefile. Obviously I did not clean it completely. The routine strlower() was added to the common library internally. Hence, I could compile and link without any problems. I forgot that other people would not have that. I have moved the routine to util.c. Thank you for the reports and suggestions of the patches. I apologize for the mistakes. A new xdi.tar.Z is now available with the fixes. This time I did try to compile again to see all the fixes are good. Sze-Ying   Return-Path: Received: from nisc.psi.net by bells.cs.ucl.ac.uk with SMTP inbound id <5998-0@bells.cs.ucl.ac.uk>; Sat, 6 Jul 1991 19:45:24 +0100 Date: Sat, 6 Jul 91 14:43:22 -0400 From: adams@net.psi.nisc (Mark Adams) Received: by nisc.psi.net (5.61/2.1-PSINet Operations ) id AA07587; Sat, 6 Jul 91 14:43:22 -0400 Message-Id: <9107061843.AA07587@nisc.psi.net> To: osi-ds@uk.ac.ucl.cs Subject: FOX and X.500 Cc: adams@net.psi.nisc Hi, I would like to receive information on developments as noted in LinkLtr 4.2 Thankyou, Mark Adams adams@psi.com   Return-Path: Received: from relay.tek.com by bells.cs.ucl.ac.uk with SMTP inbound id <13832-0@bells.cs.ucl.ac.uk>; Mon, 8 Jul 1991 17:07:06 +0100 Received: by relay.tek.com id ; Mon, 8 Jul 91 09:07:26 -0700 Received: from zephyr.ENS.TEK.COM by tektronix.TEK.COM (4.1/7.1) id AA14428; Mon, 8 Jul 91 09:07:19 PDT Received: from cascade.ENS.TEK.COM by zephyr.ENS.TEK.COM (4.1/7.1) id AA05987; Mon, 8 Jul 91 09:07:18 PDT Received: by cascade.ENS.TEK.COM (4.1/7.1) id AA15986; Mon, 8 Jul 91 09:01:42 PDT Message-Id: <9107081601.AA15986@cascade.ENS.TEK.COM> To: osi-ds@uk.ac.ucl.cs Subject: X.500/FOX Mailing List Registration Date: Mon, 08 Jul 91 09:01:42 PDT From: Dennis Thomas - Computer Network Support Please add me to your mailing list. Thanks Dennis Thomas Tektronix, Inc. dennist@tektronix.TEK.COM   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <250-0@bells.cs.ucl.ac.uk>; Tue, 9 Jul 1991 11:13:27 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Agenda - Version 2 Phone: +44-71-380-7294 Date: Tue, 09 Jul 91 11:13:25 +0100 Message-ID: <976.679054405@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Here is the revised agenda. Please make sure you bring the relevant documents with you! Steve Agenda for fifth meeting of IETF Directory Services Group Version 2 S.E. Kille July 9, 1991 Date Monday 29th July, 9:30 -- 15:30 Venue IETF Bell South Atlanta, GA Draft agenda follows. 1 Session 1 9:30 Introduction o Agenda o Minutes of SRI Meeting (OSI-DS-MINUTES 3) o Minutes of Videoconference (OSI-DS-MINUTES 4) o Matters arising 10:00 Liaisons o RARE WG3 (Erik Huizer) o ISO/CCITT (?) o OIW (Russ Wright) o NADF (Marshall Rose) 1 10:25 Operational status of pilots o FOX (Steve Hotz) o PSI WPP (?) o Paradise (Steve Kille) o AARN (?) Note: If the first part of the agenda is completed early (which will happen if possible), we will start on the agenda for Session 2. 10:45 Coffee 11:00 Document progression to RFC. (Ross Callon/Vint Cerf) 11:20 OID assignment, Delegation of Schema Authority, OID Changes. (OSI-DS 10, RFC 1239) 11:40 Requirements Specification (OSI-DS 18) 12:00 Lunch 2 Session 2 13:30 Resource description (OSI-DS 17) 14:00 NIC Profile information (OSI-DS 16) 14:15 Representing Pictures in the directory (Russ Wright) 14:40 Quality of Service (OSI-DS 15) 15:00 Naming Guidelines (OSI-DS 12) 15:10 DSA Naming (OSI-DS 13) 15:20 AOB 15:30 End (Tea) 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <1252-0@bells.cs.ucl.ac.uk>; Tue, 9 Jul 1991 11:44:32 +0100 To: osi-ds@uk.ac.ucl.cs Cc: internet-drafts@us.va.reston.nri Subject: Directory Requirements for COSINE and Internet Pilots Phone: +44-71-380-7294 Date: Tue, 09 Jul 91 11:44:30 +0100 Message-ID: <1113.679056270@UK.AC.UCL.CS> From: Steve Hardcastle-Kille The revised version of this document is now in the archives, and is being submitted as an Internet Draft. Steve OSI-DS 18 requirements.ps requirements.txt Directory Requirements for COSINE and Internet Pilots Steve Hardcastle-Kille July 1991 Abstract: This document specifies operational requirements for DUAs and DSAs in the Internet and COSINE communities. This document summarises conformance requirements. In most cases, technical detail is handled by reference to other documents. This document refers to core directory infrastructure. Each application using the directory may impose additional requirements. The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from america.ecn.purdue.edu by bells.cs.ucl.ac.uk with SMTP inbound id <25588-0@bells.cs.ucl.ac.uk>; Tue, 9 Jul 1991 17:30:16 +0100 Received: by america.ecn.purdue.edu (5.65/1.30jrs) id AA05094; Tue, 9 Jul 91 11:30:21 -0500 Date: Tue, 9 Jul 91 11:30:21 -0500 From: simmons@edu.purdue.ecn (William R Simmons) Message-Id: <9107091630.AA05094@america.ecn.purdue.edu> To: disi-request@edu.merit, osi-ds@uk.ac.ucl.cs Subject: request to be added to mail list Cc: simmons@edu.purdue.ecn For those readers interested in following the FOX project and other X.500 activities more closely, two mailing lists are suggested: disi- request@merit.edu and osi-ds@cs.ucl.ac.uk. -Pat Smith, Merit/NSFNET Joyce Reynolds, ISI May I please be added to your mailing list?   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <2957-0@bells.cs.ucl.ac.uk>; Wed, 10 Jul 1991 07:49:33 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Wed, 10 Jul 1991 07:49:47 +0100 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Wed, 10 Jul 1991 07:48:56 +0100 Date: Wed, 10 Jul 1991 08:48:56 +0200 X400-Originator: Lenggenhager@ch.switch.gate X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910710084856] X400-Content-Type: P2-1984 (2) Content-Identifier: 5729 From: Thomas Lenggenhager Message-ID: <5729*/S=Lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: Again: RARE WG3 in Zurich (30.9.-2.10): Hotel Information Hello, nearly one month ago I sent you the following message with the hotel information for the RARE WG3 meeting in Zurich. Now I did check with the two hotels Rex and Ruetli which took block reservations and found out that only very few people reserved there rooms already. *** The block reservations are only valid until end of July! The hotels in *** Zurich are as in most cities very busy in the autumn, so I recommend you *** very urgently to book now. We will not be able to give you much support *** in finding a hotel room shortly before the meeting. ================= Message from June 13, 1991 =============================== We were able to place block reservations in two hotels nearby the meeting room. These reservations are open until end of July. Please say explicetly that you want one of these reservations made under the name 'SWITCH'. For some of you coming from further away, it couldbe probably of interest that in the week after that meeting the Telecom 91 takes place in Geneva. In case you want to spend the few days inbetween somewhere in Switzerland, you could contact one of the following tourist information offices: Tourist Information for Zurich Tel: 41 1 211 40 00 Bahnhofplatz 15 Fax: 41 1 212 01 41 CH-8001 Zurich Swiss Tourist Information Tel: 41 1 288 11 11 Postfach Fax: 41 1 288 12 05 CH-8027 Zurich Shortly before the meeting I will send around the information on how to get from the airport into the city and to the meeting room. (It takes only about 30 to 45 minutes to get from the airport to the meeting room.) Thomas Lenggenhager SWITCH =============================================================================== Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerland INET: lenggenhager@switch.ch | Tel: +41-1-261 8178 | Fax: +41-1-261 8133 X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH =========== (All prices are given in Swiss Francs) *** Hotel Rex (Garni) Tel: 41 1 361 96 46 Weinbergstrasse 92 Fax: 41 1 361 20 47 CH-8006 Zurich Price: 140.00 (5 rooms have twin beds, 5 rooms have "normal beds), bath or shower, taxes, breakfast, service included) 10 Rooms have been booked until July 29, 1991 at the latest. After that day, there will not be any contingent booked for the meeting participants. Please ask for a room booked on behalf of SWITCH. 5 minutes to the meeting room, new, rather large rooms, phone, colour TV *** Hotel Ruetli Tel: 41 1 251 54 26 Zaehringerstrasse 43 Fax: 41 1 261 21 53 CH-8001 Zurich Price: 130.00 (bath or shower, WC, breakfast, taxes, service included). 12 rooms have been booked until July 31, 1991 at the latest. After that day, there will not be any contingent booked for the meeting participants. Please ask for a room booked on behalf of SWITCH. 4 minutes to the meeting room, new rooms, phone, colour TV Other possible hotels: ** Hotel Sunnehus Tel: 41 1 251 65 80 Sonneggstrasse 17 CH-8006 Zurich Price appr. 120 - 140 3 minutes to the meeting room *** Hotel Astor Tel: 41 1 251 35 60 Weinbergstrasse 44 Fax: 41 1 251 49 15 CH-8006 Zurich Price: appr. 150 - 160 rather small rooms one minute to the meeting room *** Hotel Arc Royal Comfort Inn Tel: 41 1 261 67 10 Leonhardstrasse 6 Fax: 41 1 251 47 80 CH-8001 Zurich Price appr. 110 - 140 2 minutes to the meeting room **** Hotel Helmhaus Tel: 41 1 251 88 10 Schifflaendeplatz 30 Fax: 41 1 251 04 30 CH-8001 Zurich Price appr. 140 5 min. ride by tram the hotel is located in the "old" part of the city. ========== ___________________________________________________________________________ Program RARE WG3 meeting 30 sept.-2 oct. 1991 Zurich, Switzerland Zurich, Switch/ETHZ 30 september 1300 DS session, including P2.1 operational meeting 1800 closing 1 october Big room Terminal room Lecture room with video no facilities ------------------------------------------------------ 0900 Paul Barker (UCL/Paradise) Paradise Central DUA 0945 Someone from the US(?) Mac DUA or FOX/WPP status 1030 break 1100 Andrew Findlay (Brunell) Brunell (X)DUA 1145 Graham Knight (Level-7 Ltd) P2.2 Prototype 1300 Lunch PARALLEL SESSIONS: 1400 Tim Berners-Lee (CERN) Colin Robbins (Xtel) Hypertext Tutorial DSA 1500 Steve Benford (Nottingham Univ.) continued Group Communications 1600 Plenary 1700 Drinks Various demo's The various demos would consist of: ETHZ ITAXA DUA for Mac Steve benford Group Communication PSI (?) Mac DUA Tim Howes (?) Mac DUA Brunel DUA's Paul Barker DUA Level-7 P2.2 Celestino Tomas VMS DUA X-tel DUAs Tim Berners-Lee Hypertext next Maria Dimou CERN Directory Joyce Reynolds (?) 2 october 0900 USIS part (maybe parallel some DS demo evaluations) 1600 P2.2 whatever 1800 end of meeting ___________________________________________________________________________   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <27948-0@bells.cs.ucl.ac.uk>; Wed, 10 Jul 1991 13:33:46 +0100 To: osi-ds@uk.ac.ucl.cs cc: internet-drafts@us.va.reston.nri Subject: Two revised I-Ds Phone: +44-71-380-7294 Date: Wed, 10 Jul 91 13:33:44 +0100 Message-ID: <1534.679149224@UK.AC.UCL.CS> From: Steve Hardcastle-Kille In the process of RFC submission, the I-Ds on String Representation of Presenation addres, and Network Address Structure have undergone editorial revision (a small amount in the former, and quite a bit in the latter). There are no technical changes. Thanks to Ross Callon for help in making these documents a good deal more readable. I am still hoping for some progress on the RFC front before Atlanta. We'll discuss this in Atlanta. Steve OSI-DS 5 nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille July 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSI Nework Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a global OSI Network Service. This INTERNET--DRAFT defines mechanisms to encode addressing information within Network Addresses, in order to support this type of working. In particular, support is defined for RFC 1006 mapping of COTS onto TCP/IP and COTS mapped onto X.25(1980). OSI-DS 6 string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-02.txt, ps S.E. Kille July 1991 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <2836-0@bells.cs.ucl.ac.uk>; Wed, 10 Jul 1991 16:06:35 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA05137; Wed, 10 Jul 91 17:01:42 +0200 Message-Id: <9107101501.AA05137@mitsou.inria.fr> To: Steve Hardcastle-Kille Cc: osi-ds@uk.ac.ucl.cs, braden@edu.isi In-Reply-To: Your message of 05 Jul 91 16:33:52 +0100. <2470.678728032@UK.AC.UCL.CS> Date: Wed, 10 Jul 91 17:01:26 BST From: Christian Huitema > >line form, but we should not confuse the problems. My distinguished name > >should be something like: > > < C=FR; O=INRIA; CN=Christian Huitema;> > >I disagree. Most users HATE typed names. Therefore, we need a notation for >DNs which correctly defaults out the types when they are "obvious". We will >never get the directory to fly if names look like what you have put in angle >brackets. Humm. I think that we are mixing goals there. Either we want an unambiguous notation for directory names, e.g. for exchanging them in textual representations of directory entries, or we want a user friendly notation "so that the directory will fly". I have the strong feeling that: 1) the reference notation should be completely unambiguous. Omitting the types should be only acceptable if you could restore them algorithmically, without using the directory service. This is perhaps acceptable for the default name form, e.g. CN, [OU,]* O, C. But all exceptions, eg. all usages of other name forms, should be typed. 2) the "user friendly notation" is perhaps useful as a default interface to DUAs. But the idea of copying it in one of the bottom lines of your business card seems ludicrous: the very idea of a white page serviec is that you should be able to enter it with "external" information, like the one that appears on the top lines of your business card! In fact, pursuing too far the idea of "untyped names" is equivalent to saying that X.500 as got its naming model wrong, and that we should use simple text tokens instead of typed attributes. Like the DNS... >I have scoped this as a JOINT Cosine and Internet document. I think that we >should take a collaborative approach at the technical stage. It is important >that we define conformance criteria that work for both communities. I dislike enormously the idea of a joint "requirement" document. I understand what a joint technical specification is; but a requirement document is issued by a single authority. I dont see the point of issuing an RFC that would set the policy for COSINE -- and, no, I dont see any plan to support X.25 in the Internet. I dont even know of any plan to make it a required protocol on the French Research Network... Christian Huitema   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3344-0@bells.cs.ucl.ac.uk>; Wed, 10 Jul 1991 16:32:13 +0100 To: Christian Huitema cc: osi-ds@uk.ac.ucl.cs, braden@edu.isi Phone: +44-71-380-7294 In-reply-to: Your message of Wed, 10 Jul 91 17:01:26 +0100. <9107101501.AA05137@mitsou.inria.fr> Date: Wed, 10 Jul 91 16:32:11 +0100 Message-ID: <2666.679159931@UK.AC.UCL.CS> From: Steve Hardcastle-Kille >From: Christian Huitema >To: Steve Hardcastle-Kille >Date: Wed, 10 Jul 91 17:01:26 BST >> >line form, but we should not confuse the problems. My distinguished name >> >should be something like: >> > < C=FR; O=INRIA; CN=Christian Huitema;> >> >>I disagree. Most users HATE typed names. Therefore, we need a notation for >>DNs which correctly defaults out the types when they are "obvious". We will >>never get the directory to fly if names look like what you have put in angle >>brackets. >Humm. I think that we are mixing goals there. Either we want an unambiguous >notation for directory names, e.g. for exchanging them in textual >representations of directory entries, or we want a user friendly notation "so >that the directory will fly". I have the strong feeling that: >1) the reference notation should be completely unambiguous. Omitting the types >should be only acceptable if you could restore them algorithmically, without >using the directory service. This is perhaps acceptable for the default name >form, e.g. CN, [OU,]* O, C. But all exceptions, eg. all usages of other name >forms, should be typed. This is exactly what UFN does. It defines a default type hieararchy, which is the one you note. >2) the "user friendly notation" is perhaps useful as a default interface to >DUAs. But the idea of copying it in one of the bottom lines of your business >card seems ludicrous: the very idea of a white page serviec is that you should >be able to enter it with "external" information, like the one that appears on >the top lines of your business card! The main aim is for a DUA interface. In very many cases, the business card could be used WITHOUT a specific directory encoding. That is defnitely the aim of UFN. I think that we are agreeing loudly >In fact, pursuing too far the idea of "untyped names" is equivalent to saying >that X.500 as got its naming model wrong, and that we should use simple text >tokens instead of typed attributes. Like the DNS... I have some sympathy with this argument. However, I believe that the UFN approach will allow you to get the best of both worlds. There is typing for when it is needed, and a default notation which hides it when it is not needed. >I dislike enormously the idea of a joint "requirement" document. I understand >what a joint technical specification is; but a requirement document is issued >by a single authority. I dont see the point of issuing an RFC that would set >the poli >cy for COSINE -- and, no, I dont see any plan to support X.25 in the >Internet. I dont even know of any plan to make it a required protocol on the >French Research Network... I expect that the reality will be multiple documents, as it will not be possible to reach agreement on a common document. Operational problems caused by the differences will be solved with sticking plaster. I think that both COSINE and Internet communities need to set policies. Having them in one document, to ensure coherency, is surely a laudable goal? Does anyone out there support this? >Christian Huitema Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3344-0@bells.cs.ucl.ac.uk>; Wed, 10 Jul 1991 16:32:13 +0100 To: Christian Huitema cc: osi-ds@uk.ac.ucl.cs, braden@edu.isi Phone: +44-71-380-7294 In-reply-to: Your message of Wed, 10 Jul 91 17:01:26 +0100. <9107101501.AA05137@mitsou.inria.fr> Date: Wed, 10 Jul 91 16:32:11 +0100 Message-ID: <2666.679159931@UK.AC.UCL.CS> From: Steve Hardcastle-Kille >From: Christian Huitema >To: Steve Hardcastle-Kille >Date: Wed, 10 Jul 91 17:01:26 BST >> >line form, but we should not confuse the problems. My distinguished name >> >should be something like: >> > < C=FR; O=INRIA; CN=Christian Huitema;> >> >>I disagree. Most users HATE typed names. Therefore, we need a notation for >>DNs which correctly defaults out the types when they are "obvious". We will >>never get the directory to fly if names look like what you have put in angle >>brackets. >Humm. I think that we are mixing goals there. Either we want an unambiguous >notation for directory names, e.g. for exchanging them in textual >representations of directory entries, or we want a user friendly notation "so >that the directory will fly". I have the strong feeling that: >1) the reference notation should be completely unambiguous. Omitting the types >should be only acceptable if you could restore them algorithmically, without >using the directory service. This is perhaps acceptable for the default name >form, e.g. CN, [OU,]* O, C. But all exceptions, eg. all usages of other name >forms, should be typed. This is exactly what UFN does. It defines a default type hieararchy, which is the one you note. >2) the "user friendly notation" is perhaps useful as a default interface to >DUAs. But the idea of copying it in one of the bottom lines of your business >card seems ludicrous: the very idea of a white page serviec is that you should >be able to enter it with "external" information, like the one that appears on >the top lines of your business card! The main aim is for a DUA interface. In very many cases, the business card could be used WITHOUT a specific directory encoding. That is defnitely the aim of UFN. I think that we are agreeing loudly >In fact, pursuing too far the idea of "untyped names" is equivalent to saying >that X.500 as got its naming model wrong, and that we should use simple text >tokens instead of typed attributes. Like the DNS... I have some sympathy with this argument. However, I believe that the UFN approach will allow you to get the best of both worlds. There is typing for when it is needed, and a default notation which hides it when it is not needed. >I dislike enormously the idea of a joint "requirement" document. I understand >what a joint technical specification is; but a requirement document is issued >by a single authority. I dont see the point of issuing an RFC that would set >the poli >cy for COSINE -- and, no, I dont see any plan to support X.25 in the >Internet. I dont even know of any plan to make it a required protocol on the >French Research Network... I expect that the reality will be multiple documents, as it will not be possible to reach agreement on a common document. Operational problems caused by the differences will be solved with sticking plaster. I think that both COSINE and Internet communities need to set policies. Having them in one document, to ensure coherency, is surely a laudable goal? Does anyone out there support this? >Christian Huitema Steve   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <9800-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 07:57:02 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Thu, 11 Jul 1991 07:57:13 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 11 Jul 1991 07:56:02 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 11 Jul 1991 09:55:00 +0100 Date: Thu, 11 Jul 1991 06:56:02 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.237:11.06.91.06.56.02] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: joint req... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"3238 Thu Jul 11 08:56:06 1991"@surfnet.nl> To: S.Kille@uk.ac.ucl.cs, RARE & IETF OSI-DS wg Subject: Re: joint requirements doc X-VMS-To: IN%"S.Kille@cs.ucl.ac.uk" Sender: HUIZER@nl.surfnet Steve, Christian, > I think that both COSINE and Internet communities need to set policies. > Having them in one document, to ensure coherency, is surely a laudable goal? > Does anyone out there support this? I do support Steve in this effort. It is vital for the succes of the dir service that there will be as little interworking problems as possible between different communities. Trying to allign the requirements for Cosine and Internet in one RFC (which then can also be published as a Rare technical Report), will certainly help. And unless we want to start the old CONS vs CLNS discussion again, I think we have to accept that both will be around, and that the users choose what they are going to use for the lower layers, so both have to be in the requirements doc. Erik   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <13415-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:02:47 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA05706; Thu, 11 Jul 91 11:59:54 +0200 Message-Id: <9107110959.AA05706@mitsou.inria.fr> To: Erik.Huizer@nl.surfnet Cc: S.Kille@uk.ac.ucl.cs, RARE & IETF OSI-DS wg Subject: Re: joint requirements doc In-Reply-To: Your message of 11 Jul 91 06:56:02 +0000. <"3238 Thu Jul 11 08:56:06 1991"@surfnet.nl> Date: Thu, 11 Jul 91 11:59:30 BST From: Christian Huitema Erik, Lower layer connectivity is certainly going to be a problem. I do not think that we can validly run a distributed application such as X.500 without lower layer connectivity. I know that Steve has worked a lot on using a chaining DSA as a relay between network-disconnected DSAs, but this is clearly suboptimal and may well lead to bizarre side effects. There is no way that you can mandate both TCP-IP based RFC-1006 and X.25. In particular, there is no way that you could mandate Internet DSA to use public X.25. On the other hand, I understand that some COSINE DSAs are not reachable through TCP-IP, and that COSINE cannot make TCP-IP connectivity a requirement. Thus, I think that this part of the requirement spec, at least, will have to be different in the COSINE and INTERNET document. Alternatively, the requirement spec could just avoid the problem, by not listing any lower layer requirement at all. There is one solution, though. This is called gateways, and is urgently needed. In fact, we should insist that some common transport gateways be deployed between the INTERNET, IXI, and public X.25 networks, thus enabling connectivity. In order to use these gateways, one must have an addressing plan, with identifications of connex "communities" by some particular NSAP headers. Maybe DSAs should be required then to list at least one NSAP in one of the supported communities, using the standard format for it. Christian Huitema PS. This gives an interesting notion of "the expanded Internet". Instead of "any host that I can reach using IP", "any host that I can reach through a transport relay". Gee..   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <13938-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:19:54 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Thu, 11 Jul 1991 11:20:09 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 11 Jul 1991 11:18:37 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 11 Jul 1991 13:18:00 +0100 Date: Thu, 11 Jul 1991 10:18:37 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.891:11.06.91.10.18.37] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: joint req... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"4893 Thu Jul 11 12:18:47 1991"@surfnet.nl> To: Christian.Huitema@fr.inria.mirsa, RARE & IETF OSI-DS wg Subject: Re: joint requirements doc X-VMS-To: IN%"Christian.Huitema@mirsa.inria.fr" Sender: HUIZER@nl.surfnet Christian, > Lower layer connectivity is certainly going to be a problem. I do not think > that we can validly run a distributed application such as X.500 without lower > layer connectivity. I know that Steve has worked a lot on using a chaining DSA > as a relay between network-disconnected DSAs, but this is clearly suboptimal > and may well lead to bizarre side effects. Such as? I still have the feeling (being an level-5 and upwards type of person) that trsprt layer bridges and gwys are too slow and bothersome. What's wrong with DASA chaining. That could in my opinion very well be optimised. I am at loss what we should do with FTAM though, we will need some trsprt layer connections there. > There is no way that you can mandate both TCP-IP based RFC-1006 and X.25. In > particular, there is no way that you could mandate Internet DSA to use public > X.25. On the other hand, I understand that some COSINE DSAs are not reachable > through TCP-IP, and that COSINE cannot make TCP-IP connectivity a requirement. > Thus, I think that this part of the requirement spec, at least, will have to > be different in the COSINE and INTERNET document. Alternatively, the > requirement spec could just avoid the problem, by not listing any lower layer > requirement at all. I agree that you cannot mandate a requirement for both in both worlds, however a remark stating that having both stacks will help to improve performance etc. might be more helpfull as advice than keeping your mouth shut and saying nothing. It will (at least) show some people on the internet that there's more to networking as TCP/Ip in this world :-) > There is one solution, though. This is called gateways, and is urgently > needed. In fact, we should insist that some common transport gateways be > deployed between the INTERNET, IXI, and public X.25 networks, thus enabling > connectivity. In order to use these gateways, one must have an addressing > plan, with identifications of connex "communities" by some particular NSAP > headers. Maybe DSAs should be required then to list at least one NSAP in one > of the supported communities, using the standard format for it. Don't we need a full global X.500 service to solve the NSAP problem? There's a chicken and egg problem for you. However, as you know much more then I do about transport gwys, I hope you are right that they may provide the solution, I still want to be convinced. > This gives an interesting notion of "the expanded Internet". Instead of > "any host that I can reach using IP", "any host that I can reach through a > transport relay". Gee.. I thought you (the IAB and other gurus) had decided in San Diego (or some place) that being on the internet meant sharing the same namespace? I personally find that a very nice definition, if only because it is independant of protocols. Europe is, and I know this is new to many north Americans :-), MORE than just an extension of the internet IP-network. Erik   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <14076-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:22:24 +0100 To: Christian Huitema cc: RARE & IETF OSI-DS wg Subject: Re: joint requirements doc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 11 Jul 91 11:59:30 +0100. <9107110959.AA05706@mitsou.inria.fr> Date: Thu, 11 Jul 91 11:22:22 +0100 Message-ID: <1055.679227742@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Christian, Either I didn't wirte my text clearly or you didn't read it clearly! I made 3 points in this area. 1) Pilots/MDs will need to make an internal choice about lower layers. Typically, this will be a per-national pilot decision. 2) All DSAs in the FOX/PSI/Internet Pilot shall support RFC 1006 3) All pilots must provide access to X.25 and 1006. This can be done by mandating support in all DSAs or by provision of a relay DSA. An implicaton of this is that the Internet should provide a service DSA with X.25 access, so that US sites can get access to X.25 only DSAs. I think that this is a reasonable thing to require. I'm certainly not sugesting that all Internet DSAs should run X.25. As CLNS and CONS evolve, the requirements will almost certainly need to change. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <14234-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:26:30 +0100 To: Christian Huitema cc: RARE & IETF OSI-DS wg Subject: Re: joint requirements doc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 11 Jul 91 11:59:30 +0100. <9107110959.AA05706@mitsou.inria.fr> Date: Thu, 11 Jul 91 11:26:27 +0100 Message-ID: <1069.679227987@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I reread your message, and realised that I forgot to address the transport bridging point. I think that TSBs can be useful to gateway a LAN onto a WAN. I think that they remain to be proven as a means for linking WANs, because of the routing and addressing problems. I think that application level conversion is the best strategy for directory. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <14234-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:26:30 +0100 To: Christian Huitema cc: RARE & IETF OSI-DS wg Subject: Re: joint requirements doc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 11 Jul 91 11:59:30 +0100. <9107110959.AA05706@mitsou.inria.fr> Date: Thu, 11 Jul 91 11:26:27 +0100 Message-ID: <1069.679227987@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I reread your message, and realised that I forgot to address the transport bridging point. I think that TSBs can be useful to gateway a LAN onto a WAN. I think that they remain to be proven as a means for linking WANs, because of the routing and addressing problems. I think that application level conversion is the best strategy for directory. Steve   Return-Path: Received: from concurrent.co.uk by bells.cs.ucl.ac.uk via PSS with NIFTP id <14737-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:41:47 +0100 To: Steve Hardcastle-Kille cc: Christian Huitema , RARE & IETF OSI-DS wg Organization: Concurrent Computer Corp (ESDG), Slough, U.K. Phone: +44 753 513316 Subject: Re: joint requirements doc In-reply-to: Your message of Thu, 11 Jul 91 11:26:27 +0100. <1069.679227987@UK.AC.UCL.CS> Date: Thu, 11 Jul 91 11:40:20 +0100 Message-ID: <5939.679228820@concurrent.co.uk> From: Alan Young > I reread your message, and realised that I forgot to address the transport > bridging point. I think that TSBs can be useful to gateway a LAN onto > a WAN. I think that they remain to be proven as a means for linking > WANs, because of the routing and addressing problems. I think that > application level conversion is the best strategy for directory. Why are there routing and addressing problems in using TSBs to link WANs? In particular 1006 and IXI/X.25 are quite suitable to use with a TSB because, given the ability to listen on a specific NSAP with these (sub)network types, the ISODE trick of encoding the end-system Transport Address (TSEL/NSAP) is available. The problem I see is more likely to be who will pay for the provision of such a service when pay-per-packet networks are involved. Of course this is the same with relayDSA or TSB. On the wider point I most strongly agree that *all* pilots *must* provide access to all the major networks, in particular the Internet and International X.25. I do not much care if TSBs or relayDSAs are used. Alan.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <15034-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:55:05 +0100 To: Alan Young cc: Christian Huitema , RARE & IETF OSI-DS wg Subject: Re: joint requirements doc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 11 Jul 91 11:40:20 +0100. <5939.679228820@concurrent.co.uk> Date: Thu, 11 Jul 91 11:55:02 +0100 Message-ID: <1196.679229702@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I agree that if you register the TSB in ALL DSAs, then the problem can be solved. Given the difficulty we have had in getting UK DSAs to register on IXI, I am convinced that an explict registration approach would cause problems. The addressing problems relate to use of TSBs in "transparent" mode, which your suggestion avoids. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <15034-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 11:55:05 +0100 To: Alan Young cc: Christian Huitema , RARE & IETF OSI-DS wg Subject: Re: joint requirements doc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 11 Jul 91 11:40:20 +0100. <5939.679228820@concurrent.co.uk> Date: Thu, 11 Jul 91 11:55:02 +0100 Message-ID: <1196.679229702@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I agree that if you register the TSB in ALL DSAs, then the problem can be solved. Given the difficulty we have had in getting UK DSAs to register on IXI, I am convinced that an explict registration approach would cause problems. The addressing problems relate to use of TSBs in "transparent" mode, which your suggestion avoids. Steve   Return-Path: Received: from concurrent.co.uk by bells.cs.ucl.ac.uk via PSS with NIFTP id <15735-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 12:15:00 +0100 To: Steve Hardcastle-Kille cc: RARE & IETF OSI-DS wg Organization: Concurrent Computer Corp (ESDG), Slough, U.K. Phone: +44 753 513316 Subject: Re: joint requirements doc In-reply-to: Your message of Thu, 11 Jul 91 11:55:02 +0100. <1196.679229702@UK.AC.UCL.CS> Date: Thu, 11 Jul 91 12:14:33 +0100 Message-ID: <6371.679230873@concurrent.co.uk> From: Alan Young > The addressing problems relate to use of TSBs in "transparent" mode, which > your suggestion avoids. Yes, of course, and use of TSBs in bridge (non-transparent) mode would require the TS of all DSAs to understand the ISODE TSB bridge-mode addressing mechanism which is clearly unacceptable. The maintenance of one or more TSBs with transparent-mode addresses for each DSA would be a significant burden in addition to the registration problem you outline. So it looks like TSBs don't cut it.   Return-Path: Received: from concurrent.co.uk by bells.cs.ucl.ac.uk via PSS with NIFTP id <15735-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 12:15:00 +0100 To: Steve Hardcastle-Kille cc: RARE & IETF OSI-DS wg Organization: Concurrent Computer Corp (ESDG), Slough, U.K. Phone: +44 753 513316 Subject: Re: joint requirements doc In-reply-to: Your message of Thu, 11 Jul 91 11:55:02 +0100. <1196.679229702@UK.AC.UCL.CS> Date: Thu, 11 Jul 91 12:14:33 +0100 Message-ID: <6371.679230873@concurrent.co.uk> From: Alan Young > The addressing problems relate to use of TSBs in "transparent" mode, which > your suggestion avoids. Yes, of course, and use of TSBs in bridge (non-transparent) mode would require the TS of all DSAs to understand the ISODE TSB bridge-mode addressing mechanism which is clearly unacceptable. The maintenance of one or more TSBs with transparent-mode addresses for each DSA would be a significant burden in addition to the registration problem you outline. So it looks like TSBs don't cut it.   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <16308-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 12:30:26 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA05749; Thu, 11 Jul 91 13:27:56 +0200 Message-Id: <9107111127.AA05749@mitsou.inria.fr> To: Steve Hardcastle-Kille , Alan Young , Erik.Huizer@nl.surfnet Cc: RARE & IETF OSI-DS wg Subject: Re: joint requirements doc In-Reply-To: Your message of 11 Jul 91 11:55:02 +0100. <1196.679229702@UK.AC.UCL.CS> Date: Thu, 11 Jul 91 13:27:38 BST From: Christian Huitema Steve, Alan, Erik, The reasons why I prefer a "transport bridge" approach to the application relay are the following: 1) Application relays use DSA chaining. What if a DSA down the chain issues a chained REFERAL error? There is no such thing in X.500 as a "must always chain" control bit -- the only thing you can do is either to forbid chaining or to state that you would prefer chaining. 2) Chaining has a number of security effects. In the absence of strong authentication, accepting a chained operation which access (read or write) protected ressources is not recommanded. Even in the presence of strong authentication, if intermediate DSAs perform caching -- as some will -- chaining sensitive informations is equivalent to making them public. 3) Maintenance of replicated information cannot easily be done by chaining -- you cannot specify a target DSA, only a target name. Yet, replication of data between different pilots is even more necessary than replication within a single pilot. Transport layer connectivity is useful for many applications, not only X.500 but also X.400 or FTAM or CMIP, etc. We could build upon the infrastructure, and contribute to its valorisation. I agree that we may have some administrative procedures to solve, e.g. controlling who accesses what and who pays for the bits; but as Alan pointed out, the problem is the same with application relays. Erik raised a "performance" concern; I think this is not justified. A simple TS-bridge, e.g. running as a user process on a workstation, can certainly saturate a typical 64kbps attachment to IXI or public X.25; in any case, it will use less CPU cycles per relayed bit than an application relay. Moreover TS-bridge dont have to be programmed on UNIX workstations; once the specification is public and stable, I would expect to see implementations on network switches, yelding almost the same performances as e.g. IP over X.25. Christian Huitema   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <16755-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 12:40:16 +0100 To: Christian Huitema cc: RARE & IETF OSI-DS wg Subject: Re: joint requirements doc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 11 Jul 91 13:27:38 +0100. <9107111127.AA05749@mitsou.inria.fr> Date: Thu, 11 Jul 91 12:40:13 +0100 Message-ID: <1329.679232413@UK.AC.UCL.CS> From: Steve Hardcastle-Kille >From: Christian Huitema >To: Steve Hardcastle-Kille , Alan Young , Erik.Huizer@nl.surfnet >Subject: Re: joint requirements doc >Date: Thu, 11 Jul 91 13:27:38 BST >Steve, Alan, Erik, >The reasons why I prefer a "transport bridge" approach to the application relay >are the following: >1) Application relays use DSA chaining. What if a DSA down the chain issues a >chained REFERAL error? There is no such thing in X.500 as a "must always >chain" control bit -- the only thing you can do is either to forbid chaining >or to state that you would prefer chaining. Clearly relay DSAs have to be implemented to understand connectivity. Given this, there is no real problem here. >2) Chaining has a number of security effects. In the absence of strong >authentication, accepting a chained operation which access (read or write) >protected ressources is not recommanded. Even in the presence of strong >authentication, if intermediate DSAs perform caching -- as some will -- >chaining sensitive informations is equivalent to making them public. This is a valid point. However, I think that if we are to be serous about security, this difficulty is a minor one... >3) Maintenance of replicated information cannot easily be done by chaining -- >you cannot specify a target DSA, only a target name. Yet, replication of data >between different pilots is even more necessary than replication within a >single pilot. Replication is vital. Howver, my approach of requuring pilots to have either connectivty, or relay DSAs will solve the problem, as the relay DSAs can also relay replication. Steve   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <17389-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 12:53:00 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <9947-1@sun2.nsfnet-relay.ac.uk>; Thu, 11 Jul 1991 12:49:04 +0100 Received: from funet.fi by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa06700; 11 Jul 91 12:32 BST To: awy@uk.co.concurrent CC: S.Kille@uk.ac.ucl.cs, Christian.Huitema@fr.inria.mirsa, osi-ds@uk.ac.ucl.cs In-reply-to: Alan Young's message of Thu, 11 Jul 91 11:40:20 +0100 <5939.679228820@concurrent.co.uk> Subject: joint requirements doc Date: Thu, 11 Jul 1991 14:49:19 +0300 From: Juha Heinanen Original-Sender: Juha.Heinanen@fi.funet Sender: Juha.Heinanen@fi.funet FUNET, at least, has a fixed yearly budget and it is very hard for it (or its members) to participate in any pilot that doesn't utilize the current leased line infrastructure (either internet or ixi). making public x.25 as a requirement doesn't make any sense to the members who already are paying quite high membership fees covering the current infrastructure. and even if the money would be available, FUNET would not have resources to bill its members when they cause X.25 traffic via a central directory server. i hope that these kind of administrative issues are also taking into account when placing requirements for network services. what comes to the use of COSINE in the requirements document, i think is it very inappropriate, since COSINE will die in one and half years. shouldn't RARE be mentioned instead since it is likely to represent the European user community for a longer period of time. -- juha   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <17560-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 12:58:11 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <10095-1@sun2.nsfnet-relay.ac.uk>; Thu, 11 Jul 1991 12:54:48 +0100 Received: from funet.fi by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa06826; 11 Jul 91 12:38 BST To: S.Kille@uk.ac.ucl.cs CC: Christian.Huitema@fr.inria.mirsa, osi-ds@uk.ac.ucl.cs In-reply-to: Steve Hardcastle-Kille's message of Thu, 11 Jul 91 11:22:22 +0100 <1055.679227742@UK.AC.UCL.CS> Subject: joint requirements doc Date: Thu, 11 Jul 1991 14:54:41 +0300 From: Juha Heinanen Original-Sender: Juha.Heinanen@fi.funet Sender: Juha.Heinanen@fi.funet An implicaton of this is that the Internet should provide a service DSA with X.25 access, so that US sites can get access to X.25 only DSAs. I think that this is a reasonable thing to require. I'm certainly not sugesting that all Internet DSAs should run X.25. to what X.25? i would accept x.25 but not the public one because of economical and managerial reasons. As CLNS and CONS evolve, the requirements will almost certainly need to change. yes, when do you install CLNS in the root DSA as i have been asking for a long time? -- juha   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <17870-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 13:12:26 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA05782; Thu, 11 Jul 91 14:10:16 +0200 Message-Id: <9107111210.AA05782@mitsou.inria.fr> To: Steve Hardcastle-Kille Cc: RARE & IETF OSI-DS wg Subject: Re: joint requirements doc In-Reply-To: Your message of 11 Jul 91 12:40:13 +0100. <1329.679232413@UK.AC.UCL.CS> Date: Thu, 11 Jul 91 14:10:00 BST From: Christian Huitema >Clearly relay DSAs have to be implemented to understand connectivity. >Given this, there is no real problem here. The relay DSA which you plan as the entry point to a given pilot may be "implemented to understand connectivity". But the next DSA in line will not necessarily understand that, and may well prefer to use REFERAL... > >chaining sensitive informations is equivalent to making them public. > >This is a valid point. However, I think that if we are to be serous about >security, this difficulty is a minor one... We feel that this is a real problem. This kind of control is already implemented in Pizarro. Amendments to X.500 (1992) include a redefinition of the "REFERAL" error to include a "returnToDUA" flag, to use "for example where a DSA does not wish to release information as results of a chained operation...". >Replication is vital. Howver, my approach of requuring pilots to have >either connectivty, or relay DSAs will solve the problem, as the relay DSAs >can also relay replication. How? There is a simple way to perform replication (as in THORN) by connecting the replication source as a DUA to the target DSA, and then applying modify operation to the replicated name space. But this cannot be chained -- otherwise the chaining DSA will forward the query based on the replicated object name, and can as well forward it to the primary DSA. If you look at the draft amendment on replication uses the ROS in a rather pure client/server mode, and does not seem to include any provision for chained operation. You can certainly produce a replication-agent that uses its own protocol and performs application relaying, but that is out of the scope of the standard. To sum up, I believe that DSA chaining is interesting per se but cannot replace network or transport connectivity. Christian Huitema   Return-Path: Received: from kwai.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <5572-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 16:25:11 +0100 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 11 Jul 91 17:25:22+0200 X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/; Relayed; 11 Jul 91 17:23:08+0200 Date: 11 Jul 91 17:23:08+0200 From: Paul-Andre Pays Message-ID: <9107111523.AA00638@mars.emse.fr> To: osi-ds@uk.ac.ucl.cs Subject: The COSINE and Internet X.500 Schema : error? : It seems there is an error in the version 1.1 of this document at the end of the document we find The COSINE and Internet X.500 Schema DRAFT Version 1.1 -- Generally useful syntaxes caseIgnoreStringSyntax ATTRIBUTE-SYNTAX IA5String MATCHES FOR EQUALITY SUBSTRINGS our understanding is that it should be caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX Could someone tell us if this assumption is correct or if there is something we have missed? The other point is that we miss the OID for the all these attribute syntaxes. is it documented somewhere else or really missing? Thanks for your help -- PAP and Suzan Mendes   Return-Path: Received: from bunnahabhain.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17984-0@bells.cs.ucl.ac.uk>; Thu, 11 Jul 1991 17:35:12 +0100 To: Paul-Andre Pays cc: osi-ds@uk.ac.ucl.cs Subject: Re: The COSINE and Internet X.500 Schema : error? In-reply-to: Your message of 11 Jul 91 17:23:08 +0200. <9107111523.AA00638@mars.emse.fr> Date: Thu, 11 Jul 91 17:34:58 +0100 From: Paul Barker > > our understanding is that it should be > caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX You are correct - my mistake. > The other point is that we miss the OID for the all these attribute > syntaxes. > is it documented somewhere else or really missing? There were missing (and I'm just about to edit them in!). The definitions are: iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4} caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 5} Apologies for the errors. Let me know if you unearth any more omissions etc. > Thanks for your help > -- PAP and Suzan Mendes Paul   Return-Path: Received: from bunyip.cc.uq.oz.au by bells.cs.ucl.ac.uk with SMTP inbound id <20029-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 00:33:29 +0100 Received: from uqvax.cc.uq.oz.au by bunyip.cc.uq.oz.au id aa24878; 12 Jul 91 9:33 EST Date: Fri, 12 Jul 91 09:34 EST From: "Danny Smith, The Prentice Centre, Univ of Qld" Subject: Re: joint requirements doc To: Christian.Huitema@fr.inria.mirsa, osi-ds@uk.ac.ucl.cs Message-id: <484BF6B338FF20227A@uqvax.cc.uq.oz.au> X-Envelope-to: osi-ds@cs.ucl.ac.uk, Christian.Huitema@mirsa.inria.fr X-VMS-To: IN%"Christian.Huitema@mirsa.inria.fr" X-VMS-Cc: in%"osi-ds@cs.ucl.ac.uk" Steve, Christian, et al, > >This is a valid point. However, I think that if we are to be serous about > >security, this difficulty is a minor one... > > We feel that this is a real problem. This kind of control is already > implemented in Pizarro. Amendments to X.500 (1992) include a redefinition of > the "REFERAL" error to include a "returnToDUA" flag, to use "for example where > a DSA does not wish to release information as results of a chained > operation...". I understand Steve's sentiments, but also agree with Christian - it is a real problem. It stems from the definition of the 1988 operation results which return entry information only. Any access control information is held locally, and applied locally. Once the operation is allowed to proceed the entry information is released, any DSA may cache that information if it was involved with the chain. The way this was handled in the access control work was that the DSA could decide if the information was sensitive enough not to allow it to be released as the result of a chained operation. It could pass back a referral to itself to indicate to the DUA that it should BIND directly to the DSA holding the required entry (using strong authentication??). The returnToDUA flag was placed in the referral to prevent loops forming where one DSA in the chain decides to act on the referral by starting a new chain. I believe that what Steve is saying is that if we are really serious about security, then this is one of many problems that will be handled as a matter of course. Therefore, in the total X.500 security scene, it is a small part. It is a serious problem however, as are many others. cheers, dfs...   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <27512-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 10:19:22 +0100 To: osi-ds@uk.ac.ucl.cs Subjtect: The latest OSI-DS Index Phone: +44-71-380-7294 Date: Fri, 12 Jul 91 10:19:19 +0100 Message-ID: <1015.679310359@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I've added OSI-DS 19 ( Interim Directory Tree Structure for Network Infrastructur Information), which slipped thru a hole for some reason. I'll also put this onto the Agenda. Steve INDEX OF IETF OSI DS Documents (OSI-DS 0) July 1991 The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital) ------------------------------------------------------------------------ INDEX OSI-DS 0 index.txt This document ------------------------------------------------------------------------ SCOPE OF GROUP OSI-DS 1 scope.ps scope.txt IETF Directory Working Group Scope (Version 4) S.E. Kille December 22, 1990 Abstract: This document defines the scope for the IETF OSI Directory Ser- vices Working Group (OSI-DS). The OSI-DS group works on issues relating to building an OSI Di- rectory Service using X.500 and its deployment on the Internet. Whilst this group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. ------------------------------------------------------------------------ CHARTER OSI-DS 2 charter.txt November 1990 Abstract: A synopsis of the scope in the IETF WG format ------------------------------------------------------------------------ MINUTES OF MEETINGS minutes-1-oct90.txt (OSI-DS-MINUTES 1) 1st Meeting, San Jose, Oct 90 minutes-2-dec90.txt, ps (OSI-DS-MINUTES 2) 2nd Meeting, Boulder, Dec 90 minutes-3-feb91.txt (OSI-DS-MINUTES 3) 3rd Meeting, SRI, Feb 91 minutes-4-apr91.txt, ps (OSI-DS-MINUTES 4) 4th Meeting, Videoconference, Apr 91 ------------------------------------------------------------------------ MAIL ARCHIVES arch-current.txt - Mail Archive ------------------------------------------------------------------------ IETF DRAFTS OSI-DS 3 strategy.txt strategy.ps A proposed strategy for deploying an OSI Internet Directory S.E. Kille March 1991 Abstract: This document is a first cut at describing an overall strategy for deploying an OSI Directory on the Internet. This is a draft document, and does not carry any implications of agreement on policy. OSI-DS 4 goals.txt goals.ps Overall plan of the IETF Working Group on OSI Directories (OSI-DS) to build an Internet Directory using X.500 S.E. Kille February 1991 Abstract: The IETF has established a Working Group on OSI Directory Services (IETF-OSI-DS). A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the Internet, making use of the X.500 protocols and services [CCI88b]. This document summarises the plan established by the working group to achieve this, and describes a number of RFCs which the working group will write in order to establish the technical framework. This document has now been submitted as an RFC OSI-DS 5 nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille July 1991 Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSI Nework Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a global OSI Network Service. This INTERNET--DRAFT defines mechanisms to encode addressing information within Network Addresses, in order to support this type of working. In particular, support is defined for RFC 1006 mapping of COTS onto TCP/IP and COTS mapped onto X.25(1980). OSI-DS 6 string.ps string.txt A String encoding of Presentation Address draft-ucl-kille-presentationaddress-03.txt, ps S.E. Kille July 1991 Abstract: There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. OSI-DS 7 domain.ps domain.txt Domains and X.500 S.E. Kille March 1991 Filename : draft-ucl-kille-x500domains-03.txt, or .ps Abstract: This INTERNET--DRAFT considers X.500 in relation to Internet and UK Domains. A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. OSI-DS 8 ufn.ps ufn.txt Using the OSI Directory to achieve User Friendly Naming S.E. Kille March 1991 draft-ietf-osids-friendlynaming-02.txt, or .ps Abstract: The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. OSI-DS 9 repl-req.ps repl-req.txt Replication Requirement to provide an Internet Directory using X.500 S.E. Kille March 1991 draft-ietf-osids-replication-02.txt, .ps Abstract: A companion document discussed an overall framework for deploying X.500 on the Internet [Kil90 ]. This document considers certain deficiencies of the 1988 standard, which need to be addressed before an effective open Internet Directory can be established [CCI88 ]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This INTERNET--DRAFT concerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. OSI-DS 10 na.txt P. Barker S.E. Kille March 1991 The COSINE and Internet X.500 Schema draft-ietf-osids-cosinex500-03.txt Abstract: This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema This document also proposes a mechanism for allowing the schema to evolve in line with commonly held requirements. Proformas to support this process are included. It is important to note that this version of the document is a draft, and comments on the updating mechanisms are particularly welcome. Corrections and additions to the schema should now be sent the list, as described within. OSI-DS 11 repl-sol.ps Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Kille March 1991 draft-ietf-osids-replsoln-02.txt, or .ps Abstract: Some requirements on extensions to X.500 are described in the INTERNET--DRAFT [Kil90b ], in order to build an Internet Directory as described in the INTERNET--DRAFT [Kil90a ]. This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This INTERNET--DRAFT will be obsoleted at this point. OSI-DS 12 structure.ps structure.txt P. Barker S.E. Kille February 1991 Naming Guidelines for Directory Pilots draft-ietf-osids-dirpilots-00.txt, .ps Abstract: Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. OSI-DS 13 dsanaming.ps dsanaming.txt DSA Naming S.E. Kille March 1991 draft-ietf-osids-dsanaming-00.txt, or .ps Abstract: This INTERNET--DRAFT describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot. I believe this note to be an important step forward, as it begins to evolve a clear model of a Directory Management Domain. OSI-DS 14 contacts.txt Interim Schema for Internet Network Infrastructure Information In X.500 C. Weider M. Knopper draft-ietf-disi-netinfrax500-00.txt March 1991 Abstract: As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory Information, it was perceived that having the Internet Site Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. This paper describes the interim schema used to contain this information. OSI-DS 15 qos.ps qos.txt Handling QOS (Quality of service) in the Directory S.E. Kille March 1991 draft-ietf-osids-qos-00.txt,.ps Abstract: This document describes a mechanism for specifying the Quality of Service for DSA Operations and Data in the Internet Pilot Directory Service [Kil90]. OSI-DS 16 nic-profile.txt Schema for NIC Profile information in X.500 Chris Weider Mark Knopper June 1991 Abstract: The authors wish to put put up a readily accessible, distributed Directory of Network Information Centers, or NICs. This paper discusses the schema used to hold the NIC Profiles, as well as the DIT structure necessary for this information. OSI-DS 17 resource-schema.txt Schema for Information Resource Description in X.500 Chris Weider May 1991 Abstract: The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. OSI-DS 18 requirements.ps requirements.txt Directory Requirements for COSINE and Internet Pilots Steve Hardcastle-Kille July 1991 draft-ietf-osids-requirements-00.txt, .ps Abstract: This document specifies operational requirements for DUAs and DSAs in the Internet and COSINE communities. This document summarises conformance requirements. In most cases, technical detail is handled by reference to other documents. This document refers to core directory infrastructure. Each application using the directory may impose additional requirements. OSI-DS 19 treestructure.txt Interim Directory Tree Structure for Network Infrastructur Information Mark Knopper Ruth Lang April 1991 draft-ietf-disi-netinfrax500-00.txt Abstract: As work progresses on incorporating WHOIS and Network Infrastructure infor- mation into X.500, we thought it would be useful to document the current DIT structure for this information, along with some thoughts on future expansion and organization of this subtree of the DIT. The first section of this document describes the current structure, the second section the possible expansion of the structure. ------------------------------------------------------------------------   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <12264-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 11:36:41 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 12 Jul 91 11:36:40 +0100 From: Steve Titcombe -------- This list is now sorted on highest "dsa_available" figure, and grouping countries together. The "dsa_available" is an "inclusive or" of all the addresses of a DSA. For example it is possible for a DSA to be 60% available on Internet and 60% available on Janet, and the DSA be up 100% of the time. This is what the "dsa_available" line tries to show. DSA Probe Statistics For Root DSAs, for the period Friday 28th June - Friday 12th July. Bind Fail %age Best Worst Ave Address CA: Pangolin (Northern Telecom Master) 242 25 89.67 0.1 0.1 0.10 dsa_available 75 3 96.00 2.3 54.6 17.06 Private TCP 189 25 86.77 3.1 46.7 13.19 Internet Beluga Whale (Canada Master) 68 19 72.06 0.1 0.1 0.10 dsa_available 68 19 72.06 4.2 99.8 18.35 Internet Wayne Gretzky (Old Canada Master) 182 158 13.19 0.0 0.1 0.05 dsa_available 182 158 13.19 0.0 35.7 6.93 Internet AU: Bush Dog (master for AU (phony)) 190 25 86.84 0.1 0.1 0.10 dsa_available 190 25 86.84 0.5 14.7 19.04 Internet Anaconda (AU Master) 246 63 74.39 0.0 0.1 0.09 dsa_available 192 26 86.46 1.6 14.2 9.67 Internet 198 75 62.12 0.0 87.9 21.85 Int-X.25 ES: Cayman (Madrid Uni.) 67 9 86.57 0.1 0.1 0.10 dsa_available 67 13 80.60 6.9 109.6 20.86 Int-X.25 66 17 74.24 5.5 119.9 33.06 Internet 67 67 0.00 - - - IXI Iguana (ES Master. Programa IRIS) 293 179 38.91 0.0 1.0 0.18 dsa_available 189 78 58.73 2.1 118.6 18.63 Internet 198 192 3.03 0.0 7.3 2.54 Int-X.25 173 168 2.89 0.0 7.0 2.26 IXI IS: Elephant Seal (Iceland Master) 189 33 82.54 0.1 0.1 0.10 dsa_available 189 33 82.54 6.8 76.5 25.76 Internet GB: Coypu (Thorn acces pt to quipu) 298 57 80.87 0.0 1.0 0.26 dsa_available 189 46 75.66 0.0 4.2 4.99 X121 69 0 100.00 0.9 11.2 1.88 Local Ether 173 6 96.53 1.3 7.1 7.87 Janet 191 10 94.76 0.4 62.5 10.42 Internet False Cobra (Root, GB backup) 293 67 77.13 0.0 1.0 0.25 dsa_available 189 52 72.49 0.0 4.1 3.08 X121 170 14 91.76 1.3 3.8 3.32 Janet 188 16 91.49 0.3 30.5 5.97 Internet 174 79 54.60 0.0 4.1 2.45 IXI Vampire Bat (GB backup) 148 42 71.62 0.1 1.0 0.26 dsa_available 27 0 100.00 0.5 1.6 0.70 Private TCP 141 42 70.21 1.3 12.4 6.26 Janet 146 80 45.21 0.0 55.0 2.85 IXI Passionflower Leaf Beetle (GB Domain name information) 268 114 57.46 0.0 1.0 0.18 dsa_available 188 88 53.19 0.0 10.9 6.42 X121 189 88 53.44 0.0 59.7 6.72 Internet 144 69 52.08 0.0 9.4 4.80 Janet 148 125 15.54 0.0 6.8 1.71 IXI Giant Tortoise (Root, GB Master) 291 136 53.26 0.0 1.0 0.25 dsa_available 189 100 47.09 0.0 3.8 2.48 X121 169 49 71.01 1.0 3.8 3.50 Janet 186 74 60.22 0.2 10.8 3.54 Internet 174 88 49.43 0.0 4.4 1.52 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 145 145 0.00 - - - dsa_available 145 145 0.00 - - - Janet CH: Chinchilla (Swiss Master) 193 37 80.83 0.1 0.1 0.10 dsa_available 193 37 80.83 1.9 113.6 18.50 Internet Condor (ETH Zurich) 245 72 70.61 0.0 0.1 0.09 dsa_available 191 39 79.58 1.8 23.9 9.95 Internet 199 71 64.32 0.0 82.2 10.16 Int-X.25 US: Alpaca (US master) 197 39 80.20 0.1 0.1 0.10 dsa_available 197 39 80.20 1.0 86.7 7.41 Internet Fruit Bat (US@l=NY master) 188 54 71.28 0.1 0.1 0.10 dsa_available 188 54 71.28 1.7 39.5 22.88 Internet Giant Anteater (Various slave) 184 57 69.02 0.1 0.1 0.10 dsa_available 184 57 69.02 1.3 50.8 7.58 Internet DE: Puma (GMD/FOKUS) 261 60 77.01 0.0 1.0 0.17 dsa_available 133 15 88.72 0.5 21.0 7.23 Internet 50 9 82.00 4.5 93.6 22.55 Internet 196 55 71.94 0.0 51.8 6.89 Int-X.25 147 70 52.38 0.0 5.8 3.14 IXI Margay (GMD/F3, DE backup) 269 68 74.72 0.0 1.0 0.17 dsa_available 189 26 86.24 1.8 111.3 19.15 Internet 198 57 71.21 0.0 14.3 10.33 Int-X.25 149 74 50.34 0.0 6.6 2.97 IXI NO: Boa Constrictor (Norway Backup) 299 78 73.91 0.0 1.0 0.25 dsa_available 192 22 88.54 3.8 73.8 21.39 Internet 197 60 69.54 0.0 81.5 6.89 Int-X.25 175 85 51.43 0.0 15.5 8.57 IXI Electric Eel (Norway Master) 297 109 63.30 0.0 1.0 0.25 dsa_available 191 39 79.58 1.4 74.8 9.01 Internet 199 77 61.31 0.0 60.9 5.86 Int-X.25 176 105 40.34 0.0 6.7 3.66 IXI SE: Hummingbird (Sweden Master) 231 72 68.83 0.0 0.1 0.09 dsa_available 183 24 86.89 1.7 41.3 14.14 Internet 185 185 0.00 - - - '0101'H/X121 IL: Dorcan Gazelle (Israel Master) 68 26 61.76 0.1 0.1 0.10 dsa_available 68 26 61.76 8.9 151.1 63.01 Internet DK: Axolotl (DK Master) 193 92 52.33 0.1 0.1 0.10 dsa_available 193 92 52.33 2.7 82.4 20.23 Internet AT: Piranah (AT Master) 239 128 46.44 0.0 0.1 0.07 dsa_available 186 88 52.69 0.0 106.0 13.45 Internet 197 115 41.62 0.0 10.3 17.16 Int-X.25 FI: Jaguar (Finland Master) 242 134 44.63 0.0 0.1 0.09 dsa_available 190 85 55.26 1.6 37.3 16.86 Internet 188 152 19.15 0.0 9.8 4.72 X121 NL: Hornero (NL Master) 240 170 29.17 0.0 0.1 0.07 dsa_available 188 124 34.04 0.0 26.2 10.30 Internet 189 151 20.11 0.0 8.9 5.56 X121 Agouti (NL Slave) 197 197 0.00 - - - dsa_available 197 197 0.00 - - - Internet IE: Irish Elk (Republic of Ireland Master) 173 142 17.92 0.0 1.0 0.32 dsa_available 173 142 17.92 0.0 12.1 10.54 IXI BE: Woolly Spider Monkey (Belgium Master) 67 67 0.00 - - - dsa_available 67 67 0.00 - - - Internet   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22455-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 15:32:23 +0100 To: osi-ds@uk.ac.ucl.cs cc: Megan Davies Subject: Final versions of the videoconference minuets available Phone: +44-71-380-7294 Date: Fri, 12 Jul 91 15:32:21 +0100 Message-ID: <1997.679329141@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Text and Postscript. minutes-4-apr91.txt, ps (OSI-DS-MINUTES 4) 4th Meeting, Videoconference, Apr 91 Steve The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from NRI.RESTON.VA.us by bells.cs.ucl.ac.uk with SMTP inbound id <23658-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 16:03:03 +0100 Received: from NRI by NRI.NRI.Reston.VA.US id aa11605; 12 Jul 91 10:53 EDT To: Steve Hardcastle-Kille cc: osi-ds@uk.ac.ucl.cs, Megan Davies Subject: Re: Final versions of the videoconference minuets available In-reply-to: Your message of "Fri, 12 Jul 91 15:32:21 BST." <1997.679329141@UK.AC.UCL.CS> Date: Fri, 12 Jul 91 10:52:58 -0400 From: Megan Davies Message-ID: <9107121053.aa11605@NRI.NRI.Reston.VA.US> Thanks very much Steve. Megan ========= Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa10732; 12 Jul 91 10:32 EDT Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <22455-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 15:32:23 +0100 To: osi-ds@cs.ucl.ac.uk cc: Megan Davies Subject: Final versions of the videoconference minuets available Phone: +44-71-380-7294 Date: Fri, 12 Jul 91 15:32:21 +0100 Message-ID: <1997.679329141@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Text and Postscript. minutes-4-apr91.txt, ps (OSI-DS-MINUTES 4) 4th Meeting, Videoconference, Apr 91 Steve The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTPm NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to 00000511160013, username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from earn-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <5922-0@bells.cs.ucl.ac.uk>; Fri, 12 Jul 1991 22:52:17 +0100 Received: from UKACRL by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 1245; Fri, 12 Jul 91 22:52:24 BST Received: from UMDD.BITNET by UKACRL.BITNET (Mailer R2.07) with BSMTP id 1246; Fri, 12 Jul 91 22:52:23 BS Received: from UMDD (WEBER) by UMDD.BITNET (Mailer R2.03B) with BSMTP id 4779; Fri, 12 Jul 91 16:57:14 E Date: Fri, 12 Jul 91 16:32:10 EDT From: Karen Weber To: "x.500 & Fox" Please send me information pertaining to x.500 & Fox. Karen   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <3375-0@bells.cs.ucl.ac.uk>; Sun, 14 Jul 1991 08:34:59 +0100 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-2) id ; Sun, 14 Jul 91 00:34:17 -0700 Date: Sun, 14 Jul 91 00:33:21 PDT From: hotz@edu.ISI Posted-Date: Sun, 14 Jul 91 00:33:21 PDT Message-Id: <9107140733.AA02935@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Sun, 14 Jul 91 00:33:21 PDT To: dsar@edu.ISI Cc: osi-ds@uk.ac.ucl.cs Subject: Directory Services Activities Report 7/91 June 1991 Issue #4 Directory Services Activities ----------------------------- This report serves as a forum to distribute information about the various efforts working to develop directory services that are for, or effect, the Internet. It is published as part of the FOX Project's efforts to facilitate the coordination and cooperation of different directory services working groups. This report is distributed virtually unchanged as part of the Internet Monthly Report, and a modified version is submitted to the PARADISE International Report. We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. The current reporters list includes: o IETF OSIDS Working Group o IETF DISI Working Group [X] o Field Operational X.500 Project - ISI - Merit - PSI - SRI o National Institute of Standards and Technology [X] o North American Directory Forum [X] o OSI Implementor's Workshop o PARADISE Project o PSI DARPA/NNT X.500 Project o PSI WHITE PAGES PILOT o Registration Authority Committee (ANSI USA RAC) [X] o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) [X] [X] indicates no report this month To be added to the subscription list for this report, send a message to dsar-request@isi.edu. Steve Hotz (hotz@isi.edu) DS Report Coordinator IETF OSIDS WORKING GROUP ------------------------ The OSI-DS documents are now numbered as a document series. Two documents were released: OSI-DS 16: "Schema for NIC Profile information in X.500" Chris Weider & Mark Knopper June 1991 Abstract: The authors wish to put put up a readily accessible, distributed Directory of Network Information Centers, or NICs. This paper discusses the schema used to hold the NIC Profiles, as well as the DIT structure necessary for this information. OSI-DS 17: "Schema for Information Resource Description in X.500" Chris Weider May 1991 Abstract: The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. Preparation is underway for the next WG meeting at the IETF in Atlanta. Steve Hardcastle-Kille (s.kille@cs.ucl.ac.uk) FOX -- FIELD OPERATIONAL X.500 PROJECT -------------------------------------- The FOX project is a DARPA and NSF funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. ISI --- ISI organized the July 9 FOX phone conference, which included participants from all of the FOX contractors. FOX participants will meet sometime during the Atlanta IETF. Steve Hotz (hotz@ISI.EDU) MERIT ----- Some of the Merit activities related to X.500 and Directories which took place during June: o Work on schema definitions for NIC Profiles and Internet Online Resources, including internet drafts outlining that work. o Met with John Clement of Educom about directory of K-12 people and resources. Started schema definitions for those as well. o Began work to implement e-mail based query and updating system for K-12 for Educom. This will be a prototype for a later production system. o Received new workstation to use as DSA for FOX project activities. Mark Knopper (mak@merit.edu) PSI --- A new X.500-based application, "x5ftp", was released for alpha testing by FOX project partners. "x5ftp" is an X.500-based application that allows one to search a portion of the Directory for references to documents. The application then allows the selective retrieval of documents by anonymous ftp. "X5ftp" provides a command-shell interface to a complete X.500 DUA that is specially tailored for document retrieval. A paper which discusses the role of X.500 in information retrieval was written. This paper, published by PSI as Technical Report 91-06-25, is available for anonymous ftp from uu.psi.com [136.161.128.3] in wp/nir.ms (nroff/troff version, ms macros) wp/ps/nir.ps (Postscript version) and wp/nir.txt (text version). Wengyik Yeong (yeongw@psi.com) SRI --- We observed that the Northern Swift Fox DSA was core dumping given an inconsistent collection of circumstances. The problems were traced to a lack of swap space on the DSA's host. The system was reconfigured to increase swap space by approximately 25%. No similar problems have been observed. SRI began an investigation of options for providing a user interface to support access to the WHOIS information now stored in X.500. The decision as to a course of action is forthcoming in a subsequent report. A low-level investigation of problems with NIST's Custos 0.1.1 continued. Although original suspicions centered around ISODE version incompatibilities (Custos 0.1.1 was developed with ISODE 6.0 while SRI is running version 6.8), restoring ISODE 6.0 at SRI and subsequent recompilation of Custos 0.1.1 yielded no progress. NIST and SRI will continue their investigation, focusing on possible configuration differences. Work on the DISI X.500 implementation catalog continued. Ruth Lang and Russ Wright (LBL) have written a majority of the supporting sections that will accompany the implementation descriptions. A draft list of cross-reference keywords has been selected and applied to the descriptions. A formatted version of the document (Internet-Draft) will be made available before the July IETF meeting. Ruth Lang (rlang@nisc.sri.com) OIW --- The OSI Implementor's Workshop (OIW) Directory Service SIG met during June 10-13, 1991. There were about 20 attendees representing 15 vendors and users. It was a very productive meeting and the SIG generated the following outputs: o Access Control and Replication: The SIG generated draft working agreements on Access Control and Replication based on PDAMs and CD. For Access Control, the SIG created a table for error situations and error actions. For Replication, the SIG generated the DSA Replication Conformance and Recommended Practice sections. These agreements are expected to be stable by the end of 1991 when the standards reach DAM and DIS at the end of October, 1991. o Distributed Operations: The SIG generated draft working agreements on Distributed Operations based on the EWOS profile. These agreements do not include any extension work being developed in the standard body. o APDU size limit: The SIG agreed to change Result APDU size limit from 32K to 256K in order to align with the EWOS profile. This limit will only affect DSAs involved in distributed operations. This modification is expected to affect the Stable Agreements. o Pragmatic Constraints: The SIG agreed to change ub-postal-string for the Postal Address attribute syntax from 30 to 60 characters in order to accommodate many existing postal addresses. This change is expected to be made against the Stable Agreements at the next meeting. The SIG sent liaison letters to inform this change and to investigate if this change causes any problems to current Directory user groups. o Guideline on AE Title Use: Informative text was generated in order to guide applications making use of the AE Title field to access application Entity Objects in the Directory. Youbong Weon-Yoon (youbong@arch2.att.com) PARADISE -------- The public access "simple-to-use" PARADISE DUA is available for sampling on one of the project machines; use "telnet 128.86.8.56" and enter "dua" at the login prompt. Comments welcomed to the list Paradise INTerfaceS . The PARADISE packaged DSA and DUA should be available later this month and will be based on ISODE 7.0 which is due for release in mid-July. Interoperability tests are proceeding with the French pilot; the presentation level difficulty has been resolved and the twelve French organizations represented below c=FR are now visible. The QUIPU/PIZARRO discussion has some months to run yet. Inquiries about PIZARRO may be directed to: Paul-Andre Pays . Specific questions concerning the interoperability testing may be directed to: Paradise inteROPERability . David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager PSI DARPA/NNT X.500 Project --------------------------- Beta testing was performed on ISODE beta-release 6.9. Experimental versions of existing DSA and DUA software were tested. Testing was also performed to ensure that version 6.9 is backwards-compatible with version 6.8. Effort was expended in the past month to increase the reliability of operational X.500 service. To this end: o Watchdog scripts that ensure that processes related to the provision of X.500 service continue to run were written and installed. These scripts will be further enhanced in the future to detect more error conditions that cause denial of service. o Some shuffling of DSA functionality among machines was performed to better distribute the demands placed on various machines by the X.500 service. o An enhanced version of the ISODE software was installed on all machines to fix version skew problems and further enhance reliability. o A systematic schedule of monitoring the reliability of all machines that contribute to X.500 service was begun. Testing was performed, using some of the data in the "o=Performance Systems International" subtree, in preparation for alignment with the COSINE/Internet Naming Architecture. Final testing of a beta version of a White Pages front-end for PC/MSDOS that is layered over FTP Inc.'s PC/TCP kernel is almost completed. Anonymous FTP release of the binary is slated for the 1st week of July. Wengyik Yeong (yeongw@psi.com) PSI WHITE PAGES PILOT PROJECT ----------------------------- As of June 26, 1991, there are 76 organizations participating in the White Pages in the United States of America. New organizations added this past month are: Cornell University The practice of pruning non-responsive DSAs from the c=US arc has been temporarily suspended due to a change in people supporting the White Pages Manager function. Pruning will begin again next month. Wengyik Yeong (yeongw@psi.com)   Return-Path: Received: from earn-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <16773-0@bells.cs.ucl.ac.uk>; Mon, 15 Jul 1991 17:21:47 +0100 Received: from UKACRL by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 3070; Mon, 15 Jul 91 17:20:16 BST Received: from NERVM.NERDC.UFL.EDU by UKACRL.BITNET (Mailer R2.07) with BSMTP id 7910; Mon, 15 Jul 91 17:20:14 BS Received: from NERVM (NEMNM) by NERVM.NERDC.UFL.EDU (Mailer R2.08) with BSMTP id 1344; Mon, 15 Jul 91 12:18:04 E Date: Mon, 15 Jul 91 12:17:45 EDT From: Marcus Morgan Subject: subscribe Marcus N Morgan To: osi-ds@uk.ac.ucl.cs   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <11631-0@bells.cs.ucl.ac.uk>; Wed, 17 Jul 1991 06:18:45 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <1885-3@sun2.nsfnet-relay.ac.uk>; Wed, 17 Jul 1991 06:15:23 +0100 Received: from merit.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa09499; 17 Jul 91 5:52 BST Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA19612; Wed, 17 Jul 91 01:10:41 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA18989; Wed, 17 Jul 91 01:10:40 EDT From: mak@edu.merit Message-Id: <9107170510.AA18989@home.merit.edu> To: Karen Weber Cc: "x.500 & Fox" In-Reply-To: Your message of "Fri, 12 Jul 91 16:32:10 EDT." <9107122157.AA24614@merit.edu> Date: Wed, 17 Jul 91 01:10:39 -0400 Karen, Here is last month's report on directory related activities in the internet. This should be a start at what you need. Mark > From: Karen Weber > To: "x.500 & Fox" > > > Please send me information pertaining to x.500 & Fox. > Karen (Message inbox:3130) Received: from bells.cs.ucl.ac.uk by merit.edu (5.65/1123-1.0) id AA05908; Sun, 14 Jul 91 03:43:04 -0400 Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <3375-0@bells.cs.ucl.ac.uk>; Sun, 14 Jul 1991 08:34:59 +0100 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-2) id ; Sun, 14 Jul 91 00:34:17 -0700 Date: Sun, 14 Jul 91 00:33:21 PDT From: hotz@ISI.edu Posted-Date: Sun, 14 Jul 91 00:33:21 PDT Message-Id: <9107140733.AA02935@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Sun, 14 Jul 91 00:33:21 PDT To: dsar@ISI.edu Cc: osi-ds@cs.ucl.ac.uk Subject: Directory Services Activities Report 7/91 June 1991 Issue #4 Directory Services Activities ----------------------------- This report serves as a forum to distribute information about the various efforts working to develop directory services that are for, or effect, the Internet. It is published as part of the FOX Project's efforts to facilitate the coordination and cooperation of different directory services working groups. This report is distributed virtually unchanged as part of the Internet Monthly Report, and a modified version is submitted to the PARADISE International Report. We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. The current reporters list includes: o IETF OSIDS Working Group o IETF DISI Working Group [X] o Field Operational X.500 Project - ISI - Merit - PSI - SRI o National Institute of Standards and Technology [X] o North American Directory Forum [X] o OSI Implementor's Workshop o PARADISE Project o PSI DARPA/NNT X.500 Project o PSI WHITE PAGES PILOT o Registration Authority Committee (ANSI USA RAC) [X] o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) [X] [X] indicates no report this month To be added to the subscription list for this report, send a message to dsar-request@isi.edu. Steve Hotz (hotz@isi.edu) DS Report Coordinator IETF OSIDS WORKING GROUP ------------------------ The OSI-DS documents are now numbered as a document series. Two documents were released: OSI-DS 16: "Schema for NIC Profile information in X.500" Chris Weider & Mark Knopper June 1991 Abstract: The authors wish to put put up a readily accessible, distributed Directory of Network Information Centers, or NICs. This paper discusses the schema used to hold the NIC Profiles, as well as the DIT structure necessary for this information. OSI-DS 17: "Schema for Information Resource Description in X.500" Chris Weider May 1991 Abstract: The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. Preparation is underway for the next WG meeting at the IETF in Atlanta. Steve Hardcastle-Kille (s.kille@cs.ucl.ac.uk) FOX -- FIELD OPERATIONAL X.500 PROJECT -------------------------------------- The FOX project is a DARPA and NSF funded effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. ISI --- ISI organized the July 9 FOX phone conference, which included participants from all of the FOX contractors. FOX participants will meet sometime during the Atlanta IETF. Steve Hotz (hotz@ISI.EDU) MERIT ----- Some of the Merit activities related to X.500 and Directories which took place during June: o Work on schema definitions for NIC Profiles and Internet Online Resources, including internet drafts outlining that work. o Met with John Clement of Educom about directory of K-12 people and resources. Started schema definitions for those as well. o Began work to implement e-mail based query and updating system for K-12 for Educom. This will be a prototype for a later production system. o Received new workstation to use as DSA for FOX project activities. Mark Knopper (mak@merit.edu) PSI --- A new X.500-based application, "x5ftp", was released for alpha testing by FOX project partners. "x5ftp" is an X.500-based application that allows one to search a portion of the Directory for references to documents. The application then allows the selective retrieval of documents by anonymous ftp. "X5ftp" provides a command-shell interface to a complete X.500 DUA that is specially tailored for document retrieval. A paper which discusses the role of X.500 in information retrieval was written. This paper, published by PSI as Technical Report 91-06-25, is available for anonymous ftp from uu.psi.com [136.161.128.3] in wp/nir.ms (nroff/troff version, ms macros) wp/ps/nir.ps (Postscript version) and wp/nir.txt (text version). Wengyik Yeong (yeongw@psi.com) SRI --- We observed that the Northern Swift Fox DSA was core dumping given an inconsistent collection of circumstances. The problems were traced to a lack of swap space on the DSA's host. The system was reconfigured to increase swap space by approximately 25%. No similar problems have been observed. SRI began an investigation of options for providing a user interface to support access to the WHOIS information now stored in X.500. The decision as to a course of action is forthcoming in a subsequent report. A low-level investigation of problems with NIST's Custos 0.1.1 continued. Although original suspicions centered around ISODE version incompatibilities (Custos 0.1.1 was developed with ISODE 6.0 while SRI is running version 6.8), restoring ISODE 6.0 at SRI and subsequent recompilation of Custos 0.1.1 yielded no progress. NIST and SRI will continue their investigation, focusing on possible configuration differences. Work on the DISI X.500 implementation catalog continued. Ruth Lang and Russ Wright (LBL) have written a majority of the supporting sections that will accompany the implementation descriptions. A draft list of cross-reference keywords has been selected and applied to the descriptions. A formatted version of the document (Internet-Draft) will be made available before the July IETF meeting. Ruth Lang (rlang@nisc.sri.com) OIW --- The OSI Implementor's Workshop (OIW) Directory Service SIG met during June 10-13, 1991. There were about 20 attendees representing 15 vendors and users. It was a very productive meeting and the SIG generated the following outputs: o Access Control and Replication: The SIG generated draft working agreements on Access Control and Replication based on PDAMs and CD. For Access Control, the SIG created a table for error situations and error actions. For Replication, the SIG generated the DSA Replication Conformance and Recommended Practice sections. These agreements are expected to be stable by the end of 1991 when the standards reach DAM and DIS at the end of October, 1991. o Distributed Operations: The SIG generated draft working agreements on Distributed Operations based on the EWOS profile. These agreements do not include any extension work being developed in the standard body. o APDU size limit: The SIG agreed to change Result APDU size limit from 32K to 256K in order to align with the EWOS profile. This limit will only affect DSAs involved in distributed operations. This modification is expected to affect the Stable Agreements. o Pragmatic Constraints: The SIG agreed to change ub-postal-string for the Postal Address attribute syntax from 30 to 60 characters in order to accommodate many existing postal addresses. This change is expected to be made against the Stable Agreements at the next meeting. The SIG sent liaison letters to inform this change and to investigate if this change causes any problems to current Directory user groups. o Guideline on AE Title Use: Informative text was generated in order to guide applications making use of the AE Title field to access application Entity Objects in the Directory. Youbong Weon-Yoon (youbong@arch2.att.com) PARADISE -------- The public access "simple-to-use" PARADISE DUA is available for sampling on one of the project machines; use "telnet 128.86.8.56" and enter "dua" at the login prompt. Comments welcomed to the list Paradise INTerfaceS . The PARADISE packaged DSA and DUA should be available later this month and will be based on ISODE 7.0 which is due for release in mid-July. Interoperability tests are proceeding with the French pilot; the presentation level difficulty has been resolved and the twelve French organizations represented below c=FR are now visible. The QUIPU/PIZARRO discussion has some months to run yet. Inquiries about PIZARRO may be directed to: Paul-Andre Pays . Specific questions concerning the interoperability testing may be directed to: Paradise inteROPERability . David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager PSI DARPA/NNT X.500 Project --------------------------- Beta testing was performed on ISODE beta-release 6.9. Experimental versions of existing DSA and DUA software were tested. Testing was also performed to ensure that version 6.9 is backwards-compatible with version 6.8. Effort was expended in the past month to increase the reliability of operational X.500 service. To this end: o Watchdog scripts that ensure that processes related to the provision of X.500 service continue to run were written and installed. These scripts will be further enhanced in the future to detect more error conditions that cause denial of service. o Some shuffling of DSA functionality among machines was performed to better distribute the demands placed on various machines by the X.500 service. o An enhanced version of the ISODE software was installed on all machines to fix version skew problems and further enhance reliability. o A systematic schedule of monitoring the reliability of all machines that contribute to X.500 service was begun. Testing was performed, using some of the data in the "o=Performance Systems International" subtree, in preparation for alignment with the COSINE/Internet Naming Architecture. Final testing of a beta version of a White Pages front-end for PC/MSDOS that is layered over FTP Inc.'s PC/TCP kernel is almost completed. Anonymous FTP release of the binary is slated for the 1st week of July. Wengyik Yeong (yeongw@psi.com) PSI WHITE PAGES PILOT PROJECT ----------------------------- As of June 26, 1991, there are 76 organizations participating in the White Pages in the United States of America. New organizations added this past month are: Cornell University The practice of pruning non-responsive DSAs from the c=US arc has been temporarily suspended due to a change in people supporting the White Pages Manager function. Pruning will begin again next month. Wengyik Yeong (yeongw@psi.com)   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <26262-0@bells.cs.ucl.ac.uk>; Wed, 17 Jul 1991 09:31:57 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Revision of The COSINE and Internet X.500 Schema Phone: +44-71-380-7294 Date: Wed, 17 Jul 91 09:31:55 +0100 Message-ID: <1074.679739515@UK.AC.UCL.CS> From: Steve Hardcastle-Kille This is also in the UCL archives. There are some changes on handling object identifiers, and a few new attributes. Steve ------- Forwarded Message From: Debra Legare To: ietf@edu.ISI Subject: ID ACTION:draft-ietf-osids-cosinex500-04.txt Date: Tue, 16 Jul 91 10:56:14 -0400 A Revised Internet Draft is available from the on-line Internet-Drafts directories. Title : The COSINE and Internet X.500 Schema Author(s) : P. Barker, S. Kille Filename : draft-ietf-osids-cosinex500-04.txt This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema. This document also proposes a mechanism for allowing the schema to evolve in line with commonly held requirements. Proform as to support this process are included. Please send comments to the authors or to the discussion group osi-ds@cs.ucl.ac.uk. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, type "cd internet-drafts". Type "get draft-ietf-osids-cosinex500-04.txt". Internet-Drafts directories are located at: o NSF Network Service Center (East Coast) Address: nnsc.nsf.net (192.31.103.6) o Defense Data Network NIC (West Coast) Address: nic.ddn.mil (192.67.67.20) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Nordunet NIC (Europe) Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: SERVICE@nic.ddn.mil Subject line: SEND INTERNET-DRAFTS:draft-ietf-osids-cosinex500-04.txt For questions, please mail to internet-drafts@nri.reston.va.us. ------- End of Forwarded Message   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4771-0@bells.cs.ucl.ac.uk>; Wed, 17 Jul 1991 16:56:59 +0100 To: osi-ds@uk.ac.ucl.cs Subject: I gather that some of you may not have seen this! Phone: +44-71-380-7294 Date: Wed, 17 Jul 91 16:56:50 +0100 Message-ID: <3729.679766210@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Steve ------- Forwarded Message From: ietf-rsvp@NRI.Reston.VA.US To: ietf@ISI.EDU Subject: Mailing 2: IETF, July 29-Aug. 2, 1991/Atlanta Date: Thu, 27 Jun 91 14:42:48 -0400 Dear IETFers: This is the second mailing of logistics for the upcoming IETF (Jul. 29 - Aug. 2, 1991/ Atlanta). The Agenda is still being pulled together and will be mailed separately. Please direct any questions to ietf-rsvp@nri.reston.va.us. NOTE: Remember, July 5th is the cut-off date for early registration. Included in this mailing are the following: 1. AT-A-GLANCE SHEET: A one page write-up of pertinent information (i.e., Dates, Registration Info., Hotel, Airline, Shuttle) 2. Registration Form: We are accepting payment by credit card and check. Please be sure to read the form carefully and provide complete information. 3. Directions: From the Airport to the Hyatt and to the Hilton. FYI... Just a reminder that the quality of these meetings (and in particular the Working Group technical *working* sessions) is dependent upon the informed, constructive participation of the individual attendees. Please come prepared. Information on the current status and progress of the individual Working Groups can be obtained in several ways: 1. Working Group objectives and notes from previous sessions are available online (send to ietf-manager@nri.reston.va.us for retrieval instructions). 2. Working Group objectives and notes from previous meetings are also reproduced in the hardcopy Proceedings (to order, send to proceedings@nri.reston.va.us). 3. Agendas and reading lists for Working Group meetings will also be posted to the respective Working Group mailing lists. LOOKING AHEAD.... The November 1991 IETF Meeting will be held in Santa Fe, NM. Our host for this meeting will be John Morrison and Dale Land of Los Alamos National Labs. The Spring 1992 IETF is tentatively scheduled to be hosted by San Diego Supercomputer Center. - -------------- 21ST INTERNET ENGINEERING TASK FORCE Mailing Date : 6/27/91 AT-A-GLANCE Mailing Number: 2 DATE: July 29 - August 2, 1991 HOST(S): Caroline Cranfill BellSouth Telecommunications, Inc. HOTEL/MEETING SITE: Hyatt Regency Atlanta 265 Peachtree Street, NE Atlanta, GA 30301 (404) 577-1234 {fax:(404) 588-3752} 150 Rooms reserved until July 5, 1991 $89.00/single or double Specify: IETF or CNRI GROUP ALTERNATE ACCOM: The Atlanta Hilton 255 Courtland Street, NE Atlanta, GA 30303 (404) 222-2800 {fax: (404) 222-2868} 20 Rooms reserved until July 5, 1991 $89.00/single or double Specify: IETF or CNRI Group MESSAGES: A Message Board will be set up near the registration area. Please have all messages reference IETF Group. PRE-REGISTRATION: Sunday, July 28, 1991 6pm - 8pm (reception during) Hyatt Regency Atlanta Room: Continental South REGISTRATION: Monday, July 29, 1991 8am - 9am Hyatt Regency Atlanta Room: Outside the Continental South ATTENDANCE FEE: PAYMENT BY: Credit Card or Check $130.00 if received BY July 5, 1991 $150.00 if received AFTER July 5, 1991 AIRLINE: Delta Airlines (special rate roundtrip only) 1 (800) 221-1212 File No: T12112 (IETF) We regret that discounted fares are not available for international flights. United Airlines (special rate roundtrip only) 1 (800) 521-4041 Meeting ID: 515CX (IETF) We regret that discounted fares are not available for international flights. CAR RENTAL: Alamo Discounts available through Delta. Hertz Discounts available through United. AIRPORT: Hartfield International Airport SHUTTLE: Hyatt: Complimentary, runs every 20 minutes from the Airport, you may pick it up from the north side of baggage claim. Hilton: Uses "Airport Shuttle" $8.00/each way, leaves the Airport frequently PARKING: Hyatt : $9.00/day (valet). Hilton: $7.00/day (self-service). - ---- REGISTRATION FORM 21st Internet Engineering Task Force - Page 1 of 2 July 29 - August 2, 1991 Atlanta, GA Please print or type: Name (Mr/Dr/Ms)__________________________________________________________ Title____________________________________________________________________ Organization_____________________________________________________________ Address__________________________________________________________________ City_______________________________State______________Zip Code___________ Telephone______________________________Fax_______________________________ Email____________________________________________________________________ Please check a) and b) below so we can identify your organization type and interest. a) Organization Type ___HW/SW Vendor ___Government ___Network Provider ___University ___Other (_______________________) b) Your interest in 21st IETF Meeting: ___Network Operator ___Network User ___Product Developer ___Researcher ___Other (________________) Do you plan to attend the Sunday, July 28, 1991 evening reception? YES___ NO___ $130.00 Registration postmarked by July 5, 1991 $150.00 ($130.00 + $20.00 late fee) Registration postmarked after July 5, 1991 Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check enclosed (U.S. dollars, drawn on a U.S. Bank), payable to: Corporation for National Research Initiatives Account No.____________________________ Expiration Date__________________ Cardholder Signature_____________________________________________________ Please return a copy of the Registration Form with your payment today to take advantage of the reduced rate of $130.00 and mail to: Corporation for National Research Initiatives Accounting Department - 21st IETF Meeting 1895 Preston White Drive, Suite 100 Reston, VA 22091-5434 REGISTRATION FORM 21st Internet Engineering Task Force - Page 2 of 2 July 29 - August 2, 1991 Atlanta, GA IMPORTANT: 1. Advance Registrations must be postmarked no later than July 5, 1991. 2. Register one person per form. No substitutions are allowed. 3. Request for refunds must be received by July 26, 1991. 4. Refund policy: Refunds are subject to a $20.00 service charge. Late fees will not be refunded. 5. Your registration fee includes a copy of the Meeting's Proceedings, Sunday evening reception (cash bar), and a daily continental breakfast and coffee breaks. Please contact (703) 620-8990 or (703) 620-0913 (Fax) for additional information or assistance. Direct all inquiries to: 21st IETF meeting - Atlanta. - ----------- Directions from the Hartfield International Airport to the Atlanta Hilton: Take 85 North to the International Boulevard Exit. Keep to the left off of the exit ramp to pick up International Boulevard. Turn right off of International Boulevard onto Piedmont (one way North). Turn left onto Baker (one way West). Turn left onto Courtland (one way South). Directions from the Hartfield International Airport to the Hyatt Regency: Take 85 North to the International Boulevard Exit. Turn right off of International onto W. Peachtree Street (one way North). The Hyatt is up a block or so on the left (underground parking on left too). NOTE: Parking at both Hotels is expensive (see At-A-Glance). There are Shuttles that run between both hotels and the Airport, and the MARTA Rail goes directly from the Airport to the Hyatt Regency. ------- End of Forwarded Message   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Mon, 22 Jul 1991 12:54:00 +0100 Date: Mon, 22 Jul 1991 11:54:00 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.792:22.06.91.11.54.00] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Mon, 22 Jul 1991 12:53:55 +0100) From: Colin Robbins Message-ID: <"10239 Mon Jul 22 12:52:25 1991"@xtel.co.uk> To: osi-ds@uk.ac.ucl.cs, quipu@uk.ac.ucl.cs Cc: piz-support@fr.emse Subject: Presentation Layer in ISODE-6.0 ISODE 7.0 has recently been announced. As far as we can tell it is fully backwards compatible with ISODE-6.0, 6.1 and 6.8. However, a problem in the presentation layer was found after the 6.8 release. This means that ISODE-6.8 and previous releases, do not always conform to the relevant standards. The problem mainly affects QUIPU. This problem has been fixed in version 7.0. To maintain interworking with older versions of QUIPU, the 'broken' protocol is still recognised by this version of ISODE. In future releases of the ISODE, this backwards compatibility will be removed. The ASN.1 giving the trouble is in the User-data in a presentation PDU: User-data ::= CHOICE { simple [APPLICATION 0] IMPLICIT Simply-encoded-data, complex [APPLICATION 1] IMPLICIT Fully-encoded-data } The User-data should be Simply-encoded-data when the default context is used, or when there is only one context defined. If the default context is not used, Fully-encoded-data should be used. Prior to the 7.0 release, ISODE incorrectly used Fully-encoded-data when the default context was in use. In 7.0 the correct choice should be made. The purpose of this message is to warn other directory implementations. If you have interworked with QUIPU in the past, you should carefully check this part of the protocol. You should still be able to interwork with the 7.0 release, BUT the compatibility code will be removed for the next version, so if any code fixes are need, the wheels should be set into motion now. Colin   Return-Path: Received: from gsbs.gs.uth.tmc.edu.16.106.129.IN-ADDR.arpa by bells.cs.ucl.ac.uk with SMTP inbound id <5959-0@bells.cs.ucl.ac.uk>; Mon, 22 Jul 1991 13:55:02 +0100 Received: by gsbs.gs.uth.tmc.edu (4.1/SMI-4.1) id AA02722; Mon, 22 Jul 91 07:55:53 CDT Date: Mon, 22 Jul 91 07:55:53 CDT From: dvale@edu.tmc.uth.gs.gsbs (David L. Vale) Message-Id: <9107221255.AA02722@gsbs.gs.uth.tmc.edu> To: osi-ds@uk.ac.ucl.cs Subject: x.500(FOX Project) info Please add me to your mailing list; David Vale UTOAC PO Box 20334 Houston TX 77005 thanks   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <24462-0@bells.cs.ucl.ac.uk>; Tue, 23 Jul 1991 11:11:15 +0100 To: osi-ds@uk.ac.ucl.cs Cc: internet-drafts@us.va.reston.nri Subject: Revised Naming Guidelines Document Phone: +44-71-380-7294 Date: Tue, 23 Jul 91 11:11:12 +0100 Message-ID: <1878.680263872@UK.AC.UCL.CS> From: Steve Hardcastle-Kille A revision is now available. I'm afraid that I've not been able to generate a text version! Steve OSI-DS 12 structure.ps P. Barker S.E. Kille July 1991 Naming Guidelines for Directory Pilots Abstract: Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTP, NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to bells, computer science, university college london, gb username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25656-0@bells.cs.ucl.ac.uk>; Tue, 23 Jul 1991 11:55:29 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Agenda V3 Phone: +44-71-380-7294 Date: Tue, 23 Jul 91 11:55:28 +0100 Message-ID: <2140.680266528@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Agenda for fifth meeting of IETF Directory Services Group Version 3 S.E. Kille July 23, 1991 Date Monday 29th July, 9:30 -- 15:30 Venue IETF Bell South Atlanta, GA Draft agenda follows. 1 Session 1 9:30 Introduction o Agenda o Minutes of SRI Meeting (OSI-DS-MINUTES 3) o Minutes of Videoconference (OSI-DS-MINUTES 4) o Matters arising 9:50 Liaisons o RARE WG3 (Erik Huizer) o ISO/CCITT (?) o OIW (Russ Wright) o NADF (Marshall Rose) 1 10:10 Operational status of pilots o FOX (Steve Hotz) o PSI WPP (Wengyik Yeong) o Paradise (Steve Kille) o AARN 10:25 CNI WG on Directories (George Brett) Note: If the first part of the agenda is completed early (which will happen if possible), we will start on the agenda for Session 2. 10:45 Coffee 11:00 Document progression to RFC. (Ross Callon/Vint Cerf) 11:20 OID assignment, Delegation of Schema Authority, OID Changes. (OSI-DS 10, RFC 1239) 11:40 Requirements Specification (OSI-DS 18) 12:00 Lunch 2 Session 2 13:30 Resource description (OSI-DS 17) 14:00 NIC Profile information (OSI-DS 16, OSI-DS 19) 14:15 Representing Pictures in the directory (Russ Wright) 14:40 Quality of Service (OSI-DS 15) 15:00 Naming Guidelines (OSI-DS 12) 15:10 DSA Naming (OSI-DS 13) 15:20 AOB 15:30 End (Tea) 2   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <26018-0@bells.cs.ucl.ac.uk>; Tue, 23 Jul 1991 12:10:00 +0100 To: osi-ds@uk.ac.ucl.cs, internet-drafts@us.va.reston.nri Subject: Cosine and Internet X.500 Schema Phone: +44-71-380-7294 Date: Tue, 23 Jul 91 12:09:59 +0100 Message-ID: <2235.680267399@UK.AC.UCL.CS> From: Steve Hardcastle-Kille We are just about to submit a revised version. This is technincally equivalent to the previous version, but has some long lines folded to improve readability. Steve   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <14767-0@bells.cs.ucl.ac.uk>; Wed, 24 Jul 1991 19:25:32 +0100 Return-Path: Received: from mazatzal.merit.edu by merit.edu (5.65/1123-1.0) id AA17170; Wed, 24 Jul 91 14:26:06 -0400 Received: by mazatzal.merit.edu (5.65/client-0.9) id AA00973; Wed, 24 Jul 91 14:25:08 -0400 Date: Wed, 24 Jul 91 14:25:08 -0400 From: clw@edu.merit Message-Id: <9107241825.AA00973@mazatzal.merit.edu> To: osi-ds@uk.ac.ucl.cs Subject: New paper from FOX, K-12 educator schema.... Steve and the rest of the world... Here is a paper on schema for a directory of educators and educator-related resources. Steve, could you please give me a osi-ds document number for this? How long should I wait before we can send it on to the Internet Draft archive? Chris Weider OSI-Directory Services Working Group Chris Weider INTERNET-DRAFT Mark Knopper Merit Network July 1991 X.500 Schema for a pilot Educator's Directory Service Status of this Memo From kindergarden to graduate school, educators are placing more and more emphasis on computers, computer techniques, and computer networks. As these concepts become more pervasive, the Internet is being seen as a valuable tool for students and educators who previously had neither the resources nor the time to become involved in computers. To enhance and support the resources currently available to and for educators on the Internet, Merit and Educom would like to implement a directory of educators and resources using the X.500 protocol. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group osi-ds@cs.ucl.ac.uk. INTERNET-DRAFT X.500 Schema for Educator Directory July 1991 SECTION 1: PRELIMINARIES 1.1 Introduction As computers and computer concepts become more pervasive in the K-12 arena, educators and students alike are using the Internet to communicate with each other and to tap into online computerized resources, expanding their range of educational possibilities and teaching computer literacy. A directory of educators with Internet access and a directory of resources available on the Internet would therefore enhance the usefulness of the Internet to educators. Educom has been informally keeping a paper directory of educators, areas of interest, and resources for some time now, and they have provided the motivation and definitions for the schema in this paper. 1.2 Information to be incorporated The information to be incorporated breaks down into 5 groups; 1 group contains person-related information, and the rest contain resource-related information. As a reflection of a new philosophy of object class definition, the new object class for the additional person information will be an 'auxiliary' class. 1.2.1 A new auxiliary person object. A new object class, educatorAuxiliaryPerson, will be created. A typical educator's EDB entry will therefore have as superclasses both 'pilotPerson' and 'educatorAuxiliaryPerson'. The educatorAuxiliaryPerson object class will contain the following new attributes: areaOfInterest: one of a list of keywords (yet to be determined) which describe in a 'standardized' way the areas in which the person works or would like to exchange information on. gradeLevel: one of: 1) the grade the person teaches or 2) the grade level(s) the person is interested in. dateOfCreation: a UTC string which contains the date the entry was created. Note that this is different from the lastModifiedDate attribute. personalComments: a long string in which the person can place a bit of information about themselves. department: an attribute which tells which department the educator is in. 1.2.2 New resource objects There are 4 new types of resources object, which have names which do not reflect the 'educator' structure as they are intended to have a wide range of applicability. 1) the listResource object class. This object class is intended to hold information about the various lists which are available, for example, if someone maintained online a list of support organizations for educators, there would be a directory entry for it. This will be a subclass of the pilotObject class and will contain the following new attributes: INTERNET-DRAFT X.500 Schema for Educator Directory July 1991 numberOfEntries: a string containing an (approximate) number of entries. listOf: a string describing the type of entries (i.e. what this is a list of) howToGetList: a string telling how to get the list. onlineAvailability: a string containing 'yes' or 'no. There are additional attributes which are described in detail in Weid[91], see the object class definition for a complete listing. 2) the newsGroup object class. This will contain directory information about any news groups that wish to be listed; for example, a news group which focuses on Space Science. This will also be a subclass of the pilotObject class and will contain the following new attributes: numberOfMembers: a string containing the number of members. affiliatedOrganization: a string containing the name of the affiliated organization (if any). associatedMailingList: a string containing the e-mail address of the associated mailing list (if any). There are additional attributes, which are described in Weid[91] and in the classes above. See the object class definition for a complete listing. 3) the educationalNetwork object class. This will contain information about the educational networks available (e.g. FIDONet). This will be a subclass of the pilotObject class and will contain the following new attributes: geographicalRegion: a string which contains the geographical region which the network covers. There are additional attributes, which are described in Weid[91] and in the classes above. See the object class definition for a complete listing. 4) educatorServiceProvider. This will be a subclass of the Organization object class and will contain the servicesOffered and publicationsOffered attributes from Weid[91]. It will contain directory type information about organizations which provide services for educators (e.g. educational publishers, union organizations, etc). SECTION 2: SCHEMA DESIGN 2.1 ASN.1 definitions for the new attributes. __ __ __ __ __ __ __ __ __ __ areaOfInterest ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-area)) ub-area INTEGER ::= 256 INTERNET-DRAFT X.500 Schema for Educator Directory July 1991 gradeLevel ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-grade)) ub-grade INTEGER ::= 64 dateOfCreation ATTRIBUTE WITH ATTRIBUTE SYNTAX UTCTime (SIZE (1 .. ub-dateoc)) ub-dateoc INTEGER ::= 128 personalComments ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-openarea)) ub-openarea INTEGER ::= 1024 numberOfEntries ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-noe)) ub-noe INTEGER ::= 128 listOf ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-listof)) ub-listof INTEGER ::= 512 howToGetList ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-howtoget)) ub-howtoget INTEGER ::= 2048 onlineAvailability ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-online)) ub-online INTEGER ::= 16 numberOfMembers ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-numberofmems)) ub-numberofmems INTEGER ::= 64 affiliatedOrganization ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-affiliate)) INTERNET-DRAFT X.500 Schema for Educator Directory July 1991 ub-affiliate INTEGER ::= 256 associatedMailingList ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-assocmaillist)) ub-assocmaillist INTEGER ::= 256 geographicalRegion ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-georegion)) ub-georegion INTEGER ::= 256 department ATTRIBUTE WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax (SIZE (1 .. ub-department)) ub-department INTEGER ::= 256 __ __ __ __ __ __ __ __ __ __ ASN.1 description of new attributes 2.2 New object classes Here follows the ASN.1 definitions of the new object classes: __ __ __ __ __ __ __ __ __ __ educatorAuxiliaryPerson OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { dateOfCreation } MAY CONTAIN { areaOfInterest, gradeLevel, personalComments, department } listResource OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName, listOf } MAY CONTAIN { numberOfEntries, howToGetList, onlineAvailability, producerOfResource, distributorOfResource, contactName, telephoneNumber, postalAddress } newsGroup OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName } MAY CONTAIN { numberOfMembers, affiliatedOrganization, contactName, associatedMailingList, postalAddress, telephoneNumber, servicesOffered, publicationsOffered } educationalNetwork OBJECT-CLASS SUBCLASS OF pilotObject MUST CONTAIN { commonName } MAY CONTAIN { geographicalRegion, logonOrSubscriptionInstructions, logoffOfUnsubscribeInstructions, contactName, telephoneNumber, postalAddress, costOfUse, servicesOffered, publicationsOffered} INTERNET-DRAFT X.500 Schema for Educator Directory July 1991 serviceProvider OBJECT-CLASS SUBCLASS OF organization MUST CONTAIN { } MAY CONTAIN { servicesOffered, publicationsOffered } ASN.1 definitions for the new object classes. __ __ __ __ __ __ __ __ __ __ SECTION 3: WHO WE ARE 3.1 Author's addresses Chris Weider, clw@merit.edu Mark Knopper, mak@merit.edu Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109 SECTION 4: REFERENCE(S) Weid[91] Weider, C. and Knopper, M. INTERNET-DRAFT Schema for Information Resource Description in X.500; in Internet Draft archive nnsc.nsf.net as draft-osids-resdescripx500.   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <7827-0@bells.cs.ucl.ac.uk>; Wed, 24 Jul 1991 22:00:00 +0100 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA03425; Wed, 24 Jul 91 15:59:27 -0400 Message-Id: <9107241959.AA03425@terminator.cc.umich.edu> To: clw@edu.merit Cc: osi-ds@uk.ac.ucl.cs Subject: Re: New paper from FOX, K-12 educator schema.... In-Reply-To: Your message of "Wed, 24 Jul 91 14:25:08 EDT." <9107241825.AA00973@mazatzal.merit.edu> Date: Wed, 24 Jul 91 15:59:28 -0400 From: Tim Howes > X.500 Schema for a pilot Educator's Directory Service > > personalComments ATTRIBUTE > WITH ATTRIBUTE SYNTAX > caseIgnoreStringSyntax > (SIZE (1 .. ub-openarea)) > > ub-openarea INTEGER ::= 1024 > ... > howToGetList ATTRIBUTE > WITH ATTRIBUTE SYNTAX > caseIgnoreStringSyntax > (SIZE (1 .. ub-howtoget)) > > ub-howtoget INTEGER ::= 2048 We really need a MultiLineCaseIgnoreString attribute type or something similar for stuff like this, don't you think? -- Tim   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <11043-0@bells.cs.ucl.ac.uk>; Wed, 24 Jul 1991 22:19:32 +0100 Return-Path: Received: from mazatzal.merit.edu by merit.edu (5.65/1123-1.0) id AA20628; Wed, 24 Jul 91 16:03:22 -0400 Received: by mazatzal.merit.edu (5.65/client-0.9) id AA01022; Wed, 24 Jul 91 16:02:24 -0400 Date: Wed, 24 Jul 91 16:02:24 -0400 From: clw@edu.merit Message-Id: <9107242002.AA01022@mazatzal.merit.edu> To: Tim.Howes@edu.umich.cc.terminator, clw@edu.merit Subject: Re: New paper from FOX, K-12 educator schema.... Cc: osi-ds@uk.ac.ucl.cs Yes, we do, Tim. That's an excellent idea. Chris From Tim.Howes@terminator.cc.umich.edu Wed Jul 24 15:59:35 1991 Received: from terminator.cc.umich.edu by merit.edu (5.65/1123-1.0) id AA20495; Wed, 24 Jul 91 15:59:31 -0400 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA03425; Wed, 24 Jul 91 15:59:27 -0400 Message-Id: <9107241959.AA03425@terminator.cc.umich.edu> To: clw@merit.edu Cc: osi-ds@cs.ucl.ac.uk Subject: Re: New paper from FOX, K-12 educator schema.... In-Reply-To: Your message of "Wed, 24 Jul 91 14:25:08 EDT." <9107241825.AA00973@mazatzal.merit.edu> Date: Wed, 24 Jul 91 15:59:28 -0400 From: Tim Howes > X.500 Schema for a pilot Educator's Directory Service > > personalComments ATTRIBUTE > WITH ATTRIBUTE SYNTAX > caseIgnoreStringSyntax > (SIZE (1 .. ub-openarea)) > > ub-openarea INTEGER ::= 1024 > ... > howToGetList ATTRIBUTE > WITH ATTRIBUTE SYNTAX > caseIgnoreStringSyntax > (SIZE (1 .. ub-howtoget)) > > ub-howtoget INTEGER ::= 2048 We really need a MultiLineCaseIgnoreString attribute type or something similar for stuff like this, don't you think? -- Tim   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <27457-0@bells.cs.ucl.ac.uk>; Thu, 25 Jul 1991 09:59:50 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA15491; Thu, 25 Jul 91 10:56:21 +0200 Message-Id: <9107250856.AA15491@mitsou.inria.fr> To: osi-ds Cc: clw@edu.merit, osi-ds@uk.ac.ucl.cs Subject: Re: New paper from FOX, K-12 educator schema.... In-Reply-To: Your message of 24 Jul 91 15:59:28 -0400. <9107241959.AA03425@terminator.cc.umich.edu> Date: Thu, 25 Jul 91 10:55:56 BST From: Christian Huitema > >> howToGetList ATTRIBUTE >> WITH ATTRIBUTE SYNTAX >> caseIgnoreStringSyntax >> (SIZE (1 .. ub-howtoget)) >> >> ub-howtoget INTEGER ::= 2048 > >We really need a MultiLineCaseIgnoreString attribute type or something >similar for stuff like this, don't you think? -- Tim Why not use: caseIgnoreListSyntax ATTRIBUTE SYNTAX SEQUENCE OF CHOICE {T61String, PrintableString} MATCHES FOR EQUALITY SUBSTRINGS ::= {attributeSyntax 7} As defined in X.519 section 2? Christian Huitema   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <10436-0@bells.cs.ucl.ac.uk>; Thu, 25 Jul 1991 17:45:33 +0100 To: clw@edu.merit cc: osi-ds@uk.ac.ucl.cs Subject: Re: New paper from FOX, K-12 educator schema.... Phone: +44-71-380-7294 In-reply-to: Your message of Wed, 24 Jul 91 14:25:08 -0400. <9107241825.AA00973@mazatzal.merit.edu> Date: Thu, 25 Jul 91 17:45:34 +0100 Message-ID: <3607.680460334@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I have assigned OSI-DS 20. I think that we should discuss the general issues rather than the details under the Resource Description agenda item. Steve   Return-Path: Received: from HAC2ARPA.HAC.com by bells.cs.ucl.ac.uk with SMTP inbound id <12901-0@bells.cs.ucl.ac.uk>; Thu, 25 Jul 1991 19:23:13 +0100 Received: by hac2arpa.hac.com (5.61++/SMI-DDN) id AA06602; Thu, 25 Jul 91 11:21:09 -0700 Date: Thu, 25 Jul 91 11:21:09 -0700 From: lthomson@com.hac.hac2arpa (Louisa L. Thomson) Message-Id: <9107251821.AA06602@hac2arpa.hac.com> To: osi-ds@uk.ac.ucl.cs Subject: add me to mailing list Hi, Please add me to your mailing list. My address is lthomson@hac2arpa.hac.com. Thanks.   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <5661-0@bells.cs.ucl.ac.uk>; Fri, 26 Jul 1991 10:52:34 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 26 Jul 91 10:52:29 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 12th July - Friday 26th July Probes from UCL, ULCC, STC, MRP of Adelaide, and now from GMD in Berlin. (Thank you for joining in!) Bind Fail %age Best Worst Ave Address CA: Beluga Whale (Canada Master) 63 2 96.83 0.1 0.1 0.10 dsa_available 63 2 96.83 3.8 165.8 34.58 Internet Pangolin (Northern Telecom Master) 216 10 95.37 0.1 0.1 0.10 dsa_available 64 3 95.31 1.4 77.0 12.74 Private TCP 190 13 93.16 3.1 28.1 16.61 Internet Wayne Gretzky, zebulon@ccs.uwo.ca, +1 519-661-3342 190 190 0.00 - - - dsa_available 190 190 0.00 - - - Internet IL: Dorcan Gazelle (Israel Master) 63 2 96.83 0.1 0.1 0.10 dsa_available 63 2 96.83 8.8 143.4 61.35 Internet AU: Bush Dog (master for AU (phony)) 201 11 94.53 0.1 0.1 0.10 dsa_available 201 11 94.53 0.6 14.4 24.14 Internet Anaconda (AU Master) 227 31 86.34 0.1 0.1 0.10 dsa_available 201 16 92.04 1.6 16.3 10.61 Internet 186 72 61.29 6.2 28.7 17.46 Int-X.25 NO: Boa Constrictor (Norway Backup) 283 41 85.51 0.1 1.0 0.28 dsa_available 201 16 92.04 2.1 72.5 18.82 Internet 179 44 75.42 1.9 10.6 12.31 IXI 186 78 58.06 2.4 115.5 19.32 Int-X.25 Electric Eel (Norway Master) 282 54 80.85 0.1 1.0 0.28 dsa_available 200 13 93.50 1.8 66.2 9.40 Internet 179 55 69.27 1.6 5.7 6.23 IXI 187 80 57.22 2.9 76.0 6.83 Int-X.25 CH: Chinchilla (Swiss Master) 202 30 85.15 0.1 0.1 0.10 dsa_available 202 30 85.15 1.8 94.6 22.12 Internet Condor (ETH Zurich) 226 35 84.51 0.1 0.1 0.10 dsa_available 200 14 93.00 1.6 18.9 15.29 Internet 186 68 63.44 3.3 19.5 6.77 Int-X.25 ES: Iguana (ES Master. Programa IRIS) 270 42 84.44 0.1 1.0 0.28 dsa_available 190 22 88.42 2.7 66.3 15.43 Internet 175 40 77.14 1.6 30.4 9.11 IXI 183 70 61.75 3.7 11.1 8.01 Int-X.25 Cayman (Madrid Uni.) 63 20 68.25 0.1 0.1 0.10 dsa_available 63 26 58.73 6.8 111.0 55.93 Internet 63 28 55.56 7.7 25.2 9.63 Int-X.25 63 32 49.21 6.6 57.4 10.13 IXI DK: Axolotl (DK Master) 202 33 83.66 0.1 0.1 0.10 dsa_available 202 33 83.66 3.3 79.5 20.43 Internet UK: False Cobra (Root, GB backup) 275 49 82.18 0.1 1.0 0.30 dsa_available 136 30 77.94 1.5 4.1 4.45 X121 194 20 89.69 0.3 19.7 6.04 Internet 142 18 87.32 1.4 3.6 3.69 Janet 177 46 74.01 1.4 6.4 4.85 IXI Coypu, quipu-support@cs.ucl.ac.uk, 071-387-7050 x3688 282 53 81.21 0.1 1.0 0.30 dsa_available 138 30 78.26 1.6 4.4 4.26 X121 63 0 100.00 0.9 3.1 1.72 Local Ether 200 20 90.00 0.7 31.6 9.34 Internet 144 19 86.81 1.4 3.8 9.15 Janet Coypu (Thorn acces pt to quipu) 273 112 58.97 0.0 1.0 0.30 dsa_available 138 55 60.14 0.0 3.7 2.92 X121 141 38 73.05 0.0 3.6 3.28 Janet 192 69 64.06 0.0 65.3 4.30 Internet 176 75 57.39 0.0 4.1 2.58 IXI Vampire Bat (GB backup) 165 69 58.18 0.0 1.0 0.32 dsa_available 44 0 100.00 0.5 3.9 0.73 Private TCP 124 35 71.77 0.0 19.3 5.52 Janet 159 71 55.35 0.0 61.8 5.40 IXI Passionflower Leaf Beetle, quipu-support@cs.ucl.ac.uk, 071-387-7050 x3688 254 151 40.55 0.0 1.0 0.24 dsa_available 137 85 37.96 0.0 6.7 5.84 X121 189 109 42.33 0.0 104.7 8.17 Internet 124 84 32.26 0.0 8.7 4.91 Janet 159 117 26.42 0.0 6.5 5.03 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 124 124 0.00 - - - dsa_available 124 124 0.00 - - - Janet DE: Margay (GMD/F3, DE backup) 256 46 82.03 0.1 1.0 0.23 dsa_available 192 27 85.94 1.9 115.3 18.96 Internet 160 37 76.88 2.0 6.7 8.50 IXI 186 70 62.37 1.7 12.9 12.78 Int-X.25 Puma (GMD/FOKUS) 253 72 71.54 0.1 1.0 0.24 dsa_available 59 13 77.97 4.8 101.5 22.48 Internet 130 36 72.31 0.5 16.1 9.30 Internet 159 48 69.81 0.0 5.8 3.94 IXI 185 82 55.68 0.0 17.3 7.09 Int-X.25 SE: Hummingbird (Sweden Master) 197 36 81.73 0.1 0.1 0.10 dsa_available 176 15 91.48 2.8 86.3 16.33 Internet 134 134 0.00 - - - '0101'H/X121 IS: Elephant Seal (Iceland Master) 199 38 80.90 0.1 0.1 0.10 dsa_available 199 38 80.90 7.2 56.7 30.55 Internet FI: Jaguar (Finland Master) 209 54 74.16 0.1 0.1 0.10 dsa_available 188 38 79.79 2.8 88.3 16.20 Internet 135 85 37.04 0.0 39.0 14.47 '0101'H/X121 US: Alpaca (US master) 203 54 73.40 0.1 0.1 0.10 dsa_available 203 54 73.40 1.2 20.4 7.97 Internet Fruit Bat (US@l=NY master) 196 77 60.71 0.1 0.1 0.10 dsa_available 196 77 60.71 1.2 106.5 26.36 Internet Giant Anteater (Various slave) 188 89 52.66 0.1 0.1 0.10 dsa_available 188 89 52.66 1.4 18.6 7.11 Internet IE: Irish Elk (Republic of Ireland Master) 221 77 65.16 0.1 1.0 0.31 dsa_available 162 40 75.31 2.6 23.9 17.80 Internet 173 112 35.26 4.7 18.3 21.12 IXI AT: Piranah (AT Master) 215 88 59.07 0.0 0.1 0.08 dsa_available 189 66 65.08 0.0 108.8 16.74 Internet 185 122 34.05 0.0 24.5 14.82 Int-X.25 NL: Hornero (NL Master) 214 114 46.73 0.0 0.1 0.09 dsa_available 193 96 50.26 0.0 33.5 13.71 Internet 137 92 32.85 0.0 7.3 6.27 '0101'H/X121 Agouti (NL Slave) 203 173 14.78 0.0 0.1 0.05 dsa_available 203 173 14.78 0.0 10.9 6.14 Internet BE: Woolly Spider Monkey (Belgium Master) 63 63 0.00 - - - dsa_available 63 63 0.00 - - - Internet   Return-Path: Received: from CHIRALITY.RSA.com by bells.cs.ucl.ac.uk with SMTP inbound id <26707-0@bells.cs.ucl.ac.uk>; Fri, 26 Jul 1991 17:22:11 +0100 Received: by RSA.COM id AA20967; Fri, 26 Jul 91 09:22:50 PDT Date: Fri, 26 Jul 91 09:22:50 PDT From: jason@com.RSA (Jason Paul) Message-Id: <9107261622.AA20967@RSA.COM> To: osi-ds@uk.ac.ucl.cs Subject: UFN's I've been looking at the format for UFN's and I've run into some questions. For instance, it is clear in the following case that the tag organisation is not needed: Alice Algorithm, RSA Data Security, Inc., US However, if one where to add a state to the UFN would the tag organisation = be required: Alice Algorithm, RSA Data Security, Ibc., CA, US ^ organisation = Thanks for any help. Jason Paul RSA Data Security, Inc.   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <9449-0@bells.cs.ucl.ac.uk>; Sat, 27 Jul 1991 05:56:42 +0100 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA27206; Sat, 27 Jul 91 00:57:22 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA19475; Sat, 27 Jul 91 00:57:21 EDT From: mak@edu.merit Message-Id: <9107270457.AA19475@home.merit.edu> To: fox500@edu.isi, osi-ds@uk.ac.ucl.cs Subject: dixie rfc Date: Sat, 27 Jul 91 00:57:20 -0400 Tim, Given the lack of time for changes I think it best to submit this to the lists for possible discussion at IETF. I'm sure at least the FOX participants will be interested in this. Mark ------- Forwarded Message Received: from terminator.cc.umich.edu by merit.edu (5.65/1123-1.0) id AA17354; Wed, 24 Jul 91 14:31:14 -0400 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA01835; Wed, 24 Jul 91 14:31:05 -0400 Message-Id: <9107241831.AA01835@terminator.cc.umich.edu> To: mak@merit.edu, clw@merit.edu Subject: dixie rfc Date: Wed, 24 Jul 91 14:31:06 -0400 From: Tim Howes Here it is, draft #1 hot off the press. I'd like to bring a decent copy of this to the IETF, so I'd appreciate your comments ASAP (in time to make revisions). I included a section on known implementation availability (currently listing what we've done, of course). Should it stay? Is it inappropriate? Comments? -- Tim - -----------------------------cut here---------------------------------- Network Working Group T. Howes Request for Comments: DRAFT M. Smith University of Michigan July 1991 DIXIE Protocol Specification Status of this Memo This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. The DIXIE protocol is an ad hoc method of achieving this goal. This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited. Table of Contents 1. Introduction ................................................. 2 1.1 History ..................................................... 2 2. Protocol ..................................................... 2 2.1 Header ...................................................... 3 2.2 Operations .................................................. 4 2.2.1 Read ...................................................... 4 2.2.1.1 Read Request ............................................ 4 2.2.1.2 Read Reply .............................................. 4 2.2.2 Search .................................................... 4 2.2.2.1 Search Request .......................................... 5 2.2.2.2 Search Reply ............................................ 5 2.2.3 List ...................................................... 5 2.2.3.1 List Request ............................................ 5 2.2.3.2 List Reply .............................................. 5 2.2.4 Modify .................................................... 5 2.2.4.1 Modify Request .......................................... 5 2.2.4.2 Modify Reply ............................................ 6 2.2.5 Modify RDN ................................................ 6 2.2.5.1 Modify RDN Request ...................................... 6 2.2.5.2 Modify RDN Reply ........................................ 6 2.2.6 Add ....................................................... 6 2.2.6.1 Add Request ............................................. 6 2.2.6.2 Add Reply ............................................... 7 2.2.7 Remove .................................................... 7 2.2.7.1 Remove Request .......................................... 7 2.2.7.2 Remove Reply ............................................ 7 2.2.8 Bind ...................................................... 7 2.2.8.1 Bind Request ............................................ 7 Howes & Smith [Page 1] RFC DRAFT July 1991 2.2.8.2 Bind Reply .............................................. 7 2.3 Reliable Delivery With UDP .................................. 8 2.4 Return Codes ................................................ 8 3. References ................................................... 9 4. Security ..................................................... 9 5. Available Implementations .................................... 9 6. Author's Address ............................................. 10 1. Introduction OSI Directory Service defines a powerful mechanism for storing and retrieving information about objects, and for arranging those objects in a hierarchical structure. Many types of objects and information can be stored in The Directory, including white pages information, application information, service information, etc. The OSI protocol defined to allow access to this information is the Directory Access Protocol (DAP). The DAP, being an OSI application-layer program, is fairly heavy-weight and requires a substantial amount of computing power. The DIXIE protocol is designed for use by smaller hosts (e.g., Macintoshes and PCs) that do not have the computing power or necessary software to implement a full OSI protocol. The DIXIE protocol is also useful for any Internet application that wants a simple interface to X.500 that requires very little coding investment. The basic idea behind DIXIE is the same as that described in RFC 1202 for the Directory Assistance Protocol. DIXIE offers both UDP and TCP access to The Directory, and provides a more flexible interface for user interface development than the Directory Assistance Protocol. 1.1 History The DIXIE protocol has evolved over time, slowly growing into the protocol described by this document. Without an understanding of the circumstances surrounding this evolution, the wisdom of some of the DIXIE design decisions may not be apparent. 2. Protocol This section describes the DIXIE protocol in detail. DIXIE follows a client-server request and response paradigm. Clients send request packets to a DIXIE server, and the server sends reply packets in return. Communication may be over UDP or TCP, depending upon the needs of the client. All modification operations (ADD, REMOVE, MODIFY, MODIFYRDN) must be performed over a TCP connection. When using UDP, a client can specify single packet best effort Howes & Smith [Page 2] RFC DRAFT July 1991 communication, or reliable datagram communication. The later choice requires considerably more work on the client's part. For UDP communication, packets are broken up into 512 octet fragments. Best effort communication is limited to packets smaller than 512 octets. The details are described in section 2.2.9. Whichever method of communication is used, the general packet format is the same. Each packet consists of a sixteen octet header followed by some data. The format of the header and data for each kind of request is described below. The representation used for all X.500 data passed between the server and the client is the QUIPU EDB format. So, for example, a Distinguished Name might look something like "c=US@o=University of Michigan". For a complete description of this format, see volume 5 of the ISODE Manual. The DIXIE server listens on port 7654 for both UDP packets and TCP connections. 2.1 Header The DIXIE packet header is sixteen octets long. For requests, the header is described by the following: Start Length Description 0 1 An opcode specifying one of the operations described below. 1 2 A request identifier to be included in the reply. This number should be unique to a request. 3 4 The total length of the packet, excluding the header. 7 2 Unused. 9 1 Options. Currently, there are only two options. If bit 0 is set, large attributes will be included in the response. If bit 1 is set, the dereference aliases service control will be set for the X.500 operation. 10 1 Protocol version. The current version is 1. 11 1 For the search operation, this byte specifies the scope of the search. 12 4 Unused. For replies, the header is described by the following: Start Length Description 0 1 A return code specifying either success or describing any error that occurred. (see Howes & Smith [Page 3] RFC DRAFT July 1991 section 2.4 for a description of each code) 1 2 The request identifier included in the request packet. 3 4 The total length of the response packet, excluding the header. 7 2 Sequence number for reliable UDP. 9 1 Unused. 10 1 Protocol version. The current version is 1. 11 5 Unused. All unused fields should be set to zero octets and are reserved for future expansion. 2.2 Operations This section describes the DIXIE operations, which closely parallel the X.500 DAP operations. 2.2.1 Read The DIXIE read operation corresponds to an X.500 DAP READ operation. 2.2.1.1 Read Request The header opcode should be set to 0x01. The data portion of the packet consists of the DN of the entry to read, a null octet, and then a null-octet separated list of attributes whose values are to be returned from the read. If no attributes to return are listed, all attributes are returned. The packet is terminated by two null octets in a row. 2.2.1.2 Read Reply The reply data for the read operation consists of the entry read, followed by a zero octet. An entry consists of the DN of the entry, followed by the octet 0x02, followed by a 0x02-octet separated list of attribute values. An attribute value consists of an attribute type, followed by the octet 0x01, followed by a 0x01-octet separated list of values. Each attribute type, attribute value and distinguished name has the form defined by the QUIPU EDB format. 2.2.2 Search The DIXIE search operation corresponds to an X.500 DAP SEARCH operation. Howes & Smith [Page 4] RFC DRAFT July 1991 2.2.2.1 Search Request The header opcode should be set to 0x0f. Octet 11 in the header should be set to 0x01, 0x02, or 0x03, for a search scope of base object, one level, or whole subtree, respectively. The data portion of the packet consists of the DN of the entry from which to start the search, a null octet, a string containing the search filter (dish- style), a null-octet, and then a null-octet separated list of attributes whose values are to be returned from the search. If no attributes to return are listed, all attributes are returned. The packet is terminated by two null octets in a row. 2.2.2.2 Search Reply The reply data to the search operation consists of two octets in network byte order specifying the number of matches returned. Next comes this number of sequences of the form: one 0x03 octet followed by one entry. Each entry is as described above in section 2.2.1.2. 2.2.3 List The DIXIE list operation corresponds to an X.500 DAP LIST operation. 2.2.3.1 List Request The header opcode should be set to 0x10. The data portion of the packet consists of the DN of the entry on which to perform the list, followed by a zero octet. 2.2.3.2 List Reply The reply data to the list operation consists of two octets in network byte order specifying the number of subordinates returned, followed by this number of sequences of the form: one 0x03 octet followed by a Relative Distinguished Name of a subordinate. 2.2.4 Modify The DIXIE modify operation corresponds to an X.500 DAP MODIFY operation. 2.2.4.1 Modify Request The header opcode should be set to 0x02. The data portion of the packet consists of the DN of the entry to modify, followed by a null octet, followed by a null-separated list of modify operations to perform. Each modify operation is one of the following: Howes & Smith [Page 5] RFC DRAFT July 1991 type remove attribute type type=value make value the sole value for attribute type type+=value add value to attribute type type-=value remove value from attribute type The second form will see to it that existing values (if any) are deleted before the new ones are added. The third form will add the attribute type if it does not already exist. Note that the QUIPU EDB format, used to specify value, allows multiple values to be specified separated by the `&` character. This operation is only allowed over TCP. 2.2.4.2 Modify Reply There is no reply data for the modify operation. The only indication of success or failure is the return code in the header. 2.2.5 Modify RDN The DIXIE modify RDN operation corresponds to an X.500 DAP MODIFYRDN operation. 2.2.5.1 Modify RDN Request The header opcode should be set to 0x13. The data portion of the packet consists of the DN of the entry to modify, followed by a null octet, followed by the new RDN the entry should have, followed by a final null octet. The old value of the RDN is never kept as an attribute of the entry. This operation is only allowed over TCP. 2.2.5.2 Modify RDN Reply There is no reply data to the modify RDN operation. The only indication of success or failure is the return code in the header. 2.2.6 Add The DIXIE add operation corresponds to an X.500 DAP ADD operation. 2.2.6.1 Add Request The header opcode should be set to 0x11. The data portion of the packet consists of the DN of the entry to add, followed by a null octet, followed by a null-separated list of the entry's attributes. Each attribute in this list has the form: type=value Howes & Smith [Page 6] RFC DRAFT July 1991 where value can consist of a single value, or multiple values separated by the '&' character. The request is terminated by two null octets in a row. This operation is only allowed over TCP. 2.2.6.2 Add Reply There is no reply data to the add operation. The only indication of success or failure is the return code in the header. 2.2.7 Remove The DIXIE remove operation corresponds to an X.500 DAP REMOVE operation. 2.2.7.1 Remove Request The header opcode should be set to 0x12. The data portion of the packet consists of the DN of the entry to remove, followed by a null octet. This operation is only allowed over TCP. 2.2.7.2 Remove Reply There is no reply data for the remove operation. The only indication of success or failure is the return code in the header. 2.2.8 Bind The DIXIE bind operation corresponds to an X.500 DAP BIND operation using simple authentication as defined in Recommendation X.509. 2.2.8.1 Bind Request The header opcode should be set to 0x04. The data portion of the packet consists of the DN of the entry as which to bind, followed by a null octet, followed by the password of the entry as which to bind, followed by a final null octet. 2.2.8.2 Bind Reply The format of the bind reply packet depends on whether the operation was invoked over TCP or UDP. If the operation was invoked over TCP, there is no reply data. Success or failure of the operation is indicated by the return code in the packet header. If the bind operation was invoked over UDP, the data portion of the reply packet consists of an Internet address in standard dot notation, followed by a 0x01 octet, followed by a decimal number (in text form), followed by a null octet. The address and number should Howes & Smith [Page 7] RFC DRAFT July 1991 be taken to be the address and port number to which the client should connect to obtain an authenticated TCP connection, bound as the entity specified in the request packet. 2.3 Reliable Delivery With UDP Since UDP is an unreliable protocol, some mechanism is required to guarantee reliable delivery (TCP is reliable, so no mechanism is needed). When using UDP within the DIXIE protocol, a client- driven retry mechanism is employed. Each request a client sends to the server contains an id that is used by the server along with the client's Internet address and source port number to uniquely identify the request. Once a client sends a request, it should wait a reasonable period of time for a response from the server. If no response is received, the request is resent (with the same id). If some (but not all) of the fragments that make up the response are received, the client can ask the server for retransmission by sending a request with an opcode of 0x07. This nack request should contain the same id as the original request, and should have the sequence number in the header set to the number of the first missing fragment. The client can then expect the server to resend the missing fragments. When the client receives the entire response (all the fragments) it should send an ack request with an opcode of 0x06 to the server. The timeout period used before resending a request or sending a nack is implementation defined. Since there is no good way to determine packet round trip times, current implementations use an exponential backoff algorithm (first timeout is 2 seconds, the next one (if no response fragments are received) is 4 seconds, then 8, etc). When the server receives a request, it should perform the operation requested and send the response (as one or more fragments). Each response fragment id must match the one in the request. If the server receives a nack request it should resend all fragments for the matching response that have the indicated sequence number or higher. A matching response is defined to be the one whose request has the same id and which comes from the same Internet address and port. The ack mechanism is defined to allow a server to dispose of packets eventually. Note that packet fragmentation of this kind is never done over TCP. 2.4. Return Codes This section describes the possible values for the the DIXIE header return code. There are currently 17 possible values: Howes & Smith [Page 8] RFC DRAFT July 1991 0x01 The request was successful. 0x02 The search did not find any matches. 0x03 Some unknown, generic DIXIE error has occurred. 0x04 The DIXIE opcode was not recognized by the DIXIE server. 0x05 Insufficient access to perform a modification. 0x06 A malformed DN was supplied. 0x07 Some time limit or size limit was reached. Partial results will be returned. 0x08 A modify was attempted before a bind. 0x09 A fragment requested was not found. 0x0a An attribute type specified is invalid. 0x0b An attribute specified does not exist in the entry. 0x0c An attribute value specification is invalid. 0x0d An attribute value does not exist (as for removal of the value). 0x0e A modification of an entry's RDN was attempted via a modify operation. This is not allowed (use modrdn instead). 0x0f A supplied DN references an invalid portion of the tree. 0x10 The DSA has passed back a referral to another DSA (as for a modification to a non-local entry), and the DIXIE server was unable to follow it. 0x11 The DSA is down or unreachable. 3. References [1] Information Processing - Open Systems Interconnection - The Directory, International Organization for Standardization. International Standard 9594, (1988). [2] Kille, S., Robbins, C., Roe, M., and A. Turland, "The ISO Development Environment: User's Manual", Volume 5: QUIPU, Performance Systems International, January 1990. [3] Rose, Marshall T., RFC 1202: Directory Assistance Service, Performance Systems Internationa, February 1991. 4. Security Considerations Security considerations are not discussed in this memo. 5. Available Implementations This section is not meant as an endorsement of any implementation, it is provided merely as information for the Internet community. A full Un*x-based implementation of the DIXIE protocol in the form of a DIXIE server and DIXIE application library is freely available for anonymous FTP from the host terminator.cc.umich.edu in the ~ftp/x500 directory. Un*x and Macintosh clients that use the DIXIE protocol have also been implemented and are available from the same location. Howes & Smith [Page 9] RFC DRAFT July 1991 There is also a discussion list for DIXIE-related topics called dixie@terminator.cc.umich.edu. To join, send mail to dixie- request@terminator.cc.umich.edu. 6. Author's Address Tim Howes University of Michigan Information Technology Division 535 West William St. Ann Arbor, MI 48103-4943 Phone: +1 313 764-2278 EMail: tim@umich.edu Mark Smith University of Michigan Information Technology Division 535 West William St. Ann Arbor, MI 48103-4943 Phone: +1 313 764-2277 EMail: mcs@umich.edu Howes & Smith [Page 10] ------- End of Forwarded Message   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <4048-0@bells.cs.ucl.ac.uk>; Sat, 27 Jul 1991 15:19:01 +0100 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA22681; Sat, 27 Jul 91 10:19:50 -0400 Message-Id: <9107271419.AA22681@terminator.cc.umich.edu> To: osi-ds@uk.ac.ucl.cs Subject: DIXIE rfc Date: Sat, 27 Jul 91 10:19:52 -0400 From: Tim Howes Sorry this is so close to the ietf. At the last osi-ds meeting, I promised I'd write up the dixie protocol as a draft rfc. Here it is. For those of you who have never heard of dixie, it's similar to Marshall's Directory Assistance Protocol (at least, the idea is the same). I don't expect a big discussion about this at ietf, but I would appreciate any comments people have. -- Tim Network Working Group T. Howes Request for Comments: DRAFT M. Smith B. Beecher University of Michigan July 1991 DIXIE Protocol Specification Status of this Memo This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. The DIXIE protocol is an ad hoc method of achieving this goal. This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited. Table of Contents 1. Introduction .............................................. 2 1.1 History .................................................. 2 2. Protocol .................................................. 2 2.1 Header ................................................... 3 2.2 Operations ............................................... 4 2.2.1 Read ................................................... 4 2.2.1.1 Read Request ......................................... 4 2.2.1.2 Read Reply ........................................... 4 2.2.2 Search ................................................. 4 2.2.2.1 Search Request ....................................... 5 2.2.2.2 Search Reply ......................................... 5 2.2.3 List ................................................... 5 2.2.3.1 List Request ......................................... 5 2.2.3.2 List Reply ........................................... 5 2.2.4 Modify ................................................. 5 2.2.4.1 Modify Request ....................................... 5 2.2.4.2 Modify Reply ......................................... 6 2.2.5 Modify RDN ............................................. 6 2.2.5.1 Modify RDN Request ................................... 6 2.2.5.2 Modify RDN Reply ..................................... 6 2.2.6 Add .................................................... 6 2.2.6.1 Add Request .......................................... 6 2.2.6.2 Add Reply ............................................ 7 2.2.7 Remove ................................................. 7 2.2.7.1 Remove Request ....................................... 7 2.2.7.2 Remove Reply ......................................... 7 2.2.8 Bind ................................................... 7 Howes, Smith and Beecher [Page 1] RFC DRAFT July 1991 2.2.8.1 Bind Request ......................................... 7 2.2.8.2 Bind Reply ........................................... 7 2.3 Reliable Delivery With UDP ............................... 8 2.4 Return Codes ............................................. 8 3. References ................................................ 9 4. Security .................................................. 9 5. Available Implementations ................................. 9 6. Author's Address .......................................... 10 1. Introduction OSI Directory Service defines a powerful mechanism for storing and retrieving information about objects, and for arranging those objects in a hierarchical structure. Many types of objects and information can be stored in The Directory, including white pages information, application information, service information, etc. The OSI protocol defined to allow access to this information is the Directory Access Protocol (DAP). The DAP, being an OSI application-layer program, is fairly heavy-weight and requires a substantial amount of computing power. The DIXIE protocol is designed for use by smaller hosts (e.g., Macintoshes and PCs) that do not have the computing power or necessary software to implement a full OSI protocol stack. The DIXIE protocol is also useful for any Internet application that wants a simple interface to X.500 that requires very little coding investment. The basic idea behind DIXIE is the same as that described in RFC 1202 for the Directory Assistance Protocol. DIXIE offers both UDP and TCP access to The Directory, and provides a more flexible interface for user interface development than the Directory Assistance Protocol. 1.1 History The DIXIE protocol has evolved over time, slowly growing into the protocol described by this document. Without an understanding of the circumstances surrounding this evolution, the wisdom of some of the DIXIE design decisions may not be apparent. 2. Protocol This section describes the DIXIE protocol in detail. DIXIE follows a client-server request and response paradigm. Clients send request packets to a DIXIE server, and the server sends reply packets in return. Communication may be over UDP or TCP, depending upon the needs of the client. All modification operations (ADD, REMOVE, MODIFY, MODIFYRDN) must be performed over a TCP connection. When Howes, Smith and Beecher [Page 2] RFC DRAFT July 1991 using UDP, a client can specify single-packet best-effort communication, or reliable datagram communication. The later choice requires considerably more work on the client's part. For UDP communication, packets are broken up into 512 octet fragments. Best effort communication is limited to packets smaller than 512 octets. The details are described in section 2.2.9. Whichever method of communication is used, the general packet format is the same. Each packet consists of a sixteen octet header followed by some data. The format of the header and data for each kind of request is described below. The representation used for all X.500 data passed between the server and the client is the QUIPU EDB format. So, for example, a Distinguished Name might look something like "c=US@o=University of Michigan". For a complete description of this format, see volume 5 of the ISODE Manual. The DIXIE server listens on port 7654 for both UDP packets and TCP connections. 2.1 Header The DIXIE packet header is sixteen octets long. For requests, the header is described by the following: Start Length Description 0 1 An opcode specifying one of the operations described below. 1 2 A request identifier to be included in the reply. This number should be unique to a request. 3 4 The total length of the packet, excluding the header. 7 2 Unused. 9 1 Options. Currently, there are only three options. If bit 0 is set, large attributes will be included in the response. If bit 1 is set, the dereference aliases service control will be set for the X.500 operation. If bit 2 is set, aliases will NOT be dereferenced and searched during a search operation. 10 1 Protocol version. The current version is 1. 11 1 For the search operation, this byte specifies the scope of the search. 12 4 Unused. For replies, the header is described by the following: Howes, Smith and Beecher [Page 3] RFC DRAFT July 1991 Start Length Description 0 1 A return code specifying either success or describing any error that occurred. (see section 2.4 for a description of each code) 1 2 The request identifier included in the request packet. 3 4 The total length of the response packet, excluding the header. 7 2 Sequence number for reliable UDP. 9 1 Unused. 10 1 Protocol version. The current version is 1. 11 5 Unused. All unused fields should be set to zero octets and are reserved for future expansion. 2.2 Operations This section describes the DIXIE operations, which closely parallel the X.500 DAP operations. 2.2.1 Read The DIXIE read operation corresponds to an X.500 DAP READ operation. 2.2.1.1 Read Request The header opcode should be set to 0x01. The data portion of the packet consists of the DN of the entry to read, a null octet, and then a null-octet separated list of attributes whose values are to be returned from the read. If no attributes to return are listed, all attributes are returned. The packet is terminated by two null octets in a row. 2.2.1.2 Read Reply The reply data for the read operation consists of the entry read, followed by a zero octet. An entry consists of the DN of the entry, followed by the octet 0x02, followed by a 0x02-octet separated list of attribute values. An attribute value consists of an attribute type, followed by the octet 0x01, followed by a 0x01-octet separated list of values. Each attribute type, attribute value and distinguished name has the form defined by the QUIPU EDB format. 2.2.2 Search The DIXIE search operation corresponds to an X.500 DAP SEARCH operation. Howes, Smith and Beecher [Page 4] RFC DRAFT July 1991 2.2.2.1 Search Request The header opcode should be set to 0x0f. Octet 11 in the header should be set to 0x01, 0x02, or 0x03, for a search scope of base object, one level, or whole subtree, respectively. The data portion of the packet consists of the DN of the entry from which to start the search, a null octet, a string containing the search filter (dish- style), a null-octet, and then a null-octet separated list of attributes whose values are to be returned from the search. If no attributes to return are listed, all attributes are returned. The packet is terminated by two null octets in a row. 2.2.2.2 Search Reply The reply data to the search operation consists of two octets in network byte order specifying the number of matches returned. Next comes this number of sequences of the form: one 0x03 octet followed by one entry. Each entry is as described above in section 2.2.1.2. 2.2.3 List The DIXIE list operation corresponds to an X.500 DAP LIST operation. 2.2.3.1 List Request The header opcode should be set to 0x10. The data portion of the packet consists of the DN of the entry on which to perform the list, followed by a zero octet. 2.2.3.2 List Reply The reply data to the list operation consists of two octets in network byte order specifying the number of subordinates returned, followed by this number of sequences of the form: one 0x03 octet followed by a Relative Distinguished Name of a subordinate. 2.2.4 Modify The DIXIE modify operation corresponds to an X.500 DAP MODIFY operation. 2.2.4.1 Modify Request The header opcode should be set to 0x02. The data portion of the packet consists of the DN of the entry to modify, followed by a null octet, followed by a null-separated list of modify operations to perform. Each modify operation is one of the following: Howes, Smith and Beecher [Page 5] RFC DRAFT July 1991 type remove attribute type type=value make value the sole value for attribute type type+=value add value to attribute type type-=value remove value from attribute type The second form will see to it that existing values (if any) are deleted before the new ones are added. The third form will add the attribute type if it does not already exist. Note that the QUIPU EDB format, used to specify value, allows multiple values to be specified separated by the `&` character. This operation is only allowed over TCP. 2.2.4.2 Modify Reply There is no reply data for the modify operation. The only indication of success or failure is the return code in the header. 2.2.5 Modify RDN The DIXIE modify RDN operation corresponds to an X.500 DAP MODIFYRDN operation. 2.2.5.1 Modify RDN Request The header opcode should be set to 0x13. The data portion of the packet consists of the DN of the entry to modify, followed by a null octet, followed by the new RDN the entry should have, followed by a final null octet. The old value of the RDN is never kept as an attribute of the entry. This operation is only allowed over TCP. 2.2.5.2 Modify RDN Reply There is no reply data to the modify RDN operation. The only indication of success or failure is the return code in the header. 2.2.6 Add The DIXIE add operation corresponds to an X.500 DAP ADD operation. 2.2.6.1 Add Request The header opcode should be set to 0x11. The data portion of the packet consists of the DN of the entry to add, followed by a null octet, followed by a null-separated list of the entry's attributes. Each attribute in this list has the form: type=value Howes, Smith and Beecher [Page 6] RFC DRAFT July 1991 where value can consist of a single value, or multiple values separated by the '&' character. The request is terminated by two null octets in a row. This operation is only allowed over TCP. 2.2.6.2 Add Reply There is no reply data to the add operation. The only indication of success or failure is the return code in the header. 2.2.7 Remove The DIXIE remove operation corresponds to an X.500 DAP REMOVE operation. 2.2.7.1 Remove Request The header opcode should be set to 0x12. The data portion of the packet consists of the DN of the entry to remove, followed by a null octet. This operation is only allowed over TCP. 2.2.7.2 Remove Reply There is no reply data for the remove operation. The only indication of success or failure is the return code in the header. 2.2.8 Bind The DIXIE bind operation corresponds to an X.500 DAP BIND operation using simple authentication as defined in Recommendation X.509. 2.2.8.1 Bind Request The header opcode should be set to 0x04. The data portion of the packet consists of the DN of the entry as which to bind, followed by a null octet, followed by the password of the entry as which to bind, followed by a final null octet. 2.2.8.2 Bind Reply The format of the bind reply packet depends on whether the operation was invoked over TCP or UDP. If the operation was invoked over TCP, there is no reply data. Success or failure of the operation is indicated by the return code in the packet header. If the bind operation was invoked over UDP, the data portion of the reply packet consists of an Internet address in standard dot notation, followed by a 0x01 octet, followed by a decimal number (in text form), followed by a null octet. The address and number should Howes, Smith and Beecher [Page 7] RFC DRAFT July 1991 be taken to be the address and port number to which the client should connect to obtain an authenticated TCP connection, bound as the entity specified in the request packet. 2.3 Reliable Delivery With UDP Since UDP is an unreliable protocol, some mechanism is required to guarantee reliable delivery (TCP is reliable, so no mechanism is needed). When using UDP within the DIXIE protocol, a client- driven retry mechanism is employed. Each request a client sends to the server contains an id that is used by the server along with the client's Internet address and source port number to uniquely identify the request. Once a client sends a request, it should wait a reasonable period of time for a response from the server. If no response is received, the request is resent (with the same id). If some (but not all) of the fragments that make up the response are received, the client can ask the server for retransmission by sending a request with an opcode of 0x07. This nack request should contain the same id as the original request, and should have the sequence number in the header set to the number of the first missing fragment. The client can then expect the server to resend the missing fragments. When the client receives the entire response (all the fragments) it should send an ack request with an opcode of 0x06 to the server. The timeout period used before resending a request or sending a nack is implementation defined. Since there is no good way to determine packet round trip times, current implementations use an exponential backoff algorithm (first timeout is 2 seconds, the next one (if no response fragments are received) is 4 seconds, then 8, etc). When the server receives a request, it should perform the operation requested and send the response (as one or more fragments). Each response fragment id must match the one in the request. If the server receives a nack request it should resend all fragments for the matching response that have the indicated sequence number or higher. A matching response is defined to be the one whose request has the same id and which comes from the same Internet address and port. The ack mechanism is defined to allow a server to dispose of packets eventually. Note that packet fragmentation of this kind is never done over TCP. 2.4. Return Codes This section describes the possible values for the the DIXIE header return code. There are currently 17 possible values: Howes, Smith and Beecher [Page 8] RFC DRAFT July 1991 0x01 The request was successful. 0x02 The search did not find any matches. 0x03 Some unknown, generic DIXIE error has occurred. 0x04 The DIXIE opcode was not recognized by the DIXIE server. 0x05 Insufficient access to perform a modification. 0x06 A malformed DN was supplied. 0x07 Some time limit or size limit was reached. Partial results will be returned. 0x08 A modify was attempted before a bind. 0x09 A fragment requested was not found. 0x0a An attribute type specified is invalid. 0x0b An attribute specified does not exist in the entry. 0x0c An attribute value specification is invalid. 0x0d An attribute value does not exist (as for removal of the value). 0x0e A modification of an entry's RDN was attempted via a modify operation. This is not allowed (use modrdn instead). 0x0f A supplied DN references an invalid portion of the tree. 0x10 The DSA has passed back a referral to another DSA (as for a modification to a non-local entry), and the DIXIE server was unable to follow it. 0x11 The DSA is down or unreachable. 3. References [1] Information Processing - Open Systems Interconnection - The Directory, International Organization for Standardization. International Standard 9594, (1988). [2] Kille, S., Robbins, C., Roe, M., and A. Turland, "The ISO Development Environment: User's Manual", Volume 5: QUIPU, Performance Systems International, January 1990. [3] Rose, Marshall T., RFC 1202: Directory Assistance Service, Performance Systems International, February 1991. 4. Security Considerations Security considerations are not discussed in this memo. 5. Available Implementations This section is not meant as an endorsement of any implementation, it is provided merely as information for the Internet community. A full Un*x-based implementation of the DIXIE protocol in the form of a DIXIE server and DIXIE application library is freely available for anonymous FTP from the host terminator.cc.umich.edu in the ~ftp/x500 directory. Un*x and Macintosh clients that use the DIXIE protocol have also been implemented and are available from the same location. Howes, Smith and Beecher [Page 9] RFC DRAFT July 1991 There is also a discussion list for DIXIE-related topics called dixie@terminator.cc.umich.edu. To join, send mail to dixie- request@terminator.cc.umich.edu. 6. Author's Address Tim Howes University of Michigan Information Technology Division 535 West William St. Ann Arbor, MI 48103-4943 Phone: +1 313 764-2278 EMail: tim@umich.edu Mark Smith University of Michigan Information Technology Division 535 West William St. Ann Arbor, MI 48103-4943 Phone: +1 313 764-2277 EMail: mcs@umich.edu Bryan Beecher University of Michigan Information Technology Division 535 West William St. Ann Arbor, MI 48103-4943 Phone: +1 313 764-4050 EMail: bryan@umich.edu Howes, Smith and Beecher [Page 10]   Return-Path: Received: from vtvm1.cc.vt.edu by bells.cs.ucl.ac.uk with SMTP inbound id <8286-0@bells.cs.ucl.ac.uk>; Mon, 29 Jul 1991 19:24:12 +0100 Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R1) with BSMTP id 4776; Mon, 29 Jul 91 14:24:15 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 0346; Mon, 29 Jul 91 14:24:15 EDT Date: Mon, 29 Jul 91 14:22:25 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: X.500 and Domains... To: osi-ds@uk.ac.ucl.cs Message-Id: <910729.142225.EDT.VALDIS@vtvm1.cc.vt.edu> Has anybody out there actually implemented storing DNS info in an X.500 database as per Steve Hardcastle-Kille's IETF draft 'X.500 and Domains'? If so, can you please post a quick discussion of what you did? I'd like to compare notes before I embark on doing this... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <3320-24@bells.cs.ucl.ac.uk>; Tue, 30 Jul 1991 11:12:52 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <3813-6@sun2.nsfnet-relay.ac.uk>; Tue, 30 Jul 1991 10:07:31 +0100 Received: from [138.96.8.118] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa02926; 30 Jul 91 9:31 BST Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA20083; Tue, 30 Jul 91 10:56:18 +0200 Message-Id: <9107300856.AA20083@mitsou.inria.fr> To: Tim Howes Cc: osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc In-Reply-To: Your message of 27 Jul 91 10:19:52 -0400. <9107271419.AA22681@terminator.cc.umich.edu> Date: Tue, 30 Jul 91 10:55:50 BST From: Christian Huitema Sender: huitema@fr.inria.mitsou Tim, I find the "DIXIE" idea interesting, but I certainly dislike the details -- mostly the idea of using QUIPU like text encodings. Contrarily to what you may believe, text encodings are neither easier to code nor faster to run than ASN.1 encodings. We should start by solving the "what for" question. the justification of "providing DUAs on small systems" has to be qualified: what kind of DUAs, how small is the system, etc. I dont believe that we need a special protocol -- different from DAP -- if we intend to provide a full scale "user interface" DUA, complete with screen and mouses. On the other hand, I would very much like to be able to use a simple datagram based protocol for the "name service" function of X.500, i.e. the ISO equivalent of DNS resolvers for the "get host by name" service. Why dont we imitate the successfull SNMP cut-off from CMIP? As Marshall Rose explains, the basis behind the SNMP success is "to get the right model", so that we could perform simple operations. Using ASN.1 or text for the encodings is really a non issue -- you wont gain much; on the other hand, keeping the whole set of operations assure that you will be equally complex. But cutting from the X.500 specs a "Simple Name Server Protocol" (SNSP, tm) looks like a far better idea.. Christian Huitema   Return-Path: Received: from nrtc.northrop.com by bells.cs.ucl.ac.uk with SMTP inbound id <2055-0@bells.cs.ucl.ac.uk>; Wed, 31 Jul 1991 01:37:30 +0100 Received: from nma.com by nrtc.nrtc.northrop.com id ag19106; 30 Jul 91 17:38 PDT Received: from odin.nma.com by nma.com id aa16669; 30 Jul 91 17:13 PDT To: Christian Huitema cc: Tim Howes , osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc In-reply-to: Your message of Tue, 30 Jul 91 10:55:50 +0000. <9107300856.AA20083@mitsou.inria.fr> Reply-to: Stef@edu.uci.ics From: Einar Stefferud Date: Tue, 30 Jul 91 17:10:37 MDT Message-ID: <9014.680919037@nma.com> Sender: stef@com.nma Great idea Christian -- I endorse it!...\Stef "Simple Name Server Protocol" (SNSP, tm)   Return-Path: Received: from att.att.com by bells.cs.ucl.ac.uk with SMTP inbound id <24403-0@bells.cs.ucl.ac.uk>; Wed, 31 Jul 1991 15:14:56 +0100 From: youbong@com.att.arch2 Date: Wed, 31 Jul 91 09:56 EDT To: Tim Howes , Christian Huitema Cc: osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc Christian, SNSP is a brilliant idea. Youbong Weon-Yoon   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <26947-0@bells.cs.ucl.ac.uk>; Thu, 1 Aug 1991 15:49:29 +0100 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA14048; Thu, 1 Aug 91 10:50:22 -0400 Message-Id: <9108011450.AA14048@terminator.cc.umich.edu> To: Christian Huitema Cc: osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc In-Reply-To: Your message of "Tue, 30 Jul 91 10:55:50 BST." <9107300856.AA20083@mitsou.inria.fr> Date: Thu, 01 Aug 91 10:50:25 -0400 From: Tim Howes > I find the "DIXIE" idea interesting, but I certainly dislike the details -- > mostly the idea of using QUIPU like text encodings. Contrarily to what you may > believe, text encodings are neither easier to code nor faster to run than > ASN.1 encodings. Well, I have to disagree on this point. ASN.1 is harder than a simple text encoding. Even if this point is debatable, it is certainly true that the coding investment for a text encoding is much much less than that for ASN.1. The choice of quipu text encodings was really incidental. It seemed to make more sense than coming up with a separate one of our own. > We should start by solving the "what for" question. the justification > of "providing DUAs on small systems" has to be qualified: what kind of DUAs, > how small is the system, etc. I dont believe that we need a special protocol - > different from DAP -- if we intend to provide a full scale "user interface" > DUA, complete with screen and mouses. On the other hand, I would very much > like to be able to use a simple datagram based protocol for the "name service" > function of X.500, i.e. the ISO equivalent of DNS resolvers for the "get host > by name" service. A little background: the UM campus is littered with Macs and PCs, and this is how perhaps 90% of the campus does its computing. There are also a fair number of unix boxes (maybe 2000 or so), but there are far more little machines. The little machines do not have an OSI protocol stack, and are not likely to get one soon. Yet those people want (and should be able to get) access to campus-wide directory service, especially for white pages info. The dixie protocol was designed to do this, but also to be general enough to not be restricted to white pages info. Name service-type applications may certainly be important, but the dixie protocol is general enough to do that, and light-weight enough to do it quickly. > Why dont we imitate the successfull SNMP cut-off from CMIP? As Marshall Rose > explains, the basis behind the SNMP success is "to get the right model", so > that we could perform simple operations. Using ASN.1 or text for the encodings > is really a non issue -- you wont gain much; on the other hand, keeping the > whole set of operations assure that you will be equally complex. But cutting > from the X.500 specs a "Simple Name Server Protocol" (SNSP, tm) looks like a > far better idea.. The complexity and, just as important, the coding effort necessary to actually get something talking to the directory, is much less with dixie. And it's not just the encodings that are at issue here. There is the whole OSI stack to consider. Dixie does some of what you suggest already. It is not a complete mapping onto X.500. Many of the more esoteric X.500 options are not accessible through the dixie protocol. If one really needs access to these features, then DAP is obviously the way to go. However, I think dixie provides a nice "middle ground", exporting the types of operations that will be most common. -- Tim   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <27221-0@bells.cs.ucl.ac.uk>; Fri, 2 Aug 1991 09:47:27 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA22543; Fri, 2 Aug 91 10:23:08 +0200 Message-Id: <9108020823.AA22543@mitsou.inria.fr> To: osi-ds Cc: osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc (performances of ASN.1 BER) In-Reply-To: Your message of 01 Aug 91 10:50:25 -0400. <9108011450.AA14048@terminator.cc.umich.edu> Date: Fri, 02 Aug 91 10:22:28 BST From: Christian Huitema >Well, I have to disagree on this point. ASN.1 is harder than a simple >text encoding. Even if this point is debatable, it is certainly true >that the coding investment for a text encoding is much much less than >that for ASN.1. The choice of quipu text encodings was really incidental. >It seemed to make more sense than coming up with a separate one of our >own. Contrarily to what you may think, ASN.1 is not harder than text. In fact, our ASN.1 compiler (MAVROS) can generate text coding functions in parallel to the ASN.1-BER coding functions -- it can also generate "light weight" routines, which are mostly useful for CPU intensive applications. Here are the results of a test. For various syntaxes, we show the coding and decoding cpu time, and the size of the encoding. The test case consists of a sequence of 20 X.400 messages; only the P1 enveloppe is decoded: Coding to ASN.1-BER - 51664 us - 8647 o Coding to light-weight - 35998 us - 18524 o Coding to text - 233823 us - 36892 o Decoding from ASN.1-BER - 126661 us - 8647 o Decoding from light-weight - 66664 us - 18524 o Decoding from text - 1481440 us - 36892 o Field/field comparison - 40998 us - Field/field copy + alloc - 121661 us - The results are quite clear: coding in BER, for complex protocols like X.400 or X.500, is less than twice slower than light-weight routines (similar to SUN XDR or OSF NIDL), but is about twice more compact. In fact, ASN-1 BER is well adapted to these protocols, which contain highly structured information, made mostly of text strings; light-weight routines have a much more decisive advantage if the application is more computation oriented, i.e. contain more integer and/or floating point numbers than text strings. For all syntaxes, decoding is much slower than coding: teh routines were designed to be "secure", i.e. they include systematic boundary checks and look up for syntax errors. This kind of security has indeed a cost. Text coding is more than 4 times slower than coding in ASN.1; text decoding more than 10 times slower; the text string are more than five times longer. This is quite reasonable to understand, as the text coding present the structure of the information in an "user-friendly" manner, while BER is designed for "machine readability". For example, an integer parameter in the message will be represented by something like: "foobar= 17;" which is less machine friendly than the ASN.1 encoding: '020111'H The only case where text coding are marginally faster than ASN.1 encodings is that of floating point data -- clearly not very frequent in X.500. Another interesting point is the comparison with "field per field" comparison and copy routines. These routine, automatically generated by the MAVROS compiler, do the obvious thing: use field comparison for octet strings, use "malloc" and field copy for copying string components. As you may observe, the "comparison" is only 20% faster than BER encoding, and slightly slower than light-weight coding (that is, in case of equality, where all fields must be tested). The "copy" is just slightly faster than ASN1-BER decoding, twice slower than light weight coding. This is due to a different memory allocation strategy: the decoding routines generated by MAVROS return a pointer to the location of the string in the buffer, rather than copying it. A side effect of this comparison is to show that the code generated for the coding routines is reasonably efficient... Then, what of size? It depends mightily of your compiler -- I dont have figures for ISODE. In any case, this is a problem of implementation: you can always trade size for performance, e.g. by using the kind of "interpretable" chained lists suggested in the X-OPEN APIs. The test program that produced the results quoted above has the following size: % size perf_mvr text data bss dec hex 245760 16384 4464 266608 41170 % It includes the full coding of X.400 P1, and all the syntaxes mentionned above, and a reasonable size of testing code. I dont have the detailed figures handy, but by looking at the source can give you the following hint: for 1 line of "light-weight", you should count about 2 lines of "BER", and about 3 lines of "text". Christian Huitema PS. I enclose an example of the "text encoded P1", so that you get the idea. Key-words are in French. ------------------------------------------------ < MPDU_Utilisateur= < < Identificateur_MPDU= < < < PrintableString= fr>; < PrintableString= atlas>; Identificateur_Domaine_Prive= < PrintableString= inria>>; "632761832@jerry.inria.fr">; expediteur= < < Nom_Pays= < PrintableString= fr>; Nom_Domaine_Administratif= < PrintableString= atlas>; Nom_Domaine_Prive= < PrintableString= inria>; Nom_Organisation= jerry; Nom_Personne= < nom= huitema; >; >; >; initiaux= < BIT STRING= '0010000000'B; >; Type_Contenu= p2; ID_UA_Contenu= test; Indicateur_Message= '0011'B; destinataires= < < destinataire= < < Nom_Pays= < PrintableString= CH>; Nom_Domaine_Administratif= < PrintableString= ARCOM>; Nom_Domaine_Prive= < PrintableString= SWITCH>; Nom_Organisation= SWITCH; Nom_Personne= < nom= "no such user"; >; OU= < badaboum>>; >; Identificateur_Complementaire= 1; Indicateur_Destinataire= '10101'B; >>; Informations_Trace= < < < < PrintableString= fr>; < PrintableString= atlas>; Identificateur_Domaine_Prive= < PrintableString= inria>>; < arrivee= "900119161017+010" "0"; action= relaye; >>>>; 'A0803180A806140474657374A2453143A041603F303D610413024348'H '620713054152434F4DA20813065357495443488306535749544348A5'H '0E800C6E6F20737563682075736572A60A130862616461626F756D6B'H '2413223633323736313833312E32303439332E312861296A65727279'H '2E696E7269612E6672A02E602C302A6104130266726207130561746C'H '6173A2071305696E72696183056A65727279A509800768756974656D'H '610000302AA02831038001053621041F546869732073686F756C6420'H '67656E65726174652061204E41434B2E2E0D0A0000'H>>;   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <3353-305@bells.cs.ucl.ac.uk>; Mon, 5 Aug 1991 10:32:04 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <14463-0@sun2.nsfnet-relay.ac.uk>; Fri, 2 Aug 1991 23:31:33 +0100 Received: from terminator.cc.umich.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa15283; 2 Aug 91 20:06 BST Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA06703; Fri, 2 Aug 91 15:06:37 -0400 Message-Id: <9108021906.AA06703@terminator.cc.umich.edu> To: Christian Huitema Cc: osi-ds , osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc (performances of ASN.1 BER) In-Reply-To: Your message of "Fri, 02 Aug 91 10:22:28 BST." <9108020823.AA22543@mitsou.inria.fr> Date: Fri, 02 Aug 91 15:06:39 -0400 From: Tim Howes > Contrarily to what you may think, ASN.1 is not harder than text. In fact, our > ASN.1 compiler (MAVROS) can generate text coding functions in parallel to the > ASN.1-BER coding functions -- it can also generate "light weight" routines, > which are mostly useful for CPU intensive applications. Here are the results > of a test. For various syntaxes, we show the coding and decoding cpu time, > and the size of the encoding. The test case consists of a sequence of 20 X.400 > messages; only the P1 enveloppe is decoded: > > Coding to ASN.1-BER - 51664 us - 8647 o > Coding to light-weight - 35998 us - 18524 o > Coding to text - 233823 us - 36892 o > > Decoding from ASN.1-BER - 126661 us - 8647 o > Decoding from light-weight - 66664 us - 18524 o > Decoding from text - 1481440 us - 36892 o > > Field/field comparison - 40998 us - > Field/field copy + alloc - 121661 us - > > The results are quite clear: coding in BER, for complex protocols like X.400 > or X.500, is less than twice slower than light-weight routines (similar to SUN > XDR or OSF NIDL), but is about twice more compact. In fact, ASN-1 BER is well > adapted to these protocols, which contain highly structured information, made > mostly of text strings; light-weight routines have a much more decisive > advantage if the application is more computation oriented, i.e. contain more > integer and/or floating point numbers than text strings. What sort of text encoding does this produce? Certainly your tests show that MAVROS is highly optimized for ASN.1 (as one might expect), but it's hard to believe that the text numbers are indicative of some general relationship (ASN.1 is faster than text). I'm sure that I could come up with a text encoding that was hideously worse than anything ASN.1 could produce. The point is that for the majority of attribute types that are commonly accessed (e.g., by our Mac DUA), the text encoding consumes about zero time. In other words, plain text is "encoded" as plain text. > Text coding is more than 4 times slower than coding in ASN.1; text decoding > more than 10 times slower; the text string are more than five times longer. > This is quite reasonable to understand, as the text coding present the > structure of the information in an "user-friendly" manner, while BER is > designed for "machine readability". For example, an integer parameter in the > message will be represented by something like: > "foobar= 17;" > which is less machine friendly than the ASN.1 encoding: > '020111'H > The only case where text coding are marginally faster than ASN.1 encodings is > that of floating point data -- clearly not very frequent in X.500. I think you are assuming something about our text encoding format which is not true. Text coding may be 4 times slower than ASN.1 in your implementation and choice of encoding scheme, but that can't be generalized, it seems to me. Are you thinking that by "text encoding" I mean "encoding into text that describes the ASN.1"? That's not the case. The quipu EDB format is just an "ad hoc" way of representing things as text in a database. -- Tim   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <10644-4@bells.cs.ucl.ac.uk>; Mon, 5 Aug 1991 10:54:55 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 5 Aug 1991 10:21:30 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 5 Aug 1991 10:18:02 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Mon, 5 Aug 1991 12:17:00 +0100 Date: Mon, 5 Aug 1991 09:18:02 +0000 X400-Originator: HUIZER@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.774:05.07.91.09.18.02] X400-Content-Type: P2-1984 (2) Content-Identifier: RARE WG3 meet... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"1775 Mon Aug 5 11:18:12 1991"@surfnet.nl> To: Rare WG3 , RARE & IETF OSI-DS wg Subject: RARE WG3 meeting in Zurich 30/9 - 2/10/91 X-VMS-To: WG3,OSI-DS Sender: HUIZER@nl.surfnet Here's the meeting info once more, some more detail in there too. Will all people who are coming please inform us, so we know what to expect? Please send mail indicating your participation to: lenggenhager@switch.ch Erik ___________________________________________________________________________ Program RARE WG3 meeting 30 sept.-2 oct. 1991 Zurich, Switzerland Zurich, Switch/ETHZ 30 september 1300 DS session, including P2.1 operational meeting 1800 closing 1 october Big room Terminal room Lecture room with video no facilities ------------------------------------------------------ 0900 Paul Barker (UCL/Paradise) Paradise Central DUA 0940 Chris Weider (Merit) FOX 1030 break 1100 Andrew Findlay (Brunell) Brunell (X)DUA 1145 Graham Knight (Level-7 Ltd) P2.2 Prototype 1300 Lunch PARALLEL SESSIONS: 1400 Tim Berners-Lee (CERN) Colin Robbins (Xtel) Hypertext Tutorial DSA 1500 Steve Benford (Nottingham Univ.) continued Group Communications 1600 Plenary 1700 Drinks Various demo's The various demos would consist of: ETHZ ITAXA DUA for Mac Steve benford Group Communication PSI (?) Mac DUA Tim Howes (?) Mac DUA Brunel DUA's Paul Barker DUA Level-7 P2.2 Celestino Tomas VMS DUA X-tel DUAs Tim Berners-Lee Hypertext next Maria Dimou CERN Directory Joyce Reynolds (?) 2 october 0900 USIS part (maybe parallel some DS demo evaluations) 1600 P2.2 whatever 1800 end of meeting HOTEL INFO: ___________________________________________________________________________ From: Thomas Lenggenhager Subject: RARE WG3 in Zurich (30.9.-2.10): Hotel Information We were able to place block reservations in two hotels nearby the meeting room. These reservations are open until end of July. Please say explicetly that you want one of these reservations made under the name 'SWITCH'. For some of you coming from further away, it couldbe probably of interest that in the week after that meeting the Telecom 91 takes place in Geneva. In case you want to spend the few days inbetween somewhere in Switzerland, you could contact one of the following tourist information offices: Tourist Information for Zurich Tel: 41 1 211 40 00 Bahnhofplatz 15 Fax: 41 1 212 01 41 CH-8001 Zurich Swiss Tourist Information Tel: 41 1 288 11 11 Postfach Fax: 41 1 288 12 05 CH-8027 Zurich Shortly before the meeting I will send around the information on how to get from the airport into the city and to the meeting room. (It takes only about 30 to 45 minutes to get from the airport to the meeting room.) Thomas Lenggenhager SWITCH =============================================================================== Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerland INET: | Tel: +41-1-261 8178 | Fax: +41-1-261 8133 X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH =========== (All prices are given in Swiss Francs) *** Hotel Rex (Garni) Tel: 41 1 361 96 46 Weinbergstrasse 92 Fax: 41 1 361 20 47 CH-8006 Zurich Price: 140.00 (5 rooms have twin beds, 5 rooms have "normal beds), bath or shower, taxes, breakfast, service included) 10 Rooms have been booked until July 29, 1991 at the latest. After that day, there will not be any contingent booked for the meeting participants. Please ask for a room booked on behalf of SWITCH. 5 minutes to the meeting room, new, rather large rooms, phone, colour TV *** Hotel Ruetli Tel: 41 1 251 54 26 Zaehringerstrasse 43 Fax: 41 1 261 21 53 CH-8001 Zurich Price: 130.00 (bath or shower, WC, breakfast, taxes, service included). 12 rooms have been booked until July 31, 1991 at the latest. After that day, there will not be any contingent booked for the meeting participants. Please ask for a room booked on behalf of SWITCH. 4 minutes to the meeting room, new rooms, phone, colour TV Other possible hotels: ** Hotel Sunnehus Tel: 41 1 251 65 80 Sonneggstrasse 17 CH-8006 Zurich Price appr. 120 - 140 3 minutes to the meeting room *** Hotel Astor Tel: 41 1 251 35 60 Weinbergstrasse 44 Fax: 41 1 251 49 15 CH-8006 Zurich Price: appr. 150 - 160 rather small rooms one minute to the meeting room *** Hotel Arc Royal Comfort Inn Tel: 41 1 261 67 10 Leonhardstrasse 6 Fax: 41 1 251 47 80 CH-8001 Zurich Price appr. 110 - 140 2 minutes to the meeting room **** Hotel Helmhaus Tel: 41 1 251 88 10 Schifflaendeplatz 30 Fax: 41 1 251 04 30 CH-8001 Zurich Price appr. 140 5 min. ride by tram the hotel is located in the "old" part of the city. ==========   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11590-0@bells.cs.ucl.ac.uk>; Fri, 9 Aug 1991 10:51:47 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs Date: Fri, 09 Aug 91 10:51:41 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 26th July - Friday 9th July. Probes from UCL, ULCC, STC, MRP of Adelaide, and now from GMD in Berlin. (Thank you for joining in!) Bind Fail %age Best Worst Ave Address NO: Boa Constrictor (Norway Backup) 218 4 98.17 0.1 1.0 0.37 dsa_available 152 7 95.39 2.8 65.3 19.67 Internet 141 42 70.21 0.0 9.7 16.26 IXI 123 88 28.46 0.0 5.2 4.73 Int-X.25 Electric Eel (Norway Master) 221 58 73.76 0.1 1.0 0.36 dsa_available 156 28 82.05 2.2 86.6 8.59 Internet 143 71 50.35 0.0 4.7 4.24 IXI 126 90 28.57 0.0 5.5 2.72 Int-X.25 CH: Condor (ETH Zurich) 154 4 97.40 0.1 0.1 0.10 dsa_available 154 6 96.10 1.6 54.0 13.70 Internet 124 39 68.55 0.0 6.2 6.55 Int-X.25 Chinchilla (Swiss Master) 153 7 95.42 0.1 0.1 0.10 dsa_available 153 7 95.42 2.2 27.5 18.17 Internet CA: Beluga Whale (Canada Master) 76 2 97.37 0.1 0.1 0.10 dsa_available 76 2 97.37 3.2 25.4 18.80 Internet Pangolin (Northern Telecom Master) 149 15 89.93 0.1 0.1 0.10 dsa_available 47 2 95.74 1.2 90.8 10.40 Private TCP 148 16 89.19 4.0 37.9 18.34 Internet Wayne Gretzky (Old Canada Master) 149 149 0.00 - - - dsa_available 149 149 0.00 - - - Internet SE: Hummingbird (Sweden Master) 148 7 95.27 0.1 0.1 0.10 dsa_available 148 7 95.27 2.9 67.9 20.39 Internet 87 87 0.00 - - - '0101'H/X121 IS: Elephant Seal (Iceland Master) 155 9 94.19 0.1 0.1 0.10 dsa_available 155 9 94.19 5.8 59.8 33.65 Internet DE: Puma (GMD/FOKUS) 193 21 89.12 0.1 1.0 0.31 dsa_available 134 9 93.28 0.5 91.0 12.33 Internet 14 3 78.57 5.0 127.3 24.94 Internet 122 49 59.84 0.0 5.7 7.61 IXI 125 60 52.00 0.0 7.9 7.84 Int-X.25 Margay (GMD/F3, DE backup) 204 37 81.86 0.1 1.0 0.33 dsa_available 152 20 86.84 1.4 39.2 24.40 Internet 126 46 63.49 0.0 9.0 11.54 Int-X.25 130 60 53.85 0.0 6.0 7.15 IXI AU: Anaconda (AU Master) 156 18 88.46 0.1 0.1 0.10 dsa_available 155 28 81.94 1.8 18.0 14.28 Internet 125 85 32.00 0.0 13.8 11.59 Int-X.25 Bush Dog (master for AU (phony)) 156 71 54.49 0.1 0.1 0.10 dsa_available 156 71 54.49 0.6 18.3 33.22 Internet UK: Coypu (Thorn acces pt to quipu) 226 29 87.17 0.1 1.0 0.38 dsa_available 87 10 88.51 1.7 3.9 7.52 X121 49 0 100.00 0.7 2.7 1.74 Local Ether 156 16 89.74 0.7 40.7 15.00 Internet 109 25 77.06 1.9 4.4 16.55 Janet False Cobra (Root, GB backup) 222 29 86.94 0.1 1.0 0.38 dsa_available 85 11 87.06 1.6 3.7 6.49 X121 153 15 90.20 0.7 18.7 7.53 Internet 108 23 78.70 1.5 3.4 4.03 Janet 142 64 54.93 0.0 4.8 3.93 IXI Vampire Bat (GB backup) 127 40 68.50 0.0 1.0 0.43 dsa_available 50 0 100.00 0.5 1.6 0.73 Private TCP 88 3 96.59 1.4 8.1 3.78 Janet 122 42 65.57 0.0 4.9 3.11 IXI Giant Tortoise (Root, GB Master) 222 97 56.31 0.0 1.0 0.38 dsa_available 87 31 64.37 0.4 3.5 7.72 X121 108 34 68.52 1.0 3.7 2.99 Janet 153 68 55.56 0.0 9.7 5.25 Internet 142 69 51.41 0.0 3.7 2.13 IXI Passionflower Leaf Beetle (GB Domain name information) 199 102 48.74 0.0 1.0 0.21 dsa_available 86 63 26.74 0.0 6.1 2.72 X121 149 69 53.69 0.0 29.2 7.57 Internet 88 59 32.95 0.0 5.7 5.34 Janet 122 96 21.31 0.0 6.6 2.43 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 96 96 0.00 - - - dsa_available 96 96 0.00 - - - Janet DK: Axolotl (DK Master) 154 31 79.87 0.1 0.1 0.10 dsa_available 154 31 79.87 2.6 66.2 20.19 Internet IL Dorcan Gazelle (Israel Master) 76 18 76.32 0.1 0.1 0.10 dsa_available 76 18 76.32 5.6 27.1 30.91 Internet US: Fruit Bat (US@l=NY master) 153 45 70.59 0.1 0.1 0.10 dsa_available 154 46 70.13 1.3 46.9 28.78 Internet Alpaca (US master) 157 54 65.61 0.1 0.1 0.10 dsa_available 157 54 65.61 1.1 11.9 12.34 Internet Giant Anteater (Various slave) 153 153 0.00 - - - dsa_available 153 153 0.00 - - - Internet IE: Irish Elk (Republic of Ireland Master) 216 85 60.65 0.1 1.0 0.37 dsa_available 152 47 69.08 2.6 101.5 21.06 Internet 142 100 29.58 0.0 12.9 20.36 IXI FI: Jaguar (Finland Master) 152 67 55.92 0.1 0.1 0.10 dsa_available 152 70 53.95 2.7 62.0 19.64 Internet 87 53 39.08 0.0 9.0 6.31 '0101'H/X121 NL: Hornero (NL Master) 154 72 53.25 0.1 0.1 0.10 dsa_available 87 35 59.77 2.9 6.3 6.15 '0101'H/X121 154 73 52.60 2.2 22.8 11.23 Internet Agouti (NL Slave) 157 94 40.13 0.0 0.1 0.07 dsa_available 157 94 40.13 0.0 16.6 7.15 Internet ES: Iguana (ES Master. Programa IRIS) 219 110 49.77 0.1 1.0 0.37 dsa_available 143 82 42.66 0.0 5.2 11.70 IXI 154 94 38.96 3.0 79.4 17.05 Internet 126 78 38.10 0.0 7.6 15.63 Int-X.25 Cayman (Madrid Uni.) 49 44 10.20 0.0 0.1 0.03 dsa_available 49 44 10.20 0.0 7.2 5.33 Int-X.25 49 45 8.16 0.0 7.2 4.48 IXI 49 49 0.00 - - - Internet AT: Piranah (AT Master) 148 122 17.57 0.0 0.1 0.03 dsa_available 148 122 17.57 0.0 10.7 5.16 Internet 125 114 8.80 0.0 8.4 3.01 Int-X.25 BE: Woolly Spider Monkey (Belgium Master) 74 74 0.00 - - - dsa_available 74 74 0.00 - - - Internet   Return-Path: Received: from ws28.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <17463-0@bells.cs.ucl.ac.uk>; Fri, 9 Aug 1991 17:46:15 +0100 Received: by ws28.nisc.sri.com (5.64/SRI-NISC1.1) id AA02461; Fri, 9 Aug 91 09:45:53 -0700 Message-Id: <9108091645.AA02461@ws28.nisc.sri.com> To: osi-ds@uk.ac.ucl.cs Cc: rlang@com.SRI.NISC Subject: Object Oriented Book Date: Fri, 09 Aug 91 09:45:52 BST From: Ruth Lang Several people asked that I post a reference to the object oriented programming and design book I mentioned during the OSI-DS session at IETF. Cox, Brad J., "Object Oriented Programming -- An Evolutionary Approach," Addison-Wesley Publishing Company, 1987. Ruth Lang   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25514-0@bells.cs.ucl.ac.uk>; Wed, 14 Aug 1991 12:39:10 +0100 To: Russ Wright cc: dssig@edu.uci.ics, osi-ds@uk.ac.ucl.cs, Rolf Exner Subject: Re: liaison letter form NADF Phone: +44-71-380-7294 In-reply-to: Your message of Fri, 02 Aug 91 16:51:20 +0000. <9108022353.AA20116@lbl.gov> Date: Wed, 14 Aug 91 12:39:07 +0100 Message-ID: <2102.682169947@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Russ, I think that there are valid points on both sides of the argument. Let me propose a solution which might be a way out. It relies on a 92 feature, which might be a problem for some of you. Define an attribute: Generalised Postal Address, which has large upper bounds, but is otherwise the same syntax. This should have a new attribute type (OID). Define the Postal Address as a subtype of Generalised Postal Address. This should use the current OID to retain backwards compatibility. This needs tackling in the base standard. I am cc'ing the editor of the relevant document (Rolf Exner). Steve   Return-Path: Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1291-0@bells.cs.ucl.ac.uk>; Wed, 14 Aug 1991 14:57:08 +0100 Received: from mcsun by kestrel.Ukc.AC.UK via EUnet with authorised UUCP id aa07710; 14 Aug 91 14:49 BST Received: from corton.inria.fr by mcsun.EU.net with SMTP; id AA02255 (5.65a/CWI-2.101); Wed, 14 Aug 1991 15:40:35 +0200 Received: from edfder1.UUCP by corton.inria.fr (5.65c+/90.0.9) via Fnet-EUnet id AA18284; Wed, 14 Aug 91 15:11:50 +0200 (MET) Received: from cli53an.edf.fr by edfder1.edf.fr, Wed, 14 Aug 91 15:01:42 +0200 Received: from loghost by cli53an.edf.fr (4.0/SMI-4.0) id AA08963; Wed, 14 Aug 91 15:05:51 +0200 To: osi-ds@uk.ac.ucl.cs Cc: Steve Titcombe Subject: Re: DSA Probe Statistics For Root DSAs In-Reply-To: Steve Titcombe's message of 09 Aug 91 10:51:41 +0100. <"12128 Fri Aug 9 10:54:16 1991"@cs.ucl.ac.uk> Date: Wed, 14 Aug 91 15:05:51 +0200 Message-Id: <8962.682175151@cli53an> From: Sylvain Langlois > DSA Probe Statistics For Root DSAs, for the period Friday 26th July - Friday > 9th July. > Probes from UCL, ULCC, STC, MRP of Adelaide, and now from > GMD in Berlin. (Thank you for joining in!) How is it that FR master DSA (opaxdsa, located at Ecole des Mines de Saint-Etienne) is not on the stats list? QUIPU and Pizzaro have been shown to interoperate now. Isn't France hooked to the Directory yet? Sylvain ---------------- Sylvain Langlois "Dogmatic attachement to the supposed merits (sylvain@cli53an.edf.fr) of a particular structure hinders the search of an appropriate structure" (Robert Fripp)   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Wed, 14 Aug 1991 16:10:07 +0100 Date: Wed, 14 Aug 1991 15:10:07 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.128:14.07.91.15.10.07] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Wed, 14 Aug 1991 16:10:05 +0100) From: Colin Robbins Message-ID: <"26312 Wed Aug 14 16:09:27 1991"@xtel.co.uk> To: Sylvain Langlois Cc: osi-ds@uk.ac.ucl.cs, Steve Titcombe In-Reply-To: <8962.682175151@cli53an> Subject: Re: DSA Probe Statistics For Root DSAs The probe looks for, and probes DSAs that have entries in the top level EDB file. The c=FR DSA is not a QUIPU one, and so does not the QUIPU requirement that its DSA is named at the top level. I would think the probe could be altered to look for all non-leaf entries at the root level, and probe the relevant DSA, no matter where the DSAs entry is (indeed, even if the DSA does not have an entry at all!). Colin   Return-Path: Received: from kwai.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <14036-0@bells.cs.ucl.ac.uk>; Wed, 14 Aug 1991 23:42:33 +0100 X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 15 Aug 91 00:43:56+0200 X400-Received: by /PRMD=emse/ADMD=atlas/C=fr/; Relayed; 15 Aug 91 00:39:53+0200 Date: 15 Aug 91 00:39:53+0200 From: Paul-Andre Pays Message-ID: <9108142239.AA23474@mars.emse.fr> To: "c.robbins Ltd.NONE.GB"@uk.ac.ucl.cs, sylvain@fr.edf.cli53an PP_warning: Parse error in original version of preceding line Subject: Re: DSA Probe Statistics For Root DSAs cc: S.Titcombe@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs well, I u derstand the "why" but then the stats are Quipu stats and this have nothing to do with Paradise, thus please don't use this bandwith for informations only relevant for a selected community. -- PAP   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <10645-0@bells.cs.ucl.ac.uk>; Fri, 16 Aug 1991 21:33:47 +0100 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-3) id ; Fri, 16 Aug 91 13:34:51 -0700 Date: Fri, 16 Aug 91 13:33:33 PDT From: hotz@edu.ISI Posted-Date: Fri, 16 Aug 91 13:33:33 PDT Message-Id: <9108162033.AA02619@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Fri, 16 Aug 91 13:33:33 PDT To: dsar@edu.ISI Cc: osi-ds@uk.ac.ucl.cs Subject: Directory Services Activities 7/91 July 1991 Issue #5 Directory Services Activities ----------------------------- This report serves as a forum to distribute information about the various efforts working to develop directory services that are for, or effect, the Internet. It is published as part of the FOX Project's efforts to facilitate the coordination and cooperation of different directory services working groups. This report is distributed virtually unchanged as part of the Internet Monthly Report, and a modified version is submitted to the PARADISE International Report. We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. The current reporters list includes: o IETF OSIDS Working Group [X] o IETF DISI Working Group [X] o Field Operational X.500 Project - ISI - Merit - PSI [X] - SRI o National Institute of Standards and Technology [X] o North American Directory Forum [X] o OSI Implementor's Workshop [X] o PARADISE Project o PSI DARPA/NNT X.500 Project [X] o PSI WHITE PAGES PILOT [X] o Registration Authority Committee (ANSI USA RAC) [X] o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) [X] [X] indicates no report this month Steve Hotz (hotz@isi.edu) DS Report Coordinator FOX -- FIELD OPERATIONAL X.500 PROJECT -------------------------------------- The FOX project is a DARPA and NSF sponsored effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. ISI --- Jon Postel convened an early morning meeting of the FOX group at the Atlanta IETF, which included participants from all of the FOX contractors as well as Tim Howes (UofM), Richard Colella (NIST), and Paul Mockapetris (DARPA). Hotz also participated in the OSI-DS and DISI working group meetings, and met informally to discuss FOX concerns with various members of the X.500 community. Steve Hotz (hotz@ISI.EDU) MERIT ----- o Submitted schemas for the following as Internet Drafts: - Information Resources - K-12 Educational Resources - Libraries - NIC Profiles o Continued development of an e-mail based registration and query system for NIC profiles and K-12 people and resources. o Installed ISODE 7.0 and new DSA for FOX related X.500 activities. o Convened MichNet working group on X.500. The goals of this group are to promote the use of X.500 among statewide Merit members and affiliates. o Developed a plan for coordination and evolution of network infrastructure information and WHOIS information. o Installed sendmail with X.500/alias lookup for Sprintmail gateway. o Mark Knopper, Chris Weider, and Tim Howes participated in OSI-DS and DISI working groups at the Atlanta IETF meeting. Mark Knopper (mak@merit.edu) SRI ---- SRI continued correspondence with NIST regarding problems with running Custos 0.1.1. NIST fixed a bug in the Custos DBMS library, and sent replacement code files to SRI. SRI will test the patches in early August. Russ Wright (LBL) and Ruth Lang completed the compilation of the keyword cross-reference list, formatted the document, and held reviews with implementation description authors and with the DISI working group. Near the end of the month, a DISI document, "A Catalog of Available X.500 Implementations," was published as an Internet-Draft. As a results of comments received at the DISI meeting at the Atlanta IETF meeting, the document will be revised, sent out for final review to DISI, and subsequently submitted as an FYI RFC. Chris Weider (Merit), Mark Knopper (Merit), and Ruth Lang held a phone meeting to discuss three related topics: (1) The future of "o=Internet@ou=Site Contacts" and "o=Internet@ou=WHOIS". (2) The status of two OSI-DS Internet-Draft Documents pertaining to the schema and tree structure for network infrastructure information. (3) Replication of "ou=Site Contacts" and "ou=WHOIS". Merit and SRI will work together to combine the two branches of "o=Internet" described in (1) in order to reduce redundancy. The results of this work will be reflected in the two Internet- Draft documents mentioned in (2). In addition, each agreed to pursue the configuration of hardware resources required to support the replication described in (3). Progress on these areas will be reported in subsequent monthly reports. Ruth Lang will participate in the Interop 91 panel session entitled "Fielding Operational X.500 Directory Services. Presentation materials for that panel session were prepared and delivered to Interop in early August as required. SRI responded to several queries regarding the availability of NIC WHOIS data; these queries had been posted to the ietf and tcp-ip mailing lists. Ruth Lang and Ken Harrenstien participated in a FOX project phone conference meeting held on July 9. Ruth Lang attended IETF held in Atlanta during the week of July 29. Ruth Lang (rlang@nisc.sri.com) PARADISE -------- Within PARADISE, PTT Telecom (the Netherlands), PTT Switzerland and Telecom Finland are performing a study on the suitability and expected acceptance of X.500-based Directory Services for European PTT's and service providers. An extensive questionnaire has been formulated and was distributed this month with a view of eliciting information for this study. Respondents are expected to receive an overview of the results of the non-confidential parts of the questionnaire towards the end of 1991. The PTT Telecom Research Laboratories based in Groningen, the Netherlands, is also offering diagnostic test-services for the PARADISE participants for the duration of the pilot. PTT Research is a participant in the development of test-suites for X.500 Directory tests within the European CTS2 project. In this project a group of European companies have written and implemented test suites for the Session, Presentation, ROSE, ACSE and DAP protocols and for both DUAs and DSAs. Of these, the DSA/DAP test suite was designed and implemented mainly by a PTT Research group which will probably also be involved in establishing test suites for DSP and distributed Directory operations. An EC-accredited CTS2 Conformance Testing Service will be set up by the end of 1991. For the PARADISE testing service the Groningen labs will use a DANET test system which will allow conformance, interoperability and robustness testing on specified implementation problems. For further information, contact: John van der Aalst (jvanderaalst@eurokom.ie). This month's site report is from: AUSTRIA Austria is running 3 QUIPU DSAs. The 'main' DSA for Austria (called universities in Austria. Additionally it stores detailed information about the staff of the University of Technology in Graz, e.g. e-mail addresses, phone and fax numbers, postal addresses, etc. The University of Vienna and the University of Technology in Vienna have had their own DSAs (called 'Rockhopper Penguin' and 'Yellow-legged Tortoise') since mid-July and have started to gather and store information about their local staff. The X.500 project of ACONET (the Austrian Scientific Network) is entering its second stage now. The first stage concentrated on the establishment of an X.500 service and its technical, functional and inter-communicational aspects. The second stage will focus on the development of an Information System for Universities and therefore concentrate on organizational and structural aspects as well as on the user interface (ACONET will probably have to develop their own user interface). We are thinking about storing on an X.500 basis information which is to be collected for the following international projects supported by the European Commission: 'TRACE' -- concerning relevant information about universities, colleges, etc in Austria; and 'ERASMUS' -- concerning information which should make it easier to exchange, for example, students or staff from universities in different countries. The advantage of an X.500 solution would be that this information would be available worldwide (as it should be) and would be stored where it is gathered and administered (in contrast to the TRACE approach with their central storage concept). The contact for the Austrian pilot is: Florian Schnabel (schnabel@at.ada.tu-graz.edvz). David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager   Return-Path: Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <14583-0@bells.cs.ucl.ac.uk>; Tue, 20 Aug 1991 18:52:40 +0100 Received: from mcsun by kestrel.Ukc.AC.UK via EUnet with authorised UUCP id aa17282; 20 Aug 91 18:49 BST Received: from ub4b.buug.be by mcsun.EU.net with SMTP; id AA16481 (5.65a/CWI-2.102); Tue, 20 Aug 1991 19:30:36 +0200 Received: by ub4b.buug.be (5.64+/ub4b_01) id AA27659; Tue, 20 Aug 91 19:31:39 +0200 Return-Path: old@sunbim.be Received: from corea.sunbim.uucp (8003c396) by sunbim.be (4.12/SMI-2.2) id AA28225; Tue, 20 Aug 91 17:38:58 -0200 Received: by corea.sunbim.uucp (4.1/SMI-3.0DEV3) id AA08851; Tue, 20 Aug 91 17:22:51 +0200 Date: Tue, 20 Aug 91 17:22:51 +0200 From: Olivier Dubois Message-Id: <9108201522.AA08851@corea.sunbim.uucp> To: osi-ds@uk.ac.ucl.cs Subject: interim approach to Network Addresses Cc: old@be.sunbim Hello, I just read the document dated January 1991 from a copy I get testing ftam with the ucl responder. Although I appreciated it very much I have a comment to make: The graph showing the DSP encoding part, the core of the document in fact, are not very easy to figure and to understand. There is more, it seems to me thaht it is inconsistant that for X.25, the DSP prefix is included in the encoding while for RFC-1006 e ncoding, it appears only in the example. I don't know if the document already achieve an RFC status but it seems to me that a small modification there would improve it. Another comment I would like to make is that at least a small paragraph should be devoted to describing the IDP part of the proposed encoding, particularly, the IDI allocation (I know there is no perfect allocation of value to this field, but for complete ness, this should be noticed). These comments are not to be taken to seriously, they are just some remark made by someone who would like to avoid other the problem its small mental capabilities cause him. Olivier Dubois.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <29350-0@bells.cs.ucl.ac.uk>; Thu, 22 Aug 1991 11:23:12 +0100 To: Valdis Kletnieks cc: osi-ds@uk.ac.ucl.cs Subject: Re: X.500 and Domains... Phone: +44-71-380-7294 In-reply-to: Your message of Mon, 29 Jul 91 14:22:25 -0400. <910729.142225.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Thu, 22 Aug 91 11:23:10 +0100 Message-ID: <1728.682856590@UK.AC.UCL.CS> From: Steve Hardcastle-Kille We have done some work on this. I will send you a longer private message. I think that this work is VERY important for progressing directory services on the Internet. Many sites will find the management benefits of this approach attractive. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <715-0@bells.cs.ucl.ac.uk>; Thu, 22 Aug 1991 12:18:20 +0100 To: Christian Huitema cc: osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 30 Jul 91 10:55:50 +0100. <9107300856.AA20083@mitsou.inria.fr> Date: Thu, 22 Aug 91 12:18:18 +0100 Message-ID: <2042.682859898@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Christian, Following the SNMP type approach, and having a cut down DAP using ASN.1 and mapping onto either TCP or UDP is a good idea. I prefer the name SDP (Simple Directory Protocol). I agree with the choice of ASN.1 encoding for this protocol. The key thing with X.500 is to have a unified data model. Non-X.500 protocols which follow this model have definite potential: - lightwieght DUAs - extending use of X.500 to new applications (e.g., policy based routing) - countering manr perfomance criticisms that have been raised It would also allow some of the annoying problems in the X.500 protocols to be fixed up. I don't think that it is such a big piece of work. I might have a go at this when the core OSI-DS RFCs have been finalised. How much interest would there be in implementing such a protocol? I think that there is also a lot of merit in a text based protocol such as DIXIE. Performance is an issue, but I don't think that the difference betwen text and ASN is such a big deal for small PDUs such as this. When implementing a small DUA there are two issues: - use of ASN will need quite a few libraries and PDU parsers and the such like. This will usually add quite a large overhead to the size of the process. This will improve as better quality ASN compilers become widely available. - Text encoding is much more amenable to an implementation where simple usage only is made. PDUs can be generated from string constants, parsing to extract only relevant data is straightforward. I think that it would be useful to discuss DIXIE and Marshall's Directory Assistance Protocol at the next OSI-DS meeting. Steve   Return-Path: Received: from gateway.mitre.org by bells.cs.ucl.ac.uk with SMTP inbound id <2995-0@bells.cs.ucl.ac.uk>; Thu, 22 Aug 1991 13:35:09 +0100 Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA28266; Thu, 22 Aug 91 08:34:28 -0400 Full-Name: Bill Barns Message-Id: <9108221234.AA28266@gateway.mitre.org> To: Steve Hardcastle-Kille Cc: osi-ds@uk.ac.ucl.cs, barns@org.mitre.gateway Subject: Re: DIXIE rfc In-Reply-To: Your message of "Thu, 22 Aug 91 12:18:18 BST." <2042.682859898@UK.AC.UCL.CS> Date: Thu, 22 Aug 91 08:33:58 -0400 From: barns@org.mitre.gateway I'd like to ask, Is there any expectation that any of these lightweight protocol ideas ever get implemented in an OSI stack (and offered up for standardization eventually, perhaps) or is the intention strictly limited to TCP/IP? I don't intend to imply any religious views by asking the question. I just wondered what people have in mind. Bill Barns / barns@gateway.mitre.org   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <3725-0@bells.cs.ucl.ac.uk>; Thu, 22 Aug 1991 14:02:13 +0100 To: barns@org.mitre.gateway cc: osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 22 Aug 91 08:33:58 -0400. <9108221234.AA28266@gateway.mitre.org> Date: Thu, 22 Aug 91 14:02:11 +0100 Message-ID: <2450.682866131@UK.AC.UCL.CS> From: Steve Hardcastle-Kille There is a real problem that "lightweight" and "OSI stack" are concepts which do not sit very well together. At this stage, it is appropriate to make experiments. I think that it is a good idea to standardise protocols which are shown to be useful. Steve   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <8568-0@bells.cs.ucl.ac.uk>; Fri, 23 Aug 1991 01:42:39 +0100 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA23792; Thu, 22 Aug 91 20:43:05 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA08978; Thu, 22 Aug 91 20:43:04 EDT Date: Thu, 22 Aug 91 20:43:04 EDT From: mak@edu.merit Message-Id: <9108230043.AA08978@home.merit.edu> To: osi-ds@uk.ac.ucl.cs, skh@edu.merit Subject: Quipu vs. X.500 Hi. If you were a vendor and had implemented from the X.500 recommendations, and then you wanted to add functionality to interoperate with quipu, what would you add? I know that replication is needed because quipu requires replicating the top level EDB. In this case I'm interested in operating over a pure OSI TP4/CLNP stack. Mark ps. This info will be very useful to the vendors that will demonstrate X.500 at Interop 91.   Return-Path: Received: from terminator.cc.umich.edu by bells.cs.ucl.ac.uk with SMTP inbound id <17943-0@bells.cs.ucl.ac.uk>; Fri, 23 Aug 1991 04:38:30 +0100 Received: from vertigo.rs.itd.umich.edu by terminator.cc.umich.edu (5.64/1123-1.0) id AA06603; Thu, 22 Aug 91 23:38:46 -0400 Message-Id: <9108230338.AA06603@terminator.cc.umich.edu> To: barns@org.mitre.gateway Cc: Steve Hardcastle-Kille , osi-ds@uk.ac.ucl.cs Subject: Re: DIXIE rfc In-Reply-To: Your message of "Thu, 22 Aug 91 08:33:58 EDT." <9108221234.AA28266@gateway.mitre.org> Date: Thu, 22 Aug 91 23:38:44 -0400 From: Tim Howes > I'd like to ask, Is there any expectation that any of these lightweight > protocol ideas ever get implemented in an OSI stack (and offered up > for standardization eventually, perhaps) or is the intention strictly > limited to TCP/IP? I have no intention of doing DIXIE over anything but TCP/IP. Since the idea was to avoid the overhead of an OSI stack, it wouldn't make much sense. -- Tim   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <6302-0@bells.cs.ucl.ac.uk>; Fri, 23 Aug 1991 09:48:13 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs Date: Fri, 23 Aug 91 09:48:12 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 9th August - Friday 23rd AUgust. Probes from UCL, ULCC, STC, MRP of Adelaide, and now from GMD in Berlin. Bind Fail %age Best Worst Ave Address GB: False Cobra (Root, GB backup) 299 10 96.66 0.1 1.0 0.32 dsa_available 176 6 96.59 1.5 3.7 6.15 X121 201 5 97.51 1.3 2.9 3.59 Janet 224 10 95.54 0.3 32.4 6.88 Internet 200 13 93.50 1.3 4.0 3.68 IXI Coypu (Thorn acces pt to quipu) 307 11 96.42 0.1 1.0 0.33 dsa_available 180 6 96.67 1.6 3.8 6.53 X121 69 0 100.00 0.6 3.6 0.93 Local Ether 229 8 96.51 0.4 94.3 11.96 Internet 206 8 96.12 1.3 4.6 7.03 Janet Vampire Bat (GB backup) 196 15 92.35 0.1 1.0 0.38 dsa_available 60 0 100.00 0.5 1.6 0.71 Private TCP 186 14 92.47 1.4 12.4 4.99 Janet 185 23 87.57 2.1 4.7 4.54 IXI Giant Tortoise (Root, GB Master) 304 87 71.38 0.1 1.0 0.33 dsa_available 179 52 70.95 0.3 3.4 2.59 X121 204 43 78.92 1.0 3.5 2.82 Janet 203 43 78.82 0.7 4.4 2.76 IXI 228 68 70.18 0.2 12.9 3.66 Internet Passionflower Leaf Beetle (GB Domain name information) 280 93 66.79 0.0 1.0 0.27 dsa_available 177 76 57.06 0.0 5.8 4.05 X121 187 70 62.57 0.0 8.6 5.32 Janet 219 89 59.36 0.0 46.1 10.44 Internet 186 83 55.38 0.0 6.3 4.71 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 188 188 0.00 - - - dsa_available 188 188 0.00 - - - Janet CA: Beluga Whale (Canada Master) 129 5 96.12 0.1 0.1 0.10 dsa_available 129 5 96.12 2.6 45.2 12.10 Internet Pangolin (Northern Telecom Master) 218 23 89.45 0.1 0.1 0.10 dsa_available 52 2 96.15 2.0 50.6 11.29 Private TCP 218 29 86.70 2.6 22.3 15.99 Internet Wayne Gretzky (Old Canada Master) 219 219 0.00 - - - dsa_available 219 219 0.00 - - - Internet SE: Hummingbird (Sweden Master) 218 19 91.28 0.1 0.1 0.10 dsa_available 218 19 91.28 1.9 109.5 18.27 Internet 179 179 0.00 - - - '0101'H/X121 US: Fruit Bat (US@l=NY master) 226 20 91.15 0.1 0.1 0.10 dsa_available 226 20 91.15 1.5 35.7 21.89 Internet Alpaca (US master) 233 31 86.70 0.1 0.1 0.10 dsa_available 233 31 86.70 1.0 29.2 9.78 Internet Giant Anteater (Various slave) 219 219 0.00 - - - dsa_available 219 219 0.00 - - - Internet CH: Condor (ETH Zurich) 229 21 90.83 0.1 0.1 0.10 dsa_available 229 27 88.21 1.7 56.1 10.74 Internet 190 52 72.63 3.2 6.3 15.28 Int-X.25 Chinchilla (Swiss Master) 226 23 89.82 0.1 0.1 0.10 dsa_available 226 23 89.82 2.1 66.2 15.25 Internet DK: Axolotl (DK Master) 225 25 88.89 0.1 0.1 0.10 dsa_available 225 25 88.89 2.8 29.3 16.90 Internet NO: Electric Eel (Norway Master) 297 34 88.55 0.1 1.0 0.31 dsa_available 229 21 90.83 1.5 112.6 10.77 Internet 203 33 83.74 1.5 4.5 5.69 IXI 191 60 68.59 0.0 7.1 5.58 Int-X.25 Boa Constrictor (Norway Backup) 304 48 84.21 0.1 1.0 0.32 dsa_available 208 33 84.13 1.7 9.5 12.45 IXI 230 46 80.00 0.0 39.8 22.79 Internet 190 77 59.47 0.0 5.1 5.72 Int-X.25 IS: Elephant Seal (Iceland Master) 229 30 86.90 0.1 0.1 0.10 dsa_available 229 30 86.90 5.4 73.9 25.60 Internet DE: Puma (GMD/FOKUS) 270 36 86.67 0.1 1.0 0.28 dsa_available 188 15 92.02 1.1 6.6 9.39 Int-X.25 186 22 88.17 1.9 5.2 6.60 IXI 150 21 86.00 0.0 16.0 6.53 Internet 67 35 47.76 4.9 28.4 21.70 Internet Margay (GMD/F3, DE backup) 275 180 34.55 0.0 1.0 0.18 dsa_available 220 134 39.09 0.0 65.7 8.54 Internet 188 144 23.40 0.0 6.2 7.25 IXI 191 147 23.04 0.0 24.9 7.78 Int-X.25 NL: Hornero (NL Master) 228 32 85.96 0.1 0.1 0.10 dsa_available 179 24 86.59 2.4 5.2 6.92 '0101'H/X121 228 40 82.46 1.5 100.5 13.24 Internet Agouti (NL Slave) 233 233 0.00 - - - dsa_available 233 233 0.00 - - - Internet AU: Anaconda (AU Master) 230 42 81.74 0.1 0.1 0.10 dsa_available 230 47 79.57 1.8 35.1 11.34 Internet 188 75 60.11 0.0 12.0 12.43 Int-X.25 Bush Dog (master for AU (phony)) 228 70 69.30 0.1 0.1 0.10 dsa_available 228 70 69.30 1.0 18.6 21.18 Internet IL: Dorcan Gazelle (Israel Master) 130 27 79.23 0.1 0.1 0.10 dsa_available 130 27 79.23 4.8 40.0 18.25 Internet AT: Piranah (AT Master) 217 83 61.75 0.0 0.1 0.07 dsa_available 218 94 56.88 0.0 110.0 13.52 Internet 189 124 34.39 0.0 41.2 9.08 Int-X.25 ES: Cayman (Madrid Uni.) 69 27 60.87 0.1 0.1 0.10 dsa_available 69 27 60.87 5.9 134.8 13.96 Int-X.25 69 31 55.07 6.5 223.5 52.68 IXI 69 69 0.00 - - - Internet Iguana (ES Master. Programa IRIS) 290 248 14.48 0.0 1.0 0.13 dsa_available 188 150 20.21 0.0 8.9 28.18 Int-X.25 223 210 5.83 0.0 34.8 14.31 Internet 202 193 4.46 0.0 9.8 13.14 IXI FI: Jaguar (Finland Master) 223 105 52.91 0.1 0.1 0.10 dsa_available 223 109 51.12 2.4 107.0 20.47 Internet 178 120 32.58 0.0 6.6 6.54 '0101'H/X121 IE: Irish Elk (Republic of Ireland Master) 290 167 42.41 0.1 1.0 0.31 dsa_available 221 126 42.99 2.0 107.4 19.50 Internet 203 144 29.06 0.0 10.4 25.58 IXI BE: Woolly Spider Monkey (Belgium Master) 129 129 0.00 - - - dsa_available 129 129 0.00 - - - Internet   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <22620-0@bells.cs.ucl.ac.uk>; Tue, 27 Aug 1991 09:17:15 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Tue, 27 Aug 1991 09:17:13 +0100 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Tue, 27 Aug 1991 09:13:52 +0100 Date: Tue, 27 Aug 1991 10:13:52 +0200 X400-Originator: lanz@ch.ethz.tik.komsys X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910827101352] X400-Content-Type: P2-1984 (2) Content-Identifier: 707 Conversion: Prohibited From: Cuno Lanz Message-ID: <707*/S=lanz/OU=komsys/OU=tik/O=ethz/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: osi-ds , quipu , paradise-partners , dspilot Subject: Swiss master DSA is moving Dear colleagues, In week 36 (2.IX - 6.IX) the Siss master DSA @cn=Chinchilla will be moving! The new host is a SUN 4/490 managed by SWITCH (the Swiss Academic and Research Network). The new presentation addresses will be: presentationAddress= Internet=130.59.1.40+17003 presentationAddress= Int-X25=22847971014540+PID+03018100 presentationAddress= IXI=20432840100540 Responsible for this DSA and the new contact point for c=CH will be: Thomas Lenggenhager SWITCH ETH-Zentrum, HAW CH-8092 Zurich Tel: +41-1-261 8178 Fax: +41-1-261 8133 Mail: C=CH;ADMD=arCom;PRMD=SWITCH;O=SWITCH;OU=verw;S=lenggenhager lenggenhager@verw.switch.ch Problems: C=CH;ADMD=arCom;PRMD=SWITCH;O=SWITCH;OU=verw;S=directory-oper directory-oper@verw.switch.ch Cuno Lanz   Return-Path: Received: from pink.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <13134-0@bells.cs.ucl.ac.uk>; Wed, 28 Aug 1991 09:05:33 +0100 To: osi-ds@uk.ac.ucl.cs Cc: Megan Davies Subject: Draft minutes of Atlanta OSI-DS meeting Phone: +44-71-380-7294 Date: Wed, 28 Aug 91 09:05:32 +0100 Message-ID: <1775.683366732@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Please send comments today or tomorrow (deadline for inclusion in IETF proceedings) Steve Minutes of OSI-DS Working Group meeting in Atlanta, GA 7/29/91 Atlanta, GA Tim Howes + Steve Hardcastle-Kille 1. Attendance List Claudio Allocchio claudio.allocchio@cosine-gw.infn.it William Biagi bbiagi@cos.com Peter Boos peterb@bnr.ca David Brent brent@CDNnet.ca George Brett pls@psulias Ross Callon callon@bigfut.enet.dec.com Vinton Cerf vcerf@nri.reston.va.us Richard Cherry rcherry@novell.com Chi Chu chi@sparta.com Richard Colella colella@osi3.ncsl.nist.gov Curtis Cox ccox@wnyose,nctsw.navy.mil Ralph Droms droms@bucknell.edu Urs Eppenberger eppen@v Arlene Getchell getchell@nersc.gov Jack Hahn hahn@umd5.umd.edu Steve Hardcastle-Kille S.Kille@cs.ucl.ac.uk Susan Hares skh@merit.edu Ittai Hershman ittai@nis.ans.net Russ Hobby rdhobby@ucdavis.edu Steven Hotz hotz@isi.edu Tim Howes tim@d.cc.umich.edu Erik Huizer huizer@surfnet.nl Holly Knight holly@apple.com Mark Knopper mak@merit.edu Christopher Kolb kolb@psi.com Ruth Lang rlang@nisc.sri.com Anthony Lauck lauck@tl.enet.dec.com Louis Leon osll@emuvm1.cc.emory.edu Peter Liebscher plieb@sura.net Carl Malamud carl@malamud.com Bill Manning bmanning@houston.sc.ti.com John McGuthry mcguthry@gateway.mitre.org Joe Peck peck@ms1.pa.dec.com Geir Pedersen geir.pedersen@use.uio.no Mel Pleasant pleasant@hardees.rutgers.edu Marshall Rose Unknown A. Minick Rushton rushton@stsci.edu Harvey Shapiro shapiro@wnyose.nctsw.navy.mil Keld Simonsen keld.simonsen@dkuug.dk Subu Subramanian subu@qsun.att.com Jesse Walker walker@eider.enet@decpa.dec.com Chris Weider clw@merit.edu Brian Wheeler wheeler@mbunix.mitre.org Linda Winkler lwinkler@anl.gov Russ Wright wright@lbl.gov Peter Yee yee@ames.arc.nasa.gov Wengyik Yeong yeongw@psi.com 2. Introduction and Welcome Chair Steve Hardcastle-Kille called the meeting to order after some furniture moving at 9:42am 3. Previous Minutes The minutes from the February meeting at SRI and the May video conference were accepted without change. 4. Liaison Reports 4.1 RARE WG3 (Erik Huizer - RARE) RARE WG3 has had one meeting since the last OSI-DS meeting. Erik reported the following: - PARADISE has now taken over operation of the COSINE X.500 pilot project. - The next RARE WG3 meeting will be in Zurich from 9/30 to 10/2. The meeting will include demos of lots of X.500 DUAs (for Macs, Unix, VMS, etc). Others are encouraged to attend and to contact Erik about bringing a DUA to demo. Erik also mentioned that there is the possibility of making funds available to someone from the US for the trip. 4.2 ISO/CCITT (Steve Hardcastle-Kille in lieu of a representative) There will be one more meeting before the 1992 white book comes out. This meeting will be in Berlin. 4.3 OIW (Russ Wright - LBL) Russ reported that at the OSI Implementors Workshop the following agreements had been reached: - change the maximum APDU size to 256K (up from 30K), - up the 6 line by 30 character postaladdress limit to 6 lines by 60 characters (see mtr's report below). 4.4 NADF (Marshall Rose - unaffiliated) Marshall passed out a revised copy of the US Naming Scheme document now known as NADF 175 and reported the following: - NADF 175 will be submitted as an RFC soon. - NADF naming documents can be obtained from tymer@mcimail.com - The NADF expects to sponsor a pilot to test its agreements sometime in first quarter 1992. - The NADF was not pleased to hear about the OIW agreement about a postaladdress. Apparently, postaladdress limits are determined by a separate international agreement and cannot simply be changed to suit X.500. After some discussion, it was decided that OSI-DS should support the standard (i.e., 6 by 30) definition. 4.5 FOX (Steve Hotz - ISI) Steve reported the following FOX activities: - Approximately 85K NIC WHOIS entries are now online in SRI's DSA. - SRI is also working on a lightweight application to access this information in X.500. - SRI and Merit will work together to provide replication of the WHOIS information. - There are now RFC and FYI document subtrees under o=Internet. - Merit has put a Site Contacts database online under o=Internet, which the NSFNet network operations center is using. - Merit has also begun to put NIC profile information online. 4.6 PSI White Pages (Wengyik Yeong - PSI) Weng reported that the PSI WPP would be focusing on four areas in the near future: - Increasing reliability (through probing, e.g.) - Transition to NADF naming scheme - Transition to the OSI-DS DSA naming scheme - Upgrading all pilot members to ISODE/QUIPU 7.0 4.7 PARADISE (Steve Hardcastle-Kille - UCL) Steve reported that the PARADISE project was doing the following: - Running the world-wide root DSA at ULCC (Giant Tortoise) - Running a DUA service at ULCC for European organizations - Producing a glossy report - Helping other implementations, in particular Pizarro, join the pilot 4.8 AARN (Steve Hardcastle-Kille in lieu of a representative) Steve reported that there is a funded directory service pilot started in the Australian Academic Research Network and that they will be sending a representative to future OSI-DS meetings. Graham Rees at the University of Queensland is the AARN contact person. 4.9 NORDUNET (Geir Pedersen - NORDUNET) Geir reported that a directory services group had been formed to promote directory service in Nordic countries. 4.10 CNI (George Brett - CNI) Coalition for Networked Information: - Members include Association for Research Libraries, CAUSE (administrative computing) and EDUCOM (academic computing). - 7 working groups: commercial publishing, non-commercial publishing, standards and architecture, management and professional education, K-20 education, directories and networked research centers (user services people). - George Brett and Peggy Seiden are involved in the directory working group. They are interestied in a top node or directory of directories, and bibliography of bibliographies. They currently have a flat file, and are now working on an X.500 implementation with Merit. Also looking at a WAIS database. The Merit work involves a schema to represent the library of congress enhanced MARC record. - Documentation on CNI's activities includes an article in Cause & Effect, v14no2, summer 1991. The minutes of their last meeting can be made available to the list by George. There is also a listserv list called cnidir-l. - Art St. George of CNI is interested in K-12 use of networking. 5. Internet Resource Descriptions in X.500 Document (OSI-DS 17) After much discussion, the general consensus on this document was that it needs to be rewritten with a more object-oriented approach. The feeling was that the object class for an Internet Resource should be broken up more in line with the standard's description of auxiliary and structural object classes. 6. Document Progression Vint Cerf reported that all the technical RFCs were close to publication and would be out in "a matter of weeks". Because of the general importance to the Internet community of deploying a Directory Service, the overview and strategy douments should be merged and their scope widened. It was agreed that Steve H-K should revise the document, in association with appropriate IESG and IAB members. Review should be done via email, and that a separate subgroup not be formed. The scope of the WG was also considered, and the group was favourable to moving the activity out of the OSI area and into the Applications area. 7. OID Assignment (OSI-DS 10, RFC 1239) It was decided that the existing OIDs will stay. A small debate followed about whether the current naming authority (under UCL) was ok, or whether it should be changed to the IANA. It was agreed that OIDs are just numbers, so the assignment authority is less important than stability. Currently assigned OIDs should not be adjusted. This had already been agreed between Steve H-K and Jon Postel. New OIDs would probably be assigned under an IANA subtree, subject to concensus with non-Interent users of this schema. It was agred that this document could and should progress rapidly to RFC. 8. Requirements Specification Document (OSI-DS 18) This document had been drafted after an agreemnt at the videoconference. After some discussion, it was agreed that a document of this nature would be important in the future, but was premature. It should be put on ice for now. 9. More Resources Description Document Discussion Mark Knopper of Merit said he was interested in putting NSAPs in the DIT and doing reverse lookups. Along with Chris Weider, he volunteered to write something up by mid-September on how to do this. 10. NIC Profile Information Document (OSI-DS 16) After some discussion, it was agreed that Chris Weider should rewrite this document along the same object-oriented lines as discussed previously. There was also some discussion about how this information should be organized in the DIT, since some NICs are real organizations, others aren't, some are listed in other parts of the tree, others aren't. Steve H-K drew a diagram describing a structure that could accomodate both situations, and it was generally approved. 11. K-12 Schema Document It was agreed that this document suffered from the same object-oriented concerns as the others and should be rewritten. Also, it was decided that a companion document addressing DIT structure for these objects should be produced. Chris Weider and Mark Knopper were elected for both tasks. 12. Network Infrastructure Information in X.500 This document is already being rewritten and was not discussed. 13. Pictures in the Directory Russ Wright presented a brief overview of the problem (summary: the g3fax format is bad), and a potential new format that is better (JPEG). It was agreed that JPEG is a step forward, but more study is needed on the transition path, potential size limits, etc. Russ Wright, Peter Yee, Tim Howes, and Mark Smith (in absentia) volunteered to look into these issues. 14. Quality of Service (OSI-DS 15) The QOS definitions were generally accepted, and the next step is to start making use of these attributes now that the syntax handlers are available in QUIPU 7.0. Russ Wright, Erik Huizer, and Tim Howes volunteered to try incorporating QOS into some DUAs to gain some experience with its use. All of the represented pilots agreed to install the appropriate attributes into their DITs. Both efforts were needed to make an effective test of the I-D. The I-D should not be submitted as an RFC until results of this piloting, and probable modifications to the I-D, had been done. 15. NADF Naming Document NADF 175 is now considered Stable and a Good Thing by NADF, and will be released as an RFC Real Soon Now. 16. Naming Guidelines Document (OSI-DS 12) After some discussion about multi-national organization naming, it was agreed that this document should be progressed to RFC status pending ironing out of some minor issues which will be done via email. 17. AOB Erik Huizer made a request for someone from the US to look into issues involving security/privacy laws in the US that might relate to X.500. This is something that has come up several times in Europe. 18. Next meeting Steve would like to have the next OSI-DS meeting around Interop. 19. Summary of Action Items - George Brett: Find out how to get CNI documents and send this information to the osi-ds list - Mark Knopper, Chris Weider: Write a paper describing how to store NSAP information in the DIT (mid-september) - Chris Weider: Rewrite Resource Description paper - Chris Weider: Rewrite NIC Profile paper - Mark Knopper, Chris Weider: Rewrite K-12 Schema paper - Mark Knopper, Chris Weider: Write a companion paper to the K-12 Schema paper describing the suggested DIT structure - Russ Wright, Peter Yee, Tim Howes: Experiment with JPEG photos in the Directory - Russ Wright, Erik Huizer, Tim Howes, others: Incorporate QOS into DUAs and pilot exerices - Steve Hardcastle-Kille/Paul Barker: Initiate an email discussion on the Naming Guidelines document and progress it to an RFC when all concerns have been addressed - Steve Hardcastle-Kille: Schedule the next OSI-DS meeting at or around Interop - Steve Hardcastle-Kille: Produce new strategy/overview document   Return-Path: Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <15256-0@bells.cs.ucl.ac.uk>; Wed, 28 Aug 1991 12:42:14 +0100 To: Olivier Dubois cc: osi-ds@uk.ac.ucl.cs Subject: Re: interim approach to Network Addresses Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 20 Aug 91 17:22:51 +0200. <9108201522.AA08851@corea.sunbim.uucp> Date: Wed, 28 Aug 91 12:42:11 +0100 Message-ID: <15254.683379731@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Thanks for your comments. I think that the TCP/IP and X.25 allocation is consistent. The DSP description is given as a prefix/network specific part. Then the network specifci part is defined for each format. The examples are of "whole" addresses, and include the prefix. The IDP AFI is always telex. I will add a short note about choosing the IDI, which essentially says "use an appropriate telex number". Steve >From: Olivier Dubois >To: osi-ds@uk.ac.ucl.cs >Subject: interim approach to Network Addresses >Date: Tue, 20 Aug 91 17:22:51 +0200 >Hello, >I just read the document dated January 1991 from a copy I get testing ftam with the ucl responder. >Although I appreciated it very much I have a comment to make: >The graph showing the DSP encoding part, the core of the document in fact, are not very easy to figure and to understand. There is more, it seems to me thaht it is inconsistant that for X.25, the DSP prefix is included in the encoding while for RFC-1006 e >ncoding, it appears only in the example. >I don't know if the document already achieve an RFC status but it seems to me that a small modification there would improve it. >Another comment I would like to make is that at least a small paragraph should be devoted to describing the IDP part of the proposed encoding, particularly, the IDI allocation (I know there is no perfect allocation of value to this field, but for complete >ness, this should be noticed). >These comments are not to be taken to seriously, they are just some remark made by someone who would like to avoid other the problem its > small mental capabilities cause him. >Olivier Dubois.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17048-0@bells.cs.ucl.ac.uk>; Wed, 28 Aug 1991 13:47:28 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Revised documents Phone: +44-71-380-7294 Date: Wed, 28 Aug 91 13:47:28 +0100 Message-ID: <2076.683383648@UK.AC.UCL.CS> From: Steve Hardcastle-Kille The following documents have been revised. They are available from the UCL archive, or will be available as Internet Drafts shortly. Interim Network Address Format - minor clarification, as noted in recent message Replication Requirements -edit not to reference interent drafts (so it can be submitted as RFC) Replication and Distributed Operation extensions - edit not to reference internet drafts - minor clarification QOS - semantic change (preseving syntax) agreed at meeting Steve   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <23715-0@bells.cs.ucl.ac.uk>; Wed, 28 Aug 1991 17:26:12 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA13400; Wed, 28 Aug 91 18:23:25 +0200 Message-Id: <9108281623.AA13400@mitsou.inria.fr> To: osi-ds Cc: osi-ds@uk.ac.ucl.cs, Steve Titcombe Subject: Re: DSA Probe Statistics For Root DSAs In-Reply-To: Your message of 23 Aug 91 09:48:12 +0100. <"6322 Fri Aug 23 09:48:57 1991"@cs.ucl.ac.uk> Date: Wed, 28 Aug 91 18:23:04 BST From: Christian Huitema Steve, I am surprised to find out that you have not yet managed to find a way to include the French DSA in your statistics. The fact that its name contains more than one part is a poor excuse; your tool should be able to use a list of DSA names, regardless of their place in the tree. Christian Huitema   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4499-0@bells.cs.ucl.ac.uk>; Mon, 2 Sep 1991 10:04:42 +0100 To: Megan Davies cc: osi-ds@uk.ac.ucl.cs Subject: Revised minutes of Atlanta Meeting Phone: +44-71-380-7294 Date: Mon, 02 Sep 91 10:04:40 +0100 Message-ID: <561.683802280@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Minutes of OSI-DS Working Group meeting in Atlanta, GA 7/29/91 Atlanta, GA Tim Howes + Steve Hardcastle-Kille 1. Attendance List Claudio Allocchio claudio.allocchio@cosine-gw.infn.it William Biagi bbiagi@cos.com Peter Boos peterb@bnr.ca David Brent brent@CDNnet.ca George Brett pls@psulias Ross Callon callon@bigfut.enet.dec.com Vinton Cerf vcerf@nri.reston.va.us Richard Cherry rcherry@novell.com Chi Chu chi@sparta.com Richard Colella colella@osi3.ncsl.nist.gov Curtis Cox ccox@wnyose,nctsw.navy.mil Ralph Droms droms@bucknell.edu Urs Eppenberger eppen@v Arlene Getchell getchell@nersc.gov Jack Hahn hahn@umd5.umd.edu Steve Hardcastle-Kille S.Kille@cs.ucl.ac.uk Susan Hares skh@merit.edu Ittai Hershman ittai@nis.ans.net Russ Hobby rdhobby@ucdavis.edu Steven Hotz hotz@isi.edu Tim Howes tim@d.cc.umich.edu Erik Huizer huizer@surfnet.nl Holly Knight holly@apple.com Mark Knopper mak@merit.edu Christopher Kolb kolb@psi.com Ruth Lang rlang@nisc.sri.com Anthony Lauck lauck@tl.enet.dec.com Louis Leon osll@emuvm1.cc.emory.edu Peter Liebscher plieb@sura.net Carl Malamud carl@malamud.com Bill Manning bmanning@houston.sc.ti.com John McGuthry mcguthry@gateway.mitre.org Joe Peck peck@ms1.pa.dec.com Geir Pedersen geir.pedersen@use.uio.no Mel Pleasant pleasant@hardees.rutgers.edu Marshall Rose Unknown A. Minick Rushton rushton@stsci.edu Harvey Shapiro shapiro@wnyose.nctsw.navy.mil Keld Simonsen keld.simonsen@dkuug.dk Subu Subramanian subu@qsun.att.com Jesse Walker walker@eider.enet@decpa.dec.com Chris Weider clw@merit.edu Brian Wheeler wheeler@mbunix.mitre.org Linda Winkler lwinkler@anl.gov Russ Wright wright@lbl.gov Peter Yee yee@ames.arc.nasa.gov Wengyik Yeong yeongw@psi.com 2. Introduction and Welcome Chair Steve Hardcastle-Kille called the meeting to order after some furniture moving at 9:42am 3. Previous Minutes The minutes from the February meeting at SRI and the May video conference were accepted without change. 4. Liaison Reports 4.1 RARE WG3 (Erik Huizer - RARE) RARE WG3 has had one meeting since the last OSI-DS meeting. Erik reported the following: - PARADISE has now taken over operation of the COSINE X.500 pilot project. - The next RARE WG3 meeting will be in Zurich from 9/30 to 10/2. The meeting will include demos of lots of X.500 DUAs (for Macs, Unix, VMS, etc). Others are encouraged to attend and to contact Erik about bringing a DUA to demo. Erik also mentioned that there is the possibility of making funds available to someone from the US for the trip. 4.2 ISO/CCITT (Steve Hardcastle-Kille in lieu of a representative) There will be one more meeting before the 1992 white book comes out. This meeting will be in Berlin. 4.3 OIW (Russ Wright - LBL) Russ reported that at the OSI Implementors Workshop the following agreements had been reached: - change the maximum APDU size to 256K (up from 32K), - up the 6 line by 30 character postaladdress limit to 6 lines by 60 characters (see mtr's report below). 4.4 NADF (Marshall Rose - unaffiliated) Marshall passed out a revised copy of the US Naming Scheme document now known as NADF 175 and reported the following: - NADF 175 will be submitted as an RFC soon. - NADF naming documents can be obtained from tymer@mcimail.com - The NADF expects to sponsor a pilot to test its agreements sometime in first quarter 1992. - The NADF was not pleased to hear about the OIW agreement about a postaladdress. Apparently, postaladdress limits are determined by a separate international agreement and cannot simply be changed to suit X.500. After some discussion, it was decided that OSI-DS should support the standard (i.e., 6 by 30) definition. 4.5 FOX (Steve Hotz - ISI) Steve reported the following FOX activities: - Approximately 85K NIC WHOIS entries are now online in SRI's DSA. - SRI is also working on a lightweight application to access this information in X.500. - SRI and Merit will work together to provide replication of the WHOIS information. - There are now RFC and FYI document subtrees under o=Internet. - Merit has put a Site Contacts database online under o=Internet, which the NSFNet network operations center is using. - Merit has also begun to put NIC profile information online. 4.6 PSI White Pages (Wengyik Yeong - PSI) Weng reported that the PSI WPP would be focusing on four areas in the near future: - Increasing reliability (through probing, e.g.) - Transition to NADF naming scheme - Transition to the OSI-DS DSA naming scheme - Upgrading all pilot members to ISODE/QUIPU 7.0 4.7 PARADISE (Steve Hardcastle-Kille - UCL) Steve reported that the PARADISE project was doing the following: - Running the world-wide root DSA at ULCC (Giant Tortoise) - Running a DUA service at ULCC for European organizations - Producing a glossy report - Helping other implementations, in particular Pizarro, join the pilot 4.8 AARN (Steve Hardcastle-Kille in lieu of a representative) Steve reported that there is a funded directory service pilot started in the Australian Academic Research Network and that they will be sending a representative to future OSI-DS meetings. Graham Rees at the University of Queensland is the AARN contact person. 4.9 NORDUNET (Geir Pedersen - NORDUNET) Geir reported that a directory services group is operating within NORDUNET. The group focuses on promotion of the directory within the Nordic countries. 4.10 CNI (George Brett - CNI) Coalition for Networked Information: - Members include Association for Research Libraries, CAUSE (administrative computing) and EDUCOM (academic computing). - 7 working groups: commercial publishing, non-commercial publishing, standards and architecture, management and professional education, K-20 education, directories and networked research centers (user services people). - George Brett and Peggy Seiden are involved in the directory working group. They are interestied in a top node or directory of directories, and bibliography of bibliographies. They currently have a flat file, and are now working on an X.500 implementation with Merit. Also looking at a WAIS database. The Merit work involves a schema to represent the library of congress enhanced MARC record. - Documentation on CNI's activities includes an article in Cause & Effect, v14no2, summer 1991. The minutes of their last meeting can be made available to the list by George. There is also a listserv list called cnidir-l. - Art St. George of CNI is interested in K-12 use of networking. 5. Internet Resource Descriptions in X.500 Document (OSI-DS 17) After much discussion, the general consensus on this document was that it needs to be rewritten with a more object-oriented approach. The feeling was that the object class for an Internet Resource should be broken up more in line with the standard's description of auxiliary and structural object classes. 6. Document Progression Vint Cerf reported that all the technical RFCs were close to publication and would be out in "a matter of weeks". Because of the general importance to the Internet community of deploying a Directory Service, the overview and strategy douments should be merged and their scope widened. It was agreed that Steve H-K should revise the document, in association with appropriate IESG and IAB members. Review should be done via email, and that a separate subgroup not be formed. The scope of the WG was also considered, and the group was favourable to moving the activity out of the OSI area and into the Applications area. 7. OID Assignment (OSI-DS 10, RFC 1239) It was decided that the existing OIDs will stay. A small debate followed about whether the current naming authority (under UCL) was ok, or whether it should be changed to the IANA. It was agreed that OIDs are just numbers, so the assignment authority is less important than stability. Currently assigned OIDs should not be adjusted. This had already been agreed between Steve H-K and Jon Postel. New OIDs would probably be assigned under an IANA subtree, subject to concensus with non-Interent users of this schema. It was agred that this document could and should progress rapidly to RFC. 8. Requirements Specification Document (OSI-DS 18) This document had been drafted after an agreemnt at the videoconference. After some discussion, it was agreed that a document of this nature would be important in the future, but was premature. It should be put on ice for now. 9. More Resources Description Document Discussion Mark Knopper of Merit said he was interested in putting NSAPs in the DIT and doing reverse lookups. Along with Chris Weider, he volunteered to write something up by mid-September on how to do this. 10. NIC Profile Information Document (OSI-DS 16) After some discussion, it was agreed that Chris Weider should rewrite this document along the same object-oriented lines as discussed previously. There was also some discussion about how this information should be organized in the DIT, since some NICs are real organizations, others aren't, some are listed in other parts of the tree, others aren't. Steve H-K drew a diagram describing a structure that could accomodate both situations, and it was generally approved. 11. K-12 Schema Document It was agreed that this document suffered from the same object-oriented concerns as the others and should be rewritten. Also, it was decided that a companion document addressing DIT structure for these objects should be produced. Chris Weider and Mark Knopper were elected for both tasks. 12. Network Infrastructure Information in X.500 This document is already being rewritten and was not discussed. 13. Pictures in the Directory Russ Wright presented a brief overview of the problem (summary: the g3fax format is bad), and a potential new format that is better (JPEG). It was agreed that JPEG is a step forward, but more study is needed on the transition path, potential size limits, etc. Russ Wright, Peter Yee, Tim Howes, and Mark Smith (in absentia) volunteered to look into these issues. 14. Quality of Service (OSI-DS 15) The QOS definitions were generally accepted, and the next step is to start making use of these attributes now that the syntax handlers are available in QUIPU 7.0. Russ Wright, Erik Huizer, and Tim Howes volunteered to try incorporating QOS into some DUAs to gain some experience with its use. All of the represented pilots agreed to install the appropriate attributes into their DITs. Both efforts were needed to make an effective test of the I-D. The I-D should not be submitted as an RFC until results of this piloting, and probable modifications to the I-D, had been done. 15. NADF Naming Document NADF 175 is now considered Stable and a Good Thing by NADF, and will be released as an RFC Real Soon Now. 16. Naming Guidelines Document (OSI-DS 12) After some discussion about multi-national organization naming, it was agreed that this document should be progressed to RFC status pending ironing out of some minor issues which will be done via email. 17. AOB Erik Huizer made a request for someone from the US to look into issues involving security/privacy laws in the US that might relate to X.500. This is something that has come up several times in Europe. 18. Next meeting Steve would like to have the next OSI-DS meeting around Interop. 19. Summary of Action Items - George Brett: Find out how to get CNI documents and send this information to the osi-ds list - Mark Knopper, Chris Weider: Write a paper describing how to store NSAP information in the DIT (mid-september) - Chris Weider: Rewrite Resource Description paper - Chris Weider: Rewrite NIC Profile paper - Mark Knopper, Chris Weider: Rewrite K-12 Schema paper - Mark Knopper, Chris Weider: Write a companion paper to the K-12 Schema paper describing the suggested DIT structure - Russ Wright, Peter Yee, Tim Howes: Experiment with JPEG photos in the Directory - Russ Wright, Erik Huizer, Tim Howes, others: Incorporate QOS into DUAs and pilot exerices - Steve Hardcastle-Kille/Paul Barker: Initiate an email discussion on the Naming Guidelines document and progress it to an RFC when all concerns have been addressed - Steve Hardcastle-Kille: Schedule the next OSI-DS meeting at or around Interop - Steve Hardcastle-Kille: Produce new strategy/overview document   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <4499-0@bells.cs.ucl.ac.uk>; Mon, 2 Sep 1991 10:04:42 +0100 To: Megan Davies cc: osi-ds@uk.ac.ucl.cs Subject: Revised minutes of Atlanta Meeting Phone: +44-71-380-7294 Date: Mon, 02 Sep 91 10:04:40 +0100 Message-ID: <561.683802280@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Minutes of OSI-DS Working Group meeting in Atlanta, GA 7/29/91 Atlanta, GA Tim Howes + Steve Hardcastle-Kille 1. Attendance List Claudio Allocchio claudio.allocchio@cosine-gw.infn.it William Biagi bbiagi@cos.com Peter Boos peterb@bnr.ca David Brent brent@CDNnet.ca George Brett pls@psulias Ross Callon callon@bigfut.enet.dec.com Vinton Cerf vcerf@nri.reston.va.us Richard Cherry rcherry@novell.com Chi Chu chi@sparta.com Richard Colella colella@osi3.ncsl.nist.gov Curtis Cox ccox@wnyose,nctsw.navy.mil Ralph Droms droms@bucknell.edu Urs Eppenberger eppen@v Arlene Getchell getchell@nersc.gov Jack Hahn hahn@umd5.umd.edu Steve Hardcastle-Kille S.Kille@cs.ucl.ac.uk Susan Hares skh@merit.edu Ittai Hershman ittai@nis.ans.net Russ Hobby rdhobby@ucdavis.edu Steven Hotz hotz@isi.edu Tim Howes tim@d.cc.umich.edu Erik Huizer huizer@surfnet.nl Holly Knight holly@apple.com Mark Knopper mak@merit.edu Christopher Kolb kolb@psi.com Ruth Lang rlang@nisc.sri.com Anthony Lauck lauck@tl.enet.dec.com Louis Leon osll@emuvm1.cc.emory.edu Peter Liebscher plieb@sura.net Carl Malamud carl@malamud.com Bill Manning bmanning@houston.sc.ti.com John McGuthry mcguthry@gateway.mitre.org Joe Peck peck@ms1.pa.dec.com Geir Pedersen geir.pedersen@use.uio.no Mel Pleasant pleasant@hardees.rutgers.edu Marshall Rose Unknown A. Minick Rushton rushton@stsci.edu Harvey Shapiro shapiro@wnyose.nctsw.navy.mil Keld Simonsen keld.simonsen@dkuug.dk Subu Subramanian subu@qsun.att.com Jesse Walker walker@eider.enet@decpa.dec.com Chris Weider clw@merit.edu Brian Wheeler wheeler@mbunix.mitre.org Linda Winkler lwinkler@anl.gov Russ Wright wright@lbl.gov Peter Yee yee@ames.arc.nasa.gov Wengyik Yeong yeongw@psi.com 2. Introduction and Welcome Chair Steve Hardcastle-Kille called the meeting to order after some furniture moving at 9:42am 3. Previous Minutes The minutes from the February meeting at SRI and the May video conference were accepted without change. 4. Liaison Reports 4.1 RARE WG3 (Erik Huizer - RARE) RARE WG3 has had one meeting since the last OSI-DS meeting. Erik reported the following: - PARADISE has now taken over operation of the COSINE X.500 pilot project. - The next RARE WG3 meeting will be in Zurich from 9/30 to 10/2. The meeting will include demos of lots of X.500 DUAs (for Macs, Unix, VMS, etc). Others are encouraged to attend and to contact Erik about bringing a DUA to demo. Erik also mentioned that there is the possibility of making funds available to someone from the US for the trip. 4.2 ISO/CCITT (Steve Hardcastle-Kille in lieu of a representative) There will be one more meeting before the 1992 white book comes out. This meeting will be in Berlin. 4.3 OIW (Russ Wright - LBL) Russ reported that at the OSI Implementors Workshop the following agreements had been reached: - change the maximum APDU size to 256K (up from 32K), - up the 6 line by 30 character postaladdress limit to 6 lines by 60 characters (see mtr's report below). 4.4 NADF (Marshall Rose - unaffiliated) Marshall passed out a revised copy of the US Naming Scheme document now known as NADF 175 and reported the following: - NADF 175 will be submitted as an RFC soon. - NADF naming documents can be obtained from tymer@mcimail.com - The NADF expects to sponsor a pilot to test its agreements sometime in first quarter 1992. - The NADF was not pleased to hear about the OIW agreement about a postaladdress. Apparently, postaladdress limits are determined by a separate international agreement and cannot simply be changed to suit X.500. After some discussion, it was decided that OSI-DS should support the standard (i.e., 6 by 30) definition. 4.5 FOX (Steve Hotz - ISI) Steve reported the following FOX activities: - Approximately 85K NIC WHOIS entries are now online in SRI's DSA. - SRI is also working on a lightweight application to access this information in X.500. - SRI and Merit will work together to provide replication of the WHOIS information. - There are now RFC and FYI document subtrees under o=Internet. - Merit has put a Site Contacts database online under o=Internet, which the NSFNet network operations center is using. - Merit has also begun to put NIC profile information online. 4.6 PSI White Pages (Wengyik Yeong - PSI) Weng reported that the PSI WPP would be focusing on four areas in the near future: - Increasing reliability (through probing, e.g.) - Transition to NADF naming scheme - Transition to the OSI-DS DSA naming scheme - Upgrading all pilot members to ISODE/QUIPU 7.0 4.7 PARADISE (Steve Hardcastle-Kille - UCL) Steve reported that the PARADISE project was doing the following: - Running the world-wide root DSA at ULCC (Giant Tortoise) - Running a DUA service at ULCC for European organizations - Producing a glossy report - Helping other implementations, in particular Pizarro, join the pilot 4.8 AARN (Steve Hardcastle-Kille in lieu of a representative) Steve reported that there is a funded directory service pilot started in the Australian Academic Research Network and that they will be sending a representative to future OSI-DS meetings. Graham Rees at the University of Queensland is the AARN contact person. 4.9 NORDUNET (Geir Pedersen - NORDUNET) Geir reported that a directory services group is operating within NORDUNET. The group focuses on promotion of the directory within the Nordic countries. 4.10 CNI (George Brett - CNI) Coalition for Networked Information: - Members include Association for Research Libraries, CAUSE (administrative computing) and EDUCOM (academic computing). - 7 working groups: commercial publishing, non-commercial publishing, standards and architecture, management and professional education, K-20 education, directories and networked research centers (user services people). - George Brett and Peggy Seiden are involved in the directory working group. They are interestied in a top node or directory of directories, and bibliography of bibliographies. They currently have a flat file, and are now working on an X.500 implementation with Merit. Also looking at a WAIS database. The Merit work involves a schema to represent the library of congress enhanced MARC record. - Documentation on CNI's activities includes an article in Cause & Effect, v14no2, summer 1991. The minutes of their last meeting can be made available to the list by George. There is also a listserv list called cnidir-l. - Art St. George of CNI is interested in K-12 use of networking. 5. Internet Resource Descriptions in X.500 Document (OSI-DS 17) After much discussion, the general consensus on this document was that it needs to be rewritten with a more object-oriented approach. The feeling was that the object class for an Internet Resource should be broken up more in line with the standard's description of auxiliary and structural object classes. 6. Document Progression Vint Cerf reported that all the technical RFCs were close to publication and would be out in "a matter of weeks". Because of the general importance to the Internet community of deploying a Directory Service, the overview and strategy douments should be merged and their scope widened. It was agreed that Steve H-K should revise the document, in association with appropriate IESG and IAB members. Review should be done via email, and that a separate subgroup not be formed. The scope of the WG was also considered, and the group was favourable to moving the activity out of the OSI area and into the Applications area. 7. OID Assignment (OSI-DS 10, RFC 1239) It was decided that the existing OIDs will stay. A small debate followed about whether the current naming authority (under UCL) was ok, or whether it should be changed to the IANA. It was agreed that OIDs are just numbers, so the assignment authority is less important than stability. Currently assigned OIDs should not be adjusted. This had already been agreed between Steve H-K and Jon Postel. New OIDs would probably be assigned under an IANA subtree, subject to concensus with non-Interent users of this schema. It was agred that this document could and should progress rapidly to RFC. 8. Requirements Specification Document (OSI-DS 18) This document had been drafted after an agreemnt at the videoconference. After some discussion, it was agreed that a document of this nature would be important in the future, but was premature. It should be put on ice for now. 9. More Resources Description Document Discussion Mark Knopper of Merit said he was interested in putting NSAPs in the DIT and doing reverse lookups. Along with Chris Weider, he volunteered to write something up by mid-September on how to do this. 10. NIC Profile Information Document (OSI-DS 16) After some discussion, it was agreed that Chris Weider should rewrite this document along the same object-oriented lines as discussed previously. There was also some discussion about how this information should be organized in the DIT, since some NICs are real organizations, others aren't, some are listed in other parts of the tree, others aren't. Steve H-K drew a diagram describing a structure that could accomodate both situations, and it was generally approved. 11. K-12 Schema Document It was agreed that this document suffered from the same object-oriented concerns as the others and should be rewritten. Also, it was decided that a companion document addressing DIT structure for these objects should be produced. Chris Weider and Mark Knopper were elected for both tasks. 12. Network Infrastructure Information in X.500 This document is already being rewritten and was not discussed. 13. Pictures in the Directory Russ Wright presented a brief overview of the problem (summary: the g3fax format is bad), and a potential new format that is better (JPEG). It was agreed that JPEG is a step forward, but more study is needed on the transition path, potential size limits, etc. Russ Wright, Peter Yee, Tim Howes, and Mark Smith (in absentia) volunteered to look into these issues. 14. Quality of Service (OSI-DS 15) The QOS definitions were generally accepted, and the next step is to start making use of these attributes now that the syntax handlers are available in QUIPU 7.0. Russ Wright, Erik Huizer, and Tim Howes volunteered to try incorporating QOS into some DUAs to gain some experience with its use. All of the represented pilots agreed to install the appropriate attributes into their DITs. Both efforts were needed to make an effective test of the I-D. The I-D should not be submitted as an RFC until results of this piloting, and probable modifications to the I-D, had been done. 15. NADF Naming Document NADF 175 is now considered Stable and a Good Thing by NADF, and will be released as an RFC Real Soon Now. 16. Naming Guidelines Document (OSI-DS 12) After some discussion about multi-national organization naming, it was agreed that this document should be progressed to RFC status pending ironing out of some minor issues which will be done via email. 17. AOB Erik Huizer made a request for someone from the US to look into issues involving security/privacy laws in the US that might relate to X.500. This is something that has come up several times in Europe. 18. Next meeting Steve would like to have the next OSI-DS meeting around Interop. 19. Summary of Action Items - George Brett: Find out how to get CNI documents and send this information to the osi-ds list - Mark Knopper, Chris Weider: Write a paper describing how to store NSAP information in the DIT (mid-september) - Chris Weider: Rewrite Resource Description paper - Chris Weider: Rewrite NIC Profile paper - Mark Knopper, Chris Weider: Rewrite K-12 Schema paper - Mark Knopper, Chris Weider: Write a companion paper to the K-12 Schema paper describing the suggested DIT structure - Russ Wright, Peter Yee, Tim Howes: Experiment with JPEG photos in the Directory - Russ Wright, Erik Huizer, Tim Howes, others: Incorporate QOS into DUAs and pilot exerices - Steve Hardcastle-Kille/Paul Barker: Initiate an email discussion on the Naming Guidelines document and progress it to an RFC when all concerns have been addressed - Steve Hardcastle-Kille: Schedule the next OSI-DS meeting at or around Interop - Steve Hardcastle-Kille: Produce new strategy/overview document   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9975-0@bells.cs.ucl.ac.uk>; Mon, 2 Sep 1991 13:09:05 +0100 To: mak@edu.merit cc: osi-ds@uk.ac.ucl.cs, skh@edu.merit Subject: Re: Quipu vs. X.500 Phone: +44-71-380-7294 In-reply-to: Your message of Thu, 22 Aug 91 20:43:04 -0400. <9108230043.AA08978@home.merit.edu> Date: Mon, 02 Sep 91 13:09:06 +0100 Message-ID: <2402.683813346@UK.AC.UCL.CS> From: Steve Hardcastle-Kille To points: 1) QUIPU will talk standard X.500. Thus any conformant system will be able to interwork with QUIPU without any modifications. So, to demonstrate interoperability with QUIPU, nothing needs to be done. 2) Work with QUIPU (and other systems) identified a number of areas which needed to be addresses before an effective pilot service could be deployed on the Internet. These issues are addressed in the series of RFCs produced by the OSI-DS WG. To demonstrate interoperability with the global directory pilot, the OSI-DS I-Ds should be followed. For a DUA, this should simply mean adding in support for a number of attribute types and object classes. Steve >From: mak@edu.merit >To: osi-ds@uk.ac.ucl.cs, skh@edu.merit >Subject: Quipu vs. X.500 >Date: Thu, 22 Aug 91 20:43:04 EDT >Hi. If you were a vendor and had implemented from the X.500 recommendations, >and then you wanted to add functionality to interoperate with quipu, >what would you add? I know that replication is needed because quipu >requires replicating the top level EDB. In this case I'm interested >in operating over a pure OSI TP4/CLNP stack. > Mark >ps. This info will be very useful to the vendors that will demonstrate >X.500 at Interop 91.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <10089-0@bells.cs.ucl.ac.uk>; Mon, 2 Sep 1991 13:17:47 +0100 To: osi-ds@uk.ac.ucl.cs Subject: OSI-DS meeting at Interop Phone: +44-71-380-7294 Date: Mon, 02 Sep 91 13:17:44 +0100 Message-ID: <2444.683813864@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I propose to hold this meeting on Tuesday 8th October, and to take a full day. I will try to structure the Agenda, so that half day attendance will make sense. I have asked Interop for a room, but have not received a reply (I suspect that they are despararely busy). I think that it is not safe to rely on an Interop room. So, could I ask for offers of accomodation for this meeting? Ideally from a group towards the south end of the bay. thanks Steve   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <11765-0@bells.cs.ucl.ac.uk>; Mon, 2 Sep 1991 14:39:41 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 2 Sep 1991 14:40:08 +0100 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Mon, 2 Sep 1991 14:40:06 +0100 Date: Mon, 2 Sep 1991 15:40:06 +0200 X400-Originator: Lenggenhager@ch.switch.gate X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910902154006] X400-Content-Type: P2-1984 (2) Content-Identifier: 6157 Priority: Urgent From: Thomas Lenggenhager Message-ID: <6157*/S=Lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: Do you come to RARE WG3 in Zurich (30.9.-2.10) ? Importance: High Erik asked you to send me mail when you plan to attend the meeting. From some of you I got a message, but others who will attend for sure haven't sent one yet. Could you please check the following list, whether you are already listed there when you plan to attend the RARE WG3 meeting in Zurich. If you attend only Tuesday or Wednesday but plan to come to the common dinner, please let me know it too, so we can reserve the necessary tables. On Monday we will leave for dinner on 19.00 hours, on Tuesday on 20.00 hours. 30.9. 1.10. 2.10. ----------------------------------------------------------------------------- Marko Bonac YUNAC YU x x x Ulrike Dillmann BELWue DE x x Dominique Dumas EARN France FR x x Peter Flynn HEANET IE x x x Gerti Foest DFN DE x x Jill Foster NISP UK x x x Peter Gloor Univ St. Gallen CH x Lisa Golka BELWue DE x x Roland Hedberg SUNET SE x x x Erik Huizer SURFnet NL x x x Cuno Lanz ETH Zurich CH x x Thomas Lenggenhager SWITCH CH x x x Steen Linden Univ Copenhagen DK x x Nils Meulemans Univ Brussels BE x x x Bernd Rieger DFN DE x x Florian Schnabel ACONET AT x x x Heinrich Schneeberger PTT CH x x Thomas Schoenenberger Univ St. Gallen CH x Jean-Marc Verbergt Univ Brussels BE x x x Marcel Wiget SWITCH CH x Shirley Wood JANET UK x x x I haven't got a message (or I lost it?) from the following persons who attended recent meetings or are expected to give a presentation. --> Please confirm the dates of your attendence 30.9. 1.10. 2.10. ----------------------------------------------------------------------------- Paul Barker UCL UK x Steve Benford Nottingham Univ UK x Tim Berners-Lee CERN CH x Yannis Corovesis NRC Demokritos GR Jim Craigie JNT UK Christopher Duxbury CPMU BE Andrew Findlay Brunel Univ UK x Anders Gilner SUNET SE David Goodman UCL UK Steve Hardcastle-Kille UCL UK Maria Heijne SURFnet NL Graham Knight Level-7 UK Jean-Paul LeGuigner CICB FR Ignacio Martinez IRIS ES Tim Maude Level-7 UK Ignacio de los Mozos IRIS ES Joao Neves INESC PT Gardar Nielsen Univ Iceland IS Donal O'Mahony HEANET IE Petri Ojala FUNET FI Pascal Paridans Univ Brussels BE Paul-Andre Pays OPAX FR Geir Pedersen UNINETT NO Joyce Reynolds US Colin Robins Xtel UK x Celestino Tomas RedIRIS/FUNDESCO ES Maria Zacharova-Dimou CERN CH For the late ones of you, who didn't book a hotel yet, I include that information at the end. Good luck in finding a room! Shortly before the meeting I will send around the information on how to get from the airport into the city and to the meeting room. (It takes only about 30 to 45 minutes to get from the airport to the meeting room and the hotels are nearby.) Thomas Lenggenhager SWITCH =============================================================================== Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerland INET: lenggenhager@switch.ch | Tel: +41-1-261 8178 | Fax: +41-1-261 8133 X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH ___________________________________________________________________________ Program RARE WG3 meeting 30 sept.-2 oct. 1991 Zurich, Switzerland Zurich, SWITCH/ETH Zurich 30 september 1300 RARE WG3:Directory Service (DS) session COSINE P2.1 (PARADISE) Operational meeting 1800 closing 1 october Open sessions and presentations Big room Terminal room Lecture room with video no facilities ------------------------------------------------------ 0900 Paul Barker (UCL/Paradise) Paradise Central DUA 0945 Someone from the US(?) Mac DUA or FOX/WPP status 1030 break 1100 Andrew Findlay (Brunell) Brunell (X)DUA 1145 Graham Knight (Level-7 Ltd) P2.2 Prototype 1300 Lunch PARALLEL SESSIONS: 1400 Tim Berners-Lee (CERN) Colin Robbins (Xtel) Hypertext Tutorial DSA 1500 Steve Benford (Nottingham Univ.) continued Group Communications 1600 RARE WG 3 Plenary (Directory Service and User Support & Information Services) 1700 Drinks Various demo's The various demos would consist of: ETHZ ITAXA DUA for Mac Steve benford Group Communication PSI (?) Mac DUA Tim Howes (?) Mac DUA Brunel DUA's Paul Barker DUA Level-7 P2.2 Celestino Tomas VMS DUA X-tel DUAs Tim Berners-Lee Hypertext next Maria Dimou CERN Directory Joyce Reynolds (?) 2 october 0900 RARE WG3:User Support & Information Services (USIS) part (maybe parallel some DS demo evaluations in the terminal room) 1600 COSINE P2.2 (CONCISE) meeting 1800 end of meeting ___________________________________________________________________________ ----------------------- Zurich Hotel Information ------------------------- For some of you coming from further away, it could be probably of interest that in the week after that meeting the Telecom 91 takes place in Geneva. In case you want to spend the few days inbetween somewhere in Switzerland, you could contact one of the following tourist information offices: Tourist Information for Zurich Tel: 41 1 211 40 00 Bahnhofplatz 15 Fax: 41 1 212 01 41 CH-8001 Zurich Swiss Tourist Information Tel: 41 1 288 11 11 Postfach Fax: 41 1 288 12 05 CH-8027 Zurich (All prices are given in Swiss Francs) *** Hotel Rex (Garni) Tel: 41 1 361 96 46 Weinbergstrasse 92 Fax: 41 1 361 20 47 CH-8006 Zurich Price: 140.00 (5 rooms have twin beds, 5 rooms have "normal beds), bath or shower, taxes, breakfast, service included) 5 minutes to the meeting room, new, rather large rooms, phone, colour TV *** Hotel Ruetli Tel: 41 1 251 54 26 Zaehringerstrasse 43 Fax: 41 1 261 21 53 CH-8001 Zurich Price: 130.00 (bath or shower, WC, breakfast, taxes, service included). 4 minutes to the meeting room, new rooms, phone, colour TV ** Hotel Sunnehus Tel: 41 1 251 65 80 Sonneggstrasse 17 CH-8006 Zurich Price appr. 120 - 140 3 minutes to the meeting room *** Hotel Astor Tel: 41 1 251 35 60 Weinbergstrasse 44 Fax: 41 1 251 49 15 CH-8006 Zurich Price: appr. 150 - 160 rather small rooms one minute to the meeting room *** Hotel Arc Royal Comfort Inn Tel: 41 1 261 67 10 Leonhardstrasse 6 Fax: 41 1 251 47 80 CH-8001 Zurich Price appr. 110 - 140 2 minutes to the meeting room **** Hotel Helmhaus Tel: 41 1 251 88 10 Schifflaendeplatz 30 Fax: 41 1 251 04 30 CH-8001 Zurich Price appr. 140 5 min. ride by tram the hotel is located in the "old" part of the city. ==========   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <1511-0@bells.cs.ucl.ac.uk>; Mon, 2 Sep 1991 17:05:26 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Mon, 2 Sep 1991 17:05:31 +0100 X400-Received: by /PRMD=reunir/ADMD=atlas/C=FR/; Relayed; Mon, 2 Sep 1991 18:02:20 +0100 Date: Mon, 2 Sep 1991 16:05:31 +0000 X400-Originator: leguigne@fr.cicb X400-MTS-Identifier: [/PRMD=reunir/ADMD=atlas/C=FR/;683827340@sunir.reunir.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Do you co... From: Jean-Paul Le Guigner - CICB Rennes 99 84 71 50 Message-ID: <9109021603.AA10562@mailimailo.cicb.fr> To: osi-ds@fr.cicb Cc: RARE & IETF OSI-DS wg , Rare WG3 In-Reply-To: <6157*/S=Lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> Subject: Re: Do you come to RARE WG3 in Zurich (30.9.-2.10) ? | RFC-822-HEADERS: | X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relaye d; Mon, 2 Sep 1991 14:40:08 +0100 | X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; M on, 2 Sep 1991 14:40:06 +0100 | X400-Originator: Lenggenhager@gate.switch.ch | X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910902154006] | X400-Content-Type: P2-1984 (2) | Content-Identifier: 6157 | Importance: High | | Erik asked you to send me mail when you plan to attend the meeting. From some | of you I got a message, but others who will attend for sure haven't sent one | yet. | | Could you please check the following list, whether you are already listed | there when you plan to attend the RARE WG3 meeting in Zurich. | | If you attend only Tuesday or Wednesday but plan to come to the common di nner, | | please let me know it too, so we can reserve the necessary tables. | | On Monday we will leave for dinner on 19.00 hours, | on Tuesday on 20.00 hours. | | 30.9. 1.10. 2.10. | ------------------------------------------------------------------------- ---- | Marko Bonac YUNAC YU x x x | Ulrike Dillmann BELWue DE x x | Dominique Dumas EARN France FR x x | Peter Flynn HEANET IE x x x | Gerti Foest DFN DE x x | Jill Foster NISP UK x x x | Peter Gloor Univ St. Gallen CH x | Lisa Golka BELWue DE x x | Roland Hedberg SUNET SE x x x | Erik Huizer SURFnet NL x x x | Cuno Lanz ETH Zurich CH x x | Thomas Lenggenhager SWITCH CH x x x | Steen Linden Univ Copenhagen DK x x | Nils Meulemans Univ Brussels BE x x x | Bernd Rieger DFN DE x x | Florian Schnabel ACONET AT x x x | Heinrich Schneeberger PTT CH x x | Thomas Schoenenberger Univ St. Gallen CH x | Jean-Marc Verbergt Univ Brussels BE x x x | Marcel Wiget SWITCH CH x | Shirley Wood JANET UK x x x | | | | I haven't got a message (or I lost it?) from the following persons who | attended recent meetings or are expected to give a presentation. | --> Please confirm the dates of your attendence | 30.9. 1.10. 2.10. | ------------------------------------------------------------------------- ---- | Paul Barker UCL UK x | Steve Benford Nottingham Univ UK x | Tim Berners-Lee CERN CH x | Yannis Corovesis NRC Demokritos GR | Jim Craigie JNT UK | Christopher Duxbury CPMU BE | Andrew Findlay Brunel Univ UK x | Anders Gilner SUNET SE | David Goodman UCL UK | Steve Hardcastle-Kille UCL UK | Maria Heijne SURFnet NL | Graham Knight Level-7 UK | Jean-Paul LeGuigner CICB FR Thomas, I will be attending the meeting as well as Paul Andre Pays. I'll arrive on monday at about 2:30 in the meeting room, and leave on the afternoon of the 2nd of OCtober. Paul is arranging for a hotel for both. Regards, Jean-Paul | Ignacio Martinez IRIS ES | Tim Maude Level-7 UK | Ignacio de los Mozos IRIS ES | Joao Neves INESC PT | Gardar Nielsen Univ Iceland IS | Donal O'Mahony HEANET IE | Petri Ojala FUNET FI | Pascal Paridans Univ Brussels BE | Paul-Andre Pays OPAX FR | Geir Pedersen UNINETT NO | Joyce Reynolds US | Colin Robins Xtel UK x | Celestino Tomas RedIRIS/FUNDESCO ES | Maria Zacharova-Dimou CERN CH | | | For the late ones of you, who didn't book a hotel yet, I include that | information at the end. Good luck in finding a room! | | Shortly before the meeting I will send around the information on how to | get from the airport into the city and to the meeting room. (It takes onl y | about 30 to 45 minutes to get from the airport to the meeting room and th e | hotels are nearby.) | | Thomas Lenggenhager | SWITCH | | ========================================================================= ====== | Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerla nd | INET: lenggenhager@switch.ch | Tel: +41-1-261 8178 | Fax: +41-1-261 81 33 | X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH | | _________________________________________________________________________ __ | Program RARE WG3 meeting 30 sept.-2 oct. 1991 Zurich, Switzerland | | Zurich, SWITCH/ETH Zurich | | 30 september | 1300 RARE WG3:Directory Service (DS) session | COSINE P2.1 (PARADISE) Operational meeting | 1800 closing | | 1 october | Open sessions and presentations | | Big room Terminal room Lecture room | with video no facilities | ------------------------------------------------------ | 0900 Paul Barker (UCL/Paradise) | Paradise Central DUA | 0945 Someone from the US(?) | Mac DUA or FOX/WPP status | | 1030 break | | 1100 Andrew Findlay (Brunell) | Brunell (X)DUA | | 1145 Graham Knight (Level-7 Ltd) | P2.2 Prototype | | 1300 Lunch | PARALLEL SESSIONS: | 1400 Tim Berners-Lee (CERN) Colin Robbins (Xtel) | Hypertext Tutorial DSA | | 1500 Steve Benford (Nottingham Univ.) continued | Group Communications | | 1600 RARE WG 3 Plenary (Directory Service and User Support & | Information Services) | | 1700 Drinks Various demo's | | | The various demos would consist of: | | ETHZ ITAXA DUA for Mac | Steve benford Group Communication | PSI (?) Mac DUA | Tim Howes (?) Mac DUA | Brunel DUA's | Paul Barker DUA | Level-7 P2.2 | Celestino Tomas VMS DUA | X-tel DUAs | Tim Berners-Lee Hypertext next | Maria Dimou CERN Directory | Joyce Reynolds (?) | | | 2 october | 0900 RARE WG3:User Support & Information Services (USIS) part | (maybe parallel some DS demo evaluations in the terminal room) | 1600 COSINE P2.2 (CONCISE) meeting | 1800 end of meeting | _________________________________________________________________________ __ | | | ----------------------- Zurich Hotel Information ------------------------ - | For some of you coming from further away, it could be probably of interes t | that in the week after that meeting the Telecom 91 takes place in Geneva. In | case you want to spend the few days inbetween somewhere in Switzerland, y ou | could contact one of the following tourist information offices: | | Tourist Information for Zurich Tel: 41 1 211 40 00 | Bahnhofplatz 15 Fax: 41 1 212 01 41 | CH-8001 Zurich | | Swiss Tourist Information Tel: 41 1 288 11 11 | Postfach Fax: 41 1 288 12 05 | CH-8027 Zurich | | (All prices are given in Swiss Francs) | | *** Hotel Rex (Garni) Tel: 41 1 361 96 46 | Weinbergstrasse 92 Fax: 41 1 361 20 47 | CH-8006 Zurich | | Price: 140.00 (5 rooms have twin beds, 5 rooms have "normal beds), | bath or shower, taxes, breakfast, service included) | | 5 minutes to the meeting room, new, rather large rooms, phone, | colour TV | | *** Hotel Ruetli Tel: 41 1 251 54 26 | Zaehringerstrasse 43 Fax: 41 1 261 21 53 | CH-8001 Zurich | | Price: 130.00 (bath or shower, WC, breakfast, taxes, service includ ed). | | 4 minutes to the meeting room, new rooms, phone, colour TV | | | ** Hotel Sunnehus Tel: 41 1 251 65 80 | Sonneggstrasse 17 | CH-8006 Zurich | Price appr. 120 - 140 | 3 minutes to the meeting room | | *** Hotel Astor Tel: 41 1 251 35 60 | Weinbergstrasse 44 Fax: 41 1 251 49 15 | CH-8006 Zurich | Price: appr. 150 - 160 | rather small rooms | one minute to the meeting room | | *** Hotel Arc Royal Comfort Inn Tel: 41 1 261 67 10 | Leonhardstrasse 6 Fax: 41 1 251 47 80 | CH-8001 Zurich | Price appr. 110 - 140 | 2 minutes to the meeting room | | **** Hotel Helmhaus Tel: 41 1 251 88 10 | Schifflaendeplatz 30 Fax: 41 1 251 04 30 | CH-8001 Zurich | Price appr. 140 | 5 min. ride by tram | the hotel is located in the "old" part of the city. | ========== | | Jean-Paul Le Guigner - CICB (leguigner@cicb.fr) 99 84 71 50   Return-Path: Received: from Osprey.Telcom.Arizona.edu by bells.cs.ucl.ac.uk with SMTP inbound id <27248-0@bells.cs.ucl.ac.uk>; Tue, 3 Sep 1991 00:28:36 +0100 Received: from Arizonet by Arizona.edu with PMDF#10282; Mon, 2 Sep 1991 16:29 MST Date: Mon, 2 Sep 1991 16:29 MST From: Motivated now Subject: Subscribe To: osi-ds@uk.ac.ucl.cs Message-id: X-Envelope-to: osi-ds@cs.ucl.ac.uk X-VMS-To: IN::"osi-ds@cs.ucl.ac.uk" I apologize if I am intruding on this list, but I don't know how else to subscribe. Thank you. Nancy Ashley   Return-Path: Received: from merit.edu by bells.cs.ucl.ac.uk with SMTP inbound id <6355-0@bells.cs.ucl.ac.uk>; Tue, 3 Sep 1991 16:15:05 +0100 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA08388; Tue, 3 Sep 91 11:14:59 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA10879; Tue, 3 Sep 91 11:14:58 EDT Date: Tue, 3 Sep 91 11:14:58 EDT From: clw@edu.merit Message-Id: <9109031514.AA10879@home.merit.edu> To: Lenggenhager@ch.switch.gate, osi-ds@uk.ac.ucl.cs, rare-wg3@nl.surfnet Subject: Re: Do you come to RARE WG3 in Zurich (30.9.-2.10) ? I will be attending all three days of the RARE WG 3 meeting, and will be giving the presentation on FOX/WPP status at 0945 on 1 October. Chris Weider Chair, IETF DISI Working Group MERIT Network   Return-Path: Received: from newcastle.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <2861-0@bells.cs.ucl.ac.uk>; Wed, 4 Sep 1991 15:30:47 +0100 Received: from uk.ac.ncl.mts by uk.ac.newcastle; Wed, 4 Sep 91 15:31:21 +0100 Date: Wed, 04 Sep 91 15:26:14 +0100 From: Jill.Foster@uk.ac.newcastle Subject: Attendance at WG3 meeting To: Rare WG3 , osi-ds@uk.ac.ucl.cs Message-Id: Sorry to burden both lists. If you're on both lists you need only reply once :-) In Erik's absence I need to know who is coming to WG3, which country you are representing (if appropriate) and for which Subgroup. I also need to know whether you will be funded by your own institution. Please do not assume that you will be funded by RARE unless Erik has already told you that you will be. Remember the rule is one funded member per RARE country for EACH Subgroup. (You are of course welcome to stay over for the other subgroup). Please fill in the template following the Example: Name Country DS Open Day USIS "Own" funding? 30 Sept 1st Oct 2nd Oct James Bond UK x x (x) No (Example shows member who reps. the UK for the Directory Services Subgroup but who will also stay over for the User Support and Info Services Subgroup (hence "(x)"). Thanks - Jill   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11600-0@bells.cs.ucl.ac.uk>; Thu, 5 Sep 1991 10:24:44 +0100 To: osi-ds@uk.ac.ucl.cs cc: helpdesk@uk.ac.ulcc.paradise Subject: PARADISE International Report #1 Phone: +44-71-380-7294 Date: Thu, 05 Sep 91 10:24:42 +0100 Message-ID: <994.684062682@UK.AC.UCL.CS> From: Steve Hardcastle-Kille The PARADISE project has produced a glossy report on the international directory pilot. I brought a number of these to Atlanta, but not sufficient to meet the demand. Several people have asked how to get copies. We have a limited number left. If you wish for a copy, they can be requested from the PARADISE helpdesk (run by Linda Millington). Full information on the helpdesk may be found in the OSI directory. The email address is cc'd here. Steve PS Report #2 is due in November, and we will make a longer print run   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11755-0@bells.cs.ucl.ac.uk>; Fri, 6 Sep 1991 11:54:06 +0100 To: osi-ds@uk.ac.ucl.cs Subject: NADF 175 (RFC) Phone: +44-71-380-7294 Date: Fri, 06 Sep 91 11:54:05 +0100 Message-ID: <1434.684154445@UK.AC.UCL.CS> From: Steve Hardcastle-Kille ------- Forwarded Message From: "Joyce K. Reynolds" To: Request-for-Comments-List:; Subject: RFC1255 on A Naming Scheme for c=US Date: Thu, 05 Sep 91 13:31:26 PDT A new Request for Comments is now available from SRI's Network Information Systems Center in the online library at FTP.NISC.SRI.COM. RFC 1255: Title: A Naming Scheme for c=US Author: The North American Directory Forum Pages: 25 Characters: 52,381 Obsoletes: RFC 1218 pathname: rfc/rfc1255.txt This RFC is a near-verbatim copy of a document, known as NADF-175, which has been produced by the North American Directory Forum (NADF). The NADF is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. NADF-175 represents the NADF's agreement in this area. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET, NISC.JVNC.NET, VENERA.ISI.EDU, or WUARCHIVE.WUSTL.EDU. Instructions for retrieving RFCs may be found in the file "in-notes/rfc-retrieval.txt" on VENERA.ISI.EDU. Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to POSTEL@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Requests to be added to or deleted from this distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Joyce K. Reynolds USC/Information Sciences Institute ------- End of Forwarded Message   Return-Path: Received: from alw.nih.gov by bells.cs.ucl.ac.uk with SMTP inbound id <15715-0@bells.cs.ucl.ac.uk>; Fri, 6 Sep 1991 14:58:23 +0100 Received: from pc.niaid.nih.gov by alw.nih.gov (5.61/alw-2.1) id AA06230; Fri, 6 Sep 91 09:59:00 -0400 Date: Fri, 06 Sep 91 09:58:27 EST Message-Id: <28c78983@Bethesda.BAH.pc.niaid.nih.gov> X-Mailer: Unix/3Com MX v4.3 91.03.04 From: Ogden Frank To: osi-ds@uk.ac.ucl.cs Subject: Request for Information Linda Millington, As a new entry to this DL, I'd like to know what is available from your helpdesk function and how to access the OSI directory. This message is in response to S.Kille's note on the glossy report on the international directory pilot. How does one obtain a copy? I'm assisting a very large enterprise transition to X.400 and X.500 capabilities and can use all the info I can find in these areas. Thanks   Return-Path: Received: from sariel.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <15311-0@bells.cs.ucl.ac.uk>; Fri, 6 Sep 1991 19:27:32 +0100 To: punters@uk.ac.ulcc.paradise, rare-wg3@nl.surfnet, osi-ds@uk.ac.ucl.cs cc: D.Goodman@uk.ac.ucl.cs Subject: RARE WG3/Zurich Date: Fri, 06 Sep 91 19:27:23 +0100 From: D.Goodman@uk.ac.ucl.cs Hi, Please see below a draft agenda for the RARE WG3/PUNTERS meeting on 30 September at SWITCH in Zurich. The first half of the meeting is RARE WG3 oriented and the second half PARADISE, but it's not intentioned to maintain a rigorous distinction between the two (I hope!) If you feel there is something to discuss at the meeting now is a good time to recommend it for the agenda. No complaints that you haven't been given the chance to improve it! Also, if you haven't already let Erik, Jill or Thomas know whether you're coming and how long for, please let me know and I'll pass on your news. For those who haven't seen the timetable for the three days 30 September - 2 October: the afternoon of the Monday is for Directory Services, all day Tuesday for Open Sessions, Presentations, Tutorials and Demonstrations; and Wednesday for a meeting of the User Support & Information Services group and the CONCISE project. Let me know if you want to know more. Likewise anyone who would like details of hotels etc, shout. See you there. David PS I apologise to people who are on all three mailing lists for getting this message three times. ------------------------------------------------------------------------ DIRECTORY SERVICES RARE WG3/PUNTERS 3 SEPTEMBER 30, 1991 SWITCH, ETH-Zentrum CH-8092 Zurich DRAFT AGENDA Meeting start: 1300 Meeting end: 1800 1. Introduction: - Agenda - Previous minutes 2. Liaisons with other groups: - ISO/CCITT (Oliver Wenzel) - IETF OSI-DS (Steve Hardcastle-Kille) - DISI (Chris Weider) - Y-Net (David Goodman) 3. RARE Technical Documents 4. Document Review: - Naming Guidelines (OSI-DS 12) - DSA Naming (OSI-DS 13) - Network Infrastructure Information (OSI-DS 14) - NIC Profile Information (OSI-DS 16) - Resource Description (OSI-DS 17) - Requirements Specification (OSI-DS 18) 5. PARADISE Report (UCL) 6. POPS Report (ULCC) 7. PUNTERS Status Reports (round the table & missing friends) 8. Product Reports: - Implementations (QUIPU 7.0/PIZARRO/others ...) - Interfaces (de/PIZARRO/others ...) 9. Interoperability Report (Colin Robbins/Paul-Andre Pays) 10. PTT Netherlands Report (Meindert Bekker) 11. PARADISE International Report #2 12. Publicity: - T-shirts - Press release - PARADISE leaflet 13. ESPRIT Conference Week 14. Workplans: - WG3 - PARADISE - WG3 & PUNTERS - 1993 + 14. AOB 15. Next meeting(s) -------------------------------------------------------------------   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <16108-0@bells.cs.ucl.ac.uk>; Mon, 9 Sep 1991 09:53:39 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Meeting on the 8th October Phone: +44-71-380-7294 Date: Mon, 09 Sep 91 09:53:38 +0100 Message-ID: <974.684406418@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I have been innundated with offers of rooms! (Only one offer, which would have access problems for non-US people). Let me ask again! I'm looking for a room for a meeting of 30-40 people on 8th October in the Bay Area. If I don't get an offer very shortly, I will cancel the meeting due to lack of interest. Steve   Return-Path: Received: from ws28.nisc.sri.com by bells.cs.ucl.ac.uk with SMTP inbound id <4006-0@bells.cs.ucl.ac.uk>; Mon, 9 Sep 1991 16:28:17 +0100 Received: by ws28.nisc.sri.com (5.64/SRI-NISC1.1) id AA11524; Mon, 9 Sep 91 08:28:11 -0700 Message-Id: <9109091528.AA11524@ws28.nisc.sri.com> To: Steve Hardcastle-Kille Cc: osi-ds@uk.ac.ucl.cs, rlang@com.SRI.NISC Subject: Re: Meeting on the 8th October In-Reply-To: Your message of Mon, 09 Sep 91 09:53:38 +0100. <974.684406418@UK.AC.UCL.CS> Date: Mon, 09 Sep 91 08:28:10 BST From: Ruth Lang Steve, SRI is approximately 20 miles north of the San Jose Convention Center. We'd be glad to host the meeting. Ruth Lang   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <10549-0@bells.cs.ucl.ac.uk>; Tue, 10 Sep 1991 12:42:38 +0100 To: Ruth Lang cc: osi-ds@uk.ac.ucl.cs Subject: Re: Meeting on the 8th October Phone: +44-71-380-7294 In-reply-to: Your message of Mon, 09 Sep 91 08:28:10 +0100. <9109091528.AA11524@ws28.nisc.sri.com> Date: Tue, 10 Sep 91 12:42:34 +0100 Message-ID: <1972.684502954@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Ruth, Thanks for this offer - it is appreciated, and I'd like to accept it. The meeting is officially on 8th October at SRI. I suggest we meet 09:00 - 17:00. Is this sensible? I will try to get out an Agenda soon. If anyone has items for the Agenda, please let me know. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <20153-0@bells.cs.ucl.ac.uk>; Wed, 11 Sep 1991 16:32:44 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Meeting on the 8th October Phone: +44-71-380-7294 Date: Wed, 11 Sep 91 16:32:44 +0100 Message-ID: <2629.684603164@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Folks, The Interop people are going to give us a room! Therefore, we will be meeting in San Jose, not Menlo Park. I'll send more details in a bit. Thanks to Ruth, and the others who offered rooms Steve   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <12506-0@bells.cs.ucl.ac.uk>; Tue, 17 Sep 1991 09:31:39 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Tue, 17 Sep 1991 09:32:41 +0100 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Tue, 17 Sep 1991 09:32:28 +0100 Date: Tue, 17 Sep 1991 10:32:28 +0200 X400-Originator: Lenggenhager@ch.switch.gate X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910917103228] X400-Content-Type: P2-1984 (2) Content-Identifier: 6257 Priority: Urgent From: Thomas Lenggenhager Message-ID: <6257*/S=Lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: Attendence List of RARE WG3 in Zurich (30.9.-2.10) Importance: High I send once again the attendence list I gathered so far for the next RARE WG3 meeting in Zurich. Could you please check the following list, whether you are already listed there when you plan to attend the RARE WG3 meeting in Zurich? If you attend only Tuesday or Wednesday but plan to come to the common dinner, please let me know it too, so we can reserve the necessary tables. Explanation of the symbols used in the list: x attend the meeting d attend the dinner - will not attend the meeting or dinner 30.9. 1.10. 2.10. ----------------------------------------------------------------------------- Paul Barker UCL UK xd x - Tim Berners-Lee CERN CH - xd x Marko Bonac YUNAC YU xd xd x Thomas Brunner SWITCH CH d xd - Ulrike Dillmann BELWue DE xd x - Dominique Dumas EARN France FR - xd x Christopher Duxbury CPMU BE xd xd x Andrew Findlay Brunel Univ UK d xd - Peter Flynn HEANET IE xd xd x Gerti Foest DFN DE d xd x Jill Foster NISP UK xd xd x Felipe Garcia RedIRIS ES - x- x Anders Gillner SUNET SE xd xd x Peter Gloor Univ St. Gallen CH - x - Lisa Golka BELWue DE xd x - David Goodman UCL UK xd xd ? Jean-Paul Le Guigner CICB FR xd xd - Steve Hardcastle-Kille UCL UK xd x - Roland Hedberg SUNET SE xdd x x Maria Heijne SURFnet NL d xd x Willi Huber ETH Zurich CH - x - Erik Huizer SURFnet NL xd xd x Graham Knight Level-7 UK d xd x Cuno Lanz ETH Zurich CH xd xd - Thomas Lenggenhager SWITCH CH xd xd x Steen Linden Univ Copenhagen DK xd xd - Joaquim Macedo University of Minho PT xd xd x Nils Meulemans Univ Brussels BE xd xd x Ignacio de los Mozos RedIRIS ES x- x- - Donal O'Mahony Trinity College Dublin IE xd xd - Tim Maude Level-7 UK d xd x Paul-Andre Pays OPAX FR xd xd - Geir Pedersen UNINETT NO xd xd x Fernando Pinto University of Minho PT x x x Joyce Reynolds USC/ISI US xd x- x Bernd Rieger DFN DE xd xd - Colin Robbins Xtel UK xd xd x Walter Ruenzler Union Bank Switzerland CH - x - Florian Schnabel ACONET AT xd xd x Heinrich Schneeberger PTT CH x x - Thomas Schoenenberger Univ St. Gallen CH - x - Celestino Tomas RedIRIS ES x- x- - Flemming Topsoe EUROMATH DK - xd x Panos-Gavril Tsigaridas Fokus/GMD DE xd x - Jean-Marc Verbergt Univ Brussels BE xd xd x Chris Weider MERIT US xd xd x Oliver Wenzel Fokus/GMD DE xd x - Marcel Wiget SWITCH CH - x - Shirley Wood JANET UK - xd x Petr Zimak University Basel CH - x - From the following persons I haven't got a message yet. I think some of them plan to attend. --> Please confirm the dates of your attendence 30.9. 1.10. 2.10. ----------------------------------------------------------------------------- Steve Benford Nottingham Univ UK ? Philippe Brun E3X FR Yannis Corovesis NRC Demokritos GR Jim Craigie JNT UK Joao Neves INESC PT Gardar Nielsen Univ Iceland IS Petri Ojala FUNET FI Maria Zacharova-Dimou CERN CH *** Information on the common dinners *** Monday (30.9.) leaving from Zurich main station at 19.00 hours We will have dinner will be on top of the 'mountain' of Zurich, the Uetliberg, 400 meters above the town, in the restaurant 'Uto Kulm'. A train will bring us near to the top, you will only have to walk the last few meters. Tuesday (1.10.) at about 20.00 hours We will have dinner near the Paradeplatz in the 'Zeughauskeller'. *** Hotel rooms *** In case you don't have yet a hotel room, you can contact me, and I will send you again the list of hotels which was on the distribution list before. *** How to find the conference room *** In a seperate message you will very soon get a description on where to find the meeting room. Thomas =============================================================================== Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerland INET: lenggenhager@switch.ch | Tel: +41-1-261 8178 | Fax: +41-1-261 8133 X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <17524-0@bells.cs.ucl.ac.uk>; Tue, 17 Sep 1991 11:36:48 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs Date: Tue, 17 Sep 91 11:36:47 +0100 From: Steve Titcombe (Slightly late. Sorry.) DSA Probe Statistics For Root DSAs, for the period Friday 23rd August - Friday 13th September. Probes from UCL, ULCC, STC, MRP of Adelaide, and GMD in Berlin. Bind Fail %age Best Worst Ave Address FR: FR,emse,opaxdsa (French Master) 42 0 100.00 0.1 0.1 0.10 dsa_available 41 0 100.00 5.4 5.9 5.84 \"mars GB: False Cobra (Root, GB backup) 459 25 94.55 0.1 1.0 0.32 dsa_available 270 4 98.52 1.5 4.1 3.66 X121 295 14 95.25 1.3 3.4 3.23 Janet 347 21 93.95 0.3 32.4 6.69 Internet 316 31 90.19 1.4 4.9 3.63 IXI Coypu (Thorn acces pt to quipu) 473 37 92.18 0.1 1.0 0.33 dsa_available 271 9 96.68 1.6 6.5 5.04 X121 85 0 100.00 0.6 4.1 1.04 Local Ether 307 20 93.49 1.3 6.4 9.10 Janet 349 23 93.41 0.6 94.3 13.23 Internet Vampire Bat (GB backup) 274 23 91.61 0.1 1.0 0.30 dsa_available 62 0 100.00 0.5 4.0 0.95 Private TCP 243 21 91.36 1.3 8.8 5.69 Janet 265 49 81.51 2.1 7.8 5.09 IXI Giant Tortoise (Root, GB Master) 460 157 65.87 0.0 1.0 0.31 dsa_available 268 62 76.87 0.3 4.7 3.00 X121 292 69 76.37 1.0 4.7 2.97 Janet 313 103 67.09 0.0 4.4 2.62 IXI 349 115 67.05 0.0 79.5 5.66 Internet Passionflower Leaf Beetle (GB Domain name information) 404 171 57.67 0.0 1.0 0.22 dsa_available 267 127 52.43 0.0 6.2 4.92 X121 338 157 53.55 0.0 46.1 10.62 Internet 248 118 52.42 0.0 9.6 5.12 Janet 269 157 41.64 0.0 15.7 4.48 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 254 254 0.00 - - - dsa_available 254 254 0.00 - - - Janet IL: Dorcan Gazelle (Israel Master) 183 11 93.99 0.1 0.1 0.10 dsa_available 183 11 93.99 7.1 109.9 20.76 Internet CA: Beluga Whale (Canada Master) 184 12 93.48 0.1 0.1 0.10 dsa_available 184 12 93.48 2.8 145.1 16.86 Internet Pangolin (Northern Telecom Master) 345 77 77.68 0.1 0.1 0.10 dsa_available 87 14 83.91 2.0 92.0 12.66 Private TCP 344 85 75.29 2.2 22.9 18.93 Internet Wayne Gretzky (Old Canada Master) 341 341 0.00 - - - dsa_available 341 341 0.00 - - - Internet ES: Cayman (Madrid Uni.) 85 6 92.94 0.1 0.1 0.10 dsa_available 84 10 88.10 6.3 68.5 31.27 Int-X.25 84 28 66.67 5.4 92.1 39.01 IXI 85 85 0.00 - - - Internet Iguana (ES Master. Programa IRIS) 451 152 66.30 0.0 1.0 0.30 dsa_available 303 97 67.99 3.7 6.8 17.49 Int-X.25 315 149 52.70 0.0 7.0 10.35 IXI 349 168 51.86 0.0 16.6 17.64 Internet SE: Hummingbird (Sweden Master) 324 28 91.36 0.1 0.1 0.10 dsa_available 323 27 91.64 2.3 109.5 22.09 Internet 270 270 0.00 - - - '0101'H/X121 NO: Electric Eel (Norway Master) 461 45 90.24 0.1 1.0 0.31 dsa_available 352 21 94.03 1.4 112.6 11.33 Internet 321 59 81.62 1.5 6.3 6.39 IXI 302 90 70.20 0.0 6.0 5.10 Int-X.25 Boa Constrictor (Norway Backup) 477 74 84.49 0.1 1.0 0.32 dsa_available 360 57 84.17 3.3 39.8 27.31 Internet 324 99 69.44 1.8 10.5 15.16 IXI 298 116 61.07 0.0 5.4 9.19 Int-X.25 CH: Condor (ETH Zurich) 354 47 86.72 0.1 0.1 0.10 dsa_available 248 63 74.60 0.0 10.0 6.89 Int-X.25 283 74 73.85 0.0 56.1 15.20 Internet 150 47 68.67 0.0 8.5 13.32 Internet Chinchilla (Swiss Master) 415 101 75.66 0.0 0.1 0.08 dsa_available 1 0 100.00 51.9 51.9 51.90 Int-X.25 3 0 100.00 3.8 7.5 5.30 Int-X.25 8 0 100.00 2.1 12.2 6.19 Internet 164 4 97.56 2.7 14.4 6.84 Int-X.25 216 8 96.30 1.4 8.9 13.31 Internet 110 20 81.82 2.1 66.2 16.82 Internet 2 1 50.00 2.8 2.8 2.80 Internet 1 1 0.00 - - - Int-X.25 20 20 0.00 - - - Int-X.25 213 213 0.00 - - - IXI 3 3 0.00 - - - Int-X.25 DE: Puma (GMD/FOKUS) 398 57 85.68 0.1 1.0 0.23 dsa_available 300 32 89.33 1.1 7.1 13.20 Int-X.25 270 37 86.30 1.8 6.2 9.76 IXI 236 35 85.17 0.0 28.6 7.81 Internet 103 38 63.11 4.5 28.4 21.20 Internet Margay (GMD/F3, DE backup) 412 109 73.54 0.1 1.0 0.24 dsa_available 348 77 77.87 1.2 152.1 25.13 Internet 303 68 77.56 1.6 146.2 15.48 Int-X.25 276 86 68.84 2.0 10.2 6.29 IXI AU: Anaconda (AU Master) 370 61 83.51 0.1 0.1 0.10 dsa_available 369 76 79.40 1.2 35.1 19.74 Internet 303 132 56.44 0.0 10.7 9.89 Int-X.25 Bush Dog (master for AU (phony)) 359 136 62.12 0.1 0.1 0.10 dsa_available 359 136 62.12 0.9 18.6 27.39 Internet US: Fruit Bat (US@l=NY master) 348 86 75.29 0.1 0.1 0.10 dsa_available 5 0 100.00 2.3 18.9 6.50 Internet 343 86 74.93 1.7 35.7 33.73 Internet Alpaca (US master) 370 153 58.65 0.0 0.1 0.10 dsa_available 370 153 58.65 0.0 29.2 8.44 Internet Giant Anteater (Various slave) 338 338 0.00 - - - dsa_available 338 338 0.00 - - - Internet IE: Irish Elk (Republic of Ireland Master) 439 129 70.62 0.1 1.0 0.30 dsa_available 341 73 78.59 2.4 107.4 26.72 Internet 311 184 40.84 0.0 34.2 15.34 IXI DK: Axolotl (DK Master) 364 109 70.05 0.1 0.1 0.10 dsa_available 364 109 70.05 2.6 29.3 22.42 Internet NL: Hornero (NL Master) 355 117 67.04 0.1 0.1 0.10 dsa_available 270 85 68.52 2.5 11.8 9.00 '0101'H/X121 354 129 63.56 1.7 100.5 11.87 Internet Agouti (NL Slave) 371 371 0.00 - - - dsa_available 371 371 0.00 - - - Internet FI: Jaguar (Finland Master) 344 133 61.34 0.1 0.1 0.10 dsa_available 343 135 60.64 2.5 107.0 22.89 Internet 266 149 43.98 0.0 5.7 5.71 X121 AT: Piranah (AT Master) 341 136 60.12 0.0 0.1 0.07 dsa_available 340 144 57.65 0.0 110.0 13.48 Internet 302 203 32.78 0.0 42.5 9.49 Int-X.25 IS: Elephant Seal (Iceland Master) 353 155 56.09 0.0 0.1 0.10 dsa_available 353 155 56.09 0.0 73.9 30.93 Internet BE: Woolly Spider Monkey (Belgium Master) 184 184 0.00 - - - dsa_available 184 184 0.00 - - - Internet   Return-Path: Received: from venera.isi.edu by bells.cs.ucl.ac.uk with SMTP inbound id <15216-0@bells.cs.ucl.ac.uk>; Tue, 17 Sep 1991 23:12:29 +0100 Received: from chienne.isi.edu by venera.isi.edu (5.61/5.61+local-3) id ; Tue, 17 Sep 91 15:14:52 -0700 Date: Tue, 17 Sep 91 15:12:39 PDT From: hotz@edu.ISI Posted-Date: Tue, 17 Sep 91 15:12:39 PDT Message-Id: <9109172212.AA02300@chienne.isi.edu> Received: by chienne.isi.edu (4.0/4.0.3-4) id ; Tue, 17 Sep 91 15:12:39 PDT To: dsar@edu.ISI Cc: osi-ds@uk.ac.ucl.cs Subject: Directory Services Activities Report: 9/91 August 1991 Issue #6 Directory Services Activities ----------------------------- This report serves as a forum to distribute information about the various efforts working to develop directory services that are for, or effect, the Internet. It is published as part of the FOX Project's efforts to facilitate the coordination and cooperation of different directory services working groups. This report is distributed virtually unchanged as part of the Internet Monthly Report, and a modified version is submitted to the PARADISE International Report. We would like to encourage any organization with news about directory service activities to use this forum for publishing brief monthly news items. The current reporters list includes: o IETF OSIDS Working Group [X] o IETF DISI Working Group [X] o Field Operational X.500 Project - ISI - Merit - PSI - SRI o National Institute of Standards and Technology [X] o North American Directory Forum o OSI Implementor's Workshop [X] o PARADISE Project o PSI DARPA/NNT X.500 Project o PSI WHITE PAGES PILOT o Registration Authority Committee (ANSI USA RAC) o U.S. Department of State, Study Group D, MHS Management Domain subcommittee (SG-D MHS-MD) o ANSI ASC X3T5.4 Directory Ad Hoc Group [X] indicates no report this month Steve Hotz (hotz@isi.edu) DS Report Coordinator FOX -- FIELD OPERATIONAL X.500 PROJECT -------------------------------------- The FOX project is a DARPA and NSF sponsored effort to provide a basis for operational X.500 deployment in the NREN/Internet. This work is being carried out at Merit, NSYERNet/PSI, SRI and ISI. ISI is the main contractor and responsible for project oversight. ISI --- ISI organized the August 27 FOX phone conference, which included participants from all of the FOX contractors. FOX participants are tentatively scheduled to meet at Interop '91. Steve Hotz (hotz@ISI.EDU) MERIT ----- o Sue Hares chaired the Interop OSI hot staging session, which includes X.500 interoperability testing and demos. o Chris Weider is compiling a list of DUA demos that can be done at Interop. o Chris will attend the RARE WG3 meeting in Zurich at the end of September. o Demonstrated the K-12 directory system and e-mail interface. o Upgrade to isode/quipu 7.0 and new versions of DIXIE and sendmail-x.500 for sprint.com. All mail going through this gateway now does directory lookups. o Work on schema documents progressing. An additional document on schema for NSAP addresses is in progress. Mark Knopper (mak@merit.edu) PSI --- A script was written to automate the loading of uumap information into the DIT. PSI participated in the FOX phone conference of 8/27/91. Wengyik Yeong (yeongw@psi.com) SRI ---- Based on discussion during the IETF DISI Working Group meeting in July, Russ Wright (LBL) and Ruth Lang compiled and began work on the list of required changes to the document "A Catalog of Available X.500 Implementations" (Internet-Draft document draft-ietf-disi-catalog-00.txt). We received one revised submission for WIN/DS from The Wollongong Group, Inc. We solicited descriptions for PIZARRO, ud, and AT&T implementations(s). Thus far one description has been returned for ud from the University of Michigan. We received and responded to 10 queries regarding the document's availability. Interop demonstration ideas were submitted to Chris Weider of Merit who volunteered to coordinate this effort for the FOX project. @o=Internet@ou=WHOIS is populated based on dumps of the DDN-NIC WHOIS database. The transfer of responsibility for DDN-NIC services which includes the maintenance of the WHOIS database will transfer from SRI to GSI in October 1991. Because this transfer will effect SRI's ability to keep the information in @o=Internet@ou=WHOIS up to date, SRI initiated discussion with NSF and DARPA to pursue options to ensure that the X.500 information is kept up to date. Jose Garcia-Luna, Ken Harrenstien, and Ruth Lang participated in the FOX phone conference project meeting held on August 27. Ruth Lang (rlang@nisc.sri.com) NORTH AMERICAN DIRECTORY FORUM ------------------------------- A revised version of the NADF naming document (NADF-175) is being issued as RFC-1255 ("A Naming Scheme for C=US"). Comments are being solicited. PARADISE -------- Forthcoming project operational meetings will be held on 24 September (Nottingham) and 30 October (London). The next PUNTERS meeting will be held on the first day of the RARE WG3 meeting to be held in Zurich between 30 September and 2 October, which will include a day of tutorials, demonstrations and presentations with representation from MERIT et al. After discussion with the CPMU (the COSINE Project Management Unit) some changes are to be made to the COSINE DUA known as "de". It is hoped these will be implemented by 13 September and we look forward to receiving comments on the interface's feel and usability. The address again is: telnet 128.86.8.56, and type "dua" at the login. The project is committed to a second release of this software in twelve month's time. PARADISE will shortly be announcing the release of a packaged DSA and DUA based on QUIPU 7.0 and "de". The intention of this package is to be able to market a more turnkey X.500 solution particularly to organizations/pilots with little experience with OSI products. The next PARADISE brochure is due to come out in November to coincide with ESPRIT Conference Week, hosted by the European Commission, which takes place in Brussels between 25-29 November. There is a limited number of the first brochure still available; when supplies run dry we will make the electronic version available in PostScript. We are planning a much greater volume for the second issue. David Goodman (d.goodman@cs.ucl.ac.uk) PARADISE Project Manager PSI DARPA/NNT X.500 Project --------------------------- Modifications were made to the 'pcwp' MSDOS front-end to the White Pages, and another beta version was released at the end of the month. It is available for anonymous ftp from uu.psi.com in wp/pcwp.exe. Work is progressing on a full-screen front-end to the White Pages for MSDOS. A script was written to retrieve listings of the contents of archives available for anonymous ftp in preparation for extensions to the x5ftp retrieval application. A proposal for the organization of the US DMD was prepared, based on planning and testing (in the testbed, below) performed during the month. Testbeds were set up to perform some testing on X.500-related proposals. In the past month, testing was performed on the IETF OSIDS group's recommendations on DSA naming, and to test a proposed plan for the organization of the US DMD. Some minor testing was also performed to verify that changes made to the US public naming scheme in the last NADF meeting did not cause any problems. Wengyik Yeong (yeongw@psi.com) PSI WHITE PAGES PILOT PROJECT ----------------------------- New organizations added to the pilot this past month are: The Mitre Corporation Vitalink Communications Corporation Duke University Hughes Aircraft Co. Organizations deleted from the US arc in the past month are: University of Alaska at Fairbanks Wengyik Yeong (yeongw@psi.com) Registration Authority Committee (ANSI USA RAC) ----------------------------------------------- REPORT on the ANSI RAC Meeting of August 6-7 in NYC. Agenda items of interest to OSI-DS and the internet community were: (1) Approval of some changes to the ANSI Procedures for Registration of Names in C=US. These are not substantive in terms of the needs of the Internet community, or of OSI-DS. They mostly deal with minor legalities for things like challenge procedures and such. Registration of c=US Organization Names is proceeding smoothly at this point, though fewer than 10 names have been registered so far. Most registrations to date have been for Numeric Identifiers. (2) Results of the joint ISO/CCITT Editing Meeting for ISO DIS 9834-1 which changes the arc which is used for the combined Alpha-numeric and Numeric identifiers which are used for the ANSI c=US registrations. It seems that CCITT realized too late that only ISO had an arc that was designated to do this. (This is very confusing. I will do my best to explain it as fast simply as possible!) All the ramifications of this change are not yet fully understood, but it is agreed that any identifiers already assigned under the original arc { iso(1) member-body(2) US(840) organization(n) } must never be invalidated or compromised in any way. Thus, all alpha names and numeric identifier values already assigned under {1 2 US(840) } must be reserved by ANSI under {joint-iso-ccitt(2) country(?) 840 }, which is the new arc that is assigned to c=US by joint-iso-ccitt and which will (most likely) be administered by ANSI, since ANSI is already in the business with acceptable operational rules. Joint-iso-ccitt authority has not yet decided what number the new arc will be assigned, so it is represented here with a (?). Perhaps the number will be assigned this month at the ISO/CCITT meeting. The question of whether ANSI will have administrative authority over the new arc { 2 ? 840 } hinges on the fact that the new arc is under joint-iso-ccitt, and is assigned to the Country (c=US) and not to an ISO Member-Body (ANSI). Thus, the authority and responsibility is shared by ANSI (ISO Member-Body for the US) and the US Department of State CCITT National Committee, Study Group D (CCITT Member Body for the US). Actions are underway to resolve this in favor of ANSI assumption of { 2 ? US(840) } registration authority and responsibility. Both ANSI and Study Group D are working on it. As for the impact of this change on the use of c=US registered names in the X.500 Directory Service, it should be noted that the full numeric identifier (OID) is not used for a Distinguished Name (DN) (except possibly for the "short-form" name if it is ever approved -- but that is another story altogether). In c=US, the X.500 DN is formed with the Alpha Name value of of an ANSI Registered Organization under c=US. This means that the alpha names will all be the same in either the old or the new c=US arc, and X.500 Directory Services will be unaffected by the change. Only numeric OID values will be affected. Since the new joint-iso-ccitt arc { 2 ? 840 } will be constrained by ANSI to have the same Values (used or reserved) for any registered organization in both the { 1 2 840 } and { 2 ? 840 } arcs, and since X.500 "top" levels are always country codes (from iso 3166), nothing is changed in c=US. (3) The Proposed NADF c=US Naming scheme was presented to USA RAC for consideration of any aspects that might affect, or be affected by ANSI registration actions. ANSI USA RAC has taken the NADF proposal under study, but has not otherwise taken any action. There is concern by the NADF that ANSI should endorse the c=US scheme in order to stabilize it and assure that no actions will be taken to upset it after NADF begins to deploy systems. On behalf of the NADF, Einar Stefferud made the following proposal to the ANSI USA RAC: That the ANSI Register of Organization Names should have a related list of reserved names of organizations chartered by the US Government (e.g., Lawrence Livermore National Labs), so as to prevent attempts by private organizations to register names that are already in use by US Government chartered organizations. ANSI USA RAC countered with the argument that this is only feasible if the US Government already maintains such a list (Register of US Chartered Organization Names) that ANSI can use, without having to do a research job to find these names. Einar Stefferud has taken an assignment from the USA RAC to locate the register of US Government Chartered Organizations. This task is to be accomplished by asking those organizations involved with OSI-DS to find this register, and tell us where to get copies of the list of names to use. (e.g., LLNL should tell us where it is!) Another proposal involved the observation that ANSI appears to have registered each of the state governments, using the same FIPS 5 locality codes that the NADF uses for stateOrStateEquivalent. Closer examination shows that what is really registered are stateOrProvince names, and not states-as-organizations. Indeed, there is some confusion at this point with regard to exactly what was originally intended when ANSI grafted the FIPS 5 two letter State Codes into its registry under the { 1 2 US(840) } arc. We also note that ANSI has registered a number of ANSI Standards under the same arc, with a segment of the numeric ID space reserved for standards. Thus, under the { 1 2 US(840) } arc, ANSI has registered three distinct kinds of things (stateOrProvince names, standards names, and private organization names), each with a segment of numeric values reserved for the type. Given all this, Einar Stefferud made the following proposal to the ANSI USA RAC. Remove the copy of FIPS 5 state codes in favor of pointing to the FIPS 5 registry, in order to avoid any possible confusion about who is the real naming authority for assigning names to states and state equivalents in c=US. It is obvious that c=US naming is the prerogative of the US Government, and that the US Government is not going to ask ANSI for permission to name any new states, or state-equivalents. ANSI USA RAC countered with a task assignment Stefferud to produce a complete, fleshed out proposal as a contribution to the next ANSI USA RAC meeting during the week of November 18. The proposal is due by September 30. The skeleton of this (DRAFT) proposal is as follows (your comments are welcome): ANSI shall use and maintain 3 tables of names. Table 1: The names of the states and state-equivalents are found in FIPS 5. The FIPS 5 name for any state or state-equivalent (e.g., "California") is the registered name for that state or state-equivalent (e.g., "for the State of California"). Table 2: Names of standards registered by ANSI under { 1 2 US(840) } must be distinguished (different) from any state or state-equivalent names in FIPS 5, and from any names assigned to any private organization under this same arc. Table 3: Names of organizations in the { 1 2 US(840) } and the { 2 ? US(840) } registers maintained by ANSI must always be distinguished (different) from any names registered in Part 1, Part 2, or Part 3. The logic of this proposal is that any alpha or numeric name of any entity (state, standard or organization) registered in { 1 2 US(840) } or in {2 ? US(840) } must be unique without consideration of the attribute type with which it may be associated. This will assure that These three tables (plus the to-be-discovered table of US Government Chartered Organization Names) will thus serve as reserved lists against which names requested by applicants will be checked for conflicts. In the event of a conflict, the name request must be denied. This proposal has not yet been given to anyone else for review or comment. It will be further fleshed out and refined before submission as a contribution to the next ANSI USA RAC meeting. It is not part of this specific proposal that the two arcs -- { 1 2 US(840) } and { 2 ? US(840) } must be synchronized so that they are identical wherever there is any entry in one that also exists in the other. Also, all existing alpha names registered in { 1 2 US(840) } must be simply copied over to { 2 ? US(840) } and new organization names should henceforth be registered only in { 2 ? US(840) }. As noted above, this will not be detectable in the use of these alpha names in X.500 DistinguishedNames. Einar Stefferud (stef@ics.uci.edu) SG-D MHS-MD ----------- MHSMD will meet next month on Sept 17-18 at the US Dept of State, Room 1207. To arrange for your attendance if you wish to attend: Phone Gary Fereno at 202-647-2592, or FAX at 202-647-7407, or Internetmail to "Gary Fereno" <0004266994@mcimail.com> Secutity is tight at the State Dept. You must be listed in advance to be admitted to the building, and you must have ID to show, but there are no other restrictions that I know of. If you are not a US Citizen, ask Gary if this is a problem. A report will be forthcoming after the MHSMD meeting. Einar Stefferud (stef@ics.uci.edu) ANSI ASC X3T5.4 Directory Ad Hoc Group -------------------------------------- The American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X3T5.4 met at Nashua, New Hampshire from July 22-26 1991. The major agenda item was the preparation of ballot comments on the Committee Draft (CD) for Replication and the 12 Proposed Draft Amendments (PDAMs) for extensions to the International Consultative Committee for Telegraphy and Telephony (CCITT) X.500 Recommendations/International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 9594. The CD and PDAMs resulted from the international editing meeting in Phoenix in April-May. The Directory Ad Hoc Group is generally pleased with the content of the CD and PDAMs and proposed that the US vote to accept them with one exception, the abstract services PDAM, which has one service that is not compatible with the access control model. The proposed ballot comments were accepted by ANSI ASC X3T5.5 and with minor modifications by ANSI ASC X3T5. Draft International Standard (DIS) and Draft Amendment (DAM) text is expected in November 1991. Ella Gardner (epg@gateway.mitre.org)   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <10540-0@bells.cs.ucl.ac.uk>; Wed, 18 Sep 1991 08:31:49 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Wed, 18 Sep 1991 08:32:45 +0100 X400-Received: by /PRMD=switch/ADMD=arcom/C=ch/; Relayed; Wed, 18 Sep 1991 08:32:30 +0100 Date: Wed, 18 Sep 1991 09:32:30 +0200 X400-Originator: Lenggenhager@ch.switch.gate X400-MTS-Identifier: [/PRMD=switch/ADMD=arcom/C=ch/;910918093230] X400-Content-Type: P2-1984 (2) Content-Identifier: 6283 Priority: Urgent From: Thomas Lenggenhager Message-ID: <6283*/S=Lenggenhager/OU=gate/O=switch/PRMD=switch/ADMD=arcom/C=ch/@MHS> To: RARE & IETF OSI-DS wg , Rare WG3 Subject: How to find the meeting room for RARE WG3 in Zurich (30.9.-2.10) Importance: High Below you find a description on how to reach the meeting room. In case of special questions about Zurich contact me directly, I will try to answer them. Regards, Thomas =============================================================================== RARE WG3 Meeting Sept. 30. - Oct. 2. 1991 at ETH in Zurich, Switzerland ----------------------------------------------------------------------- Building IFW (i.e. Informatik West of ETH Zurich) Room A36 Address Haldenegg-Steig 4, CH-8006 Zurich Short overview agenda (for details see the messages from Jill and Erik) --------------------- Monday September 30: 1300-1530 RARE WG3: Directory Service (DS) session & COSINE P2.1 (PARADISE) Operational meeting 1530-1600 Break 1600-1800 RARE WG3: DS & PARADISE (contd.) 1800 closing Tuesday October 1: 0900-1030 Open sessions and presentations 1030-1100 Break 1100-1300 Open sessions and presentations (contd.) 1300-1400 Lunch 1400-1600 Open sessions and presentations (contd.) 1600- Various demonstrations 1600-1700 RARE WG3 Plenary (Directory Service and User Support & Information Services) 1700- Drinks 1930 closing Wednesday October 2: 0900-1030 RARE WG3: User Support & Information Services (USIS) 1030-1100 Break 1100-1300 RARE WG3: USIS (contd.) 1300-1400 Lunch 1400-1530 RARE WG3: USIS (contd.) 1530 End of meeting How to reach the meeting room in the IFW building from the Airport ------------------------------------------------------------------ (Normally you need about 30-45 minutes from the airport) - At the airport, please follow the signs (on the ceiling) showing you the way to the trains. Get a ticket to Zurich Main Station. (At the ticket machine you must select the code 8000). A return ticket (sFr. 8.40) allows you to travel free for 24 hours from the airport - Zurich, all trams in Zurich and the way back to the airport. Trains leave about every 10 - 15 minutes heading for Zurich Main Station (e.g. 10.04, 10.21, 10.33, 1039, 1042). This trip takes you about 10 minutes. - If you need a map or further information, you can find the office of the tourist information in the main station (on the side to the Bahnhofstrasse). - In the main Station, please walk in the direction the train entered the station. On the head of the track, turn to right and go ahead to the stairs down to the 'shop-ville', a subway with many shops. - Please follow the sign of the trams put on the ceiling. Take one of the following trams: number color direction 6 brown Zoo 7 black Bahnhof Stettbach 10 pink Oerlikon get out of it at the second stop (1st stop:Central, 2nd stop: Haldenegg). - With the attached plan you will find the Haldenegg-Steig, a small way up. - To the IFW building (Haldenegg-Steig, Nr 4): Walk up there and turn right after about 30 meters. You are now just in front of the IFW building! It is quite a new building, the walls are covered with red stone and metal. -------------------------------------------------------------------------- Clausiusstrasse --------------------+ ++-------=-------------------++ +----------+ +-- | || || | | | | || RZ building || | | | | |+-----+ +-----------------+| | | | | +------| |------------------+ +----------+ | | | | Zehnderweg | | +-----| |---------------------------------+ | | |+----+ +------+ |S| | || | |t| | || IFW building | +------------+|a| Haldenegg-Steig | || +--=--+ | | Catholic ||i| | || | ^ | | | Church ||r| | || | E | | +------------+|s| | || | n | | | | | || | t | | Leonhardstrasse +-------------------+| |`---' r | | .--------+ +-- | |\ ` y | | Tram .-' Tram Nr | Hotel Astor | \ `-----' Stop .--' ### 6,10 -> # | | \ +------------. Haldenegg/ ### .----- +--------===--------+ \ \ +-----> ### .-----' ------------------------------============= '-----' # | ######### <- Tram Nr 7 ################################# # '------------ Weinbergstrsse ^ ####################### ------------------------------------|----------------. <- Tram Nr 6,7,10 Tram Stop + Haldenegg `------------------------ =============================================================================== Thomas Lenggenhager, SWITCH, ETH-Zentrum, CH-8092 Zurich, Switzerland INET: lenggenhager@switch.ch | Tel: +41-1-261 8178 | Fax: +41-1-261 8133 X.400: S=lenggenhager;O=switch;P=switch;A=arcom;C=CH   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <9215-0@bells.cs.ucl.ac.uk>; Wed, 18 Sep 1991 14:04:41 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Revised DSA Naming I-D (OSI-DS 13) Phone: +44-71-380-7294 Date: Wed, 18 Sep 91 14:04:41 +0100 Message-ID: <4697.685199081@UK.AC.UCL.CS> From: Steve Hardcastle-Kille This document, substantially revised, is now available from the UCL Archive. It is being submitted as an I-D Steve OSI-DS 13 dsanaming.ps dsanaming.txt DSA Naming S.E. Kille September 1991 draft-ietf-osids-dsanaming-00.txt, or .ps Abstract: This INTERNET--DRAFT describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot. I believe this note to be an important step forward, as it begins to evolve a clear model of a Directory Management Domain. *********************************** The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTP, NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to bells, computer science, university college london, gb username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from ukc.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <9317-0@bells.cs.ucl.ac.uk>; Wed, 18 Sep 1991 14:07:48 +0100 Received: from mcsun by kestrel.Ukc.AC.UK via EUnet with authorised UUCP id aa16760; 18 Sep 91 14:02 BST Received: by mcsun.EU.net; Wed, 18 Sep 1991 14:53:46 +0200; from corton.inria.fr with SMTP; id AA09642 (5.65a/CWI-2.109); Received: from edfder1.UUCP by corton.inria.fr (5.65c+/90.0.9) via Fnet-EUnet id AA08800; Wed, 18 Sep 91 13:58:06 +0200 (MET) Received: from cli53an.edf.fr by edfder1.edf.fr, Wed, 18 Sep 91 13:51:11 +0200 Received: from loghost by cli53an.edf.fr (4.0/SMI-4.0) id AA04411; Wed, 18 Sep 91 13:56:04 +0200 To: Steve Titcombe Cc: osi-ds@uk.ac.ucl.cs Subject: Re: DSA Probe Statistics For Root DSAs In-Reply-To: Steve Titcombe's message of 17 Sep 91 11:36:47 +0100. <"17556 Tue Sep 17 11:37:44 1991"@cs.ucl.ac.uk> Date: Wed, 18 Sep 91 13:56:03 +0200 Message-Id: <4410.685194963@cli53an> From: Sylvain Langlois > FR: > FR,emse,opaxdsa (French Master) > 42 0 100.00 0.1 0.1 0.10 dsa_available > 41 0 100.00 5.4 5.9 5.84 \"mars Thanks for these lines ! Sylvain ---------------- Sylvain Langlois "Dogmatic attachement to the supposed merits (sylvain@cli53an.edf.fr) of a particular structure hinders the search of an appropriate structure" (Robert Fripp)   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <14959-0@bells.cs.ucl.ac.uk>; Thu, 19 Sep 1991 14:03:45 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Thu, 19 Sep 1991 14:03:42 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 19 Sep 1991 13:54:55 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 19 Sep 1991 15:58:00 +0100 Date: Thu, 19 Sep 1991 12:54:55 +0000 X400-Originator: Erik.Huizer@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.672:19.08.91.12.54.55] X400-Content-Type: P2-1984 (2) Content-Identifier: Agenda for RA... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"10673 Thu Sep 19 14:55:04 1991"@surfnet.nl> To: Rare WG3 , RARE & IETF OSI-DS wg Subject: Agenda for RARE WG3 and Punters meeting in Zurich X-VMS-To: WG3,OSI-DS Documents mentioned in the agenda, can be found on the UCL document server (see mail today from David goodman) or have been send around over the WG3 list. Come well prepared, I am sure it's going to be a productive meeting. Erik ___________________________________________________________________________ RARE WG3 SEPTEMBER 30-OCTOBER 2, 1991 SWITCH, ETH-Zentrum CH-8092 Zurich AGENDA 30 september ___________________________________________________________________________ WG3-DS and Paradise Punters meeting ___________________________________________________________________________ Meeting start: 1300 Meeting end: 1800 1. Introduction: - Agenda - Previous minutes 2. Liaisons with other groups: - ISO/CCITT (Oliver Wenzel) - IETF OSI-DS (Steve Hardcastle-Kille) - DISI (Chris Weider) - Y-Net (David Goodman) 3. RARE Technical Documents 4. Naming in various countries - who is the naming authority - is this officialised 5. Document Review: - Naming Guidelines (OSI-DS 12) - DSA Naming (OSI-DS 13) - Network Infrastructure Information (OSI-DS 14) - NIC Profile Information (OSI-DS 16) - Resource Description (OSI-DS 17) - Requirements Specification (OSI-DS 18) 6. PARADISE Report (UCL) 7. POPS Report (ULCC) 8. PUNTERS Status Reports (round the table & missing friends) 9. Product Reports: - Implementations (QUIPU 7.0/PIZARRO/others ...) - Interfaces (de/PIZARRO/others ...) 10. Interoperability Report (Colin Robbins/Paul-Andre Pays) 11. PTT Netherlands Report (Meindert Bekker) 12. PARADISE International Report #2 13. Publicity: - T-shirts - Press release - PARADISE leaflet 14. ESPRIT Conference Week 15. Workplans: - WG3 - PARADISE - WG3 & PUNTERS - 1993 + 16. AOB 17. Next meeting(s) 1 october ___________________________________________________________________________ Demo's, tutorials and Plenary ___________________________________________________________________________ Big room Terminal room Lecture room with video no facilities ------------------------------------------------------ 0900 Paul Barker (UCL/Paradise) Paradise Central DUA 0940 Chris Weider (Merit) FOX 1030 break 1100 Andrew Findlay (Brunell) Brunell (X)DUA 1145 Graham Knight (Level-7 Ltd) P2.2 Prototype 1300 Lunch PARALLEL SESSIONS: 1400 Tim Berners-Lee (CERN) Colin Robbins (Xtel) Hypertext Tutorial DSA 1500 Steve Benford (Nottingham Univ.) continued Group Communications 1600-1700 plenary 1 Introduction - Agenda - Minutes 2 Erik's corner (RARE CoA/WGC) several reports 3 The future of WORKING Group 3! 4 Short report of DS session for USIS people 5 Jill's server and WG3 6 Dates/places etc. next meeting(s) 7 AOB 1700 Drinks and Various demo's The various demos would consist of: ETHZ ITAXA DUA for Mac Steve benford Group Communication Chris Weider Mac DUA (Univ of Michigan) Andrew Findlay DUA's (Brunell) Paul Barker DUA Level-7 P2.2 Celestino Tomas VMS DUA X-tel DUAs Tim Berners-Lee Hypertext next Maria Dimou CERN Directory E3X DSA/DUA 2 october ___________________________________________________________________________ USIS Subgroup ___________________________________________________________________________ 0900-1530 1. Introduction - Agenda - Minutes of previous meeting - Admin: Sub-group mailing list etc - Workplan (ongoing item during meeting) 2. CPMU report - CMPU staff changes (and introductions) - COSINE Project Status reports - P2.2 - P3: Phase I report and plans for Phase II I have been asked by some members of the group to keep this section for WG3 members only to allow free and frank discussion. The P3 Phase I contractors will not be present, and the CONCISE team have agreed to join the meeting after item 2. Any real concerns should of course be relayed to them during item 3. 3. P2.2: European Information Sevice - Queries and concerns - Initial service and system - Documentation/User Guide - Information gathering - Tools for group communication on CONCISE 4. Liaison with North America - Presentation: "User Services Planning in the Internet" Joyce Reynolds USC/ISI - IETF US-WG and USAC and Liaison with RARE WG3 USIS - NREN Workshop and solicitation for NIS services (PF/JR) 5. Liaison between RARE countries on USIS through WG3 - The template and Thomas's server - A RARE report on USIS (similar to the PARADISE report) - Summary report on USIS activities (to be circulated): time for comments, questions, discussion (in place of usual "round table" session - The Nordic SR-NETT project: This is a cooperative project between the Nordic library and network communities to pilot the ISO 10162/10163 standards to interconnect a number of library systems. These standards are the ISO version of the Z39.50 standard. Geir will talk about the project. 6. Liaison with EARNINFO group (David Sitman) - EARNINFO plans: documentation, glossary etc (and IETF Usergloss group) 7. Liaison with other groups: - Coalition for Networked Information - Other groups working on Z39.50 - Others? 8. Group Communication and List Servers - OSI group comms work - WG3/WG1? - IETF List server development group 9. Workplan - updates needed in the light of today's discussions 10. The Text Encoding Initative: This is an international project focusing on getting on-line written material being studied within the humanities. One important aspect of the project is the exchange of texts between researchers. Geir will give a short introduction to the project, and also hand out some material. 11. AOB! ___________________________________________________________________________   Return-Path: Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <14716-0@bells.cs.ucl.ac.uk>; Fri, 20 Sep 1991 09:09:13 +0100 X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Fri, 20 Sep 1991 09:10:17 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Fri, 20 Sep 1991 09:01:38 +0100 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Fri, 20 Sep 1991 11:06:00 +0100 Date: Fri, 20 Sep 1991 08:01:38 +0000 X400-Originator: Erik.Huizer@nl.surfnet X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;surver.sur.124:20.08.91.08.01.38] X400-Content-Type: P2-1984 (2) Content-Identifier: New SURFnet X... From: Erik.Huizer@nl.surfnet Original-Sender: "Erik Huizer - SURFnet B.V. - Network Development" Message-ID: <"12125 Fri Sep 20 10:01:43 1991"@surfnet.nl> To: paradise-partners@uk.ac.ucl.cs, RARE & IETF OSI-DS wg , "SURFnet X.500 list" Subject: New SURFnet X.500 project proposal X-VMS-To: IN%"paradise-partners@cs.ucl.ac.uk",OSI-DS By the end of this month the Dutch SURFnet X.500 pilot runs to the end of its funding period (2 years). As not all the goals of the original project have been reached, I wrote a proposal for a followup project. This proposal is now underconsideration by both the foundation SURF and the CEC (value). I am confident that the money will be awarded (got some hints :-). For those of you interested in the proposal, fully (including $), you can retrieve it from our brand new ftp fileserver (dont't bother looking for anything else, it's still virtually empty): file.nic.surfnet.nl login as anonymous, your e-mail address as password. cd projects/x500 get project_proposal.txt (for the ascii version) get project_proposal.ps (for the postscript version) The proposed project concentrates mainly on: - Paradise - Datamanagement I look forward to your comments, Erik Huizer SURFnet BV   Return-Path: Received: from HAL.com by bells.cs.ucl.ac.uk with SMTP inbound id <12602-0@bells.cs.ucl.ac.uk>; Fri, 20 Sep 1991 16:23:26 +0100 Received: from halaus.hal.com ([148.57.160.129]) by hal.com (4.1/SMI-4.1) id AA23543; Fri, 20 Sep 91 08:27:39 PDT Received: from daisy.hal.com by halaus.hal.com (4.1/SMI-4.1) id AA01411; Fri, 20 Sep 91 10:24:50 CDT Subject: Please add me to the mailing list To: osi-ds@uk.ac.ucl.cs X-Mailer: Poste 1.0 From: petonic@com.hal Date: Fri, 20 Sep 91 10:24:48 -0500 Message-Id: <910920102448.6711@daisy> Encoding: 5 TEXT, 4 TEXT SIGNATURE Please add me to the X.500 mailing list... My Internet address is: petonic@hal.com TNX1.0e06, -MikeP Michael A. Petonic petonic@hal.com +1-512-794-2855 HaL Computer Systems - Director of Custodial Services and Entertainment Austin, Texas "If you *have* to live in Texas..."   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19233-0@bells.cs.ucl.ac.uk>; Fri, 20 Sep 1991 17:19:11 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Naming Guidelines (OSI-DS 12) Phone: +44-71-380-7294 Date: Fri, 20 Sep 91 17:19:09 +0100 Message-ID: <5775.685383549@UK.AC.UCL.CS> From: Steve Hardcastle-Kille The revised Naming Guidelines document is available. In view of the closensess of the next meetings, and as the co-author has not reviewed the changes, this will not be submitted as an RFC (as we agreed). We will discuss in San Jose. It might be useful to discuss in Zurich if there is space on the agenda. Steve OSI-DS 12 structure.ps structure.txt P. Barker S.E. Kille September 1991 Naming Guidelines for Directory Pilots draft-ietf-osids-dirpilots-02.ps Abstract: Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. ********** The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTP, NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to bells, computer science, university college london, gb username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19971-0@bells.cs.ucl.ac.uk>; Fri, 20 Sep 1991 17:23:35 +0100 To: osi-ds@uk.ac.ucl.cs Subject: QOS progress Phone: +44-71-380-7294 Date: Fri, 20 Sep 91 17:23:28 +0100 Message-ID: <5805.685383808@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Can anyone working on QOS (DUA implentations and Pilots) send me a brief status report, and an indication of how much material they feel there is for discussion in San Jose. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <20038-0@bells.cs.ucl.ac.uk>; Fri, 20 Sep 1991 17:24:01 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Agenda Items for Interop Phone: +44-71-380-7294 Date: Fri, 20 Sep 91 17:23:57 +0100 Message-ID: <5810.685383837@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Please send now! Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <24717-0@bells.cs.ucl.ac.uk>; Mon, 23 Sep 1991 13:05:52 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Draft Agenda and meeting venue for 8th October Phone: +44-71-380-7294 Date: Mon, 23 Sep 91 13:05:50 +0100 Message-ID: <3795.685627550@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Note that whilst this meeting is co-located with Interop, there is no requirement to register for Interop. Please send me comments on the Agenda. Steve Agenda for sixth meeting of IETF Directory Services Group Version 0 S.E. Hardcastle-Kille September 23, 1991 Date Tuesday 8th October, 1991 Time 09:00-18:00 Venue Hotel de Anza 233 West Santa Clara Street San Jose CA 95113 Tel: (408) 286-1000 Draft agenda follows. 9:00 Introduction o Agenda o Minutes of Atlanta meeting (OSI-DS-MINUTES 5) o Matters arising 9:20 Liaisons o RARE WG3 1 o ISO/CCITT o OIW (Russ Wright) o NADF o DISI 9:40 Operational status of pilots o FOX o PSI WPP (Wengyik Yeong) o Paradise (Steve Hardcastle-Kille) o AARN 10:10 Document progression to RFC 10:15 Presentation of OSI-DS Work. Summary for newcomers (Steve Hardcastle-Kille) 11:15 Strategy Document (to be circulated) 12:00 Representing management information in the directory. The new object models (OSI-DS 14, OSI-DS 16, OSI-DS 17, OSI-DS 19) (Mark Knopper et al) 13:00 Lunch 14:00 Presentation of new US Naming Scheme (Wengyik Yeong) 14:30 Naming Guidelines (OSI-DS 12) 14:45 The JPEG Experiment: pictures in the directory (Russ Wright) 15:15 The QOS Experiment 15:45 DSA Operations for Paradise: managing the root of the DIT (Colin Robbins) 16:15 DSA Naming. Presentation and discussion. (OSI-DS 13) 2 17:30 AARN Liaison 17:45 AOB 18:00 Close 3   Return-Path: Received: from relay1.UU.net by bells.cs.ucl.ac.uk with SMTP inbound id <26401-0@bells.cs.ucl.ac.uk>; Mon, 23 Sep 1991 16:28:45 +0100 Received: from internet.sbi.com (via uunet.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07899; Mon, 23 Sep 91 11:14:56 -0400 Received: from mhnj.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA18670; Mon, 23 Sep 91 11:06:15 EDT Received: by mhnj.sbi.com (4.1/SMI-4.0) id AA06848; Mon, 23 Sep 91 11:10:49 EDT Date: Mon, 23 Sep 91 11:10:49 EDT From: ch18494@com.sbi.mhnj (Christine Hall - 5R5) Message-Id: <9109231510.AA06848@mhnj.sbi.com> To: osi-ds@uk.ac.ucl.cs Subject: Subscibe me please Gentlemen, Could you please add me to your distribution list on X500? My address is: ch18494@mhnj.sbi.com (Christina Hall Global Messaging Dept Salomon Bros. 745 Route 3, Rutherford NJ, USA 07070) Thank You.   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <27353-0@bells.cs.ucl.ac.uk>; Mon, 23 Sep 1991 16:48:21 +0100 To: osi-ds@uk.ac.ucl.cs Subject: A new I-D on Access Control Phone: +44-71-380-7294 Date: Mon, 23 Sep 91 16:48:20 +0100 Message-ID: <4875.685640900@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Tim promises me that it will all be working by Interop, and so we can discuss it at the meeting! Steve OSI-DS 21 newacl.ps newacl.txt An Access Control approach for Searching and Listing S.E. Hardcastle-Kille T. Howes September 1991 Abstract: This memo defines an extended ACL (Access Control List) mechanism for the OSI Directory. It is intended to meet strong operational requirements to restrict searching and listing externally, while allowing much more freedom within an organization. In particular, this mechanism makes it possible to restrict searches to certain sets of attributes, and to prevent ``trawling'': the disclosure of large organizational data or structure information by repeated searches or lists. This capability is necessary for organizations that want to hide their internal structure, or to prevent dumping of their entire database. This memo describes functionality beyond, but compatible with, that expected in the 1992 X.500 standard. The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTP, NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to bells, computer science, university college london, gb username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from brolga.cc.uq.oz.au by bells.cs.ucl.ac.uk with SMTP inbound id <8598-0@bells.cs.ucl.ac.uk>; Tue, 24 Sep 1991 08:31:22 +0100 Date: Tue, 24 Sep 91 17:32:32 EST From: George Michaelson Subject: No "preferredName" attribute? To: osi-ds@uk.ac.ucl.cs Cc: ggm@au.oz.uq.cc Hmmm. Ok I can understand that we have to be careful with non-Indo-European naming methods, 8-bit alphabets, etc, and that commonName is a non-"loaded" form of construct, but I STILL don't understand why there isn't a "preferred name" attribute, which takes the (end-user-supplied) string that represents their desired ... well preferred name. instance: Mark Williams. locally called Wilber for reasons best not gone into. cn=Wilber Williams -not true. never called this cn=Mark Williams -legally binding, distinctly unfriendly I want to produce telephonelistings which have the form Surname, I.n.i.t.i.a.l.s (Preferred) number eg Williams, M......(Wilber) 53942 Michaelson, G.G..(George) 54079 Kille, S.E.......(Egbert) 12345 Chen, G..........(Graham) 54321 Only one of these can be synthesized from existing data in the DIT (George), and that by use of a dubious rule (first of given names is preferred, in my case true, but not for our friend "Eggy".) The last instance is real. Chen Gang, "Gang" being Chinese for "Red", a personal name bestowed in hardly the nicest of social circumstances (the cultural revolution) but undenyably his legal monniker. He has also quite deliberately chosen "Graham" as his preferred name, but hasn't (yet?) legalized this. Many examples of this can be found in the Vietnamese, Malaysian and Chinese community locally, where a western inability to come to terms with their real names has forced a pragmatic decision of a western "handle" onto people. I think the directory needs to take cognizance of this sort of thing explicitly in the attribute set, not via some external representation. I think its pan-cultural, non-language, non-charset specific, and simple. Can a suitably bounded PrintableString Attribute be assigned to this? - Preferred name is NOT always deducable from commonName. - commonName is typically part of the RDN of an entity and is non-changeable, whilst user preference for naming is flexible. - As many useful constructs can be synthesized from combinations of Preferred name and surname as from commonName. Knock me down in flames time! -George   Return-Path: X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 24 Sep 1991 09:35:25 +0100 Date: Tue, 24 Sep 1991 08:35:25 +0000 X400-Originator: osi-ds-request@uk.ac.ucl.cs X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/;bells.cs.u.286:24.08.91.08.35.25] Priority: Non-Urgent DL-Expansion-History: osi-ds@uk.ac.ucl.cs (Tue, 24 Sep 1991 09:35:25 +0100) From: "Andrew Macpherson (Postmaster)" Message-ID: <2396.685701323@palm13.bnr.co.uk> To: George Michaelson Cc: osi-ds@uk.ac.ucl.cs Subject: Re: No "preferredName" attribute? Organisation: BNR Europe, HARLOW, Essex CM17 9NA, UK Phone: +44 279 429531 ext 2423 George Michaelson wrote: | Can a suitably bounded PrintableString Attribute be assigned to this? | | - Preferred name is NOT always deducable from commonName. | - commonName is typically part of the RDN of an entity | and is non-changeable, whilst user preference for naming | is flexible. | - As many useful constructs can be synthesized from combinations | of Preferred name and surname as from commonName. | Thanks for bringing it up George! This is demonstrably a common requirement --- the internal BNR attribute set includes (with some of the names changed to make them externally clearer) firstName, In the sense `Preferred name' common diminutive or whatever. department, an alphanumeric code mTA, Mailbox location company, ie operating Company, BNR / NT / STC... eMailDomain, [Well we are international - bnr.co.uk, bnr.ca] initials, Cannot be derived from Common Name siteTelephoneCode, eg "742" -- Internal telephone system uniqueKey, for DD.ID=uniqueKey in X.400 employeeStatus, Staff / Summer Student employeeNumber, mailStopCode, Some NorthAmericanism? userCertificate, Most of which I believe are replicated by other large organisations   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <11623-0@bells.cs.ucl.ac.uk>; Thu, 26 Sep 1991 09:40:07 +0100 To: "Andrew Macpherson (Postmaster)" cc: osi-ds@uk.ac.ucl.cs Subject: Re: No "preferredName" attribute? Phone: +44-71-380-7294 In-reply-to: Your message of Tue, 24 Sep 91 08:35:25 -0000. <2396.685701323@palm13.bnr.co.uk> Date: Thu, 26 Sep 91 09:40:06 +0100 Message-ID: <1142.685874406@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Some of this clearly needs to go into the Cosine + Internet Schema. Paul and I will look at the list of attributes you propose here, and report back to the list Steve   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <8851-0@bells.cs.ucl.ac.uk>; Fri, 27 Sep 1991 12:30:10 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs Date: Fri, 27 Sep 91 12:30:10 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 13th September - Friday 27th September. Probes from UCL, ULCC, STC, MRP of Adelaide, and GMD in Berlin. Bind Fail %age Best Worst Ave Address FR: FR,emse,opaxdsa (French Master) 64 0 100.00 0.1 0.1 0.10 dsa_available 64 0 100.00 5.3 9.4 5.98 \"mars GB: False Cobra (Root, GB backup) 245 5 97.96 0.1 1.0 0.39 dsa_available 156 4 97.44 1.5 84.3 5.36 X121 152 4 97.37 0.3 17.5 3.40 Internet 197 7 96.45 1.3 5.6 3.75 Janet 206 58 71.84 1.5 7.4 4.25 IXI Vampire Bat (GB backup) 189 6 96.83 0.1 1.0 0.40 dsa_available 62 0 100.00 0.5 3.6 0.79 Private TCP 180 4 97.78 1.4 17.0 5.12 Janet 189 54 71.43 2.2 12.2 4.17 IXI Coypu (Thorn acces pt to quipu) 245 11 95.51 0.1 1.0 0.39 dsa_available 156 7 95.51 1.6 5.5 6.92 X121 152 6 96.05 0.4 18.2 6.74 Internet 198 11 94.44 1.4 4.9 9.28 Janet 67 4 94.03 0.6 2.3 1.13 Local Ether Passionflower Leaf Beetle (GB Domain name information) 232 66 71.55 0.0 1.0 0.34 dsa_available 153 63 58.82 0.0 6.5 4.70 X121 187 59 68.45 0.0 8.5 5.90 Janet 149 62 58.39 0.0 14.5 3.92 Internet 196 115 41.33 0.0 7.1 4.83 IXI Giant Tortoise (Root, GB Master) 245 73 70.20 0.1 1.0 0.39 dsa_available 156 38 75.64 0.4 7.4 7.21 X121 197 50 74.62 1.0 6.4 3.45 Janet 152 42 72.37 0.2 3.6 1.86 Internet 206 89 56.80 0.0 5.4 2.09 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 194 194 0.00 - - - dsa_available 194 194 0.00 - - - Janet CA: Beluga Whale (Canada Master) 121 3 97.52 0.1 0.1 0.10 dsa_available 121 3 97.52 3.1 147.8 27.55 Internet Pangolin (Northern Telecom Master) 164 25 84.76 0.1 0.1 0.10 dsa_available 37 4 89.19 2.1 60.6 28.28 Private TCP 151 26 82.78 3.3 70.1 21.33 Internet Wayne Gretzky (Old Canada Master) 152 152 0.00 - - - dsa_available 152 152 0.00 - - - Internet DE: Puma (GMD/FOKUS) 235 9 96.17 0.1 1.0 0.36 dsa_available 166 7 95.78 1.1 26.8 8.98 Int-X.25 15 1 93.33 4.6 8.1 6.90 Internet 137 11 91.97 0.5 17.1 5.98 Internet 196 63 67.86 1.8 8.2 9.07 IXI Margay (GMD/F3, DE backup) 242 31 87.19 0.1 1.0 0.38 dsa_available 166 7 95.78 1.7 147.1 12.75 Int-X.25 151 13 91.39 1.2 56.9 8.21 Internet 203 82 59.61 2.0 12.0 7.87 IXI DK: Axolotl (DK Master) 152 7 95.39 0.1 0.1 0.10 dsa_available 152 7 95.39 2.7 66.3 15.45 Internet NO: Electric Eel (Norway Master) 241 16 93.36 0.1 1.0 0.38 dsa_available 151 4 97.35 1.3 40.7 6.41 Internet 165 41 75.15 0.0 84.8 5.71 Int-X.25 203 59 70.94 1.6 6.8 6.63 IXI Boa Constrictor (Norway Backup) 245 32 86.94 0.1 1.0 0.39 dsa_available 151 16 89.40 1.4 79.5 13.70 Internet 165 51 69.09 0.0 89.7 5.70 Int-X.25 207 69 66.67 1.8 13.2 10.67 IXI ES: Iguana (ES Master. Programa IRIS) 245 18 92.65 0.1 1.0 0.39 dsa_available 166 19 88.55 3.3 141.1 11.10 Int-X.25 152 18 88.16 1.6 191.9 13.56 Internet 206 63 69.42 1.6 168.7 11.14 IXI Cayman (Madrid Uni.) 67 8 88.06 0.1 0.1 0.10 dsa_available 67 8 88.06 6.2 170.5 33.35 Int-X.25 67 56 16.42 0.0 100.5 18.12 IXI 67 67 0.00 - - - Internet CH: Condor (Swiss Slave) 165 16 90.30 0.1 0.1 0.10 dsa_available 151 2 98.68 1.5 218.1 16.86 Internet 17 17 0.00 - - - Int-X.25 4 4 0.00 - - - Internet Chinchilla (Swiss Master) 232 78 66.38 0.1 1.0 0.41 dsa_available 140 4 97.14 1.0 86.0 11.92 Internet 141 6 95.74 2.6 14.2 6.31 Int-X.25 11 1 90.91 5.3 145.9 45.26 Internet 84 32 61.90 1.5 6.6 4.99 IXI 122 122 0.00 - - - IXI SE: Hummingbird (SE Master) 158 20 87.34 0.1 0.1 0.10 dsa_available 145 7 95.17 2.3 144.1 14.86 Internet 155 147 5.16 0.0 5.8 3.47 X121 AU: Anaconda (AU Master) 166 25 84.94 0.1 0.1 0.10 dsa_available 152 17 88.82 4.6 68.5 18.00 Internet 166 49 70.48 0.0 89.9 9.08 Int-X.25 Bush Dog (master for AU (phony)) 152 55 63.82 0.1 0.1 0.10 dsa_available 152 55 63.82 6.0 72.3 23.40 Internet US: Alpaca (US master) 152 31 79.61 0.0 0.1 0.10 dsa_available 152 31 79.61 0.0 48.6 9.44 Internet Fruit Bat (US@l=NY master) 152 41 73.03 0.0 0.1 0.10 dsa_available 149 38 74.50 0.0 36.0 8.32 Internet 3 3 0.00 - - - Internet Giant Anteater (Various slave) 152 152 0.00 - - - dsa_available 152 152 0.00 - - - Internet IS: Elephant Seal (Iceland Master) 152 43 71.71 0.1 0.1 0.10 dsa_available 152 43 71.71 6.2 173.8 28.21 Internet NL: Hornero (NL Master) 165 62 62.42 0.1 0.1 0.10 dsa_available 152 52 65.79 1.3 123.7 14.16 Internet 156 62 60.26 2.4 11.7 6.42 '0101'H/X121 Agouti (NL Slave) 152 132 13.16 0.0 0.1 0.04 dsa_available 29 9 68.97 1.6 11.3 5.26 Internet 123 123 0.00 - - - Internet FI: Jaguar (Finland Master) 165 73 55.76 0.1 0.1 0.10 dsa_available 152 65 57.24 2.1 25.9 15.01 Internet 156 111 28.85 0.0 5.9 5.18 '0101'H/X121 IE: Irish Elk (Republic of Ireland Master) 229 104 54.59 0.0 0.1 0.07 dsa_available 152 27 82.24 2.5 131.6 16.81 Internet 203 203 0.00 - - - IXI IL: Dorcan Gazelle (Israel Master) 121 57 52.89 0.1 0.1 0.10 dsa_available 121 57 52.89 8.0 170.5 25.70 Internet AT: Piranah (AT Master) 166 100 39.76 0.0 0.1 0.07 dsa_available 152 89 41.45 0.0 28.2 7.88 Internet 166 119 28.31 0.0 104.8 9.83 Int-X.25 BE: Woolly Spider Monkey (BE Master) 121 121 0.00 - - - dsa_available 121 121 0.00 - - - Internet   Return-Path: Received: from SPARTA.com by bells.cs.ucl.ac.uk with SMTP inbound id <24062-0@bells.cs.ucl.ac.uk>; Tue, 1 Oct 1991 14:27:04 +0100 Received: from descartes.SPARTA.COM by sparta.com (5.65/1.34) id AA16216; Tue, 1 Oct 91 09:28:27 -0400 Received: by descartes.sparta.com (4.0/cfm-mcl-sub-1.1) id AA00844; Tue, 1 Oct 91 09:23:24 EDT Date: Tue, 1 Oct 91 09:23:24 EDT From: cae@com.sparta (Charlie Eldridge) Message-Id: <9110011323.AA00844@descartes.sparta.com> To: osi-ds@uk.ac.ucl.cs Subject: request to be included in discussion list Gentlemen: Could you please add my name to the mailing list for the discussions of OSI directory services on the Internet? Thanks much. Charles Eldridge SPARTA, Inc. Internet mailing address: eldridge@sparta.com X.400 mailing address: none yet   Return-Path: Received: from CHIRALITY.RSA.com by bells.cs.ucl.ac.uk with SMTP inbound id <853-0@bells.cs.ucl.ac.uk>; Wed, 2 Oct 1991 00:35:41 +0100 Received: by RSA.COM id AA06621; Tue, 1 Oct 91 16:37:17 PDT Date: Tue, 1 Oct 91 16:37:17 PDT From: jefft@com.RSA (Jeff Thompson) Message-Id: <9110012337.AA06621@RSA.COM> To: osi-ds@uk.ac.ucl.cs Cc: burt@com.RSA Subject: Deterministic and unique UFN syntax The UFN syntax claims to be deterministic and unique in that a user friendly name can be converted to a distinct distinguished name. This is true for the placement of attribute value assertions, but I don't see how UFN determines whether an attribute value is to be encoded as a PRINTABLE STRING or a T.61 STRING. This is important since some applications need to compare DER encodings of names during a directory lookup, and it is important that the PRINTABLE STRING vs. T.61 STRING tag be set correctly for the conversion to be deterministic and unique. Is there a UFN syntax for distinguishing PRINTABLE STRING from T.61 STRING ? - Jeff   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28702-0@bells.cs.ucl.ac.uk>; Wed, 2 Oct 1991 11:22:38 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Great news on Document Progress! Phone: +44-71-380-7294 Date: Wed, 02 Oct 91 11:22:33 +0100 Message-ID: <2040.686398953@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I enclose the recent messages form the IESG, for those who have not seen them. Steve ------- Forwarded Messages From: Internet Engineering Steering Group To: Jon Postel -- RFC Editor Subject: Docment Action: X.500 and Domain Names Date: Mon, 30 Sep 91 14:17:53 -0400 Notification: The IESG recommends that the internet-draft "X.500 and Domains" be published as an Experimental protocol. This is the product of the OSI Directory Services Working Group of the IETF. Technical Summary: This provides a description of a possible way to store Domain Name Service information in an X.500 directory. This is very useful for sites which have need for both X.500 directories, and for the Domain Name Service, but which do not want to manage two independent name services. This is also useful to allow searching the DNS data stored in X.500. ------- Message 2 From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Subject: Protocol Action: Interim Approach to Network Addresses to Proposed Standard Date: Mon, 30 Sep 91 14:18:52 -0400 Recommendation: The IESG recommends that the internet-draft "An interim approach to use of Network Addresses" be published as a proposed standard. This is the product of the OSI Directory Services Working Group of the IETF. Technical Summary: The ISO standard for NSAP addresses specifies a large number of possible formats on which the address can be based, and a mechanism to ensure that any NSAP address based on any of these formats (except for the "local" format) is recognizable as a globally unique NSAP address. There is a need, for operation of OSI applications (including the directory service) over RFC 1006, to have a unique and unambiguous means for identifying IP addresses in OSI NSAP address fields. This document specifies a unique and easy to identify method for doing so. This mechanism ensures that anyone who has a valid IP address, "automatically" has a valid way to identify the IP address in an NSAP address field. The fact that the mechanism employed utilizes a relatively obscure part of the NSAP address space is not a problem, and may in fact be considered to be a useful feature. This document specifically applies to use of OSI applications over X.25, or over TCP/IP using RFC 1006. Other Internet Drafts and RFCs discussing OSI NSAP addresses (such as "Guidelines for OSI NSAP Allocation in the Internet") are largely unrelated, and are applicable where the OSI connectionless network layer protocol is being used. ------- Message 3 From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Subject: RE: Protocol Action: Interim Approach to Network Addresses to Propose d Standard Date: Mon, 30 Sep 91 14:24:32 -0400 Fat Finger error. The IESG recommendation to elevate the internet-draft "An interim approach to use of Network Addresses" was sent pre-maturely. The IESG has approved this recommendation, however, the final text has not yet been submitted to the Internet Drafts directory. This text will be made available within the next few days in the filename . Greg Vaudreuil IESG Secretary ------- Message 4 From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Subject: Protocol Action: String Encoding of Presentation Addresses Date: Mon, 30 Sep 91 14:25:08 -0400 Recommendation: The IESG recommends that the internet-draft "A string encoding of Presentation Address" be published as a proposed standard. This is the product of the OSI Directory Services Working Group of the IETF. Technical Summary: There is a need to represent presentation addresses as strings in a number of different contexts. This Internet Draft defines a format for use on the Internet. It is for human to machine interfacing and its use is recommended whenever this needs to be done. Typically, this will be for system managers rather than for end users. It is not intended for internal storage. The IESG has considered the question of whether the IETF should make Internet standards in the area of user presentation or formatting. In general, the IESG believes that presentation and formatting issues are good subjects for product differentiation in the marketplace and therefore may not be appropriate subjects for standardization. However, the IESG feels that standards for a "commonly" used presentation format is essential for smooth operations in the real heterogeneous Interent. Some possible examples of de facto "commonly" used presentation formats include the dotted 4 decimal digit notation for Internet network numbers and the DNS naming scheme. ------- Message 5 From: Internet Engineering Steering Group To: Jon Postel -- RFC Editor Subject: Document Action: X.500 Replication Requirements Date: Mon, 30 Sep 91 14:26:01 -0400 Notification: The IESG recommends that the internet-draft "Replication Requirements to provide an Internet Directory using X.500" be published as an informational RFC. This document is the work of the OSI Directory Services working group of the IETF. Evaluation: This document discusses the requirements for replication of X.500 information for use in the Internet. Some of these requirements are general to X.500 (e.g.; we need replication and the OSI standard is not done yet); some are specific to the Internet (the need to be able to operate over RFC1006). The requirements outlined in this document are real requirements accurately documented. As various X.500 pilot projects progress, we can reasonably expect that further requirements may be refined. However, the requirements outlined in this document are indeed very real. ------- Message 6 From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Subject: Protocol Action: X.500 Replication Extensions Date: Mon, 30 Sep 91 14:26:40 -0400 Recommendation: The IESG recommends that the internet-draft "Replication and Distributed Operations extensions to provide an Internet Directory using X.500" be published as a proposed standard. This is the product of the OSI Directory Services Working Group of the IETF. Technical Summary: This document outlines solutions to the replication requirements discussed in the Internet Draft . These solutions are based on the current QUIPU implementation, with a few extensions. It is the intent of the IESG to make this a standard for the Internet community. It must be understood that the mechanisms specified in this document are for INTERIM use, however, this document represents more than an experiment. In particular, It is anticipated that these mechanisms will be replaced by work that is currently ongoing in ISO. In addition, the mechanisms outlined in this paper, although important for use in current X.500 pilots, are not likely to be adequate for long term use. ------- Message 7 From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Subject: Protocol Action: X.500 Schema Date: Mon, 30 Sep 91 14:27:25 -0400 Recommendation: The IESG recommends that the internet-draft "The COSINE and Internet X.500 Schema" be published as a proposed standard. This is the product of the OSI Directory Services Working Group of the IETF. Technical Summary: This is a joint Internet (IETF) and European (COSINE) document, and that it is very valuable to have one document for both communities. This provides an important list of defined types of information which is to be stored in X.500 directories. Publication of an Internet Standard for these types is important to allow commonality across directories. For example, this is useful to avoid confusion, and is essential for searches across multiple DSAs. This document will grow and change over time as the schema is upgraded and more types of information are added to the directory. Nonetheless, this work is appropriate for standardization (In this one limited sense, this document may be somewhat analogous to the series of Internet Assigned Numbers RFCs). ------- Message 8 From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Subject: Protocol Action: OSI Directory for User Friendly Naming to Proposed Standard Date: Mon, 30 Sep 91 14:28:01 -0400 Recommendation: The IESG recommends that the internet-draft "Using the OSI Directory to achieve User Friendly Naming" be published as a proposed standard. This is the product of the OSI Directory Services Working Group of the IETF. Technical Summary: This document is of critical importance, and completes an important part of the directory/naming service which is a serious hole in the existing OSI standards. Solution to the problem of user friendly naming is critical to wide-spread acceptance and use of OSI Applications. This document is addressing two very different (although related) issues: - definition of a user-friendly external syntax for writing names. This external syntax is deterministic and unique (i.e., for any given external syntax, there is only one corresponding X.500 name and it is possible to algorithmically determine that name). - determination of how to handle "guessability" when the complete X.500 name is not available (i.e., neither the complete external syntax, nor the complete X.500 name is available). This is useful to facilitate searching in the case that the user has forgotten (or never knew) the compete name for a particular named entity. The proposal in this document is much more user friendly than any other proposal that we have seen for X.500 naming. This document therefore provides a substantial and important improvement. Also, please note that there is some operational experience with the current document, including both User Freindly syntax and the search algorithm. ------- End of Forwarded Messages   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <28342-0@bells.cs.ucl.ac.uk>; Wed, 2 Oct 1991 11:16:34 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Modified Network Address document Phone: +44-71-380-7294 Date: Wed, 02 Oct 91 11:16:28 +0100 Message-ID: <2002.686398588@UK.AC.UCL.CS> From: Steve Hardcastle-Kille This has no technical changes, but has had significant editorial work. Steve OSI-DS 5 nsap.ps nsap.txt "An Interim Approach to use of Network Addresses" S.E. Kille September 1991 draft-ucl-kille-networkaddresses-05.txt, or .ps Abstract: The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSI Network Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a global OSI Network Service. This INTERNET--DRAFT defines mechanisms to encode addressing information within Network Addresses, in order to support operation over non-OSI lower layers. In particular, support is defined for RFC 1006 mapping of COTS onto TCP/IP and COTS mapped onto X.25(1980). The following topics may be obtained from the info-server using a request in the form: request: osi-ds topic: For example: From: Joe.Soap@somedomain To: info-server@cs.ucl.ac.uk Subject: Anything you like request: osi-ds topic: scope.txt Files are available in Text, Postscript or both. FILENAME.txt for plain text format FILENAME.ps for postscript Note that not all the files are available in all the formats. All documents are numbered, in the form OSI-DS nnn or OSI-DS-MINUTES nnn The files are also available by FTP, NIFTP, and FTAM. FTP to CS.UCL.AC.UK, username anonymous and your own name as password cd osi-ds; Note that listing of the directory is not supported by the UCL FTP FTAM to bells, computer science, university college london, gb username = anon, no password NIFTP to uk.ac.ucl.cs, binary mode, username = guest, password = (Your mail address in the form user@site) filenames should be prepended with (Note that the angle brackets and capital letters are vital)   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <1340-0@bells.cs.ucl.ac.uk>; Wed, 2 Oct 1991 11:54:18 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Agenda for next week Phone: +44-71-380-7294 Date: Wed, 02 Oct 91 11:54:17 +0100 Message-ID: <2139.686400857@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I am trying hard to finalise a few items for this! I will be sending a revised agenda as soon as I can. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <19263-0@bells.cs.ucl.ac.uk>; Thu, 3 Oct 1991 14:07:26 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Agenda for the Atlanta meeting Phone: +44-71-380-7294 Date: Thu, 03 Oct 91 14:07:24 +0100 Message-ID: <1599.686495244@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Here is the revised agenda. I have added a couple of items, and changed some timings. I apologise for the fact that there is still one document not circulated. This is being held up on the final review by co-authors. I think that this document is important. I hope to have a version to circulate tomorrow. I will try to get copies brought to the meeting, due to the short notice. Steve Agenda for sixth meeting of IETF Directory Services Group Version 1 S.E. Hardcastle-Kille October 3, 1991 Date Tuesday 8th October, 1991 Time 09:00-18:00 Venue Hotel de Anza 233 West Santa Clara Street San Jose CA 95113 Tel: (408) 286-1000 Draft agenda follows. 9:00 Introduction o Agenda o Minutes of Atlanta meeting (OSI-DS-MINUTES 5) o Matters arising 9:20 Liaisons o RARE WG3 1 o ISO/CCITT (Ken Rossen) o OIW (Russ Wright) o NADF (Einar Stefferud) o DISI (Chris Weider) 10:00 Operational status of pilots o FOX o PSI WPP (Wengyik Yeong) o Paradise (Steve Hardcastle-Kille) 10:30 Document progression to RFC 10:35 Presentation of OSI-DS Work. Summary for newcomers (Steve Hardcastle-Kille) 11:05 Progress on representing management information in the directory. The new object models (OSI-DS 14, OSI-DS 16, OSI-DS 17, OSI-DS 19) (Mark Knopper et al) 11:15 Strategy Document (to be circulated) 12:00 Access Control for Searching and Listing (OSI-DS 21) 12:30 DIXIE, DAS, and lightweight protocols (RFCs 1202 and 1249) 13:00 Lunch 14:00 Presentation of new US Naming Scheme (Wengyik Yeong) 14:30 Naming Guidelines (OSI-DS 12) 14:45 The JPEG Experiment: pictures in the directory (Russ Wright) 15:15 The QOS Experiment 15:45 DSA Operations for Paradise: managing the root of the DIT (Colin Robbins) 2 16:15 DSA Naming. Presentation and discussion. (OSI-DS 13) 17:30 AARN Liaison 17:45 AOB 18:00 Close 3   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25609-0@bells.cs.ucl.ac.uk>; Fri, 4 Oct 1991 12:51:44 +0100 To: osi-ds@uk.ac.ucl.cs, iesg@us.va.reston.nri Subject: A stragic plan for deploying an Internet Directory Service Phone: +44-71-380-7294 Date: Fri, 04 Oct 91 12:51:38 +0100 Message-ID: <1119.686577098@UK.AC.UCL.CS> From: Steve Hardcastle-Kille I will be sending this document in the next message (postscript I'm afraid). This will be discussed at the WG meeting in Tuesday. This document is in many ways tentative, but I believe that it is very important to discuss it now. It must be viewed as a suggestion, with no implications of agreed policy at this stage. It will be updated and released as an Internet Draft following Interop. Steve   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25704-0@bells.cs.ucl.ac.uk>; Fri, 4 Oct 1991 12:52:27 +0100 To: osi-ds@uk.ac.ucl.cs, iesg@us.va.reston.nri Subject: Strategy (big) Phone: +44-71-380-7294 Date: Fri, 04 Oct 91 12:52:21 +0100 Message-ID: <1127.686577141@UK.AC.UCL.CS> From: Steve Hardcastle-Kille %! for use by dvi2ps Version 2.00 % a start (Ha!) at a TeX mode for PostScript. % The following defines procedures assumed and used by program "dvi2ps" % and must be downloaded or sent as a header file for all TeX jobs. % By: Neal Holtz, Carleton University, Ottawa, Canada % % % June, 1985 % Last Modified: Aug 25/85 % oystr 12-Feb-1986 % Changed @dc macro to check for a badly formed bits in character % definitions. Can get a <> bit map if a character is not actually % in the font file. This is absolutely guaranteed to drive the % printer nuts - it will appear that you can no longer define a % new font, although the built-ins will still be there. % To convert this file into a downloaded file instead of a header % file, uncomment all of the lines beginning with %-% %-%0000000 % Server loop exit password %-%serverdict begin exitserver %-% systemdict /statusdict known %-% {statusdict begin 9 0 3 setsccinteractive /waittimeout 300 def end} %-% if /TeXDict 200 dict def % define a working dictionary TeXDict begin % start using it. % units are in "dots" (300/inch) /Resolution 300 def /Inch {Resolution mul} def % converts inches to internal units /Mtrx 6 array def %%%%%%%%%%%%%%%%%%%%% Page setup (user) options %%%%%%%%%%%%%%%%%%%%%%%% % dvi2ps will output coordinates in the TeX system ([0,0] 1" down and in % from top left, with y +ive downward). The default PostScript system % is [0,0] at bottom left, y +ive up. The Many Matrix Machinations in % the following code are an attempt to reconcile that. The intent is to % specify the scaling as 1 and have only translations in the matrix to % properly position the text. Caution: the default device matrices are % *not* the same in all PostScript devices; that should not matter in most % of the code below (except for lanscape mode -- in that, rotations of % -90 degrees resulted in the the rotation matrix [ e 1 ] % [ 1 e ] % where the "e"s were almost exactly but not quite unlike zeros. % NOTE: We use A4 size paper. For letter size paper the constants '340' in the % following code should be changed to '310'. /@a4 { 72 Resolution div dup neg scale 270 -3215 translate Mtrx currentmatrix pop }def /@letter { letter initmatrix 72 Resolution div dup neg scale % set scaling to 1. 310 -3005 translate % move origin to top (these are not exactly 1" Mtrx currentmatrix pop % and -10" because margins aren't set exactly right) } def % note mode is like letter, except it uses less VM /@note { note initmatrix 72 Resolution div dup neg scale % set scaling to 1. 310 -3005 translate % move origin to top Mtrx currentmatrix pop } def % A3 modes courtesy of Francis Pintos, UCL /@a3landscape {a3 initmatrix 72 Resolution div dup neg scale -90 rotate 300 310 translate Mtrx currentmatrix pop statusdict begin 1 setpapertray end }def /@a3portrait {a3 initmatrix 72 Resolution div dup neg scale 300 310 translate Mtrx currentmatrix pop statusdict begin 1 setpapertray end }def /@landscape { letter initmatrix 72 Resolution div dup neg scale % set scaling to 1. -90 rotate % it would be nice to be able to do this % Mtrx currentmatrix 0 0.0 put % but instead we have to do things like this because what % Mtrx 1 -1.0 put % should be zero terms aren't (and text comes out wobbly) % Mtrx 2 1.0 put % Fie! This likely will not work on QMS printers % Mtrx 3 0.0 put % (nor on others where the device matrix is not like % Mtrx setmatrix % like it is on the LaserWriter). 300 310 translate % move origin to top Mtrx currentmatrix pop } def /@legal { legal initmatrix 72 Resolution div dup neg scale % set scaling to 1. 295 -3880 translate % move origin to top Mtrx currentmatrix pop } def /@manualfeed { statusdict /manualfeed true put } def % n @copies - set number of copies /@copies { /#copies exch def } def /@restore /restore load def /restore {vmstatus pop dup @VMused lt{pop @VMused}if % calculate virtual memory used exch pop exch @restore /@VMused exch def }def /@pri { ( ) print ( ) cvs print }def /@FontMatrix [1 0 0 -1 0 0] def /@FontBBox [0 0 1 1] def %%%%%%%%%%%%%%%%%%%% Procedure Defintions %%%%%%%%%%%%%%%%%%%%%%%%%% /@newfont % id @newfont - -- initialize a new font dictionary { /newname exch def newname 7 dict def % allocate new font dictionary newname load begin /FontType 3 def /FontMatrix @FontMatrix def /FontBBox @FontBBox def /BitMaps 128 array def /BuildChar {CharBuilder} def /Encoding 128 array def 0 1 127 {Encoding exch /.undef put} for end newname newname load definefont pop } def % the following is the only character builder we need. it looks up the % char data in the BitMaps array, and paints the character if possible. % char data -- a bitmap descriptor -- is an array of length 6, of % which the various slots are: /ch-image {ch-data 0 get} def % the hex string image /ch-width {ch-data 1 get} def % the number of pixels across /ch-height {ch-data 2 get} def % the number of pixels tall /ch-xoff {ch-data 3 get} def % number of pixels below origin /ch-yoff {ch-data 4 get} def % number of pixels to left of origin /ch-tfmw {ch-data 5 get} def % spacing to next character /CharBuilder % fontdict ch Charbuilder - -- image one character {save 3 1 roll exch /BitMaps get exch get /ch-data exch def ch-data null ne {ch-tfmw 0 ch-xoff neg ch-yoff neg ch-width ch-xoff sub ch-height ch-yoff sub setcachedevice ch-width ch-height true [1 0 0 1 ch-xoff ch-yoff] {ch-image} imagemask }if restore } def /@sf % fontdict @sf - -- make that the current font { dup % All smallcaps fonts must have the string SmallCaps in their name /FontName known { dup /FontName get tempstring cvs (SmallCaps) search {/smallcaps true def pop pop pop} {/smallcaps false def pop} ifelse } {/smallcaps false def} ifelse setfont } def % in the following, the font-cacheing mechanism requires that % a name unique in the particular font be generated /@dc % char-data ch @dc - -- define a new character bitmap in current font { /ch-code exch def % ++oystr 12-Feb-86++ dup 0 get length 2 lt { pop [ <00> 1 1 0 0 8.00 ] } % replace <> with null if % --oystr 12-Feb-86-- /ch-data exch def currentfont /BitMaps get ch-code ch-data put currentfont /Encoding get ch-code dup ( ) cvs cvn % generate a unique name simply from the character code put } def /@pc % char-data ch @pc - -- print a character bitmap not downloaded {pop /ch-data exch def currentpoint translate ch-width ch-height true [1 0 0 -1 ch-xoff ch-yoff] {ch-image}imagemask }def /@bop0 % n @bop0 - -- begin the char def section of a new page { pop } def /@bop1 % n @bop1 - -- begin a brand new page { pop erasepage initgraphics Mtrx setmatrix /SaveImage save def % % RLW: % The following is a fix necessary since a /@beginspecial immediately % following a /@bop1 failed. This was due to a lack of definition of the % current point, something which can only happen in the one situation. % Suffer the extra code for all other case as new pages don't happen too often. % 0 0 moveto % } def /@eop % - @eop - -- end a page { showpage SaveImage restore } def /@start % - @start - -- start everything { @a4 % (there is not much to do) vmstatus pop /@VMused exch def pop } def /@end % - @end - -- done the whole shebang {(VM used: ) print @VMused @pri (. Unused: ) print vmstatus @VMused sub @pri pop pop (\n) print flush end } def /p % x y p - -- move to position { moveto } def /r % x r - -- move right { 0 rmoveto } def /s % string s - -- show the string { smallcaps {SmallCapShow} {show} ifelse } def /c % ch c - -- show the character (code given) { c-string exch 0 exch put c-string s } def /c-string ( ) def /ru % dx dy ru - -- set a rule (rectangle) { /dy exch neg def % because dy is height up from bottom /dx exch def /x currentpoint /y exch def def % remember current point newpath x y moveto dx 0 rlineto 0 dy rlineto dx neg 0 rlineto closepath fill x y moveto } def /l % x y l - -- draw line to { lineto } def /rl % dx dy rl - -- draw relative line { rlineto } def /rc % x0 y0 x1 y1 y2 y2 rc -- draw bezier curve { rcurveto } def /np % np - -- start a new path and save currenpoint { /SaveX currentpoint /SaveY exch def def % remember current point newpath } def /st % st - -- draw the last path and restore currentpoint { stroke SaveX SaveY moveto % restore the current point } def /f % f -- fill the last path and restore currentpoint { fill SaveX SaveY moveto % restore the current point } def /ellipse % xc yc xrad yrad startAngle endAngle ellipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix matrix currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix } def %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% the \special command junk %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % The structure of the PostScript produced by dvi2ps for \special is: % @beginspecial % - any number of @hsize, @hoffset, @hscale, etc., commands % @setspecial % - the users file of PostScript commands % @endspecial % The @beginspecial command recognizes whether the Macintosh Laserprep % has been loaded or not, and redfines some Mac commands if so. %%% NOTE: This has been disabled as we don't use it !! % The @setspecial handles the users shifting, scaling, clipping commands % The following are user settable options from the \special command. /@SpecialDefaults { /hs 8.5 Inch def /vs 11.68 Inch def /ho 0 def /vo 0 def /hsc 1 def /vsc 1 def /CLIP false def } def % d @hsize - specify a horizontal clipping dimension % these 2 are executed before the MacDraw initializations /@hsize {/hs exch def /CLIP true def} def /@vsize {/vs exch def /CLIP true def} def % d @hoffset - specify a shift for the drwgs /@hoffset {/ho exch def} def /@voffset {/vo exch def} def % s @hscale - set scale factor /@hscale {/hsc exch def} def /@vscale {/vsc exch def} def /@setclipper { hsc vsc scale CLIP { newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto closepath clip } if } def % this will be invoked as the result of a \special command (for the % inclusion of PostScript graphics). The basic idea is to change all % scaling and graphics back to defaults, but to shift the origin % to the current position on the page. Due to TeXnical difficulties, % we only set the y-origin. The x-origin is set at the left edge of % the page. /@beginspecial % - @beginspecial - -- enter special mode { gsave /SpecialSave save def % the following magic incantation establishes the current point as % the users origin, and reverts back to default scalings, rotations currentpoint transform initgraphics itransform translate @SpecialDefaults % setup default offsets, scales, sizes %%% @MacSetUp % fix up Mac stuff -- DISABLED /showpage {} def %%% Ignore showpage commands } def /@setspecial % to setup user specified offsets, scales, sizes (for clipping) { MacDrwgs {md begin /pxt ho def /pyt vo neg def end} {ho vo translate @setclipper} ifelse } def /@endspecial % - @endspecial - -- leave special mode { SpecialSave restore grestore } def %! % All software, documentation, and related files in this distribution of % psfig/tex are Copyright (c) 1987 Trevor J. Darrell % % Permission is granted for use and non-profit distribution of psfig/tex % providing that this notice be clearly maintained, but the right to % distribute any portion of psfig/tex for profit or as part of any commercial % product is specifically reserved for the author. % % % psfigTeX PostScript Prolog % $Header: tex.ps,v 1.13 87/12/14 00:57:00 van Exp $ % /psf$TeXscale { 65536 div } def /DocumentInitState [ matrix currentmatrix currentlinewidth currentlinecap currentlinejoin currentdash currentgray currentmiterlimit ] cvx def % x y bb-llx bb-lly bb-urx bb-ury startFig - /startTexFig { /psf$SavedState save def userdict maxlength dict begin currentpoint transform DocumentInitState setmiterlimit setgray setdash setlinejoin setlinecap setlinewidth setmatrix itransform moveto /psf$ury exch psf$TeXscale def /psf$urx exch psf$TeXscale def /psf$lly exch psf$TeXscale def /psf$llx exch psf$TeXscale def /psf$y exch psf$TeXscale def /psf$x exch psf$TeXscale def currentpoint /psf$cy exch def /psf$cx exch def /psf$sx psf$x psf$urx psf$llx sub div def % scaling for x /psf$sy psf$y psf$ury psf$lly sub div def % scaling for y psf$sx psf$sy scale % scale by (sx,sy) psf$cx psf$sx div psf$llx sub psf$cy psf$sy div psf$ury sub translate /DefFigCTM matrix currentmatrix def /initmatrix { DefFigCTM setmatrix } def /defaultmatrix { DefFigCTM exch copy } def /initgraphics { DocumentInitState setmiterlimit setgray setdash setlinejoin setlinecap setlinewidth setmatrix DefFigCTM setmatrix } def /showpage { initgraphics } def @MacSetUp } def % llx lly urx ury doclip - (args in figure coordinates) /doclip { currentpoint 6 2 roll newpath 4 copy 4 2 roll moveto 6 -1 roll exch lineto exch lineto exch lineto closepath clip newpath moveto } def % - endTexFig - /endTexFig { end psf$SavedState restore } def %%%% Additions by LA Carr to reencode Adobe fonts as TeX fonts (almost) %%%% Based on routine in LaserWriter Cookbook /ReEncodeForTeX { /newfontname exch def /basefontname exch def /TeXstr 30 string def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall %% newfont /FontName newfontname put %% basefontname TeXstr cvs (Dingbat) search { pop pop pop } { pop /TeXvec basefontname TeXstr cvs (Courier) search { pop pop pop TeXcourvec } { pop TeXnormalvec } ifelse def TeXvec aload pop TeXvec length 2 idiv { newfont /Encoding get 3 1 roll put } repeat } ifelse newfontname newfont definefont pop } def /TeXnormalvec [ 8#014 /fi 8#015 /fl 8#020 /dotlessi 8#022 /grave 8#023 /acute 8#024 /caron 8#025 /breve 8#026 /macron 8#027 /ring 8#030 /cedilla 8#031 /germandbls 8#032 /ae 8#033 /oe 8#034 /oslash 8#035 /AE 8#036 /OE 8#037 /Oslash 8#042 /quotedblright 8#074 /exclamdown 8#076 /questiondown 8#134 /quotedblleft 8#136 /circumflex 8#137 /dotaccent 8#173 /endash 8#174 /emdash 8#175 /quotedbl 8#177 /dieresis ] def /TeXcourvec [ 8#016 /exclamdown 8#017 /questiondown 8#020 /dotlessi 8#022 /grave 8#023 /acute 8#024 /caron 8#025 /breve 8#026 /macron 8#027 /ring 8#030 /cedilla 8#031 /germandbls 8#032 /ae 8#033 /oe 8#034 /oslash 8#035 /AE 8#036 /OE 8#037 /Oslash 8#074 /less 8#076 /greater 8#134 /backslash 8#136 /circumflex 8#137 /underscore 8#173 /braceleft 8#174 /bar 8#175 /braceright 8#177 /dieresis ] def /TeXPSmakefont { % defines a routine for generating PS fonts, fudged! /TeXsize exch def findfont [ TeXsize 0 0 TeXsize neg 0 0 ] makefont } def %Create a General Oblique font /ObliqueFont { /ObliqueAngle exch def /ObliqueBaseName exch def /ObliqueFontName exch def /ObliqueTransform [1 0 ObliqueAngle sin ObliqueAngle cos div 1 0 0] def /basefontdict ObliqueBaseName findfont ObliqueTransform makefont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName ObliqueFontName put ObliqueFontName newfont definefont pop } def /Times-Oblique /Times-Roman 15.5 ObliqueFont /Times-BoldOblique /Times-Bold 15 ObliqueFont %/Palatino-Oblique /Palatino-Roman 10 ObliqueFont %/Palatino-BoldOblique /Palatino-Bold 10 ObliqueFont /Times-ItalicUnslanted /Times-Italic -15.15 ObliqueFont %Create a Palatino-ItalicUnslanted font? You must be joking! %Create a General SmallCaps font /SmallCapsFont { /SmallCapsBaseName exch def /SmallCapsFontName exch def /basefontdict SmallCapsBaseName findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName SmallCapsFontName put SmallCapsFontName newfont definefont pop } def /Times-SmallCaps /Times-Roman SmallCapsFont %/Palatino-SmallCaps /Palatino-Roman SmallCapsFont /SmallCapShow { % string smallcaps show /achar (A) def /xfac 0.8 def /yfac 0.8 def /xrec 1 xfac div def /yrec 1 yfac div def { dup dup 8#141 ge exch 8#172 le and { 8#40 sub achar exch 0 exch put achar xfac yfac scale show xrec yrec scale } { achar exch 0 exch put achar show } ifelse } forall } def /tempstring 100 string def % used for string conversions %%%% Additions by LA Carr to reencode Adobe fonts as TeX fonts (almost) %%%% Based on routine in LaserWriter Cookbook /MacDrwgs false def % will get set if we think the Mac LaserPrep file has been loaded % - @MacSetUp - turn-off/fix-up all the MacDraw stuff that might hurt us % we depend on 'psu' being the first procedure executed % by a Mac document. We redefine 'psu' to adjust page % translations, and to do all other the fixups required. % This stuff will not harm other included PS files /@MacSetUp { userdict /md known % if md is defined { userdict /md get type /dicttype eq % and if it is a dictionary { /MacDrwgs true def md begin % then redefine some stuff /psu % redfine psu to set origins, etc. /psu load % this procedure contains almost all the fixup code { /letter {} def % it is bad manners to execute the real /note {} def % versions of these (clears page image, etc.) /legal {} def statusdict /waittimeout 300 put /page {pop} def % no printing of pages /pyt vo neg def % x & y pixel translations /pxt ho def } concatprocs def /od % redefine od to set clipping region /od load { @setclipper } concatprocs def end } if } if } def % p1 p2 concatprocs p - concatenate procedures /concatprocs { /p2 exch cvlit def /p1 exch cvlit def /p p1 length p2 length add array def p 0 p1 putinterval p p1 length p2 putinterval p cvx } def end % revert to previous dictionary statusdict /waittimeout 300 put % Creator: Soren-Aksel Sorensen, Dept Computer Science, UCL % Title: University College London Logo % EndComments /UCL_line { 3 1 roll lineto { rlineto } repeat } def /UCL_mline { 3 1 roll moveto { rlineto } repeat } def /UCL_mcline { 3 1 roll moveto { rlineto } repeat closepath } def /UCL_box { 2 index exch 2 index exch dup 6 index exch moveto 3 { lineto } repeat closepath stroke newpath } def /UCL_leftdome { 216 355 85 180 130 arcn 196 446 175 528 10 arcto 4 { pop } repeat 202 456 8 191 110 arcn 17 20 -6 0 0 30 202 466 3 UCL_line 7 0 0 9 211 518 2 UCL_line stroke newpath } def /UCL_rightdome { 216 355 85 0 50 arc 236 446 257 528 10 arcto 4 { pop } repeat 230 456 8 349 70 arc -17 20 6 0 0 30 230 466 3 UCL_line -7 0 0 9 221 518 2 UCL_line stroke newpath } def /UCL_support { 0 0 432 28 UCL_box 16 42 416 68 UCL_box 2 26 378 0 2 -26 23 261 3 UCL_mline -2 -10 197 -42 197 42 -2 10 19 261 4 UCL_mcline 0 -18 4 -4 0 -26 10 -16 184 0 10 16 0 26 4 4 0 18 110 289 9 UCL_mline 204 0 114 333 1 UCL_mline stroke newpath } def /UCL_domebars { 88 0 172 428 1 UCL_mline 0 75 216 353 1 UCL_mline stroke newpath 301 347 144 177 146 arcn stroke newpath 386 353 200 180 158 arcn stroke newpath 46 353 200 22 0 arcn stroke newpath 131 347 144 34 3 arcn stroke newpath } def /UCL_LargeU { newpath 6 setlinewidth 0 setgray 58 213 moveto 63 213 63 150 9 arcto 4 { pop } repeat 63 123 lineto 63 80 150 80 150 123 curveto 150 209 167 211 9 arcto 4 { pop } repeat 165 211 lineto 165 212 1 270 90 arc 127 213 lineto 127 212 1 90 270 arc 145 209 145 150 9 arcto 4 { pop } repeat 145 128 lineto 145 85 75 85 75 128 curveto 75 209 93 211 9 arcto 4 { pop } repeat 91 211 lineto 91 212 1 270 90 arc closepath gsave fill grestore stroke newpath 58 213 moveto 31 213 lineto 31 212 1 90 270 arc 47 209 47 150 9 arcto 4 { pop } repeat 47 128 lineto 47 80 150 80 150 123 curveto stroke } def /UCL_LargeC { newpath 251 216 moveto 213 216 187 190 187 150 curveto 187 121 209 92 250 92 curveto 271 92 277 98 283 102 curveto 284 108 288 113 288 124 curveto 287 124 1 0 170 arc 281 110 266 96 250 96 curveto 218 96 201 115 201 155 curveto 201 190 218 211 254 211 curveto 266 211 275 205 285 191 curveto 286 191 1 200 0 arc 286 196 285 205 282 210 curveto 268 216 258 216 251 216 curveto closepath gsave fill grestore stroke newpath 251 216 moveto 198 216 172 190 171 150 curveto 171 125 183 92 250 92 curveto stroke newpath } def /UCL_LargeL { 318 213 moveto 339 213 339 150 11 arcto 4 { pop } repeat 339 94 318 94 14 arcto 4 { pop } repeat 401 94 lineto 403 100 404 110 405 121 curveto 404 121 1 0 170 arc 390 98 308 98 42 arcto 4 { pop } repeat 350 98 350 210 12 arcto 4 { pop } repeat 350 209 366 211 11 arcto 4 { pop } repeat 366 211 lineto 366 212 1 270 90 arc closepath gsave fill grestore stroke newpath 318 213 moveto 307 213 lineto 307 212 1 90 270 arc 323 209 323 150 9 arcto 4 { pop } repeat 323 98 307 96 10 arcto 4 { pop } repeat 307 96 lineto 307 95 1 90 270 arc 404 94 lineto stroke newpath } def /UCL_logo { 4 setlinewidth UCL_leftdome UCL_rightdome UCL_domebars UCL_support UCL_LargeU UCL_LargeC UCL_LargeL } def TeXDict begin @start %%Title: strategy.dvi %%Creator: dvi2ps %%EndProlog 0 @bop0 /cmr10.329 @newfont cmr10.329 @sf [ 31 31 -1 0 34] 78 @dc [<03F8000FFE001F87003E03807C0180780000F80000F00000F00000F00000FFFF80FFFF80F00380F007807807807807003C0F 001E1E000FFC0003F000> 17 20 -1 0 20] 101 @dc [<07E00FF01F301E181E181E181E181E181E001E001E001E001E001E001E001E001E001E00FFF8FFF83E001E000E000E000600 060006000600> 13 28 -1 0 18] 116 @dc [<00E01C0000E01C0000F03C0001F03E0001F03E0001F87E0003F87F0003D87B0003D8730003CCF300078CF180078CE1800787 E1800F07E0C00F07C0C00F03C0C01E03C0E01E07C0F0FF9FF3FCFF9FF3FC> 30 20 -1 0 33] 119 @dc [<01F80007FE001E07803C03C03801C07801E07000E0F000F0F000F0F000F0F000F0F000F0F000F07000E07000E03801C03C03 C01E078007FE0001F800> 20 20 -1 0 23] 111 @dc [ 16 20 0 0 18] 114 @dc [ 22 32 0 0 24] 107 @dc [<000600060000000E00070000000F000F0000000F000F0000001F000F8000001F801F8000001F801F8000003F801FC000003E C03EC000003EC03EC000003EC03EC000007C607C6000007C607C6000007C607C600000F830F8300000F830F8300000F830F8 300001F019F0180001F019F0180001F019F0180003E00FF00C0003E00FE00C0003E00FE00C0007C00FE0060007C007C00600 07C007C006000F800FC003000F800F8007001F800F800F80FFF8FFF83FF0FFF8FFF83FF0> 44 31 -1 0 47] 87 @dc [ 11 31 0 0 13] 105 @dc [ 24 20 0 0 25] 110 @dc [<03FC001FFF803E07C07801E0F000F0E00070E00070E00070F000F07803F03FFFE01FFFE03FFF803FFE003800003000003000 0037F0003FFC003E3E003C1E00780F00780F00780F00780F00780F003C1E703E3EF01FFFF007F1E0> 20 30 -1 10 23] 103 @dc [<001FF06000FFFCE001FC1FE007E007E00FC003E01F0003E01F0003E03E0003E07C0003E07C0003E07C0003E0F800FFFCF800 FFFCF8000000F8000000F8000000F8000000F8000000F8000000F80000607C0000607C0000607C0000E03E0000E01F0001E0 1F0001E00F8003E007E00FE001F81EE000FFF860001FE060> 30 31 -3 0 36] 71 @dc [<01F8FF07FEFF0F87F00F03F00F01F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00 F0FF0FF0FF0FF00F00F0> 24 20 0 0 25] 117 @dc [ 22 29 0 9 25] 112 @dc [ 15 31 0 0 16] 73 @dc [<07FFFF0007FFFF00000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F8000000F 8000000F8000000F8000000F8000000F8000000F8000000F8000000F8000C00F8030C00F8030C00F8030C00F8030E00F8070 600F8060600F8060700F80E07C0F81E07FFFFFE07FFFFFE0> 28 31 -2 0 33] 84 @dc [ 28 31 -1 0 31] 69 @dc [ 31 31 -1 0 33] 82 @dc [ 10 3 -1 -9 15] 45 @dc [ 30 31 -1 0 35] 68 @dc [ 31 31 -1 0 34] 65 @dc [ 26 31 -1 0 30] 70 @dc [ 18 31 -3 0 25] 83 @dc [<70F8F8F870> 5 5 -4 0 13] 46 @dc [ 31 31 -1 0 34] 72 @dc [<1F83C03FE7E07C7FF0F81F30F01F30F00F30F00F30F80F007C0F003E0F000FCF0003FF00000F00000F00380F007C1F007C1E 007C7E007FFC001FF000> 20 20 -2 0 23] 97 @dc [<07E3FC1FFBFC3E1FC03C0FC07807C07803C0F003C0F003C0F003C0F003C0F003C0F003C0F003C0F003C07803C07803C03C07 C01E1FC00FFFC007F3C00003C00003C00003C00003C00003C00003C00003C00003C00003C0003FC0003FC00003C0> 22 32 -2 0 25] 100 @dc [<03F00FFC1F0E3E077C037800F800F000F000F000F000F000F000F000781C783E3C3E1E3E0FFE03F8> 16 20 -2 0 20] 99 @dc [ 13 20 -2 0 18] 115 @dc [ 12 32 0 0 13] 108 @dc [ 31 31 -1 0 35] 75 @dc [<000FF000003FFC00007C1E0000F0070001E0038003E0018003C0018007C001C007C000C007C000C007C000C007C000C007C0 00C007C000C007C000C007C000C007C000C007C000C007C000C007C000C007C000C007C000C007C000C007C000C007C000C0 07C000C007C000C007C000C007C001E0FFFE1FFEFFFE1FFE> 31 31 -1 0 34] 85 @dc [<00700000700000700000F80000F80001FC0001EC0001EC0003EE0003C60003C6000783000783000783000F01800F01800F01 C01F03E0FFC7F8FFC7F8> 21 20 -1 0 24] 118 @dc [<3C00007F0000E38000C18000F8C00070C00000600000600000600000700000700000700000F80000F80001FC0001EC0001EC 0003EE0003C60003C6000783000783000783000F01800F01800F01C01F03E0FFC7F8FFC7F8> 21 29 -1 9 24] 121 @dc [<001FE00000FFF80003F83C0007E00E000F8007001F0003801E0001803E0001C07C0000C07C0000C07C0000C0F8000000F800 0000F8000000F8000000F8000000F8000000F8000000F8000000F80000C07C0000C07C0000C07C0001C03E0001C01E0003C0 1F0003C00F8007C007E00FC003F83DC000FFF8C0001FC0C0> 26 31 -3 0 33] 67 @dc [ 24 31 -1 0 28] 76 @dc [<0003800000038000000380000007C0000007C000000FE000000FE000000FE000001FB000001F3000001F3000003E1800003E 1800003E1800007C0C00007C0C0000FC0E0000F8060000F8060001F8030001F0030001F0030003E0018003E0018003E00180 07C000C007C000C00FC000E00FC001F0FFF807FEFFF807FE> 31 31 -1 0 34] 86 @dc [ 17 32 0 0 14] 102 @dc [ 24 32 0 0 25] 104 @dc [<0C3F800E7FC00FE1E00F80F00F80780F00780F003C0F003C0F003C0F003C0F003C0F003C0F003C0F003C0F00780F00780F80 F00FE1F00FFFE00F1F800F00000F00000F00000F00000F00000F00000F00000F00000F0000FF0000FF00000F0000> 22 32 0 0 25] 98 @dc [<60F07038181C0C0C0C7CFCFCF870> 6 14 -4 9 13] 44 @dc [ 27 31 -1 0 32] 66 @dc [ 38 20 0 0 39] 109 @dc [<1FC0003FF00078FC00FC7C00FC3E00FC3E00FC3E00783E00003E00003E00003E00003E00003E00003E00003E00003E00003E 00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E000FFFE00FFFE0> 19 31 -1 0 23] 74 @dc [ 26 31 -1 0 31] 80 @dc [<7FFF7FFF03C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C003C0F3C0 FFC00FC001C000C0> 16 29 -3 0 23] 49 @dc [<0FC0003FF000787C007C1C007C0E007C0F007C07000007800007800003800183C00FF3C01FFBC03C1FC0780FC07007C0F007 C0F003C0F003C0F003C0F003C0F00380F003807007807807003C0F001E1E000FFC0003F000> 18 29 -2 0 23] 57 @dc /cmr10.432 @newfont cmr10.432 @sf [ 40 42 -2 0 45] 65 @dc [ 26 43 -3 1 33] 83 @dc [<007E0001FF0003F38003E18007C1C007C0C007C0C007C0C007C0C007C0C007C0C007C00007C00007C00007C00007C00007C0 0007C00007C00007C00007C00007C00007C00007C000FFFF80FFFF801FC0000FC00007C00003C00001C00001C00001C00000 C00000C00000C00000C000> 18 37 -1 0 23] 116 @dc [ 20 26 -1 0 23] 114 @dc [<07F81F001FFE7F803F8F7FC07E03F860FE01F860FC01F860FC00F860FC00F860FC00F860FE00F8007F00F8003F80F8001FE0 F8000FFCF80001FFF800001FF8000000F8000000F8000000F8001E00F8003F01F8003F01F0003F03F0003F07E0001FFF8000 07FE0000> 27 26 -2 0 30] 97 @dc [<007F0003FFE007F0F00FC0381F00183F001C7E000C7E00007C0000FC0000FC0000FC0000FC0000FC0000FFFFFCFFFFFCFC00 7C7C007C7C007C7E00F83E00F81F01F81F81F007C7E003FFC000FF00> 22 26 -2 0 27] 101 @dc [<00FF800007FFF0001FC1FC003E003E007C001F00F8000F80F0000780F0000780F0000780F0000780F8000F8078001F803E00 7F001FFFFF000FFFFE001FFFF8001FFFE0003E00000038000000380000003800000039FE00001FFF80001F87C0001F03E000 3F03F0003E01F0007E01F8007E01F8007E01F8007E01F8007E01F8007E01F8003E01F0003F03F1801F03E3C00F87F3C007FF FBC001FE3FC000000F80> 26 40 -2 13 30] 103 @dc [ 14 41 0 0 16] 105 @dc [<007F8003FFE007F0F00FC0381F80183F001C7E000C7E00007E0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC00 007C00007E00007E00783F00FC1F00FC0F80FC07E0FC03FFF8007FE0> 22 26 -2 0 27] 99 @dc [ 35 41 -2 0 41] 80 @dc [ 15 42 0 0 16] 108 @dc [ 30 26 -1 0 33] 110 @dc [ 20 42 -1 0 18] 102 @dc [<007F000001FFC00007C1F0000F80F8001F007C003E003E003E003E007C001F007C001F00FC001F80FC001F80FC001F80FC00 1F80FC001F80FC001F80FC001F80FC001F807C001F007C001F003E003E003E003E001E003C000F00780007C1F00001FFC000 007F0000> 25 26 -2 0 30] 111 @dc [<00FE1FF803FF9FF80FC1FF801F80FF001F003F003E003F007E001F007C001F007C001F00FC001F00FC001F00FC001F00FC00 1F00FC001F00FC001F00FC001F00FC001F007C001F007E001F007E001F003E001F001F003F000F807F0007E1FF0003FFDF00 00FF1F0000001F0000001F0000001F0000001F0000001F0000001F0000001F0000001F0000001F0000001F0000001F000000 1F0000003F000003FF000003FF0000001F00> 29 42 -2 0 33] 100 @dc [ 29 38 -1 12 33] 112 @dc [<1F0000003FC0000078E00000FC700000FC300000FC180000FC180000300C0000000C0000000E000000060000000600000007 000000070000000F8000000F8000000F8000001FC000001FC000001FC000003E6000003E6000007E3000007C3000007C3000 00F8180000F8180001F81C0001F00C0001F00C0003E0060003E0060007E0070007C0070007C007800FE00FC0FFF81FF8FFF8 1FF8> 29 38 -1 12 32] 121 @dc [ 18 41 -2 0 22] 73 @dc [ 40 41 -2 0 46] 68 @dc [<0007000000070000000F8000000F8000000F8000001FC000001FC000001FC000003E6000003E6000007E3000007C3000007C 300000F8180000F8180001F81C0001F00C0001F00C0003E0060003E0060007E0070007C0070007C007800FE00FC0FFF81FF8 FFF81FF8> 29 26 -1 0 32] 118 @dc /cmr12.300 @newfont cmr12.300 @sf [ 20 34 -3 0 27] 83 @dc [<01F007F807980F1C0F0C0F0C0F0C0F0C0F0C0F000F000F000F000F000F000F000F000F000F00FFF8FFF83F001F000F000700 070007000300030003000300> 14 31 -1 0 19] 116 @dc [<1F83C03FE7F07C7FB8F81F18F01F18F00F18F00F18F00F00780F007C0F003E0F000FCF0001FF00000F00000F00380F007C0F 007C1F007C3E007FFC001FF000> 21 21 -2 0 24] 97 @dc [<01F8FF07FEFF0787F80F03F00F01F00F01F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00F00 F01F01F0FF0FF0FF0FF00F00F0> 24 21 -1 0 27] 117 @dc [ 14 21 -2 0 19] 115 @dc [<01FC0007FF000F07801C01C03800E07800F0700070F00078F00078F00078F00078F00078F00078F000787000707800F03800 E01C01C00F078007FF0001FC00> 21 21 -1 0 24] 111 @dc [<7FFC007FFC000780000780000780000780000780000780000780000780000780000780000780000780000780000780000780 00078000078000FFF800FFF800078000078000078000078000078000078000078000078000078F8003CF8003EF8001FF8000 FF00003F00> 17 35 0 0 15] 102 @dc [ 24 35 -1 0 27] 104 @dc [ 11 34 0 0 13] 105 @dc [ 40 34 -2 0 45] 77 @dc [<01FC0007FF000F83C03E01C03C00E0780060780000F00000F00000F00000F00000F00000FFFFE0FFFFE07801E07801E03C01 C03E03C01F0F8007FF0001FC00> 19 21 -1 0 22] 101 @dc [ 38 21 -1 0 41] 109 @dc cmr10.329 @sf [<003FFC003FFC0003C00003C00003C00003C00003C00003C00003C007E3C01FFBC03E1FC03C0FC07C07C07803C0F803C0F003 C0F003C0F003C0F003C0F003C0F003C0F803C07803C07C07C03C0FC01F1DC00FF9C007F0C0> 22 29 -2 9 24] 113 @dc [<003FC00000FFF00003E07C0007C03E000F801F001F000F801E0007803E0007C07C0003E07C0003E07C0003E0F80001F0F800 01F0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0780001E07C0003E03C0003C03C0003C01E000780 1E0007800F000F0007801E0003E07C0000FFF000003FC000> 28 31 -3 0 35] 79 @dc [ 31 31 -1 0 34] 88 @dc [<07F0001FFC007C3E00701F00F80F80F80780F807C0F807C0F807C00007C00007C00007C0000780380F803C0F003E1F003FFC 0033F8003000003000003000003000003000003000003FF0003FFC003FFE003FFF00380700> 18 29 -2 0 23] 53 @dc [<03F0000FFC001E1E003C0F00380700780780700380700380F003C0F003C0F003C0F003C0F003C0F003C0F003C0F003C0F003 C0F003C0F003C0F003C0F003C07003807003807807803807003C0F001E1E000FFC0003F000> 18 29 -2 0 23] 48 @dc [<018001C001800180C183E187F18F7DBE1FF803C003C01FF87DBEF18FE187C1830180018001C00180> 16 20 -3 -14 23] 42 @dc [ 23 20 0 0 24] 120 @dc [ 39 31 -1 0 42] 77 @dc [ 24 32 0 0 25] 12 @dc [<00E001E003C0038007000F000E001E001C003C00380038007800780070007000F000F000F000F000F000F000F000F000F000 F000F000F000F000F0007000700078007800380038003C001C001E000E000F000700038003C001E000E0> 11 46 -3 12 18] 40 @dc [ 11 46 -3 12 18] 41 @dc 0 @bop1 cmr10.329 @sf 224 195 p (Net) s 119 c -1 r (ork) s 13 r 87 c -3 r (orking) s 13 r (Group) s 224 252 p (INTERNET-DRAFT) s 1303 195 p (S.E.) s 14 r (Hardcastle-Kille) s 1192 252 p (Univ) s (ersit) s -2 r 121 c 14 r (College) s 14 r (London) s 1573 308 p (V.) s 14 r (Cerf) s 817 364 p (Corp) s 1 r (oration) s 14 r (for) s 14 r (National) s 14 r (Researc) s 104 c 15 r (Initiativ) s -1 r (es) s 1528 421 p (R.) s 15 r (Hobb) s 121 c 1114 477 p (Univ) s (ersit) s -1 r 121 c 13 r (of) s 15 r (California,) s 12 r (Da) s (vis) s 1569 534 p (S.) s 15 r (Ken) s 116 c 1167 590 p (Bolt,) s 14 r (Beranek) s 16 r (and) s 15 r (Newman) s 1502 647 p (J.B.) s 15 r 80 c (ostel) s 1121 703 p (Information) s 13 r (Sciences) s 17 r (Institute) s 1403 760 p (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.432 @sf 531 1151 p 65 c 20 r (Strategic) s 20 r (Plan) s 20 r (for) s 21 r (deplo) s -1 r (ying) s 20 r (an) s 631 1226 p (In) s -1 r (ternet) s 19 r (Directory) s 20 r (Service) s cmr12.300 @sf 224 1675 p (Status) s 17 r (of) s 17 r (this) s 17 r (Memo) s cmr10.329 @sf 224 1751 p (There) s 22 r (are) s 22 r 97 c 21 r 110 c (um) s -1 r 98 c 1 r (er) s 20 r (of) s 22 r (reasons) s 21 r (that) s 21 r 97 c 21 r (new) s 22 r (In) s (ternet) s 21 r (Directory) s 21 r (Service) s 22 r (is) s 224 1808 p (required.) s 28 r (This) s 18 r (do) s 1 r (cumen) s 116 c 16 r (describ) s 1 r (es) s 18 r (an) s 18 r 111 c 118 c (era) s -1 r (ll) s 15 r (strategy) s 17 r (for) s 17 r (deplo) s (ying) s 16 r 97 c 18 r (Di-) s 224 1864 p (rectory) s 16 r (Service) s 16 r (on) s 16 r (the) s 16 r (In) s (ternet,) s 15 r (based) s 16 r (on) s 16 r (the) s 16 r (OSI) s 17 r (X.500) s 15 r (Directory) s 15 r (Service.) s 224 1921 p (It) s 17 r (then) s 16 r (describ) s 1 r (es) s 17 r (in) s 16 r (more) s 15 r (detail) s 16 r (the) s 16 r (initial) s 14 r (steps) s 17 r (whic) s 104 c 15 r (need) s 17 r (to) s 16 r 98 c 1 r 101 c 17 r (tak) s (en) s 15 r (in) s 224 1977 p (order) s 20 r (to) s 19 r (ac) s (hiev) s 101 c 18 r (these) s 20 r (goals,) s 20 r (and) s 20 r (ho) s 119 c 18 r 119 c (ork) s 18 r (already) s 19 r (undertak) s (en) s 20 r 98 c 121 c 19 r (IETF) s 224 2034 p 87 c (Gs) s 13 r (is) s 15 r 119 c (orking) s 13 r (to) s 119 c -1 r (a) s -1 r (rds) s 13 r (these) s 16 r (goals.) s 224 2110 p (****) s 11 r (This) s 12 r (is) s 12 r 97 c 12 r (preliminary) s 10 r (and) s 13 r (draft) s 11 r 118 c (ersion) s 11 r (of) s 12 r (this) s 12 r (do) s 1 r (cumen) s (t.) s 17 r (It) s 12 r (is) s 12 r (exp) s 1 r (ected) s 224 2166 p (to) s 17 r (ev) s (olv) s -1 r 101 c 16 r (substan) s (tiall) s -1 r 121 c 16 r 98 c 1 r (efore) s 18 r (it) s 17 r (is) s 17 r (suitable) s 17 r (for) s 17 r (publication.) s 27 r (Man) s 121 c 16 r (ideas) s 18 r (in) s 224 2223 p (this) s 21 r (do) s 1 r (cumen) s 116 c 20 r (are) s 22 r (op) s 1 r (en,) s 24 r (and) s 22 r (details) s 20 r (remain) s 20 r (to) s 22 r 98 c 1 r 101 c 22 r (\014lled.) s 39 r (Stev) s 101 c 21 r (Ken) s 116 c 21 r (\(a) s 224 2279 p (planned) s 16 r (author\)) s 14 r (has) s 15 r (not) s 15 r 121 c (et) s 14 r (review) s (ed) s 14 r (this) s 14 r (do) s 1 r (cumen) s (t.) s 19 r (****) s 224 2355 p (This) s 10 r (draft) s 10 r (do) s 1 r (cumen) s 116 c 9 r (will) s 10 r 98 c 1 r 101 c 11 r (submitted) s 9 r (to) s 10 r (the) s 11 r (RF) s 67 c 9 r (editor) s 10 r (as) s 10 r (an) s 11 r (informati) s -1 r (onal) s 224 2412 p (do) s 1 r (cumen) s (t.) s 24 r (Distribution) s 16 r (of) s 16 r (this) s 17 r (memo) s 15 r (is) s 16 r (unlimited.) s 25 r (Please) s 16 r (send) s 18 r (commen) s -1 r (ts) s 224 2468 p (to) s 15 r (the) s 15 r (authors.) s @eop 1 @bop0 cmr12.300 @sf [ 15 34 -1 0 18] 73 @dc [ 32 34 -2 0 37] 78 @dc [<03FFFF8003FFFF800007C0000007C0000007C0000007C0000007C0000007C0000007C0000007C0000007C0000007C0000007 C0000007C0000007C0000007C0000007C0000007C0000007C0000007C0000007C0000007C000C007C00CC007C00CC007C00C C007C00CE007C00CE007C01C6007C0186007C0187007C0387C07C0F87FFFFFF87FFFFFF8> 30 34 -2 0 35] 84 @dc [ 29 34 -2 0 33] 69 @dc [ 33 34 -2 0 36] 82 @dc [ 23 2 0 -12 24] 123 @dc [ 31 34 -2 0 37] 68 @dc [ 32 34 -2 0 37] 65 @dc [ 27 34 -2 0 32] 70 @dc [ 24 21 -1 0 27] 110 @dc [ 16 21 -1 0 19] 114 @dc [<03FC000FFF001F87803E01803C01C07800C0780000F00000F00000F00000F00000F00000F00000F000007800007807003C0F 803E0F801F0F800FFF8003FE00> 18 21 -2 0 22] 99 @dc [<3E00007F0000FB8000F9C000F8C000F86000006000007000003000003000003800003800007C00007C00007C0000FE0000F6 0000F60001E30001E30003E38003C18003C18007C0C00780C00780C00F00E00F00701F00F8FFE3FEFFE3FE> 23 31 -1 10 26] 121 @dc [<003800003800007C00007C00007C0000FE0000F60000F60001E30001E30003E38003C18003C18007C0C00780C00780C00F00 E00F00701F00F8FFE3FEFFE3FE> 23 21 -1 0 26] 118 @dc [ 23 31 -1 10 27] 112 @dc [<0C3F800E7FE00FE1F00F80F80F807C0F003C0F003C0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001C0F003C0F00 3C0F80780FE1F00FFFE00F1F800F00000F00000F00000F00000F00000F00000F00000F00000F00000F00001F0000FF0000FF 00000F0000> 23 35 -1 0 27] 98 @dc [ 16 32 -4 0 24] 49 @dc [<0FE0001FF800387C00701E007C0F007C07007C07807C03800003C00003C00001C00081E00FF1E01FF9E03C0DE03807E07803 E07003E0F003E0F001E0F001E0F001E0F001E0F001C0F001C0F003C07803807807803C07001F1F000FFE0003F800> 19 32 -2 0 24] 57 @dc /cmbx10.432 @newfont cmbx10.432 @sf [<00007FF800000007FFFF0000001FFFFFC000007FF807F00000FFC000F80003FF00007C0007FE00001E000FFC00000F000FF8 000007001FF0000007803FF0000003803FE0000003807FE0000003807FE0000003807FC000000000FFC000000000FFC00000 0000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000FFC000000000 FFC0000000007FC0000007807FE0000007807FE0000007803FE000000F803FF000000F801FF000001F800FF800001F800FFC 00003F8007FE00007F8003FF0000FF8000FFC003FF80007FF80FFF80001FFFFF8F800007FFFE078000007FF00380> 41 41 -4 0 50] 67 @dc [<003FE00001FFFC0007FFFF000FF07F801FC01FC03F800FE03F800FE07F0007F07F0007F0FF0007F8FF0007F8FF0007F8FF00 07F8FF0007F8FF0007F8FF0007F8FF0007F87F0007F07F0007F07F0007F03F800FE03F800FE01FC01FC00FF07F8003FFFE00 01FFFC00003FE000> 29 27 -2 0 34] 111 @dc [ 33 27 -3 0 38] 110 @dc [<003F8000FFE001FFF003F8F007F87807F03807F03807F03807F03807F03807F03807F00007F00007F00007F00007F00007F0 0007F00007F00007F00007F00007F00007F00007F000FFFFF0FFFFF0FFFFF01FF00007F00003F00001F00001F00000F00000 F000007000007000007000007000> 21 38 -1 0 27] 116 @dc [<003FF00001FFFE0003FFFF800FFC0FC01FF003C03FC001E03F8000E07F8000007F800000FF000000FF000000FF000000FF00 0000FFFFFFE0FFFFFFE0FFFFFFE0FF0007E0FF0007E07F0007E07F800FC03F800FC03FC01FC01FC03F800FF07F0007FFFE00 01FFFC00003FE000> 27 27 -2 0 32] 101 @dc [ 22 27 -2 0 27] 115 @dc /cmbx10.329 @newfont cmbx10.329 @sf [ 17 29 -4 0 26] 49 @dc [ 36 31 -2 0 39] 82 @dc [<01FF8007FFE01FC1F03F00783E00387E00007C0000FC0000FC0000FC0000FFFFF8FFFFF8FC00F8FC00F87E00F87E00F03F01 F01F87E007FFC001FF00> 21 20 -1 0 24] 101 @dc [<0007FF800007FF800007FF800000FC000000FC000000FC000000FC000000FC000000FC0003F8FC000FFFFC001F87FC003F03 FC007E01FC007E00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FE00FC007E00FC007E01FC00 3F03FC001FC7FC000FFF3C0003FC1C00> 25 29 -2 9 28] 113 @dc [<03FE7FC00FFF7FC00FC3FFC01F81FE001F80FE001F807E001F807E001F807E001F807E001F807E001F807E001F807E001F80 7E001F807E001F807E001F807E001F807E00FF83FE00FF83FE00FF83FE00> 26 20 -2 0 29] 117 @dc [ 12 33 -2 0 15] 105 @dc [ 19 20 -1 0 22] 114 @dc [ 42 20 -2 0 47] 109 @dc [ 26 20 -2 0 29] 110 @dc [<03F00FFC0FDC1F8E1F8E1F8E1F8E1F8E1F801F801F801F801F801F801F801F801F80FFFCFFFC3FFC1F800F80078007800780 0380038003800380> 15 29 -1 0 20] 116 @dc [ 16 20 -2 0 21] 115 @dc [ 19 29 -3 0 26] 50 @dc [ 22 31 -3 0 29] 83 @dc [<0FF0FE3FFDFE7E1FFEFC07F0F803F0F803F0F803F0FC03F07E03F03FC3F00FFFF001FFF00003F01E03F03F03F03F03F03F07 E03F0FE01FFF8007FE00> 23 20 -1 0 25] 97 @dc [<1F0000007F800000F1E00000E0E00000FC700000FC7800007838000000380000001C0000001C0000003E0000003E0000007F 0000007F000000FF800000FF800000FF800001F9C00001F9C00003F9E00003F0E00007F0F00007E0700007E070000FC03800 0FC03800FFF0FF80FFF0FF80FFF0FF80> 25 29 -1 9 28] 121 @dc [<01FF0007FFC01F83F03E00F83E00F87C007C7C007CFC007EFC007EFC007EFC007EFC007EFC007E7C007C7C007C3E00F83E00 F81F83F007FFC001FF00> 23 20 -1 0 26] 111 @dc [<7FFC007FFC007FFC000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0 00FFFC00FFFC00FFFC000FC0000FC0000FC0000FC0000FC0000FC3C00FC7E00FE7E007E7E003F7E001FFC0003F80> 19 32 -1 0 16] 102 @dc [ 12 32 -2 0 15] 108 @dc [<07FC001FFF807FFFC07C1FE0FE0FF0FE07F0FE07F8FE07F8FE07F87C07F80007F80007F80007F0000FE0001FC001FE0001FE 00003F80001FC0001FC01F0FE03F0FE03F8FE03F0FE03F0FE01F1FC01FFFC00FFF0003FC00> 21 29 -2 0 26] 51 @dc [ 17 31 -1 0 20] 73 @dc [ 28 31 -2 0 33] 70 @dc [<007803C000007803C00000FC07E00000FC07E00000FC07E00001FE0FF00001FE0FF00001FE0FF00003F71FB80003F71F3800 07F7BF3C0007E3BE1C0007E3BE1C000FE3FE1E000FC1FC0E000FC1FC0E001F80FC0700FFE7FF3FE0FFE7FF3FE0FFE7FF3FE0> 35 20 -1 0 38] 119 @dc [ 25 32 -1 0 28] 107 @dc cmr10.329 @sf [<07F0003FFC007C3F00F81F00FC0F80FC07C0FC07C0FC07C07807C00007C00007C0000780000F80001F00003E0003F00003F8 00007E00001F00000F00000F807C0F807C0F807E0F807C0F807C0F003C3F001FFE0007F000> 18 29 -2 0 23] 51 @dc /cmmi10.329 @newfont cmmi10.329 @sf [<70F8F8F870> 5 5 -4 0 13] 58 @dc cmr10.329 @sf [ 18 29 -2 0 23] 50 @dc cmbx10.329 @sf [<01FFFE01FFFE01FFFE000FC0000FC0000FC0000FC0000FC0FFFFFEFFFFFEFFFFFEF007C07007C03807C01C07C00E07C00707 C00707C00387C001C7C000E7C00077C0003FC0003FC0001FC0000FC00007C00003C00003C0> 23 29 -1 0 26] 52 @dc [ 35 31 -2 0 40] 65 @dc [<03FE000FFF801FC3C03F01E07E00E07E0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC07807C0FC07E0FC03F0F C01F8FC00FFF8003FE00> 19 20 -2 0 23] 99 @dc [ 45 31 -2 0 50] 77 @dc [ 26 32 -2 0 29] 104 @dc cmr10.329 @sf [<01FFE001FFE0001E00001E00001E00001E00001E00001E00FFFFF0FFFFF0E01E00601E00301E00381E00181E000C1E000E1E 00061E00031E00039E00019E0000DE0000FE00007E00003E00003E00001E00000E00000E00> 20 29 -1 0 23] 52 @dc cmbx10.329 @sf [<0FF0001FFE003FFF007C3F80FC1FC0FC0FC0FC0FE0FC0FE0FC0FE07C0FE0000FE0000FE0000FE0300FC0381FC03E3F803FFF 003BF8003800003800003800003800003FE0003FF8003FFE003FFF003FFF803FFF80380380> 19 29 -3 0 26] 53 @dc [ 36 31 -2 0 41] 78 @dc [<03FF801FFFF03F83F87E00FCFC007EF8003EF8003EF8007E7C00FE7FFFFE1FFFFC1FFFF81FFFF03FFFC03E00003C00003800 001FFE001FFF801F8FC01F07C03E03E03E03E03E03E03E03E03E03FC1F07DE1F8FFE0FFFFE03FE7C> 23 30 -1 10 26] 103 @dc [<01FE0007FF801FFFC01F87E03F03F07E03F07E03F87E03F8FE03F8FE03F8FE03F8FE03F8FE03F8FF03F0FF03F0FF87E0FFFF C0FEFF80FE10007E00007E01E07F03F03F03F03F03F01F83F00FE1F007FFE001FFC0007F80> 21 29 -2 0 26] 54 @dc [ 35 31 -2 0 40] 88 @dc [<3C7EFFFFFFFF7E3C> 8 8 -3 0 15] 46 @dc [<01FC0007FF001F8FC01E03C03E03E07C01F07C01F07C01F0FC01F8FC01F8FC01F8FC01F8FC01F8FC01F8FC01F8FC01F8FC01 F8FC01F8FC01F8FC01F8FC01F87C01F07C01F07C01F03E03E01E03C01F07C007FF0001FC00> 21 29 -2 0 26] 48 @dc [ 34 31 -2 0 40] 68 @dc [ 25 29 -1 9 29] 112 @dc cmr10.329 @sf [<03F8000FFC001E1E003C0F003807807803807803C07003C0F003C0F003C0F003C0F003C0F803C0F80380FC0780FE0F00F7FE 00F3FC00F06000700000780000780000380F803C0F801E0F800F0F8007878003FF0000FE00> 18 29 -2 0 23] 54 @dc [<03800007C00007C00007C00007C00007C00007C00007C00007C00003C00003C00003C00003C00001C00001E00000E00000E0 00006000007000003800001800C01C00C00E00C00600E007007FFF807FFFC07FFFC07FFFC0600000> 18 30 -3 0 23] 55 @dc [<07F0001FFC003E1F00780780700380F001C0E001C0E001C0E003C0E007C0F00FC0781FC03C7F801FFF000FFF000FFC001FF8 003FFE003FCF007F07007C0780780380700380700380700780380F001E1F000FFE0003F800> 18 29 -2 0 23] 56 @dc cmbx10.329 @sf [<01E00003F00003F00003F00003F00003F00003F00003F00003F00001F00001F00001F00001F00000F80000F8000078000078 00003C00003C00E01E00E00F00E00780F003C0FFFFC07FFFE07FFFF07FFFF87FFFF87FFFF8700000> 21 30 -3 0 26] 55 @dc [<07F0001FFE003FFF007C3F807E0FC07E07E07E07E07E03F03C03F00003F00043F80FFBF81FFFF83F0FF87E07F87E07F8FE03 F8FE03F8FE03F8FE03F8FE03F8FE03F0FE03F07E03F07E07E03F8FE01FFFC00FFF0003FC00> 21 29 -2 0 26] 57 @dc [<03FE001FFF803FFFE07F07E07E01F0FC00F8F800F8F800F8F801F8F803F8FC0FF87C3FF87E7FF01FFFF00FFFE00FFFC01FFF 801FFF803FFFC03FE3E03F81E03F01E03C01E03C01E01E03E01F07C00FFFC007FF8001FE00> 21 29 -2 0 26] 56 @dc [ 30 31 -2 0 34] 69 @dc [ 25 20 -1 0 28] 120 @dc [<000FFC00007FFF8001FFFFE003FF03F00FF800F81FE0003C1FC0003C3FC0001E7F80000E7F80000E7F00000EFF000000FF00 0000FF000000FF000000FF000000FF000000FF000000FF000000FF00000E7F00000E7F80001E7F80001E3FC0003E1FC0003E 1FE0007E0FF800FE03FF03FE01FFFFFE007FFF9E000FFC06> 31 31 -3 0 38] 67 @dc [<03FCFF800FFFFF801F87FF803E01FC007E00FC007C00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00FC00 FC00FC00FC007C00FC007E00FC003F01FC001F87FC000FFFFC0003FCFC000000FC000000FC000000FC000000FC000000FC00 0000FC000000FC000000FC000000FC000007FC000007FC000007FC00> 25 32 -2 0 29] 100 @dc [<300038001C000E00070007000300038001803D807F80FF80FF80FF80FF007F003C00> 9 17 -3 -15 15] 39 @dc cmr12.300 @sf [ 32 34 -2 0 37] 72 @dc [<03F1FE0FFDFE1F0FF03C07E07803E07801E07001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E07801E07801E07C01 E03E03E01F0FE00FFFE003F9E00001E00001E00001E00001E00001E00001E00001E00001E00001E00001E00003E0001FE000 1FE00001E0> 23 35 -2 0 27] 100 @dc [ 12 35 0 0 13] 108 @dc [ 11 3 -1 -9 16] 45 @dc [ 33 34 -2 0 38] 75 @dc [ 27 34 -2 0 33] 80 @dc [<03FE000FFF803F07E07C01F0F00078F00078E00038E00038E000787000787C01F81FFFF00FFFE01FFFC01FFF001C00001800 001800001BF8001FFC001F1F001E0F003C07803C07803C07803C07803C07803C07801E0F381F1F7807FFF803F8F0> 21 32 -1 11 24] 103 @dc 1 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmbx10.432 @sf 224 195 p (Con) s -1 r (ten) s -1 r (ts) s cmbx10.329 @sf 224 317 p 49 c 42 r (Requirem) s -2 r (en) s -2 r (ts) s 1082 r 50 c 224 438 p 50 c 42 r (Sum) s -1 r (m) s -3 r (ar) s -1 r 121 c 15 r (of) s 18 r (Solution) s 914 r 50 c 224 560 p 51 c 42 r (Inform) s -2 r (ation) s 16 r 70 c -3 r (ram) s -3 r (ew) s -1 r (or) s -1 r 107 c 854 r 50 c cmr10.329 @sf 292 636 p (3.1) s 46 r (Short) s 15 r 84 c -3 r (erm) s cmmi10.329 @sf 32 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 50 c 292 712 p (3.2) s 46 r (Longer) s 15 r 84 c -3 r (erm) s cmmi10.329 @sf 39 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 51 c cmbx10.329 @sf 224 833 p 52 c 42 r (Access) s 17 r (Mec) s (hanism) s -4 r 115 c 951 r 52 c cmr10.329 @sf 292 909 p (4.1) s 46 r (Short) s 15 r 84 c -3 r (erm) s cmmi10.329 @sf 32 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 52 c 292 985 p (4.2) s 46 r (Longer) s 15 r 84 c -3 r (erm) s cmmi10.329 @sf 39 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 52 c cmbx10.329 @sf 224 1107 p 53 c 42 r (Nam) s -1 r 101 c 16 r (Assignm) s -3 r (en) s -2 r 116 c 981 r 52 c 224 1228 p 54 c 42 r (X.500) s 17 r (Deplo) s (ym) s -3 r (en) s -2 r 116 c 973 r 53 c cmr10.329 @sf 292 1304 p (6.1) s 46 r 84 c -3 r (ec) s (hnical) s 13 r (Issues) s cmmi10.329 @sf 16 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 53 c 397 1380 p (6.1.1) s 50 r (Sc) s (hema) s cmmi10.329 @sf 36 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 54 c 397 1456 p (6.1.2) s 50 r (Use) s 16 r (on) s 15 r (the) s 15 r (In) s (ternet) s cmmi10.329 @sf 12 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 54 c 397 1532 p (6.1.3) s 50 r (Replication) s 15 r (of) s 15 r (Kno) s (wledge) s 14 r (and) s 15 r (Data) s cmmi10.329 @sf 43 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 55 c 397 1608 p (6.1.4) s 50 r (Presen) s (tation) s 13 r (of) s 15 r (Directory) s 14 r (Names) s cmmi10.329 @sf 29 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 55 c 397 1684 p (6.1.5) s 50 r (DSA) s 16 r (Naming) s 13 r (and) s 15 r (MD) s 15 r (Structure) s cmmi10.329 @sf 36 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 56 c 292 1760 p (6.2) s 46 r (Infrastructure) s cmmi10.329 @sf 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 56 c 397 1836 p (6.2.1) s 50 r (Implemen) s (t) s -1 r (ati) s -1 r (ons) s cmmi10.329 @sf 32 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 56 c 397 1912 p (6.2.2) s 50 r (Cen) s (tral) s 13 r (Op) s 1 r (erations) s cmmi10.329 @sf 19 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 56 c 397 1988 p (6.2.3) s 50 r (Site) s 15 r (Supp) s 1 r (ort) s cmmi10.329 @sf 44 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 57 c cmbx10.329 @sf 224 2110 p 55 c 42 r (Securit) s 121 c 1210 r 57 c cmr10.329 @sf 292 2186 p (7.1) s 46 r (Directory) s 14 r (Pro) s (visi) s -1 r (on) s 13 r (of) s 15 r (Authen) s (tication) s cmmi10.329 @sf 38 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 69 r 57 c 292 2262 p (7.2) s 46 r (Directory) s 14 r (Securit) s 121 c cmmi10.329 @sf 38 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 23 r 58 c 22 r 58 c 22 r 58 c cmr10.329 @sf 46 r (10) s cmbx10.329 @sf 224 2383 p 56 c 42 r (Relation) s 18 r (to) s 18 r (DNS) s 989 r (11) s 224 2505 p 57 c 42 r (External) s 17 r (Connections) s 880 r (11) s 224 2626 p (10) s 16 r (Securit) s 121 c 16 r (Considerations) s 828 r (13) s 224 2748 p (11) s 16 r (Authors') s 16 r (Addresses) s 925 r (13) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 49 c @eop 2 @bop0 cmbx10.432 @sf [<7FFFFE7FFFFE7FFFFE00FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF 0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF00F8FF00FF FF00FFFF0007FF00007F00000F00000700> 23 39 -5 0 34] 49 @dc [ 48 41 -3 0 52] 82 @dc [<00003FFF8000003FFF8000003FFF80000003F800000003F800000003F800000003F800000003F800000003F800000003F800 000003F800000003F800007FC3F80001FFF3F80007FFFBF8000FF87FF8001FE01FF8003FC00FF8003FC007F8007F8003F800 7F8003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF8003F800 7F8003F8007F8003F8003FC007F8003FC00FF8001FE01FF8000FF83CF80007FFF8F80001FFF07800003FC03800> 33 39 -2 12 36] 113 @dc [<007FC3FF8001FFF3FF8007FFFBFF8007F03FF8000FE00FF8000FE007F8000FE007F8000FE003F8000FE003F8000FE003F800 0FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F800 0FE003F8000FE003F8000FE003F8000FE003F800FFE03FF800FFE03FF800FFE03FF800> 33 27 -3 0 38] 117 @dc [ 15 43 -3 0 20] 105 @dc [ 24 27 -2 0 28] 114 @dc [ 53 27 -3 0 60] 109 @dc cmr10.329 @sf [<70F8F8F8700000000000000000000070F8F8F870> 5 20 -4 0 13] 58 @dc /cmsy10.329 @newfont cmsy10.329 @sf [<07E01FF83FFC7FFE7FFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7FFE7FFE3FFC1FF807E0> 16 18 -3 -2 23] 15 @dc cmr10.329 @sf [ 7 45 -4 11 13] 91 @dc [ 7 45 -1 11 13] 93 @dc cmbx10.329 @sf [ 25 2 0 -11 26] 123 @dc cmbx10.432 @sf [ 27 39 -3 0 34] 50 @dc [ 29 41 -4 0 38] 83 @dc [<03FC07FC0FFF0FFC3FFFDFFC7FC3FFC07F00FF80FF007F80FE003F80FE003F80FE003F80FF003F807F003F803F803F801FE0 3F800FFE3F8003FFFF80003FFF8000003F8000003F801F803F803FC03F803FC03F803FC07F003FC0FF003FC1FE001FFFFC00 0FFFF00003FFC000> 30 27 -2 0 33] 97 @dc [<0F800000003FE00000007FF8000000F67C000000FE1C000000FE0E000000FE0F0000007C0700000038078000000003800000 00038000000001C000000001C000000003E000000003E000000007F000000007F00000000FF80000000FF80000000FF80000 001FDC0000001FDC0000003FDE0000003F8E0000007F8F0000007F070000007F07000000FE03800000FE03800001FC01C000 01FC01C00003FC01E00003F800E00007F800F00007F000700007F0007000FFFE03FF80FFFE03FF80FFFE03FF80> 33 39 -1 12 36] 121 @dc [<7FFF80007FFF80007FFF800007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0 000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F00000FFFFC000 FFFFC000FFFFC00007F0000007F0000007F0000007F0000007F0000007F0000007F03F0007F07F8007F87F8003F87F8003FC 7F8001FF7F80007FFF00003FFE000007FC00> 25 42 -2 0 21] 102 @dc [ 15 42 -3 0 20] 108 @dc cmr10.329 @sf [ 24 32 0 0 25] 13 @dc cmbx10.432 @sf [<00FFC00007FFF8001FFFFC003F83FF007F01FF807F80FF80FFC0FFC0FFC07FC0FFC07FE0FFC07FE0FFC07FE07F807FE07F80 7FE01E007FE000007FE000007FC00000FFC00000FF800001FF000003FE0000FFF80000FFC00000FFF0000007F8000003FC00 0001FE000F81FF001FC0FF003FE0FF803FE0FF803FE0FF803FE0FF803FE0FF803FC0FF801F81FF000FC3FE0007FFFC0003FF F80000FFC000> 27 39 -3 0 34] 51 @dc [ 23 41 -1 0 26] 73 @dc [ 36 41 -3 0 43] 70 @dc [<00078003C00000078003C000000FC007E000000FC007E000000FC007E000001FE00FF000001FE00FF000003FF01FF800003F F01FB800003FF01FB800007F783F3C00007F383F1C0000FF383F1E0000FE1C7E0E0000FE1C7E0E0001FE1EFC0F0001FC0EFC 070001FC0EFC070003F807F8038003F807F8038007F807F803C007F003F001C007F003F001C00FE007E000E0FFFE7FFC0FFE FFFE7FFC0FFEFFFE7FFC0FFE> 47 27 -1 0 50] 119 @dc [ 31 42 -2 0 36] 107 @dc /cmbx12.300 @newfont cmbx12.300 @sf [<03FF001FFFC03FFFF07E07F8FE03FCFE03FCFE01FEFE01FEFE01FE7C01FE0001FE0001FE0001FC0003FC0003F8000FE001FF 0001FF00001FC0000FE00007F00007F00E07F83F03F83F03F83F83F83F07F83F07F81F0FF01FFFE007FFC001FE00> 23 32 -2 0 28] 51 @dc [<3C7EFFFFFFFF7E3C> 8 8 -4 0 16] 46 @dc [<7FFFE07FFFE07FFFE001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F8 0001F80001F80001F80001F80001F80001F80001F80001F80001F800FDF800FFF800FFF80003F800007800001800> 19 32 -4 0 28] 49 @dc [ 24 34 -3 0 31] 83 @dc [ 26 35 -2 0 31] 104 @dc [<00FE0007FFC00F83E01F01F03F01F87E00FC7E00FCFE00FEFE00FEFE00FEFE00FEFE00FEFE00FEFE00FE7E00FC7E00FC7E00 FC3E00F81F01F00F83E007FFC000FE00> 23 22 -2 0 28] 111 @dc [ 19 22 -2 0 23] 114 @dc [<01FC0003FE0007E7000FC7800FC3800FC3800FC3800FC3800FC3800FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0 000FC0000FC000FFFF00FFFF003FFF000FC00007C00007C00003C00003C00003C00001C00001C00001C00001C000> 17 32 -1 0 22] 116 @dc [<03FFFFF80003FFFFF80003FFFFF8000003F800000003F800000003F800000003F800000003F800000003F800000003F80000 0003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F80000 0003F80000E003F801C0E003F801C0E003F801C0E003F801C0F003F803C0F003F803C07003F803807803F807807C03F80780 7E03F81F807FFFFFFF807FFFFFFF807FFFFFFF80> 34 34 -2 0 39] 84 @dc [<00FF8007FFE00FE1F01F80783F00387F00007E0000FE0000FE0000FE0000FE0000FFFFF8FFFFF8FE01F8FE01F87E01F87E01 F03F03F03F03E01FC7E007FF8001FE00> 21 22 -2 0 26] 101 @dc [ 42 22 -2 0 47] 109 @dc cmr10.329 @sf [ 30 32 0 0 27] 11 @dc cmr12.300 @sf [ 19 32 -2 0 24] 50 @dc 2 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmbx10.432 @sf 224 195 p 49 c 69 r (Requirem) s -2 r (e) s -1 r 110 c -1 r (ts) s cmr10.329 @sf 224 316 p (There) s 16 r (is) s 15 r (substan) s (tial) s 13 r (in) s (terest) s 14 r (in) s 16 r (establishing) s 14 r 97 c 15 r (new) s 16 r (Directory) s 15 r (Service) s 16 r (on) s 15 r (the) s 224 373 p (In) s (ternet.) s 18 r (In) s 13 r (the) s 13 r (short) s 12 r (term,) s 11 r (there) s 12 r (is) s 12 r (pressure) s 13 r (to) s 12 r (establish) s 11 r 97 c 12 r 116 c 119 c -1 r 111 c 10 r (new) s 13 r (services:) s cmsy10.329 @sf 292 476 p 15 c cmr10.329 @sf 23 r (White) s 14 r 80 c (ages) s 14 r (lo) s 1 r (okup) s 15 r (of) s 15 r (users.) s cmsy10.329 @sf 292 563 p 15 c cmr10.329 @sf 23 r (Supp) s 1 r (ort) s 16 r (for) s 16 r (X.509) s 15 r (Authen) s (tication) s 14 r (for) s 16 r 97 c 15 r (range) s 16 r (of) s 16 r (applications,) s 15 r (in) s 16 r (par-) s 338 619 p (ticular) s 14 r (for) s 14 r (Priv) s -2 r (acy) s 14 r (Enhanced) s 17 r (Mail) s 13 r 91 c (Lin89) s (].) s 224 722 p (In) s 14 r (the) s 14 r (medium) s 12 r (term,) s 12 r (there) s 14 r (are) s 13 r (lik) s (ely) s 12 r (to) s 13 r 98 c 1 r 101 c 14 r (man) s 121 c 11 r (requiremen) s (ts) s 12 r (for) s 13 r (Directory) s 224 779 p (Services,) s 15 r (including:) s cmsy10.329 @sf 292 882 p 15 c cmr10.329 @sf 23 r (General) s 9 r (resource) s 11 r (lo) s 1 r (okup,) s 10 r (for) s 10 r (informat) s -1 r (ion) s 8 r (ranging) s 9 r (from) s 9 r (comm) s -1 r (itt) s -1 r (ee) s 9 r (struc-) s 338 938 p (tures) s 15 r (to) s 14 r (bibliographic) s 14 r (data.) s cmsy10.329 @sf 292 1025 p 15 c cmr10.329 @sf 23 r (Supp) s 1 r (ort) s 13 r (of) s 13 r (managem) s -1 r (en) s -1 r 116 c 11 r (of) s 12 r (the) s 13 r (in) s (ternet) s 11 r (infrastructure,) s 12 r (and) s 13 r (in) s (tegratio) s -1 r 110 c 338 1082 p (of) s 15 r (con\014guration) s 14 r (informati) s -1 r (on) s 13 r (in) s (to) s 13 r (the) s 16 r (higher) s 15 r (lev) s (el) s 13 r (directory) s -3 r 46 c cmsy10.329 @sf 292 1169 p 15 c cmr10.329 @sf 23 r (Supp) s 1 r (ort) s 15 r (of) s 15 r (Applications) s 14 r (on) s 15 r (the) s 16 r (In) s (ternet.) s 19 r 70 c -3 r (or) s 13 r (example:) s cmbx10.329 @sf 389 1256 p 123 c cmr10.329 @sf 23 r (Electronic) s 14 r (distribution) s 14 r (lists) s cmbx10.329 @sf 389 1323 p 123 c cmr10.329 @sf 23 r (Capabilit) s -1 r 121 c 13 r (informati) s -1 r (on) s 13 r (for) s 15 r (adv) s -2 r (anced) s 15 r (user) s 15 r (agen) s (ts) s cmbx10.329 @sf 389 1390 p 123 c cmr10.329 @sf 23 r (Lo) s 1 r (cation) s 15 r (of) s 14 r (\014les) s 15 r (and) s 16 r (arc) s (hiv) s -1 r 101 c 13 r (services) s cmbx10.432 @sf 224 1549 p 50 c 69 r (Summ) s -3 r (ary) s 22 r (of) s 23 r (Solution) s cmr10.329 @sf 224 1670 p (In) s 18 r (principle,) s 17 r (the) s 18 r (curren) s 116 c 16 r (Domai) s -1 r 110 c 16 r (Name) s 16 r (System) s 16 r (could) s 18 r 98 c 1 r 101 c 18 r (used) s 17 r (for) s 17 r (man) s 121 c 15 r (of) s 224 1727 p (these) s 16 r (functions,) s 16 r (with) s 15 r (appropriate) s 15 r (extensions.) s 22 r (Ho) s 119 c -1 r (ev) s -1 r (er,) s 14 r (it) s 15 r (is) s 15 r (suggested) s 16 r (that) s 224 1783 p 97 c 17 r (higher) s 17 r (lev) s (el) s 15 r (of) s 16 r (directory) s 17 r (service) s 16 r (is) s 17 r (needed.) s 26 r (It) s 17 r (is) s 17 r (prop) s 1 r (osed) s 17 r (to) s 16 r (establish) s 17 r (an) s 224 1840 p (In) s (ternet) s 14 r (Directory) s 13 r (Service) s 15 r (based) s 15 r (on) s 15 r (X.500.) s 19 r (This) s 14 r (pro) s (vides) s 13 r (appropriate) s 14 r (func-) s 224 1896 p (tionalit) s -1 r 121 c 11 r (for) s 12 r (the) s 13 r (services) s 13 r (en) s (visaged,) s 11 r (and) s 13 r (giv) s (es) s 11 r (\015exibilit) s 121 c 11 r (for) s 12 r (future) s 13 r (extension.) s 224 1953 p (This) s 13 r (extension) s 12 r (could) s 13 r 98 c 1 r 101 c 14 r (ac) s (hiev) s -1 r (ed) s 12 r (either) s 12 r 98 c 121 c 12 r (trac) s (king) s 10 r (the) s 13 r (ev) s (olution) s 11 r (of) s 13 r (the) s 12 r (OSI) s 224 2009 p (Standard) s 15 r (or) s 14 r 98 c 121 c 13 r 119 c (ork) s 13 r (sp) s 1 r (eci\014c) s 15 r (to) s 14 r (the) s 15 r (In) s (ternet.) s 18 r (In) s 16 r (practice,) s 14 r (it) s 13 r (is) s 14 r (lik) s (ely) s 13 r (to) s 14 r 98 c 1 r 101 c 15 r 97 c 224 2065 p (mixture) s 14 r (of) s 14 r 98 c 1 r (oth.) s cmbx10.432 @sf 224 2225 p 51 c 69 r (Information) s 21 r 70 c -5 r (rame) s -1 r 119 c -2 r (ork) s cmbx12.300 @sf 224 2348 p (3.1) s 56 r (Short) s 18 r 84 c -4 r (erm) s cmr10.329 @sf 224 2453 p (The) s 11 r (most) s 8 r (critical) s 9 r (asp) s 1 r (ect) s 11 r (of) s 10 r (the) s 10 r (direction) s 10 r (is) s 10 r (to) s 9 r (establish) s 10 r 97 c 10 r (In) s (ternet) s 10 r (Informatio) s -1 r 110 c 224 2510 p 70 c -3 r (ram) s -1 r (ew) s -1 r (ork.) s 17 r (When) s 16 r (establishing) s 13 r 97 c 15 r (sophisticated) s 13 r (distributed) s 15 r (directory) s 14 r (with) s 14 r 97 c 224 2566 p (coheren) s 116 c 16 r (informati) s -1 r (on) s 15 r (framew) s -1 r (ork,) s 15 r (it) s 16 r (in) s 118 c -1 r (ol) s -1 r 118 c -1 r (es) s 15 r (substan) s (tial) s 14 r (e\013ort) s 16 r (to) s 16 r (map) s 16 r (data) s 224 2623 p (on) s (to) s 20 r (this) s 21 r (framew) s -1 r (o) s -1 r (rk.) s 37 r (This) s 21 r (e\013ort) s 21 r (far) s 20 r (out) s 119 c -1 r (eighs) s 20 r (the) s 21 r (e\013ort) s 21 r (of) s 21 r (establishing) s 224 2679 p (serv) s (ers) s 18 r (and) s 20 r (user) s 20 r (agen) s (ts.) s 30 r (By) s 20 r 99 c (ho) s 1 r (osing) s 18 r (the) s 20 r (X.500) s 18 r (mo) s 1 r (del) s 18 r (as) s 19 r 97 c 20 r (basis) s 19 r (for) s 18 r (the) s 224 2736 p (informati) s -1 r (on) s 11 r (framew) s -1 r (o) s -1 r (rk,) s 11 r (it) s 11 r (will) s 11 r (also) s 11 r 98 c 1 r 101 c 13 r 97 c 12 r (part) s 12 r (of) s 12 r 97 c 12 r (\(future\)) s 11 r (global) s 11 r (informatio) s -1 r 110 c 224 2792 p (framew) s -1 r (ork.) s 18 r (The) s 15 r 107 c (ey) s 14 r (asp) s 1 r (ects) s 15 r (of) s 15 r (this) s 15 r (mo) s 1 r (del) s 14 r (are:) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 50 c @eop 3 @bop0 cmr10.329 @sf [<3F807FE0F9F0F8F0F87870780078007800780078007800780078007800780078007800780078007800780078007800780078 00F807F807F80078000000000000000000000000007000F800F800F80070> 13 40 3 9 14] 106 @dc [<381C7C3EFC7EFC7EF87CC060C060C060E07060307038381C3C1E180C> 15 14 -5 -18 23] 92 @dc [<6030F0787038381C180C1C0E0C060C060C067C3EFC7EFC7EF87C7038> 15 14 -2 -18 23] 34 @dc [<40E07030303818181878F8F8F8700000000000000000000070F8F8F870> 5 29 -4 9 13] 59 @dc cmbx12.300 @sf [ 21 32 -3 0 28] 50 @dc [ 29 34 -2 0 34] 76 @dc [ 26 22 -2 0 31] 110 @dc [<01FFC0000FFFF8003F80FE007E003F00FC001F80F8000F80F8000F80F8000F80F8001F807C007F803FFFFF001FFFFF001FFF FE003FFFFC003FFFE0003C00000038000000380000003BFE00001FFF80001F8FC0003F07E0007E03F0007E03F0007E03F000 7E03F0007E03F0007E03F0007E03F7803F07E7801F8FFF800FFFFF8003FE3F00> 25 33 -1 11 28] 103 @dc cmr12.300 @sf [<07F8001FFE003C1F00700F80F807C0FC07C0FC03E0FC03E0FC03E03003E00003E00003E00007C00007C0000F80001E0003F8 0003FC00003E00001F00000F800007800007C03807C07C07C07E07C07E07C07C07C0780F803C1F001FFE0007F800> 19 32 -2 0 24] 51 @dc 3 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmsy10.329 @sf 292 195 p 15 c cmr10.329 @sf 23 r (Eac) s 104 c 14 r (ob) s 3 r (ject) s 14 r (is) s 15 r (represen) s (ted) s 15 r (as) s 15 r (an) s 15 r (en) s (try) s cmsy10.329 @sf 292 289 p 15 c cmr10.329 @sf 23 r (Ob) s 3 r (jects) s 14 r (are) s 14 r 116 c (yp) s 1 r (ed) s 13 r 98 c 121 c 14 r (an) s 14 r (\\ob) s 3 r (ject) s 13 r (class",) s 13 r (whic) s 104 c 13 r 112 c 1 r (ermits) s 13 r 109 c (ult) s -1 r (iple) s 12 r (inher-) s 338 345 p (itance.) s cmsy10.329 @sf 292 439 p 15 c cmr10.329 @sf 23 r (An) s 15 r (ob) s 3 r (ject) s 15 r (is) s 15 r (describ) s 1 r (ed) s 16 r 98 c 121 c 14 r 97 c 15 r (set) s 15 r (of) s 14 r (attributes.) s cmsy10.329 @sf 292 533 p 15 c cmr10.329 @sf 23 r (Eac) s 104 c 14 r (attribute) s 14 r (is) s 15 r 116 c (yp) s 1 r (ed.) s 19 r 65 c (ttri) s -1 r (bute) s 14 r 116 c (yp) s 1 r (es) s 14 r (are) s 15 r (hierarc) s (hical.) s cmsy10.329 @sf 292 627 p 15 c cmr10.329 @sf 23 r (Eac) s 104 c 13 r (attribute) s 12 r 116 c (yp) s 1 r 101 c 13 r (has) s 14 r (an) s 14 r (asso) s 1 r (ciated) s 13 r (attribute) s 13 r (syn) s (tax,) s 12 r (whic) s 104 c 13 r (ma) s -1 r 121 c 12 r 98 c 1 r 101 c 338 683 p (generic) s 18 r (or) s 17 r (shared) s 18 r (with) s 17 r (other) s 17 r (attributes) s 17 r (\(e.g.,) s 17 r (In) s (teger) s 16 r (Syn) s (tax;) s 18 r (Distin-) s 338 740 p (guished) s 20 r (Name) s 20 r (Syn) s (tax\),) s 19 r (This) s 20 r (allo) s (ws) s 18 r (for) s 20 r (represen) s (tatio) s -1 r 110 c 19 r (of) s 20 r (simple) s 19 r (at-) s 338 796 p (tributes) s 12 r (\(e.g.,) s 12 r (strings) s 12 r (or) s 12 r (bitmaps\)) s 11 r (or) s 13 r (complex) s 12 r (ones) s 13 r (with) s 12 r (detailed) s 13 r (struc-) s 338 853 p (tures.) s cmsy10.329 @sf 292 946 p 15 c cmr10.329 @sf 23 r (Eac) s 104 c 14 r (en) s (try) s 14 r (has) s 15 r (an) s 15 r (unam) s (big) s -1 r (uous) s 14 r (and) s 15 r (unique) s 16 r (global) s 13 r (name.) s cmsy10.329 @sf 292 1040 p 15 c cmr10.329 @sf 23 r (Alternate) s 21 r (hierarc) s (hies) s 21 r (ma) s 121 c 20 r 98 c 1 r 101 c 23 r (built) s 22 r 98 c 121 c 21 r (use) s 23 r (of) s 22 r (aliases) s 21 r (or) s 22 r 112 c 1 r (oin) s (ters) s 21 r (of) s 338 1097 p (distinguished) s 15 r (name) s 14 r (syn) s (tax.) s 224 1223 p (This) s 22 r (framew) s -1 r (ork) s 20 r (allo) s -1 r (ws) s 21 r (for) s 21 r (represen) s (tation) s 21 r (of) s 22 r (basic) s 22 r (ob) s 3 r (jects,) s 23 r (suc) s 104 c 21 r (as) s 22 r (users) s 224 1279 p (within) s 16 r (organisations.) s 23 r (It) s 17 r (is) s 16 r (also) s 16 r (highly) s 17 r (extensible,) s 17 r (and) s 17 r (so) s 16 r (can) s 17 r 98 c 1 r 101 c 18 r (used) s 17 r (for) s 17 r 97 c 224 1335 p (range) s 15 r (of) s 15 r (other) s 15 r (activities.) s cmbx12.300 @sf 224 1477 p (3.2) s 56 r (Longer) s 18 r 84 c -4 r (erm) s cmr10.329 @sf 224 1582 p (The) s 19 r (informatio) s -1 r 110 c 18 r (framew) s -1 r (o) s -1 r (rk) s 17 r (could) s 19 r 98 c 1 r 101 c 20 r (extended) s 20 r (in) s 18 r (the) s 20 r (longer) s 18 r (term) s 17 r (to) s 19 r (deal) s 224 1639 p (with) s 11 r 97 c 11 r 110 c (um) s -2 r 98 c 1 r (er) s 10 r (of) s 11 r (other) s 11 r (issues,) s 11 r (whic) s 104 c 10 r (are) s 11 r 112 c 1 r (oten) s (tiall) s -1 r 121 c 9 r (imp) s 1 r (ortan) s -1 r 116 c 9 r (in) s 11 r (an) s 11 r (In) s (ternet) s 224 1695 p (Directory) s -3 r 46 c 18 r 80 c (ossible) s 13 r (extensions) s 15 r (include:) s cmsy10.329 @sf 292 1821 p 15 c cmr10.329 @sf 23 r (Storage) s 21 r (of) s 23 r (large) s 21 r (attributes) s 22 r (and) s 23 r (\014les) s 22 r (\(e.g.,) s 23 r (to) s 22 r (supp) s 1 r (ort) s 23 r (bibliographic) s 338 1877 p (services\).) s cmsy10.329 @sf 292 1971 p 15 c cmr10.329 @sf 23 r (Supp) s 1 r (ort) s 18 r (of) s 17 r (ordered) s 18 r (attributes) s 17 r (\(needed) s 19 r 98 c 121 c 17 r (some) s 16 r (applications,) s 17 r (suc) s 104 c 17 r (as) s 338 2028 p (message) s 14 r (storage\).) s cmsy10.329 @sf 292 2121 p 15 c cmr10.329 @sf 23 r (Extensions) s 14 r (to) s 13 r (allo) s 119 c 12 r (uni\014cation) s 14 r (with) s 13 r (managemen) s -1 r 116 c 12 r (informat) s -1 r (ion,) s 12 r (asso) s 1 r (ci-) s 338 2178 p (ated) s 15 r (with) s 14 r (SNMP) s 15 r 91 c (CFSD90) s -1 r (].) s cmsy10.329 @sf 292 2272 p 15 c cmr10.329 @sf 23 r (Handle) s 14 r (non-hierarc) s (hical) s 12 r (data) s 14 r (in) s 14 r 97 c 14 r 98 c 1 r (etter) s 14 r (manner) s 13 r (for) s 13 r (searc) s (hing) s 13 r (and) s 14 r (re-) s 338 2328 p (triev) s -2 r (al,) s 12 r (whilst) s 12 r (retaining) s 13 r (the) s 14 r (basic) s 13 r (hierarc) s 104 c -1 r 121 c 12 r (for) s 13 r (managemen) s -1 r 116 c 11 r (purp) s 1 r (oses.) s 338 2385 p (This) s 13 r (is) s 14 r (essen) s (tiall) s -1 r 121 c 12 r (building) s 13 r 97 c 14 r (general) s 13 r (purp) s 1 r (ose) s 15 r (resource) s 14 r (lo) s 1 r (cation) s 13 r (service) s 338 2441 p (on) s 12 r (top) s 11 r (of) s 12 r (the) s 12 r (basic) s 11 r (infrastructure.) s 18 r (It) s 12 r (will) s 11 r (need) s 12 r 119 c (ork) s 10 r (on) s 12 r (the) s 12 r (informatio) s -1 r 110 c 338 2497 p (mo) s 1 r (del,) s 14 r (and) s 15 r (not) s 15 r (just) s 15 r (the) s 15 r (access) s 15 r (proto) s 1 r (cols.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 51 c @eop 4 @bop0 cmbx10.432 @sf [<007FFFF8007FFFF8007FFFF80000FF000000FF000000FF000000FF000000FF000000FF000000FF00FFFFFFF8FFFFFFF8FFFF FFF8F0007F0078007F003C007F001E007F001E007F000F007F0007807F0003C07F0001C07F0001E07F0000F07F0000787F00 003C7F00003C7F00001E7F00000F7F000007FF000003FF000003FF000001FF000000FF0000007F0000007F0000003F000000 1F0000000F00> 29 39 -2 0 34] 52 @dc [ 47 41 -2 0 52] 65 @dc [<003FF00001FFFC0007FFFF000FFC0F801FF003803FC003C03FC001C07F8000007F800000FF000000FF000000FF000000FF00 0000FF000000FF000000FF000000FF000000FF0000007F003F007F807F803F807F803FC07F801FE07F800FF87F8007FFFF00 01FFFE00003FF800> 26 27 -2 0 31] 99 @dc [ 58 41 -3 0 65] 77 @dc [ 33 42 -3 0 38] 104 @dc cmbx12.300 @sf [<00FFFE00FFFE00FFFE0007E00007E00007E00007E00007E00007E0FFFFFEFFFFFEFFFFFEE007E07007E03807E01C07E00E07 E00E07E00707E00387E001C7E000E7E000E7E00077E0003FE0001FE0000FE0000FE00007E00003E00001E00000E0> 23 32 -2 0 28] 52 @dc cmr10.329 @sf [ 22 31 -3 0 28] 90 @dc cmbx10.432 @sf [<00FF800007FFF0000FFFFC003F83FE003C00FF007C007F80FF007FC0FF003FC0FF803FE0FF803FE0FF803FE0FF003FE07F00 3FE03C003FE000003FE000003FE000003FC000003FC01E007F801F007F801FC1FF001FFFFE001FFFF8001E7FC0001E000000 1E0000001E0000001E0000001E0000001FFE00001FFF80001FFFE0001FFFF0001FFFFC001FFFFC001FFFFE001FFFFF001F80 3F001C000700> 27 39 -3 0 34] 53 @dc [ 47 41 -3 0 54] 78 @dc [<00FFF80007FFFF001FFFFFC03FE03FE07F0007F07E0003F0FE0003F8FC0001F8FC0001F8FC0001F8FE0003F87E000FF83FFF FFF01FFFFFF00FFFFFE01FFFFFC03FFFFF003FFFFC003E0000003C0000003C0000003800000038FF80001FFFF0000FFFF800 1FC1FC003F80FE003F007E007F007F007F007F007F007F007F007F007F007F007F007F003F007E783F80FE7C1FC1FEFC0FFF FFFC07FFF7FC00FF81F0> 30 40 -2 13 34] 103 @dc cmr12.300 @sf [<01FFF801FFF8000F00000F00000F00000F00000F00000F00000F00FFFFF8FFFFF8E00F00600F00300F00380F00180F000C0F 000E0F00060F00030F00038F00018F0001CF0000CF00006F00007F00003F00001F00001F00000F00000700000700> 21 32 -1 0 24] 52 @dc 4 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmbx10.432 @sf 224 195 p 52 c 69 r (Access) s 22 r (Mec) s -1 r (hanism) s -2 r 115 c cmbx12.300 @sf 224 318 p (4.1) s 56 r (Short) s 18 r 84 c -4 r (erm) s cmr10.329 @sf 224 423 p (The) s 22 r (In) s (ternet) s 21 r (Directory) s 20 r (Service) s 22 r (should) s 22 r 98 c 1 r 101 c 22 r (ac) s (hiev) s (ed) s 20 r (initially) s 19 r 98 c 121 c 21 r (deplo) s (ying) s 224 480 p (X.500) s 14 r (on) s 15 r (the) s 16 r (In) s (ternet.) s 19 r (The) s 15 r (means) s 14 r (to) s 15 r (do) s 15 r (this) s 15 r (is) s 14 r (discussed) s 16 r (in) s 15 r (Section) s 15 r (6.) s cmbx12.300 @sf 224 620 p (4.2) s 56 r (Longer) s 18 r 84 c -4 r (erm) s cmr10.329 @sf 224 725 p (It) s 12 r (is) s 11 r (exp) s 1 r (ected) s 12 r (that) s 11 r (other) s 11 r (access) s 12 r (mec) s (hanis) s -1 r (m) s -1 r 115 c 10 r (will) s 10 r (ev) s (olv) s -1 r (e.) s 17 r 80 c (ossibi) s -1 r (lit) s -1 r (ies) s 9 r (include:) s cmsy10.329 @sf 292 843 p 15 c cmr10.329 @sf 23 r 84 c -3 r (rac) s -1 r (king) s 13 r (the) s 15 r (ev) s (olution) s 13 r (of) s 15 r (X.500.) s cmsy10.329 @sf 292 934 p 15 c cmr10.329 @sf 23 r (Ligh) s 116 c -1 r 119 c -1 r (ei) s -1 r (gh) s -1 r 116 c 13 r (access) s 16 r (proto) s 1 r (cols,) s 14 r (retaining) s 14 r (the) s 16 r (comm) s -1 r (on) s 14 r (core.) s 20 r (There) s 16 r (ha) s 118 c -1 r 101 c 338 991 p (already) s 19 r 98 c 1 r (een) s 21 r (priv) s -2 r (ate) s 18 r (proto) s 1 r (cols) s 19 r (whic) s 104 c 19 r (do) s 19 r (this) s 20 r (\(The) s 19 r (Mic) s (higan) s 18 r (DIXIE) s 338 1047 p (proto) s 1 r (col) s 14 r 91 c (HSB91) s 93 c 14 r (and) s 16 r (the) s 15 r (PSI) s 16 r (Directory) s 14 r (Assistance) s 14 r (Service) s 16 r 91 c (Ros91) s -1 r (].) s cmsy10.329 @sf 292 1139 p 15 c cmr10.329 @sf 23 r (Ligh) s 116 c -1 r 119 c -1 r (ei) s -1 r (gh) s -1 r 116 c 20 r (proto) s 1 r (cols) s 22 r (for) s 21 r (access) s 23 r (and) s 23 r (system) s 21 r (usage.) s 41 r (This) s 22 r (could) s 23 r 98 c 1 r 101 c 338 1195 p (used) s 17 r (to) s 15 r (signi\014can) s (tly) s 14 r (increase) s 17 r (the) s 16 r 112 c 1 r (erformance) s 16 r (of) s 15 r (the) s 17 r (directory) s -3 r 44 c 15 r (whic) s 104 c 338 1251 p 119 c (ould) s 10 r (mak) s 101 c 10 r (it) s 12 r (useful) s 12 r (for) s 12 r 97 c 12 r (range) s 12 r (of) s 12 r (new) s 12 r (applications) s 11 r (\(e.g.,) s 11 r 112 c 1 r (olicy) s 12 r (based) s 338 1308 p (routing\).) s cmsy10.329 @sf 292 1399 p 15 c cmr10.329 @sf 23 r (Proto) s 1 r (cols) s 19 r (with) s 20 r (impro) s -1 r 118 c -1 r (ed) s 19 r (searc) s (hing) s 19 r (tec) s (hniques) s 19 r (for) s 20 r (bibliographic) s 20 r (use.) s 338 1456 p 70 c -3 r (or) s 10 r (example,) s 11 r (some) s 10 r (simple) s 10 r (additions) s 11 r (to) s 11 r (X.500) s 10 r (could) s 12 r (mak) s -1 r 101 c 10 r (it) s 11 r (an) s 11 r (e\013ectiv) s 101 c 338 1512 p (replacemen) s 116 c 13 r (for) s 14 r (Z39.50) s 14 r (based) s 15 r (services) s 15 r 91 c (Lyn91) s (].) s cmsy10.329 @sf 292 1604 p 15 c cmr10.329 @sf 23 r (Proto) s 1 r (cols) s 18 r (making) s 17 r (use) s 20 r (of) s 19 r 109 c (ulti) s -1 r (cast,) s 18 r (to) s 19 r (allo) s -1 r 119 c 17 r (for) s 19 r (searc) s (hing) s 18 r (of) s 19 r (rapidly) s 338 1660 p 99 c (hanging) s 13 r (informatio) s -1 r (n.) s cmbx10.432 @sf 224 1822 p 53 c 69 r (Name) s 20 r (Assignm) s -1 r (en) s -2 r 116 c cmr10.329 @sf 224 1943 p (In) s 17 r (order) s 17 r (to) s 16 r (deplo) s 121 c 15 r (the) s 17 r (In) s (ternet) s 16 r (Directory) s 15 r (Service,) s 17 r (it) s 16 r (is) s 16 r (imp) s 1 r (ortan) s -1 r 116 c 14 r (to) s 16 r (de\014ne) s 224 1999 p (ho) s 119 c 14 r (the) s 15 r (naming) s 13 r (hierarc) s 104 c -1 r 121 c 13 r (will) s 14 r 98 c 1 r 101 c 15 r (de\014ned.) s 22 r (The) s 15 r (lo) s 119 c -2 r (er) s 13 r (parts) s 15 r (of) s 14 r (the) s 15 r (hierarc) s 104 c 121 c 224 2056 p (will) s 13 r (in) s 15 r (general) s 14 r 98 c 1 r 101 c 15 r (delegated) s 15 r (to) s 14 r (organisatio) s -1 r (ns,) s 13 r (who) s 14 r (will) s 14 r (ha) s 118 c -1 r 101 c 13 r (con) s (trol) s 12 r (of) s 14 r (name) s 224 2112 p (assignmen) s -1 r (t.) s 30 r (There) s 20 r (is) s 18 r (no) s 20 r (reason) s 18 r (to) s 19 r (mandate) s 18 r (ho) s 119 c 18 r (to) s 18 r (assign) s 19 r (this) s 18 r (hierarc) s 104 c 121 c -4 r 44 c 224 2169 p (although) s 16 r (it) s 17 r (is) s 16 r (appropriate) s 16 r (to) s 17 r (giv) s 101 c 15 r (guidelines.) s 25 r (Suitable) s 17 r (guidelines) s 16 r (are) s 17 r 98 c 1 r (eing) s 224 2225 p (dev) s (elop) s 1 r (ed) s 15 r 98 c 121 c 14 r (the) s 15 r (OSI-DS) s 17 r 87 c 71 c 13 r 91 c (BK91b) s (].) s 224 2301 p (Some) s 16 r (parts) s 16 r (of) s 17 r (the) s 17 r (DIT) s 17 r (ma) s -1 r 121 c 15 r 98 c 1 r 101 c 17 r (assigned) s 17 r (at) s 16 r (the) s 17 r (ro) s 1 r (ot) s 16 r (for) s 17 r (the) s 17 r (In) s (ternet.) s 24 r (This) s 224 2358 p (should) s 16 r 98 c 1 r 101 c 16 r (handled) s 16 r (as) s 15 r 97 c 16 r (part) s 15 r (of) s 15 r (the) s 16 r (general) s 15 r (op) s 1 r (eration) s 15 r (of) s 15 r 97 c 15 r (directory) s 15 r (service.) s 224 2414 p (An) s 16 r (example) s 14 r (of) s 15 r (this) s 15 r (migh) s -1 r 116 c 13 r 98 c 1 r 101 c 16 r (assignmen) s 116 c 13 r (of) s 15 r 97 c 15 r (represen) s (tatio) s -1 r 110 c 14 r (of) s 15 r (the) s 16 r (Domai) s -1 r 110 c 224 2471 p (Namespace) s 13 r (under) s 14 r (the) s 14 r (ro) s 1 r (ot) s 13 r (of) s 13 r (the) s 14 r (DIT.) s 13 r (This) s 14 r (is) s 13 r (further) s 14 r (discussed) s 14 r (in) s 13 r 91 c (BK91b) s (].) s 224 2547 p (The) s 14 r (core) s 13 r (DIT) s 13 r (informat) s -1 r (ion) s 11 r (will) s 12 r 98 c 1 r 101 c 14 r (nationally) s 11 r (assigned.) s 19 r (The) s 13 r (parts) s 13 r (of) s 12 r (the) s 14 r (DIT) s 224 2603 p 98 c 1 r (elo) s 119 c 14 r (coun) s (try) s 14 r (lev) s (el) s 13 r (will) s 14 r 98 c 1 r 101 c 16 r (managed) s 14 r (di\013eren) s (tly) s 13 r (in) s 15 r (eac) s 104 c 14 r (coun) s (tries.) s 224 2679 p (In) s 15 r (man) s -1 r 121 c 12 r (coun) s (tries,) s 12 r (registration) s 12 r (authorities) s 12 r (will) s 13 r 98 c 1 r 101 c 14 r (established) s 14 r (according) s 13 r (the) s 224 2736 p (OSI) s 19 r (Standard) s 18 r 91 c (ISO) s 1 r (].) s 28 r (This) s 18 r (has) s 18 r 98 c 1 r (een) s 19 r (done) s 19 r (in) s 18 r (the) s 18 r (UK) s 19 r 98 c 121 c 17 r (BSI,) s 18 r (and) s 19 r (is) s 17 r 98 c 1 r (eing) s 224 2792 p (done) s 16 r (in) s 15 r (the) s 15 r (US) s 16 r 98 c 121 c 14 r (COS.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 52 c @eop 5 @bop0 cmbx10.432 @sf [<007FE00001FFF80003FFFC0007F0FF000FE07F801FC03F803F803FC03F803FC07F803FE07F803FE07F803FE07F803FE0FF80 3FE0FF803FE0FF803FE0FF803FE0FFC03FE0FFC03FC0FFC03FC0FFE03F80FFE07F00FFFFFE00FFBFFC00FF9FF000FF820000 7F8000007F8000007F801E007FC03F003FC07F803FC07F801FC07F800FE07F800FF03F8007F81F0001FE1F0000FFFE00003F FC000007F800> 27 39 -3 0 34] 54 @dc [ 47 41 -2 0 52] 88 @dc [<1E007F807F80FFC0FFC0FFC0FFC07F807F801E00> 10 10 -4 0 19] 46 @dc [<003F800001FFF00007FFFC000FE0FE001FC07F001F803F003F803F803F001F807F001FC07F001FC07F001FC07F001FC0FF00 1FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0FF001FE0 FF001FE0FF001FE07F001FC07F001FC07F001FC07F001FC03F001F803F803F801F803F001FC07F000FE0FE0007FFFC0001FF F000003F8000> 27 39 -3 0 34] 48 @dc [ 45 41 -3 0 53] 68 @dc [ 33 39 -2 12 38] 112 @dc cmbx12.300 @sf [<00FF0007FFC00FFFF01FC3F83F01FC3F00FC7E00FE7E00FE7E00FEFE00FEFE00FEFE00FEFE00FEFE00FEFF00FEFF00FCFF81 F8FFC1F8FEFFF0FE7FC0FE08007E00007E00007F00F03F01F83F01F81F81F80FC1F807F0F803FFF001FFE0003FC0> 23 32 -2 0 28] 54 @dc [<01FF0007FFC01FE1E03F80F03F80707F00007F0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE00007E01E07F03 F03F03F03F83F01FC3F007FFE001FF80> 20 22 -2 0 25] 99 @dc [ 12 36 -1 0 15] 105 @dc [<0FF0FF3FFDFF7F1FFFFF0FF8FE07F0FE03F0FE03F0FF03F07F03F07F83F03FE3F00FFFF001FFF00003F00003F01E03F03F03 F03F07F03F07E03F0FC01FFF8007FE00> 24 22 -2 0 27] 97 @dc [ 12 35 -1 0 15] 108 @dc [ 19 34 -1 0 21] 73 @dc [ 17 22 -2 0 22] 115 @dc [<03FC7FC00FFF7FC00FC3FFC01F81FE001F80FE001F80FE001F807E001F807E001F807E001F807E001F807E001F807E001F80 7E001F807E001F807E001F807E001F807E001F807E001F807E00FF83FE00FF83FE00FF83FE00> 26 22 -2 0 31] 117 @dc cmr10.329 @sf [ 37 32 0 0 38] 14 @dc cmr12.300 @sf [<07F0001FFC003C3F00700F806007C0F807C0F803C0F803E0F803E0F803E00003E00003E00003E00003E00003C01807C01C07 801F1F001FFE0019F8001800001800001800001800001800001800001FF0001FFC001FFF001FFF801E0780180180> 19 32 -2 0 24] 53 @dc 5 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 224 195 p (In) s 19 r (the) s 18 r (US,) s 17 r (there) s 18 r (is) s 17 r (an) s 18 r (alternativ) s -1 r 101 c 16 r (approac) s 104 c 17 r 98 c 1 r (eing) s 18 r (dev) s (elop) s 1 r (ed) s 17 r 98 c 121 c 17 r (the) s 18 r (North) s 224 252 p (American) s 18 r (Directory) s 18 r 70 c -3 r (orum) s 16 r (\(NADF\),) s 18 r (whic) s 104 c 18 r (lev) s (erages) s 17 r (existing) s 18 r (registratio) s -1 r 110 c 224 308 p (mec) s (hanism) s -1 r 115 c 15 r 91 c 70 c -3 r (or91) s -3 r (].) s 26 r (It) s 17 r (is) s 17 r (not) s 16 r (clear) s 17 r (what) s 17 r (form) s 15 r 97 c 17 r (\014nal) s 17 r (US) s 17 r (directory) s 17 r (service) s 224 364 p (will) s 14 r (tak) s (e.) s 224 440 p (It) s 11 r (is) s 11 r (clearly) s 11 r (desirable) s 11 r (that) s 10 r (the) s 11 r (In) s (ternet) s 11 r (Directory) s 10 r (Service) s 11 r (follo) s (ws) s 9 r (an) s 121 c 10 r (ev) s (olving) s 224 497 p (national) s 14 r (and) s 15 r (in) s (ternati) s -1 r (onal) s 13 r (hierarc) s (hies.) s 18 r (Ho) s 119 c -1 r (ev) s -1 r (er,) s 12 r (this) s 15 r (should) s 15 r (not) s 14 r 98 c 1 r 101 c 16 r (allo) s -1 r 119 c -1 r (ed) s 224 553 p (to) s 17 r (cause) s 18 r (undue) s 19 r (dela) s 121 c -3 r 46 c 25 r (The) s 18 r (strategy) s 17 r (prop) s 1 r (osed) s 18 r (is) s 17 r (to) s 17 r (pro) s 1 r (ceed) s 19 r (with) s 17 r (name) s 17 r (as-) s 224 610 p (signmen) s 116 c 13 r (as) s 15 r (needed,) s 17 r (and) s 16 r (to) s 15 r (establish) s 15 r (in) s (terim) s 13 r (registrati) s -1 r (on) s 14 r (authorities) s 14 r (where) s 224 666 p (necessary) s -3 r 44 c 18 r (taking) s 17 r (practical) s 17 r (steps) s 18 r (to) s 18 r 98 c 1 r 101 c 19 r (aligned) s 17 r (with) s 18 r (emerging) s 17 r (national) s 16 r (au-) s 224 723 p (thorities) s 14 r (wherev) s (er) s 14 r 112 c 1 r (ossible.) s 224 799 p (It) s 15 r (is) s 15 r (suggested) s 15 r (that) s 15 r (the) s 15 r (In) s (ternet) s 14 r (Directory) s 14 r (Service) s 16 r (do) s 1 r (es) s 15 r 116 c 119 c -1 r 111 c 13 r (things.) s 224 875 p (First,) s 20 r (eac) s 104 c 19 r (national) s 18 r (part) s 20 r (of) s 19 r (the) s 20 r (In) s (ternet) s 19 r (DIT) s 20 r (Namespace) s 19 r (should) s 20 r 98 c 1 r 101 c 21 r (dele-) s 224 931 p (gated) s 17 r (to) s 16 r (an) s 17 r (appropriate) s 16 r (organisatio) s -1 r (n,) s 16 r (whic) s 104 c 15 r (will) s 16 r (usually) s 16 r 98 c 1 r 101 c 18 r (in) s 17 r (the) s 17 r (coun) s (try) s 224 988 p (in) s 15 r (question.) s 224 1064 p (Second,) s 16 r (the) s 14 r (delegated) s 15 r (organisation) s 13 r (should) s 14 r (assign) s 14 r (names) s 14 r (for) s 14 r (that) s 14 r (coun) s (try) s 14 r (as) s 224 1120 p 97 c 16 r (part) s 16 r (of) s 16 r (the) s 17 r (In) s (ternet) s 15 r (Directory) s 16 r (Service.) s 23 r (This) s 17 r (should) s 16 r 98 c 1 r 101 c 17 r (done) s 17 r (in) s 16 r 97 c 16 r (manner) s 224 1177 p (whic) s 104 c 12 r (is) s 12 r (appropriately) s 11 r (aligned) s 12 r (with) s 12 r (emerging) s 11 r (national) s 11 r (services,) s 13 r (but) s 13 r (do) s 1 r (es) s 13 r (not) s 224 1233 p (unduly) s 19 r (dela) s 121 c 18 r (the) s 19 r (deplo) s (ym) s -1 r (en) s -1 r 116 c 17 r (of) s 18 r (the) s 19 r (In) s (ternet) s 18 r (Directory) s 17 r (Service.) s 31 r 70 c -3 r (or) s 17 r (most) s 224 1290 p (coun) s (tries,) s 14 r (this) s 16 r (will) s 14 r (\014t) s 16 r (in) s 16 r (as) s 16 r 97 c 15 r (natural) s 15 r (ev) s (olution) s 14 r (of) s 16 r (the) s 16 r (early) s 15 r (directory) s 15 r (pilot-) s 224 1346 p (ing,) s 18 r (where) s 18 r (the) s 18 r (op) s 1 r (erators) s 17 r (of) s 18 r (pilots) s 16 r (ha) s 118 c 101 c 16 r (acted) s 18 r (as) s 17 r (in) s (terim) s 15 r (name) s 17 r (registratio) s -1 r 110 c 224 1402 p (authorities.) s cmbx10.432 @sf 224 1565 p 54 c 69 r (X.500) s 24 r (Deplo) s -1 r (ym) s -2 r (e) s -1 r 110 c -1 r 116 c cmr10.329 @sf 224 1686 p (This) s 20 r (section) s 20 r (describ) s 1 r (es) s 20 r (steps) s 21 r (whic) s 104 c 19 r (need) s 21 r (to) s 19 r 98 c 1 r 101 c 21 r (tak) s (en) s 19 r (to) s 19 r (deplo) s 121 c 19 r (the) s 20 r (initial) s 224 1743 p (X.500) s 14 r (based) s 16 r (In) s (ternet) s 14 r (Directory) s 14 r (Service.) s cmbx12.300 @sf 224 1884 p (6.1) s 56 r 84 c -4 r (ec) s -1 r (hnical) s 18 r (Issues) s cmr10.329 @sf 224 1989 p (The) s 24 r (IETF) s 23 r (has) s 23 r (established) s 24 r 97 c 23 r 87 c -3 r (orking) s 21 r (Group) s 23 r (on) s 24 r (OSI) s 24 r (Directory) s 22 r (Services) s 224 2046 p (\(IETF-OSI-DS\).) s 22 r 65 c 21 r (ma) s 3 r (jor) s 19 r (comp) s 1 r (onen) s 116 c 19 r (of) s 21 r (the) s 21 r (initial) s 20 r 119 c (ork) s 19 r (of) s 21 r (this) s 21 r (group) s 21 r (is) s 224 2102 p (to) s 18 r (establish) s 19 r 97 c 18 r (tec) s (hnical) s 18 r (framew) s -1 r (o) s -1 r (rk) s 17 r (for) s 18 r (establishing) s 18 r 97 c 19 r (Directory) s 17 r (Service) s 20 r (on) s 224 2159 p (the) s 13 r (In) s (ternet,) s 13 r (making) s 11 r (use) s 14 r (of) s 13 r (the) s 13 r (X.500) s 12 r (proto) s 1 r (cols) s 12 r (and) s 14 r (services) s 13 r 91 c (CCI88b) s -1 r (].) s 19 r (This) s 224 2215 p (section) s 16 r (describ) s 1 r (es) s 17 r (the) s 17 r 119 c (ork) s 15 r (done) s 17 r 98 c 121 c 15 r (this) s 16 r 87 c (G,) s 15 r (whic) s 104 c 15 r (has) s 16 r 98 c 1 r (een) s 18 r (implicitl) s -1 r 121 c 15 r (fo-) s 224 2272 p (cussed) s 16 r (on) s 15 r (the) s 15 r (issues) s 15 r (needed) s 17 r (to) s 15 r (deplo) s 121 c 14 r (the) s 15 r (In) s (ternet) s 14 r (Directory) s 14 r (Service.) s 224 2348 p (The) s 12 r (OSI) s 13 r (Directory) s 11 r (Standards) s 12 r (do) s 12 r (not) s 11 r (con) s (tain) s 10 r (su\016cien) s 116 c 11 r (informat) s -1 r (ion) s 10 r (to) s 11 r (enable) s 224 2404 p (the) s 11 r (In) s (ternet) s 11 r (Directory) s 10 r (Service) s 11 r (to) s 11 r 98 c 1 r 101 c 12 r (built.) s 18 r 70 c -3 r (ull) s 9 r (op) s 1 r (enness) s 12 r (and) s 12 r (in) s (terop) s 1 r (erabil) s -1 r (it) s -1 r 121 c 224 2461 p (are) s 13 r 97 c 14 r 107 c (ey) s 12 r (goal,) s 12 r (so) s 13 r (service) s 14 r 109 c -1 r (ust) s 12 r (not) s 13 r (dep) s 1 r (end) s 15 r (on) s 13 r (priv) s -2 r (ate) s 13 r (extensions) s 13 r (or) s 13 r (informal) s 224 2517 p (agreemen) s (ts) s -1 r 46 c 17 r (This) s 12 r (section) s 11 r (notes) s 12 r (areas) s 11 r (where) s 12 r (the) s 12 r (standard) s 11 r (do) s 1 r (es) s 12 r (not) s 12 r (ha) s 118 c -1 r 101 c 10 r (su\016-) s 224 2573 p (cien) s 116 c 11 r (co) s 118 c -1 r (erage,) s 10 r (and) s 12 r (indicates) s 11 r (the) s 12 r (RF) s (Cs) s 11 r (whic) s 104 c 11 r (ha) s 118 c -1 r 101 c 10 r 98 c 1 r (een) s 13 r (written) s 11 r (to) s 11 r 111 c 118 c (erco) s -1 r (m) s -1 r 101 c 224 2630 p (these) s 16 r (problems.) s 224 2706 p (The) s 23 r 119 c (ork) s 20 r (is) s 22 r 98 c 1 r (eing) s 23 r (limit) s -1 r (ed) s 21 r (to) s 22 r (\(reasonably) s 21 r 119 c (ell\)) s 20 r (understo) s 1 r 111 c 1 r 100 c 23 r (issues.) s 42 r (This) s 224 2762 p (means) s 16 r (that) s 16 r (whilst) s 15 r 119 c 101 c 15 r (will) s 16 r (attempt) s 14 r (to) s 16 r (solv) s 101 c 15 r 97 c 16 r (wide) s 17 r (range) s 16 r (of) s 16 r (problems,) s 15 r (that) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 53 c @eop 6 @bop0 cmbx10.329 @sf [<0007FE0000001FFF8000007FFFE00000FF03F00001FC00F00003F800780003F800380007F0003C0007F0001C0007F0001C00 07F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C00 07F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C0007F0001C00FFFF83FFE0FFFF83FFE0 FFFF83FFE0> 35 31 -2 0 40] 85 @dc cmr10.329 @sf [ 16 45 -3 11 23] 47 @dc cmr12.300 @sf [<03F80007FE000F0F001C07803C03C03803C07801E07001E07001E0F001E0F001E0F001E0F001E0F801E0F801C0F803C0FC03 80F60780F7FF00F1FE00F020007000007800007800003807C03C07C01C07C01E07C00F01C007C38001FF80007E00> 19 32 -2 0 24] 54 @dc 6 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 224 195 p (not) s 15 r (all) s 14 r (\(p) s 1 r (oten) s (tial\)) s 12 r (requiremen) s (ts) s 13 r (will) s 14 r (necessarily) s 15 r 98 c 1 r 101 c 15 r (met.) s 224 271 p (This) s 10 r (tec) s (hnical) s 9 r 119 c (ork) s 8 r (has) s 10 r 98 c 1 r (een) s 11 r (done) s 11 r (in) s 10 r (conjunction) s 10 r (with) s 9 r (RARE) s 11 r 87 c (G3) s 8 r (directory) s 224 328 p (subgroup.) s 33 r (The) s 19 r (IETF) s 20 r 87 c 71 c 17 r (and) s 20 r (the) s 19 r (RARE) s 20 r 87 c 71 c 18 r (ha) s 118 c -1 r 101 c 18 r 97 c 19 r (commo) s -1 r 110 c 18 r (tec) s (hnical) s 224 384 p (mailing) s 15 r (list.) s 26 r (It) s 17 r (is) s 17 r (in) s (tended) s 17 r (that) s 17 r (this) s 17 r (will) s 16 r (lead) s 17 r (to) s 17 r 97 c 17 r (common) s 15 r (Europ) s 1 r (ean) s 18 r (and) s 224 440 p (North) s 15 r (American) s 14 r (tec) s (hnical) s 13 r (approac) s (h.) s cmbx10.329 @sf 224 580 p (6.1.1) s 52 r (Sc) s (hem) s -3 r 97 c cmr10.329 @sf 224 685 p 65 c 16 r (Directory) s 14 r (needs) s 17 r (to) s 15 r 98 c 1 r 101 c 16 r (used) s 16 r (in) s 16 r (the) s 16 r (con) s (text) s 14 r (of) s 15 r (an) s 16 r (Informatio) s -1 r 110 c 14 r 70 c -3 r (ramew) s -2 r (ork.) s 224 742 p (The) s 14 r (standard) s 13 r (directory) s 12 r (pro) s (vides) s 12 r 97 c 13 r 110 c (um) s -1 r 98 c 1 r (er) s 12 r (of) s 13 r 97 c 13 r (attributes) s 12 r (and) s 13 r (ob) s 3 r (ject) s 13 r (classes) s 224 798 p (to) s 18 r (enable) s 19 r (basic) s 18 r (op) s 1 r (eration.) s 30 r (It) s 19 r (is) s 18 r (certain) s 18 r (that) s 18 r (the) s 19 r (In) s (ternet) s 18 r (Comm) s -2 r (unit) s -2 r 121 c 17 r (will) s 224 854 p (ha) s 118 c 101 c 16 r (requiremen) s (ts) s 16 r (for) s 17 r (additional) s 17 r (attributes) s 17 r (and) s 18 r (ob) s 3 r (ject) s 18 r (classes.) s 29 r (There) s 18 r (is) s 18 r 97 c 224 911 p (need) s 16 r (to) s 15 r (establish) s 14 r 97 c 15 r (mec) s (hanism) s 12 r (to) s 14 r (register) s 15 r (suc) s 104 c 14 r (informati) s -1 r (on.) s 224 987 p (Pilots) s 18 r (in) s 20 r (the) s 20 r (Europ) s 1 r (ean) s 20 r (RARE) s 21 r (Comm) s -2 r (unit) s -1 r 121 c 17 r (and) s 20 r (the) s 20 r (US) s 21 r (PSI) s 20 r (White) s 19 r 80 c (ages) s 224 1043 p (Pilot) s 16 r (ha) s 118 c 101 c 16 r (based) s 18 r (their) s 17 r (informati) s -1 r (on) s 16 r (framew) s -1 r (ork) s 15 r (on) s 18 r (the) s 18 r (THORN) s 19 r (and) s 18 r (RARE) s 224 1100 p (Naming) s 21 r (Arc) s (hitecture) s 21 r 91 c (Kil89c) s -1 r (].) s 41 r (This) s 22 r (arc) s (hitecture) s 20 r (should) s 23 r 98 c 1 r 101 c 23 r (used) s 23 r (for) s 21 r (the) s 224 1156 p (In) s (ternet) s 17 r (Directory) s 17 r (Service,) s 19 r (in) s 17 r (conjunction) s 18 r (with) s 18 r (COSINE) s 19 r (based) s 18 r (services) s 18 r (in) s 224 1213 p (Europ) s 1 r (e.) s 27 r 65 c 17 r (revised) s 17 r 118 c (ersion) s 16 r (of) s 16 r (the) s 18 r (Naming) s 15 r (Arc) s (hitecture,) s 16 r (with) s 17 r 97 c 17 r (mec) s (hanism) s 224 1269 p (for) s 21 r (registratio) s -1 r 110 c 20 r (of) s 20 r (new) s 22 r (attributes) s 20 r (and) s 21 r (ob) s 3 r (ject) s 21 r (classes,) s 22 r (has) s 21 r 98 c 1 r (een) s 22 r (release) s 21 r (as) s 224 1326 p (RF) s 67 c 14 r (12XX) s 15 r 91 c (BK91a) s -1 r (].) s cmbx10.329 @sf 224 1465 p (6.1.2) s 52 r (Use) s 17 r (on) s 18 r (the) s 17 r (In) s (ternet) s cmr10.329 @sf 224 1570 p (It) s 20 r (is) s 19 r 97 c 19 r (recognised) s 20 r 112 c 1 r (olicy) s 19 r (on) s 20 r (the) s 20 r (In) s (ternet) s 19 r (to) s 19 r (deplo) s 121 c 18 r (OSI) s 21 r (Applications) s 18 r 111 c 118 c (er) s 224 1627 p (non-OSI) s 15 r (lo) s 119 c -1 r (er) s 12 r (la) s 121 c -1 r (ers) s 12 r (\(suc) s 104 c 12 r (as) s 14 r (RF) s 67 c 12 r (1006\).) s 18 r (This) s 14 r 112 c 1 r (olicy) s 13 r (allo) s (ws) s 12 r (deplo) s (ym) s -1 r (en) s -1 r 116 c 12 r (of) s 224 1683 p (OSI) s 12 r (Applications) s 10 r 98 c 1 r (efore) s 11 r (an) s 11 r (OSI) s 11 r (lo) s 119 c -1 r (er) s 9 r (la) s 121 c -1 r (er) s 8 r (infrastructure) s 10 r (has) s 11 r 98 c 1 r (een) s 12 r (deplo) s 121 c -1 r (ed.) s 224 1740 p (Th) s (us,) s 18 r (the) s 18 r (In) s (ternet) s 18 r (Directory) s 17 r (Service) s 18 r (will) s 17 r (decouple) s 19 r (deplo) s (ymen) s -1 r 116 c 16 r (of) s 18 r (the) s 18 r (OSI) s 224 1796 p (Directory) s 14 r (from) s 13 r (deplo) s (ymen) s -1 r 116 c 13 r (of) s 14 r (the) s 15 r (OSI) s 16 r (lo) s 119 c -1 r (er) s 13 r (la) s 121 c -1 r (ers.) s 17 r (The) s 16 r (In) s (ternet) s 14 r (Directory) s 224 1852 p (Service) s 12 r (will) s 10 r (not) s 12 r (mak) s -1 r 101 c 10 r (an) s 121 c 10 r (mandatory) s 10 r (requiremen) s (t) s -1 r 115 c 10 r (ab) s 1 r (out) s 12 r (use) s 12 r (of) s 11 r (lo) s 119 c -2 r (er) s 10 r (la) s 121 c -1 r (ers.) s 224 1909 p (When) s 20 r (con\014guring) s 20 r (the) s 19 r (In) s (ternet) s 19 r (Directory) s 19 r (Services,) s 20 r 118 c -2 r (ariations) s 18 r (in) s 19 r (the) s 20 r (lo) s 119 c -1 r (er) s 224 1965 p (la) s 121 c -1 r (ers) s 13 r 109 c (ust) s 13 r 98 c 1 r 101 c 16 r (considered.) s 20 r (The) s 15 r (follo) s (w) s -1 r (ing) s 13 r (options) s 15 r (are) s 14 r 112 c 1 r (ossible:) s cmsy10.329 @sf 292 2088 p 15 c cmr10.329 @sf 23 r (Use) s 14 r (of) s 13 r (OSI) s 14 r (Net) s 119 c -1 r (ork) s 11 r (Service) s 14 r (\(Connection) s 13 r (Orien) s (ted) s 13 r (or) s 13 r (Connectionless\).) s 338 2145 p (It) s 15 r (is) s 15 r (seen) s 15 r (as) s 15 r (fundamen) s (tal) s 13 r (to) s 14 r (allo) s 119 c 13 r (use) s 15 r (of) s 15 r (the) s 15 r (OSI) s 17 r (lo) s 119 c -2 r (er) s 13 r (la) s 121 c -1 r (ers.) s cmsy10.329 @sf 292 2238 p 15 c cmr10.329 @sf 23 r (Op) s 1 r (eration) s 17 r 111 c 118 c -1 r (er) s 15 r (TCP/IP) s 17 r (using) s 17 r (RF) s 67 c 15 r (1006) s 16 r 91 c 82 c (C87) s -2 r (].) s 26 r (This) s 16 r (is) s 17 r 97 c 17 r (practical) s 338 2294 p (requiremen) s 116 c 8 r (of) s 11 r (deplo) s (ymen) s -1 r 116 c 9 r (at) s 10 r 118 c (ery) s 10 r (man) s 121 c 9 r (In) s (ternet) s 10 r (sites,) s 11 r (and) s 11 r (is) s 11 r (the) s 11 r (basis) s 338 2350 p (of) s 15 r (the) s 15 r (existing) s 14 r (services.) s cmsy10.329 @sf 292 2443 p 15 c cmr10.329 @sf 23 r (X.25\(80\)) s 17 r (will) s 17 r (probably) s 18 r (not) s 19 r 98 c 1 r 101 c 19 r (used) s 20 r (in) s 18 r (the) s 19 r (core) s 19 r (infrastructure) s 18 r (of) s 18 r (the) s 338 2500 p (In) s (ternet) s 9 r (Directory) s 10 r (Service,) s 11 r (but) s 10 r (is) s 10 r (the) s 11 r (basis) s 10 r (of) s 10 r (some) s 9 r (Europ) s 1 r (ean) s 11 r (activities.) s 338 2556 p (It) s 18 r (ma) s -1 r 121 c 16 r 98 c 1 r 101 c 19 r (needed) s 19 r (later) s 17 r (to) s 17 r (in) s (terconnect) s 17 r (with) s 17 r (US) s 18 r (commercia) s -1 r 108 c 16 r (systems) s 338 2613 p (not) s 15 r (on) s 16 r (the) s 16 r (In) s (ternet.) s 21 r (There) s 16 r (will) s 14 r 98 c 1 r 101 c 17 r 97 c 15 r (practical) s 15 r (need) s 17 r (to) s 15 r (in) s (terw) s -1 r (or) s -1 r 107 c 14 r (with) s 338 2669 p (DSAs) s 15 r (whic) s 104 c 14 r (only) s 15 r (supp) s 1 r (ort) s 15 r (this) s 15 r (stac) s (k.) s 224 2792 p (This) s 15 r (approac) s 104 c 14 r (has) s 15 r (the) s 15 r (follo) s -1 r (wing) s 13 r (implicati) s -1 r (ons.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 54 c @eop 7 @bop0 cmbx10.329 @sf [ 36 31 -2 0 41] 75 @dc cmr10.329 @sf [<00000F8000001FC000001FE000001FE000003FF000003C70000038300000301000003010003FE01000FFF00003F87C0007F0 7E000F38CF001F3F8F801E0F07803C0003C07C0003E07C0003E0780001E0F80001F0F80001F0F80001F0F80001F0F80001F0 F80001F0F80001F0F80001F0F80001F0780001E07C0003E03C0003C03C0003C01E0007801F000F800F000F0007C03E0003E0 7C0000FFF000003FC000> 28 40 -3 9 35] 81 @dc cmbx10.329 @sf [ 30 31 -2 0 36] 80 @dc cmr12.300 @sf [<03800007C00007C00007C00007C00007C00007C00007C00007C00003C00003C00003C00003C00001C00001E00001E00000E0 0000E000007000007000003800001800001C00C00E00C00600C00700E003806001807FFFC07FFFE07FFFE07FFFE070000060 0000> 19 34 -3 0 24] 55 @dc 7 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 280 195 p (1.) s 22 r (There) s 18 r (is) s 17 r 97 c 17 r (need) s 19 r (to) s 17 r (represen) s 116 c 17 r (TCP/IP) s 17 r (addresses) s 18 r (within) s 17 r (OSI) s 19 r (Net) s 119 c -1 r (ork) s 338 252 p (Addresses.) s 20 r (This) s 15 r (is) s 15 r (sp) s 1 r (eci\014ed) s 16 r (in) s 15 r (RF) s 67 c 14 r (12XX) s 15 r 91 c (Kil89a) s -2 r (].) s 280 345 p (2.) s 22 r (It) s 14 r (will) s 13 r 98 c 1 r 101 c 15 r (desirable) s 14 r (to) s 14 r (ha) s 118 c -1 r 101 c 13 r 97 c 14 r (uniform) s 12 r (metho) s 1 r 100 c 14 r (to) s 14 r (presen) s 116 c 13 r (Net) s 119 c -1 r (ork) s 12 r (Ad-) s 338 402 p (dresses) s 15 r (of) s 14 r (this) s 15 r (st) s (yle.) s 18 r (Therefore) s 14 r 97 c 15 r (string) s 14 r (represen) s (tation) s 13 r (of) s 14 r (presen) s (tation) s 338 458 p (addresses) s 15 r (is) s 15 r (sp) s 1 r (eci\014ed) s 16 r (in) s 15 r (RF) s 67 c 14 r (12XX) s 15 r 91 c (Kil89b) s -1 r (].) s 280 552 p (3.) s 22 r (This) s 15 r (approac) s 104 c 13 r (leads) s 15 r (to) s 15 r (the) s 15 r (situation) s 14 r (where) s 15 r (not) s 15 r (all) s 14 r (DSAs) s 15 r (can) s 16 r (comm) s -2 r (u-) s 338 609 p (nicate) s 14 r (directly) s 14 r (due) s 15 r (the) s 14 r (di\013eren) s 116 c 13 r 99 c (hoice) s 13 r (of) s 14 r (lo) s 119 c -1 r (er) s 12 r (la) s 121 c -1 r (ers.) s 17 r (This) s 14 r (is) s 14 r (already) s 338 665 p 97 c 16 r (practical) s 15 r (result) s 16 r (of) s 16 r (man) s 121 c 14 r (Europ) s 1 r (ean) s 17 r (sites) s 16 r (op) s 1 r (erating) s 16 r (DSAs) s 16 r 111 c 118 c -1 r (er) s 15 r (X.25.) s 338 721 p (There) s 16 r (ma) s -1 r 121 c 15 r 98 c 1 r 101 c 16 r 97 c 16 r (requiremen) s 116 c 14 r (to) s 15 r (extend) s 17 r (the) s 16 r (distributed) s 16 r (op) s 1 r (erations,) s 15 r (so) s 338 778 p (that) s 17 r (there) s 18 r (is) s 17 r (no) s 18 r (requiremen) s 116 c 16 r (for) s 17 r (full) s 17 r (connectivit) s 121 c -4 r 46 c 26 r 65 c 18 r (solution) s 17 r (to) s 17 r (this) s 338 834 p (problem) s 14 r (is) s 14 r (sp) s 1 r (eci\014ed) s 17 r (in) s 15 r (RF) s 67 c 14 r (12XX) s 14 r 91 c (Kil91b) s -1 r (].) s 280 928 p (4.) s 22 r (When) s 19 r (the) s 19 r (In) s (ternet) s 18 r (Directory) s 17 r (Service) s 19 r (is) s 19 r (deplo) s 121 c -1 r (ed,) s 18 r (the) s 19 r (issue) s 18 r (of) s 19 r (whic) s 104 c 338 985 p (DSAs) s 17 r (op) s 1 r (erate) s 17 r (whic) s 104 c 16 r (stac) s (ks) s 15 r 109 c (ust) s 15 r 98 c 1 r 101 c 17 r (considered) s 18 r (in) s 17 r (order) s 17 r (to) s 16 r (ac) s (hiev) s 101 c 15 r 97 c 338 1041 p (coheren) s 116 c 14 r (service.) s 20 r (This) s 15 r (will) s 13 r 98 c 1 r 101 c 16 r (tac) s (kled) s 14 r (as) s 15 r (an) s 15 r (op) s 1 r (erational) s 14 r (issue.) s cmbx10.329 @sf 224 1181 p (6.1.3) s 52 r (Replication) s 17 r (of) s 18 r (Kno) s (wledge) s 15 r (and) s 18 r (Data) s cmr10.329 @sf 224 1286 p (There) s 14 r (are) s 13 r 97 c 13 r 110 c (um) s -1 r 98 c 1 r (er) s 11 r (of) s 13 r (requiremen) s (ts) s 11 r (on) s 14 r (replication,) s 12 r 98 c 1 r (oth) s 13 r (of) s 13 r (data) s 13 r (and) s 13 r (kno) s (wl-) s 224 1343 p (edge) s 18 r (informatio) s -1 r (n,) s 17 r (whic) s 104 c 16 r 109 c (ust) s 15 r 98 c 1 r 101 c 19 r (met) s 16 r 98 c 1 r (efore) s 19 r (an) s 17 r (In) s (ternet) s 17 r (Directory) s 17 r (can) s 18 r 98 c 1 r 101 c 224 1399 p (deplo) s 121 c (ed.) s 35 r (The) s 21 r (1988) s 19 r (standard) s 21 r (cannot) s 20 r 98 c 1 r 101 c 22 r (used) s 21 r (as) s 20 r (is.) s 36 r (Three) s 21 r (solutions) s 20 r (are) s 224 1455 p (noted:) s cmsy10.329 @sf 292 1581 p 15 c cmr10.329 @sf 23 r 87 c -3 r (ait) s 13 r (un) s (til) s 13 r (the) s 15 r (1992) s 15 r (standard) s 14 r (is) s 15 r 97 c 118 c -2 r (ai) s -1 r (lable) s cmsy10.329 @sf 292 1675 p 15 c cmr10.329 @sf 23 r 65 c (ttem) s -1 r (pt) s 15 r (to) s 16 r (in) s (tercept) s 15 r (the) s 17 r (1992) s 15 r (standard,) s 16 r (probably) s 17 r 98 c 121 c 15 r (sp) s 1 r (eci\014cation) s 17 r (of) s 338 1732 p (subset) s 16 r (functionalit) s 121 c 14 r (based) s 17 r (on) s 16 r (the) s 16 r (curren) s 116 c 16 r 119 c (orki) s -1 r (ng) s 15 r (do) s 1 r (cumen) s (ts,) s 14 r (and) s 17 r (in) s 338 1788 p (particular) s 14 r (the) s 15 r (CD) s 15 r (on) s 15 r (replication) s 14 r 91 c (CCI90) s -1 r (].) s cmsy10.329 @sf 292 1882 p 15 c cmr10.329 @sf 23 r (Use) s 15 r (an) s 15 r (in) s (terim) s 12 r (approac) s 104 c 224 2008 p (These) s 16 r (issues) s 15 r (are) s 15 r (discussed) s 15 r (in) s 15 r (more) s 14 r (detail) s 14 r (in) s 15 r (RF) s 67 c 14 r (12XX) s 15 r 91 c (Kil91c) s -1 r (].) s 224 2084 p (The) s 21 r (third) s 20 r (approac) s 104 c 19 r (will) s 20 r 98 c 1 r 101 c 21 r (tak) s (en) s 19 r (initially) s -4 r 46 c 34 r (It) s 21 r (will) s 19 r 98 c 1 r 101 c 22 r (clearly) s 19 r (emphasised) s 224 2140 p (that) s 18 r (this) s 17 r (is) s 18 r (an) s 18 r (in) s (terim) s 15 r (approac) s (h,) s 17 r (whic) s 104 c 17 r (will) s 17 r 98 c 1 r 101 c 18 r (phased) s 19 r (out) s 18 r (as) s 18 r (so) s 1 r (on) s 18 r (as) s 17 r (the) s 224 2197 p (appropriate) s 13 r (standards) s 13 r (are) s 14 r 97 c 118 c -2 r (a) s -1 r (ila) s -1 r (ble) s 12 r (and) s 14 r (stable.) s 19 r (An) s 14 r (in) s (terim) s 11 r (approac) s (h,) s 12 r (based) s 224 2253 p (on) s 10 r (the) s 11 r (approac) s 104 c 8 r (used) s 11 r (in) s 10 r (the) s 11 r (QUIPU) s 11 r (Implemen) s -1 r (ta) s -1 r (tio) s -1 r 110 c 9 r (and) s 10 r (deplo) s 121 c (ed) s 8 r (in) s 10 r (existing) s 224 2309 p (pilots) s 11 r (will) s 11 r 98 c 1 r 101 c 13 r (used) s 12 r 91 c (Kil88) s -1 r (].) s 18 r (This) s 12 r (approac) s 104 c 11 r (is) s 12 r (sp) s 1 r (eci\014ed) s 13 r (in) s 12 r (RF) s 67 c 11 r (12XX) s 11 r 91 c (Kil91b) s -1 r (].) s cmbx10.329 @sf 224 2449 p (6.1.4) s 52 r (Presen) s -1 r (tation) s 16 r (of) s 18 r (Directory) s 16 r (Nam) s -1 r (es) s cmr10.329 @sf 224 2554 p (The) s 19 r (standard) s 17 r (do) s 1 r (es) s 19 r (not) s 17 r (sp) s 1 r (ecify) s 19 r 97 c 18 r (means) s 17 r (to) s 17 r (presen) s 116 c 17 r (directory) s 18 r (names) s 17 r (to) s 17 r (the) s 224 2611 p (user.) s 38 r (This) s 20 r (is) s 21 r (seen) s 21 r (as) s 21 r 97 c 20 r (serious) s 21 r (de\014ciency) s -3 r 44 c 22 r (and) s 21 r 97 c 21 r (standard) s 21 r (for) s 20 r (presen) s (ting) s 224 2667 p (directory) s 12 r (names) s 12 r (is) s 13 r (required.) s 19 r (The) s 13 r (\\User) s 12 r 70 c -3 r (riendly) s 12 r (Name") s 11 r (syn) s (tax) s 12 r (is) s 12 r 99 c (hosen) s 12 r (for) s 224 2724 p (represen) s (ting) s 12 r (directory) s 13 r (names) s 13 r (on) s 13 r (the) s 14 r (In) s (ternet,) s 13 r (and) s 13 r (is) s 13 r (sp) s 1 r (eci\014ed) s 15 r (in) s 14 r (RF) s 67 c 12 r (12XX) s 224 2780 p 91 c (Kil90) s -1 r (].) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 55 c @eop 8 @bop0 cmr10.329 @sf [ 16 20 -1 0 20] 122 @dc cmbx12.300 @sf [<7FFC007FFC007FFC000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0 000FC0000FC000FFFC00FFFC00FFFC000FC0000FC0000FC0000FC0000FC0000FC0000FC3C00FC7E007E7E007E7E003F7E001 FFC0003F80> 19 35 -1 0 17] 102 @dc cmbx10.329 @sf [<001FF80000FFFF0001F81F8007F00FE00FE007F01FC003F83F8001FC3F8001FC7F8001FE7F0000FE7F0000FEFF0000FFFF00 00FFFF0000FFFF0000FFFF0000FFFF0000FFFF0000FFFF0000FFFF0000FF7F0000FE7F0000FE7F8001FE3F8001FC1F8001F8 1FC003F80FE007F007F00FE001F81F8000FFFF00001FF800> 32 31 -3 0 39] 79 @dc cmr12.300 @sf [<03F8000FFE003E0F007C03807801C0F001C0E000E0E000E0E000E0E001E0E001E07007E0780FE0383FC01E7F800FFF8007FF 000FFC001FFC003FFF003FC7807F03807C03C07801C07001C07001C07001C03803C03C07801E1F000FFE0003F800> 19 32 -2 0 24] 56 @dc 8 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmbx10.329 @sf 224 195 p (6.1.5) s 52 r (DSA) s 17 r (Nam) s -1 r (i) s -1 r (ng) s 16 r (and) s 18 r (MD) s 17 r (Structure) s cmr10.329 @sf 224 300 p (There) s 12 r (are) s 11 r (some) s 9 r (critical) s 10 r (issues) s 11 r (related) s 11 r (to) s 11 r (naming) s 9 r (of) s 11 r (DSAs) s 11 r (and) s 12 r (the) s 11 r (structure) s 11 r (of) s 224 357 p (Directory) s 15 r (Managemen) s -1 r 116 c 13 r (Domains.) s 20 r (These) s 16 r (will) s 15 r 98 c 1 r 101 c 16 r (signi\014can) s 116 c 14 r (as) s 15 r (the) s 16 r (directory) s 224 413 p (increases) s 19 r (in) s 19 r (size) s 19 r 98 c 121 c 18 r (orders) s 19 r (of) s 19 r (magnitude.) s 31 r (The) s 19 r (OSI-DS) s 20 r 87 c 71 c 18 r (is) s 18 r 119 c (orking) s 17 r (to) s 224 470 p (dev) s (elop) s 14 r 97 c 15 r (solution) s 14 r (in) s 15 r (this) s 15 r (area) s 14 r 91 c (Kil91a) s -1 r (].) s cmbx12.300 @sf 224 611 p (6.2) s 56 r (Infrastructure) s cmr10.329 @sf 224 716 p (In) s 15 r (order) s 15 r (to) s 14 r (e\013ectiv) s (ely) s 12 r (deplo) s 121 c 13 r (the) s 15 r (In) s (ternet) s 14 r (Directory) s 13 r (Service,) s 15 r (there) s 14 r (is) s 14 r 97 c 15 r (need) s 224 773 p (to) s 18 r (ensure) s 18 r (that) s 18 r (appropriate) s 17 r (comp) s 1 r (onen) s (ts.) s 26 r (The) s 18 r (DISI) s 19 r (\(Directory) s 17 r (Informatio) s -1 r 110 c 224 829 p (Services) s 18 r (Infrastructure\)) s 17 r 87 c 71 c 15 r (is) s 17 r (pla) s (ying) s 15 r 97 c 17 r 107 c (ey) s 16 r (role) s 17 r (in) s 17 r (de\014ning) s 18 r (necessary) s 17 r (in-) s 224 886 p (frastructure) s 15 r (comp) s 1 r (onen) s (ts.) s cmbx10.329 @sf 224 1025 p (6.2.1) s 52 r (Im) s -2 r (plem) s -4 r (en) s -1 r (tations) s cmr10.329 @sf 224 1131 p (An) s 14 r (e\013ectiv) s 101 c 12 r (service) s 14 r (will) s 13 r (need) s 15 r (to) s 13 r (ha) s 118 c -1 r 101 c 12 r (su\016cien) s 116 c 13 r (implem) s -1 r (en) s -1 r (tati) s -1 r (ons,) s 12 r (in) s 13 r (order) s 14 r (to) s 224 1187 p (giv) s 101 c 9 r (full) s 10 r (co) s 118 c (erag) s -1 r 101 c 9 r 111 c 118 c (er) s 8 r (di\013eren) s 116 c 9 r (mac) s (hine) s 9 r 116 c (yp) s 1 r (es,) s 10 r (and) s 12 r (to) s 10 r (demonstrate) s 9 r (op) s 1 r (enness.) s 224 1244 p (The) s 12 r (recen) s 116 c 10 r (DISI) s 12 r (Surv) s (ey) s 11 r (of) s 11 r (Directory) s 10 r (Implemen) s -1 r (tat) s -1 r (ion) s 9 r (suggests) s 11 r (that) s 10 r (there) s 12 r (will) s 224 1300 p (not) s 15 r 98 c 1 r 101 c 16 r 97 c 15 r (problem) s 14 r (here) s 15 r 91 c 76 c -4 r (W91) s -2 r (].) s 224 1376 p (When) s 13 r (su\016cien) s 116 c 10 r (exp) s 1 r (erience) s 13 r (is) s 12 r (gained,) s 12 r 97 c 12 r (Directory) s 10 r (Requiremen) s (ts) s 11 r (sp) s 1 r (eci\014cation) s 224 1432 p (should) s 15 r 98 c 1 r 101 c 16 r (written.) s cmbx10.329 @sf 224 1572 p (6.2.2) s 52 r (Cen) s (tral) s 15 r (Op) s 1 r (erations) s cmr10.329 @sf 224 1677 p (There) s 17 r (is) s 16 r 97 c 17 r (need) s 17 r (for) s 16 r 97 c 16 r 110 c (um) s -1 r 98 c 1 r (er) s 15 r (of) s 17 r (op) s 1 r (erations) s 15 r (to) s 16 r 98 c 1 r 101 c 18 r (managed) s 15 r (as) s 16 r 97 c 17 r (service) s 16 r (for) s 224 1734 p (the) s 15 r (whole) s 15 r (in) s (ternet.) s 18 r (These) s 16 r (services) s 15 r (are:) s cmbx10.329 @sf 224 1859 p (Nam) s -1 r 101 c 15 r (Assignm) s -3 r (en) s -1 r 116 c cmr10.329 @sf 21 r (Instan) s (tiati) s -1 r (ng) s 11 r (names) s 12 r (in) s (to) s 11 r (the) s 13 r (Directory) s -3 r 46 c 17 r (This) s 13 r (could) s 13 r 98 c 1 r 101 c 338 1915 p (done) s 12 r (in) s 12 r (conjunction) s 12 r (with) s 12 r (the) s 12 r (appropriate) s 11 r (Registration) s 11 r (Authorit) s 121 c 10 r (or) s 12 r 98 c 121 c 338 1972 p (the) s 13 r (Registration) s 11 r (Authorit) s 121 c -4 r 46 c 17 r (In) s 14 r (most) s 11 r (cases,) s 13 r (it) s 12 r (is) s 12 r (lik) s (ely) s 11 r (to) s 12 r 98 c 1 r 101 c 14 r (the) s 13 r (former,) s 338 2028 p (and) s 18 r (mec) s (hanis) s -1 r (m) s -1 r 115 c 16 r (will) s 16 r (need) s 19 r (to) s 17 r 98 c 1 r 101 c 18 r (set) s 18 r (up) s 18 r (to) s 17 r (allo) s -1 r 119 c 16 r (organisati) s -1 r (ons) s 16 r (to) s 17 r (get) s 338 2085 p (their) s 15 r (names) s 14 r (instan) s (tia) s -1 r (ted) s 14 r (in) s (to) s 13 r (the) s 16 r (directory) s -3 r 44 c 13 r (either) s 15 r (directly) s 15 r (or) s 15 r (through) s 338 2141 p (the) s 15 r (registration) s 13 r (authorit) s -1 r 121 c -3 r 46 c cmbx10.329 @sf 224 2235 p (Kno) s (wledge) s 16 r (Managem) s -1 r (en) s -2 r 116 c cmr10.329 @sf 21 r (DSAs) s 10 r (will) s 9 r 98 c 1 r 101 c 11 r (established) s 10 r 98 c 121 c 9 r (Organisations.) s 16 r (There) s 338 2291 p (will) s 15 r 98 c 1 r 101 c 17 r 97 c 17 r (need) s 17 r (to) s 16 r (cen) s (trally) s 14 r (manage) s 15 r (kno) s (wledge) s 16 r (informa) s -1 r (tio) s -1 r 110 c 15 r (asso) s 1 r (ciated) s 338 2348 p (with) s 12 r (these) s 13 r (DSAs.) s 20 r (This) s 12 r (is) s 13 r (lik) s (ely) s 11 r (to) s 12 r 98 c 1 r 101 c 14 r (coupled) s 13 r (to) s 13 r (the) s 13 r (name) s 12 r (assignmen) s -1 r (t.) s cmbx10.329 @sf 224 2441 p (Kno) s (wledge) s 16 r (and) s 18 r (Data) s 18 r (Replication) s cmr10.329 @sf 23 r 70 c -3 r (or) s 22 r (the) s 24 r (directory) s 24 r (to) s 23 r 112 c 1 r (erform) s 23 r 119 c (ell,) s 338 2498 p (kno) s (wledge) s 13 r (and) s 14 r (data) s 14 r (high) s 14 r (up) s 14 r (the) s 15 r (DIT) s 14 r 109 c -1 r (ust) s 13 r 98 c 1 r 101 c 14 r (signi\014can) s (tly) s 12 r (replicated.) s 338 2554 p 65 c 17 r (service) s 18 r 109 c -1 r (ust) s 15 r 98 c 1 r 101 c 18 r (pro) s (vided) s 17 r (to) s 16 r (mak) s 101 c 15 r (replicated) s 17 r (informati) s -1 r (on) s 16 r 97 c 118 c -2 r (a) s -1 r (ila) s -1 r (ble) s 338 2611 p (to) s 14 r (organisations) s 13 r (that) s 15 r (need) s 16 r (it.) s 224 2736 p (These) s 20 r (services) s 19 r (need) s 20 r (to) s 19 r 98 c 1 r 101 c 20 r (pro) s (vided) s 18 r (at) s 19 r (the) s 19 r (ro) s 1 r (ot) s 19 r (lev) s (el,) s 18 r (and) s 20 r (at) s 18 r (the) s 20 r (national) s 224 2792 p (lev) s (el) s 14 r (for) s 14 r (ev) s (ery) s 14 r (coun) s (try) s 14 r (participating) s 13 r (in) s 15 r (the) s 16 r (In) s (ternet) s 14 r (Directory) s 14 r (Service.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 56 c @eop 9 @bop0 cmr10.329 @sf [<1FE03F807FF8FFE07C3DF870F81FE038F00FC018F00F8000F80F8000780F00007E0F00001FEF000003FFFFF8000FFFF8000F 0038000F0038380F80787C0F80707C1FC0F07C3FF1E07FFCFFC01FF03F80> 29 20 -2 0 33] 26 @dc cmbx10.329 @sf [<0001C0007000000003C0007800000003E000F800000007E000FC00000007F001FC00000007F001FC0000000FF001FE000000 0FF803FE0000000FF803FE0000001FF803FF0000001FDC07F70000003FDC07F78000003F9E0FF38000003F8E0FE38000007F 8E0FE1C000007F0F1FE1C000007F071FC1C00000FE071FC0E00000FE03BF80E00001FE03BF80F00001FC03BF80700001FC01 FF00700003FC01FF00780003F801FF00380003F800FE00380007F000FE001C0007F001FC001C000FF001FC001E00FFFF1FFF C1FFE0FFFF1FFFC1FFE0FFFF1FFFC1FFE0> 51 31 -1 0 54] 87 @dc cmbx10.432 @sf [<0078000000FC000001FE000001FE000001FE000001FE000001FE000001FE000001FE000001FE000000FE000000FE000000FE 000000FE0000007E0000007E0000007F0000003F0000003F0000003F0000001F0000000F8000000F80000007C0000007C000 E003E000E001F000E000F8007000780070007C0070003E007FFFFF007FFFFF807FFFFFC07FFFFFC03FFFFFE03FFFFFF03FFF FFF03FFFFFF03E00000038000000> 28 41 -4 0 34] 55 @dc cmbx12.300 @sf [<01E00003F00003F00003F00003F00003F00003F00003F00001F00001F00001F00001F00000F80000F80000F800007800003C 00003C00001E00001E00000F00E00780E003C0E001C0E001E0F000F07FFFF87FFFFC7FFFFE7FFFFE7FFFFE7FFFFE7C000070 0000> 23 34 -3 0 28] 55 @dc [ 37 34 -2 0 43] 68 @dc [<1F0000007FC0000079E00000FC700000FC780000FC380000783C0000001C0000001C0000000E0000000E0000001F0000001F 0000003F8000003F8000007FC000007FC000007FC00000FCE00000FCE00001FCF00001F8700003F8780003F0380003F03800 07E01C0007E01C000FE01E000FC00E00FFF03FE0FFF03FE0FFF03FE0> 27 32 -1 10 30] 121 @dc [ 32 34 -2 0 38] 80 @dc [<000E0000001F0000001F0000003F8000003F8000007FC000007FC000007FC00000FCE00000FCE00001FCF00001F8700003F8 780003F0380003F0380007E01C0007E01C000FE01E000FC00E00FFF03FE0FFF03FE0FFF03FE0> 27 22 -1 0 30] 118 @dc [ 37 34 -2 0 42] 65 @dc 9 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 224 195 p (Before) s 22 r (discussing) s 21 r (the) s 22 r (prop) s 1 r (osed) s 21 r (direction,) s 23 r (it) s 20 r (is) s 21 r 119 c (orth) s 20 r (noting) s 21 r (ho) s 119 c 20 r (in) s (terim) s 224 252 p (pilots) s 14 r (ha) s 118 c 101 c 13 r 98 c 1 r (een) s 17 r (established.) s 20 r (The) s 16 r (initial) s 14 r (op) s 1 r (eration) s 14 r (of) s 15 r (the) s 16 r (existing) s 14 r (directory) s 224 308 p (activities) s 14 r (is) s 14 r (under) s 16 r (the) s 15 r (\032gis) s 15 r (of) s 15 r 116 c 119 c -2 r 111 c 13 r (pro) s 3 r (jects:) s cmbx10.329 @sf 224 434 p (PSI) s 17 r (White) s 17 r 80 c (ages) s 16 r (Pilot) s cmr10.329 @sf 338 509 p (This) s 18 r (is) s 17 r 97 c 18 r (pilot) s 17 r (service,) s 19 r (whic) s 104 c 17 r (is) s 17 r (op) s 1 r (eration) s 18 r (X.500) s 17 r (on) s 18 r (the) s 18 r (In) s (ternet.) s 28 r (In) s 338 565 p (man) s -1 r 121 c 14 r 119 c 97 c -1 r (ys) s 13 r (it) s 14 r (is) s 15 r (op) s 1 r (erating) s 14 r (as) s 15 r (an) s 15 r (In) s (ternet-wide) s 15 r (directory) s 14 r (pilot.) s cmbx10.329 @sf 224 659 p 70 c 79 c -1 r 88 c cmr10.329 @sf 338 734 p (Fielding) s 14 r (Op) s 1 r (erational) s 14 r (X.500,) s 14 r (whic) s 104 c 14 r (is) s 15 r (exploring) s 15 r (the) s 15 r (in) s (terop) s 1 r (erabili) s -1 r 116 c -1 r 121 c 13 r (of) s 338 791 p (X.500) s 14 r (implem) s -1 r (en) s -1 r (tati) s -1 r (ons.) s 224 917 p (The) s 22 r (top) s 21 r (lev) s (el) s 19 r (of) s 21 r (the) s 22 r (DIT) s 21 r (has) s 21 r 98 c 1 r (een) s 23 r (managed) s 20 r 98 c 121 c 20 r (the) s 22 r 80 c -3 r (ARADISE) s 21 r (pro) s 3 r (ject) s 224 973 p (\(Piloting) s 15 r 97 c 17 r (ReseArc) s 104 c 17 r (DIrectory) s 16 r (Service) s 17 r (in) s 17 r (Europ) s 1 r (e\).) s 26 r (This) s 16 r (pro) s 3 r (ject) s 16 r (has) s 17 r 98 c 1 r (een) s 224 1030 p (pro) s (viding) s 11 r (the) s 13 r (necessary) s 14 r (glue) s 13 r (to) s 12 r (hold) s 13 r (the) s 13 r 118 c -2 r (arious) s 12 r (national) s 11 r (activities) s 12 r (together.) s 224 1106 p (It) s 12 r (is) s 11 r (prop) s 1 r (osed) s 11 r (that) s 11 r (the) s 11 r 80 c -3 r (ARADISE) s 12 r (pro) s 3 r (ject) s 11 r (should) s 11 r 98 c 1 r 101 c 12 r (used) s 12 r (as) s 11 r (the) s 12 r (initial) s 9 r (basis) s 224 1162 p (for) s 13 r (handling) s 13 r (the) s 14 r (top) s 13 r (lev) s (el.) s 17 r (Eac) s 104 c 13 r (participating) s 11 r (coun) s (try) s 12 r (will) s 13 r (need) s 14 r (to) s 13 r (de\014ne) s 14 r (its) s 224 1219 p 111 c (wn) s 14 r (approac) s 104 c 14 r (for) s 14 r (name) s 14 r (assignmen) s 116 c 13 r (and) s 15 r (kno) s (wledge) s 14 r (managem) s -1 r (en) s -1 r (t.) s 224 1295 p (It) s 17 r (ma) s -1 r 121 c 15 r 98 c 1 r 101 c 18 r (useful) s 17 r (to) s 16 r (pro) s (vide) s 15 r 97 c 17 r (comp) s 1 r (onen) s 116 c 14 r (of) s 17 r (the) s 17 r (In) s (ternet) s 16 r (Directory) s 15 r (Service) s 224 1351 p (to) s 15 r (o\013er) s 14 r (replicated) s 15 r (data) s 14 r (whic) s 104 c 14 r (is) s 15 r (not) s 15 r (structured) s 15 r (on) s 15 r 97 c 15 r 112 c 1 r (er-coun) s (try) s 15 r (basis.) s cmbx10.329 @sf 224 1491 p (6.2.3) s 52 r (Site) s 17 r (Supp) s 1 r (ort) s cmr10.329 @sf 224 1596 p (There) s 14 r (is) s 14 r 97 c 13 r (need) s 15 r (to) s 14 r (plan) s 13 r (the) s 14 r (supp) s 1 r (ort) s 14 r (needed,) s 16 r 98 c 1 r (oth) s 14 r (for) s 13 r (participating) s 12 r (sites) s 13 r (and) s 224 1652 p (users.) s 33 r (The) s 20 r (DISI) s 20 r 87 c 71 c 18 r (is) s 19 r (lo) s 1 r (oking) s 18 r (at) s 19 r (the) s 19 r (issue) s 20 r (of) s 19 r (necessary) s 19 r (do) s 1 r (cumen) s (tation,) s 224 1709 p (and) s 16 r 97 c 14 r 110 c (um) s -1 r 98 c 1 r (er) s 14 r (of) s 15 r (pap) s 1 r (ers) s 15 r (are) s 15 r 98 c 1 r (eing) s 16 r (prepared.) s 224 1785 p (It) s 14 r 119 c (ould) s 13 r 98 c 1 r 101 c 15 r (useful) s 14 r (to) s 14 r (ha) s 118 c -1 r 101 c 12 r (site) s 14 r (supp) s 1 r (ort) s 14 r (for) s 14 r (directory) s 13 r (op) s 1 r (eration) s 14 r (in) s (tegra) s -1 r (ted) s 13 r (in) s 224 1841 p (with) s 15 r (the) s 15 r (curren) s 116 c 14 r (NOCs.) s cmbx10.432 @sf 224 2004 p 55 c 69 r (Securit) s -1 r 121 c cmr10.329 @sf 224 2125 p 65 c 15 r (Directory) s 14 r (and) s 16 r (Securit) s 121 c 13 r (are) s 15 r (closely) s 15 r (related.) s 19 r (The) s 15 r (directory) s 15 r (is) s 15 r 97 c 14 r (pro) s (vider) s 14 r (of) s 224 2182 p (authen) s (tication) s 13 r (services,) s 14 r (whic) s 104 c 13 r (are) s 15 r (in) s 15 r (turn) s 14 r (used) s 16 r (as) s 14 r (the) s 15 r (basis) s 14 r (for) s 14 r 97 c 15 r 110 c (um) s -1 r 98 c 1 r (er) s 13 r (of) s 224 2238 p (OSI) s 15 r (Services) s 15 r (\(e.g.,) s 13 r (X.400\)) s 12 r (and) s 15 r (non-OSI) s 15 r (Services) s 15 r (\(e.g.,) s 13 r (PEM\).) s 13 r (The) s 14 r (directory) s 224 2295 p (also) s 14 r (mak) s -1 r (es) s 13 r (use) s 16 r (of) s 14 r (these) s 15 r (services) s 15 r (as) s 15 r (the) s 15 r (basis) s 14 r (of) s 14 r 97 c 15 r 110 c (um) s -1 r 98 c 1 r (er) s 13 r (of) s 15 r (secure) s 15 r (features.) s 224 2351 p (The) s 17 r (directory) s 16 r (pro) s (visio) s -1 r 110 c 15 r (of) s 16 r (authen) s (tication) s 15 r (do) s 1 r (es) s 17 r (not) s 16 r (dep) s 1 r (end) s 18 r (on) s 17 r (an) s 121 c 15 r (of) s 16 r (these) s 224 2407 p (features.) s cmbx12.300 @sf 224 2549 p (7.1) s 56 r (Directory) s 18 r (Pro) s -1 r (vision) s 19 r (of) s 19 r (Authen) s -1 r (tication) s cmr10.329 @sf 224 2654 p (The) s 14 r (directory) s 12 r (will) s 12 r 98 c 1 r 101 c 14 r (used) s 13 r (to) s 13 r (pro) s (vide) s 11 r (X.509) s 12 r (strong) s 13 r (authen) s (ticati) s -1 r (on) s 11 r 91 c (CCI88a) s -1 r (].) s 224 2711 p (This) s 17 r (places) s 16 r (minima) s -1 r 108 c 15 r (requiremen) s (t) s -1 r 115 c 15 r (on) s 17 r (the) s 17 r (directory) s -3 r 46 c 23 r 84 c -3 r 111 c 16 r (use) s 17 r (this) s 16 r (infrastruc-) s 224 2767 p (ture,) s 16 r (users) s 17 r (of) s 16 r (authen) s (ticatio) s -1 r 110 c 15 r (services) s 17 r 109 c -1 r (ust) s 14 r (ha) s 118 c 101 c 15 r (access) s 16 r (to) s 16 r (the) s 17 r (directory) s -3 r 46 c 22 r (In) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 899 r 80 c (age) s 15 r 57 c @eop 10 @bop0 cmbx10.329 @sf [ 12 5 -1 -8 17] 45 @dc [<7FF9FFE07FF9FFE07FF9FFE00FC03F000FC03F000FC03F000FC03F000FC03F000FC03F000FC03F000FC03F000FC03F000FC0 3F000FC03F000FC03F000FC03F000FC03F00FFFFFF00FFFFFF00FFFFFF000FC1FF000FC000000FC000000FC07E000FC07E00 0FC07E000FC0FF0007E07E0007F07E0003FC3E0000FFFC00000FF800> 27 32 0 0 29] 12 @dc cmr12.300 @sf [<01F00007FC000E0E001C07003803803803807803C07001C07001C0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001 E0F001E0F001E0F001E0F001E0F001E0F001E07001C07001C07001C03803803803801C07000E0E0007FC0001F000> 19 32 -2 0 24] 48 @dc 10 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 224 195 p (practice,) s 14 r (this) s 13 r 116 c (yp) s 1 r 101 c 13 r (of) s 13 r (authen) s (ticatio) s -1 r 110 c 12 r (can) s 14 r (only) s 14 r 98 c 1 r 101 c 14 r (deplo) s 121 c (ed) s 12 r (on) s 14 r 97 c 13 r (limited) s 12 r (scale) s 224 252 p (without) s 16 r (use) s 18 r (of) s 16 r 97 c 17 r (directory) s -3 r 44 c 15 r (and) s 18 r (so) s 16 r (this) s 17 r (pro) s (visi) s -1 r (on) s 15 r (is) s 17 r (critical) s 15 r (for) s 17 r (applications) s 224 308 p (suc) s 104 c 17 r (as) s 18 r (Priv) s -2 r (acy) s 17 r (Enhanced) s 19 r (Mail.) s 26 r (The) s 19 r (PEM) s 17 r (dev) s (elopmen) s -1 r 116 c 16 r (is) s 17 r (considering) s 18 r (is-) s 224 364 p (sues) s 20 r (relating) s 17 r (to) s 19 r (deplo) s (ying) s 17 r (Certi\014cation) s 18 r (Authorities,) s 18 r (and) s 20 r (this) s 18 r (discussion) s 19 r (is) s 224 421 p (not) s 15 r (duplicated) s 15 r (here.) s cmbx12.300 @sf 224 560 p (7.2) s 56 r (Directory) s 18 r (Securit) s -1 r 121 c cmr10.329 @sf 224 665 p 65 c 15 r 110 c (um) s -1 r 98 c 1 r (er) s 14 r (of) s 15 r (securit) s 121 c 13 r (services) s 15 r (are) s 15 r 112 c 1 r (ossible) s 15 r (with) s 15 r (the) s 15 r (directory:) s cmbx10.329 @sf 224 773 p 80 c (eer) s 15 r (Authen) s (tication) s cmr10.329 @sf 22 r (Authen) s (tication) s 8 r (\(one) s 10 r (or) s 10 r 116 c 119 c -1 r 111 c 7 r 119 c 97 c (y) s -1 r 41 c 8 r 98 c 1 r (et) s 119 c (een) s 9 r (DUA/DSA) s 338 830 p (and) s 15 r (DSA/DSA.) s 15 r (This) s 15 r (is) s 14 r (sp) s 1 r (eci\014ed) s 17 r (in) s 15 r (X.500\(88\)) s -1 r 46 c cmbx10.329 @sf 224 919 p 80 c (er-op) s 1 r (eration) s 16 r (authen) s (tication) s cmr10.329 @sf 23 r (This) s 15 r (is) s 14 r (usually) s 15 r (used) s 16 r (to) s 14 r (iden) s (tify) s 13 r (the) s 16 r (DUA) s 338 975 p (originating) s 15 r (an) s 17 r (op) s 1 r (eration) s 17 r (to) s 17 r (the) s 17 r (Directory) s 16 r (\(e.g.,) s 17 r (to) s 17 r (authen) s (ticate) s 15 r (prior) s 338 1032 p (to) s 17 r (data) s 17 r (mo) s 1 r (di\014cation\).) s 25 r (It) s 18 r (ma) s 121 c 15 r (also) s 17 r 98 c 1 r 101 c 19 r (used) s 18 r (to) s 17 r 118 c (erify) s 16 r (the) s 18 r (DSA) s 18 r (whic) s 104 c 338 1088 p (pro) s (vided) s 14 r (data) s 14 r (bac) s 107 c 14 r (to) s 15 r (the) s 15 r (user.) s 20 r (This) s 15 r (is) s 15 r (sp) s 1 r (eci\014ed) s 16 r (in) s 15 r (X.500\(88\).) s cmbx10.329 @sf 224 1177 p (Single) s 17 r (En) s (try) s 16 r (Access) s 16 r (Con) s (trol) s cmr10.329 @sf 21 r (This) s 10 r (is) s 9 r (used) s 11 r (to) s 10 r (con) s (trol) s 7 r (whic) s 104 c 9 r (users) s 11 r (\(DUAs\)) s 338 1233 p (can) s 24 r (access) s 23 r (and) s 24 r (mo) s 1 r (dify) s 23 r (data) s 23 r (within) s 23 r (an) s 23 r (en) s (try) s -3 r 46 c 43 r (This) s 24 r (is) s 23 r (sp) s 1 r (eci\014ed) s 25 r (in) s 338 1290 p (X.500\(92\)) s 13 r (and) s 15 r (most) s 13 r (DSA) s 16 r (implem) s -1 r (en) s -1 r (tat) s -1 r (ions) s 13 r (pro) s (vide) s 14 r (an) s 15 r (approac) s (h.) s cmbx10.329 @sf 224 1378 p (Multiple) s 16 r (En) s (try) s 16 r (Access) s 17 r (Con) s (trol) s cmr10.329 @sf 20 r (This) s 18 r (is) s 17 r (used) s 18 r (to) s 18 r (con) s (trol) s 15 r (searc) s 104 c 17 r (and) s 18 r (list) s 338 1435 p (op) s 1 r (erations,) s 13 r (in) s 14 r (order) s 13 r (to) s 14 r (allo) s -1 r 119 c 12 r (lo) s 1 r (cation) s 13 r (of) s 13 r (informati) s -1 r (on) s 12 r 98 c 121 c 13 r (searc) s (hing,) s 12 r (but) s 338 1491 p (to) s 14 r (prev) s (en) s 116 c 13 r (tra) s (wli) s -1 r (ng) s 13 r (of) s 15 r (informati) s -1 r (on) s 14 r (and) s 15 r (organisational) s 12 r (structure.) s cmbx10.329 @sf 224 1580 p (Authorisation) s cmr10.329 @sf 22 r (This) s 14 r (allo) s (ws) s 12 r (DSAs) s 15 r (to) s 14 r (con) s (trol) s 12 r (service) s 15 r (in) s 15 r 97 c 14 r (data) s 14 r (indep) s 1 r (enden) s 116 c 338 1637 p (manner,) s 13 r (based) s 15 r (on) s 14 r 112 c 1 r (eer) s 15 r (authen) s (ticati) s -1 r (on.) s 18 r (This) s 14 r (migh) s -1 r 116 c 12 r 98 c 1 r 101 c 15 r (used) s 15 r (to) s 14 r (prev) s (en) s 116 c 338 1693 p (studen) s (ts) s 14 r (from) s 13 r (making) s 14 r (non-lo) s 1 r (cal) s 14 r (queries.) s cmbx10.329 @sf 224 1782 p (Securit) s 121 c 15 r 80 c (olicy) s cmr10.329 @sf 20 r (This) s 18 r (relates) s 17 r (access) s 18 r (con) s (trol,) s 16 r (authorisation,) s 17 r (and) s 18 r (authen) s (ti-) s 338 1838 p (cation,) s 13 r (and) s 15 r 112 c 1 r (ossibly) s 15 r (other) s 14 r (lo) s 1 r (cal) s 14 r (considerations.) s 18 r 70 c -3 r (or) s 13 r (example,) s 14 r (it) s 14 r (migh) s -1 r 116 c 338 1895 p 98 c 1 r 101 c 16 r (required) s 16 r (that) s 15 r (all) s 15 r (mo) s 1 r (di\014cations) s 13 r (ha) s 118 c 101 c 14 r (strong) s 15 r (authen) s (ticati) s -1 r (on) s 14 r (and) s 16 r (are) s 338 1951 p (from) s 13 r 97 c 15 r (mac) s (hine) s 13 r (at) s 15 r 97 c 15 r (kno) s (wn) s 14 r (lo) s 1 r (cation.) s cmbx10.329 @sf 224 2040 p (Data) s 19 r (Con\014den) s (tialit) s -1 r 121 c cmr10.329 @sf 20 r (Prev) s (en) s (t) s -1 r (ing) s 22 r (ea) s 118 c -1 r (esdropping) s 22 r (of) s 24 r (data) s 23 r (as) s 24 r (it) s 23 r (is) s 24 r (trans-) s 338 2096 p (ferred.) s 224 2205 p (Initially) s -3 r 44 c 12 r (there) s 14 r (will) s 13 r 98 c 1 r 101 c 15 r (no) s 14 r (sp) s 1 r (eci\014cation) s 14 r (of) s 14 r (an) s 121 c 13 r (In) s (ternet) s 13 r (securit) s 121 c 13 r (for) s 13 r (directory) s -3 r 46 c 224 2261 p (Deplo) s (ym) s -1 r (en) s -1 r 116 c 13 r (of) s 15 r 97 c 15 r (directory) s 14 r (could) s 16 r 98 c 1 r 101 c 15 r (based) s 16 r (on) s 15 r (one) s 15 r (of:) s cmsy10.329 @sf 292 2369 p 15 c cmr10.329 @sf 23 r (Read) s 17 r (only) s 15 r (system,) s 15 r (con) s (taining) s 14 r (only) s 16 r (public) s 16 r (data) s 16 r (and) s 16 r (using) s 16 r (lo) s 1 r (cal) s 16 r (mo) s 1 r (di-) s 338 2426 p (\014cation.) s cmsy10.329 @sf 292 2514 p 15 c cmr10.329 @sf 23 r (Use) s 19 r (of) s 19 r (X.509) s 18 r (authen) s (ticati) s -1 r (on,) s 18 r (and) s 19 r (priv) s -2 r (ate) s 18 r (access) s 19 r (con) s (trol) s 17 r (mec) s (hanism) s -1 r 115 c 338 2571 p (\(this) s 17 r (will) s 16 r (not) s 18 r (allo) s -1 r 119 c 16 r (op) s 1 r (en) s 19 r (access) s 18 r (con) s (trol) s 15 r (managemen) s -1 r (t,) s 16 r (but) s 18 r (this) s 17 r (is) s 18 r (not) s 338 2627 p (seen) s 16 r (as) s 14 r 97 c 15 r (fundamen) s (tal) s 13 r (problem\)) s 13 r 91 c (CCI88a) s -1 r (].) s 224 2736 p (It) s 18 r (will) s 17 r 98 c 1 r 101 c 19 r (imp) s 1 r (ortan) s -1 r 116 c 16 r (to) s 18 r (understand) s 19 r (securit) s 121 c 16 r (requiremen) s (ts,) s 16 r (and) s 19 r (so) s 18 r (an) s 18 r (RF) s 67 c 224 2792 p (should) s 15 r 98 c 1 r 101 c 16 r (written) s 14 r (to) s 15 r (ev) s -2 r (aluate) s 14 r (this.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 874 r 80 c (age) s 16 r (10) s @eop 11 @bop0 cmbx10.432 @sf [<00FFC00007FFF8000FFFFE001FC07F003F000F807E0007807C0007C0FC0003C0F80003E0F80003E0F80007E0F80007E0F800 1FE0FC007FE07C00FFE07E03FFE03F0FFFC01FBFFFC00FFFFF8007FFFF0003FFFE0007FFFC000FFFF8001FFFFC001FFFFE00 3FFE3F003FF81F003FF01F803FC00F803F000F803E000F803E000F801E001F801E001F000F003F000FC0FE0007FFFC0001FF F800007FC000> 27 39 -3 0 34] 56 @dc [<01FE000007FFC0000FFFE0001F07F8001F01FC003F80FE003FC0FF003FC07F003FC07F803FC07F801F803FC00F003FC00000 3FC000003FC000083FE001FF3FE007FFBFE00FFFFFE01FC0FFE03F80FFE07F807FE07F807FE0FF807FE0FF803FE0FF803FE0 FF803FE0FF803FE0FF803FC0FF803FC0FF803FC0FF803FC07F803F807F803F803F807F001FC07E000FE1FE0007FFFC0003FF F000007FC000> 27 39 -3 0 34] 57 @dc [ 39 41 -3 0 45] 69 @dc [ 33 27 -1 0 36] 120 @dc cmbx10.329 @sf [<001C0000003E0000003E0000007F0000007F000000FF800000FF800000FF800001F9C00001F9C00003F9E00003F0E00007F0 F00007E0700007E070000FC038000FC03800FFF0FF80FFF0FF80FFF0FF80> 25 20 -1 0 28] 118 @dc [ 31 31 -2 0 37] 66 @dc cmr10.329 @sf [ 44 2 0 -11 45] 124 @dc [ 28 12 -3 -5 35] 61 @dc 11 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmbx10.432 @sf 224 195 p 56 c 69 r (Relation) s 21 r (to) s 23 r (DNS) s cmr10.329 @sf 224 316 p (It) s 16 r (is) s 16 r (imp) s 1 r (ortan) s -1 r 116 c 14 r (to) s 15 r (establish) s 15 r (the) s 16 r (relationship) s 15 r 98 c 1 r (et) s 119 c (een) s 15 r (the) s 16 r (prop) s 1 r (osed) s 16 r (In) s (ternet) s 224 373 p (Directory) s -3 r 44 c 16 r (and) s 18 r (the) s 18 r (existing) s 17 r (Domain) s 16 r (Name) s 17 r (System.) s 26 r (An) s 19 r (exp) s 1 r (erimen) s (ta) s -1 r 108 c 16 r (RF) s 67 c 224 429 p (\(RF) s 67 c 16 r (12XX\)) s 17 r (prop) s 1 r (oses) s 18 r 97 c 17 r (mapping) s 17 r (of) s 17 r (DNS) s 18 r (informa) s -1 r (tio) s -1 r 110 c 16 r (on) s (to) s 16 r (the) s 18 r (Directory) s -3 r 46 c 224 485 p (Exp) s 1 r (erimen) s (ts) s 13 r (should) s 15 r 98 c 1 r 101 c 16 r (conducted) s 16 r (in) s 15 r (this) s 15 r (area) s 15 r 91 c (Kil89d) s -2 r (].) s cmbx10.432 @sf 224 648 p 57 c 69 r (External) s 23 r (Connections) s cmr10.329 @sf 224 769 p (It) s 16 r (will) s 15 r 98 c 1 r 101 c 17 r (imp) s 1 r (ortan) s -1 r 116 c 14 r (for) s 15 r (this) s 16 r (activit) s -1 r 121 c 14 r (to) s 16 r (main) s -1 r (ta) s -1 r (in) s 14 r (suitable) s 16 r (external) s 15 r (liaisons.) s 224 826 p (In) s 16 r (particular) s 14 r (to:) s cmbx10.329 @sf 224 952 p (Other) s 18 r (Directory) s 16 r (Services) s 16 r (and) s 18 r (Directory) s 16 r (Pilots) s cmr10.329 @sf 338 1027 p 84 c -3 r 111 c 11 r (ensure) s 12 r 97 c 12 r (service) s 12 r (whic) s 104 c 11 r (is) s 12 r (coheren) s 116 c 11 r (with) s 11 r (other) s 12 r (groups) s 12 r (building) s 12 r (X.500) s 338 1083 p (services.) s cmbx10.329 @sf 224 1177 p (Standards) s 18 r (Bo) s 1 r (dies) s cmr10.329 @sf 338 1252 p 84 c -3 r 111 c 19 r (feed) s 20 r (bac) s 107 c 20 r (exp) s 1 r (erience) s 21 r (gained) s 20 r (from) s 18 r (this) s 20 r (activit) s -1 r 121 c -3 r 44 c 19 r (so) s 20 r (that) s 19 r (the) s 20 r (next) s 338 1309 p (round) s 22 r (of) s 21 r (standards) s 21 r (meets) s 21 r (as) s 21 r (man) s 121 c 20 r (of) s 21 r (the) s 22 r (In) s (ternet) s 21 r (requiremen) s (t) s -1 r 115 c 20 r (as) s 338 1365 p 112 c 1 r (ossible.) s cmbx10.432 @sf 224 1528 p (References) s cmr10.329 @sf 224 1648 p ([BK91a]) s 54 r 80 c -3 r 46 c 23 r (Bark) s (er) s 23 r (and) s 25 r (S.E.) s 24 r (Kille.) s 47 r (The) s 25 r (COSINE) s 25 r (and) s 25 r (In) s (ternet) s 24 r (X.500) s 440 1704 p (sc) s (hema,) s 13 r (Marc) s 104 c 13 r (1991.) s 224 1798 p ([BK91b]) s 52 r 80 c -3 r 46 c 13 r (Bark) s (er) s 12 r (and) s 14 r (S.E.) s 13 r (Kille.) s 17 r (Handling) s 13 r (qos) s 14 r (\(qualit) s -1 r 121 c 12 r (of) s 13 r (service\)) s 14 r (in) s 13 r (the) s 440 1855 p (directory) s -3 r 44 c 15 r (Marc) s 104 c 16 r (1991.) s 23 r (In) s (ternet) s 16 r (Draft:) s 22 r (draft-ietf-osids-dirpilot) s -1 r (s-) s 440 1911 p (00.txt,.ps.) s 224 2005 p ([CCI88a]) s 39 r (The) s 26 r (Directory) s 25 r 124 c 27 r (authen) s (ticati) s -1 r (on) s 24 r (framew) s (o) s -1 r (rk,) s 26 r (Decem) s 98 c 1 r (er) s 25 r (1988.) s 440 2061 p (CCITT) s 15 r (Recommendation) s 13 r (X.509.) s 224 2155 p ([CCI88b]) s 37 r (The) s 15 r (Directory) s 13 r 124 c 15 r 111 c 118 c (ervi) s -1 r (ew) s 13 r (of) s 14 r (concepts,) s 15 r (mo) s 1 r (dels) s 13 r (and) s 15 r (services,) s 14 r (De-) s 440 2212 p (cem) s 98 c 1 r (er) s 14 r (1988.) s 18 r (CCITT) s 15 r (X.500) s 14 r (Series) s 16 r (Recommendatio) s -1 r (ns.) s 224 2305 p ([CCI90]) s 62 r (The) s 41 r (Directory) s 39 r 124 c 41 r (part) s 39 r 57 c 40 r 124 c 41 r (replication,) s 45 r (Octob) s 1 r (er) s 41 r (1990.) s 440 2362 p (ISO/IEC) s 16 r (CD) s 15 r (9594-9) s 14 r (Otto) s 119 c -1 r 97 c 12 r (ouput.) s 224 2456 p ([CFSD90]) s 21 r (J.D.) s 10 r (Case,) s 10 r (M.S.) s 10 r 70 c -3 r (edor,) s 10 r (M.L.) s 9 r (Sc) s (ho\013stall) s -1 r 44 c 9 r (and) s 11 r (J.R.) s 10 r (Da) s (vin.) s 10 r 65 c 11 r (Simple) s 440 2512 p (Net) s 119 c -1 r (ork) s 19 r (Managemen) s 116 c 19 r (Proto) s 1 r (col.) s 38 r (Request) s 22 r (for) s 21 r (Commen) s -1 r (t) s -1 r 115 c 20 r (1157,) s 440 2569 p (DDN) s 13 r (Net) s 119 c -1 r (or) s -1 r 107 c 11 r (Information) s 11 r (Cen) s (ter,) s 12 r (SRI) s 14 r (In) s (ternational,) s 11 r (Ma) s 121 c 11 r (1990.) s 224 2662 p ([F) s -3 r (or91]) s 76 r (The) s 18 r (North) s 17 r (American) s 17 r (Directory) s 17 r 70 c -3 r (orum) s -1 r 46 c 44 r 65 c 17 r (Naming) s 17 r (Sc) s (heme) s 16 r (for) s 440 2719 p (C=US.) s 19 r (Request) s 15 r (for) s 14 r (Comm) s -1 r (en) s -1 r (ts) s 12 r (1255,) s 13 r (DDN) s 14 r (Net) s 119 c (o) s -1 r (rk) s 13 r (Informatio) s -1 r 110 c 440 2775 p (Cen) s (ter,) s 14 r (SRI) s 16 r (In) s (ternational,) s 12 r (Septem) s 98 c 1 r (er) s 14 r (1991.) s 19 r (Also) s 14 r (NADF-175.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 874 r 80 c (age) s 16 r (11) s @eop 12 @bop0 /cmti10.329 @newfont cmti10.329 @sf [ 20 31 -3 0 18] 73 @dc [ 30 31 -3 0 30] 70 @dc [ 30 31 -3 0 31] 80 @dc [<0C000C0000000E000E0000000E000E0000000F000F0000000F800F0000000F800F8000000FC00F8000000FC00FC000000F60 0FC000000F600F6000000F300F6000000F300F3000000F180F3000000F180F1800000F0C1F1C00000F0C1E0C00000F061E0E 00000F061E0600000F031E0300000F031E0300000F019E0180000F019E0180000F00DE00C0000F00DE00C0001F007E006000 1F007E0060001E003E0030001E001E0038001F001F007C00FFF0FFE1FF80FFF0FFE1FF80> 41 31 -9 0 45] 87 @dc [<00FF040007FFCC000FC0FE001F003E003E001E003C001F007C001F0078000F0078000F00F8000F80F8000F80F800FFF0F800 FFF0FC0000007C0000007C0000007C0000007E0000003E0000003E0000601F0000601F0000600F80007007C0007007C00070 03F000F001F800F8007C01F8003F87B8000FFF180001FC0C> 30 31 -6 0 35] 71 @dc [<3F00007FC000F1E000E07800E07800E03C00E03E00E01E00E01E00F01E00F01F00F00F00F80F00F80F007C0E007E0E007BFE 007DFC003C20003C00001E00001E00000F03800783C00383C001E1C000F1C0007FC0001F80> 18 29 -6 0 23] 54 @dc [ 5 5 -5 0 14] 46 @dc [<3F80007FE000F1F000C07800C03C00E01E00F01F00F00F00600F00000F00000F800007800007801C07001E07000F0F000FFE 000CFC000E000006000006000006000007000003000003FC0003FF8003FFC001FFE00180E0> 19 29 -5 0 23] 53 @dc [<00FF000003FFC0000FC0F0001F0038003E001E003C000E007C0007007C00038078000180F8000180F80001C0F8000000F800 0000FC0000007C0000007C0000007C0000007E0000003E0000003E0000301F0000301F0000300F80003807C0003803E00038 03F0007800F8007C007E00FC003F83DC000FFF8C0001FE06> 31 31 -6 0 33] 67 @dc [<0FC0003FF8003C7C00781E00700F00F00780F00780F003C0F003C0F803E07803E07801E07801E03C01E03C01E01E01C00F03 C007C78003FF80007E00> 19 20 -4 0 23] 111 @dc [<1C01F03E03F81E079C1E078E1E07C61F03C60F03C70F03E00F01E00F81E00781F00780F00780F0E7C0F063C0F863E07873F0 7833F8F03F9FF01F0FC0> 24 20 -3 0 26] 110 @dc [ 12 4 -3 -8 16] 45 @dc [<7C00007F0000FF00007B800073C00003C00001C00001E00001E00001E00001E00000F00000F00000F00000F00000F8000078 00007800007800007800007800007C00003C00003C00003C00003C00003E0003FFF003FFF0001E00001E00001F00000F0000 0F00000F00000F000007BC0007BC0003BC0003FC0000F8> 22 41 2 9 14] 102 @dc [<0FE0001FFC003C3E00780700700300700000F00000F00000F00000F800007FF0007FFC00781F007C07003C03801E01800F03 8007C78003FF0000FE00> 17 20 -4 0 21] 101 @dc [<1C00003E00001E00001E00001E00001F00000F00000F00000F00000F8000078000078000078000E7C38063C3C063C3C073E3 C033F1C03FBF801F1F00> 18 20 -3 0 19] 114 @dc [<0FE0003FFC003C3E00780700700300F00000F00000F00000F00000F800007800007800007800003C02003C07801E07800F07 8007C38003FF00007E00> 17 20 -4 0 21] 99 @dc [ 42 31 -3 0 41] 77 @dc [<1FC07FF0F078F03CF01CF01C701E003E03FE07FE0FFC1FF81FF01F000E0F0E0F0F0F078703FE00FC> 16 20 -3 0 19] 115 @dc [<1F0F803FDFC079FCC0707CE0F03C60F03C60F03E70F01E00F01E00F81E00781F00780F00780F003C0F003C0F801E07800F0F 80079FC003FFC000FB80> 20 20 -4 0 23] 97 @dc [<3FC000FFF000F8F800787C00703E00001E00001F00001F00000F0007EF000FFF801E3F801C1F803C0F803C07C03C07C03C03 C03C03C03E03E03E03E01E01E01E01E00F01F00F01F00781F003C1F001E3F800FFF8003E70> 21 29 -2 9 21] 103 @dc [ 35 31 -3 0 34] 72 @dc [<1F0F803FDFC079FCC0707CE0F03C60F03E60F03E70F01E00F01E00F81F00781F00780F00780F003C0F803C0F801E07800F0F 80079FC003FFC000FBC00003C00003E00003E00001E00001E00001F00001F00000F00000F00007F80007F80000F8> 21 32 -4 0 23] 100 @dc [<3E007F00F300F380F180F980F9C0780078007C007C003C003C003E003E001E001E001F001F000F000F000F800F8007800780 07C007C003C003C01FE01FE003E0> 11 32 -3 0 12] 108 @dc [<1F003F803DC03CE03C603E601E701E001F000F000F000F800780E78067C063C073C03BC01FC00F8000000000000000000000 0000000000E000F000F000F0> 12 31 -3 0 14] 105 @dc [ 26 31 -3 0 26] 83 @dc [<1F80007FE00071F000787800783C00783E00101E00001F00000F0003FF0007FF000F1F800F0F800F07800F07800F07C00F03 C00F03C00F83C00783E00781E007C1E0E3C1E063C1F063E0F071E0F039E0F81FC0F80F8070> 21 29 -3 9 22] 121 @dc [<1F003F8079C078E078607C607C703C003C003E003E001E001E001F001F000F000F000F80FFF0FFF0078007C007C003C003C0 03E003E001C0> 12 28 -4 0 15] 116 @dc [<1C03803E003E07C07F001E07C0F3801E03C0F1C01E03C0F8C01F03E078C00F03E078E00F01E07C000F01E03C000F81F03C00 0781F03E000780F01E000780F01E00E7C0F81E0063C0F81F0063E07C0F0073F07E0F0033F8F71E003F9FF3FE001F0FC1F800> 35 20 -3 0 37] 109 @dc [ 31 31 -3 0 34] 68 @dc [<1F80003FE00078F000707800F03C00F01E00F01E00F00F00F00F00F80F80780F807807807807807C07807C07803E07803F07 003F8F003FFE001EFC001E00001F00001F00000F00000F00000F80000F80000780000780003FC0003FC00007C000> 17 32 -4 0 21] 98 @dc [<03E3E007FFF00F3F300F0F380F0F180F0F180F0F9C0F07800F07800F87800787C00783C007C3C0E3C3C063C3E063E1E071E1 E039E1F01FC1F00F80E0> 22 20 -3 0 24] 117 @dc [ 29 31 -2 0 34] 65 @dc [ 23 29 0 9 23] 112 @dc cmr10.329 @sf [ 22 2 0 -11 23] 123 @dc 12 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 224 195 p ([HSB91]) s 53 r (T.) s 16 r (Ho) s 119 c -1 r (es,) s 15 r (M.) s 17 r (Smith,) s 15 r (and) s 17 r (B.) s 17 r (Beec) s (her.) s 41 r (DIXIE) s 18 r (Proto) s 1 r (col) s 15 r (Sp) s 1 r (eci\014-) s 440 252 p (cation) s 13 r 46 c 17 r (Request) s 14 r (for) s 13 r (Comm) s -1 r (en) s -1 r (ts) s 11 r (1249,) s 12 r (DDN) s 13 r (Net) s 119 c (o) s -1 r (rk) s 12 r (Informatio) s -1 r 110 c 440 308 p (Cen) s (ter,) s 14 r (SRI) s 16 r (In) s (ternational,) s 12 r (July) s 16 r (1991.) s 224 402 p ([ISO]) s 114 r (Pro) s 1 r (cedures) s 20 r (for) s 18 r (the) s 20 r (op) s 1 r (eration) s 18 r (of) s 19 r (OSI) s 20 r (registration) s 17 r (authorities) s 18 r 124 c 440 458 p (part) s 15 r (1:) s 19 r (general) s 15 r (pro) s 1 r (cedures.) s 21 r (ISO/IEC) s 16 r (9834-1.) s 224 552 p ([Kil88]) s 83 r (S.E.) s 14 r (Kille.) s 19 r (The) s 15 r (QUIPU) s 16 r (directory) s 14 r (service.) s 20 r (In) s cmti10.329 @sf 15 r (IFIP) s 15 r (WG) s 16 r (6.5) s 17 r (Con-) s 440 609 p (fer) s -1 r (enc) s -2 r 101 c 17 r (on) s 20 r (Message) s 18 r (Hand) s 2 r (ling) s 19 r (Systems) s 18 r (and) s 20 r (Distribute) s -1 r 100 c 19 r (Applic) s -1 r (a-) s 440 665 p (tions) s cmr10.329 @sf 44 c 14 r (pages) s 15 r (173{186.) s 13 r (North) s 15 r (Holland) s 14 r (Publishing,) s 14 r (Octob) s 1 r (er) s 16 r (1988.) s 224 759 p ([Kil89a]) s 60 r (S.E.) s 13 r (Kille.) s 17 r (An) s 13 r (in) s (terim) s 11 r (approac) s 104 c 12 r (to) s 13 r (use) s 14 r (of) s 13 r (net) s 119 c -1 r (ork) s 11 r (addresses.) s 18 r (Re-) s 440 815 p (searc) s 104 c 17 r (Note) s 17 r (RN/89/13,) s 17 r (Departmen) s 116 c 15 r (of) s 18 r (Computer) s 16 r (Science,) s 19 r (Uni-) s 440 872 p 118 c (ersit) s -1 r 121 c 10 r (College) s 11 r (London,) s 12 r 70 c -3 r (ebruary) s 11 r (1989.) s 14 r (In) s (ternet) s 11 r (Draft:) s 17 r (draft-ucl-) s 440 928 p (kille-net) s 119 c -1 r (o) s -1 r (rk) s -2 r (a) s -1 r (ddresses-02.txt) s -1 r 44 c 13 r (ps.) s 224 1022 p ([Kil89b]) s 58 r (S.E.) s 16 r (Kille.) s 24 r 65 c 17 r (string) s 16 r (enco) s 1 r (ding) s 17 r (of) s 17 r (presen) s (tatio) s -1 r 110 c 15 r (address.) s 25 r (Researc) s 104 c 440 1078 p (Note) s 21 r (RN/89/14,) s 22 r (Departmen) s -1 r 116 c 20 r (of) s 21 r (Computer) s 20 r (Science,) s 24 r (Univ) s (ersit) s -1 r 121 c 440 1135 p (College) s 17 r (London,) s 19 r 70 c -3 r (ebruary) s 17 r (1989.) s 28 r (In) s (ternet) s 17 r (Draft:) s 25 r (draft-ucl-kille-) s 440 1191 p (presen) s (tationaddress-01.) s -1 r (txt,) s 13 r (ps.) s 224 1285 p ([Kil89c]) s 63 r (S.E.) s 11 r (Kille.) s 13 r (The) s 11 r (THORN) s 13 r (and) s 11 r (RARE) s 12 r (naming) s 10 r (arc) s (hitecture.) s 12 r 84 c -3 r (ec) s (hni-) s 440 1342 p (cal) s 15 r (rep) s 1 r (ort,) s 15 r (Departmen) s 116 c 13 r (of) s 15 r (Computer) s 14 r (Science,) s 16 r (Univ) s (ersit) s -1 r 121 c 14 r (College) s 440 1398 p (London,) s 15 r (June) s 17 r (1989.) s 18 r (THORN) s 16 r (Rep) s 1 r (ort) s 16 r (UCL-64) s 15 r (\(v) s (ersion) s 13 r (2\).) s 224 1492 p ([Kil89d]) s 58 r (S.E.) s 18 r (Kille.) s 28 r (X.500) s 17 r (and) s 18 r (domains.) s 27 r (Researc) s 104 c 18 r (Note) s 18 r (RN/89/47,) s 17 r (De-) s 440 1548 p (partmen) s 116 c 12 r (of) s 15 r (Computer) s 14 r (Science,) s 15 r (Univ) s (ersit) s -1 r 121 c 13 r (College) s 14 r (London,) s 15 r (Ma) s 121 c 440 1605 p (1989.) s 19 r (Also) s 14 r (In) s (ternet) s 15 r (Draft:) s 18 r (draft-ucl-kille-x500dom) s -1 r (ains-03) s -1 r (.ps.) s 224 1699 p ([Kil90]) s 83 r (S.E.) s 13 r (Kille.) s 18 r (Using) s 13 r (the) s 14 r (OSI) s 15 r (directory) s 13 r (to) s 13 r (ac) s (hiev) s 101 c 12 r (user) s 14 r (friendly) s 14 r (nam-) s 440 1755 p (ing.) s 14 r (Researc) s 104 c 11 r (Note) s 12 r (RN/90/29,) s 11 r (Departmen) s -1 r 116 c 10 r (of) s 11 r (Computer) s 11 r (Science,) s 440 1811 p (Univ) s (ersit) s -1 r 121 c 13 r (College) s 14 r (London,) s 15 r 70 c -3 r (ebruary) s 14 r (1990.) s 224 1905 p ([Kil91a]) s 60 r (S.E.) s 16 r (Kille.) s 24 r (Dsa) s 16 r (naming,) s 15 r (Marc) s 104 c 15 r (1991.) s 23 r (In) s (ternet) s 16 r (Draft:) s 21 r (draft-ietf-) s 440 1962 p (osids-dsanaming-00.) s -1 r (txt,) s -1 r (.ps.) s 224 2056 p ([Kil91b]) s 58 r (S.E.) s 16 r (Kille.) s 24 r (Replication) s 16 r (and) s 17 r (distributed) s 16 r (op) s 1 r (erations) s 16 r (extensions) s 16 r (to) s 440 2112 p (pro) s (vide) s 10 r (an) s 12 r (in) s (ternet) s 10 r (directory) s 11 r (using) s 11 r (X.500,) s 11 r (Jan) s (uary) s 10 r (1991.) s 13 r (In) s (ternet) s 440 2168 p (Draft:) s 19 r (draft-ietf-osids-replsoln-02) s -1 r (.txt) s -1 r 44 c 13 r (ps.) s 224 2262 p ([Kil91c]) s 63 r (S.E.) s 15 r (Kille.) s 19 r (Replication) s 14 r (requiremen) s 116 c 13 r (to) s 15 r (pro) s (vide) s 14 r (an) s 15 r (in) s (ternet) s 13 r (direc-) s 440 2319 p (tory) s 15 r (using) s 15 r (X.500,) s 14 r (Jan) s (uary) s 14 r (1991.) s 20 r (In) s (ternet) s 15 r (Draft:) s 19 r (draft-ietf-osids-) s 440 2375 p (replication-02.txt) s -1 r 46 c 224 2469 p ([Lin89]) s 78 r (J.) s 13 r (Linn.) s 17 r (Priv) s -2 r (acy) s 12 r (Enhancemen) s 116 c 12 r (for) s 12 r (In) s (ternet) s 13 r (Electronic) s 12 r (Mail:) s 18 r 80 c (art) s 440 2525 p 49 c 13 r 124 c 14 r (Message) s 13 r (Enciphermen) s 116 c 11 r (and) s 14 r (Authen) s (tication) s 11 r (Pro) s 1 r (cedures.) s 18 r (Re-) s 440 2582 p (quest) s 22 r (for) s 21 r (Comm) s -1 r (en) s -1 r (ts) s 20 r (1113,) s 22 r (DDN) s 21 r (Net) s 119 c -1 r (ork) s 19 r (Information) s 20 r (Cen) s (ter,) s 440 2638 p (SRI) s 16 r (In) s (ternational,) s 13 r (August) s 15 r (1989.) s 224 2732 p ([L) s -4 r (W91]) s 73 r (R.) s 16 r (Lang) s 16 r (and) s 17 r (R.) s 16 r 87 c -3 r (righ) s -1 r (t.) s 20 r 65 c 17 r (catalog) s 14 r (of) s 16 r 97 c 118 c -2 r (a) s -1 r (ila) s -1 r (ble) s 15 r (x.500) s 14 r (implemen-) s 440 2789 p (tations,) s 13 r (July) s 16 r (1991.) s 19 r (In) s (ternet) s 14 r (Draft.) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 874 r 80 c (age) s 16 r (12) s @eop 13 @bop0 cmti10.329 @sf [ 29 31 -3 0 33] 82 @dc [<03F00007F8000F9C000F0E000F07000F03000F03000F01800F01800F81800781C00780C007C0C0E3C0C063C0E063E1E071E3 E039E3E01FC3E00F81C0> 19 20 -3 0 21] 118 @dc [<03F1F80007FBFE000F9FCF000F0F83000F0F83800F0781800F0781C00F0780C00F0780C00F87C0C00787C0E00783C06007C3 C060E3C3E06063C3E07063E1E0F071E1E1F039E1F1F01FC1F1F00F80E0E0> 28 20 -3 0 30] 119 @dc cmbx10.432 @sf [<007FC3FF8001FFF3FF8007FFFBFF800FF07FF8001FC01FF8003FC00FF8003F8007F8007F8003F8007F0003F800FF0003F800 FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F8007F0003F8007F8003F800 3F8003F8003FC007F8001FE00FF8000FF83FF80007FFFFF80001FFFBF800003FC3F800000003F800000003F800000003F800 000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F80000003FF800 00003FF80000003FF800> 33 42 -2 0 38] 100 @dc [<38003C003E001F000F000780038003C001C001C001E000E03FE07FE0FFE0FFE0FFE0FFE0FFC0FFC07F803E00> 11 22 -4 -20 19] 39 @dc cmr10.329 @sf [<0006000000060000000600000006000000060000000600000006000000060000000600000006000000060000000600000006 00000006000000060000FFFFFFF0FFFFFFF00006000000060000000600000006000000060000000600000006000000060000 00060000000600000006000000060000000600000006000000060000> 28 32 -3 5 35] 43 @dc [<003FF00000FFFF0003E01FE0078001F00E0000001C000000181F8F80387FDFC070F9FEE070F07C6061E07C30E1E03C30C3E0 3C30C3C03C30C3C03C30C3C03C30C3C03C30C3C03C30C3C03C30C3E03C30E1E03C7061E07C6070F070E070F9E0E0387FC1C0 181F81801C0003800E00070007801E0003E07C0000FFF000003FC000> 28 32 -3 0 35] 64 @dc 13 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 224 195 p ([Lyn91]) s 67 r (C.A.) s 24 r (Lync) s (h.) s 49 r (The) s 25 r (Z39.50) s 23 r (informat) s -1 r (ion) s 23 r (retriev) s -2 r (al) s 23 r (proto) s 1 r (col:) s 38 r (An) s 440 252 p 111 c 118 c -1 r (erview) s 16 r (and) s 18 r (status) s 17 r (rep) s 1 r (ort.) s cmti10.329 @sf 27 r (Computer) s 20 r (Communic) s -1 r (ation) s 17 r 82 c -1 r (eview) s cmr10.329 @sf 44 c 440 308 p (21\(1\):58{) s -1 r (70,) s 13 r (Jan) s (uary) s 14 r (1991.) s 224 402 p ([R) s (C87]) s 78 r (Marshall) s 16 r (T.) s 17 r (Rose) s 18 r (and) s 17 r (Dwigh) s 116 c 16 r (E.) s 17 r (Cass.) s 26 r (ISO) s 18 r 84 c -3 r (ransp) s 1 r (ort) s 16 r (Services) s 440 458 p (on) s 15 r (top) s 15 r (of) s 15 r (the) s 15 r (TCP.) s 20 r (Request) s 16 r (for) s 15 r (Comm) s -1 r (en) s -1 r (ts) s 13 r (1006,) s 14 r (DDN) s 15 r (Net) s 119 c -1 r (ork) s 440 515 p (Information) s 13 r (Cen) s (ter,) s 14 r (SRI) s 16 r (In) s (ternational,) s 12 r (Ma) s 121 c 14 r (1987.) s 224 609 p ([Ros91]) s 70 r (M.T.) s 18 r (Rose.) s 53 r (Directory) s 18 r (Assistance) s 19 r (Service) s 20 r 46 c 33 r (Request) s 20 r (for) s 19 r (Com-) s 440 665 p (men) s (ts) s 22 r (1202,) s 24 r (DDN) s 24 r (Net) s 119 c -1 r (ork) s 22 r (Informatio) s -1 r 110 c 23 r (Cen) s (ter,) s 24 r (SRI) s 25 r (In) s (terna-) s 440 721 p (tional,) s 13 r 70 c -3 r (ebruary) s 15 r (1991.) s cmbx10.432 @sf 224 884 p (10) s 70 r (Securit) s -2 r 121 c 21 r (Considerations) s cmr10.329 @sf 224 1005 p (This) s 15 r (INTERNET{DRAFT) s 16 r (considers) s 15 r (the) s 16 r (general) s 15 r (relationship) s 14 r (of) s 15 r (securit) s 121 c 14 r (to) s 224 1062 p (the) s 15 r (directory) s -3 r 46 c cmbx10.432 @sf 224 1225 p (11) s 70 r (Authors') s 24 r (Addresses) s cmr10.329 @sf 338 1345 p (Stev) s 101 c 14 r (Hardcastle-Kille) s 338 1401 p (Departmen) s -1 r 116 c 13 r (of) s 15 r (Computer) s 14 r (Science) s 338 1458 p (Univ) s (ersit) s -2 r 121 c 14 r (College) s 14 r (London) s 338 1514 p (Go) s 119 c -2 r (er) s 14 r (Street) s 338 1570 p 87 c (C1E) s 13 r (6BT) s 338 1627 p (England) s 338 1753 p (Phone:) s 20 r (+44-71-380-7294) s 338 1879 p (EMail:) s 18 r (S.Kille@CS.UCL.A) s (C.UK) s 338 2004 p (Vin) s (ton) s 13 r (Cerf) s 338 2061 p (Corp) s 1 r (oration) s 13 r (for) s 15 r (National) s 14 r (Researc) s 104 c 14 r (Initiativ) s (es) s 338 2117 p (1895) s 14 r (Preston) s 15 r (White) s 14 r (Driv) s (e,) s 13 r (Suite) s 15 r (100) s 338 2174 p (Reston,) s 15 r 86 c -4 r 65 c 14 r (22091) s 338 2300 p (Phone:) s 20 r (\(703\)) s 14 r (620-8990) s 338 2425 p (EMail:) s 18 r 118 c (cerf@nri.reston.v) s -3 r (a.us) s 338 2551 p (Russ) s 16 r (Hobb) s 121 c 338 2608 p (Univ) s (ersit) s -2 r 121 c 14 r (of) s 14 r (California,) s 13 r (Da) s (vis) s 338 2664 p (Computing) s 13 r (Services) s 338 2721 p (Surge) s 15 r 73 c 1 r 73 c 16 r (Ro) s 1 r (om) s 15 r (1400) s 338 2777 p (Da) s (vis,) s 12 r (CA) s 15 r (95616) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 874 r 80 c (age) s 16 r (13) s @eop 14 @bop0 14 @bop1 cmr12.300 @sf 224 50 p (INTERNET{DRAFT) s 66 r (In) s (ternet) s 14 r (Directory) s 17 r (Services) s 50 r (Septem) s 98 c 1 r (er) s 14 r (1991) s cmr10.329 @sf 338 195 p (Phone:) s 20 r (\(916\)) s 14 r (752-0236) s 338 321 p (EMail:) s 18 r (rdhobb) s (y@ucda) s (vis.edu) s 338 447 p (Stev) s 101 c 14 r (Ken) s 116 c 338 503 p (Bolt,) s 14 r (Beranek,) s 15 r (and) s 15 r (Newman) s 338 629 p (Phone:) s 20 r (\(617\)) s 14 r (873-3988) s 338 755 p (EMail:) s 18 r (sk) s (en) s (t@bbn.com) s 338 881 p (Jon) s 15 r 80 c (ostel) s 338 937 p (Information) s 13 r (Sciences) s 16 r (Institute) s 338 994 p (4676) s 14 r (Admiralt) s -2 r 121 c 13 r 87 c -3 r 97 c 121 c -4 r 44 c 13 r (Suite) s 15 r (10001) s 338 1050 p (Marina) s 14 r (del) s 15 r (Rey) s -3 r 44 c 15 r (CA) s 15 r (90292-6695) s 338 1176 p (Phone:) s 20 r (\(213\)-822-15) s -1 r (11) s 338 1302 p (EMail:) s 18 r 112 c 1 r (ostel@v) s (enera.isi.edu) s cmr12.300 @sf 224 2916 p (Hardcastle-Kille) s 18 r (et) s 16 r (al) s 874 r 80 c (age) s 16 r (14) s @eop @end   Return-Path: Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <25955-0@bells.cs.ucl.ac.uk>; Fri, 4 Oct 1991 12:55:32 +0100 To: osi-ds@uk.ac.ucl.cs Subject: Delta for OSI-DS 12 Phone: +44-71-380-7294 Date: Fri, 04 Oct 91 12:55:30 +0100 Message-ID: <1143.686577330@UK.AC.UCL.CS> From: Steve Hardcastle-Kille Both authors agree on this text. The document is not being rereleased now, to avoid confusion. Steve ------- Forwarded Message From: Paul Barker To: S.Kille@uk.ac.ucl.cs Subject: New text Date: Fri, 04 Oct 91 12:51:36 +0100 An additional section on the use of access control is proposed for the document "Naming Guidelines for Directory Pilots" (OSI-DS 12). The following text should be considered as a third sub-section to section 2, "DIT structure". Access control An entry's object class attribute, and any attribute(s) used for naming an entry are of special significance and may be considered to be ``structural''. Any inability to access these attributes will often militate against successsful querying of the Directory. For example, user interfaces typically limit the scope of their searches by searching for entries of a particular type, where the type of entry is indicated by its object class. Thus, unless the intention is to bar public access to an entry or set of entries, the object class and naming attributes should be publicly readable. ... and a typo needs fixing. In section 4.4, in the paragraph on "Impact on naming", about 4 lins into the paragraph, it should read: ... DNs are more natural, although the need to disambiguate ... ^^^^^^^^ ------- End of Forwarded Message   Return-Path: Received: from uknet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <541-0@bells.cs.ucl.ac.uk>; Fri, 4 Oct 1991 17:56:16 +0100 Received: from concurrent.co.uk by eros.uknet.ac.uk via PSS with NIFTP (PP) id <19066-1@eros.uknet.ac.uk>; Fri, 4 Oct 1991 17:54:41 +0100 To: s.kille@uk.ac.ucl.cs cc: osi-ds@uk.ac.ucl.cs Subject: Strategic Plan/UFN -- representation of DNs Date: Fri, 04 Oct 91 17:32:11 +0100 Message-ID: <8614.686593931@concurrent.co.uk> From: Alan Young Reading "A Strategic Plan for deploying an Internet Directory Service" reminded me of a problem that had struck me before and which I beleive I may have seen some reference to on this list, but no resolution. You say "in section 6.1.4" that the UFN syntax is chosen for the representation to users of DNs. The problem arises with the distinction between a DN and a Purported Name. UFNs are fine for the latter but, because the syntax is the same, their use as the former is problematic. In short is is necessary to be able to specify to a DUA a DN, and not have it interpreted as a Purported Name. It is highly desirable that many DUAs will also be able to accept Purported Names. If the syntax chosen to represent DNs to the user is also the one used to specify Purported Names to the DUA then there is scope for significant confusion. Perhaps a simple marker could be added (at the front) of the UFN syntax to distinguish between DNs and Purported Names? Alan.   Return-Path: Received: from mitsou.inria.fr by bells.cs.ucl.ac.uk with SMTP inbound id <6587-0@bells.cs.ucl.ac.uk>; Fri, 4 Oct 1991 18:38:47 +0100 Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA08859; Fri, 4 Oct 91 18:39:50 +0100 Message-Id: <9110041739.AA08859@mitsou.inria.fr> To: Alan Young Cc: s.kille@uk.ac.ucl.cs, osi-ds@uk.ac.ucl.cs Subject: Re: Strategic Plan/UFN -- representation of DNs In-Reply-To: Your message of "04 Oct 91 17:32:11 +0100." <8614.686593931@concurrent.co.uk> Date: Fri, 04 Oct 91 18:39:49 +0000 From: Christian Huitema X-Mts: smtp I concur. The notation of DNs should be such that one could completely build them without any knowledge of the directory, i.e. without doing any search. I understand the rationale for removing the "protocol" information in the UFNs. This is certainly one way towards user-friendliness. But these info should be left in somehow if we use the format to pass DNs. This can be done either "explicitely", which may well lead to "UDNs", i.e. ugly D Names, or implicitely, by assuming a "most used" schema. For example: Standard Schema: Peter Kirstein, CS, UCL, UK Locality in lieu of OU: Christian Huitema, Locality=Sophia-Antipolis, INRIA, FR Locality under C: John Smith, O=Smith and Co LTD, Locality=London, GB International Org: Tony Rudkowsky, ORG=CCITT, ORG=ITU Basically, one would have to note explicitely all exceptions in order to qualify as a "distinguished name". This may well go down to listing the syntax in case of choices between numeric/printable/T61, when the default (e.g. Printable) is not used. This imply that the "default schema" used for the "assumptions" be listed in the document. Christian Huitema   Return-Path: Received: from CHIRALITY.RSA.com by bells.cs.ucl.ac.uk with SMTP inbound id <1169-0@bells.cs.ucl.ac.uk>; Fri, 4 Oct 1991 23:08:21 +0100 Received: by RSA.COM id AA03239; Fri, 4 Oct 91 15:09:54 PDT Date: Fri, 4 Oct 91 15:09:54 PDT From: jefft@com.RSA (Jeff Thompson) Message-Id: <9110042209.AA03239@RSA.COM> To: osi-ds@uk.ac.ucl.cs Subject: PRINTABLE vs. T.61 STRING values in UFN Christian Huitema writes: > Basically, one would have to note explicitely all exceptions in order to > qualify as a "distinguished name". This may well go down to listing the > syntax in case of choices between numeric/printable/T61, when the default > (e.g. Printable) is not used. This imply that the "default schema" used for > the "assumptions" be listed in the document. Here is what we invented to extended UFN to deal with T.61 values in distingushed names in our implementation. When converting from UFN to a distinguished name, we scan each value (such as a common name or organization name). If all of the characters are in the PRINTABLE STRING set, we encode the value as a PRINTABLE STRING, otherwise we encode it as T.61. Therefore the PRINTABLE STRING vs. T.61 STRING default is determined by the characters in the value itself. In the following name, the common name is encoded as PRINTABLE STRING but the organization names is encoded as T.61 because '&' is not in the PRINTABLE STRING character set. John Smith, Fun & Games Corporation, US Likewise, when converting from a distingiuished name to UFN, a PRINTABLE STRING value is always presented in UFN as it is in the distinguished name, and a T.61 STRING values is presented as it is in the distinguished name if it indeed contains charaters that are not in the PRINTABLE STRING character set. The only diffuculty is for a T.61 STRING value that contain all characters from the PRINTABLE STRING character set. If there is an agreement that a distinguished name should only have a T.61 STRING value if it has non-PRINTABLE STRING characters, then there is no problem converting between UFN and distinguished names in a deterministic manner. - Jeff   Return-Path: Received: from ics.uci.edu by bells.cs.ucl.ac.uk with SMTP inbound id <20439-0@bells.cs.ucl.ac.uk>; Sat, 5 Oct 1991 21:33:32 +0100 Received: from nma.com by ics.uci.edu id ae08530; 5 Oct 91 11:57 PDT Received: from odin.nma.com by nma.com id aa17779; 5 Oct 91 11:03 PDT To: osi-ds@uk.ac.ucl.cs Subject: Re: Agenda for the Atlanta meeting In-reply-to: Your message of Thu, 03 Oct 91 14:07:24 +0000. <1599.686495244@UK.AC.UCL.CS> Reply-to: Stef@com.nma From: Einar Stefferud Date: Sat, 05 Oct 91 11:01:02 MDT Message-ID: <2524.686685662@nma.com> Sender: stef@com.nma I note that I am on the agenda, so I must warn that I have another early (very early) video conference to attend, adn will then come directly to the OSI-DS meeting. I will be there well be for noon. See you all there...\Stef   Return-Path: Received: from nsfnet-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP id <7723-0@bells.cs.ucl.ac.uk>; Tue, 8 Oct 1991 11:04:28 +0100 Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <6373-3@sun2.nsfnet-relay.ac.uk>; Tue, 8 Oct 1991 10:34:18 +0100 Received: from [138.96.8.118] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa05426; 8 Oct 91 10:28 BST Received: from localhost by mitsou.inria.fr with SMTP (5.65b/IDA-1.2.8) id AA12556; Tue, 8 Oct 91 10:28:12 +0100 Message-Id: <9110080928.AA12556@mitsou.inria.fr> To: Steve Hardcastle-Kille Cc: osi-ds@uk.ac.ucl.cs Subject: Re: DSA naming In-Reply-To: Your message of "04 Oct 91 12:52:21 +0100." <1127.686577141@UK.AC.UCL.CS> Date: Tue, 08 Oct 91 10:28:09 +0000 From: Christian Huitema X-Mts: smtp Sender: huitema@fr.inria.mitsou Steve, I have some problems understanding your "DSA Naming" draft. You raise in this document a number of points, e.g. that the current QUIPU practice of DSA naming is dubious -- no doubt for that -- and that one should organize the distribution of knowledge -- which is also a reasonable concern. Then you introduce the concept of "DMD", mixing it with the notion of Organisation and special naming rules. I think that this choice of words is misleading -- naming domain do not necessarily match organization boundaries. If I understand correctly, the idea is to use DMD as an intermediate concept for expressing knowledge and references, i.e: Knowledge: entry X belongs to DMD Y, Reference: info on DMD Y is found in DSA Z1 (primary), Z2(copy). Address: PSAP of DSA Z1 is obtained by reading the entry Z1 in DIT. If that is really what you have in mind, then it should be expressed clearly in an "architecture" document describing the "operation of the Internet Name service" -- which seems to me drifting apart from the original X.500 spec. Such a concept should not be buried under the title of "DSA naming", as it is the basis for the management of navigation and replication. Moreover, it should be widely discussed. If we were to introduce the DMD concept, the format for "Continuation references" and "searches" should be changed. Currently, these references are composed of a single DSA name and the associated PSAP. This is simple, and as one big advantage of being deadlock free. If we were to follow the proposed DMD concept, then the reference should be composed of a single DMD name, and the directory should be used to get the names and addresses of the DSAs serving the domain. This gives a degree of freedom -- one can choose the "nearest DSA" -- but introduces a possibility of deadlock: one needs the address of the DSA to access its address. In order to solve this deadlock possibility, you engage in a grand scale DSA naming exercise, with the introduction of a hierarchy of DSAs that would parallel the naming hierarchy, probably in order to ease the replication of information. I think that simpler solutions can be found: 1) We should keep the existing referral mechanism, 2) DSAs can be named anywhere in the DIT, 3) Storing more information in the DIT entries allows a more intelligent behaviour. The reasons for keeping the existing reference mechanism, as defined in the standard, are obvious: it work, it is deadlock free, and all implementations of X.500 support it. The standard does not place any constraint on the naming of DSAs. In fact, such a constraint is unrealistic as a given piece of software does not necessarily implement only one "ASE". It would be perfectly reasonable to come out with a combined CMIP-X500 or X400-X500 implementation. The "signature" that proves that a given entry represent a DSA is the presence of the "DAP" and "DSP" value in the "SupportedApplicationContext" attribute; the fact that the Common Name contains the identification of an environmentally challenged animal or of a Spanish conquistador is just folklore. The real use of the DMD concept is to allow the description in one reference of the fact that the entry may be retrieved from several DSAs. This can be achieved by merging the concepts of "DMD" and "main DSA". When a DSA returns a reference (Continuation reference, Referal), that reference should contain the name and PSAP of the "main DSA" for the "DMD". An attribute of this main DSA could be a list of "equivalent DSAs", that hold a copy of the information. In fact, we have adopted from the start in the "PIZARRO" implementation a very simple structure that does not contrain DSA naming. A PIZARRO DSA is named anywhere in the DIT -- preferably within the DMD that it manages. The DSA entry, in complement to the PSAP, contain information on the "mastered domains" and "copied domains". The administration of the network maintains a file of these DSAs that is regularly propagated to all members of the "OPAX" network: by simply replicating (caching?) the DSA entries, one get all the navigation information that is needed -- without having to replicate the entries themselves. I am aware that such a simple solution will be found inappropriate for QUIPU, and not invented here; it could however still be discussed. Christian Huitema   Return-Path: Received: from laphroaig.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <24492-0@bells.cs.ucl.ac.uk>; Fri, 11 Oct 1991 09:45:09 +0100 To: osi-ds@uk.ac.ucl.cs cc: Steve Titcombe Subject: DSA Probe Statistics For Root DSAs. Date: Fri, 11 Oct 91 09:45:08 +0100 From: Steve Titcombe DSA Probe Statistics For Root DSAs, for the period Friday 27th September - Friday October 11th. Probes from UCL, ULCC, STC, Adelaide, and GMD in Berlin. Bind Fail %age Best Worst Ave Address FR: FR,emse,opaxdsa (French Master) 60 0 100.00 0.1 0.1 0.10 dsa_available 60 0 100.00 5.3 7.0 5.84 \"mars ES: Cayman (Madrid Uni.) 63 1 98.41 0.1 0.1 0.10 dsa_available 63 2 96.83 6.2 167.7 17.63 Int-X.25 45 3 93.33 4.6 93.9 27.15 Internet 63 31 50.79 4.8 15.0 7.90 IXI 18 18 0.00 - - - Internet Iguana (ES Master. Programa IRIS) 259 85 67.18 0.1 1.0 0.31 dsa_available 156 51 67.31 3.4 14.5 6.76 Int-X.25 180 65 63.89 1.6 5.2 8.34 IXI 196 71 63.78 1.6 8.8 13.77 Internet AU: Anaconda (AU Master) 208 5 97.60 0.1 0.1 0.10 dsa_available 204 6 97.06 1.5 25.9 13.96 Internet 157 35 77.71 0.0 9.2 10.88 Int-X.25 Bush Dog (master for AU (phony)) 205 121 40.98 0.1 0.1 0.10 dsa_available 205 121 40.98 1.5 23.3 20.26 Internet NO: Boa Constrictor (Norway Backup) 266 9 96.62 0.1 1.0 0.30 dsa_available 203 12 94.09 2.3 14.0 16.70 Internet 181 35 80.66 1.7 8.6 16.28 IXI 157 33 78.98 0.0 5.1 5.35 Int-X.25 Electric Eel (Norway Master) 263 9 96.58 0.1 1.0 0.30 dsa_available 200 12 94.00 2.0 8.2 9.38 Internet 181 34 81.22 1.5 4.5 8.05 IXI 156 33 78.85 0.0 5.4 6.81 Int-X.25 DE: Puma (GMD/FOKUS) 243 11 95.47 0.1 1.0 0.30 dsa_available 155 5 96.77 1.1 6.2 9.10 Int-X.25 57 3 94.74 4.6 119.5 23.82 Internet 127 13 89.76 0.5 5.1 7.54 Internet 176 41 76.70 1.8 5.4 10.62 IXI Margay (GMD/F3, DE backup) 253 32 87.35 0.1 1.0 0.31 dsa_available 190 13 93.16 1.2 15.0 9.71 Internet 155 11 92.90 1.6 7.9 16.74 Int-X.25 180 54 70.00 1.8 5.8 10.31 IXI CA: Beluga Whale (Canada Master) 112 7 93.75 0.1 0.1 0.10 dsa_available 112 7 93.75 3.0 65.7 24.18 Internet Pangolin (Northern Telecom Master) 191 86 54.97 0.1 0.1 0.10 dsa_available 30 5 83.33 2.1 81.3 17.59 Private TCP 187 87 53.48 3.2 16.0 17.43 Internet Wayne Gretzky (Old Canada Master) 181 181 0.00 - - - dsa_available 181 181 0.00 - - - Internet SE: Hummingbird (SE Master) 188 12 93.62 0.1 0.1 0.10 dsa_available 184 11 94.02 2.1 30.6 16.43 Internet 141 78 44.68 0.0 22.1 9.28 '0101'H/X121 IS: Elephant Seal (Iceland Master) 203 15 92.61 0.1 0.1 0.10 dsa_available 203 15 92.61 6.3 17.4 34.81 Internet DK: Axolotl (DK Master) 205 20 90.24 0.1 0.1 0.10 dsa_available 205 20 90.24 2.2 11.5 16.67 Internet FI: Jaguar (Finland Master) 192 21 89.06 0.1 0.1 0.10 dsa_available 188 22 88.30 2.4 9.1 11.92 Internet 141 72 48.94 0.0 8.5 3.06 '0101'H/X121 GB: Coypu (Thorn acces pt to quipu) 278 31 88.85 0.0 1.0 0.34 dsa_available 140 8 94.29 1.6 3.8 5.84 X121 62 4 93.55 0.7 22.0 1.34 Local Ether 199 20 89.95 0.0 10.0 12.10 Internet 186 21 88.71 1.4 6.4 10.71 Janet False Cobra (Root, GB backup) 278 39 85.97 0.0 1.0 0.34 dsa_available 139 11 92.09 1.5 3.8 3.86 X121 186 22 88.17 1.4 5.0 3.43 Janet 199 28 85.93 0.0 8.3 8.10 Internet 180 47 73.89 0.0 4.3 3.77 IXI Vampire Bat (GB backup) 200 36 82.00 0.1 1.0 0.45 dsa_available 77 0 100.00 0.5 3.7 1.00 Private TCP 181 35 80.66 1.3 20.3 5.76 Janet 175 50 71.43 2.2 5.0 5.07 IXI Giant Tortoise (Root, GB Master) 279 99 64.52 0.0 1.0 0.34 dsa_available 142 34 76.06 0.4 3.5 2.90 X121 187 59 68.45 1.0 5.9 3.18 Janet 200 64 68.00 0.0 7.3 5.10 Internet 181 73 59.67 0.0 3.9 2.93 IXI Passionflower Leaf Beetle (GB Domain name information) 260 104 60.00 0.0 1.0 0.33 dsa_available 140 70 50.00 0.0 5.9 4.39 X121 182 83 54.40 0.0 8.6 6.03 Janet 185 86 53.51 0.0 14.8 9.96 Internet 176 100 43.18 0.0 6.3 4.90 IXI Maned Sloth (Edinburgh, DSA holding NRS info) 186 186 0.00 - - - dsa_available 186 186 0.00 - - - Janet US: Fruit Bat (US@l=NY master) 201 27 86.57 0.0 0.1 0.10 dsa_available 197 23 88.32 0.0 6.9 7.95 Internet 4 4 0.00 - - - Internet Alpaca (US master) 204 50 75.49 0.0 0.1 0.10 dsa_available 204 50 75.49 0.0 7.2 10.06 Internet Giant Anteater (Various slave) 200 200 0.00 - - - dsa_available 200 200 0.00 - - - Internet NL: Hornero (NL Master) 202 33 83.66 0.1 0.1 0.10 dsa_available 141 14 90.07 2.2 6.9 14.06 '0101'H/X121 198 69 65.15 1.8 7.2 14.43 Internet Agouti (NL Slave) 205 191 6.83 0.0 0.1 0.05 dsa_available 177 163 7.91 0.0 71.4 6.08 Internet 28 28 0.00 - - - Internet CH: Condor (Swiss Slave) 204 35 82.84 0.1 0.1 0.10 dsa_available 191 22 88.48 1.5 7.5 14.29 Internet 13 13 0.00 - - - Int-X.25 9 9 0.00 - - - Internet Chinchilla (Swiss Master) 264 76 71.21 0.0 0.1 0.08 dsa_available 13 0 100.00 7.7 10.4 40.08 Internet 192 17 91.15 0.0 9.0 13.10 Internet 139 127 8.63 0.0 10.1 4.35 Int-X.25 135 129 4.44 0.0 3.3 0.45 IXI 46 46 0.00 - - - IXI AT: Piranah (AT Master) 185 58 68.65 0.0 0.1 0.07 dsa_available 181 60 66.85 0.0 11.2 11.50 Internet 154 83 46.10 0.0 8.1 11.15 Int-X.25 IE: Irish Elk (Republic of Ireland Master) 234 133 43.16 0.0 1.0 0.21 dsa_available 188 88 53.19 2.7 13.5 17.13 Internet 144 142 1.39 0.0 21.8 7.14 IXI IL: Dorcan Gazelle (Israel Master) 112 85 24.11 0.1 0.1 0.10 dsa_available 112 85 24.11 9.0 20.8 23.28 Internet BE: Woolly Spider Monkey (BE Master) 111 111 0.00 - - - dsa_available 111 111 0.00 - - - Internet