RFC1249 日本語訳

Network Working Group                                           T. Howes
Request for Comments: 1249                                      M. Smith
                                                              B. Beecher
                                                  University of Michigan
                                                             August 1991

コメントを求めるワーキンググループT.ハウズの要求をネットワークでつないでください: 1249 M.スミスB.ビーチャーミシガン大学1991年8月

                      DIXIE Protocol Specification

デキシープロトコル仕様

Status of this Memo

このMemoの状態

   This RFC defines a mechanism by which TCP/UDP based clients can
   access OSI Directory Service without the overhead of the ISO
   transport and presentation protocols required to implement full-blown
   DAP.  This memo provides information for the Internet community.  It
   does not specify any standard.  Distribution of this memo is
   unlimited.

このRFCはTCP/UDPのベースのクライアントがプロトコルが花盛りのDAPを実装するのを必要としたISO輸送とプレゼンテーションのオーバーヘッドなしでOSIディレクトリサービスにアクセスできるメカニズムを定義します。 このメモはインターネットコミュニティのための情報を提供します。 それはどんな規格も指定しません。 このメモの分配は無制限です。

Table of Contents

目次

   1. Introduction ..............................................  2
   1.1 History ..................................................  2
   2. Protocol ..................................................  2
   2.1 Header ...................................................  3
   2.2 Operations ...............................................  4
   2.2.1 Read ...................................................  4
   2.2.1.1 Read Request .........................................  4
   2.2.1.2 Read Reply ...........................................  4
   2.2.2 Search .................................................  5
   2.2.2.1 Search Request .......................................  5
   2.2.2.2 Search Reply .........................................  5
   2.2.3 List ...................................................  5
   2.2.3.1 List Request .........................................  5
   2.2.3.2 List Reply ...........................................  5
   2.2.4 Modify .................................................  5
   2.2.4.1 Modify Request .......................................  6
   2.2.4.2 Modify Reply .........................................  6
   2.2.5 Modify RDN .............................................  6
   2.2.5.1 Modify RDN Request ...................................  6
   2.2.5.2 Modify RDN Reply .....................................  6
   2.2.6 Add ....................................................  6
   2.2.6.1 Add Request ..........................................  7
   2.2.6.2 Add Reply ............................................  7
   2.2.7 Remove .................................................  7
   2.2.7.1 Remove Request .......................................  7
   2.2.7.2 Remove Reply .........................................  7
   2.2.8 Bind ...................................................  7
   2.2.8.1 Bind Request .........................................  7

1. 序論… 2 1.1歴史… 2 2. 議定書を作ってください… 2 2.1ヘッダー… 3 2.2の操作… 4 2.2 .1 読んでください… 4 2.2 .1 .1 要求を読んでください… 4 2.2 .1 .2 回答を読んでください… 4 2.2 .2 探してください… 5 2.2 .2 .1 要求を捜してください… 5 2.2 .2 .2 回答を捜してください… 5 2.2 .3 記載してください… 5 2.2 .3 .1 要求をリストアップしてください… 5 2.2 .3 .2 回答を記載してください… 5 2.2 .4 変更します。 5 2.2 .4 .1 要求を変更してください… 6 2.2 .4 .2 回答を変更してください… 6 2.2 .5 RDNを変更してください… 6 2.2 .5 .1 RDN要求を変更してください… 6 2.2 .5 .2 RDN回答を変更してください… 6 2.2 .6 加えてください… 6 2.2 .6 .1 要求を加えてください… 7 2.2 .6 .2 回答を加えてください… 7 2.2 .7 取り外してください… 7 2.2 .7 .1 要求を取り除いてください… 7 2.2 .7 .2 回答を取り除いてください… 7 2.2 .8 付いてください… 7 2.2 .8 .1 要求を縛ってください… 7

Howes, Smith, & Beecher                                         [Page 1]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[1ページ]RFC1249デキシー1991年8月

   2.2.8.2 Bind Reply ...........................................  8
   2.3 Operation Code Summary ...................................  8
   2.4 Return Code Summary ......................................  8
   3. References ................................................  9
   4. Available Implementations .................................  9
   5. Security Considerations....................................  9
   6. Authors' Addresses ........................................ 10

