summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1617.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1617.txt')
-rw-r--r--doc/rfc/rfc1617.txt1571
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc1617.txt b/doc/rfc/rfc1617.txt
new file mode 100644
index 0000000..ce57779
--- /dev/null
+++ b/doc/rfc/rfc1617.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group P. Barker
+Request for Comments: 1617 University College London
+RARE Technical Report: 11 S. Kille
+Obsoletes: 1384 ISODE Consortium
+Category: Informational T. Lenggenhager
+ SWITCH
+ May 1994
+
+
+ Naming and Structuring Guidelines for X.500 Directory Pilots
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ Deployment of a Directory will benefit from following certain
+ guidelines. This document defines a number of naming and structuring
+ guidelines focused on White Pages usage. Alignment to these
+ guidelines is recommended for directory pilots. The final version of
+ this document will replace RFC 1384.
+
+Table of Contents
+
+ 1. Introduction 2
+ 2. DIT Structure 3
+ 2.1. Structure Rules 3
+ 2.2. The Top Level of the DIT 3
+ 2.3. Countries 4
+ 2.4. Organisations 5
+ 2.4.1. Directory Manager, Postmaster & Secretary 5
+ 2.4.2. Depth of tree 6
+ 2.4.3. Real World Organisational Structure 7
+ 2.5. Multi-National Organisations 7
+ 2.5.1. The Multi-National as a Single Entity 7
+ 2.5.2. The Multi-National as a Loose Confederation 8
+ 2.5.3. Loosely Linked DIT Sub-Trees 9
+ 2.5.4. Summary of Advantages and Disadvantages of the
+ Above Approaches 9
+ 3. Naming Style 10
+ 3.1. Multi-Component Relative Distinguished Names 11
+ 3.2. National Guidelines for Naming 11
+ 3.3. Naming Organisation and Organisational Unit Names 11
+ 3.4. Naming Human Users 12
+ 3.5. Application Entities 13
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 1]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ 4. Attribute Values 13
+ 4.1. Basic Attribute Syntaxes 13
+ 4.1.1. Printable String 14
+ 4.1.2. IA5 String - T.50 14
+ 4.1.3. Teletex String - T.61 14
+ 4.1.4. Case Ignore String 14
+ 4.1.5. Distinguished Name 14
+ 4.2. Languages & Transliteration 14
+ 4.2.1. Languages other than English 15
+ 4.2.2. Transliteration 15
+ 4.3. Access control 15
+ 4.4. Selected Attributes 16
+ 4.4.1. Personal Attributes 16
+ 4.4.2. Organisational Attributes 18
+ 4.4.3. Local Attributes 19
+ 4.4.4. Miscellaneous Attributes 20
+ 4.4.5. MHS Attributes 21
+ 4.4.6. Postal Attributes 21
+ 4.4.7. Telecom Attributes 22
+ 5. Miscellany 22
+ 5.1. Schema consistency of aliases 22
+ 5.2. Organisational Units 23
+ 6. References 23
+ 7. Security Considerations 23
+ 8. Authors' Addresses 24
+ 9. Appendix - Example Entries 25
+
+1. Introduction
+
+ The intended audience for this document are mainly data managers
+ using X.500 Directory Services. With the help of these guidelines it
+ should be easier for them to define the structure for the part of the
+ Directory Information Tree they want to model, e.g., the
+ representation of their organisation in the Directory. In addition,
+ decisions like which data elements to store for each kind of entry
+ shall be supported.
+
+ These guidelines concentrate mainly on the White Pages use of the
+ Directory, the X.500 application with most operational experience
+ today, nonetheless many recommendations are also valid for other
+ applications of the Directory.
+
+ As a pre-requisite to this document, it is assumed that the COSINE
+ and Internet X.500 Schema is followed [1].
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 2]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+2. DIT Structure
+
+ The majority of this document is concerned with DIT structure, naming
+ and the usage of attributes for organisations, organisational units
+ and personal entries.
+
+ This section briefly notes five other key issues.
+
+2.1 Structure Rules
+
+ A DIT structure is suggested in Annex B of X.521 [2], and it is
+ recommended that Directory Pilots for White Pages services should
+ follow these guidelines. Some simple restrictions should be applied,
+ as described below. For further usage of the Directory like e-mail
+ routing with the Directory or storage of network information in the
+ Directory it will be necessary to follow the guidelines specified in
+ the respective documents.
+
+ One of the few exceptions to the basic DIT structure is, that
+ international organisations will be stored immediately under the root
+ of the tree. Multi-national organisations will be stored within the
+ framework outlined, but with some use of aliases and attributes such
+ as seeAlso to help bind together the constituent parts of these
+ organisations. This is discussed in more detail in section 2.5.
+
+ A general rule for the depth of a subtree is as follows: When a
+ subtree is mainly accessed via searching, it should be as flat as
+ possible to improve the performance, when the access will be mainly
+ through read operations, the depth of the subtree is not a
+ significant parameter for performance.
+
+2.2 The Top Level of the DIT
+
+ The following information will be present at the top level of the
+ DIT:
+
+ Participating Countries
+
+ According to the standard the RDN is the ISO 3166 country code. In
+ addition, the entries should contain suitable values of the
+ friendlyCountryName attribute specified in RFC 1274. Use of this
+ attribute is described in more detail in section 4.4.4.
+
+ International Organisations
+
+ An international organisation is an organisation, such as the
+ United Nations, which inherently has a brief and scope covering
+ many nations. Such organisations might be considered to be
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 3]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ supra-national and this, indeed, is the raison-d'etre of such
+ organisations. Such organisations will almost all be governmental
+ or quasi-governmental. A multi-national organisation is an
+ organisation which operates in more than one country, but is not
+ supra-national. This classification includes the large commercial
+ organisations whose production and sales are spread throughout a
+ large number of countries.
+
+ International organisations may be registered at the top level.
+ This will not be done for multi-national organisations. Currently
+ three organisations are registered so far: Inmarsat, Internet and
+ North Atlantic Treaty Organization.
+
+ Localities
+
+ A few localities will be registered under the root. The chief
+ purpose of these locality entries is to provide a "natural" parent
+ node for organisations which are supra-national, and yet which do
+ not have global authority in their particular field. Such
+ organisations will usually be governmental or quasi-governmental.
+ Example localities might include: Europe, Africa, West Indies.
+ Example organisations within Europe might include: European Court
+ of Justice, European Space Agency, European Commission.
+
+ DSA Information
+
+ Some information on DSAs may be needed at the top level. This
+ should be kept to a minimum.
+
+ The only directory information for which there is a recognised top
+ level registration authority is countries. Registration of other
+ information at the top level may potentially cause problems. At this
+ stage, it is argued that the benefit of limiting additional top level
+ registrations outweighs these problems. However, this potential
+ problem should be noted by anyone making use of such a registration.
+
+2.3 Countries
+
+ The national standardisation bodies will define national guidelines
+ for the structure of the national part of the DIT. In the interim,
+ the following simple structure should suffice. The country entry will
+ appear immediately beneath the root of the tree. Organisations which
+ have national significance should have entries immediately beneath
+ their respective country entries. Smaller organisations which are
+ only known in a particular locality should be placed underneath
+ locality entries representing states or similar geographical
+ divisions. Entry for private persons will be listed under the
+ locality entries. An example plan evolving for the US is the work of
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 4]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ the North American Directory Forum [3]. Another example is the
+ organisation of the X.500 namespace as standardized in Australia [4].
+
+2.4 Organisations
+
+ Large organisations will probably need to be sub-divided by
+ organisational units to help in the disambiguation of entries for
+ people with common names. Entries for people and roles will be stored
+ beneath organisations or organisational units.
+
+ The organisation entry itself shall contain the information necessary
+ to contact the organisation: for example, postal address, telephone
+ and fax numbers.
+
+ Although the structure of organisations often changes considerably
+ over time, the aim should be to minimise the number of changes to the
+ DIT. Note that renaming a superior, department entry has the effect
+ of changing the DN of all subordinate entries. This has an
+ undesirable impact on the service for several reasons. Alias entries
+ and certain attributes or ordinary entries such as seeAlso, secretary
+ and roleOccupant use DNs to maintain links with other entries. These
+ references are one-way only and the Directory standard offers no
+ support to automatically update all references to an entry once its
+ DN changes.
+
+2.4.1 Directory Manager, Postmaster & Secretary
+
+ Similar to messaging, where every domain has its postmaster address
+ it is highly recommended that each organisation in the X.500
+ Directory has two entries: Postmaster and Directory Manager. In
+ addition, Secretary entries for an organisation and its units should
+ be listed. If this guidance is followed, users will benefit because
+ it will be straightforward to find the right contacts for questions
+ or problems with the service.
+
+ These entries should use the object class organizationalRole with the
+ roleOccupant attributes containing the distinguished names of the
+ persons in charge of this role. The values
+
+ CN=Directory Manager
+
+ CN=Postmaster
+
+ CN=Secretary
+
+ should be added as additional values whenever another language than
+ English is used for the name of the entries.
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 5]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+2.4.2 Depth of tree
+
+ The broad recommendation for White Pages is that the DIT should be as
+ flat as possible. A flat tree means that Directory names will be
+ relatively short, and probably somewhat similar in length and
+ component structure to paper mail addresses. A deep DIT would imply
+ long Directory names, with somewhat arbitrary component parts, with a
+ result which it is argued seems less natural. Any artificiality in
+ the choice of names militates against successful querying.
+
+ A presumption behind this style of naming is that most querying will
+ be supported by the user specifying convenient strings of characters
+ which will be mapped onto powerful search operations. The
+ alternative approach of the user browsing their way down the tree and
+ selecting names from large numbers of possibilities may be more
+ appropriate in some cases, and a deeper tree facilitates this.
+ However, these guidelines recommend a shallow tree, and implicitly a
+ search oriented approach.
+
+ It may be considered that there are two determinants of DIT depth:
+ first, how far down the DIT an organisation is placed; second, the
+ structure of the DIT within organisations.
+
+ The structure of the upper levels of the tree will be determined in
+ due course by various registration authorities, and the pilot will
+ have to work within the given structure. However, it is important
+ that the various pilots are cognisant of what the structures are
+ likely to be, and move early to adopt these structures.
+
+ The other principal determinant of DIT depth is whether an
+ organisation splits its entries over a number of organisational
+ units, and if so, the number of levels. The recommendation here is
+ that this sub-division of organisations is kept to a minimum. A
+ maximum of two levels of organisational unit should suffice even for
+ large organisations. Organisations with only a few tens or hundreds
+ of employees should strongly consider not using organisational units
+ at all. It is noted that there may be some problems with choice of
+ unique RDNs when using a flat DIT structure. Multi-component RDNs can
+ alleviate this problem: see section 3.1. The standard X.521
+ recommends that an organizationalUnitName attribute can also be used
+ as a naming attribute to disambiguate entries [2]. Further
+ disambiguation may be achieved by the use of a personalTitle or
+ userId attribute in the RDN.
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 6]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+2.4.3 Real World Organisational Structure
+
+ Another aspect on designing the DIT structure for an organisation is
+ the administrative structure within a company. Using the same
+ structure in the DIT might help in distributing maintenance authority
+ to the different units. Please note comments on the stability of the
+ DIT structure in section 2.4.
+
+2.5 Multi-National Organisations
+
+ The standard says that only international organisations may be placed
+ under the root of the DIT. This implies that multi-national
+ organisations must be represented as a number of separate entries
+ underneath country or locality entries. This structure makes it more
+ awkward to use X.500 within a multi-national to provide an internal
+ organisational directory, as the data is now spread widely throughout
+ the DIT, rather than all being grouped within a single sub-tree.
+
+ Many people have expressed the view that this restriction is a severe
+ limitation of X.500, and argue that the intentions of the standard
+ should be ignored in this respect. This note argues, though, that the
+ standard should be followed.
+
+ No attempt to precisely define multinational organisation is essayed
+ here. Instead, the observation is made that the term is applied to a
+ variety of organisational structures, where an organisation operates
+ in more than one country. This suggests that a variety of DIT
+ structures may be appropriate to accommodate these different
+ organisational structures. This document suggests three approaches,
+ and notes some of the characteristics associated with each of these
+ approaches.
+
+ Before considering the approaches, it is worth bearing in mind again
+ that a major aim in the choice of a DIT structure is to facilitate
+ querying, and that approaches which militate against this should be
+ avoided wherever possible.
+
+2.5.1 The Multi-National as a Single Entity
+
+ In many cases, a multi-national organisation will operate with a
+ highly centralised structure. While the organisation may have large
+ operations in a number of countries, the organisation is strongly
+ controlled from the centre and the disparate parts of the
+ organisation exist only as limbs of the main organisation. In such a
+ situation, the model shown in figure 1 may be the best choice.
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 7]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ ROOT
+
+ / | \
+ / | \
+
+ C=GB C=FR C=US
+
+ / | \
+ / | \
+
+ O=MultiNat---->O=MultiNat<----O=MultiNat
+
+ / | \
+ / | \
+ / | \
+
+ l=abc ou=def l=fgi
+
+ ---> means "alias to"
+
+ Figure 1: The multi-national as a single entity
+
+ The organisation's entries all exist under a single sub-tree. The
+ organisational structure beneath the organisation entry should
+ reflect the perceived structure of the organisation, and so no
+ recommendations on this matter can be made here. To assist the person
+ querying the directory, alias entries should be created under all
+ countries where the organisation operates.
+
+2.5.2 The Multi-National as a Loose Confederation
+
+ Another common model of organisational structure is that where a
+ multi-national consists of a number of national entities, which are
+ in large part independent of both sibling national entities, and of
+ any central entity. In such cases, the model shown in Figure 2 may be
+ a better choice. Organisational entries exist within each country,
+ and only that country's localities and organisational units appear
+ directly beneath the appropriate organisational entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 8]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ ROOT
+
+ / | \
+ / | \
+ C=GB C=FR C=US
+
+ / | \
+ / | \
+ O=MultiNat O=MultiNat O=MultiNat
+
+ / | / | \ | \
+ / | / | \ | \
+
+ L=FR L=GB<---L=GB | L=US--->L=US L=FR
+ \ | /
+ ------------------->L=FR<----------------
+
+ ---> means "alias to"
+
+ Figure 2: The multi-national as a loose confederation
+
+ Some binding together of the various parts of the organisation can be
+ achieved by the use of aliases for localities and organisational
+ units, and this can be done in a highly flexible fashion. In some
+ cases, the national view might not contain all branches of the
+ company, as illustrated in Figure 2.
+
+2.5.3 Loosely Linked DIT Sub-Trees
+
+ A third approach is to avoid aliasing altogether, and to use the
+ looser binding provided by an attribute such as seeAlso. This
+ approach treats all parts of an organisation as essentially separate.
+
+ A unified view of the organisation can only be achieved by user
+ interfaces choosing to follow the seeAlso links. This is a key
+ difference with aliasing, where decisions to follow links may be
+ specified within the protocol. (Note that it may be better to specify
+ another attribute for this purpose, as seeAlso is likely to be used
+ for a wide variety of purposes.)
+
+2.5.4 Summary of Advantages and Disadvantages of the Above Approaches
+
+ Providing an internal directory
+
+ All the above methods can be used to provide an internal
+ directory. In the first two cases, the linkage to other parts of
+ the organisation can be followed by the protocol and thus
+ organisation-wide searches can be achieved by single X.500
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 9]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ operations. In the last case, interfaces would have to "know" to
+ follow the soft links indicated by the seeAlso attribute.
+
+ Impact on naming
+
+ In the single-entity model, all DNs within the organisation will
+ be under one country. It could be argued that this will often
+ result in rather "unnatural" naming. In the loose- confederation
+ model, DNs are more natural, although the need to disambiguate
+ between organisational units and localities on an international,
+ rather than just a national, basis may have some impact on the
+ choice of names. For example, it may be necessary to add in an
+ extra level of organisational unit or locality information. In the
+ loosely-linked model, there is no impact on naming at all.
+
+ Views of the organisation
+
+ The first method provides a unique view of the organisation. The
+ loose confederacy allows for a variety of views of the
+ organisation. The view from the centre of the organisation may
+ well be that all constituent organisations should be seen as part
+ of the main organisation, whereas other parts of the organisation
+ may only be interested in the organisation's centre and a few of
+ its sibling organisations. The third model gives an equally
+ flexible view of organisational structures.
+
+ Lookup performance
+
+ All methods should perform reasonably well, providing information
+ is either held within a single DSA or it is replicated to the
+ other DSAs.
+
+3. Naming Style
+
+ The first goal of naming is to provide unique identifiers for
+ entries. Once this is achieved, the next major goal in naming entries
+ should be to facilitate querying of the Directory. In particular,
+ support for a naming structure which facilitates use of user friendly
+ naming [5] is desirable. Other considerations, such as accurately
+ reflecting the organisational structure of an organisation, should be
+ disregarded if this has an adverse effect on normal querying. Early
+ experience in the pilot has shown that a consistent approach to
+ structure and naming is an aid to querying using a wide range of user
+ interfaces, as interfaces are often optimised for DIT structures
+ which appear prevalent. In addition, the X.501 standard notes that
+ "RDNs are intended to be long-lived so that the users of the
+ Directory can store the distinguished names of objects..." and "It is
+ preferable that distinguished names of objects which humans have to
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 10]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ deal with be user-friendly." [2]
+
+ Naming is dependent on a number of factors and these are now
+ considered in turn.
+
+3.1 Multi-Component Relative Distinguished Names
+
+ According to the standard, relative distinguished names may have more
+ than one component selected from the set of the attributes of the
+ entry to be named. This is useful when there are, for example, two
+ "John Smiths" in one department. The use of multi-component relative
+ distinguished names allows one to avoid artificial naming values such
+ as "John Smith 1" or "John Smith-2". Attributes which could be used
+ as the additional naming attribute include: personalTitle,
+ roomNumber, telephoneNumber, and userId.
+
+3.2 National Guidelines for Naming
+
+ Where naming is being done in a country which has established
+ guidelines for naming, these guidelines should in general be
+ followed. These guidelines might be based on an established
+ registration authority, or may make use of an existing registration
+ mechanism (e.g., company name registration).
+
+ Where an organisation has a name which is nationally registered in an
+ existing registry, this name is likely to be appropriate for use in
+ the Directory, even in cases where there are no national guidelines.
+
+3.3 Naming Organisation and Organisational Unit Names
+
+ The naming of organisations in the Directory will ultimately come
+ under the jurisdiction of official naming authorities. In the
+ interim, it is recommended that pilots and organisations follow these
+ guidelines. An organisation's RDN should usually be the full name of
+ the organisation, rather than just a set of initials. This means that
+ University College London should be preferred over UCL. An example
+ of the problems which a short name might cause is given by the
+ proposed registration of AA for the Automobile Association. This
+ seems reasonable at first glance, as the Automobile Association is
+ well known by this acronym. However, it seems less reasonable in a
+ broader perspective when you consider that organisations such as
+ Alcoholics Anonymous and American Airlines use the same acronym.
+
+ Just as initials should usually be avoided for organisational RDNs,
+ so should formal names which, for example, exist only on official
+ charters and are not generally well known. There are two reasons for
+ this approach:
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 11]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ 1. The names should be meaningful.
+
+ 2. The names should uniquely identify the organisation, and be
+ a name which is unlikely to be challenged in an open
+ registration process. For example, UCL might well be
+ challenged by United Carriers Ltd.
+
+ The same arguments on naming style can be applied with even greater
+ force to the choice of RDNs for organisational units. While
+ abbreviated names will be in common parlance within an organisation,
+ they will almost always be meaningless outside of that organisation.
+ While many people in academic computing habitually refer to CS when
+ thinking of Computer Science, CS may be given several different
+ interpretations. It could equally be interpreted as Computing
+ Services, Cognitive Science, Clinical Science or even Counselling
+ Services.
+
+ For both organisations and organisational units, extra naming
+ information should be stored in the directory as alternative values
+ of the naming attribute. Thus, for University College London, UCL
+ should be stored as an alternative organizationName attribute value.
+ Similarly CS could be stored as an alternative organizationalUnitName
+ value for Computer Science and any of the other departments cited
+ earlier. In general, entries will be located by searching, and so it
+ is not essential to have RDNs which are either the most memorable or
+ guessable, although names should be recognisable. The need for users
+ not to type long names may be achieved by use of carefully selected
+ alternative values.
+
+3.4 Naming Human Users
+
+ A reasonably consistent approach to naming people is particularly
+ critical as a large percentage of directory usage will be looking up
+ information about people. User interfaces will be better able to
+ assist users if entries have names conforming to a common format, or
+ small group of formats. It is suggested that the RDN should follow
+ such a format. Alternative values of the common name attribute should
+ be used to store extra naming information. It seems sensible to try
+ to ensure that the RDN commonName value is genuinely the most common
+ name for a person as it is likely that user interfaces may choose to
+ place greater weight on matches on the RDN than on matches on one of
+ the alternative names.
+
+ The choice of RDN for humans will be influenced by cultural
+ considerations. In many countries the best choice will be of the form
+ familiar-first-name surname. Thus, Steve Kille is preferred as the
+ RDN choice for one of this document's co-authors, while Stephen E.
+ Kille is stored as an alternative commonName value. Pragmatic choices
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 12]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ will have to be made for other cultures. The common name attribute
+ should not be used to hold other attribute information such as
+ telephone numbers, room numbers, or local codes. Such information
+ should be stored within the appropriate attributes as defined in the
+ COSINE and Internet X.500 Schema. Section 3.1 on multi-component RDNs
+ shows how clashing names can be made unique.
+
+ The choice of a naming strategy should not be made on the basis of
+ the possibilities of the currently available user interface
+ implementations. For example, it is inappropriate to use common names
+ of the form 'surname firstname' merely because a user interface
+ presents results in a more satisfactory order by so doing. Use the
+ best structure for human names, and fix the user interface!
+
+ More details on the use of commonName in section 4.4.1.
+
+3.5 Application Entities
+
+ The guidelines of X.521 should be followed, in that the application
+ entity should always be named relative to an Organisation or
+ Organisational Unit. The application process will often correspond to
+ a system or host. In this case, the application entities should be
+ named by Common Names which identify the service (e.g., "FTAM
+ Service"). In cases where there is no useful distinction between
+ application process and application entity, the application process
+ may be omitted (This is often done for DSAs in the current pilot).
+
+4. Attribute Values
+
+ In general the attribute values should be used as documented in the
+ standards. Sometimes the standard is not very precise about which
+ attribute to use and how to represent a value.
+
+ The following sections give recommendations how to use them in X.500
+ pilot projects.
+
+4.1 Basic Attribute Syntaxes
+
+ Every attribute type has a definition of the attribute syntaxes its
+ values may be use. Most attribute types make use the basic attribute
+ syntaxes only.
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 13]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+4.1.1 Printable String
+
+ This most simple syntax uses a subset of characters from ISO 646 IRV.
+
+ A-Z a-z 0-9 ' ( ) +
+
+ , - . / : ? space
+
+ Tab 1: Characters in PrintableString
+
+4.1.2 IA5 String - T.50
+
+ The International Alphabet No. 5 (IA5) is known from the X.400
+ message handling service. It covers a wider range of characters than
+ the printable string. The international reference version of IA5
+ offers the same set of characters as ISO 646 IRV.
+
+4.1.3 Teletex String - T.61
+
+ The Teletex character set is a very unusual one in the computing
+ environment because it uses mixed one and two octet character codes
+ which are more difficult to handle than single octet codes. Most of
+ the characters can be mapped to the more often supported 8-bit
+ character set standard ISO 8859-1 (ISO Latin-1).
+
+4.1.4 Case Ignore String
+
+ Many attributes use this case insensitive syntax. It allows attribute
+ values to be represented using a mixture of upper and lower case
+ letters, as appropriate. Matching of attribute values, however, is
+ performed such that no significance is given to case.
+
+4.1.5 Distinguished Name
+
+ A Distinguished Name should currently never contain a value in T.61
+ string syntax because most users would not be able to view or type it
+ correctly by lack of appropriate hardware/software configuration.
+ Therefore, only the characters defined in printable string syntax
+ should be used as part of a RDN. The correct representation of the
+ name should be added as additional attribute value to match for
+ search operations.
+
+4.2 Languages & Transliteration
+
+ The standard as available has no support at all for the use of
+ different languages in the Directory. It is e.g., not possible to add
+ a language qualifier to a description attribute nor is it possible to
+ use characters beyond the Teletex character set.
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 14]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+4.2.1 Languages other than English
+
+ Many countries have more than one national language and a world-wide
+ Directory must be able to support non-English-speaking users.
+
+ Until the standard provides a solution for this problem it is
+ possible to make use of multi-valued attributes to specify a value
+ not only in the local languages but also in English.
+
+ In particular the friendlyCountryName, stateOrProvinceName and
+ localityName attributes should use the most often used translations
+ of its original value to increase the chance for successful searches
+ also for users with a foreign language. Other attributes like
+ description, organizationName and organizationalUnitName attributes
+ should provide multi-lingual values where appropriate.
+
+ The drawback of this solution is, that the user interfaces present
+ much redundant information because they are not able to know the
+ language of the values and make an automatic selection.
+
+ Note: The sequence of multi-valued attribute values in an entry
+ cannot be defined. It is always up to the DSA to decide on
+ which order to store them and return them as results, and
+ to the DUA to decide on which order to display them.
+
+4.2.2 Transliteration
+
+ What measures can be taken to make sure all users are able to read an
+ attribute, when a value uses one of the special characters from the
+ T.61 character set? An interim solution is transliteration as used in
+ earlier days with the typewriters, where e.g., the German 'a' with
+ umlaut is written as 'ae'. Transliteration is not necessarily unique
+ since it is dependent on the language, English speakers transliterate
+ the 'a' with umlaut just to an 'a'. However, it is an improvement
+ over just using the T.61 value since it may not be possible to
+ display such a value at all. Whenever an attribute needs a character
+ not in PrintableString and the attribute syntax allows the use of the
+ T.61 character set, it is recommended that the attribute should be
+ supplied as multi-valued attribute both in T.61 string and in a
+ transliterated PrintableString notation.
+
+4.3 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 successful querying of the Directory. For example,
+ user interfaces typically limit the scope of their searches by
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 15]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ 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.
+
+4.4 Selected Attributes
+
+ The section lists attributes together with a short description what
+ they should be used for and some examples. [6] The source of the
+ attributes is given in brackets.
+
+ Note that due to national legal restrictions on privacy issues it
+ might be forbidden to use certain attributes or that the search on
+ them is restricted. [7]
+
+4.4.1 Personal Attributes
+
+ commonName [X.520]
+
+ It is proposed that pilots should ignore the standard's
+ recommendations on storing personal titles, and letters indicating
+ academic and professional qualifications within the commonName
+ attribute, as this overloads the commonName attribute. A
+ personalTitle attribute has already been specified in the COSINE
+ and Internet Schema, and another attribute could be specified for
+ information about qualifications.
+
+ The choice of a name depends on the culture as discussed in
+ section 3.4. When a commonName is selected as (part of) a RDN the
+ most often used form of the name should be selected. A firstname
+ should never be supplied only as an initial (unless, of course,
+ the source data does not include forenames). It is very important
+ to have its full value in order to be able to distinguish between
+ two similar entries. Sets of initials should not be concatenated
+ into a single "word", but be separated by spaces and/or "."
+ characters.
+
+
+ Format: Firstname [Initials] Lastname
+
+ Example: Steve Kille
+
+ Stephen E. Kille
+
+ S.E. Kille
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 16]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ The use of 'Lastname Firstname' is deprecated as explained in
+ section 3.4.
+
+ favouriteDrink [RFC 1274]
+
+ The intention of this attribute is that it provides at least one
+ benign attribute which any user can create or modify, given a
+ suitable user interface, without having the unfortunate impact on
+ the directory service that follows from modifying an attribute
+ such as an e-mail address or telephone number.
+
+ Example: Pure Crystal Water
+
+ organizationalStatus [RFC 1274]
+
+ 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 consider carefully the
+ distinctions between this and the title and description
+ attributes.
+
+ Example: undergraduate student
+
+ personalTitle [RFC 1274]
+
+ The usually used titles, especially academic ones. Excessive use
+ should be avoided.
+
+ Example: Prof. Dr.
+
+ roomNumber [RFC 1274]
+
+ The room where the person works, it will mostly be locally defined
+ how to write the room number, e.g., Building Floor Room.
+
+ Example: HLW B12
+
+ secretary [RFC 1274]
+
+ The secretary of the person. This is the Distinguished Name (DN)
+ of the secretary.
+
+ Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 17]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ surname [X.520]
+
+ Like with commonName it is a matter of culture what to use for
+ surname in case of a noble name, e.g., de Stefani, von Gunten.
+
+ Example: Kille
+
+ title [X.520]
+
+ Title describing the position, job title or function of an
+ organisational person.
+
+ Example: Manager - International Sales
+
+ userId [RFC 1274]
+
+ When an organisation has centrally managed user ids, it might make
+ sense to include it into the entry. It might also be used to form
+ a unique RDN for the person.
+
+ Example: skille
+
+ userPassword [X.520]
+
+ The password of the entry which allows the modification of the
+ entry, provided that the access control permits it. The password
+ should not be the same as any system password, unless it is sure
+ that nobody can read it. With the current implementations this is
+ mostly not guaranteed.
+
+ Example: 8kiu8z7e
+
+4.4.2 Organisational Attributes
+
+ associatedDomain [RFC 1274]
+
+ The Internet domain name for an organisation or one of its units.
+
+ Example: isode.com
+
+ businessCategory [X.520]
+
+ Type of business an organisation, an organisational unit or
+ organisational person is involved in. The values could be chosen
+ from a thesaurus.
+
+ Example: Software Development
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 18]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ organizationName [X.520]
+
+ The name of the organisation. The value for the RDN should be
+ chosen according to section 3.3. Additional names like
+ abbreviations should be used for better search results.
+
+ Example: Uni Lausanne
+ Universite de Lausanne
+ Universit\c2e Lausanne (with a T.61 encoded umlaut)
+ University of Lausanne
+ unil
+
+ organizationalUnitName [X.520]
+
+ The name of a part of the organisation. The value for the RDN
+ should be chosen according to section 3.3. Additional names like
+ abbreviations should be provided for better search results.
+
+ Example: Institut fuer Angewandte Mathematik
+ Mathematik
+ iam
+
+ roleOccupant [X.520]
+
+ The person(s) in that role. This is the Distinguished Name of the
+ entry of the person(s).
+
+ Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
+
+ searchGuide [X.520]
+
+ The currently available DUAs make no use this attribute. It seems
+ that it is not powerful enough for real usage. Experience is
+ needed before being able to give recommendations on how to
+ configure it.
+
+4.4.3 Local Attributes
+
+ localityName [X.520]
+
+ Name of the place, village or town with values in local and other
+ languages as useful.
+
+ Example: Bale
+ B\c3ale (with a T.61 encoded accented character) Basel
+ Basilea
+ Basle
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 19]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ stateOrProvinceName [X.520]
+
+ Name of the canton, county, department, province or state with
+ values in local and other languages as useful. If official and
+ commonly used abbreviations exist for the states, they should be
+ supplied as additional values
+
+ Example: Ticino
+ Tessin
+ TI
+
+4.4.4 Miscellaneous Attributes
+
+ audio [RFC 1274]
+
+ The audio attribute uses a u-law encoded sound file as used by the
+ "play" utility on a Sun 4. According to RFC 1274 it is an interim
+ format. It may be useful to listen to the pronunciation of a name
+ which is otherwise unknown.
+
+ description [X.520]
+
+ A short informal explanation of special interests of a person or
+ organisation. Overlap with businessCategory, organizationalStatus
+ and title should be avoided.
+
+ Example: Networking, distributed systems, OSI, implementation.
+
+ friendlyCountryName [RFC 1274]
+
+ The friendlyCountryName attribute type specifies names of
+ countries in human readable format. Especially the country name as
+ used in the major languages should be included as additional
+ values to help foreign users.
+
+ jpegPhoto [RFC 1488] [8]
+
+ A colour or grayscale picture encoded according to JPEG File
+ Interchange Format (JFIF). Thanks to compression the size of the
+ pictures is moderate. For persons it may show a portrait, for
+ organisations the company logo or a map on how to get there.
+
+ photo [RFC 1274]
+
+ The photo attribute is a b/w G3 fax encoded picture of an object.
+ The size of the photo should be in a sensible relation to the
+ informational value of it. This attribute will be replaced by
+ jpegPhoto.
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 20]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ seeAlso [X.520]
+
+ Reference to another closely related entry in the DIT, e.g., from
+ a room to the person using that room. It is the Distinguished Name
+ of the entry.
+
+ Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
+
+4.4.5 MHS Attributes
+
+ mhsORAddresses [X.411]
+
+ The attribute uses internally an ASN.1 structure. The string
+ notation used for display purposes is implementation dependent.
+ This attribute is especially useful for an integrated X.400 user
+ agent since it gets the address in a directly usable format.
+
+ rfc822mailbox [RFC 1274]
+
+ E-Mail address in RFC 822 notation
+
+ Example: s.kille@isode.com
+
+ textEncodedORAddress [RFC 1274]
+
+ X.400 e-mail address in string notation. The F.401 notation should
+ be used. This attribute shall disappear once the majority of the
+ DUAs support the mhsORAddresses attribute. The advantage of the
+ latter attribute is, that a configurable DUA could adjust the
+ syntax to the one needed by the local mailer, where
+ textencodedORAddress is just a string which will mostly have a
+ different syntax than the mailer expects.
+
+ Example: G=thomas; S=lenggenhager; OU1=gate; O=switch; \
+ P=switch; A=arcom; C=ch;
+
+4.4.6 Postal Attributes
+
+ postalAddress [X.520]
+
+ The full postal address (but not including the name) in
+ international notation, with up to 6 lines with 30 characters
+ each.
+
+ Example: SWITCH
+ Limmatquai 13
+ CH-8001 Zurich
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 21]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ postalCode [X.520]
+
+ The postalCode will be the same as used in the postalAddress (in
+ international notation).
+
+ Example: CH-8001
+
+ streetAddress [X.520]
+
+ It shall be the street where the person has its office. Mostly, it
+ will be the street part of the postalAddress.
+
+ Example: Limmatquai 138
+
+4.4.7 Telecom Attributes
+
+ telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520]
+
+ The phone number in the international notation according to CCITT
+ E.123. The separator '-' instead of space may be used according to
+ the local habit, it should be used consistently within a country.
+
+ Format: "+" <country code> <national number> ["x" <extension>]
+ Example: +41 1 268 1540
+
+ telexNumber [X.520]
+
+ The telex number in the international notation
+
+ Example: 817379, ch, ehhg
+
+5. Miscellany
+
+ This section draws attention to two areas which frequently provoke
+ questions, and where it is felt that a consistent approach will be
+ useful.
+
+5.1 Schema consistency of aliases
+
+ According to the letter of the standard, an alias may point at any
+ entry. It is beneficial for aliases to be 'schema consistent'.
+
+ The following two checks should be made:
+
+ 1. The Relative Distinguished Name of the alias should use an
+ attribute type normally used for naming entries of the
+ object class of the main entry.
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 22]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ 2. If the entry (aliased object) were placed where the alias
+ is, there should be no schema violation.
+
+5.2 Organisational Units
+
+ There is a problem that many organisations can be either
+ organisations or organisational units, dependent on the location in
+ the DIT (with aliases giving the alternate names). For example, an
+ organisation may be an independent national organisation and also an
+ organisational unit of a parent organisation. To achieve this, it is
+ important to allow an entry to be of both object class organisation
+ and of object class organisational unit.
+
+6. References
+
+ [1] Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
+ X.500 schema", RFC 1274, Department of Computer Science,
+ University College London, November 1991.
+
+ [2] "The Directory --- Overview of concepts, models and services",
+ CCITT X.500 Series Recommendations, December 1988.
+
+ [3] The North American Directory Forum. "A Naming Scheme for C=US",
+ RFC 1255, NADF-175, NADF, September 1991.
+
+ [4] Michaelson, G., and M. Prior, "Naming Guidelines for the AARNet
+ X.500 Directory Service", RFC 1562, AEN-001, The University of
+ Queensland, The University of Adelaide, December 1993.
+
+ [5] Hardcastle-Kille, S., "Using the OSI Directory to achieve user
+ friendly naming", RFC 1484, Department of Computer Science,
+ University College London, July 1993.
+
+ [6] Barker, P., "Preparing data for inclusion in an X.500 Directory",
+ Research Note RN/92/41, Department of Computer Science,
+ University College London, May 1992.
+
+ [7] Jeunink, E., and E. Huizer, "Directory Services and Privacy
+ Issues", RARE WG-DATMAN, TF-LEGAL, Work in Progress, May 1993.
+
+ [8] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The X.500
+ String Representation of Standard Attribute Syntaxes", RFC 1488,
+ University of Michigan, ISODE Consortium, Performance Systems
+ International, NeXor Ltd., July 1993.
+
+7. Security Considerations
+
+ Security issues are not substantially discussed in this memo.
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 23]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+8. Authors' Addresses
+
+ Paul Barker
+ Department of Computer Science
+ University College London
+ Gower Street
+ London WC1E 6BT
+ England
+
+ Phone: +44 71 380 7366
+ EMail: p.barker@cs.ucl.ac.uk
+
+ DN: CN=Paul Barker, OU=Computer Science, O=University College
+ London, C=GB
+
+ UFN: Paul Barker, Computer Science, UCL, GB
+
+
+ Steve Kille
+ ISODE Consortium
+ The Dome
+ The Square
+ Richmond TW9 1DT
+ England
+
+ Phone: +44 81 332 9091
+ EMail: s.kille@isode.com
+
+ DN: CN=Steve Kille, O=ISODE Consortium, C=GB
+
+ UFN: S. Kille, ISODE Consortium, GB
+
+
+ Thomas Lenggenhager
+ SWITCH
+ Limmatquai 138
+ CH-8001 Zurich
+ Switzerland
+
+ Phone: +41 1 268 1540
+ EMail: lenggenhager@switch.ch
+
+ DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH
+
+ UFN: Thomas Lenggenhager, SWITCH, CH
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 24]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+9. Appendix - Example Entries
+
+9.1 Country
+
+ DN: C=CH
+
+ objectClass=top & country & domainRelatedObject & friendlyCountry
+ country=CH
+ associatedDomain=ch
+ friendlyCountryName=CH
+ friendlyCountryName=Confoederatio Helvetica
+ friendlyCountryName=Schweiz
+ friendlyCountryName=Suisse
+ friendlyCountryName=Svizzera
+ friendlyCountryName=Switzerland
+
+9.2 Organisation
+
+ DN: O=SWITCH, C=CH
+
+ objectClass=top & organization & mhsUser & domainRelatedObject
+ description=Swiss Academic and Research Network
+ organizationName=SWIss TeleCommunication system for Higher
+ education\and research
+ organizationName=Swiss Academic and Research Network
+ organizationName=SWITCH
+ localityName=Zuerich
+ localityName=Zurich
+ localityName={T.61}Z\c8urich
+ stateOrProvinceName=ZH
+ stateOrProvinceName=Zuerich
+ stateOrProvinceName=Zurich
+ stateOrProvinceName={T.61}Z\c8urich
+ postalAddress=SWITCH
+ Limmatquai 138
+ CH-8001 Zurich
+ postalCode=CH-8001
+ streetAddress=Limmatquai 138
+ telephoneNumber=+41 1 268 1515
+ facsimileTelephoneNumber=+41 1 268 1568
+ seeAlso=CN=Postmaster, O=SWITCH, C=CH
+ mhsORAddresses=S=postmaster, O=switch; P=switch; A=arcom; C=ch;
+ associatedDomain=switch.ch
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 25]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+9.3 Organisation Unit
+
+ DN: OU=SWITCHdirectory, O=SWITCH, C=CH
+
+ objectClass=top & organizationalUnit
+ description=The SWITCH X.500 pilot project
+ organizationalUnitName=SWITCHdirectory
+ localityName=Zurich
+ localityName=Zuerich
+ localityName={T.61}Z\c8urich
+ stateOrProvinceName=Zurich
+ stateOrProvinceName=Zuerich
+ stateOrProvinceName=ZH
+ stateOrProvinceName={T.61}Z\c8urich
+ postalAddress=SWITCHdirectory
+ SWITCH
+ Limmatquai 138
+ CH-8001 Zurich
+ postalCode=CH-8001
+ streetAddress=Limmatquai 138
+ telephoneNumber=+41 1 268 1540
+ facsimileTelephoneNumber=+41 1 268 1568
+
+9.4 Organizational Role
+
+ DN: CN=Directory Manager, O=SWITCH, C=CH
+
+ objectClass=top & organizationalRole & mhsUser
+ commonName=Directory Manager
+ description=SWITCH Directory Managers
+ roleOccupant=CN=Martin Berli, O=SWITCH, C=CH
+ roleOccupant=CN=Thomas Lenggenhager, O=SWITCH, C=CH
+ localityName=Zuerich
+ localityName=Zurich
+ localityName={T.61}Z\c8urich
+ stateOrProvinceName=Zurich
+ stateOrProvinceName=Zuerich
+ stateOrProvinceName=ZH
+ stateOrProvinceName={T.61}Z\c8urich
+ postalAddress=SWITCHdirectory
+ SWITCH
+ Limmatquai 138
+ CH-8001 Zurich
+ postalCode=CH-8001
+ streetAddress=Limmatquai 138
+ telephoneNumber=+41 1 268 1540
+ facsimileTelephoneNumber=+41 1 268 1568
+ mhsORAddresses=S=switchinfo; O=switch; P=switch; A=arcom; C=ch;
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 26]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+ DN: CN=Postmaster, O=SWITCH, C=CH
+
+ objectClass=top & organizationalRole & mhsUser
+ commonName=Postmaster
+ commonName=Helpdesk
+ roleOccupant=CN=Christoph Graf, O=SWITCH, C=CH
+ roleOccupant=CN=Felix Kugler, O=SWITCH, C=CH
+ roleOccupant=CN=Marcel Parodi, O=SWITCH, C=CH
+ roleOccupant=CN=Marcel Schneider, O=SWITCH, C=CH
+ telephoneNumber=+41 1 268 1520
+ facsimileTelephoneNumber=+41 1 268 1568
+ mhsORAddresses=S=postmaster; O=switch; P=switch; A=arcom; C=ch;
+
+ DN: CN=Secretary, O=SWITCH, C=CH
+
+ objectClass=top & organizationalRole & quipuObject
+ commonName=Secretary
+ roleOccupant=CN=Franziska Remund, O=SWITCH, C=CH
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 27]
+
+RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
+
+
+9.5 Person
+
+ DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH
+
+ objectClass=top & person & organizationalPerson & mhsUser &
+ pilotObject & newPilotPerson
+ commonName=Thomas Lenggenhager
+ commonName=T. Lenggenhager
+ surname=Lenggenhager
+ description=SWITCHinfo, Project Leader
+ localityName=Zuerich
+ localityName=Zurich
+ localityName={T.61}Z\c8urich
+ stateOrProvinceName=ZH
+ stateOrProvinceName=Zuerich
+ stateOrProvinceName=Zurich
+ stateOrProvinceName={T.61}Z\c8urich
+ postalAddress=SWITCH
+ Limmatquai 138
+ CH-8001 Zurich
+ postalCode=CH-8001
+ streetAddress=Limmatquai 138
+ telephoneNumber=+41 1 268 1540
+ facsimileTelephoneNumber=+41 1 268 1568
+ mhsORAddresses=S=lenggenhager; O=switch; P=switch; A=arcom; C=ch;
+ userPassword=secret
+ textEncodedORaddress={T.61}S=lenggenhager; O=switch; P=switch; \
+ A=arcom; C=ch;
+ rfc822mailbox=lenggenhager@switch.ch
+ secretary=CN=Franziska Remund, O=SWITCH, C=CH
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support (WG-NAP) [Page 28]
+