RFC1837 日本語訳

Network Working Group                                           S. Kille
Request for Comments: 1837                              ISODE Consortium
Category: Experimental                                       August 1995

Killeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1837年のISODE共同体カテゴリ: 実験的な1995年8月

        Representing Tables and Subtrees in the X.500 Directory

X.500ディレクトリにおけるテーブルと下位木を表します。

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This document defines techniques for representing two types of
   information mapping in the OSI Directory [1].

このドキュメントはOSIディレクトリ[1]で2つのタイプに関する情報マッピングを表すためのテクニックを定義します。

   1.  Mapping from a key to a value (or set of values), as might be
       done in a table lookup.

1. 値のキー(または、値のセット)から、索表でするかもしれないように、写像します。

   2.  Mapping from a distinguished name to an associated value (or
       values), where the values are not defined by the owner of the
       entry.  This is achieved by use of a directory subtree.

2. 分類名から関連値(または、値)まで写像します。そこでは、値がエントリーの所有者によって定義されません。 これはディレクトリ下位木の使用で達成されます。

   These techniques were developed for supporting MHS use of Directory
   [2], but are specified separately as they have more general
   applicability.

これらのテクニックは、MHSがディレクトリ[2]の使用であるとサポートするために開発されましたが、彼らにより一般的な適用性があるとき、別々に指定されます。

1.  Representing Flat Tables

1. 平坦なテーブルを表します。

   Before considering specific function, a general purpose technique for
   representing tables in the directory is introduced.  The schema for
   this is given in Figure 1.

具体的な機能を考える前に、ディレクトリにテーブルを表すための汎用のテクニックを導入します。 図1でこれのための図式を与えます。

   A table can be considered as an unordered set of key to (single or
   multiple) value mappings, where the key cannot be represented as a
   global name.  There are four reasons why this may occur:

(単一であるか複数)の値のマッピングへの順不同のセットのキーであるとテーブルをみなすことができます。(そこでは、グローバル名としてキーを表すことができません)。 これが起こるかもしれない4つの理由があります:

   1.  The object does not have a natural global name.

1. オブジェクトには、自然なグローバル名がありません。

   2.  The object can only be named effectively in the context of being
       a key to a binding.  In this case, the object will be given a
       natural global name by the table.

2. 結合のキーであることの文脈で有効にオブジェクトを命名できるだけです。 この場合、テーブルによる自然なグローバル名をオブジェクトに与えるでしょう。

Kille                         Experimental                      [Page 1]

RFC 1837                 Representing Subtrees               August 1995

1995年8月に下位木を表すKilleの実験的な[1ページ]RFC1837

   3.  The object has a global name, and the table is being used to
       associate parameters with this object, in cases where they cannot
       be placed in the objects global entry.  Reasons why they might
       not be so placed include:

3. オブジェクトには、グローバル名があります、そして、テーブルはこのオブジェクトにパラメタを関連づけるのに使用されています、それらをオブジェクトに置くことができない場合で。グローバルなエントリー。 それらがそのように置かれないかもしれない理由は:

        o  The object does not have a directory entry

o オブジェクトには、ディレクトリエントリがありません。

        o  There is no authority to place the parameters in the global
           entry

o グローバルなエントリーにパラメタを置く権威が全くありません。

        o  The parameters are not global --- they only make sense in the
           context of the table.

o パラメタはグローバルではありません。--- 彼らはテーブルの文脈で理解できるだけです。

   4.  It is desirable to group information together as a performance
       optimisation, so that the block of information may be widely
       replicated.

4. 性能最適化として情報を分類するのは望ましいです、広く情報のブロックを模写できるように。

   A table is represented as a single level subtree.  The root of the
   subtree is an entry of object class Table.  This is named with a
   common name descriptive of the table.  The table will be located
   somewhere appropriate to its function.  If a table is private to an
   MTA, it will be below the MTA's entry.  If it is shared by MTA's in
   an organisation, it will be located under the organisation.

