RFC1804 日本語訳

Network Working Group                                       G. Mansfield
Request for Comments: 1804                              AIC Laboratories
Category: Experimental                                         P. Rajeev
                                                 Hughes Software Systems
                                                             S. Raghavan
                                  Indian Institute of Technology, Madras
                                                                T. Howes
                                                  University of Michigan
                                                               June 1995

コメントを求めるワーキンググループG.マンスフィールド要求をネットワークでつないでください: 1804年のアイク研究所カテゴリ: 実験用P.Rajeevヒューズソフトウェア・システムS.ラガバンインド工科大学、マドラスT.ハウズミシガン大学1995年6月

                  Schema Publishing in X.500 Directory

X.500ディレクトリにおける図式出版

Status of this Memo

このMemoの状態

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

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

Abstract

要約

   The X.500 directory provides a powerful mechanism for storing and
   retrieving information about objects of interest.  To interpret the
   information stored in the directory, the schema must be known to all
   the components of the directory. Presently, there are no means other
   than ftp to distribute schema information across the Internet.  This
   is proving to be a severe constraint as the Directory is growing.
   This document presents a solution to the schema distribution problem
   using the existing mechanisms of the directory. A naming scheme for
   naming schema objects and a meta-schema for storing schema objects is
   presented. The procedures for fetching unknown schema from the
   directory at runtime are described.

X.500ディレクトリは興味があるオブジェクトの情報を保存して、検索するのに強力なメカニズムを提供します。 ディレクトリに保存された情報を解釈するために、ディレクトリのすべての部品に図式を知っていなければなりません。 現在、インターネットの向こう側に図式情報を分配するために、ftp以外の手段は全くありません。 これはディレクトリが成長しているので厳しい規制であると判明しています。 このドキュメントはディレクトリの既存のメカニズムを使用することにおける図式分配問題にソリューションを提示します。 図式オブジェクトとメタ図式を図式オブジェクトを保存するのにちなんで命名することの命名体系は提示されます。 ランタイムのディレクトリからの魅惑的な未知の図式のための手順は説明されます。

Table of Contents

目次

   1. Introduction                                         2
   2. Schema Management                                    2
   3. Storage of Schema Information in the Directory       3
   4. Retrieval of Schema from the Directory               5
   5. The Meta-Schema                                      6
   6. References                                           9
   7. Security Considerations                              9
   8. Authors' Addresses                                  10

1. 序論2 2。 図式管理2 3。 ディレクトリ3 4における、図式情報のストレージ。 ディレクトリ5 5からの図式の検索。 メタ図式6 6。 参照9 7。 セキュリティ問題9 8。 作者のアドレス10

Mansfield, et al              Experimental                      [Page 1]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[1ページ]RFC1804Schema出版

1. Introduction

1. 序論

   The X.500 Directory [1] is now used for a wide range of applications
   from name/address lookup to network management, from restaurant
   information to bibliographic information services. This information
   is distributed and managed across a network of many autonomous sites.
   In order to interpret the information stored in the directory, the
   components of the directory must have knowledge about the structure
   and representation (schema) of the information held within the
   directory.

X.500ディレクトリ[1]は現在さまざまな名前/アドレスルックアップからネットワークマネージメントまでのアプリケーションに使用されます、レストラン、飲食店情報から図書目録の情報サービスまで。 この情報は、多くの自治のサイトのネットワークの向こう側に分配されて、管理されます。 ディレクトリに保存された情報を解釈するために、ディレクトリの部品はディレクトリの中に保持された情報の構造と表現(図式)に関して心得がなければなりません。

   The distributed nature of the network and the relatively slow process
   of standardization have given rise to the challenging task of making
   accessible the information about the schema rules themselves.  A
   mechanism for making the schema accessible to the functional
   components of the directory is urgently required.

ネットワークの分配された本質と標準化の比較的遅いプロセスは図式規則自体の情報をアクセスしやすくするやりがいのある仕事をもたらしました。 図式をディレクトリの機能部品にアクセスしやすくするためのメカニズムが緊急に必要です。

   The 1993 X.500 Directory Standard [2] has attempted to address the
   problem of schema management and distribution. The 1993 framework
   does provide the means for storing and retrieving schema information
   in the directory. However, the resolution of unknown OIDs will
   require both the DUA and the DSA to be compliant with [2].

