RFC1617 日本語訳

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

コメントを求めるワーキンググループP.バーカー要求をネットワークでつないでください: 1617年のユニバーシティ・カレッジのロンドンのまれな技術報告書: 11秒間Killeは以下を時代遅れにします。 1384年のISODE共同体カテゴリ: 情報のT.Lenggenhagerスイッチ1994年5月

      Naming and Structuring Guidelines for X.500 Directory Pilots

X.500ディレクトリのパイロットのためにガイドラインを命名して、構造化します。

Status of this Memo

この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.

ディレクトリの展開は次のあるガイドラインの利益を得るでしょう。 このドキュメントはホワイトページ用法に集中しているガイドラインを命名して、構造化する数を定義します。 これらのガイドラインへの整列はディレクトリのパイロットのために推薦されます。 このドキュメントの最終版はRFC1384を取り替えるでしょう。

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

1. 序論2 2。 デイット構造3 2.1。 2.2に規則3を構造化してください。 デイット3 2.3のもののトップレベル。 国4の2.4。 機構、5 2.4 .1。 ディレクトリマネージャ、郵便局長、および長官5 2.4、.2 木6の2.4で徹底的な.3 本当の世界Organisational構造7 2.5。 多国籍の機構、7 2.5 .1。 aとしての多国籍企業は実体7 2.5に.2人を選抜します。 aとしての多国籍企業は同盟者8 2.5に.3を発射します。 緩く繋がっているデイット下位木9 2.5.4。 利点の概要と上のアプローチ9 3の損失。 様式10を3.1と命名します。 多成分系の相対的な分類名11 3.2。 命名11 3.3のための国家のガイドライン。 機構とOrganisationalユニット名11を3.4に挙げます。 人間のユーザ12 3.5を命名します。 アプリケーション実体13

RARE Working Group on Network Applications Support (WG-NAP)     [Page 1]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994

1994年5月にX.500のためのガイドラインを命名して、構造化するネットワーク応用サポート(WG-仮眠)[1ページ]RFC1617の上のまれな作業部会

    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

4. 4.1に値13を結果と考えてください。 基本的な属性構文13 4.1.1。 印刷可能である、4.1に.2に14を結んでください。 IA5ストリング--T.50 14 4.1.3。 テレテックスストリング--T.61 14 4.1.4。 ケースはストリング14 4.1に.5を無視します。 分類名14 4.2。 言語と音訳14 4.2、.1 英語以外の言語15 4.2、.2 音訳15 4.3。 コントロール15 4.4にアクセスしてください。 属性16 4.4に.1に選択されます。 パーソナルは4.4に.2に16を結果と考えます。 Organisational属性18 4.4.3。 ローカルは4.4に.4に19を結果と考えます。 その他は4.4に.5に20を結果と考えます。 MHS属性21 4.4.6。 郵便、4.4に.7に21を結果と考えます。 電子通信属性22 5。 雑録22 5.1。 別名22 5.2の図式の一貫性。 Organisationalユニット23 6。 参照23 7。 セキュリティ問題23 8。 作者のアドレス24 9。 付録--例のエントリー25

1. Introduction

1. 序論

   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.

このドキュメントのための対象とする訪問者は主にX.500ディレクトリサービスを使用しているデータ管理ソフトウェアです。 これらのガイドラインの助けでは、それらがモデル化したがっているディレクトリ情報Treeの部分と構造を定義するのは、より簡単であるはずです、例えば、ディレクトリにおける、彼らの機構の代理。 さらに、どのデータ要素を各種類のエントリーに格納したらよいかような決定は支持されるものとします。

   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.

主にディレクトリのホワイトのページ使用のこれらのガイドライン濃縮、今日の最も操作上の経験によるX.500アプリケーション、また、ディレクトリの他のアプリケーションに、それにもかかわらず、多くの推薦も有効です。

   As a pre-requisite to this document, it is assumed that the COSINE
   and Internet X.500 Schema is followed [1].

このドキュメントへの前提条件として、COSINEとインターネットX.500 Schemaが続かれていると思われます。[1]。

RARE Working Group on Network Applications Support (WG-NAP)     [Page 2]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994

1994年5月にX.500のためのガイドラインを命名して、構造化するネットワーク応用サポート(WG-仮眠)[2ページ]RFC1617の上のまれな作業部会

2. DIT Structure

2. デイット構造

   The majority of this document is concerned with DIT structure, naming
   and the usage of attributes for organisations, organisational units
   and personal entries.

このドキュメントの大部分が機構、organisationalユニット、および個人的なエントリーへの属性のDIT構造、命名、および用法に関係があります。

   This section briefly notes five other key issues.

このセクションは簡潔に他の主要な5冊に注意します。

2.1 Structure Rules

2.1 構造規則

   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.

DIT構造はX.521[2]のAnnex Bで提案されます、そして、ホワイトのページサービスのためのディレクトリPilotsがこれらのガイドラインに従うはずであるのは、お勧めです。 いくつかの簡単な制限が以下で説明されるように適用されるべきです。 それぞれのドキュメントで指定されたガイドラインに従うのはディレクトリがあるメールルーティングのようなディレクトリのさらなる用法かディレクトリにおける、ネットワーク情報の格納に、必要になるでしょう。

   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.

基本的なDIT構造へのわずかな例外の1つはそうであり、国際機関は木の根のすぐ下で格納されるでしょう。 多国籍の機構は、これらの機構の構成している部分を一緒にくくるのを助けるために概説されているのにもかかわらずの、seeAlsoなどの別名と属性の何らかの使用がある枠組みの中に格納されるでしょう。 さらに詳細にセクション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