テーブルはただ一つの平らな下位木として表されます。 下位木の根本はオブジェクトのクラスTableのエントリーです。 これはテーブルで描写的である一般名で命名されます。 テーブルはどこかに機能に適切な状態で位置するでしょう。 テーブルがMTAに個人的であるなら、MTAのエントリーの下にそれはあるでしょう。 機構でMTAのものによって共有されると、それは機構で見つけられるでしょう。

   The generic table entry contains only a description.  All instances
   will be subclassed, and the subclass will define the naming
   attribute.  Two subclasses are defined:

ジェネリックテーブル項目は記述だけを含んでいます。 すべてのインスタンスが副分類されるでしょう、そして、サブクラスは命名属性を定義するでしょう。 2つのサブクラスが定義されます:

-----------------------------------------------------------------------
table OBJECT-CLASS ::= {
    SUBCLASS OF {top}
    MUST CONTAIN {commonName}
    MAY CONTAIN {manager}
    ID oc-table}

----------------------------------------------------------------------- OBJECT-CLASSをテーブルの上に置いてください:、:= SUBCLASS OFがMUST CONTAIN commonNameを上回っている、MAY CONTAINマネージャIDはocにテーブルの上に置きます。

tableEntry OBJECT-CLASS ::= {
    SUBCLASS OF {top}
    MAY CONTAIN {description}                                       10
    ID oc-table-entry}

tableEntryは以下をオブジェクトで分類します:= SUBCLASS OFはocエントリーをテーブルの上に置いてMAY CONTAIN記述10IDを付けます。

textTableEntry OBJECT-CLASS ::= {
    SUBCLASS OF {tableEntry}
    MUST CONTAIN {textTableKey}
    MAY CONTAIN {textTableValue}
    ID oc-text-table-entry}

textTableEntryは以下をオブジェクトで分類します:= SUBCLASS OF tableEntry、MUST CONTAIN textTableKey、MAY CONTAIN textTableValue、ID ocテキストテーブル項目