1993X.500ディレクトリStandard[2]は、図式管理と分配のその問題を訴えるのを試みました。 1993年のフレームワークはディレクトリの図式情報を保存して、検索するための手段を提供します。 しかしながら、未知のOIDsの決議は、DUAとDSAの両方が[2]で言いなりになるのを必要とするでしょう。

   In this document we propose a solution using the existing mechanisms
   of the directory [1] itself. We present a naming scheme for naming
   schema objects and a meta-schema for storing schema objects in the
   directory.  The proposal allows the algorithmic resolution of unknown
   objects in the directory and in the absence of 1993 X.500 Directory
   Standard implementations provides an interim solution to the schema
   publishing problem.

本書では私たちは、ディレクトリ[1]自体の既存のメカニズムを使用することでソリューションを提案します。 私たちは図式オブジェクトと図式オブジェクトを蓄えるためのメタ図式をディレクトリと命名することの命名体系を提示します。 提案は、ディレクトリで未知のオブジェクトのアルゴリズムの解決を許して、1993のX.500ディレクトリStandard実装がないとき図式出版問題に当座の解決法を提供します。

2. Schema Management

2. 図式管理

   The storage and retrieval mechanism provided by the directory is
   powerful and flexible.  However, the key to the directory is the
   knowledge of the schema rules defined for the objects represented in
   the directory.  To facilitate the diffusion of this knowledge
   appropriate schema management mechanisms need to be designed.  Schema
   management involves:

ディレクトリによって提供されたストレージと回収機構は、強力であって、フレキシブルです。 しかしながら、ディレクトリのキーはディレクトリに表されたオブジェクトのために定義された図式規則に関する知識です。 この知識の拡散を容易にするために、適切な図式管理メカニズムは、設計されている必要があります。 図式経営者側は以下を伴います。

        o Storage of schema information in the directory
        o Algorithmic access to and retrieval of schema information
          in the directory
        o Definition of rules for schema modification
        o Propagation of schema information from one component of the
          directory to other components of directory

o 図式情報のディレクトリo Algorithmicアクセスと検索における、図式情報のディレクトリの1つの部品からディレクトリの他の部品までの図式変更o Propagationのための規則のディレクトリo Definitionにおける、図式情報のストレージ

Mansfield, et al              Experimental                      [Page 2]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[2ページ]RFC1804Schema出版

   In this document we concentrate on the aspect of schema
   access/retrieval from the directory. Since schema objects are defined
   and employed, the modification , addition and deletion of schema
   objects can be carried out using existing directory mechanisms. But
   the operational issue of synchronizing the schema with the DIB will
   require further attention.  Similarly the issue of schema propagation
   requires further work and is outside the scope of this document.  The
   strategy proposed in this document has a very simple and workable
   approach.  No added DAP/DSP functionality is envisaged. At the same
   time by using the directory's distributed framework scalability
   problems are avoided.  In essence, it allows the distributed storage
   of schema objects and proposes a naming scheme which allows
   algorithmic schema retrieval. Of course, on the down side, more than
   one directory read operation may be required to retrieve the
   information about an object and its attributes, as objects and
   attributes are stored as separate entries in the directory.

本書では私たちはディレクトリから図式アクセス/検索の局面に集中します。 図式オブジェクトが定義されて、使われるので、既存のディレクトリメカニズムを使用することで図式オブジェクトの変更、追加、および削除を行うことができます。しかし、図式をDIBと同期させる操作上の問題はさらなる注意を必要とするでしょう。 同様に、図式伝播の問題は、さらなる仕事を必要として、このドキュメントの範囲の外にあります。 本書では提案された戦略は非常に簡単で実行可能なアプローチを持っています。 付記されたDAP/DSPの機能性は全く考えられません。 ディレクトリの分配されたフレームワークを使用するのによる同時に、スケーラビリティ問題は避けられます。 本質では、それは、図式オブジェクトの分配されたストレージを許して、アルゴリズムの図式検索を許す命名体系を提案します。 もちろん、悲観的に見れば、操作が読まれた1つ以上のディレクトリがオブジェクトとその属性の情報を検索するのに必要であるかもしれません、オブジェクトと属性がディレクトリにおける別々のエントリーとして保存されるとき。

   As schema information of all objects in a naming context are stored
   below the root entry of that naming context, the same DSA will be
   able to supply the schema information stored in that DSA. Thus there
   is no need to contact another DSA for resolving the schema of an
   object stored in the local DSA.

