RFC1798 日本語訳
1798 Connection-less Lightweight X.500 Directory Access Protocol. A.Young. June 1995. (Format: TXT=18548 bytes) (Obsoleted by RFC3352) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Young Request for Comments: 1798 ISODE Consortium Category: Standards Track June 1995
コメントを求めるワーキンググループのA.の若い要求をネットワークでつないでください: 1798年のISODE共同体カテゴリ: 標準化過程1995年6月
Connection-less Lightweight X.500 Directory Access Protocol
コネクションレスな軽量のX.500ディレクトリアクセス・プロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
X.500
X.500
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP) [3]. In particular, it is aimed at avoiding the elapsed time that is associated with connection-oriented communication and it facilitates use of the Directory in a manner analagous to the DNS [5,6]. It is specifically targeted at simple lookup applications that require to read a small number of attribute values from a single entry. It is intended to be a complement to DAP and LDAP [4]. The protocol specification draws heavily on that of LDAP.
本書では説明されたプロトコルは、ディレクトリAccessプロトコル(DAP)[3]のリソース要件を被っていない間、ディレクトリへのアクセスを提供するように設計されています。 特に、コネクション型通信に関連している経過時間を避けるのは目的とされます、そして、それはDNS[5、6]に方法analagousにおけるディレクトリの使用を容易にします。 それはそれが単一のエントリーから少ない数の属性値を読むのを必要とする簡単なルックアップアプリケーションのときに明確に狙います。 DAPとLDAP[4]への補数であることは意図しています。 プロトコル仕様はLDAPからそれを大いに引き出します。
1. Background
1. バックグラウンド
The Directory can be used as a repository for many kinds of information. The full power of DAP is unnecessary for applications that require simple read access to a few attribute values. Applications addressing is a good example of this type of use where an application entity needs to determine the Presentation Address (PA) of a peer entity given that peer's Application Entity Title (AET). If the AET is a Directory Name (DN) then the required result can be obtained from the PA attribute of the Directory entry identified by the AET. This is very similar to DNS.
多くの種類の情報に倉庫としてディレクトリを使用できます。 いくつかの属性値への簡単な読書アクセスを必要とするアプリケーションに、DAPの全出力は不要です。 その同輩のApplication Entity Title(AET)を考えて、アプリケーションアドレシングはアプリケーション実体が同輩実体のPresentation Address(PA)を決定する必要がある使用のこのタイプの好例です。 AETがディレクトリName(DN)であるなら、AETによって特定されたディレクトリエントリーのPA属性から必要な結果を得ることができます。 これはDNSと非常に同様です。
Young Standards Track [Page 1] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[1ページ]。
Use of DAP to achieve this functionality involves a significant number of network exchanges:
この機能性を達成するDAPの使用は多くのネットワーク交換にかかわります:
___________________________________________________________
|_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
| 1| N-Connect.request -> |
| 2| <- N-Connect.response |
| 3| T-Connect.request -> |
| 4| <- T-Connect.response |
| | S-Connect.request, |
| | P-Connect.request, |
| | A-Associate.request, |
| 5| DAP-Bind.request -> |
| | S-Connect.response, |
| | P-Connect.response, |
| | A-Associate.response, |
| 6| <- DAP-Bind.response |
| 7| DAP-Read.request -> |
| 8| <- DAP-Read.response |
| | S-Release.request, |
| | P-Release.request, |
| | A-Release.request, |
| 9| DAP-Unbind.request -> |
| | S-Release.response, |
| | P-Release.response, |
| | A-Release.response, |
| 10| <- DAP-Unbind.response |
| | T-Disconnect.request, |
| 11| N-Disconnect.request -> |
| | T-Disconnect.response,|
| 12| <- N-Disconnect.response |
|___|______________________________________________________|
___________________________________________________________ |_#_|______クライアント_(DUA)________ちょと浸してください。________サーバ_(DSA)_____| | 1| N-Connect.request->。| | 2| <。 N-Connect.response| | 3| T-Connect.request->。| | 4| <。 T-Connect.response| | | S-Connect.request| | | P-Connect.request| | | 1Associate.requestです。| | 5| Bind.requestをちょと浸している->。| | | S-Connect.response| | | P-Connect.response| | | 1Associate.responseです。| | 6| <。 Bind.responseをちょと浸します。| | 7| Read.requestをちょと浸している->。| | 8| <。 Read.responseをちょと浸します。| | | S-Release.request| | | P-Release.request| | | 1Release.requestです。| | 9| Unbind.requestをちょと浸している->。| | | S-Release.response| | | P-Release.response| | | 1Release.responseです。| | 10| <。 Unbind.responseをちょと浸します。| | | T-Disconnect.request| | 11| N-Disconnect.request->。| | | T-Disconnect.response| | 12| <。 N-Disconnect.response| |___|______________________________________________________|
Young Standards Track [Page 2] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[2ページ]。
This is 10 packets before the application can continue, given that it can probably do so after issuing the T-Disconnect.request. (Some minor variations arise depending upon the class of Network and Transport service that is being used; for example use of TP4 over CLNS reduces the packet count by two.) LDAP is no better in the case where the LDAP server uses full DAP to communicate with the Directory:
T-Disconnect.requestを発行した後にたぶんそうできるなら、アプリケーションが続くことができる前にこれは10のパケットです。 (利用されているNetworkの、そして、Transportサービスのクラスによって、いくつかの小さい方の変化が起こります; 例えば、CLNSの上のTP4の使用はパケットカウントを2つ抑えます。) LDAPサーバがディレクトリで交信するのに完全なDAPを使用する場合ではLDAPは、より良くはありません:
____________________________________________________________________ |__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______| | 1 | TCP SYN -> | | 2 | <- TCP SYN ACK | | 3 | BindReq -> | | 4 | N-Connect.req -> | | 5 | <- N-Connect.res | | 6 | T-Connect.req -> | | 7 | <- T-Connect.res | | 8 | DAP-Bind.req -> | | 9 | <- DAP-Bind.res | | 10 | <- BindRes | | 11 | SearchReq -> | | 12 | DAP-Search.req -> | | 13 | <- DAP-Search.res | | 14 | <- SearchRes | | 15 | TCP FIN -> | | 16 | DAP-Unbind.req -> | | 17 | <- DAP-Unbind.res | | 18 | N-Disconnect.req -> | | 19 | <- N-Disconnect.res| |____|______________________________________________________________|
____________________________________________________________________ |__#_|___クライアント_____LDAP_____LDAP_サーバ______ちょと浸してください。_________DSA_______| | 1 | TCP SYN->。| | 2 | <。 TCP SYN ACK| | 3 | BindReq->。| | 4 | N-Connect.req->。| | 5 | <。 N-Connect.res| | 6 | T-Connect.req->。| | 7 | <。 T-Connect.res| | 8 | Bind.reqをちょと浸している->。| | 9 | <。 Bind.resをちょと浸します。| | 10 | <。 BindRes| | 11 | SearchReq->。| | 12 | Search.reqをちょと浸している->。| | 13 | <。 Search.resをちょと浸します。| | 14 | <。 SearchRes| | 15 | TCPフィン->。| | 16 | Unbind.reqをちょと浸している->。| | 17 | <。 Unbind.resをちょと浸します。| | 18 | N-Disconnect.req->。| | 19 | <。 N-Disconnect.res| |____|______________________________________________________________|
Young Standards Track [Page 3] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[3ページ]。
Here there are 14 packets before the application can continue. Even if the LDAP server is on the same host as the DSA (so packet delay is negligible), or if the DSA supports LDAP directly, then there are still 6 packets.
ここに、アプリケーションが続くことができる前に14のパケットがあります。 DSAと同じホストの上にLDAPサーバがあるか(したがって、パケット遅れは取るにたらないです)、またはDSAが直接LDAPをサポートするなら、6つのパケットがまだあります。
____________________________________
| #| Client LDAP LDAP server|
|__|________________________________|
| 1| TCP SYN -> |
| 2| <- TCP SYN ACK|
| 3| BindReq -> |
| 4| <- BindRes |
| 5| SearchReq -> |
|_6|_______________<-____SearchRes__|
____________________________________ | #| クライアントLDAP LDAPサーバ| |__|________________________________| | 1| TCP SYN->。| | 2| <。 TCP SYN ACK| | 3| BindReq->。| | 4| <。 BindRes| | 5| SearchReq->。| |_6|_______________<。____SearchRes__|
This protocol provides for simple access to the Directory where the delays inherent in the above exchanges are unacceptable and where the additional functionality provided by connection-mode operation is not required.
このプロトコルは上の交換に固有の遅れが容認できなく、接続モード操作で提供された追加機能性は必要でないディレクトリへの簡単なアクセスに備えます。
2. Protocol Model
2. プロトコルモデル
CLDAP is based directly on LDAP [4] and inherits many of the key aspects of the LDAP protocol:
CLDAPは直接LDAP[4]に基づいていて、LDAPプロトコルの特徴の多くを引き継ぎます:
- - Many protocol data elements are encoding as ordinary strings
(e.g., Distinguished Names).
- - 要素が普通であるとしてコード化している多くのプロトコルデータが(例えば、Distinguished Names)を結びます。
- - A lightweight BER encoding is used to encode all protocol
elements.
- - 軽量のBERコード化は、すべてのプロトコル要素をコード化するのに使用されます。
It is different to LDAP in that:
それはそれでLDAPに異なっています:
- - Protocol elements are carried directly over UDP or other
connection-less transport, bypassing much of the
session/presentation overhead and that of connections (LDAP uses
a connection-mode transport service).
- - プロトコル要素はUDPか他のコネクションレスな輸送の直接上まで運ばれます、セッション/プレゼンテーションオーバーヘッドの多く、接続のものを迂回させて(LDAPは接続モード輸送サービスを使用します)。
- - A restricted set of operations is available.
- - 制限されたセットの操作は利用可能です。
The definitions of most protocol elements are inherited from LDAP.
ほとんどのプロトコル要素の定義はLDAPから引き継がれます。
The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, this is accomplished by a client transmitting a protocol request describing the operation to be performed to a server, which is then responsible for performing the necessary operations on the Directory.
このプロトコルによって採用された一般的なモデルはサーバに対してプロトコル操作を実行しているクライアントのひとりです。 このモデルでは、これは次にディレクトリに必要な操作を実行するのに原因となるサーバに実行されるために操作について説明するプロトコル要求を伝えるクライアントによって達成されます。
Young Standards Track [Page 4] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[4ページ]。
Upon completion of the necessary operations, the server returns a response containing any results or errors to the requesting client.
必要な操作の完成のときに、サーバはどんな結果も含む応答か誤りを要求しているクライアントに返します。
Note that, although servers are required to return responses whenever such responses are defined in the protocol, there is no requirement for synchronous behaviour on the part of either client or server implementations: requests and responses for multiple operations may be exchanged by client and servers in any order, as long as servers eventually send a response for every request that requires one.
サーバがそのような応答がプロトコルで定義されるときはいつも、応答を返すのに必要ですが、同期ふるまいのための要件が全くクライアントかサーバ実装のどちらか側のないことに注意してください: 順不同なクライアントとサーバで同時併行処理のための要求と応答を交換するかもしれません、サーバが結局1を必要とするあらゆる要求のための応答を送る限り。
Also, because the protocol is implemented over a connection-less transport service clients must be prepared for either requests or responses to be lost. Clients should use a retry mechanism with timeouts in order to achieve the desired level of reliability. For example, a client might send off a request and wait for two seconds. If no reply is forthcoming, the request is sent again and the client waits four seconds. If there is still no reply, the client sends it again and waits eight seconds, and so on, until some maximun time. Such algorithms are widely used in other datagram-based protocol implementations, such as the DNS. It is not appropriate to mandate a specific algorithm as this will depend upon the requirments and operational environment of individual CLDAP client implementations.
また、プロトコルがコネクションレスな輸送サービスの上で実装されるので、クライアントは要求か応答のどちらかが失われる用意ができていなければなりません。 クライアントは、必要なレベルの信頼性を獲得するのにタイムアウトに伴う再試行メカニズムを使用するべきです。 例えば、クライアントは、要求を送って、2秒間、待つかもしれません。 どんな回答も用意されていないなら、再び要求を送ります、そして、クライアントは4秒待ちます。 回答が全くまだなければ、クライアントは、再びそれを送って、8秒、などに待ちます、いつかのmaximun時間まで。 そのようなアルゴリズムはDNSなどの他のデータグラムベースのプロトコル実装に広く使用されます。 これが個々のCLDAPクライアント実装のrequirmentsと運用環境によるので、特定のアルゴリズムを強制するのは適切ではありません。
It is not required that a client abandon any requests to which no response has been received and for which a reply is no longer required (because the request has been timed out), but they may do so.
いずれも要求するクライアント放棄はどんな応答もどれでないかに受け取られて、回答がどれであるかためにもう必要ではありませんが(要求が外で調節されたので)、彼らがそうするかもしれないのが必要ではありません。
Consistent with the model of servers performing protocol operations on behalf of clients, it is also to be noted that protocol servers are expected to handle referrals without resorting to the return of such referrals to the client. This protocol makes no provisions for the return of referrals to clients, as the model is one of servers ensuring the performance of all necessary operations in the Directory, with only final results or errors being returned by servers to clients.
クライアントを代表してプロトコル操作を実行するサーバのモデルと一致しています、また、プロトコルサーバがそのような紹介のクライアントへの復帰に頼らないで紹介を扱うと予想されることに注意されることになっています。 このプロトコルはクライアントへの紹介の復帰に備えません、モデルがディレクトリにおける、すべての必要な操作の性能を確実にするサーバの1つであるので、最終的な結果か誤りだけがサーバによってクライアントに返されている状態で。
Note that this protocol can be mapped to a strict subset of the Directory abstract service, so it can be cleanly provided by the DAP.
DAPが清潔にそれを提供できるように、厳しい抽象的にディレクトリサービスの部分集合にこのプロトコルを写像できることに注意してください。
3. Mapping Onto Transport Services
3. サービスを輸送に写像します。
This protocol is designed to run over connection-less transports, with all 8 bits in an octet being significant in the data stream. Specifications for two underlying services are defined here, though others are also possible.
このプロトコルはコネクションレスな輸送をひくように設計されています、八重奏におけるすべての8ビットがデータ・ストリームで重要な状態で。 また、他のものも可能ですが、2つの基本的なサービスのための仕様はここで定義されます。
Young Standards Track [Page 5] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[5ページ]。
3.1. User Datagram Protocol (UDP)
3.1. ユーザー・データグラム・プロトコル(UDP)
The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only one request may be sent in a single datagram. Only one response may be sent in a single datagram. Server implementations running over the UDP should provide a protocol listener on port 389.
直接UDPデータグラムにCLDAPMessage PDUsを写像します。単一のデータグラムで1つの要求だけを送るかもしれません。 単一のデータグラムで1つの応答だけを送るかもしれません。 UDPをひくサーバ実装はポート389の上でプロトコルリスナーを提供するべきです。
3.2. Connection-less Transport Service (CLTS)
3.2. コネクションレスな輸送サービス(CLTS)
Each LDAPMessage PDU is mapped directly onto T-Unit-Data.
各LDAPMessage PDUは直接Tユニットデータに写像されます。
4. Elements of Protocol
4. プロトコルのElements
CLDAP messages are defined by the following ASN.1:
CLDAPメッセージは以下のASN.1によって定義されます:
CLDAPMessage ::= SEQUENCE {
messageID MessageID,
user LDAPDN, -- on request only --
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SEQUENCE OF
SearchResponse,
abandonRequest AbandonRequest
}
}
CLDAPMessage:、:= 系列messageID MessageID、要求だけでのユーザLDAPDN、protocolOp CHOICE、searchRequest SearchRequest、searchResponse SEQUENCE OF SearchResponse、abandonRequest AbandonRequest
where MessageID, LDAPDN, SearchRequest, SearchResponse and AbandonRequest are defined in the LDAP protocol.
MessageID、LDAPDN、SearchRequest、SearchResponse、およびAbandonRequestがLDAPで定義されるところでは、議定書を作ってください。
The 'user' element is supplied only on requests (it should be zero length and is ignored in responses). It may be used for logging purposes but it is not required that a CLDAP server implementation apply any particular semantics to this field.
単に要求のときに'ユーザ'要素を供給します(それは、ゼロ・レングスであるべきであり、応答で無視されます)。 それは伐採目的に使用されるかもしれませんが、CLDAPサーバ実装がどんな特定の意味論もこの分野に適用するのが必要ではありません。
Editorial note:
There has been some discussion about the desirability of
authentication with CLDAP requests and the addition of the fields
necessary to support this. This might take the form of a clear
text password (which would go against the current IAB drive to
remove such things from protocols) or some arbitrary credentials.
Such a field is not included. It is felt that, in general,
authentication would incur sufficient overhead to negate the
advantages of the connectionless basis of CLDAP. If an
application requires authenticated access to the Directory then
CLDAP is not an appropriate protocol.
社説欄の短評: CLDAP要求による認証の願わしさとこれをサポートするのに必要な分野の追加についての何らかの議論がありました。 これはクリアテキストパスワード(プロトコルからそのようなものを取り外す現在のIABドライブに反する)かいくつかの任意の資格証明書の形を取るかもしれません。 そのような分野は含まれていません。 一般に、認証がCLDAPのコネクションレスな基礎の利点を無効にすることができるくらいのオーバーヘッドを被るのを感じられます。 アプリケーションがディレクトリへの認証されたアクセスを必要とするなら、CLDAPは適切なプロトコルではありません。
Young Standards Track [Page 6] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[6ページ]。
Within a searchResponse all but the last SearchResponse has choice 'entry' and the last SearchResponse has choice 'resultCode'. Within a searchResponse, as an encoding optimisation, the value of the objectName LDAP DN may use a trailing '*' character to refer to the baseObject of the corresponding searchRequest. For example, if the baseObject is specified as "o=UofM, c=US", then the following objectName LDAPDNs in a response would have the indicated meanings
searchResponseの中では、最後のSearchResponse以外のすべてが特選している'エントリー'を持っています、そして、最後のSearchResponseには、選択'resultCode'があります。 searchResponseの中では、コード化最適化として、objectName LDAP DNの値は、対応するsearchRequestのbaseObjectについて言及するのに引きずっている'*'キャラクタを使用するかもしれません。 例えば、baseObjectが「o=UofM、c=米国」として指定されるなら、応答における以下のobjectName LDAPDNsには示された意味があるでしょう。
objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"
objectNameは指示された実際のLDAPDNを返しました。____________________________________________________ 「*」、「o=UofM、c=米国、」 「cnはBabsジェンセン、*と等しいこと」が「cnに、Babsジェンセン、o=UofM、c=米国と等しいです」。
4.1. Errors
4.1. 誤り
The following error code is added to the LDAPResult.resultCode enumeration of [4]:
以下のエラーコードは[4]のLDAPResult.resultCode列挙に加えられます:
resultsTooLarge (70),
resultsTooLarge(70)
This error is returned when the LDAPMessage PDU containing the results of an operation are too large to be sent in a single datagram.
操作の結果を含むLDAPMessage PDUが単一のデータグラムで送ることができないくらい大きいときに、この誤りは返されます。
4.2. Example
4.2. 例
A simple lookup can be performed in 4 packets. This is reduced to 2 if either the DSA implements the CLDAP protocol, the CLDAP server has a cache of the desired results, or the CLDAP server and DSA are co- located such that there is insignificant delay between them.
4つのパケットで簡単なルックアップを実行できます。 DSAがCLDAPプロトコルを実装するか、CLDAPサーバには望み通りの成果のキャッシュがあるか、またはCLDAPサーバとDSAがそれらの間には、わずかな遅れがあるように共同見つけられているなら、これは2まで減少します。
_______________________________________________________________
|_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
| 1| SearchReq -> |
| 2| DAP-Search.req -> |
| 3| <- DAP-Search.res|
| 4| <- SearchRes |
|__|___________________________________________________________|
_______________________________________________________________ |_#|___クライアント_____CLDAP____CLDAP_サーバ____ちょと浸してください。________DSA______| | 1| SearchReq->。| | 2| Search.reqをちょと浸している->。| | 3| <。 Search.resをちょと浸します。| | 4| <。 SearchRes| |__|___________________________________________________________|
5. Implementation Considerations
5. 実装問題
The following subsections provide guidance on the implementation of clients and servers using the CLDAP protocol.
以下の小区分は、クライアントとサーバの実装でCLDAPプロトコルを使用することで指導を提供します。
Young Standards Track [Page 7] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[7ページ]。
5.1. Server Implementations
5.1. サーバ実装
Given that the goal of this protocol is to minimise the elapsed time between making a Directory request and receiving the response, a server which uses DAP to access the directory should use techniques that assist in this.
このプロトコルの目標がディレクトリ要求をして、応答を受けるとき経過時間を最小とならせることであるなら、ディレクトリにアクセスするのにDAPを使用するサーバはこれを助けるテクニックを使用するべきです。
- - A server should remain bound to the Directory during reasonably
long idle periods or should remain bound permanently.
- - サーバは、適度に長い活動していない期間、ディレクトリのままでバウンドのままで残るべきであるか、または永久に、制限されていたままで残るべきです。
- - Cacheing of results is highly desirable but this must be
tempered by the need to provide up-to-date results given the
lack of a cache invalidation protocol in DAP (either implicit
via timers or explicit) and the lack of a dontUseCopy service
control in the protocol.
- - 結果のCacheingは非常に望ましいのですが、DAP(タイマを通した暗黙の、または、明白な)のキャッシュ無効にするプロトコルの不足とプロトコルにおける、dontUseCopyサービス制御の不足を考えて、最新の結果を提供する必要性でこれを焼き戻さなければなりません。
Of course these issues are irrelevant if the CLDAP protocol is directly supported by a DSA.
もちろん、CLDAPプロトコルがDSAによって直接サポートされるなら、これらの問題は無関係です。
5.2. Client Implementations
5.2. クライアント実装
For simple lookup applications, use of a retry algorithm with multiple servers similar to that commonly used in DNS stub resolver implementations is recommended. The location of a CLDAP server or servers may be better specified using IP addresses (simple or broadcast) rather than names that must first be looked up in another directory such as DNS.
簡単なルックアップアプリケーションにおいて、DNSスタッブレゾルバ実装に一般的に使用されるそれと同様の複数のサーバによる再試行アルゴリズムの使用はお勧めです。 CLDAPサーバかサーバの位置は、最初にDNSなどの別のディレクトリで調べなければならない名前よりむしろIPアドレス(簡単であるか放送の)を使用することで指定されるほうがよいです。
6. Security Considerations
6. セキュリティ問題
This protocol provides no facilities for authentication. It is expected that servers will bind to the Directory either anonymously or using simple authentication without a password.
このプロトコルは施設を全く認証に提供しません。 サーバがそうすると匿名でディレクトリに付くか、またはパスワードなしで簡易認証を使用することで予想されます。
7. Bibliography
7. 図書目録
[1] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[1] ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要。 CCITT推薦X.500、1988。
[2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
1/SC21; International Standard 9594-2, 1988.
[2] ディレクトリ: モデル。 CCITT推薦X.501 ISO/IEC JTC1/SC21。 国際規格9594-2、1988。
[3] The Directory: Abstract Service Definition. CCITT Recommendation
X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
[3] ディレクトリ: 抽象的なサービス定義。 CCITT推薦X.511、ISO/IEC JTC1/SC21。 国際規格9594-3、1988。
[4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
Access Protocol", RFC 1487, Performance Systems International,
University of Michigan, ISODE Consortium, July 1993.
[4]YeongとW.とハウズ、T.とS.Kille、「X.500ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1487、国際言語運用機構、ミシガン大学、ISODE共同体、1993年7月。
Young Standards Track [Page 8] RFC 1798 CLDAP June 1995
若い規格はCLDAP1995年6月にRFC1798を追跡します[8ページ]。
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[5]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[6]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
8. Acknowledgements
8. 承認
Many thanks to Tim Howes and Steve Kille for their detailed comments and to other members of the working group.
彼らの詳細なコメントのためのティム・ハウズとスティーブKilleと、そして、ワーキンググループの他のメンバーをありがとうございます。
This work was initiated by the Union Bank of Switzerland.
この仕事はスイス・ユニオン銀行によって開始されました。
9. Author's Address
9. 作者のアドレス
Alan Young ISODE Consortium The Dome, The Square RICHMOND GB - TW9 1DT
ドーム、アランヤングISODE共同体の正方形のリッチモンド、GB--、TW9 1DT
Phone: +44 81 332 9091 EMail: A.Young@isode.com X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
以下に電話をしてください。 +44 81 332 9091はメールされます: A.Young@isode.com X.400: i=A。 sはヤングと等しいです。 o=ISODE共同体。 p=ISODE。 a=MAILNET。 c=FI
Young Standards Track [Page 9]
若い標準化過程[9ページ]
一覧
スポンサーリンク