2.2.8.2 回答を縛ってください… 8 2.3命令コード概要… 8 2.4復帰コード概要… 8 3. 参照… 9 4. 利用可能な実装… 9 5. セキュリティ問題… 9 6. 作者のアドレス… 10

1.    Introduction

1. 序論

   OSI Directory Service defines a powerful mechanism for storing and
   retrieving information about objects, and for arranging those objects
   in a hierarchical structure.  Many types of objects and information
   can be stored in The Directory, including white pages information,
   application information, service information, etc.  The OSI protocol
   defined to allow access to this information is the Directory Access
   Protocol (DAP).  The DAP, being an OSI application-layer program, is
   fairly heavy-weight and requires a substantial amount of computing
   power and coding investment to implement.

OSIディレクトリサービスは、オブジェクトの周りで情報を保存して、検索して、階層構造でそれらのオブジェクトを配置するために強力なメカニズムを定義します。 ディレクトリで多くのタイプのオブジェクトと情報を保存できます、ホワイトページ情報、アプリケーション情報、サービス情報などを含んでいて この情報へのアクセスを許すために定義されたOSIプロトコルはディレクトリAccessプロトコル(DAP)です。 DAPはOSI応用層プログラムであり、かなりヘビー級であり、パワーを計算して、実装する投資をコード化するのをかなりの量に要求します。

   The DIXIE protocol is designed for use by smaller hosts (e.g.,
   Macintoshes and PCs) that do not have the computing power or
   necessary software to implement a full OSI protocol stack.  The DIXIE
   protocol is also useful for any Internet application that wants a
   simple interface to X.500 that requires very little coding
   investment.

コンピューティングパワーを持っていないより小さいホスト(例えば、マッキントッシュとPC)か必要なソフトウェアによる使用が、完全なOSIがプロトコル・スタックであると実装するように、デキシープロトコルは設計されています。 また、デキシープロトコルも投資をコード化しながらほとんど必要でないX.500に簡単なインタフェースを必要とするどんなインターネットアプリケーションも役に立ちます。

   The basic idea behind DIXIE is the same as that described in RFC 1202
   for the Directory Assistance Protocol.  DIXIE offers both UDP and TCP
   access to The Directory.  While the Directory Assistance Protocol
   exports something of a user interface, DIXIE provides a more direct
   protocol translation.

デキシーの後ろの基本的な考え方はディレクトリAssistanceプロトコルのためにRFC1202で説明されたそれと同じです。 デキシーはUDPとTCPアクセスのディレクトリへの両方を提供します。 ディレクトリAssistanceプロトコルはある種のユーザーインタフェースをエクスポートしますが、デキシーは、よりダイレクトなプロトコル変換を提供します。

1.1   History

1.1 歴史

   The DIXIE protocol has evolved over time, slowly growing into the
   protocol described by this document.  Without an understanding of the
   circumstances surrounding this evolution, the wisdom of some of the
   DIXIE design decisions may not be apparent.

ゆっくりこのドキュメントによって説明されたプロトコルになって、デキシープロトコルは時間がたつにつれて、発展しました。 事情の理解がこの発展を囲まないで、デキシーデザイン決定のいくつかの知恵は明らかでないかもしれません。

2.    Protocol

2. プロトコル

   This section describes the DIXIE protocol in detail.  DIXIE follows a
   client-server request and response paradigm.  Clients send request
   packets to a DIXIE server, and the server sends reply packets in
   return.  Communication may be over UDP or TCP, depending upon the
   needs of the client.  All modification operations (ADD, REMOVE,
   MODIFY, MODIFYRDN) must be performed over a TCP connection, which

このセクションは詳細にデキシープロトコルについて説明します。 デキシーはクライアント/サーバ要求と応答パラダイムに従います。 クライアントはデキシーサーバにリクエスト・パケットを送ります、そして、サーバは代わりに回答パケットを送ります。 クライアントの必要性によって、UDPかTCPの上にコミュニケーションがあるかもしれません。 TCP接続の上ですべての変更操作(削除、ADD、MODIFY、MODIFYRDN)を実行しなければならない、どれ

Howes, Smith, & Beecher                                         [Page 2]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[2ページ]RFC1249デキシー1991年8月

   provides some level of authentication.