すべての図式情報として、命名文脈のオブジェクトはその命名文脈の根のエントリーの下に保存されて、同じDSAはそのDSAに保存された図式情報を提供できるでしょう。 したがって、地方のDSAに保存されたオブジェクトの図式を決議するために別のDSAに連絡する必要は全くありません。

3. Storage of Schema Information in the Directory

3. ディレクトリにおける、図式情報のストレージ

   The schema information may be stored and distributed using mechanisms
   external to the X.500 directory standard [5]. This document proposes
   storing schema information in the directory.  It has the following
   advantages:

図式情報は、X.500ディレクトリ規格[5]への外部のメカニズムを使用することで保存されて、分配されるかもしれません。 このドキュメントは、ディレクトリの図式情報を保存するよう提案します。 それには、以下の利点があります:

        o The components of the directory can access the schema
          information using the standard directory protocols.

o 標準のディレクトリプロトコルを使用することでディレクトリの部品は図式情報にアクセスできます。

        o The nature of the directory naturally allows the schema
          to be distributed. Schema used locally can be kept in the
          local DSA itself whereas schema for general objects like
          person, organization etc can be made available to all
          components of the directory by publishing it.

o ディレクトリの本質は、図式が分配されるのを自然に許容します。 局所的に使用される図式は人のような一般的なオブジェクトのために地方のDSA自身にもかかわらず、図式で保たれます、組織などをそれを発行することによってディレクトリのすべての部品に利用可能にすることができるということであるかもしれません。

   In the operational model, the schema information in the directory is
   expected to complement the schema information held in central
   repositories.

オペレーショナル・モデルでは、ディレクトリの図式情報が中央倉庫に保持された図式情報の補足となると予想されます。

Mansfield, et al              Experimental                      [Page 3]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[3ページ]RFC1804Schema出版

3.1  Naming Scheme for the Schema

3.1 図式の体系を命名すること。

   The schema information is stored in a distributed manner.  We propose
   a model in which each naming context stores the schema relevant to
   it.

図式情報は分配された方法で保存されます。 私たちはそれぞれの命名文脈がそれに関連している図式を保存するモデルを提案します。

                                Root
                                    \
                                     \
                        +-------------\----------------------+
                        |            C=IN            DSA-1   |
                        |          /      \                  |
                        |         /        \                 |
                        |        /          \                |
                        |       /            \               |
                        |      /          cn=subschema       |
                        |     /           /  / | \ \ \       |
                        |    /           /  /  |  \ \ \      |
                        |   /          oid= oid=             |
                        +--/---------------------------------+
                          /
  +----------------------/----------------------+
  |                o=IIT, Madras      DSA-2     |
  |                 /           \               |
  |                /             \              |
  |               /               \             |
  |              /                 \            |
  |         ou=CSE             cn=subschema     |
  |         /    \             /   /| \ \ \     |
  |        /      \           /   / |  \ \ \    |
  |ipni=spark  cn=Rajeev oid=ipni  oid=         |
  +---------------------------------------------+

根の\\+-------------\----------------------+ | DSA-1のC=| | / \ | | / \ | | / \ | | / \ | | /cnはサブスキーマと等しいです。| | / / / | \ \ \ | | / / / | \ \ \ | | /oid= oid=| +--/---------------------------------+ / +----------------------/----------------------+ | o=IIT、マドラスDSA-2| | / \ | | / \ | | / \ | | / \ | | ou=CSE cnはサブスキーマと等しいです。| | / \ / /| \ \ \ | | / \ / / | \ \ \ | |ipniはスパークcn=Rajeev oid=ipni oid=と等しいです。| +---------------------------------------------+

         Figure 1: DIT with schema objects