textTableKey ATTRIBUTE ::= {

textTableKeyは以下を結果と考えます:= {

Kille                         Experimental                      [Page 2]

RFC 1837                 Representing Subtrees               August 1995

1995年8月に下位木を表すKilleの実験的な[2ページ]RFC1837

    SUBTYPE OF name                                                 20
    WITH SYNTAX DirectoryString {ub-name}
    ID at-text-table-key}

SUBTYPE OFは20WITH SYNTAX DirectoryString ub-名をIDにテキストテーブルキーであることで挙げます。

textTableValue ATTRIBUTE ::= {
    SUBTYPE OF name
    WITH SYNTAX  DirectoryString {ub-description}
    ID at-text-table-value}

textTableValueは以下を結果と考えます:= SUBTYPE OFはWITH SYNTAX DirectoryString ub-記述をIDとテキストテーブル価値で命名します。

distinguishedNameTableEntry OBJECT-CLASS ::= {
    SUBCLASS OF {tableEntry}                                        30
    MUST CONTAIN {distinguishedNameTableKey}
    ID oc-distinguished-name-table-entry}

distinguishedNameTableEntryは以下をオブジェクトで分類します:= SUBCLASS OF tableEntry、30MUST CONTAIN distinguishedNameTableKey、IDのocの顕著な名前テーブルエントリー

distinguishedNameTableKey ATTRIBUTE ::= {
    SUBTYPE OF distinguishedName
    ID at-distinguished-name-table-key}

distinguishedNameTableKeyは以下を結果と考えます:= キーが顕著な名前でテーブル用のSUBTYPE OF distinguishedName ID

                     Figure 1:  Representing Tables

図1: テーブルを表します。

1.  TextEntry, which define table entries with text keys, which may
    have single or multiple values of any type.  An attribute is
    defined to allow a text value, to support the frequent text key to
    text value mapping.  Additional values may be defined.

1. TextEntry。(そのTextEntryはテキストキーでテーブル項目を定義します)。(キーにはどんなタイプの単一であるか複数の値もあるかもしれません)。 属性は、テキスト値を許容して、テキスト値のマッピングに主要な頻繁なテキストをサポートするために定義されます。 加算値は定義されるかもしれません。

2.  DistinguishedNameEntry.  This is used for associating information
    with globally defined objects.  This approach should be used where
    the number of objects in the table is small or very sparsely
    spread over the DIT. In other cases where there are many objects
    or the objects are tightly clustered in the DIT, the subtree
    approach defined in Section 2 will be preferable.  No value
    attributes are defined for this type of entry.  An application of
    this will make appropriate subtyping to define the needed values.

2. DistinguishedNameEntry。 これは、グローバルに定義されたオブジェクトに情報を関連づけるのに使用されます。 このアプローチは、テーブルのオブジェクトの数が少ないところで使用されるべきであるか、またはDITに非常にまばらに広がるべきです。 多くのオブジェクトがあるか、またはオブジェクトがDITにしっかりクラスタリングしている他の場合では、セクション2で定義された下位木アプローチは望ましくなるでしょう。 値の属性は全くこのタイプのエントリーと定義されません。 このアプリケーションは、必要な値を定義するために適切な副タイプを作るでしょう。

This is best illustrated by example.  Consider the MTA:

例でこれを例証するのは最も良いです。 MTAを考えてください:

CN=Bells, OU=Computer Science,
O=University College London, C=GB

CNはベル、OU=コンピュータサイエンスユニバーシティ・カレッジO=ロンドン、C=GBと等しいです。

Suppose that the MTA needs a table mapping from private keys to fully
qualified domain names (this example is fictitious).  The table might
be named as:

MTAが秘密鍵から完全修飾ドメイン名までテーブルマッピングを必要とすると仮定してください(この例は架空です)。 テーブルは以下として命名されるかもしれません。

CN=domain-nicknames,
CN=Bells, OU=Computer Science,
O=University College London, C=GB

CN=ドメインあだ名(CN=ベル、OU=コンピュータサイエンスユニバーシティ・カレッジO=ロンドン、C)はGBと等しいです。

Kille                         Experimental                      [Page 3]

RFC 1837                 Representing Subtrees               August 1995

1995年8月に下位木を表すKilleの実験的な[3ページ]RFC1837

To represent a mapping in this table from "euclid" to
"bloomsbury.ac.uk", the entry:

これにマッピングを表すために、"euclid"から"bloomsbury.ac.uk"、エントリーまで以下をテーブルの上に置いてください。

CN=euclid, CN=domain-nicknames,
CN=Bells, OU=Computer Science,
O=University College London, C=GB

CN=euclid、ユニバーシティ・カレッジCN=ドメインあだ名、CN=ベルコンピュータサイエンス、OU=O=ロンドンCはGBと等しいです。

will contain the attribute:

属性を含むでしょう:

TextTableValue=bloomsbury.ac.uk

TextTableValue=bloomsbury.ac.uk

A second example, showing the use of DistinguishedNameEntry is now
given.  Consider again the MTA:

2番目の例であり、現在、DistinguishedNameEntryの使用を示しているのを与えます。 もう一度MTAを考えてください:

CN=Bells, OU=Computer Science,
O=University College London, C=GB

CNはベル、OU=コンピュータサイエンスユニバーシティ・カレッジO=ロンドン、C=GBと等しいです。

Suppose that the MTA needs a table mapping from MTA Name to bilateral
agreement information of that MTA. The table might be named as:

MTAがMTA NameからそのMTAの二国間条約情報までテーブルマッピングを必要とすると仮定してください。 テーブルは以下として命名されるかもしれません。

CN=MTA Bilateral Agreements,
CN=Bells, OU=Computer Science,
O=University College London, C=GB

CN=MTA二国間条約(CN=ベル、OU=コンピュータサイエンスユニバーシティ・カレッジO=ロンドン、C)はGBと等しいです。

To represent information on the MTA which has the Distinguished Name:

Distinguished Nameを持っているMTAの情報を表すために:

CN=Q3T21, ADMD=Gold 400, C=GB

金400、CN=Q3T21、ADMD=CはGBと等しいです。

   There would be an entry in this table with the Relative Distinguished
   Name of the table entry being the Distinguished Name of the MTA being
   referred to.  The MTA Bilateral information would be an attribute in
   this entry.  Using a non-standard notation, the Distinguished Name of
   the table entry is:

エントリーが言及されるMTAのDistinguished Nameであるテーブル項目のRelative Distinguished Nameでのこのテーブルにあるでしょう。 MTA Bilateral情報はこのエントリーで属性でしょう。 標準的でない記法を使用して、テーブル項目のDistinguished Nameは以下の通りです。

   DistinguishedNameTableValue=<CN=Q3T21, ADMD=Gold 400, C=GB>,
   CN=MTA Bilateral Agreements,
   CN=Bells, OU=Computer Science,
   O=University College London, C=GB

DistinguishedNameTableValueは<CN=Q3T21と等しく、ADMDは金400と等しく、C=GB>、ユニバーシティ・カレッジCN=MTA二国間条約、CN=ベルコンピュータサイエンス、OU=O=ロンドンCはGBと等しいです。

Kille                         Experimental                      [Page 4]

RFC 1837                 Representing Subtrees               August 1995

1995年8月に下位木を表すKilleの実験的な[4ページ]RFC1837

2.  Representing Subtrees

2. 下位木を表します。

   A subtree is similar to a table, except that the keys are constructed
   as a distinguished name hierarchy relative to the location of the
   subtree in the DIT. The subtree effectively starts a private "root",
   and has distinguished names relative to this root.  Typically, this
   approach is used to associate local information with global objects.
   The schema used is defined in Figure 2.  Functionally, this is
   equivalent to a table with distinguished name keys.  The table
   approach is best when the tree is very sparse.  This approach is
   better for subtrees which are more populated.

下位木はテーブルと同様です、キーが分類名階層構造としてDITの下位木の位置に比例して組み立てられるのを除いて。 下位木は、事実上、個人的な「根」を始めて、この根に比例して分類名を持っています。 通常、このアプローチは、ローカルの情報をグローバルなオブジェクトに関連づけるのに使用されます。 使用される図式は図2で定義されます。 これは分類名キーがあるテーブルに機能上、同等です。 木が非常にまばらであるときに、テーブルアプローチは最も良いです。 さらに居住される下位木には、このアプローチは、より良いです。

   The subtree object class defines the root for a subtree in an
   analogous means to the table.  Information within the subtree will
   generally be defined in the same way as for the global object, and so

下位木オブジェクトのクラスは下位木のために類似の手段で根をテーブルと定義します。 一般に、同様に、下位木の中の情報はグローバルなオブジェクト、およびそうのために定義づけられるでしょう。

   ---------------------------------------------------------------------
   subtree OBJECT-CLASS ::= {
       SUBCLASS OF {top}
       MUST CONTAIN {commonName}
       MAY CONTAIN {manager}
       ID oc-subtree}

--------------------------------------------------------------------- 下位木OBJECT-CLASS:、:= SUBCLASS OFがMUST CONTAIN commonNameを上回っている、MAY CONTAINマネージャ、ID oc-下位木

                     Figure 2:  Representing Subtrees

図2: 下位木を表します。

   no specific object classes for subtree entries are needed.

下位木エントリーへのどんな特定のオブジェクトのクラスも必要ではありません。

   For example consider University College London.

例えば、ユニバーシティ・カレッジロンドンを考えてください。

   O=University College London, C=GB

○ = ユニバーシティ・カレッジロンドン、CはGBと等しいです。

   Suppose that the UCL needs a private subtree, with interesting
   information about directory objects.  The table might be named as:

UCLがディレクトリオブジェクトに関する興味ある情報がある個人的な下位木を必要とすると仮定してください。 テーブルは以下として命名されるかもしれません。

   CN=private subtree,
   O=University College London, C=GB

CNは個人的な下位木と等しく、Oはユニバーシティ・カレッジロンドンと等しく、CはGBと等しいです。

   UCL specific information on Inria might be stored in the entry:

Inriaに関するUCL特殊情報はエントリーに保存されるかもしれません:

   O=Inria, C=FR,
   CN=private subtree,
   O=University College London, C=GB

O=Inria、C=FR、ユニバーシティ・カレッジ個人的な下位木、CN=O=ロンドンCはGBと等しいです。

   Practical examples of this mapping are given in [2].

[2]でこのマッピングに関する実例を与えます。

Kille                         Experimental                      [Page 5]

RFC 1837                 Representing Subtrees               August 1995

1995年8月に下位木を表すKilleの実験的な[5ページ]RFC1837

3.  Acknowledgements

3. 承認

   Acknowledgements for work on this document are given in [2].

[2]でこのドキュメントへの作業のための承認を与えます。

References

参照

   [1] The Directory --- overview of concepts, models and services,
       1993. CCITT X.500 Series Recommendations.

[1] ディレクトリ--- 概念の、そして、モデルの、そして、サービスの概要、1993。 CCITT X.500シリーズ勧告。

   [2] Kille, S., "MHS use of the X.500 Directory to Support MHS
       Routing", RFC 1801, ISODE Consortium, June 1995.

[2]Kille、S.、「Support MHSルート設定へのX.500ディレクトリのMHS使用」、RFC1801、ISODE Consortium、1995年6月。

4.  Security Considerations

4. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

5.  Author's Address

5. 作者のアドレス

   Steve Kille
   ISODE Consortium
   The Dome
   The Square
   Richmond
   TW9 1DT
   England

スティーブKille ISODE共同体のドームの正方形のリッチモンドTW9 1DTイギリス

   Phone:  +44-81-332-9091
   Internet EMail:  S.Kille@ISODE.COM
   X.400:  I=S; S=Kille; O=ISODE Consortium; P=ISODE;
   A=Mailnet; C=FI;
   DN: CN=Steve Kille,
   O=ISODE Consortium, C=GB
   UFN: S. Kille, ISODE Consortium, GB

以下に電話をしてください。 +44-81-332-9091 インターネットメール: S.Kille@ISODE.COM X.400: I=S。 S=Kille。 O=ISODE共同体。 P=ISODE。 A=Mailnet。 CはFIと等しいです。 DN: CNはスティーブKille、O=ISODE共同体と等しく、CはGB UFNと等しいです: S。 Kille、ISODE共同体、GB

Kille                         Experimental                      [Page 6]

RFC 1837                 Representing Subtrees               August 1995

1995年8月に下位木を表すKilleの実験的な[6ページ]RFC1837

A.  Object Identifier Assignment

A。 オブジェクト識別子課題

-----------------------------------------------------------------------
mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
          private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}