何らかのレベルの認証を提供します。

   Whichever method of communication is used, the general packet format
   is the same.  Each packet consists of a sixteen octet header followed
   by some data.  The format of the header and data for each kind of
   request is described below.

どの伝達方法が使用されていても、一般的なパケット・フォーマットは同じです。 各パケットはいくつかのデータがあとに続いた16八重奏ヘッダーから成ります。 各種類の要求のためのヘッダーとデータの形式は以下で説明されます。

   The representation used for all X.500 data passed between the server
   and the client is the QUIPU EDB format.  So, for example, a
   Distinguished Name might look something like "c=US@o=University of
   Michigan".  For a complete description of this format, see volume 5
   of the ISODE Manual.

サーバとクライアントの間で通過されたすべてのX.500データに使用される表現はQUIPU EDB形式です。 そのように、例えば、Distinguished Nameは「c= US@o はミシガン大学と等しいです」のように見えるかもしれません。 この形式の完全な記述に関しては、ISODE Manualの第5巻を見てください。

   The DIXIE server listens on port 96 for both UDP packets and TCP
   connections.

デキシーサーバはUDPパケットとTCP接続の両方のためにポート96の上で聴かれます。

2.1   Header

2.1 ヘッダー

   The DIXIE packet header is sixteen octets long.  For requests, the
   header is described by the following:

長い間、デキシーパケットのヘッダーは16の八重奏です。 要求において、ヘッダーは以下によって説明されます:

      Start Length    Description
      0       1       An opcode specifying one of the operations
                      described below.  (see section 2.3 for a summary)
      1       2       A request identifier to be included in the reply.
                      This number should be unique to a request.
      3       4       The total length of the request packet, excluding
                      the header.
      7       2       Unused.
      9       1       Options.  Currently, there are only three options.
                      If bit 0 is set, "large" attributes will be
                      included in the response.  The choice of what
                      constitutes large is up to the implementation.
                      If bit 1 is set, the dereference aliases service
                      control will be set for the X.500 operation.  If
                      bit 2 is set, aliases will NOT be dereferenced and
                      searched during a search operation.
      10      1       Protocol version. The current version is 1.
      11      1       For the search operation, this byte specifies the
                      scope of the search.  (see section 2.2.2.1)
      12      2       Timelimit in seconds for the operation.
      14      2       Sizelimit for the operation (search and list).

Length記述0 1An opcodeは以下で説明された操作の1つを指定し始めてください。 (概要に関してセクション2.3を見ます) 回答に含まれるべき1 2A要求識別子。 この数は要求にユニークであるべきです。 3 4、ヘッダーを除いたリクエスト・パケットの全長。 7 2、未使用です。 9 1のオプション。 現在、3つのオプションしかありません。 ビット0が設定されると、「大きい」属性は応答に含まれるでしょう。 多、を構成することの選択は実装まで達しています。 ビット1が設定されると、反参照別名サービス制御はX.500操作に設定されるでしょう。 ビット2が設定されると、別名は、索敵行動の間、「反-参照をつけ」られて、捜されないでしょう。 10 1つのプロトコルバージョン。 最新版は1です。 11 1 索敵行動として、このバイトは検索の範囲を指定します。 (.1は、)2.2に.2を区分するのを見ます。 12 2 操作のための秒のTimelimit。 14 2 操作(捜して、記載する)のためのSizelimit。

Howes, Smith, & Beecher                                         [Page 3]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[3ページ]RFC1249デキシー1991年8月

   For replies, the header is described by the following:

回答において、ヘッダーは以下によって説明されます:

      Start Length    Description
      0       1       A return code specifying either success or
                      describing any error that occurred.  (see
                      section 2.4 for a description of each code)
      1       2       The identifier included in the corresponding
                      request packet.
      3       4       The total length of the response packet, excluding
                      the header.
      7       3       Unused.
      10      1       Protocol version.  The current version is 1.
      11      5       Unused.

Length記述0 1A復帰コードは、成功を指定し始めるか、または発生したあらゆる誤りについて説明し始めてください。 (それぞれのコードの記述に関してセクション2.4を見ます) 対応に識別子を含んでいる1 2はパケットを要求します。 3 4、ヘッダーを除いた応答パケットの全長。 7 3、未使用です。 10 1つのプロトコルバージョン。 最新版は1です。 11 5 未使用です。

   All unused fields should be set to null octets and are reserved for
   future expansion.