図1: 図式オブジェクトがあるDIT

   To store the schema information, an object called subschema object is
   defined. This object can come anywhere in the Directory Information
   Tree (DIT). The subschema is defined as a subclass of Top.  The
   subschema entry is stored below the root entry of a naming context.
   The root entry of a naming context must contain a subschema subentry,
   named {CN= Subschema}.  This standard naming methodology is necessary
   so that the components of the directory can easily and
   algorithmically locate the schema entries.  All schema information
   relevant to that naming context is stored below the subschema entry.
   Children of the subschema entry store information about objects,
   attribute types, attribute syntaxes or matching rules. The DIT

図式情報を保存するために、サブスキーマオブジェクトと呼ばれるオブジェクトは定義されます。 このオブジェクトはディレクトリ情報Tree(DIT)でどこでも来ることができます。 サブスキーマはTopのサブクラスと定義されます。 サブスキーマエントリーは命名文脈の根のエントリーの下に保存されます。 命名文脈の根のエントリーはCN=サブスキーマというサブスキーマ副次的記載を含まなければなりません。 方法論を命名するこの規格が、ディレクトリの部品が簡単にalgorithmicallyに図式エントリーの場所を見つけることができるくらい必要です。 その命名文脈に関連しているすべての図式情報がサブスキーマエントリーの下に保存されます。 サブスキーマエントリーの子供はオブジェクト、属性タイプ、属性構文または合っている規則の情報を保存します。 デイット

Mansfield, et al              Experimental                      [Page 4]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[4ページ]RFC1804Schema出版

   structure for storing schema information is shown in Figure 1.
   Schema for these objects are given in section 5.

図式情報を保存するための構造は図1で見せられます。 セクション5でこれらのオブジェクトのための図式を与えます。

4. Retrieval of Schema from the Directory

4. ディレクトリからの図式の検索

   When an unknown object is encountered by any component of directory
   during a directory operation, it proceeds the following way to
   resolve the schema.

未知のオブジェクトがディレクトリ操作の間ディレクトリのどんな部品でも遭遇するとき、それは図式を決議する以下の方法を続かせます。

   The RDN component at the leaf-end of the name of the object whose
   schema is to be resolved is replaced by the RDNs "oid=<object
   identifier of the new object>, CN=subschema" and a read request is
   initiated for the newly formed name.  If the entry is not found, two
   RDN components from the leaf-end of the name of the object are
   replaced by the RDNs "oid=<object identifier of the new object>,
   CN=subschema" and another read is attempted. The process continues
   until the read succeeds.  For example, while resolving the schema of
   the object "IPNI=spark, OU=Department of Computer Science, O=Indian
   Institute of Technology, Madras , C=IN", if the schema of the object
   IPNI (IP Node Image) is not known to a component of the directory,
   the following procedure will be adopted.

決議される図式がことであるオブジェクトの名前のバネ板端部のRDNの部品は取り替えて、RDNsが「新しいオブジェクト>、CN=サブスキーマに関する=<オブジェクト識別子をoidし」て、読み出し要求が新たに形成された名前のために開始されるということです。 エントリーを見つけないなら、オブジェクトの名前のバネ板端部からの2つのRDNの部品を「oidは新しいオブジェクト>に関する<オブジェクト識別子と等しいです、CN=サブスキーマ」と別のものが試みられると読んでいるRDNsに取り替えます。 読みが成功するまで、プロセスは持続します。 例えば、オブジェクトIPNI(IP Node Image)の図式がディレクトリの部品に知られていないなら「IPNIはスパーク、OU=コンピュータサイエンス学部、インド工科大学、マドラス、O=C=と等しい」オブジェクトの図式を決議している間、以下の手順が取り入れられるでしょう。

   Let the object id for the object IPNI be ipni.  The RDN "IPNI=spark"
   is removed from the distinguished name of the entry and the RDNs
   "oid=ipni, CN= Subschema" is appended.  The name thus formed is
   "oid=ipni, CN=subschema, OU=Department of Computer Science, O=Indian
   Institute of Technology, Madras, C=IN" A read request is initiated on
   this name.  If the distinguished name "OU= Department of Computer
   Science, O=Indian Institute of Technology, Madras, C=IN" is the
   context prefix of a naming context, this read request will result in
   the directory returning the schema for the object IPNI. If it is not,
   the read operation will fail. In that case, a read operation is
   initiated with distinguished name "oid=ipni, CN= subschema, O=Indian
   Institute of Technology, Madras, C=IN". For the DIT structure shown
   in Figure-1, this query will succeed and the schema information will
   be returned.  The schema for the requested object will always be
   located below the starting entry of the naming context in which the
   entry is located.