2.2 デイットのトップレベル

   The following information will be present at the top level of the
   DIT:

以下の情報は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.

規格によると、RDNはISO3166国名略号です。 さらに、エントリーはRFC1274で指定されたfriendlyCountryName属性の適当な値を含むべきです。 この属性の使用はさらに詳細にセクション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

1994年5月にX.500のためのガイドラインを命名して、構造化するネットワーク応用サポート(WG-仮眠)[3ページ]RFC1617の上のまれな作業部会

      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.

そして、上国家、本当に、これはそのような機構の存在理由です。 そのような機構はほとんどすべてを望んでいます。政府である、または準政府になってください。 多国籍の機構は、1つ以上の国で作動する機構ですが、上国家ではありません。 この分類は生産販売が多くの国中で広げられる大きい営利団体を含んでいます。

      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.

国際機関はトップレベルで登録されるかもしれません。 多国籍の機構のためにこれをしないでしょう。 現在の、3つの機構が今までのところ、登録されます: Inmarsat、インターネット、および北大西洋条約機構。

   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

DSA情報

      Some information on DSAs may be needed at the top level.  This
      should be kept to a minimum.

DSAsの何らかの情報がトップレベルで必要であるかもしれません。 これは最小限に保たれるべきです。

   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

2.3 国

   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

国家の規格化本体はDITの国家の部分の構造のための国家のガイドラインを定義するでしょう。 その間、以下の単純構造は十分であるべきです。 国のエントリーは木の根のすぐ下に現れるでしょう。 国家の意味を持っている機構は彼らのそれぞれの国のエントリーのすぐ下にエントリーを持つべきです。 特定の場所で知られているだけであるより小さい機構は、州か同様の地理的な部門を代表しながら、場所エントリーの下に置かれるべきです。 個人的な人々のためのエントリーは場所エントリーで記載されるでしょう。 米国に発展する例のプランは仕事です。

RARE Working Group on Network Applications Support (WG-NAP)     [Page 4]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994

1994年5月にX.500のためのガイドラインを命名して、構造化するネットワーク応用サポート(WG-仮眠)[4ページ]RFC1617の上のまれな作業部会

   the North American Directory Forum [3]. Another example is the
   organisation of the X.500 namespace as standardized in Australia [4].

北米のディレクトリフォーラム[3]。 別の例はオーストラリア[4]で標準化されるようにX.500名前空間の機構です。

2.4 Organisations

2.4 機構

   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.

大きな組織はたぶんorganisationalユニットによって細分されて、人々のために一般名でエントリーの曖昧さの解消で助ける必要があるでしょう。 人々と役割のためのエントリーは機構かorganisationalユニットの下に格納されるでしょう。

   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.

機構の構造は時間がたつにつれてしばしばかなり変化しますが、目的はDITへの変化の数を最小とならせることであるべきです。 上司を改名して、部門登録にはすべての下位のエントリーのDNを変えるという効果があることに注意してください。 これはいくつかの理由のためのサービスに望ましくない影響力を持っています。 seeAlsoや、秘書やroleOccupantなどの別名エントリーとある属性か普通のエントリーが、他のエントリーとのリンクを維持するのにDNsを使用します。 これらの参照が片道である、唯一、そして、自動的にアップデートへのどんなサポートもエントリーにDNがいったん変えるとすべて参照をつけないディレクトリの標準の申し出。

2.4.1 Directory Manager, Postmaster & Secretary

2.4.1 ディレクトリマネージャ、郵便局長、および長官

   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.

メッセージングと同様です、あらゆるドメインが郵便局長住所を知っているところでは、X.500ディレクトリにおける各機構には2つのエントリーがあるのは、非常にお勧めです: 郵便局長とディレクトリマネージャ。 さらに、機構とそのユニット長官エントリーは記載されているべきです。 この指導が続かれていると、サービスに関する質問か問題に関して正しい接触を見つけるのが簡単であるので、ユーザは利益を得るでしょう。

   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

これらのエントリーは人々の分類名のこの役割担当のroleOccupant属性による含有での物のクラスorganizationalRoleを使用するべきです。 値

      CN=Directory Manager

CNはディレクトリマネージャと等しいです。

      CN=Postmaster

CNは郵便局長と等しいです。

      CN=Secretary

CNは長官と等しいです。

   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

1994年5月にX.500のためのガイドラインを命名して、構造化するネットワーク応用サポート(WG-仮眠)[5ページ]RFC1617の上のまれな作業部会

2.4.2 Depth of tree

2.4.2 木の深さ

   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.

ホワイトPagesのための広い推薦はDITができるだけ平坦であるべきであるということです。 平坦な木は、ディレクトリ名がたぶん長さとコンポーネント構造で比較的不足していて、紙の郵便の宛先といくらか同様になることを意味します。 深いDITは、長さが論争されて、ディレクトリがいくらか任意のコンポーネントの部品、それがそうである結果で命名するより自然でなく見えるのを含意するでしょう。 名前の選択におけるどんな不自然さもうまくいっている質問に影響します。

   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.

DITの深さの2つの決定因があると考えられるかもしれません: まず最初に、どれくらい遠くにDITの下側に、機構は置かれるか。 2番目、機構の中のDITの構造。

   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.

木の上側のレベルの構造は様々な登録局でやがて決定するでしょう、そして、パイロットは与えられた構造の中で働かなければならないでしょう。 しかしながら、様々なパイロットは構造がおそらくであることになっているこれらの構造を採用するために早く動かすものにおいて認識力があるのは、重要です。