すべての未使用の分野が、ヌル八重奏に設定されるべきであり、今後の拡張のために予約されます。

2.2   Operations

2.2 操作

   This section describes the DIXIE operations, which closely parallel
   the X.500 DAP operations.

このセクションはデキシー操作について説明します。(密接に、操作はX.500 DAP操作に沿います)。

2.2.1 Read

2.2.1 読んでください。

   The DIXIE read operation corresponds to an X.500 DAP READ operation.

操作が読まれたデキシーはX.500 DAP READ操作に対応しています。

2.2.1.1 Read Request

2.2.1.1 読み出し要求

   The header opcode should be set to 0x01.  The data portion of the
   packet consists of the DN of the entry to read, a null octet, and
   then a null-octet separated list of attributes whose values are to be
   returned from the read.  If no attributes to return are listed, all
   attributes are returned.  The packet is terminated by two null octets
   in a row.

ヘッダーopcodeは0×01に用意ができるべきです。 パケットのデータ部は読むエントリーのDN、ヌル八重奏、および次に、読みから返される値がことである属性のヌル八重奏の切り離されたリストから成ります。 返すどんな属性も記載されていないなら、すべての属性が返されます。 パケットは2ヌルによって八重奏で並んで終えられます。

2.2.1.2 Read Reply

2.2.1.2 回答を読んでください。

   The reply data for the read operation consists of the entry read,
   followed by a null octet.  An entry consists of the DN of the entry,
   followed by the octet 0x02, followed by a 0x02-octet separated list
   of attribute values.  An attribute value consists of an attribute
   type, followed by the octet 0x01, followed by a 0x01-octet separated
   list of values.  Each attribute type, attribute value and
   distinguished name has the form defined by the QUIPU EDB format.

読書操作のための回答データはヌル八重奏があとに続いたエントリー読書から成ります。 属性値の0×02八重奏の切り離されたリストがあとに続いていて、エントリーは八重奏0x02があとに続いたエントリーのDNから成ります。 属性値は八重奏0x01があとに続いたタイプが値の0×01八重奏の切り離されたリストを続けた属性から成ります。 タイプ、属性が評価して、QUIPU EDBによって定義された書式が分類名でフォーマットする各属性。

Howes, Smith, & Beecher                                         [Page 4]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[4ページ]RFC1249デキシー1991年8月

2.2.2 Search

2.2.2 検索

   The DIXIE search operation corresponds to an X.500 DAP SEARCH
   operation.

デキシー索敵行動はX.500 DAP SEARCH操作に対応しています。

2.2.2.1 Search Request

2.2.2.1 検索要求

   The header opcode should be set to 0x0f.  Octet 11 in the header
   should be set to 0x01, 0x02, or 0x03, for a search scope of base
   object, one level, or whole subtree, respectively.  The data portion
   of the packet consists of the DN of the entry from which to start the
   search, a null octet, a string containing the search filter (dish-
   style), a null-octet, and then a null-octet separated list of
   attributes whose values are to be returned from the search.  If no
   attributes to return are listed, all attributes are returned.  The
   packet is terminated by two null octets in a row.

ヘッダーopcodeは0x0fに用意ができるべきです。 ヘッダーの八重奏11はベースオブジェクト、1つのレベルの検索範囲、または全体の下位木のためにそれぞれ0×01、0×02、または0×03に設定されるべきです。 パケットのデータ部は検索から返される値がことである属性の検索を始めるエントリーのDN、ヌル八重奏、検索フィルタ(皿のスタイル)を入れてあるストリング、ヌル八重奏、および次に、ヌル八重奏の切り離されたリストから成ります。 返すどんな属性も記載されていないなら、すべての属性が返されます。 パケットは2ヌルによって八重奏で並んで終えられます。

2.2.2.2 Search Reply

2.2.2.2 検索回答

   The reply data to the search operation consists of two octets in
   network byte order specifying the number of matches returned.  Next
   comes this number of sequences of the form: one 0x03 octet followed
   by one entry.  Each entry is as described above in section 2.2.1.2.