オブジェクトIPNIのためのオブジェクトイドがipniであることをさせてください。 エントリーの分類名からRDN「IPNI=スパーク」を取り除きます、そして、RDNs「oid=ipni、CN=サブスキーマ」を追加します。 このようにして形成された名前は「oid=ipni、CN=サブスキーマ、コンピュータScienceのOU=部、O=インド工科大学、マドラス、CはINと等しい」というA読み出し要求がこの名前で開始されるということです。 「OUはコンピュータサイエンス学部、インド工科大学、マドラス、O=C=と等しい」分類名が命名文脈の文脈接頭語であるなら、この読み出し要求がオブジェクトIPNIのために図式を返すディレクトリをもたらすでしょう。 それがないなら、操作が失敗する読みます。 その場合、読書操作は分類名で開始されます。「サブスキーマ、oid=ipni、CN=Oはインド工科大学、マドラス、C=INと等しいです」。 図-1で見せられたDIT構造に、この質問は成功するでしょう、そして、図式情報を返すでしょう。 要求されたオブジェクトのための図式はエントリーが位置している命名文脈の始めのエントリーの下にいつも位置するでしょう。

Mansfield, et al              Experimental                      [Page 5]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[5ページ]RFC1804Schema出版

5. The Meta-Schema

5. メタ図式

experimental = 1.3.6.1.3

実験的な=1.3.6、.1、.3

schema OBJECT IDENTIFIER
        ::= {experimental 65}

図式OBJECT IDENTIFIER:、:= 実験的な65

schemaObjectClass OBJECT IDENTIFIER
        ::= {schema.1}

schemaObjectClassオブジェクト識別子:、:= 図式.1

schemaAttribute OBJECT IDENTIFIER
        ::= {schema.2}

schemaAttributeオブジェクト識別子:、:= 図式.2

subschema OBJECT CLASS
    Subclass of TOP
        MUST CONTAIN {
            commonName
            - -  For naming
        }
        ::= {schemaObjectClass.1}

TOP MUST CONTAINのサブスキーマOBJECT CLASS Subclass、commonName--、命名、:、:= schemaObjectClass.1

objectClass OBJECT CLASS
    Subclass of TOP
        MUST CONTAIN {
            objectIdentifier
                - - This field stores the object identifier of object
                - - represented by an object class entry. This attribute
                - - is used for naming an object class entry.
        }
        MAY CONTAIN {
            commonName,
                 - - This field is used to store the name of the object
            mandatoryNamingAttributes,
            mandatoryAttributes,
            optionalNamingAttibutes,
            optionalAttributes,
            obsolete,
            description,
            subClassOf
        }
        ::= {schemaObjectClass.2}

先端のオブジェクトクラスサブクラスが含まなければならないobjectClass{ objectIdentifier----この分野がオブジェクトに関するオブジェクト識別子を保存する----オブジェクトクラスエントリーで、表されます。 この属性----オブジェクトクラスエントリーを命名するために、使用されます。 } MAY CONTAIN、commonName----この分野はオブジェクトmandatoryNamingAttributesという名前を保存するのに使用されます、mandatoryAttributes、optionalNamingAttibutes、optionalAttributes、時代遅れです、記述、subClassOf、:、:= schemaObjectClass.2

attributeType OBJECT CLASS
    Subclass of Top
        MUST CONTAIN {
            objectIdentifier
        }
        MAY CONTAIN {

先端のattributeTypeオブジェクトクラスサブクラスがobjectIdentifierを含まなければならない、含むかもしれません。

Mansfield, et al              Experimental                      [Page 6]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[6ページ]RFC1804Schema出版

             commonName,
                - - used to store the name of the attribute type
             constraint,
             attributeSyntax,
             multivalued,
             obsolete,
             matchRules,
             description
        }
        ::= {schemaObjectClass.3}