----------------------------------------------------------------------- mhs-ds OBJECT IDENTIFIER:、:= 個人的なiso(1) org(3) dod(6)の企業(1)isode-共同体(453)mhs-dsインターネット(1)(4)(7)

tables OBJECT IDENTIFIER ::= {mhs-ds 1}

テーブルOBJECT IDENTIFIER:、:= mhs-ds1

oc OBJECT IDENTIFIER ::= {tables 1}
at OBJECT IDENTIFIER ::= {tables 2}

oc OBJECT IDENTIFIER:、:= オブジェクト識別子におけるテーブル1:、:= テーブル2

oc-subtree OBJECT IDENTIFIER ::= {oc 1}
oc-table OBJECT IDENTIFIER ::= {oc 2}                               10
oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
oc-distinguished-name-table-entry  OBJECT IDENTIFIER ::= {oc 5}

oc-下位木OBJECT IDENTIFIER:、:= oc1oc-テーブルOBJECT IDENTIFIER:、:= oc2 10oc-テーブル項目OBJECT IDENTIFIER:、:= oc3ocテキストテーブル項目OBJECT IDENTIFIER:、:= ocが名前テーブルエントリーを区別しているoc4OBJECT IDENTIFIER:、:= oc5

at-text-table-key OBJECT IDENTIFIER ::= {at 1}
at-text-table-value OBJECT IDENTIFIER ::= {at 2}
at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}

キーがテキストでテーブル用のOBJECT IDENTIFIER:、:= 1時にテキストで値を見送ってください、OBJECT IDENTIFIER:、:= 2時に顕著な名義のテーブルのキーのOBJECT IDENTIFIER:、:= 3

                 Figure 3:  Object Identifier Assignment

図3: オブジェクト識別子課題

Kille                         Experimental                      [Page 7]

Kille実験的です。[7ページ]