索敵行動への回答データはマッチの数が返したネットワークバイトオーダー指定における2つの八重奏から成ります。 次に、フォームのこの数の系列が来ます: 1つのエントリーで1つ0x03の八重奏が続きました。 各エントリーが上でセクション2.2.1で.2に説明されるようにあります。

2.2.3 List

2.2.3 リスト

   The DIXIE list operation corresponds to an X.500 DAP LIST operation.

デキシーリスト操作はX.500 DAP LIST操作に対応しています。

2.2.3.1 List Request

2.2.3.1 リスト要求

   The header opcode should be set to 0x10.  The data portion of the
   packet consists of the DN of the entry on which to perform the list,
   followed by a null octet.

ヘッダーopcodeは0×10に用意ができるべきです。 パケットのデータ部はヌル八重奏があとに続いたリストを実行するエントリーのDNから成ります。

2.2.3.2 List Reply

2.2.3.2 リスト回答

   The reply data to the list operation consists of two octets in
   network byte order specifying the number of subordinates returned,
   followed by this number of sequences of the form: one 0x03 octet
   followed by a Relative Distinguished Name of a subordinate.

リスト操作への回答データは部下の数が返したネットワークバイトオーダー指定における2つの八重奏から成ります、フォームのこの数の系列があとに続いていて: 1つ0x03の八重奏が部下のRelative Distinguished Nameで続きました。

2.2.4 Modify

2.2.4、変更

   The DIXIE modify operation corresponds to an X.500 DAP MODIFY
   operation.

デキシーは操作を変更します。X.500 DAP MODIFY操作に対応しています。

Howes, Smith, & Beecher                                         [Page 5]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[5ページ]RFC1249デキシー1991年8月

2.2.4.1 Modify Request

2.2.4.1 要求を変更してください。

   The header opcode should be set to 0x02.  The data portion of the
   packet consists of the DN of the entry to modify, followed by a null
   octet, followed by a null-separated list of modify operations to
   perform.  Each modify operation is one of the following:

ヘッダーopcodeは0×02に用意ができるべきです。 パケットの一部が変更するためにエントリーのDNから成って、ヌル八重奏で続いて、ヌルで切り離されたリストで続いたデータは、働くように操作を変更します。 それぞれ変更する、操作は以下の1つです:

           type            remove attribute type
           type=value      make value the sole value for attribute type
           type+=value     add value to attribute type
           type-=value     remove value from attribute type

タイプはタイプ=がタイプ+=が=をタイプしている属性タイプ値への値が属性タイプから値を取り除くと言い足すのを評価する属性タイプのために値を唯一の値にするのを評価する属性タイプを外します。

   The second form will see to it that existing values (if any) are
   deleted before the new ones are added.  The third form will add the
   attribute type if it does not already exist.  Note that the QUIPU EDB
   format, used to specify value, allows multiple values to be specified
   separated by the "&" character.  This operation is only allowed over
   TCP.

2番目のフォームは、新しい方が加えられる前に既存の値(もしあれば)が削除されるように取り計らうでしょう。 既に存在していないと、3番目のフォームは属性タイプを加えるでしょう。 値を指定するのに使用されるQUIPU EDB形式が、複数の値が指定されるのを許容するというメモは“&"キャラクタで分離しました。 この操作はTCPの上で許されているだけです。

2.2.4.2 Modify Reply

2.2.4.2 回答を変更してください。

   There is no reply data for the modify operation.  The only indication
   of success or failure is the return code in the header.

回答データが全くない、操作を変更してください。 成否の唯一のしるしがヘッダーの復帰コードです。

2.2.5 Modify RDN

2.2.5 RDNを変更してください。

   The DIXIE modify RDN operation corresponds to an X.500 DAP  MODIFYRDN
   operation.

デキシーはRDN操作を変更します。X.500 DAP MODIFYRDN操作に対応しています。

2.2.5.1 Modify RDN Request

2.2.5.1 RDN要求を変更してください。

   The header opcode should be set to 0x13.  The data portion of the
   packet consists of the DN of the entry to modify, followed by a null
   octet, followed by the new RDN the entry should have, followed by a
   final null octet.  The old value of the RDN is never kept as an
   attribute of the entry.  This operation is only allowed over TCP.

