RFC1276 日本語訳
1276 Replication and Distributed Operations extensions to provide anInternet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT=33731, PS=217170 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S.E. Hardcastle-Kille
Requests for Comments 1276 University College London
November 1991
ネットワークワーキンググループ東南Hardcastle-Killeは1991年11月にコメント1276のためにユニバーシティ・カレッジロンドンを要求します。
Replication and Distributed Operations extensions
to provide an Internet Directory using X.500
X.500を使用することでインターネットディレクトリを提供する模写とDistributed Operations拡張子
Status of this Memo
This RFC specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the ``IAB
Official Protocol Standards'' for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
このMemo This RFCの状態は、IAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
Some requirements on extensions to X.500 are described in the
RFC[HK91b], in order to build an Internet Directory using
X.500(1988). 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 RFCwill be obsoleted at this
point.
X.500への拡大に関する抽象的なSome要件はRFC[HK91b]で説明されます、X.500(1988)を使用することでインターネットディレクトリを築き上げるために。 このドキュメントは提起された問題への1セットの解決を指定します。 これらの解決策はQUIPU実現のためにして、多くのディレクトリのパイロットで有効になるように示すいくらかの仕事に基づいています。 デファクトスタンダードを記録することによって、実物大のパイロットに向かって飛躍的進歩を作ることができます。 これらの手順はINTERIMアプローチです。 欠乏は管理可能性とスケーラビリティで知られています。 適切な規格が利用可能であるときに、標準のアプローチへの変遷は計画されています。 このRFCwill、ここに、時代遅れにされてください。
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
Contents
コンテンツ
1 Approach 2
1 アプローチ2
2 Extensions to Distributed Operations 3
分配された操作3への2つの拡大
3 Alternative DSAs 4
3 代替のDSAs4
4 Data Model 5
4 データモデル5
5 DSA Naming 6
5 DSA命名6
6 Knowledge Representation 6
6 知識表現6
7 Replication Protocol 9
7 模写プロトコル9
8 New Application Context 12
8 新しいアプリケーション関係12
9 Policy on Replication Procedures 12
模写手順12に関する9方針
10 Use of the Directory by Applications 12
10 ディレクトリのアプリケーション12による使用
11 Migration and Scaling 12
11 移動とスケーリング12
12 Security Considerations 13
12 セキュリティ問題13
13 Author's Address 13
13作者のアドレス13
A ASN.1 Summary and Object Identifier Allocation 14
ASN.1概要と物の識別子配分14
List of Figures
数字のリスト
1 Knowledge Attributes . . . . . . . . 8
1 知識属性. . . . . . . . 8
2 Replication Protocol . . . . . . . . 10
3 Summary of the ASN.1 . . . . . . . . 17
ASN.1の2模写プロトコル. . . . . . . . 10 3概要… 17
Hardcastle-Kille Page 1
Hardcastle-Kille1ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
1 Approach
1 アプローチ
There are a number of non-negotiable requirements which must be met before a directory can be deployed on the Internet [HK91b]. 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:
インターネット[HK91b]でディレクトリを配備できる前に満たさなければならない多くの譲渡禁止の必要条件があります。 これらの問題は規格アリーナで取り組まれていますが、現在、どんな安定した解決策もありません。 1つのアプローチは規格を妨害するのを試みるだろうことです。 これにおける困難は以下の通りでしょう。
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.
o 一貫性を持っているインタセプトを定義するのは無器用でしょう、そして、努力はたぶん規格に取り組むのにささげられるほうがよいでしょう。 そのようなインタセプトを定義できたのは明確になりさえしません。
o The target is moving, and it is always tempting to track it, thus
causing more delay.
o 目標は動きます、そして、それはそれを追跡するのにいつも誘惑していて、その結果、より多くの遅れを引き起こします。
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.
o このアプローチにかかわる遅れがあるでしょう。 多くが、それを実行しないのを選ぶのが、最終的な規格のタイミングの十分急速な始めの役に立つことにおけるあまりに遅いのと、近くにそれがあるでしょう。
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:
したがって、私たちは、簡潔な解決法を取るのを選びます。 これは、完全なX.500アプローチより非常に簡単であり、運用経験に基づいています。 このアプローチの利点は以下の通りです。
o It is proven in operation. This RFCis simply documenting what is
being done already.
o それは稼働中であり立証されます。 単に既に行われていることを記録するこのRFCis。
o There will be a minimum of delay in starting to use the approach.
o アプローチを使用し始めることについて最小遅れるでしょう。
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
implementation, as it is less effort, and can be further ahead of
the standard.
o アプローチが、より簡単であるので、実現の費用ははるかに少ないです。 したがって、実現の一助となるのははるかに魅力的になるでしょう、それが、より少ない努力であり、規格のさらに前に、あることができるとき。
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 RFCwill be obsoleted at this point.
これらの手順はINTERIMアプローチです。 欠乏は管理可能性とスケーラビリティで知られています。 適切な規格が利用可能であるときに、標準のアプローチへの変遷は計画されています。 このRFCwill、ここに、時代遅れにされてください。
Hardcastle-Kille Page 2
Hardcastle-Kille2ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
2 Extensions to Distributed Operations
分配された操作への2つの拡大
The distributed operations of X.500 assume that all DUAs and DSAs are fully interconnected with a global network service. For the Internet Pilot, this assumption is invalid. DSAs may be operated over TCP/IP, TP4/CLNS, or TP0/CONS. The extension to distributed operations to support this situation is straightforward. We define the term community as an environment where direct (network) communication is possible. Communities may be separated because they operate different protocols, or because of lack of physical connectivity. Example communities are the DARPA/NSF Internet, and the Janet private X.25 network. A network entity in a community is addressed by its Network Address. If two network entities are in the same community, they can by definition communicate. A community is identified by a set of network address prefixes. For the approach to be useful, this set should be small (typically 1). For TCP/IP Networks, and X.25 Networks not providing CONS, the approach is described in [HK91a] allows for communities to be defined for the networks of operational interest.
X.500の分配された操作は、すべてのDUAsとDSAsが世界的なネットワークサービスで完全にインタコネクトされると仮定します。 インターネットPilotにおいて、この仮定は無効です。 DSAsはTCP/IP、TP4/CLNS、またはTP0/コンズの上で操作されるかもしれません。 この状況を支持する分配された操作への拡大は簡単です。 私たちはダイレクト(ネットワーク)コミュニケーションが可能である環境と共同体という用語を定義します。 共同体はそれらが異なったプロトコルを操作するためか物理的な接続性の不足ので切り離されるかもしれません。 例の共同体は、DARPA/NSFインターネットと、個人的なX.25がネットワークでつなぐジャネットです。 共同体のネットワーク実体はNetwork Addressによって記述されます。 2つのネットワーク実体が同じ共同体にあるなら、それらは定義上交信できます。 共同体は1セットのネットワーク・アドレス接頭語によって特定されます。 アプローチが役に立つように、このセットは小さいはずです(通常1)。 Networks、およびコンズを提供しないX.25 Networks、アプローチが説明されるTCP/IPに関しては、[HK91a]は、共同体が操作上の関心のネットワークのために定義されるのを許容します。
This model can be used to determine whether a pair of application entities can communicate. For each entity, determine the presentation address (typically by directory lookup). Each network address in the presentation address will have a single associated community. The set of communities to which each application entity belongs can thus be determined. If the two application entities have a common community, then they can communicate directly. Two extensions to the standard distributed operations are needed.
1組のアプリケーション実体が交信できるかどうか決定するのにこのモデルを使用できます。 各実体には、プレゼンテーションアドレス(通常ディレクトリルックアップによる)を決定してください。 プレゼンテーションアドレスの各ネットワーク・アドレスには、単一の関連共同体があるでしょう。 その結果、それぞれのアプリケーション実体が属する共同体のセットは決定できます。 2つのアプリケーション実体に一般的な共同体があるなら、それらは直接伝達できます。 標準の分配された操作への2つの拡大が必要です。
1. Consider a DSA (the local DSA) which is contacted by either a DUA
or DSA (the calling entity) to resolve a query. The local DSA
determines that the query must be progressed by another DSA (the
referred-to DSA). The DSA will make a chain/referral choice. If
chaining is prohibited by service control, a referral will be
passed back. Otherwise, if the local DSA prefers to chain (e.g.,
for policy reasons) it will then chain. The remaining situation
is that the local DSA prefers to give a referral. It shall only
do so if it believes that the calling entity can directly connect
to the referred-to DSA. If the calling entity is a DUA, it should
be assumed to belong only to the community of the called network
address. If the calling entity is a DSA, its communities should
be determined by lookup of the DSA's presentation address in the
directory. The communities of the referred-to DSA can be
1. DSAが質問を決議するためにDUAかDSA(呼ぶ実体)のどちらかによって連絡される(地方のDSA)であると考えてください。 地方のDSAは、別のDSA(参照されたDSA)が質問を進行しなければならないことを決定します。 DSAはチェーン/紹介選択をするでしょう。 推論がサービス制御で禁止されると、紹介は戻されるでしょう。 さもなければ、そして、地方のDSAが、鎖を作るのを(例えば、方針理由で)好むと、それは鎖を作るでしょう。 残っている状況は地方のDSAが、紹介を与えるのを好むということです。 呼ぶ実体が直接参照されたDSAに接続できるのが信じている場合にだけ、それはそうするものとします。 呼ぶ実体がDUAであるなら、呼ばれたネットワーク・アドレスの共同体だけに属すと思われるべきです。 呼ぶ実体がDSAであるなら、共同体はディレクトリのDSAのプレゼンテーションアドレスのルックアップで決定するべきです。 参照されたDSAの共同体はそうであることができます。
Hardcastle-Kille Page 3
Hardcastle-Kille3ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
determined from its presentation address, which will either be
present in the reference or can be looked up in the directory. If
the calling entity and the referred-to DSA do not have a common
community, then chaining shall be used. Otherwise, a referral may
be passed back to the calling entity.
プレゼンテーションアドレスから、断固としています。(それを参照に存在するか、またはディレクトリで調べることができます)。 呼んでいる実体と参照されたDSAに一般的な共同体がないなら、推論は使用されるものとします。 さもなければ、紹介は呼ぶ実体に戻されるかもしれません。
2. Consider that a DSA (or DUA), termed here the local entity is
following a referral (to a referred-to DSA). In some cases, the
local entity and referred-to DSA will not be able to communicate
directly (i.e., not have a common community). There are two
approaches to solve this:
2. DSA(または、DUA)であり、ここに呼ばれて、ローカル要素が紹介(言及しているDSAへの)に続いていると考えてください。 いくつかの場合、ローカル要素と言及しているDSAは直接伝達できないでしょう(すなわち、一般的な共同体を持っていません)。 これを解決するために、2つのアプローチがあります:
(a) Pass the query to a DSA it would use to resolve a query for
the entry one level higher in the DIT. This will work,
provided that this DSA follows this specification. This
default mechanism will work without additional configuration.
(a) 質問をDSAに通過してください。それはエントリー1レベルに決心に質問をDITで、より高く使用するでしょう。 このDSAがこの仕様に従うと、これは働くでしょう。 このデフォルトメカニズムは追加構成なしで動作するでしょう。
(b) Use a ``relay DSA'' to access the community. A relay DSA is
one which can chain the query on to the remote community. The
relay DSA must belong to both the remote community and to at
least one community to which the local entity belongs. The
choice of relay DSA for a given community will be manually
configured by a DSA manager to enable access to a community to
which there is not direct connectivity. Typically this will
be used where the default DSA is a poor choice (e.g., because
relaying is not authorised through this DSA).
(b) 「リレーDSA」を使用して、共同体にアクセスしてください。 リレーDSAは遠く離れた共同体に質問をチェーニングできるものです。 リレーDSAは遠く離れた共同体とローカル要素が属する少なくとも1つの共同体への両方に属しなければなりません。 与えられた共同体へのリレーDSAの選択は、ダイレクト接続性がない共同体へのアクセスを可能にするためにDSAマネージャによって手動で構成されるでしょう。 通常、これはデフォルトDSAが不十分な選択(例えば、リレーがこのDSAを通して認可されないので)であるところで使用されるでしょう。
A DSA conforming to this specification shall follow these
procedures. A DUA may also follow these procedures, and this will
give improvements in some circumstances (i.e., the ability to
resolve certain queries without use of chaining). However, this
specification does not place requirements on DUAs.
この仕様に従うDSAはこれらの手順に従うものとします。 また、DUAはこれらの手順に従うかもしれません、そして、これはいくつかの事情(すなわち、推論の使用なしである質問を決議する能力)における改良を与えるでしょう。 しかしながら、この仕様は要件をDUAsに置きません。
3 Alternative DSAs
3 代替の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. This relies on the fact that there may only be a single subordinate reference or cross reference.
データの奴隷コピーの上で知らせる必要があります。 これは標準プロトコルを使用しますが、意味論を変更し終わることができます。 これはただ一つの下位参照か相互参照があるだけであるかもしれないという事実を当てにします。
If there is a need to include references to master and slave data (EDB copies) in a referral, then this should be done in a referral by specifying a subordinate reference with multiple values. This cannot
紹介に習得する参照と奴隷データ(EDBコピー)を含む必要があれば、紹介で複数の値で下位参照を指定することによって、これをするべきです。 これはそうすることができません。
Hardcastle-Kille Page 4
Hardcastle-Kille4ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
be a standard subordinate reference, which would only have a single value. Therefore, this usage does not conflict with standard references. The first reference is the master copy, and subsequent references are slave copies.
標準の下位参照になってください。(その下位参照には、ただ一つの値があるだけでしょう)。 したがって、この用法は標準の参照と衝突しません。 最初の参照はマスターコピーです、そして、その後の参照は奴隷コピーです。
4 Data Model
4データモデル
The X.500 data model takes the unit of mastering data as the entry. A DSA may hold an arbitrary collection of entries. We restrict this model so that for the replication protocol defined in this specification the base unit of replication (shadowing) is the complete set of immediate subordinate entries of a given entry, termed an Entry Data Block (EDB). An EDB is named by its parent entry. It contains the relative distinguished names of all of the children of the entry, and each of the child entries. For each entry, this comprises all attributes of the entry, the relative distinguished name, and knowledge information associated with the entry. If a DSA holds (non-cached) information on an entry, it will hold information on all of its siblings. One DSA will hold a master EDB. This will contain two types of entry:
X.500データモデルはエントリーとして習得データのユニットをみなします。 DSAはエントリーの任意の収集を保持するかもしれません。 Entry Data Block(EDB)は、私たちがこのモデルを制限するので模写(シャドウイング)のベース単位がこの仕様に基づき定義された模写プロトコルのための与えられたエントリーの完全な即座の下位のエントリーであると呼びました。 EDBは親エントリーで命名されます。 それはエントリー、およびそれぞれの子供エントリーの子供のすべての相対的な分類名を含んでいます。 各エントリーに、これはエントリー、相対的な分類名、およびエントリーに関連している知識情報のすべての属性を包括します。 DSAがエントリーの(非キャッシュされる)の情報を保持すると、それは兄弟のすべての情報を保持するでしょう。 1DSAがマスターEDBを持つでしょう。 これは2つのタイプのエントリーを含むでしょう:
1. Entries for which this DSA is the master.
1. このDSAがマスターであるエントリー。
2. Slave copies of entries which are mastered in another DSA,
indicated by a subordinate reference. This copy must be
maintained automatically by the DSA holding the master EDB.
2. 下位参照で示された別のDSAで習得されるエントリーの奴隷コピー。 マスターEDBを持っているDSAは自動的にこのコピーを維持しなければなりません。
Thus the master EDB contains a mixture of master entries, and entries which are mastered elsewhere and shadowed by the DSA holding the master EDB on an entry by entry basis. Other DSAs may hold slave copies of this EDB (slave EDBs), which are replicated in their entirity directly or indirectly from the master EDB. This approach has the following advantages.
したがって、マスターEDBはエントリーのときにエントリー基礎でマスターEDBを持っているDSAによってほかの場所で習得されて、影でおおわれるマスターエントリー、およびエントリーの混合物を含んでいます。 他のDSAsはこのEDB(奴隷EDBs)の奴隷コピーを持っているかもしれません。(EDBは彼らのentirityで直接か間接的なマスターEDBから模写されます)。 このアプローチには、以下の利点があります。
o Name resolution is simplified, and performance improved.
o 名前解決は簡易型です、そして、性能は向上しました。
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
might require to access very many DSAs and be prohibitively
expensive.
o 単一の平らな探すのとリストは、望ましい市場成果を持って、実行するために簡単です。 洗練された模写なしで規格を適用するより一般的な場合では、これらの操作は、非常に多くのDSAsをアクセスに必要として、法外に高価であるかもしれません。
Hardcastle-Kille Page 5
Hardcastle-Kille5ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
5 DSA Naming
5 DSA命名
All DSAs must be named in the DIT, and the master definition of the presentation address stored in this entry. X.500 (including some of the extension work) implies that the presentation address information is extensively replicated (manually). The management overhead implied by this is not acceptable. Care must be taken to prevent deadlock in determining a DSAs address. This is solved by:
プレゼンテーションアドレスの定義がこのエントリーに格納したDIT、およびマスターですべてのDSAsを命名しなければなりません。 X.500(拡充工事のいくつかを含んでいる)は、プレゼンテーションアドレス情報が手広く(手動で)模写されるのを含意します。 これによって含意された管理オーバーヘッドは許容できません。 DSAsアドレスを決定する際に行き詰まりを防ぐために注意しなければなりません。 これは以下によって解決されています。
1. Use of a well known DSA with ``root knowledge''
1. 「根の知識」によるよく知られているDSAの使用
2. Naming DSAs in a manner which prevents deadlocks. Currently this
is done by giving DSAs names high in the DIT.
2. 行き詰まりを防ぐ方法でDSAsを命名します。 DSAs名をDITで高く与えることによって、現在の、これをします。
The Internet Pilot will need to define detailed policies for naming DSAs, in conjunction with the replication policy. This will be defined in a future RFC.
インターネットPilotは、模写方針に関連してDSAsを命名するための詳細な方針を定義する必要があるでしょう。 これは将来のRFCで定義されるでしょう。
6 Knowledge Representation
6知識表現
Knowledge information is represented in the DIT. It seems unreasonable to manage this by any other means. Knowledge information is represented in an entry by use of knowledge attributes. These attributes are considered separately from all the other attributes in the entry which are termed ``user attributes''. Each entry in a master EDB will be in one of four categories.
知識情報はDITに表されます。 いかなる他の手段でもこれを管理するのは無理に思えます。 知識情報はエントリーに知識属性の使用で表されます。 これらの属性は別々にエントリーにおける「ユーザ属性」と呼ばれる他のすべての属性から考えられます。 4つのカテゴリの1つにはマスターEDBの各エントリーがあるでしょう。
1. The entry is a leaf entry mastered in this EDB, and so only
contains user attributes
1. エントリーは、このEDBで習得された葉のエントリーであるのでユーザ属性を含むだけです。
2. The level below has an associated EDB (i.e., the DIT continues
downwards to use the data model of this specification). All
attributes of this entry will be mastered in this entry. The
entry will contain an attribute with the name of the DSA which
holds the master of the associated EDB. Optionally, it will
contain an attribute holding the names of DSAs which hold slave
EDBs. The entry may not hold a subordinate reference attribute.
The DIT is followed by use of the master and slave attributes.
2. 以下のレベルに、関連EDBがあります(すなわち、DITは、下向きにこの仕様のデータモデルを使用し続けています)。 このエントリーのすべての属性がこのエントリーで習得されるでしょう。 エントリーは関連EDBのマスターを保持するDSAという名前がある属性を含むでしょう。 任意に、それは奴隷EDBsを持っているDSAsという名前を保持する属性を含むでしょう。 エントリーは下位参照属性を保持しないかもしれません。 マスターと奴隷属性の使用はDITのあとに続いています。
Hardcastle-Kille Page 6
Hardcastle-Kille6ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
3. The entry is mastered in a DSA which does not follow this
specification. The entry in the EDB will contain a master
attribute, which holds a subordinate reference (or cross
reference) to the DSA which holds the master entry. The user
attributes of the entry will be mastered in the DSA pointed to by
the reference. The DSA holding the master EDB, which actually
acts as an intermediate shadow for this entry, will read these
attributes from the DSA indicated by the reference, so that it
will have a full copy of the entry, using a standared DSP Read
operation. This technique is called ``spot shadowing''. Any
access control on the entry being spot shadowed must be configured
so that all attributes can be copied by the DSA holding the master
EDB. DSAs taking slave copies of the EDB will not do spot
shadowing. However, the knowledge attributes will be copied, and
may be used by this DSA (e.g., for modify operations).
3. エントリーはこの仕様に従わないDSAで習得されます。 EDBのエントリーはマスター属性を含むでしょう。(それは、マスターエントリーを保持するDSAとして下位参照を保持します(参照に交差してください))。 エントリーのユーザ属性は参照で示されたDSAで習得されるでしょう。 実際にこのエントリーへの中間的影として機能するマスターEDBを持っているDSAは参照で示されたDSAからこれらの属性を読むでしょう、それにはエントリーの完全なコピーがあるように、standared DSP Read操作を使用して。 このテクニックは「スポットシャドウイング」と呼ばれます。 マスターEDBを持っているDSAがすべての属性をコピーできるように、エントリー存在場所におけるコントロールが影でおおったどんなアクセスも構成しなければなりません。 EDBの奴隷コピーを取るDSAsがスポットシャドウイングをしないでしょう。 しかしながら、知識属性がコピーされて、このDSAによって使用されるかもしれない、(例えば、変更、操作)
4. The entries at the level below are held in DSAs which do not
follow this specification, and all of these are indicated by a set
of NSSRs (Non Specific Subordinate Reference). The NSSRs are
stored as an attribute of the entry. The user attributes are
either mastered in the EDB.
It is important to note that NSSRs are stored at the level above
subordinate references. At a given point in the DIT, if there are
subordinate references, these are stored in shadow entries below
that point, and named by the RDN. If there are NSSRs, they are
stored in the entry itself, as there is no RDN associated with an
NSSR. This approach is cleanest where there are either NSSRs or
subordinate references, but not both. For example, consider an
Organisation HP, whose many OUs are stored in a set of DSAs
indicated by by NSSRs. Here, the NSSR attributes will be used to
identify these DSAs.
This model of replication is not tightly integrated with NSSRs.
Where there is a mixture of NSSRs and Subordinate references at a
given point in the DIT, this is handled by giving a single
subordinate reference to a DSA which follows standard X.500
distributed operations and can cleanly handle this mixture. In
practice, this is equivalent to not allowing a mixture of
subordinate references and NSSRs.
4. 以下のレベルにおけるエントリーはこの仕様に従わないDSAsに保持されます、そして、これらのすべてがNSSRs(非Specific Subordinate Reference)の1セットによって示されます。 NSSRsはエントリーの属性として格納されます。 ユーザ属性はEDBで習得されます。 NSSRsがレベルで下位参照の上に格納されることに注意するのは重要です。 DITの与えられたポイントでは、下位参照があれば、これらは、そのポイントより下での影のエントリーに格納されて、RDNによって命名されます。 NSSRsがあれば、NSSRに関連しているどんなRDNもないとき、彼らはエントリー自体に格納されます。 このアプローチは、NSSRsか下位参照のどちらかがあるところで最も清潔ですが、ともに清潔であるというわけではありません。 例えば、多くのOUsがNSSRsによって示されたDSAsの1セットに格納されるOrganisation HPを考えてください。 ここで、NSSR属性は、これらのDSAsを特定するのに使用されるでしょう。 模写のこのモデルはしっかりNSSRsと統合されません。 NSSRsとSubordinate参照の混合物がDITに与えられたポイントにあるところでは、これは、DSAの標準のX.500に続くただ一つの下位参照に分配された操作を与えることによって扱われて、清潔にこの混合物を扱うことができます。 実際には、これは下位参照とNSSRsの混合物を許容しないのに同等です。
The information framework needed to support this is defined in Figure_1.______________________________________________________________
これを支持するのに必要である情報枠組みは図_1で定義されます。______________________________________________________________
Hardcastle-Kille Page 7
Hardcastle-Kille7ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
InternetDSNonLeafObject ::= OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {masterDSA}
MAY CONTAIN {slaveDSA}
InternetDSNonLeafObject:、:= OBJECT-CLASS SUBCLASS OFがMUST CONTAIN masterDSAを上回っている、MAY CONTAINslaveDSA
ExternalDSObject ::= OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN {SubordinateReference, CrossReference, 10
NonSpecificSubordinateReference}
-- will contain exactly one of these references
ExternalDSObject:、:= OBJECT-CLASS SUBCLASS OFがMAY CONTAINを上回っている、SubordinateReference、CrossReference、10NonSpecificSubordinateReference--ちょうどこれらの参照の1つを含むでしょう。
MasterDSA ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
SINGLE VALUE
MasterDSA:、:= 属性構文distinguishedNameSyntaxと共にただ一つの値を結果と考えてください。
SlaveDSA ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
20
SubordinateReference ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AccessPoint
SINGLE VALUE
SlaveDSA:、:= 属性構文distinguishedNameSyntax20SubordinateReferenceと共に以下を結果と考えてください:= 属性構文AccessPointと共にただ一つの値を結果と考えてください。
CrossReference ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AccessPoint
SINGLE VALUE
CrossReference:、:= 属性構文AccessPointと共にただ一つの値を結果と考えてください。
NonSpecificSubordinateReference ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AccessPoint 30
NonSpecificSubordinateReference:、:= 属性構文AccessPoint30がある属性
AccessPoint ::= SET {
ae-title [0] Name,
address [2] PresentationAddress OPTIONAL }
AccessPoint:、:= セットします。ae-タイトル[0]名、アドレス[2]PresentationAddress OPTIONAL
-- Same definition as X.500 AccessPoint,
-- but presentation address is optional
-- X.500 AccessPointと同じ定義--プレゼンテーションアドレスだけが任意です。
___________________Figure_1:__Knowledge_Attributes_____________________
___________________図_1: __知識_属性_____________________
Two object classes are defined to support this approach:
2つの物のクラスがこのアプローチを支持するために定義されます:
Hardcastle-Kille Page 8
Hardcastle-Kille8ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
InternetDSNonLeafObject This is for where the level below follows the
model defined here, and there is an Entry Data Block (EDB)
containing the sibling entries. The Entry itself contains master
data. The associated attributes are:
兄弟エントリーを含んでいて、以下のレベルがここで定義されたモデルに従って、Entry Data Block(EDB)があるところにはInternetDSNonLeafObject Thisがあります。 Entry自身はマスタデータを含んでいます。 関連属性は以下の通りです。
MasterDSA The name of the DSA where the master EDB is held.
MasterDSA、マスターEDBが持たれているDSAという名前。
SlaveDSA The names of DSAs which hold slave copies of the EDB for
public access.
SlaveDSAは公共のアクセサリーのためのEDBの奴隷コピーを持っているDSAsという名前です。
ExternalDSObject 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 NonSpecificSubordinateReference, the master of the
entry will be in the master EDB, For SubordinateReference or
CrossReference1 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. DSAs holding slave copies of the EDB
do not perform spot shadowing, but do receive copies of the
references.
X.500に応じて以下のエントリーとレベルが習得されるところにはExternalDSObject Thisがあります。 質問を決議するのに使用される標準の知識参照に対応する属性があります。 プレゼンテーションアドレスはこれらの属性で任意です。 プレゼントでないなら、それはDSAsの自己のエントリーで調べられるべきです。 NonSpecificSubordinateReferenceに関しては、エントリーのマスターはマスターEDB、For SubordinateReferenceまたはCrossReference1DSAでのEDBが「影を見つける」どのマスターがエントリーであったかならそうするでしょう、間隔を置いてそれを読むことによって。 これは、マスターEDBがそれぞれのエントリーのコピーを含むのを確実にするでしょう。 そして、それはデータのマスターコピーにアクセスするのに必要でないところで効率的に単一の平らな探すことができます。 EDBの奴隷コピーを持っているDSAsがスポットシャドウイングを実行しませんが、参照のコピーを受けてください。
7 Replication Protocol
_______________________________________________________________________
GetEntryDataBlock ABSTRACT-OPERATION
ARGUMENT GetEntryDataBlockArgument
RESULT GetEntryDataBlockResult
ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}
7 模写プロトコル_______________________________________________________________________ GetEntryDataBlock抽象的な操作議論GetEntryDataBlockArgument結果GetEntryDataBlockResult誤りnameError、ServiceError、SecurityError、EDBVersionError
EDBVersionError ABSTRACT-ERROR
PARAMETER versionHeld EDBVersion
EDBVersionError抽象的なエラー・パラメータversionHeld EDBVersion
GetEntryDataBlockArgument ::= SET { 10
GetEntryDataBlockArgument:、:= セット、10
----------------------------
1. These references are really the same. The function and value
are the same. The name depends on where the reference is stored. It
may be preferable to have only one attribute.
---------------------------- 1. これらの参照は本当に同じです。 機能と値は同じです。 名前は参照が格納されるところによります。 1つの属性しか持っていないのは望ましいかもしれません。
Hardcastle-Kille Page 9
Hardcastle-Kille9ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
entry [0] DistinguishedName,
CHOICE {
sendIfMoreRecentThan [1] EDBVersion,
getVersionNumber [2] NULL,
getEDB [3] NULL, -- force retrieval
continuation [4] SEQUENCE {
EDBVersion,
nextEntryPosition INTEGER }
},
maxEntries [5] INTEGER OPTIONAL 20
-- if omitted return whole EDB in
-- one operation
}
エントリー[0]DistinguishedName、CHOICE、sendIfMoreRecentThan[1]EDBVersion、getVersionNumber[2]NULL、getEDB[3]NULL--検索継続[4]SEQUENCEを強制してください、EDBVersion、nextEntryPosition INTEGER、maxEntries[5]INTEGER OPTIONAL20、中の省略されたリターンの全体のEDBであるなら1つの操作
GetEntryDataBlockResult ::= SEQUENCE {
versionHeld [0] EDBVersion,
[1] SEQUENCE OF RelativeEntry OPTIONAL,
-- if omitted, only version is returned
nextEntryPostion INTEGER OPTIONAL
-- if omitted there are no more entries 30
}
GetEntryDataBlockResult:、:= 系列[1] versionHeld[0]EDBVersion、そこで省略されるなら、省略するなら、nextEntryPostion INTEGER OPTIONALをバージョンだけに返すというSEQUENCE OF RelativeEntry OPTIONALは、より多くのエントリー30です。
RelativeEntry ::= SEQUENCE {
RelativeDistinguishedName,
SET OF Attribute
}
RelativeEntry:、:= 系列RelativeDistinguishedName、属性のセット
EDBVersion ::= UTCTime 40
EDBVersion:、:= UTCTime40
___________________Figure_2:__Replication_Protocol_____________________
___________________図_2: __模写_プロトコル_____________________
A ROS operation to support replication is defined in Figure 2. This pulls an entire copy of the EDB. In normal use, the initiator specifies the EDB Version held. If the responder has a more recent version, then all of the entries in the EDB are returned. There are options to rerequest only the version of EDB held, or to return the full EDB irrespective of the version held by the initiator. For large EDBs, transfer of an entire EDB in a single operation would lead to very large ROS PDUs. This gives a definite scaling limitation. To overcome this, the protocol allows an EDB to be retrived in chunks of a size (in number of entries) specified by the
模写を支持するROS操作は図2で定義されます。 これはEDBの全体のコピーを引きます。 通常の使用で、創始者はバージョンが持っていたEDBを指定します。 応答者により最近のバージョンがあるなら、EDBのエントリーのすべてを返します。 最もrerequestへのEDBのバージョンだけが保持したオプションがあったか、またはバージョンの如何にかかわらず完全なEDBを返すのは創始者を固守しました。 大きいEDBsに関しては、ただ一つの操作における、全体のEDBの転送は非常に大きいROS PDUsに通じるでしょう。 これは明確なスケーリング制限を与えます。 これに打ち勝つために、プロトコルは、EDBが指定されたサイズ(エントリーの数における)の塊でretrivedされるのを許容します。
Hardcastle-Kille Page 10
Hardcastle-Kille10ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
initiator. The responder specifies a number which indicates the next entry to be transferred. The same operation can be used to retrieve the next chunk of the EDB, with EDBVersion and the same integer as parameters. 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. An implementation issue that must be noted is how to deal with updates whilst a multi-operation transfer is in progress. There are two possible approaches:
創始者。 応答者は移すために次のエントリーを示す数を指定します。 EDBの次の塊を検索するのに同じ操作を使用できます、EDBVersionとパラメタと同じ整数で。 このアプローチは実行するのが簡単です。 それは増加のテクニックほど効率的ではありません。 スケーリングが、増加のテクニックを使用しなければならないと決めるとき、適当な規格が利用可能になると予想されます。 注意しなければならない導入問題はマルチ操作転送が進行している間、どのようにアップデートに対処するかということです。 2つの可能なアプローチがあります:
1. 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).
1. EDBがわたるまで、アップデートを拒否するか、または妨げてください。 これはアップデートと転送の速度が高い問題を引き起こすかもしれません、アップデートがこれで非常に難しく(マネージャのための)なるとき。
2. Create a new version of the EDB, whilst retaining the old EDB to
complete the bulk transfer. A suitable retentions strategy would
be to hold an EDB version as long as the association on which it
is being pulled it remains active.
2. バルク転送を終了するために古いEDBを保有している間、EDBの新しいバージョンを作成してください。 適当な捕そく性戦略はそれが引かれている協会と同じくらい長くEDBバージョンを保持するために、アクティブなままであるということでしょう。
3. Allow the update and fail subsequent transfer requests for the
EDB. This may cause both transfer failure and excessive waste of
bandwidth due to retries if the rate of update and transfer is
high.
3. アップデートを許してください、そして、EDBを求めるその後の転送要求に失敗してください。 アップデートと転送の速度が高いなら、これは再試行による転送失敗と帯域幅の過度の浪費の両方を引き起こすかもしれません。
If option 1. or 3. is chosen, for a widely replicated EDB where the update rate is greater than a few changes per day, it is recommended to configure the master EDB in a DSA which only replicates to one other DSA. This second DSA can then control its update rate, and safely perform a large fanout of replications (option 3). The first DSA will have reasonable availability for modifications (option 1).
オプションが1か3に選ばれているなら、他の1DSAにしか模写しないDSAでマスターEDBを構成するのはアップデート率がいくつかの1日あたりの変化より大きい広く模写されたEDBに関してお勧めです。 この第2DSAは次に、アップデート率を制御して、安全に模写(オプション3)の大きいfanoutを実行できます。 最初のDSAには、変更(オプション1)のための妥当な有用性があるでしょう。
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 them2. This protocol should only transfer user attributes. In particular, implementation specific attributes such as those needed to support
このプロトコルは、高く木(通常根と国家のEDBs)でEDBsのコピーを入手するのにDSAsによって使用されるでしょう。 これらのコピーを必要とするDSAsはthem2にアクセスする二国間条約を確立するはずです。 このプロトコルはユーザ属性を移すだけであるべきです。 特にそれらなどの特定の属性が支持する必要があった実現
----------------------------
2. QUIPU defines some attributes to register such agreements, but
these are probably not appropriate for this specification.
---------------------------- 2. QUIPUはそのような協定を登録するためにいくつかの属性を定義しますが、この仕様には、これらはたぶん適切ではありません。
Hardcastle-Kille Page 11
Hardcastle-Kille11ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
private access control should not be transferred. There may be bilateral agreements on access control policy of the information (e.g., size limits on listing), which are implemented by (different) system specific techniques.
個人的なアクセス管理を移すべきではありません。 情報(例えば、リストにおけるサイズ限界)のアクセス管理方針に関する二国間条約があるかもしれません。(二国間条約は(異なる)のシステム特定のテクニックで履行されます)。
8 New Application Context
8の新しいアプリケーション関係
A DSA which follows these procedures will support a new ApplicationContext ``Internet DSP'' defined in Appendix A. This will be stored in the DSAs entry, so that support of the extensions defined here can easily be determined.
これらの手順に従うDSAはAppendix A.で定義された新しいApplicationContext「インターネットDSP」を支持するでしょう。ThisはDSAsエントリーに格納されるでしょう、ここで定義された拡大のサポートが容易に決定できるように。
9 Policy on Replication Procedures
模写手順に関する9方針
To be effective, a directory configuration must be laid out. These protocols will need to be used in the framework of a pilot, and service providers making available data for replication. There is a requirement to manage the replication process. This can be done by a combination of local configuration (to register shadowing agreements) and directory operations to set pointers to master and slave copies of the data.
有効に、なるように、ディレクトリ構成を広げなければなりません。 これらのプロトコルは、パイロット、および模写のための利用可能なデータを作るサービスプロバイダーのフレームワークに使用される必要があるでしょう。 模写プロセスを管理するという要件があります。 地方の構成(協定を影でおおいながら登録する)と指針がマスタリングするように設定するディレクトリ操作の組み合わせとデータの奴隷コピーはこれができます。
10 Use of the Directory by Applications
10 ディレクトリのアプリケーションによる使用
Care must be taken by users of the directory when replication is available. This is not a change from current use of X.500, but is noted here as it is important. Normal read requests should allow use of copy information. If the user of the directory believes that information may be out of date (e.g., because an association could not be established), then the request should be repeated and use of copy data prohibited by service controls.
模写が利用可能であるときに、ディレクトリのユーザは注意しなければなりません。 これは、X.500の現在の使用からの変化ではありませんが、それが重要であるようにここに述べられます。 通常の読み出し要求はコピー情報の使用を許すべきです。 ディレクトリのユーザが、情報が時代遅れであるかもしれないと信じているなら(例えば、協会を設立できなかったので)、要求は繰り返されるべきです、そして、サービスで禁止されたコピーデータの使用は制御されます。
11 Migration and Scaling
11の移行とスケーリング
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 average entry size of around a thousand bytes, and a maximum reasonable transfer size is tens of megabytes, then the
このアプローチの主要なスケーリング限界は非アップデート増加です。 これはサポートすることができる最大のDIT fanoutに限界を置くでしょう。 およそ1,000バイトの平均したエントリーサイズを与えて、最大の妥当な転送サイズは10メガバイトです、そして
Hardcastle-Kille Page 12
Hardcastle-Kille12ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
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. It should be noted that although the replication technique described here is general, it is only intended for high levels of the DIT. These figures assume this. 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).
このアプローチのfanout限界はオーダー10 000のものです。 より小さい機構が、地理的(例えば、州による米国で)に登録される傾向があることに注意してください、Organisationsの数の限界がいくらか大きいように。 ここで説明された模写のテクニックが一般的ですが、それがDITの高いレベルのために意図するだけであることに注意されるべきです。 これらの数字はこれを仮定します。 これらのテクニックは他のテクニックの模写の使用を排除しません。 このアプローチを使用するデータ、およびX.500(92)で定義されるそれを模写するのはかなり妥当でしょう。
References
参照
[HK91a] S.E. Hardcastle-Kille. Encoding network addresses to support
operation over non-osi lower layers. Request for Comments
RFC 1277, Department of Computer Science, University College
London, November 1991.
[HK91a]東南Hardcastle-Kille。 非osiの低級層の上の操作をサポートするためにネットワーク・アドレスをコード化します。 コメントには、1991年11月にRFC1277、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンを要求してください。
[HK91b] S.E. Hardcastle-Kille. Replication requirement to provide an
internet directory using X.500. Request for Comments
RFC 1275, Department of Computer Science, University College
London, November 1991.
[HK91b]東南Hardcastle-Kille。 X.500を使用することでインターネットディレクトリを提供するという模写要件。 コメントには、1991年11月にRFC1275、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンを要求してください。
12 Security Considerations
12 セキュリティ問題
Security considerations are not discussed in this memo.
このメモでセキュリティ問題について議論しません。
13 Author's Address
13作者のアドレス
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
スティーブHardcastle-Killeコンピュータサイエンス学部ユニバーシティ・カレッジロンドンWC1E 6BTイギリスガウアー・ストリート
Phone: +44-71-380-7294
以下に電話をしてください。 +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
メール: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 13
Hardcastle-Kille13ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
A ASN.1 Summary and Object Identifier Allocation
ASN.1概要とオブジェクト識別子配分
There_are_a_few_object_identifiers_needed.__These_are_defined_here.____
_そこでは、_オブジェクト_識別子_しかare_a_ほとんど. __を必要としませんでした。これらの_は_ここで定義された_です。____
InternetDSP TAGS ::= BEGIN
InternetDSPは以下にタグ付けをします:= 始まってください。
IMPORTS
APPLICATION-SERVICE-ELEMENT, PORT, APPLICATION-CONTEXT,
aCSE, ABSTRACT OPERATION
FROM Remote-Operations-Notation-extension {joint-iso-ccitt
remote-operations(4) notation-extension(2)}
リモート操作記法拡大から応用サービス要素、ポート、アプリケーション文脈がaCSE、抽象的な操作であるとインポートします。共同iso-ccittのリモート操作(4)記法拡大(2)
10
id-as-mrse, id-as-mase, id-as-ms
FROM MTSAccessProtocol {joint-iso-ccitt mhs-motis(6)
protocols(0) modules(0) object-identifiers(0)}
mrseとしての10イド、maseとしてのイド、ms FROM MTSAccessProtocolとしてのイド共同iso-ccitt mhs-motis(6)プロトコル(0)モジュール(0)オブジェクト識別子(0)
chainedReadASE, chainedSearchASE, chainedModifyASE
FROM DirectorySystemProtocol {joint-iso-ccitt ds(5)
modules(1) dsp(12)}
DirectorySystemProtocolからのchainedReadASE、chainedSearchASE、chainedModifyASE共同iso-ccitt ds(5)モジュール(1)dsp(12)
DistinguishedName, RelativeDistinguishedName, Attribute
FROM InformationFramework {joint-iso-ccitt ds(5) 20
modules(1) InformationFramework(1)}
InformationFrameworkからのDistinguishedName、RelativeDistinguishedName、属性共同iso-ccitt ds(5)20のモジュール(1)InformationFramework(1)
ATTRIBUTE, OBJECT-CLASS
FROM InformationFramework {joint-iso-ccitt ds(5)
modules(1) informationFramework(1)};
ATTRIBUTE、OBJECT-CLASS FROM InformationFramework共同iso-ccitt ds(5)モジュール(1)informationFramework(1)。
internet-dsp OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342) 30
ucl(19200300) internet-dsp(107)}
インターネット-dsp OBJECT IDENTIFIER:、:= ccittデータ(9)pss(2342)30ucl(19200300)インターネット-dsp(107)
-- General
-- 一般
at OBJECT IDENTIFIER ::= {internet-dsp at(1)}
oc OBJECT IDENTIFIER ::= {internet-dsp oc(2)}
オブジェクト識別子で:、:= (1)のインターネット-dsp oc OBJECT IDENTIFIER:、:= インターネット-dsp oc(2)
-- Object Classes needed for association
-- 協会に必要であるオブジェクトClasses
Hardcastle-Kille Page 14
Hardcastle-Kille14ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
40
id-ac-idsp OBJECT IDENTIFIER ::= {internet-dsp ac-idsp(3))}
id-as-idsp OBJECT IDENTIFIER ::= {internet-dsp as-idsp(4))}
id-ase-replication OBJECT IDENTIFIER ::= {internet-dsp ase-replication(5))}
40イド-ac-idsp OBJECT IDENTIFIER:、:= idsp OBJECT IDENTIFIERとしてのインターネット-dsp ac-idsp(3))イド:、:= インターネットidsp(4))としてdspなイドase模写OBJECT IDENTIFIER:、:= インターネット-dsp ase模写(5))
-- Attribute Types
-- 属性タイプ
master-dsa MasterDSA ::= {at 1}
slave-dsa SlaveDSA ::= {at 2}
subordinate-reference SubordinateReference ::= {at 3} 50
cross-reference CrossReference ::= {at 4}
nssr NonSpecificSubordinateReference ::= {at 5}
マスター-dsa MasterDSA:、:= 1、奴隷-dsa SlaveDSA:、:= 下位の参照している2時にSubordinateReference:、:= 50は3時にCrossReferenceに十字で参照をつけます:、:= 4、nssr NonSpecificSubordinateReference:、:= 5
-- Object Classes
-- オブジェクトのクラス
internet-ds-non-leaf-object InternetDSNonLeafObject ::= {oc 1}
external-ds-object ExternalDSObject ::= {oc 2}
インターネットのdsの非葉のオブジェクトInternetDSNonLeafObject:、:= oc1外部のdsオブジェクトExternalDSObject:、:= oc2
-- Operation and Error bindings 60
-- 操作とError結合60
getEntryDataBlock GetEntryDataBlock ::= 10
getEntryDataBlock GetEntryDataBlock:、:= 10
eDBVersionError EDBVersionError ::= 10
eDBVersionError EDBVersionError:、:= 10
-- Protocol Definitions
-- プロトコル定義
replicationASE APPLICATION-SERVICE-ELEMENT
OPERATIONS {getEntryDataBlock} 70
::= id-ase-replication
replicationASE応用サービス要素操作getEntryDataBlock、70:、:= イドase模写
internet-dsp APPLICATION-CONTEXT
APPLICATION SERVICE ELEMENTS {aCSE}
BIND MSBind
UNBIND MSUnbind
REMOTE OPERATIONS {rOSE}
OPERATIONS OF { chainedReadADSm chainedSearchASE,
chainedModifyASE, replicationASE }
ABSTRACT SYNTAXES { 80
id-as-acse,
id-as-idsp }
::= id-ac-idsp
インターネット-dsp APPLICATION-CONTEXT APPLICATION SERVICE Elements aCSE、BIND MSBind UNBIND MSUnbind REMOTE OPERATIONS rOSE、OPERATIONS OF、chainedReadADSm chainedSearchASE、chainedModifyASE、replicationASE、ABSTRACT SYNTAXES、acseとしての80イド、idspとしてのイド:、:= イド-ac-idsp
Hardcastle-Kille Page 15
Hardcastle-Kille15ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
90
InternetDSNonLeafObject ::= OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {masterDSA}
MAY CONTAIN {slaveDSA}
90InternetDSNonLeafObject:、:= OBJECT-CLASS SUBCLASS OFがMUST CONTAIN masterDSAを上回っている、MAY CONTAINslaveDSA
ExternalDSObject ::= OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN {SubordinateReference, CrossReference,
NonSpecificSubordinateReference}
-- will contain exactly one of these references100
ExternalDSObject:、:= OBJECT-CLASS SUBCLASS OFがMAY CONTAINを上回っている、SubordinateReference、CrossReference、NonSpecificSubordinateReference--ちょうどこれらのreferences100の1つを含むために望んでください。
MasterDSA ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
SINGLE VALUE
MasterDSA:、:= 属性構文distinguishedNameSyntaxと共にただ一つの値を結果と考えてください。
SlaveDSA ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
SlaveDSA:、:= 属性構文distinguishedNameSyntaxがある属性
SubordinateReference ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AccessPoint 110
SINGLE VALUE
SubordinateReference:、:= 属性構文AccessPoint110と共にただ一つの値を結果と考えてください。
CrossReference ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AccessPoint
SINGLE VALUE
CrossReference:、:= 属性構文AccessPointと共にただ一つの値を結果と考えてください。
NonSpecificSubordinateReference ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AccessPoint
NonSpecificSubordinateReference:、:= 属性構文AccessPointがある属性
AccessPoint ::= SET { 120
ae-title [0] Name,
address [2] PresentationAddress OPTIONAL }
AccessPoint:、:= セットします。120ae-タイトル[0]名、アドレス[2]PresentationAddress OPTIONAL
-- Same definition as X.500 AccessPoint,
-- but presentation address is optional
-- X.500 AccessPointと同じ定義--プレゼンテーションアドレスだけが任意です。
GetEntryDataBlock ABSTRACT-OPERATION
GetEntryDataBlockの抽象的な操作
Hardcastle-Kille Page 16
Hardcastle-Kille16ページ
RFC 1276 Internet Directory Replication November 1991
RFC1276インターネットディレクトリ模写1991年11月
ARGUMENT GetEntryDataBlockArgument
RESULT GetEntryDataBlockResult
ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}130
議論GetEntryDataBlockArgument結果GetEntryDataBlockResult誤り、nameError、ServiceError、SecurityError、EDBVersionError、130
EDBVersionError ABSTRACT-ERROR
PARAMETER versionHeld EDBVersion
EDBVersionError抽象的なエラー・パラメータversionHeld EDBVersion
GetEntryDataBlockArgument ::= SET {
entry [0] DistinguishedName,
CHOICE {
sendIfMoreRecentThan [1] EDBVersion,
getVersionNumber [2] NULL, 140
getEDB [3] NULL, -- force retrieval
continuation [4] SEQUENCE {
EDBVersion,
nextEntryPosition INTEGER }
},
maxEntries [5] INTEGER OPTIONAL
-- if omitted return whole EDB in
-- one operation
}
150
GetEntryDataBlockResult ::= SEQUENCE {
versionHeld [0] EDBVersion,
[1] SEQUENCE OF RelativeEntry OPTIONAL,
-- if omitted, only version is returned
nextEntryPostion INTEGER OPTIONAL
-- if omitted there are no more entries
}
GetEntryDataBlockArgument:、:= SET、エントリー[0]DistinguishedName、CHOICE、sendIfMoreRecentThan[1]EDBVersion、getVersionNumber[2]NULL、140getEDB[3]NULL--検索継続[4]SEQUENCEを強制してください、EDBVersion、nextEntryPosition INTEGER、maxEntries[5]INTEGER OPTIONAL、中の省略されたリターンの全体のEDBであるなら1つの操作、150GetEntryDataBlockResult:、:= 系列[1] versionHeld[0]EDBVersion、そこで省略されるなら、省略するなら、nextEntryPostion INTEGER OPTIONALをバージョンだけに返すというSEQUENCE OF RelativeEntry OPTIONALはそれ以上のエントリーではありません。
160
RelativeEntry ::= SEQUENCE {
RelativeDistinguishedName,
SET OF Attribute
}
160RelativeEntry:、:= 系列RelativeDistinguishedName、属性のセット
EDBVersion ::= UTCTime END
EDBVersion:、:= UTCTimeエンド
___________________Figure_3:__Summary_of_the_ASN.1_____________________
___________________図_3: __ASN.1の__概要______________________
Hardcastle-Kille Page 17
Hardcastle-Kille17ページ
一覧
スポンサーリンク