commonName----属性タイプ規制、attributeSyntax、多値の、そして、時代遅れのmatchRulesという名前を保存するのにおいて使用されている、記述 ::= schemaObjectClass.3

matchingRule OBJECT CLASS
     Subclass of Top
        MUST CONTAIN {
             objectIdentifier
        }
         MAY CONTAIN {
             commonName,
             matchtype,
             description,
             obsolete
        }
        ::= {schemaObjectClass.4}

Top MUST CONTAIN objectIdentifierのmatchingRule OBJECT CLASS Subclass、MAY CONTAIN、commonName(matchtype、記述)は時代遅れにします:、:= schemaObjectClass.4

objectIdentifier ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            objectIdentifierSyntax
       ::= {schemaAttribute.1}

objectIdentifierは属性構文objectIdentifierSyntaxと共に以下を結果と考えます:= schemaAttribute.1

mandatoryNamingAttributes ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            SET OF OBJECT IDENTIFIER
       ::= {schemaAttribute.2}

mandatoryNamingAttributesはオブジェクト識別子の属性構文セットで以下を結果と考えます:= schemaAttribute.2

mandatoryAttributes ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            SET OF OBJECT IDENTIFIER
       ::= {schemaAttribute.3}

mandatoryAttributesはオブジェクト識別子の属性構文セットで以下を結果と考えます:= schemaAttribute.3

optionalNamingAttibutes ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            SET OF OBJECT IDENTIFIER
       ::= {schemaAttribute.4}

optionalNamingAttibutesはオブジェクト識別子の属性構文セットで以下を結果と考えます:= schemaAttribute.4

optionalAttibutes ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            SET OF OBJECT IDENTIFIER
       ::= {schemaAttribute.5}

optionalAttibutesはオブジェクト識別子の属性構文セットで以下を結果と考えます:= schemaAttribute.5

Mansfield, et al              Experimental                      [Page 7]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[7ページ]RFC1804Schema出版

obsolete ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            BOOLEAN
                           -- DEFAULT FALSE
       ::= {schemaAttribute.6}

ATTRIBUTE WITH ATTRIBUTE-SYNTAX BOOLEANを時代遅れにしてください--、DEFAULT FALSE:、:= schemaAttribute.6

subClassOf      ATTRIBUTE
        WITH ATTRIBUTE-SYNTAX
                SET OF OBJECT IDENTIFIER
       ::= {schemaAttribute.7}

subClassOfはオブジェクト識別子の属性構文セットで以下を結果と考えます:= schemaAttribute.7

constraint ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            Constraint
       ::= {schemaAttribute.8}

規制ATTRIBUTE WITH ATTRIBUTE-SYNTAX Constraint:、:= schemaAttribute.8

Constraint ::=Choice {
             StringConstraint,
             IntegerConstraint
        }

規制:、:=選択StringConstraint、IntegerConstraint

StringConstraint ::= SEQUENCE {
             shortest INTEGER,
             longest  INTEGER
        }

StringConstraint:、:= 系列最も短いINTEGER、最も長いINTEGER

IntegerConstraint ::= SEQUENCE {
             lowerbound INTEGER,
             upperbound INTEGER OPTIONAL
        }

IntegerConstraint:、:= 系列lowerbound INTEGER、upperbound INTEGER OPTIONAL

attributeSyntax ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
              ASN1DataType
       ::= {schemaAttribute.9}

attributeSyntaxは属性構文ASN1DataTypeと共に以下を結果と考えます:= schemaAttribute.9

multivalued ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            BOOLEAN             -- DEFAULT FALSE
       ::= {schemaAttribute.10}

多値のATTRIBUTE WITH ATTRIBUTE-SYNTAX BOOLEAN--、DEFAULT FALSE:、:= schemaAttribute.10

matchRules ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX
            SET OF OBJECT IDENTIFIER
       ::= {schemaAttribute.11}

matchRulesはオブジェクト識別子の属性構文セットで以下を結果と考えます:= schemaAttribute.11

matchtype ATTRIBUTE
       WITH ATTRIBUTE-SYNTAX