ヘッダーopcodeは0×13に用意ができるべきです。 最終的なヌル八重奏でエントリーにはあるべきである新しいRDNによって続かれたヌル八重奏があとに続いていて、パケットの一部が変更するためにエントリーのDNから成らせるデータが従いました。 RDNの古い値はエントリーの属性として決して保たれません。 この操作はTCPの上で許されているだけです。

2.2.5.2 Modify RDN Reply

2.2.5.2 RDN回答を変更してください。

   There is no reply data to the modify RDN operation.  The only
   indication of success or failure is the return code in the header.

回答データが全くない、RDN操作を変更してください。 成否の唯一のしるしがヘッダーの復帰コードです。

2.2.6 Add

2.2.6 加えてください。

   The DIXIE add operation corresponds to an X.500 DAP ADD operation.

デキシーは、操作がX.500 DAP ADD操作に対応すると言い足します。

Howes, Smith, & Beecher                                         [Page 6]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[6ページ]RFC1249デキシー1991年8月

2.2.6.1 Add Request

2.2.6.1 要求を加えてください。

   The header opcode should be set to 0x11.  The data portion of the
   packet consists of the DN of the entry to add, followed by a null
   octet, followed by a null-separated list of the entry's attributes.
   Each attribute in this list has the form:

ヘッダーopcodeは0×11に用意ができるべきです。 パケットのデータ部は加えるエントリーのDNから成ります、エントリーの属性のヌルで切り離されたリストがあとに続いたヌル八重奏があとに続いていて。 このリストの各属性に、フォームがあります:

           type=value

=値をタイプしてください。

   where value can consist of a single value, or multiple values
   separated by the "&" character.  The request is terminated by two
   null octets in a row.  This operation is only allowed over TCP.

値がただ一つの値、または“&"キャラクタによって切り離された複数の値から成ることができるところ。 要求は2ヌルによって八重奏で並んで終えられます。 この操作はTCPの上で許されているだけです。

2.2.6.2 Add Reply

2.2.6.2 回答を加えてください。

   There is no reply data to the add operation.  The only indication of
   success or failure is the return code in the header.

回答データが全くない、操作を加えてください。 成否の唯一のしるしがヘッダーの復帰コードです。

2.2.7 Remove

2.2.7 取り外してください。

   The DIXIE remove operation corresponds to an X.500 DAP REMOVE
   operation.

デキシーは操作を移します。X.500 DAP REMOVE操作に対応しています。

2.2.7.1 Remove Request

2.2.7.1 要求を取り除いてください。

   The header opcode should be set to 0x12.  The data portion of the
   packet consists of the DN of the entry to remove, followed by a null
   octet.  This operation is only allowed over TCP.

ヘッダーopcodeは0×12に用意ができるべきです。 ヌル八重奏があとに続いていて、パケットのデータ部は取り除くエントリーのDNから成ります。 この操作はTCPの上で許されているだけです。

2.2.7.2 Remove Reply

2.2.7.2 回答を取り除いてください。

   There is no reply data for the remove operation.  The only indication
   of success or failure is the return code in the header.

回答データが全くない、操作を取り除いてください。 成否の唯一のしるしがヘッダーの復帰コードです。

2.2.8 Bind

2.2.8 ひも

   The DIXIE bind operation corresponds to an X.500 DAP BIND operation
   using simple authentication as defined in Recommendation X.509.

デキシーひもの操作は、Recommendation X.509で定義されるように簡易認証を使用することでX.500 DAP BIND操作に対応しています。

2.2.8.1 Bind Request

2.2.8.1 ひもの要求

   The header opcode should be set to 0x04.  The data portion of the
   packet consists of the DN of the entry as which to bind, followed by
   a null octet, followed by the password of the entry as which to bind,
   followed by a final null octet.  A null DN corresponds causes a bind
   as NULLDN to occur.

ヘッダーopcodeは0×04に用意ができるべきです。 最終的なヌル八重奏でひもに従ったパケットの一部がどれがエントリーに関するパスワードでヌル八重奏があとに続いたひもに続いたかとしてのエントリーのDNから成るデータ。 ヌルDNは対応しています。NULLDNとしてのひもが起こることを引き起こします。

Howes, Smith, & Beecher                                         [Page 7]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[7ページ]RFC1249デキシー1991年8月

2.2.8.2 Bind Reply

2.2.8.2 ひもの回答

   The format of the bind reply packet depends on whether the operation
   was invoked over TCP or UDP.  If the operation was invoked over TCP,
   there is no reply data.  Success or failure of the operation is
   indicated by the return code in the packet header.

ひもの回答パケットの形式は操作がTCPかUDPの上に呼び出されたかどうかに依存します。 操作がTCPの上に呼び出されたなら、回答データが全くありません。 操作の成否はパケットのヘッダーで復帰コードによって示されます。

   If the bind operation was invoked over UDP, the data portion of the
   reply packet consists of an Internet address in standard dot
   notation, followed by a 0x01 octet, followed by a decimal number (in
   text form), followed by a null octet.  The address and number should
   be taken to be the IP address and port number to which the client
   should connect to obtain an authenticated TCP connection, bound as
   the entity specified in the request packet.

ひもの操作がUDPの上に呼び出されたなら、回答パケットのデータ部はインターネット・アドレスから10進数(テキストフォームにおける)があとに続いたヌル八重奏があとに続いた0×01八重奏があとに続いた標準のドット記法で成ります。 クライアントが認証されたTCP接続を得るために接続するべきであるIPアドレスとポートナンバーになるようにアドレスと数を取るべきです、リクエスト・パケットで指定された実体として、制限されています。

2.3 Operation Code Summary

2.3 命令コード概要

   This section describes the  possible  values  for  the  DIXIE  header
   operation code.  There are currently 8 possible values:

このセクションはデキシーヘッダー命令コードのために可能な値について説明します。 現在、8つの可能な値があります:

      0x01    Read
      0x02    Modify
      0x04    Bind
      0x0f    Search
      0x10    List
      0x11    Add
      0x12    Remove
      0x13    Modify RDN

検索0x10リスト0x11が、0×12が取り外すと言い足す0×04ひもの0x0fを変更する、0×01が、0×02を読む0×13はRDNを変更します。

2.4 Return Code Summary

2.4 復帰コード概要

   This section describes the possible values for the the DIXIE header
   return code.  There are currently 17 possible values:

このセクションはデキシーヘッダー復帰コードのために可能な値について説明します。 現在、17の可能な値があります:

      0x01    The request was successful.
      0x02    The search did not find any matches.
      0x03    Some unknown, generic DIXIE error has occurred.
      0x04    The DIXIE opcode was not recognized by the DIXIE server.
      0x05    Insufficient access to perform a modification.
      0x06    A malformed DN was supplied.
      0x07    Some time limit or size limit was reached.
              Partial results will be returned.
      0x08    A modify was attempted before a bind.
      0x09    A fragment requested was not found.
      0x0a    An attribute type specified is invalid.
      0x0b    An attribute specified does not exist in the entry.
      0x0c    An attribute value specification is invalid.
      0x0d    An attribute value does not exist (as for removal of the

0×01 要求はうまくいきました。 0×02 検索はどんなマッチにも当たりませんでした。 0×03 何らかの未知のジェネリックデキシー誤りが発生しました。 0×04 デキシーopcodeは. 0×05Insufficientが変更を実行するためにアクセスするデキシーサーバによって認識されませんでした。 0×06 奇形のDNを供給しました。 0×07 何らかのタイムリミットかサイズ限界に達しました。 部分的な結果は返されるでしょう。 Aが変更する0×08はひもの前に試みられました。 断片が要求した0×09は見つけられませんでした。 属性タイプが指定した0x0a Anは無効です。 属性が指定した0x0bはエントリーに存在していません。 0x0c、属性値仕様は無効です。 属性が評価する0x0dが存在していない、(取り外し

Howes, Smith, & Beecher                                         [Page 8]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[8ページ]RFC1249デキシー1991年8月

              value).
      0x0e    A modification of an entry's RDN was attempted via a modify
              operation.  This is not allowed (use modrdn instead).
      0x0f    A supplied DN references an invalid portion of the tree.
      0x10    The DSA has passed back a referral to another DSA (as for a
              modification to a non-local entry), and the DIXIE server was
              unable to follow it.
      0x11    The DSA is down or unreachable.

値) エントリーのRDNの0x0e A変更はaを通して試みられました。操作を変更してください。 これは許容されていません(代わりにmodrdnを使用してください)。 0x0f Aは木の無効の部分をDN参照に供給しました。 0×10 DSAは別のDSA(非地方のエントリーへの変更のような)に紹介を戻して、デキシーサーバはそれに続くことができませんでした。 0×11 DSAは下がっているか、または手が届きません。