matchtype ATTRIBUTE WITH ATTRIBUTE-SYNTAX

Mansfield, et al              Experimental                      [Page 8]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[8ページ]RFC1804Schema出版

            INTEGER {
             PRESENT                    (0),
             EQUALITY                   (1),
             ORDERING                   (2),
             CASESENSITIVEMATCH         (3),
             CASEINSENSITIVEMATCH       (4)
            }
       ::= {schemaAttribute.12}

(2)、CASESENSITIVEMATCH(3)、CASEINSENSITIVEMATCH(4)を注文して、整数は(0)、平等(1)を提示します:、:= schemaAttribute.12

6. References

6. 参照

   [1] CCITT. "Data Communication Networks: Directory", Recommendations
       X.500 - X.521 1988.

[1] CCITT。 「データ通信は以下をネットワークでつなぎます」 「ディレクトリ」、推薦X.500--X.521 1988。

   [2] CCITT. "Data Communication Networks: Directory", Recommendations
       X.500 - X.525 1993.

[2] CCITT。 「データ通信は以下をネットワークでつなぎます」 「ディレクトリ」、推薦X.500--X.525 1993。

   [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
       RFC 1274, University College London, November 1991.

[3] RFC1274、ユニバーシティ・カレッジロンドン1991年11月のバーカー、P.、S.Kille、および「コサインとインターネットX.500図式」

   [4] Howes, T., "Schema Information in the X.500 Directory", Work in
       Progress, University of Michigan, July 1992.

[4] ハウズ、T.、「X.500ディレクトリにおける図式情報」が1992年7月に進歩、ミシガン大学で働いています。

   [5] Howes, T., Rossen, K., Sataluri, S., and R. Wright, "Procedures
       for Formalization, Evolution, and Maintenance of the Internet
       X.500 Directory Schema", Work in Progress, June 1995.

[5] ハウズとT.とロッセンとK.とSataluri、S.とR.ライト、「インターネットX.500ディレクトリ図式の形式化、発展、およびメインテナンスのための手順」処理中の作業(1995年6月)。

7. Security Considerations

7. セキュリティ問題

   Security issues are not discussed in this memo.

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

Mansfield, et al              Experimental                      [Page 9]

RFC 1804          Schema Publishing in X.500 Directory         June 1995

マンスフィールド、X.500ディレクトリ1995年6月の他のExperimental[9ページ]RFC1804Schema出版

8. Authors' Addresses

8. 作者のアドレス

   Glenn Mansfield
   AIC Systems Laboratories,
   6-6-3, Minami Yoshinari, Aoba-Ku, Sendai,
   Japan

グレンマンスフィールドアイクSystems研究所、6-6-3、Yoshinari、Aoba区、仙台、日本の南

   Phone: +81 (22) 279-3310
   Fax: +81 (22) 279-3640
   EMail: glenn@aic.co.jp

以下に電話をしてください。 +81 (22) 279-3310Fax: +81 (22) 279-3640 メールしてください: glenn@aic.co.jp

   P. V. Rajeev
   Hughes Software Systems,
   2nd Floor, International Trade Tower,
   Nehru Place, New Delhi,
   India

P.V.Rajeevヒューズソフトウェア・システム、2階、国際貿易塔、ネール場所、ニューデリー、インド

   EMail: rajeev%hss@lando.hns.com

メール: rajeev%hss@lando.hns.com

   S. V. Raghavan
   Department of Computer Science and Engineering,
   Indian Institute of Technology, Madras 600 036,
   India

S.V.ラガバンコンピュータサイエンス学部と工学、インド工科大学、マドラス600 036、インド

   EMail: svr@iitm.ernet.in

メール: svr@iitm.ernet.in

   Tim Howes
   University of Michigan
   ITD Research Systems
   535 W William St.
   Ann Arbor, MI 48103-4943, USA

アナーバー、ティムハウズミシガン大学ITDリサーチシステム535Wウィリアム通りMI48103-4943(米国)

   Phone: +1 (313) 747-4454
   EMail: tim@umich.edu

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

Mansfield, et al              Experimental                     [Page 10]

マンスフィールド、他のExperimental[10ページ]