3.    References

3. 参照

   [1] Information Processing - Open Systems Interconnection - The
       Directory, International Organization for Standardization,
       International Standard 9594, 1988.

[1] 情報処理--オープン・システム・インターコネクション--ディレクトリ、国際標準化機構、国際規格9594、1988。

   [2] Kille, S., Robbins, C., Roe, M., and A. Turland, "The ISO
       Development Environment: User's Manual", Volume 5: QUIPU,
       Performance Systems International, January 1990.

[2]Kille、S.、ロビンス、C.、魚卵、M.、およびA.Turland、「ISO開発環境:」 「ユーザマニュアル」、第5巻: 結び縄文字、国際言語運用機構、1990年1月。

   [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance
       Systems International, February 1991.

[3] ローズ、M.、「ディレクトリ支援サービス」、RFC1202、国際言語運用機構、1991年2月。

4.    Available Implementations

4. 利用可能な実装

       This section is not meant as an endorsement of any
       implementation, it is provided merely as information for the
       Internet community.  A full Un*x-based implementation of the
       DIXIE protocol in the form of a DIXIE server and DIXIE
       application library is freely available for anonymous FTP from
       the host terminator.cc.umich.edu in the ~ftp/x500 directory.
       Un*x and Macintosh clients that use the DIXIE protocol have also
       been implemented and are available from the same location.

どんな実装の裏書きとしてもこのセクションを意味しないで、単にインターネットコミュニティのための情報としてそれを提供します。 デキシーサーバとデキシーアプリケーションライブラリの形のデキシープロトコルの完全なUn*xベースの実装は自由に~ftp/x500ディレクトリのホストterminator.cc.umich.eduからの公開FTPに利用可能です。 デキシープロトコルを使用する不-*xとマッキントッシュクライアントは、また、実装されて、同じ位置から手があいています。

       There is also a discussion list for DIXIE-related topics called
       dixie@terminator.cc.umich.edu.  To join, send mail to dixie-
       request@terminator.cc.umich.edu.

また、 dixie@terminator.cc.umich.edu と呼ばれるデキシー関連の話題のための議論リストがあります。 接合するには、大きな鉄鍋 request@terminator.cc.umich.edu にメールを送ってください。

5.    Security Considerations

5. セキュリティ問題

   Security issues are not discussed in this memo.

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

Howes, Smith, & Beecher                                         [Page 9]

RFC 1249                         DIXIE                       August 1991

ハウズ、スミス、およびビーチャー[9ページ]RFC1249デキシー1991年8月

6.    Authors' Addresses

6. 作者のアドレス

   Tim Howes
   University of Michigan
   Information Technology Division
   535 West William St.
   Ann Arbor, MI 48103-4943

西ウィリアム・聖アナーバー、ティムハウズミシガン大学情報技術師団535MI48103-4943

   Phone: +1 313 764-2278
   EMail: tim@umich.edu

以下に電話をしてください。 +1 313 764-2278 メールしてください: tim@umich.edu

   Mark Smith
   University of Michigan
   Information Technology Division
   535 West William St.
   Ann Arbor, MI 48103-4943

西ウィリアム・聖アナーバー、マークスミスミシガン大学情報技術師団535MI48103-4943

   Phone: +1 313 764-2277
   EMail: mcs@umich.edu

以下に電話をしてください。 +1 313 764-2277 メールしてください: mcs@umich.edu

   Bryan Beecher
   University of Michigan
   Information Technology Division
   535 West William St.
   Ann Arbor, MI 48103-4943

西ウィリアム・聖アナーバー、ブライアンビーチャーミシガン大学情報技術師団535MI48103-4943

   Phone: +1 313 764-4050
   EMail: bryan@umich.edu

以下に電話をしてください。 +1 313 764-4050 メールしてください: bryan@umich.edu

Howes, Smith, & Beecher                                        [Page 10]

ハウズ、スミス、およびビーチャー[10ページ]